CSRS Datum Shift and Bing Live Maps

[Pointdump]

Thinking about the CSRS Datum Shift in >>>This Thread<<<,in a drawing assigned UTM83-13 I exported Control Point #775019(Nipawin, Saskatchewan) as Decimal Lats and Longs(to the maximum 17 decimal places). In QGIS I saved that point in 2 Projections:

EPSG:2957
NAD83(CSRS) / UTM zone 13N

EPSG:26913
NAD83 / UTM zone 13N

Open 2 empty Metric Drawings, assigning one of the above Coordinate Systems to each drawing. Drag-n-Drop both of the attached shapefiles into each drawing. In the CSRS drawing you get two points 31 Meters apart. In the NAD83 drawing both points land in the same spot.
What to make of this? I dunno.

[Koesti]

Hi @Pointdump ,

I have no answer so far but it makes it easier to test with the upcoming version and send it to our team for further information 🙂 Keep you updated - but probably take some time.

Regards

[ChicagoLooper]

Regarding the red and yellow points in the image shown below:

Red Circle=correct location. Yellow circle=Incorrect location

Yes, questions must be answered to narrow down the reasons for this shift.

• Why is the yellow point not accurately interpreted by by Map 3D when using CSRS.UTM-13N?
• Is the NTv2 transformation that was applied to CSRS responsible for this inaccuracy?
• If the NTv2 is removed from MAPCSLIBRARY will the yellow point be geospatially accurate when using CSRS?
• Why does UTM83 give consistent results regardless if the shapefiles's projection is CSRS or UTM83?

[Pointdump]

@ChicagoLooper,
"Is the NTv2 transformation that was applied to CSRS responsible for this inaccuracy?"
Dunno. What would be nice is 4 or 5 rock-solid pieces of data to see what lines up and what doesn't. Most sources of "official" data make you beg for Metadata.
"If the NTv2 is removed from MAPCSLIBRARY will the yellow point be geospatially accurate when using CSRS?"
I expect all that will happen is the error: "Cannot save projection code to the drawing"
"Why does UTM83 give consistent results regardless if the shapefiles's projection is CSRS or UTM83?"
Certainly gives me more confidence in that projection.

Dave

[Pointdump]

Step 1. Create PNEZD Point File Formats with Coordinate Zone Transforms in LL84, UTM83-13, and CSRS.UTM83-13N.
Step 2. Create COGO Point with LL Coords:
1,53.30717720625818856,-104.00252803403915891,370.1993,775019
Step 3. Use Transfer Points to Transform and Export that point to both UTM83-13 and CSRS.UTM83-13N.
1,5906906.2679997440,566463.6890000041,370.1993,775019
1,5906909.9536812073,566432.7566291813,370.1993,775019
Step 4. Use distance formula in Excel to find Shift:
31.15117674 Meters

Sorry for the needlessly high precision.

[ChicagoLooper]

Put those calcs aside for a moment and try this. Open two separate metric template. Drawing A and drawing B.

1. For A, assign UTM83-13.
2. For B, assign CSRS.UTM-13N 
3. While in A, go to Geolocation tab=>Tools panel=>Mark postion dropdown and choose Lat-Long icon. Input Lat=53.30717720625818856 and Long=-104.00252803403915891. Turn on Bing imagery.
4. Go to drawing B, go to Geolocation tab=>Tools panel=>Mark postion dropdown and choose Lat-Long icon. Input the same Lat/Longs as  step 3 above. Turn on Bing imagery.

The resulting point of step 3 and  and the resulting point of step 4 will look the same when referenced against Bing background imagery. Both points will have the same Lat/Long. The only difference will be the x,y coordinates in A and the x,y coordinates in B. This difference will be understandable because each drawing is referenced against a different coordinate system.

Conclusion, when inputting points use Lat/Long degrees, not x,y in meters. If you cannot compel yourself to use Lat/Long degrees and use x,y meters anyway, then you must know whether the x,y meters are referenced against CSRS.UTM or UTM83. Failure to recognize the source of your x,y coordinates can result in inaccurate placement of your points.

[Pointdump]

@ChicagoLooper,
"...Geolocation tab=>Tools panel=>Mark postion dropdown..."
The GeoLocation Tools are for Vanilla AutoCAD. They are wonky and unreliable, at best, with Map 3D and Civil 3D. I avoid 'em like the Wu Flu.
"...when inputting points use Lat/Long degrees, not x,y in meters."
My data, the only verifiable data I had, was in Meters. And that was the whole point. To find out WHAT is shifting, Bing or AutoCAD's transformation. I think Jay @gingerbreadman is right, that there shouldn't be such a large shift between NAD 83 and CSRS. For whatever reason, Map is botching the transformation.
Dave

[ChicagoLooper]

Despite accessing the GEOMARKLATLONG command from the Geolocation Tab on the Ribbon, the this command is not wonky. It's accurate and reliable. Make MAPCSASSIGN = CSRS.UTM-13N. Next, invoke the GEOMARKLATLONG command from the ribbon, go to Geolocation tab=>Tools panel=>Mark Position Icon shown below=>select LAT-LONG from the dropdown options. Enter the Lat/Long coordinates shown under Step #2 in post 5 of this thread. Image-1.

Image-1.

The verify accuracy enter UNITS on command line=>then set the Precision to the maximum 8-decimals. Image-2.

Then use MAPTRACKS. (Go to Analyze tab=>geo Tools=>MapTracks icon). Then confirm the position of your Geomarker. Image-3.

Image-3.

[gingerbreadman]

Thanks, Dave @Anonymous for continuing with this and thanks to @ChicagoLooper for providing the checks.  Just thought I'd share that I tried performing a coordinate transformation from MTM NAD83 to MTM NAD83 CSRS in OpenRoads (as I have access to it on my workstation) and there was zero shift (which also seems incorrect) and I stumbled upon the following forum: https://communities.bentley.com/products/microstation/f/microstation-forum/176867/has-anyone-created-a-functioning-useroverridegeodetictransform-asc-file-for-map-projections-in-alberta-i-need-to-reproject-data-between-epsg-3780--nad83-csrs-alberta-3tm-ref-merid-114-w-and-epsg-3776---nad83-alberta-3tm-ref-m .  Looks like Bentley has been having their own problems with CSRS coordinate systems also... 

[Pointdump]

Jay,
I found the problem. Natural Resources Canada has an >>>NTv2 Tool<<<. I used the Tool to Transform 53.30717720625818856,-104.00252803403915891 from:

NAD27 to CSRS(using Saskatchewan SK27-98 Binary Grid Shift file)
NAD83 to CSRS(using Saskatchewan SK83-98 Binary Grid Shift file)

Results:
NAD27 to CSRS Shift = 31.65775185 Meters
NAD83 to CSRS Shift = 0.560315982 Meters

I think creating Custom Geodetic Transformations from >>>Province GSB Files<<< will solve this, but both of my attempts have failed.

Dave

[Pointdump]

From >>>This NRCan site<<< you can download Grid Shift Files for each Province. A further complication is that there are at least 3 Canadian Datums: NAD83(CSRS) epoch 1997, NAD83(CSRS) epoch 2002, and NAD83(CSRS) epoch 2010.
Dave

[ChicagoLooper]

Hi @Pointdump 

It worked for me! Read on..... 

Regarding your image with the Red and Yellow dots in post #1 of this thread, you are assigning CSRS.UTM-13N to modelspace and the red & yellow dots, separate shapefiles using two different prj's, are 31 meters apart. Correct? 

QUESTION:

So is there a way to place the dots directly on top of one another when modelspace is using CSRS.UTM-13N? 

ANSWER:

Yes, there is. This is how I got  it to work.

1. Delete the NTv2_0.GSB from the transformation known as NAD83_TO_CSRS. Image-1.
2. Assign CSRS.UTM-13N to a brand new metric template. Connect to the shapefiles. Image-2.

Image-1.

Image-2.

In the image above, the shapefiles have two different prj's, CSRS.UTM-13N and UTM83-13, yet they are geospatially consistent. (Compare to your image in Post #1 up above.)

The NTv2_0.GSB does NOT need to be applied to the transformation known as NAD83_to_CSRS.  

[Pointdump]

@ChicagoLooper,
"The NTv2_0.GSB does NOT need to be applied..."
By removing the GSB file it becomes effectively a null transformation. The reason why Map is not handling this correctly is because that GSB file is taking the transformation from NAD27 to NAD83(CSRS). Not Autodesk's fault. What is needed is NAD83 to NAD83(CSRS), but there doesn't seem to be a nation-wide GSB file for that. Saskatchewan Province has 3 published Grid Shift files: sk27-83, sk27-98, and sk83-98. >>>Link<<< I haven't been able to figure out how to use these. I've tried with and without creating a "Path". I've made several attempts. I'm missing some key piece of knowledge.

Map 3D Help is woefully deficient on explicit steps in this regard. Kinda understandable, though. After all, Autodesk is not responsible for the world's Datums.
Dave

[ChicagoLooper]

Here's a thought (or thoughts). The yellow circle in Post #1 is a shapefile created in QGIS and this shapefile is given a projection of CSRS.UTM-13N by QGIS. Since every shapefile needs a prj, does giving it a CSRS.UTM projection shift, the circle 31 meters so it lands in the right spot? Is there an NTv2 in QGIS that's responsible for giving the yellow circle a 'corrective' shift?

If it has already gone through the NTv2 transformation in QGIS, does Map3D subject it to, or not subject it to, another NTv2  transformation when it plops down in modelspace? Is there a 'double-transformation' being applied when using CSRS.UTM-13N in both QGIS and M3D?

Would removing the NTv2 from Map3D's NAD83_to_CSRS solve this? What are your thoughts?

[Pointdump]

Hi @ChicagoLooper,
"Is there a 'double-transformation' being applied when using CSRS.UTM-13N in both QGIS and M3D?"
Nope, they're both working perfectly fine. The problem is the Canadian NTv2 file goes like this: NAD27 >> NAD83 >> CSRS, in effect 2 transformations. What is needed is just NAD83 >> CSRS. Canada has not published a nationwide NAD83_to_CSRS grid shift file.
I can't seem to make a Geodetic Transformation work in Map 3D. I always get the old "Can't save Projection Code..." But you gave me a good idea. I'm going to swap out the National GSB with a Province-specific NAD83_to_CSRS GSB. Tomorrow.
Dave

[Pointdump]

@ChicagoLooper,
I swapped out the National GSB with a Saskatchewan-specific "sk83-98.gsb" file. Didn't work.
Now assigning any Projection that uses the CSRS Geodetic Transformation gets the error "Cannot save projection code to the drawing." It might just be that the "sk83-98.gsb" file is not in NTv2 format:
"AutoCAD Map 3D toolset does not check whether your grid file is in the selected format. You must en...
I don't know how to find that out.

Dave

[Pointdump]

I'm swinging in the wind here.
"Now assigning any Projection that uses the CSRS Geodetic Transformation gets the error "Cannot save projection code to the drawing."
I lied. Just my Custom Extended CSRS.UTM13N failed. The OOTB CSRS.UTM-13N produced an interesting result. Now both Points are 31+ Meters away from where they should be, but the distance between them is the expected half-a-Meter. Don't know what to make of this.

[Pointdump]

OK, so Assigning CSRS.UTM-13N, and with the Saskathewan "sk83-98.gsb" file substituting the National NTv2, I dropped in both Point Shapefiles and created a COGO Point with published Lats and Longs of 775019:
Lat:53-18-25.83794
Long:-104-00-09.10094
Seems to match the QGIS-created CSRS Point, and the two points are half-a-meter apart and in the right spot. Getting closer.

[Pointdump · Accepted solution]

I was reading >>>Here<<< and stumbled upon the Solution:

"Grid Data File Interpolation:
The transformation will be done following the order visible in Grid Data File Interpolation.
If objects from data sources are not in the area of first GSB file boundary the second GSB file will be used and so on.
If there is no area inside GSB file boundaries, the transformation will be done using the setting in fallback transformation, if enabled."

[ChicagoLooper]

Thanks for the shapefiles. I was able to do this without any shift using a geomarker as a reference point.

The blue geomarker, cyan shapefile and red shapefile are all consistent.