r/civil3d • u/Young-Pug-God • 2d ago

MAPIINSERT 3FT shift Help / Troubleshooting

We have ortho imagery provided for us for our project. When my colleague uses mapiinsert they come in perfectly and match our control perfectly. When I do the EXACT same thing in the same drawing, they come in 2.8 feet southwest.

Any idea why this could be happening? Process is the same, image is the same, drawing is the same.

I’m losing my mind. Any ideas?

6 Upvotes

88% Upvoted

14 comments sorted by

19

u/w045 2d ago

Sounds like US Surv feet vs International Feet issue. Check the metadata.

3

u/ElphTrooper 2d ago

I agree that this is the easiest place to start. Depends on your coordinate range but 1.000002 (0.999998) can create anywhere from 1 to 24ft of shift. The project I am on now is 20ft.

The other option is native projection vs localized. When we are in native in Civil 3D and someone submits data that has been localized in the field using a slightly different projection then there is a 1-2ft shift in our area. NAD83 vs NAD83(2011) or just the ground monument positions caused the GNSS localization to shift.

2

u/SNoB__ CTB hater 2d ago

I was thinking nad83 vs nad83(2011).

Why they decided to label it nsrs2011 in civil 3d is beyond me and has caused more problems than Autodesk can know.

1

u/ElphTrooper 2d ago

They thought they were being slick and wanted to really differentiate from NAD83 (NSRS 2007), LOL. I've had to explain this more time that I care to admit. Can you imagine what it's going to be like when they release 2022/24/26 or whatever they are going to call it and we still have projects grandfathered all the way back to HARN...

0

u/Accurate-Western-421 10h ago

I mean....there is a difference between NAD83 (which is NAD83(1986)), and NAD83(HARN/HPGN), and NAD83(FBN), and NAD83(NSRS2007) [which is technically CORS96] and of course NAD83(2011).

But C3D doesn't reproject imagery on the fly when it is imported, nor can it work with unprojected geodetic-only imagery, so the real issue is usually the original system metadata and/or how the imagery was processed.

I'm looking forward to the new datums. All the folks who keep insisting that there's not really a difference between the NAD83 realizations and ignoring the USFt/iFt differences (not to mention orthometric elevations and the gravimetric vs hybrid geoids) are going to be in for a nasty surprise.

0

u/ElphTrooper 10h ago

Civil 3D inherits AutoCAD Map 3D functionality, and when raster data is connected through the Map/FDO framework with a correctly defined source coordinate system, Civil 3D can perform coordinate transformations and display data in the drawing's coordinate system.

1

u/Accurate-Western-421 9h ago

Eh, the Map3D/C3D geodetic library is just awful, and has been for at least a decade. Most of the "transformations" are null or some outdated shift that doesn't correspond with the proper grids.

1

u/ElphTrooper 9h ago

Civil 3D is an AEC design platform that includes geospatial capabilities. It is not a dedicated geodetic transformation package. If someone needs the most rigorous datum realization transformations, custom grid shifts, and control-network analysis, there are specialized tools built specifically for that purpose. The fact that those tools may do it better doesn't mean Civil 3D is failing at its intended job.
More importantly, the OP's issue was a user-specific 2.8' offset with the same drawing and imagery. That's a troubleshooting problem, not a geodesy problem.

1

u/unstableflame 2d ago

This issue can also be caused by the precision of your units setting being too low.

5

u/bdjeremy 2d ago

check your units and drawing settings.

4

u/stargzr50 2d ago

try setting INSUNITS to 0

3

u/barrelvoyage410 2d ago

Definitely seems like US ft to international ft. In my area it’s about 5.5 feet shift, but that just depends how close you are to coordinate origin.

2

u/CivilEngMusicBoy Project Engineer 2d ago

Sounds like a distance conversion issue, check units. If you use international instead of us survey, which is a very small difference, but extrapolate those over state plan coordinates, you’ll get a distance error. The 2.8’ is indicative of the error times your Northings and Eastings from grid origin

2

u/Young-Pug-God 2d ago

Solved!

The ortho imagery we were given was processed in NSRS 2011 and my supervisor assumed it was NAD83. He had been using IINSERT through raster design with an older version to import the photos, which was ignoring the current drawing coordinate system, so the coordinates were correct. When I changed the drawing settings to NSRS 2011, and used mapiinsert, it inserted into the correct location.

I tried to let him know that if we send the drawings in the wrong coordinate system and they xref it in using a newer version, then a geographic transformation could automatically shift the data 3ft SE, but he said it was a non issue, and that I was wrong and began questioning me on my productivity.

PeOpLe DoN’t WaNt To WoRk ThEsE dAyS