NAD83 CSRS v7 (epoch 2010) and ArcMap Versions

868
2
Jump to solution
09-18-2018 01:21 PM
Labels (1)
BryanMcIntosh
New Contributor III

Some previous posts have starting discussing LiDAR data in Ontario, Canada using the PCS: NAD83 CSRS v7 (epoch 2010). This is related, but more specifically about how ArcMap handles some of these projections and their differences. Hoping Melita Kennedy‌ is watching this thread

We are using both ArcMap 10.6x with some partner agencies using 10.3x. We noticed that the new GCS for NAD83CSRS v7 (8255) is available in ArcGIS 10.6x and Pro, so we've created a new custom PCS using this GCS reference. This creates our PCS projection file - all is well so far.

Our questions are when looking at the details of the new PRJ and the related GCS PRJ files...

1. In looking at the details of the GCS for "NAD83(CSRS)v7" and comparing to another version such as "NAD83(CSRS)v3", there is no real difference in the details (beyond names). Is there something that makes these (all 7 versions of this GCS) different? Possibly an underlying DLL that has the additional "Reference Epoch Coordinate Transformation" values stored - as this is the only difference notice b/w the GCS's when digging into the EPSG site (wayyy deeper than I truly understand). Example: v7 uses the epoch reference EPSG:1198, while v3 uses EPSG:1194. But this detail isn't in the prj and not sure if this has any impact, or how the software can tell the difference. Or is this something that only matters if transformation from one to another - realizing these transformation aren't out there?

2. Based on the above, will this custom PCS.PRJ work with ArcMap 10.3 since GCS 8255 and possibly underlying reference datum/epoch values not being available in older versions of the software?

Phew, I really hope that made sense. I thank everyone who even read this far -  and any insights you may have.

Tags (1)
0 Kudos
1 Solution

Accepted Solutions
MelitaKennedy
Esri Notable Contributor

HI Bryan, 

We exactly compare two coordinate systems, so if the names are different, that's enough to trigger a "not equal!" result. Handling different base epochs (assuming data is at time zero of the GCS), would require a transformation that has those different GCS in its definition. In a future release, we hope to add both inter-movement, between two different reference frames AKA GCS at the same epoch date like ITRF2014 and NAD83(CSRS)v7 and both are at 2017, and intra-movement, NAD83(CSRS)v7 where input data is at 2017.6 and you want to convert it to 2018.4. 

So anyway, we currently don't have any transformations yet for the Canadian realizations. Hopefully, in the next release. (don't ask me when yet)

Melita

View solution in original post

2 Replies
MelitaKennedy
Esri Notable Contributor

HI Bryan, 

We exactly compare two coordinate systems, so if the names are different, that's enough to trigger a "not equal!" result. Handling different base epochs (assuming data is at time zero of the GCS), would require a transformation that has those different GCS in its definition. In a future release, we hope to add both inter-movement, between two different reference frames AKA GCS at the same epoch date like ITRF2014 and NAD83(CSRS)v7 and both are at 2017, and intra-movement, NAD83(CSRS)v7 where input data is at 2017.6 and you want to convert it to 2018.4. 

So anyway, we currently don't have any transformations yet for the Canadian realizations. Hopefully, in the next release. (don't ask me when yet)

Melita

View solution in original post

BryanMcIntosh
New Contributor III

Thank you so much Melita. Answers the questions, and looking forward to a future release with that enhancement.

0 Kudos