Community
Civil 3D Forum
Welcome to Autodesk’s Civil 3D Forums. Share your knowledge, ask questions, and explore popular AutoCAD Civil 3D topics.
cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

Coordinate Shift on DEM import vs mapimport

24 REPLIES 24
Reply
Message 1 of 25
eladkcem
5325 Views, 24 Replies

Coordinate Shift on DEM import vs mapimport

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

24 REPLIES 24
Message 2 of 25
BrianHailey
in reply to: eladkcem

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.

Brian J. Hailey, P.E.



GEI Consultants
My Civil 3D Blog

Message 3 of 25
eladkcem
in reply to: BrianHailey

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...

Message 4 of 25
BrianHailey
in reply to: eladkcem

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.

Brian J. Hailey, P.E.



GEI Consultants
My Civil 3D Blog

Message 5 of 25
BrianHailey
in reply to: eladkcem

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.

Brian J. Hailey, P.E.



GEI Consultants
My Civil 3D Blog

Message 6 of 25
eladkcem
in reply to: BrianHailey

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.

 

 

Message 7 of 25
fcernst
in reply to: eladkcem

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:

 

  1. Create a new blank drawing with the coordinate system set to CA Zone 2 Metric.
  2. Create a new TIN surface in the blank drawing, and add the UTM based DEM data defintion (make sure your specifying the correct CS's for each)
  3. XML export the surface
  4. XML import the surface into your drawing with the CA Zone 2 US Foot (Imperial) 


Fred Ernst, PE
C3D 2024
Ernst Engineering
www.ernstengineering.com
Message 8 of 25
clinton_merrell
in reply to: eladkcem

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. 

Message 9 of 25

What is DEM in tiff format?

Chicagolooper
Message 10 of 25


@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.

 

Message 11 of 25
cwitzel
in reply to: clinton_merrell

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,

Thanks,
Conan Witzel
Civil 3d 2021 SP1.1
Smoking BOXX Apex 2 Workstation
Message 12 of 25
IvanGrebenyuk
in reply to: eladkcem

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)

Message 13 of 25
Pointdump
in reply to: cwitzel

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

EESignature

64GB DDR4 2400MHz ECC SoDIMM / 1TB SSD
NVIDIA Quadro P5000 16GB
Windows 10 Pro 64 / Civil 3D 2024
Message 14 of 25
mgutenkauf
in reply to: Pointdump

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?"

 

Message 15 of 25
cwitzel
in reply to: mgutenkauf

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. 

Thanks,
Conan Witzel
Civil 3d 2021 SP1.1
Smoking BOXX Apex 2 Workstation
Message 16 of 25
wskesecker
in reply to: cwitzel

We are still encountering this issue. Have you gotten any more information from  Autodesk?

Message 17 of 25

No, absolute silence.

Issue is still present in The 2020 release. We just can't use geotiffs
anymore...

Message 18 of 25
ChicagoLooper
in reply to: wskesecker

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. 

Chicagolooper
Message 19 of 25
cwitzel
in reply to: ChicagoLooper

The work flow described is:

Insert a DEM using MAP

Insert a DEM using Surface

 

They are not the same.

Thanks,
Conan Witzel
Civil 3d 2021 SP1.1
Smoking BOXX Apex 2 Workstation
Message 20 of 25
ChicagoLooper
in reply to: cwitzel

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.

Chicagolooper

Can't find what you're looking for? Ask the community or share your knowledge.

Post to forums  

Rail Community


Autodesk Design & Make Report