Issues with WGS_1984_(ITRF00)_To_NAD_1983 Datum transformation

JohnDeLoretta3 · ‎12-10-2018

Hi,

Recently been having issues while working with this datum transformation. My company is working on a project where data comes from Trimble GPS receivers and also survey data. The survey data is both exported from Trimble Business center and also transformed with PostGIS using Proj4 into local state plane coordinates. The GPS data is post-processed with Trimble Pathfinder office and exported as shapefiles into the local state plane coordinate system. The shapefiles are then imported into our SDE which is in WGS84 using the WGS_1984_(ITRF00)_To_NAD_1983 Datum transformation.

When comparing data exported from PostGIS to the data in our SDE they line up fine in ArcMap, until I apply the WGS_1984_(ITRF00)_To_NAD_1983 Datum transformation to my map document (ArcMap 10.5). We see a 1m shift between the datasets when the datum transformation is applied.

It appears that there is no datum transformation applied to the survey data that is transformed using PostGIS/Proj4. Digging deeper I found that between WGS84 and NAD83 there is essentially no difference between the two- at least the original iteration of WGS84 and NAD83. Going even further, I confirmed in Pathfinder Office that there is no transformation between WGS84 and NAD83 (see attachment) . I noticed that the transformation values applied in ArcGIS using WGS84 using the WGS_1984_(ITRF00)_To_NAD_1983 match the transformation values exactly to what Trimble Pathfinder office uses for NAD 1983 (Conus) CORS96 (see attachments).

It is at this point where I am questioning everything I know about datums and coordinate systems.

Does anyone have any input on this workflow? Should Survey be exporting using a transformation in Trimble Business Center/Proj4 or should I ignore the datum transformation?

Any input or clarification would be greatly appreciated, I've run myself into an infinite loop.

JohnDeLoretta3 · ‎12-11-2018

Thanks Joel, yes it does seem like that would be a good idea to do a compare. I always thought it was a black & white issue- where you apply the 'most accurate' datum transformation when migrating between coordinate systems. I've been applying datum transformations to my data for years and now I'm not sure if that's the correct thing to do. Especially when working with KMZ files from my clients- I guess it's impossible to know whether a datum transformation was applied for their output to a kmz, and thus impossible for me to know if I should apply one taking it out of the KMZ.

JoelCusick · ‎12-11-2018

John,

I'm pretty familiar with PFO/TBC and have both down cold depending on what you want your final export to be "in". Then there is the issue of what is your input datum, and how you are correcting the data. Your screen shots from PFO are absolutely correct. TBC also has the same exact ones. But, and I'll emphasize again is there is no way around testing on control set to the output you want to be "in". I've trained hundreds, and every student by the 3rd day doesn't get "it" until they plop their data onto a point in ArcMap and they are 1.5 meters away, while the other students are 10cm away. Your getting bit by thee most common confusion in GIS today. Thank god we got Melita, but you can imagine her inbox from all over the world. Your original question is very specific to handling in TBC, PFO.

So, I don't even want to guess why you want to be in "WGS84". If your in State Plane, your an obvious US citizen, so most common is you want to be in NAD83, and since your using top dollar GPS devices, you most specifically want to be "in" NAD83 (2011) Epoch 2010.0. Thats what you get when you run OPUS or PFO with a CORS base station and you use the reference from Base file. You have with each software, 2 datum gates you must pass thru, and thirdly ask what you are setting in ArcMap. So that is a 3x3 matrix or 9 possible combinations. You can't do this correctly without TRUTH. You must calibrate your GPS work, and Accuracy means doing the right thing with datum. You can't evaluate Accuracy without comparing to TRUTH, and its so darn easy these days to set a nail, occupy with a GPS running 2 hours and comparing.

Oh, and your last comment on KMZ production. Nothing in Google Earth ever is to be trusted. I wouldn't export data from 2,000$ software just to be compliant with GE. Export to NAD83 (2011) and let others suffer with any supposed shifts in GE.

Just some thoughts. Joel