Data Connector not using elevation data

[maxime.carrierC5VFZ]

Hi all, 

Data Connector doesn't seem to read directly the elevation data (Z value) in connected 3D objects.

Wasn't sure if this an error for the debug team, a setting that I've missed on my end or an idea that I need to submit to the developers team.

Context:

I'm currently mixing Map 3D database connection capabilities with Dynamo for Civil 3D to rebuild underground pipe networks. Dynamo can work through Data Connector to read the geometry and tabular data of GIS objects and create Civil 3D objects through attribute/value mapping. 

Though I'm using a SQLITE, but I've tested SHP and SDF files and have the same issue: in the read geometry, only X and Y coordinates passes through the Data Connector, no Z values. In every other GIS softwares I've used this data with, imbedded Z values are read and applied, but not through Map 3D's Data Connector.

You can manually create and push 3D objects through the data connector, but whatever Z values it already has is not available, making it hard to properly place underground infrastructures (like pipes and manholes).

Workaround:

Via using the MAPIMPORT command to import my SQLITE file, the imbedded elevation data is applied to the created AutoCAD objects.

Dynamo works as easily with the AutoCAD objects as with the Map Feature objects (read through the Data Connector), except that those AutoCAD objects need to be discarded (being temporarily useful) and are completely disconnected to the actual database once they are imported. Plus, a user you can easily miss a setting while MAPIMPORTing their data, making this workaround a bit less efficient than what I would normally expect through the Data Connector.

You can probably see why I would prefer to work with the Data Connector, especially with his capacities to connect to remote databases (compared to MAPIMPORT that can only connect to locally available GIS files).

Thanks in advance!

[Pointdump]

Hi Maxime,
You might also want to post this in the >>>Dynamo for Civil 3D Forum<<<.
Dave

[maxime.carrierC5VFZ]

Thanks Dave for the cue!

[ChicagoLooper · Accepted solution]

@maxime.carrierC5VFZ 
Is your shapefile data storing the elevation data as an attribute because if it is, then that’s just a number in a field and doesn’t make a ‘physical’ connection to the geometric entities.  

What you want is the shapefile to have its elevation within the geometry so the vectors are actually at (or raised to) their proper elevation. 

If you use Civil3D day-in-day-out then you know you can create a surface using GIS data contained in a topo contour shapefile. In this scenario, Civil will read a field in the dbf to ascertain elevation then triangulate. This surface is created by attribute values not by vectors.  

In contrast to creating a tinn surface in C3D using GIS data, you can also create a surface using topo polylines generated from shapefile you ‘process’ using the AutoCAD Map3D toolset. IMHO this method is superior when compared to using C3D attribute values. In this scenario the polylines are raised to their respective elevations from their default z-value of 0. This procedure, as you already know, uses MAPIMPORT combined with an alter properties QUERY. (BTW if you don’t use a query during MapImport then your imported plines will remain at z=0. The alter properties query is the ‘driver’ that raises them.)

In your ArcGis workflow you can use Feature to 3D By Attribute function in the 3D Analyst Toolkit so each feature's elevation will be derived from the value obtained in the elevation field. This will eliminate your reliance on an attributed z-value because you use the geometry itself to provide the elevation.