Create a SHP File from a Multi Object Type C3D DWG File from within Civil 3D

[Jake6954]

Hi all,

I am fairly good at importing Shapefiles, an querying the object data for what my needs require in any given scenario.  But now I must create my own .SHP File from a C3D drawing.  And ultimately, the .SHP files I create will be brought back into Civil 3D by others, using MAPIMPORT and Data Querry.

 When I execute the MAPEXPORT command, and come to the "Object Type" section of the "Export" dialog box, what it appears to be asking of me seems clear enough.  That is, if the objects I'm exporting are "Points", then I choose the "Point" object type; and if the objects are "Lines" then I choose the "Line" object type, etc...

 QUESTION 1 - But what I'm getting hung up on what I am supposed to do if my drawing contains all those object types i.e. Points, Lines, Polygons and Text (and I'm assuming the "Line Object Type" would cover 2D and 3D polylines, as well as ordinary lines?), and I want them all in my SHP File??  As it is, it seems my SHP File can be created using just ONE of the Object Type options??

I'm getting hung up on this because I am thinking that having all the object types in source drawing (DWG), is what I want in the final SHP File I create?   And I am thinking that because most of the SHP Files I've ever imported into Civil 3D, seem to have all those things in one file (and by "one file" I mean the SHP File and its associated 5 to 8 support files). 

But maybe I'm misunderstanding something SHP Files?

QUESTION 2 – If anyone knows of a website, video or article that goes into more depth on the topic of Shapefile creation from a Civil 3D Drawing, using Civil 3D, I’m all ears.

I’ve found quite a few short videos and support articles on creating SHP Files from DWG Files in C3D, but in all of them, they deal with only one Object Type…

Thanks in advance for your time.

[ChicagoLooper · Accepted solution]

Hi @Jake6954 

<<....what I am supposed to do if my drawing contains all those object types i.e. Points, Lines, Polygons and Text....>> 

You're supposed to EXPORT each feature class. When exporting AutoCAD objects to shapefile format, the feature class concept is not only the most misunderstood, it's the most ignored too. (And BTW, it shouldn't be ignored.) It's not possible to export more than one feature class to shapefile. 

You should (must) export 3 separate shapefiles: (1) for your points, (2) for your lines, and (3) for your polygons. Combining 2 or more feat. classes is not allowed. Never ever.

You should (must) also create or harvest data, from the points/lines/polygons. Examples include, for manhole points, their ID#s MH101, MH102, MH103, x,y,z coordinates. For street centerlines, the names Main St, State Blvd, Highway 999. county jurisdiction, no. of lanes, etc. For parcel polygons, parcel#, square feet, owner, county name, property taxes, and mailing address for tax bill.

Without data, you won't be able to run queries on your shapefile. Exporting to shapefile is not a plain vanilla AutoCAD procedure and doesn't necessarily conform to, or comply with, plain vanilla commands.   

Depending on the data you utilize when you add the shapefile to modelspace, your data can be either be captured or created from scratch. You may capture, the AutoCAD layer the object resides on, the object's coordinates, objects z-value or elevation, the object's length, object's square foot area, the block attribute values (if exporting a block to shapefile), and much more. Captured data is typically harvested from the same values dispolayed in the Properties Palette. 

Data which you create from scratch include, but are not limited to, parcel ID number, condition of a tree such as good, fair, poor, proposed topographic contour lines, location of city and state, etc. Unlike captured data from the Properties Palette, data created from scratch is customizable and a procedure unto itself. 

The data you successfully export with the individual objects will end up in the shapefile's database (dbf). It's this data that drives those labels you display on your map. The data also fuels a query you may run once the shapefile is added to modelspace. Without data, all you have are dumb points & lines, not smart, data-rich objects that can be queried and isolated with expressions.

If you want multi feature class, then you're no longer dealing with shapefile. Multi-class data is considered a geodatabase (gdb) and that's a completely different entity. AutoCAD's proprietary SDF format is more like gdb than it is shapefile. If you really want to export multiclass, then export to SDF, not shapefile. 

<<The gdb format is proprietary, it's ESRI format so if you want open a file that's gdb format, you'll need an ESRI license, e.g. ArcPro. It's ESRI's product so it's their rule. Don't make the mistake thinking it's an AutoCAD rule. It's not. It's ESRI's.>>

As a general rule, I'd recommend exporting to shapefile only, Why? Because you can only export ONE class, not multiple. When you understand shapefile & database thoroughly and become expert, then go for SDF.

[Jake6954]

Hi ChicagoLooper,

 That was EXTREMELY helpful!  Thank you!

 I can’t say I’m completely on top of it yet, if for no other reason than the intricacies of how CAD software reads and/or creates, processes and manages drawing objects and all the other relevant data (i.e. object attributes and properties, geospatial info etc. etc.), is simply is not something I know very much about.  I mean, just look at all the sub-files that are a part of any given Shapefile.  I might know that a prj file contains the relevant geocoordinate reference system info (if it exists), or that the dbf file contains most of the object data that one ultimately may want to query into their C3D drawing, but "a" SHP File can have upwards of 6 other sub-files that I know nothing about (i.e files with extensions like idx, cpg, sbn, sbx, shx, shp.xm etc.).

 Based on what you said, I believe I now know where one of the major flaws in my thinking was.  I said that when I was importing other people’s SHP files, they contained multiple object types (or “feature classes” as I presume is the more correct way of describing them, based on your response??), but I now see that this is incorrect.  It simply has to be incorrect, because you emphatically pointed out that a SHP File can be comprised of only ONE feature class. 

 The mistake I believe I was making (and it seems so obvious now), is that most of the SHP files I was working with contained “Linework”  AND “Text”, (i.e. roads or contours and that kind of thing, along with road names and/or other labels); which, in my mind, meant that the SHP File must therefore contain at least TWO Object Types: Lines AND Text.  But that apparently has to be wrong.  I am now thinking that the “text’ wasn’t really stand-alone-text per se, it was really an attribute of the line work, or a label tied to the linework (not sure how to describe it) and therefore it would be contained in the dbf file associated with the SHP file, and not viewed by AutoCAD as a separate object type.  And I think this correlates with how I had to go about “capturing” that information, as you put, in order to bring it into my drawing (model space).  That is to say, I brought that “text” into my model space by querying what I believe was the data that was formerly in the dbf file, but was brought into the drawing file I created, when I executed the MAPIMPORT command at the beginning of the porcess. 

 How I brought that text into my drawing corresponds with the bit you said about:

 “Depending on the data you utilize when you add the shapefile to modelspace, your data can be either captured or created from scratch. You may capture, the AutoCAD layer the object resides on, the object's coordinates, objects z-value or elevation, the object's length, object's square foot area, the block attribute values (if exporting a block to shapefile), and much more. Captured data is typically harvested from the values in the Properties Palette. “

 You’re saying here that one captures the data they need/want by harvesting it from the “Properties Palette”, but a few days ago I would not have understood this. Only recently did I start to see that  when talking about the Properties of a given object that one has imported into the Model Space, from a SHP File, the Property Values that one sees in the Properties Palette for that object are a reflection of - or rather was obtained from - the dbf file data that was brought into the drawing during the execution of the MAPIMPORT command (and it should probably be noted that one chooses what data from the dbf file they want to bring into their drawing when executing the MAPIMPORT Command).  BUT that does NOT mean that the data, or “values” that one is seeing in the Properties Palette (which, among other things may define the attributes, or the style effects of the objects in model space.) has been applied to the relevant objects in the Model Space of your drawing yet.  The only way (that I know of…which isn’t saying much) to get that data into your Model Space, or in other words applied to the relevant objects in Model Space, is to Query that data into your drawing.  But, whether one realizes it or not, what they are effectively Querying is the data that was in the original dbf file associated with the original SHP File.  So, practically speaking “harvesting from the values in the Properties Palette” is synonymous with “Querying the dbf file that accompanies the SHP File”.

 I am not sure I’ve got that 100% right.  Please do correct me where I may be off track, though there may be many things I don’t have quite right because I know I still don’t have a full grasp of this yet.  For example, the issue of Elevations when working with SHP Files is a good illustration of how limited my understanding still is.  I know that when bringing in Contour Lines from a shape file, they will look exactly as they should in plan-view, without my having to do any data querying beyond the initial MAPIMPORT. But as you surly know, the problem is that those contour lines come into model space with no Elevations assigned to them. The elevations are there, in the dbf file, and were subsequently brought into the drawing with the MAPIMPORT Command (I elected to bring in All the associated data), hence that Elevation info can be seen in the Properties Palette.  And I know how to go about capturing that elevation data, but to say I fully ‘understand” that would be wrong.  To someone like you, I’m confident this elevation issue likely makes perfect sense, and there is assuredly a logical explanation for it, even if that explanation isn’t obvious.  But to someone with my limited knowledge, I’m left wondering, “If the contour polylines were brought into model space by way of the MAPIMPORT Command, with all the necessary XY coordinate data in tact , without the need to query any additional data, then why wouldn’t it also bring in the Z component of those polylines?  Why is the Elevation something different that must be queried separately?”  I’m not really seeking an answer to that specific question, but it does demonstrate my limited grasp of this topic, even if I am able to follow the steps necessary to make things work.   

I really appreciated you taking the time to write all that you did.  It was all very illuminating.

If you would like to point out the areas where I am still off-track, I'm all ears.   

[AllenJessup]

In getting advice from @ChicagoLooper you are getting advisee from one of the top GIS people on these boards.

One thing to remember is that GIS is not Engineering or Surveying. It's data gathering and manipulation. The commands you're working with are not Civil 3D commands they are Map 3D commands.

You've said you are creating the Shape files to eventually be brought into Civil 3D. I don't know what the thought process is on that but I'd view it as a poor workflow. You can bring GIS data into Civil 3D via Map. But it's no longer Civil 3D data.

If the data needs to be used in a GIS application. Fine. Create the Shape files they need. But why not give those who have Civil 3D a Civil 3D drawing or some LandXML files so they still have Civil 3D objects?

[ChicagoLooper · Accepted solution]

Hi @Jake6954 

There are two frequently used ways to ADD shapefile linework to modelspace, (1) adding the linework using MAPIMPORT and (2) adding the linework as a Feature Data Object (FDO) using the Data Connect Palette. The former literally 'converts' the ESRI entities into AutoCAD entities (you should Create Object Data during this MapImport procedure) while the latter adds the linework as an ESRI entity which means you'll be maintaining the shapefile format. 

When using the MapImport procedure you can, and should, 'Create Object Data' which will make the converted objects smart. Be sure to bring in ALL the data because it' s better to have ALL than only some. You don't necessarily have use all that data but you should have the opportunity to access all the data and potentially use it. 

Remember, the shapefile's linework and database (dbf) go together. On the other hand, the MapImported entities (converted objects) go with Object Data. Whether the shapefile format is maintained OR converted, the DATA is physically stored in each individual line (or point), they're not in Mtext. This stored data can be leveraged to run a query, group objects, isolate objects, highlight and color, hide/display objects, etc., etc., etc. This is why it's important to Create Object Data when using MapImport. If you forget or are unwilling to create OD, then you'll only be able to run queries on the shapefile itself, not on your imported linework.

Just to be clear, don't necessarily need to run a query to bring in a subset (or a group) of your lines. You may bring ALL lines into modelspace, then run your query on those lines which will allow you to display (or not display) your custom lines, meaning you can choose color, symbol, and line weight. You can might even make multiple customized styles turning styles on and off as needed. Your only limitation is your creativity and know-how.

OTOH, if you run a query and to bring in just a specific subset of the objects and data, then you'll be limited to querying only the objects and data you originally brought in. The objects and data you've left BEHIND won't exist in modelspace and you can't query objects & data that isn't available. Don't get wrong, querying to limit the linework you bring in is beneficial, definitely beneficial. Just remember, you also have the option to NOT to limit your data.    

[ChicagoLooper]

Hi @Jake6954 

The minimum for shapefile is

• shp
• dbf
• prj
• shx 

Each component plays a distinct role when adding the data to modelspace. All other extensions can be considered optional (some extensions 'might' be required). Depending on the program you use to OPEN the shapefile, the optional file(s) may be created (or recreated) by that other program if that other program needs it. 

[ChicagoLooper · Accepted solution]

Hi @Jake6954 

Yes, you're correct. Running MapImport on a topo contour shapefile will convert ESRI linework to AutoCAD linework. The problem, however, arises when you build a surface based on the imported contours--all contours are at 0' elevation. So if you create a surface with these imported contours, you'll end up with a surface that's flat, and not just flat, that surface will be like beachfront property, at sea level!

To elevate the contours to their proper elevation, and by proper I mean the elevation listed in the Imported Object Data, you'll need to run a special query known as a Query that uses the Alter Properties workflow. Alter Properties is AutoCAD's fancy-schmancy, socially acceptable way of saying, I'm not satisfied with the way Mapimport brought in my linework so I want to ALTER, or change, one or more of the PROPERTIES that's listed in the Properties Palette. And BTW, I want this change to happen to each individual line, all at once, and fast.  

But seriously, you want to change each individual contour's elevation from 0' to to the elevation that's stored in Object Data. You created OD when you performed MapImport, remember? Combining a Query with this Alter Properties enhancement will effectively raise (elevate) each topo line to where it needs to be. The contours are already at the correct northing/easting geospatial position, they just need to be elevated and not at the beach. Once they're elevated, you can now build your surface suing the contours as the surface definition.

<<Note: you can also build a surface directly from shapefile without using a query or Alter Properties. A detailed analysis that compares using a query vs. not using a query, will reveal the using query method will triangulate more accurately. It's just building a TIN without a query is (1) easy and (2) doesn't require much know-how, and due to these factors, it has become a common way of using shapefile data for surface creation. It doesn't mean using a query is a waste of time and not using a query is just-as-good or better, it just means the easy way is more popular.>>  

[Jake6954]

Hi AllenJessup,

Yeah, maybe I should have been more clear about the Map 3D / Civil 3D thing, but I think the issue there was that when someone says Civil 3D, I just assume that any Map 3D capabilities are implied because it’s included in Civil 3D.  But when someone talks about Map 3D, it doesn’t necessarily mean they also have Civil 3D, so I suppose it seemed more efficient to just say C3D.

But your point about how the commands I’m using are Map 3D commands, not C3D commands, is worth noting, but more so I think because that fact can pose a rather significant issue in certain situations that may arise down the road, for reasons that I would say might not be at all “obvious” to the average C3D user.  For example, I've learned that if one is creating a C3D drawing from a SHP File that involves something like roads and road labels that are aligned with those roads, and the plan is to be able to Xref the resulting C3D drawing into some other AutoCAD drawing, there are some quirky aspects of Map 3D that might pose a problem.  Specifically, whether those road labelsactually show up, or show up correctly, in that other AutoCAD drawing will depend on how one went about getting those labels into the C3D drawing that is being Xref’d.  The issue there being that Map 3D Layers – if present - simply will not show up if the drawing is Xref’d into another AutoCAD drawing (though I have no idea why, I just know that’s the case).

As for the work flow of going from a C3D DWG to a SHP, then back into a C3D DWG, the reasons for that have absolutely nothing to do with me, it’s just what was asked for.  But judging by the people who asked, I’m sure they have their reasons.

[AllenJessup]

Hello @Jake6954 

Yes. Been through that myself. Once I have the drawing imported and styled as I want. I often use "Save as AutoCAD drawing" from the Display Manager tab on the Task Pane. That gets everything down to plain AutoCAD entities.

I also have found there can be issues in the way the Shape File was created. I recently got a shapefile from a consultant that contained nearly 1000 polygon tiles with a specific label  for each  tile. When I attached it through FDO the text was all over the place. I asked our GIS Department if they had anything better. They had the same thing. However my friend there broke out the Labels as a separate field and it worked with no issues.

At times I've used QGIS to export a GDB as a DXF. That often works well.

However for your export issues. The Master Class posted by ChicagoLooper is most likely the best advice you'll get. I'm bookmarking this thread for later reference.

---

@Jake6954 wrote:

As for the work flow of going from a C3D DWG to a SHP, then back into a C3D DWG, the reasons for that have absolutely nothing to do with me, it’s just what was asked for.  But judging by the people who asked, I’m sure they have their reasons.

---

Yes. That's often the case.

[Joe-Bouza]

Exporting cad data from civil3d so it can be reimported back into civil3.

Am I reading that right? why?

[Jake6954]

Ha!!  it's a hell of a problem.....when you encounter it for the first time.....isn’t' it!!  There ain't noth'n obvious about that problem in my opinion. 🙂   Either you know what's going on there, or you don't, and if you don't, and no one around you knows, you're gonna be spending some time working that one out!  LOL!!

[Jake6954]

LOLOL!!! I'm afraid so. 🙂

....and don't bother asking me why, becasue I don't know the answer to that.  My only guess was that it "might" have something to do with some data collector software, and the "back into C3D" bit was not something they were necessarily going to actually do with it, but by specifying that perhapse it ensures (or they think it ensures) that what's exported will not have elements that are incompatible with what they are specifically trying to do??  But I don't really have any idea...

[Jake6954]

Hi ChicagoLooper,

“There are two frequently used ways to ADD shapefile linework to modelspace, (1) adding the linework using MAPIMPORT and (2) adding the linework as a Feature Data Object (FDO) using the Data Connect Palette. The former literally 'converts' the ESRI entities into AutoCAD entities (you should Create Object Data during this MapImport procedure) while the latter adds the linework as an ESRI entity which means you'll be maintaining the shapefile format.”

Assuming I am not mistaken about what you are referring to, I am “somewhat” familiar with using the Data Connect feature of Map 3D, but my experience with it is very limited.  And the situation in which I used some of the Data Connect features (I’m referring to the double-hockey-puck icon at the top of the Map 3D TASK PANE), was after the initial shape file was imported using the MAPIMPORT process. 

“To elevate the contours to their proper elevation, and by proper I mean the elevation listed in the Imported Object Data, you'll need to run a special query known as a Query that uses the Alter Properties workflow. Alter Properties is AutoCAD's fancy-schmancy, socially acceptable way of saying, I'm not satisfied with the way Mapimport brought in my linework so I want to ALTER, or change, one or more of the PROPERTIES that's listed in the Properties Palette. And BTW, I want this change to happen to each individual line, all at once, and fast.”

LOLOL!!  I love it.  Your personification of AutoCAD was beautiful!  I don’t think you could have described that little oddity better if you had month of Sundays to do so.

“<<Note: you can also build a surface directly from shapefile without using a query or Alter Properties. A detailed analysis that compares using a query vs. not using a query, will reveal the using query method will triangulate more accurately. It's just building a TIN without a query is (1) easy and (2) doesn't require much know-how, and due to these factors, it has become a common way of using shapefile data for surface creation. It doesn't mean using a query is a waste of time and not using a query is just-as-good or better, it just means the easy way is more popular.>>”,

Though Querying is how I go about it, I did NOT know that if you create your surface, in that scenario, without a Query, the TIN triangulation will be less accurate.  That’s so strange.  Very good to know!!  Thank you for that little tid-bit.

[Joe-Bouza]

That's what I am getting confused with. It sounds like you are taking base map AutoCAD lines and circles exporting to shp to bring back to create a base map? what's the intent?

And if Mapwspace is being used, that has to be saved as acad drawing to use effectively in production

[Jake6954]

Hi Joe-Bouza,

You may have missed my earlier response to you.  The answer is, I simply don't know what the intent is.

It was a request that had nothing to do with me.

[Joe-Bouza]

Thank  @Jake6954 , I caught it late