Please read and help if you can, thanks. -Dale
Briefly:
Mapimport command maintains integrity of x,y coordinates. Adding dem information to a civil3d TIN surface does NOT.
Detailed screen shot(s) attached.
Detailed:
I am trying to create a tin surface in autoCAD from a raster dataset in GIS. Originally, my raster dataset was in UTM's (Zone 10N), and my CAD drawings were in CA State Plane (zone 2, US feet). Both NAD83. But I have, to date, been unable to get AutoCAD to correctly convert between these two coordinate systems. I thought, hmm.. let's just convert to State Plane in GIS and then add to the surface definition in AutoCAD. I had hoped this approach would 'go easy' on autoCAD as it would not need to do any conversions. Turns out, that does not appear to work either. In fact, it is even further 'off' than before... I hope the attached PDF illustrates the situation clearly. AutoCAD's mapImport command works great. The surface boundary can be imported and appears to have the correct coordinates. The surface, with the dem added to the definition, however, does not. It is shifted down and to the left.
I'll post mxds, shape files, and the cad dwg if it would help somebody help me troubleshoot this issue. As much as I am frustrated by GIS, this is not a gis problem...
Thanks again,
-dale
When adding the DEM file to your surface, are you assigning a coordinate system to it?
If you post up the files, I'll see if I can duplicate it on my end.
Hiya Brian. Thank you sooo much for taking a look at this. I'm nearly convinced it is a serious, but subtle issue that will require a painful work-around... but perhaps I'm just overlooking something? -dale
I do specify a coordinate system when adding the dem to the surface definition. See additional screenshot attached.
Zip attachment has an Arcgis mxd file that has two rasters and two boundary shapefiles. (You may have to repair data sources based on where you put the files on your computer) One is in UTM and the other (with suffix _P) is 'projected' into state plane. I can't get either to end up in exactly the right location in civil3d. If I use CAD to do the coordinate conversion, the surface is close to the correct location, but slightly shifted, rotated, and slighly scaled. If I have GIS do the coordinate conversion, where then CAD is in state plane and receiving a state plane dem, I get the translational issue described on this post. <Edit: Note that rasters have elevation values in feet. As I've posted before, CAD will blindy convert those feet (as if they were meters) to feet if the x/y CS is in meters(UTM's). In this post I'm only interested in the spatial problem... elevations I can fix...)
Also attached is a dwg file that includes the surfaces I was using to test the coordinate locations. I've tried to clean out the drawing and provide some helpful explanatory labels.
I've tried different types of dems now as well. In gis I can save the surface grid raster to an ascii text file. CAD puts that in the same wrong location as the .adf raster... If I convert the raster to points (shape file points) then CAD puts them in correctly. That's my workaround so far... but it is very problematic for large data sets...
I've been getting some weird results with DEM files lately. When I bring in your DEM file using FDO (Map Dataconnect) and then bring that very same DEM file into a surface, they come in very different locations. I'll do a bit more testing and see if I can find anything out.
Alright, so here is what I've discovered.
The DEM "master_clip" is in the coordinate system HARN/10.UTM-10. The DEM "master_clip_P" is in the coordinate system CA83-IIF.
When I bring those into a surface as DEM data, they do not come in at the same location (as you've seen). When I bring them in using Map 3D (FDO connection) they line up. When I bring them into Autodesk Infrastructure Modeler (AIM), they line up. In fact, if I export them out of AIM and then into C3D, they line up.
I definitely think you've found an issue with that part of the software. If you are on subscription, I would recommend submitting a support request with Autodesk and reference this thread in it.
If you have access to AIM, you can simply import into AIM and then export a .imx file and then import that into C3D.
Thank you for confirming the error Brian.
I'm unfortunately not on a subscription, and I do not have access to AIM.
I worry that many, many folks have used that import 'feature' without noticing the error in the coordinate system... Who HASN"T worked on a project where something is just inexplicably 3 feet off... Given that the export to DEM is also flawed I'm suprised this hasn't become a major issue as it would seem to severely limit any project involving surface data that needs to be moved back and forth between a GIS and a CAD environment... Did Autodesk fix this in any later versions 2012 or 2013? (Or is AIM, *sigh*, the fix?) To me this would warrant either a statement of 'yup, it doesn't work. sorry' or a an all-out autodesk issued bug fix...
In any event, I've got a pretty clever, if slightly tedious, workaround figured now. I have a very large site (32 million + points), but is is mostly flat, with ditches criss-crossing. I need all the points near the ditches, but of course the large flat areas can be easily captured with only a handful of points. So, I use the raster calculator (Spatial Analyst) to create rasters representing the slope and the std dev of the slope. With some fine-tuning I can create a raster with only the points necessary. Converting the raster to points (as a shape file) I can then export it to a csv file... (yup... I'm using csv files... *sigh*). But, I can add those directly to the surface definition in autocad and low and behold the coordinates are correctly preserved.
Thanks again Brian for taking the time to confirm this is indeed an issue. (and for providing a solution for those with AIM). PS - I took your civ3D course in Durango in 2007... I knew your name was familiar... searched my email and yup! sure enough. :O) Thanks for all the info over the years.
Originally, my raster dataset was in UTM's (Zone 10N), and my CAD drawings were in CA State Plane (zone 2, US feet).
See if this helps at all converting your metric surface to imperial:
Has anyone figured out how to fix this behavior?
I am seeing similar results. While I conenct via FDO, the DEM comes in the right location. When I add the DEM file to a TIN surface, a horizontal shift of about 20 feet occurs (in the y direction in my case). Interestingly, if I add an ESRI Grid (.adf) file to the surface, the DEM comes in at almost the right location. It's only when I add a DEM file in TIFF format, that I see the shift occur.
I'm using Civil 3D 2018 and still have this problem occuring.
@ChicagoLooper wrote:What is DEM in tiff format?
A DEM in TIFF format is a DEM stored in a raster file with a .tif file extension.
In my scenario, both the .tif and .adf files are the same and are nearly identical when viewed in ArcMAP, but when the .tif file is added to a surface in Civil 3D, the resulting surface is shifted about 20 ft south of the result when the same DEM (in .adf format) is add to the surface.
Also, if I generate a shape file of contours using the .tif file using ArcMap, then import the shapefile into my civil 3D drawing, the civil 3d surface resulting from the same .tif file is 20 feet south of the imported shapefile contours.
Having the same issue, with about the same shift. Using map, everything is great, using Civil 3d DEM everything is just off.
Do you have a resolution?
Has this been reported to AutoDESK?
Thanks,
I could be off the subject here but my solution to this kind of problems have always been solved in ArcGIS (looks like you are using it too). I do all my surface projections and clipping there and than either create surface from breaklines (shp of contours) or do Surface from GIS (using contours shp).
ArcGIS handle surfaces (especially large ones a lot better than CAD)
Conan,
I'm guessing the problem is how C3D places the DEM, i.e., center of grid square or upper left corner. Of course the problem is greater with larger grids.
Dave
Dave Stoll
Las Vegas, Nevada
I've seen this problem for years now, always assuming it was something wrong in C3D, which it turns out it truly is.
This thread seems to spell it out well: https://forums.autodesk.com/t5/civil-3d-forum/civil-3d-causes-horizontal-shift-in-dem-geotif-surface...
Has this been submitted to AutoDesk? Or is it another case of, "Autodesk is aware of the problem, but won't fix it ever?"
I did report it to Autodesk and have a defect #, (Somewhere in an email)
I should have posted back, as I did find a work around using Recap and the raw Lidar. Didn't use to work as it would only handle unfiltered. They have added the ability at some point to make a surface with Surface points.
Far, far from ideal, but at least these terabytes aren't completely useless.
We are still encountering this issue. Have you gotten any more information from Autodesk?
How much is the shift? A lot? A little? Distance?
Was the DEM downloaded? If yes, from where? Url?
If not, then who created it? And how was it created? What program?
I've seen and heard of DEM shifts attributed to DEM error and AutoCad error, and then to find out it was actually due to user error, even though user swears it's not.
The work flow described is:
Insert a DEM using MAP
Insert a DEM using Surface
They are not the same.
Exactly! Different indeed! Using one over the other may, or may not, instigate claims of inaccuracy.
So which one is right? Or are both inaccurate? More importantly, what's the solution? Does a user who submits a ticket and posts in a forum that the ticket has been elevated a viable solution? Well.....maybe not a solution, but is it fair? Is it productive in providing a solution for the OP?
If you really need a surface, are you open to other sources of elevation data? Or are DEMs the only source you'll consider? If you can create a geospatially accurate surface, does it really matter?
DEMs are convenient to download and provide an easy way to create a surface. Why not use polylines taken from contour data or download LiDAR? Convenience should not be the determining factoring when defining a surface.