Save Datum Transformation

[dpitman]

Is there any way to save a Datum Transformation (Go To WGS84) to a CRS so it does not need to be entered each time on a new project?

I suppose I could enter it and save the empty project as a template.  But it seems there should be a way to edit the CRS to retain this transformation.  In the Edit CRS dialog, there is currently no way to assign a Go To WGS84 transformation.

Am I missing it?  Thanks!

[Paulo]

Hi Dave,

I  would enter the correct 7 parameters towgs84 and save the project as a template. Then any time you need to work with  NAD83(20111)_Washsoth_NAVD88(ftUS), just open the template project and go from there...

See attached example template.

PS. in each project psz, the CRS is kept in the reference entry of doc.xml

[dpitman]

Okay, thanks Paul.

I'm still struggling a bit with this transformation per our other conversation.  Using the OPUS point as a benchmark, when I perform the transformation from epoch corrected geographic to state plane projected in MS without using the towgs84 transform, the resulting coordinate is closer to what OPUS reports than when I apply the 7 parameter transformation.  I have to assume the state plane coordinate on the OPUS report is the most accurate, right?  And, the transformation from geographic to projected with out using the towgs84 transform in MS also agrees with the transformation using another tool in my Emlid account.  So, at this point, I'm relieved that my job isn't requiring me to provide a horizontally, centimeter accurate, projected product!

Thanks for the tip on the .xml file!

[Paulo]

Hi Dave,

what happens is the 7 parameter set is for a certain epoch. In this example epoch 2010.0 parameters [-1.0053,1.90921,0.54157,0.0267815,-0.00042078,0.01093254,-0.00036891].

Thus in your OPUS report the point ITRF2014 coordinates at epoch of survey (2024.9968) have to be transformed to epoch 2020 before conversion to nad83(2011) UTM11n NAVD88 height. This is done by using HTDP program from NGS.

From Opus report for reac point:

Code: [Select]

REF FRAME: NAD_83(2011)(EPOCH:2010.0000)              ITRF2014 (EPOCH:2024.9968)

         X:     -2124257.474(m)   0.019(m)          -2124258.504(m)   0.019(m)
         Y:     -3787362.091(m)   0.006(m)          -3787360.891(m)   0.006(m)
         Z:      4656407.232(m)   0.012(m)           4656407.181(m)   0.012(m)

       LAT:   47 11 24.99997      0.016(m)        47 11 25.01174      0.016(m)
     E LON:  240 42 46.02161      0.017(m)       240 42 45.95105      0.017(m)
     W LON:  119 17 13.97839      0.017(m)       119 17 14.04895      0.017(m)
    EL HGT:          329.021(m)   0.007(m)               328.615(m)   0.007(m)
 ORTHO HGT:          349.672(m)   0.063(m) [NAVD88 (Computed using GEOID18)]

                        UTM COORDINATES    STATE PLANE COORDINATES
                         UTM (Zone 11)         SPC (4602 WA S)
Northing (Y) [meters]     5228847.071           207112.470
Easting (X)  [meters]      326734.825           591905.162
So with HTDP we transform the ITRF2014 coordinates from survey epoch (2024.9968) to 2010.0 epoch:

Code: [Select]

HTDP OUTPUT, VERSION 3.5.0   

 TRANSFORMING POSITIONS FROM ITRF2014 or IGS14/IGb14  (EPOCH = 12-30-2024 (2024.9968))
                          TO ITRF2014 or IGS14/IGb14  (EPOCH = 01-01-2010 (2010.0000))

 reac                   
  LATITUDE     47 11 25.01174 N     47 11 25.01621 N       -9.21 mm/yr  north   47.1902822805
  LONGITUDE   119 17 14.04895 W    119 17 14.03983 W      -12.81 mm/yr  east -119.2872332861
  ELLIP. HT.             328.615             328.617 m     -0.12 mm/yr  up
  X                 -2124258.504        -2124258.288 m    -14.44 mm/yr
  Y                 -3787360.891        -3787360.898 m      0.44 mm/yr
  Z                  4656407.181         4656407.276 m     -6.34 mm/yr
Now in MS, I can transform itrf14_2020 coordinates to nad83_utm11n_navd88 using:

Code: [Select]

wgs84
<CoordinateSystem 'WGS 84 (EPSG::4326)'>

nad83_UTM11n_navd88.wkt
'COMPD_CS["NAD83(2011) / UTM zone 11N + NAVD88 height",PROJCS["NAD83(2011) / UTM zone 11N",GEOGCS["NAD83(2011)",DATUM["NAD83 (National Spatial Reference System 2011)",SPHEROID["GRS 1980",6378137,298.257222101,AUTHORITY["EPSG","7019"]],TOWGS84[-1.0053,1.90921,0.54157,0.0267815,-0.00042078,0.01093254,-0.00036891],AUTHORITY["EPSG","1116"]],PRIMEM["Greenwich",0,AUTHORITY["EPSG","8901"]],UNIT["degree",0.01745329251994328,AUTHORITY["EPSG","9102"]],AUTHORITY["EPSG","6318"]],PROJECTION["Transverse_Mercator",AUTHORITY["EPSG","9807"]],PARAMETER["latitude_of_origin",0],PARAMETER["central_meridian",-117],PARAMETER["scale_factor",0.9996],PARAMETER["false_easting",500000],PARAMETER["false_northing",0],UNIT["metre",1,AUTHORITY["EPSG","9001"]],AUTHORITY["EPSG","6340"]],VERT_CS["NAVD88 height",VERT_DATUM["North American Vertical Datum 1988",2005,AUTHORITY["EPSG","5103"]],UNIT["metre",1,AUTHORITY["EPSG","9001"]],AUTHORITY["EPSG","5703"]]]'

reac_itrf14_2010
 Vector([-119.28723328611112, 47.19028228055556, 328.617])

wgs84.transform(reac_itrf14_2010,wgs84,nad83_UTM11n_navd88)
 Vector([326734.8246430163, 5228847.071200894, 349.67292042895883])
As you can see the coordinates agree with OPUS nad83 UTM11N NAVD88 height at mm level...

Hope this is clearer!

[dpitman]

Your instructions are very clear, Paul.  Thank you.

However, when I enter the epoch adjusted coordinate into MS and apply the transformation, the state plane coordinate is off by 1.4 ft and 3.9 ft horizontally.  Elevation is fine.

I'm using the results from the HTDP tool which are the same as yours.
I then convert the DMS coordinate to Decimal because MS doesn't like DMS at least in WGS84.

Then I apply the CS and the towgs84 parameters.  I don't know why I get a different result than you do.

[Paulo]

That is puzzling, Dave...if you have the original coordinates of this point in ITRF2014 epoch? then maybe I can test the transformation to your projected NAD83(2011) ft...

[dpitman]

I'm not sure what you are asking for, Paul?  The coordinate that I have been using is the one established by a 2+ hour observation receiver rinex file processed through OPUS. And you have that.

[Paulo]

Ok, I understand same point but in Washington South (ftUS) + NAVD88..

I transformed the same point (epoch 2010) to this crs and got:
 

Code: [Select]

crs
<CoordinateSystem 'NAD83(2011) / Washington South (ftUS) + NAVD88 height (ftUS)'>

pt
Vector([1941942.184291527, 679501.4939030237, 1147.2179104756112])

which is very close to your values.

and then when I transform to NAD83 UTM11N, i get:

Code: [Select]

nad83_UTM11n
 <CoordinateSystem 'NAD83(2011) / UTM zone 11N (EPSG::6340)'>

crs.transform(pt,crs,nad83_UTM11n)
 Vector([326734.8245687194, 5228847.071092972, 329.02173215756494])
which are equal to UTM coordinates + elip. height given in OPUS report...

So it seems ok on this side...

[dpitman]

I can reproduce your transform to UTM grid using 6340 horizontal.  But I can't seem to get close to WA State Plane South no matter which CS I use.

Neither of these have a combined vertical transform like 8791.  Using 8791 seems to get me a good match to the geoid height in the OPUS report using the 7 parameter adjustment towgs84.

This all seems somewhat messy and prone to error for sure. :/

I really appreciate your help!

[Paulo]

Hello Dave,

what  SPCS are you using?  Feet are international or US? Possible error there?

In attachment, I have side by side chunk with your point reac in WGS94(ITRF2024) EPOCH 2024.99 and in Nad83(2011)/Washington South epoch 2010 and values are equal to ones published by OPUS report...

[Paulo]

Yes Dave,

this is the NAD83 / Washington South (ftUS) + NAVD88 height (ftUS) CS. Again I could propose a workflow where your survey data could be transformed from the WGS84 (ITRF2014) CS at capture date to some official NAD83(2011) CS at epoch 2010 for cliente delivery. This could include the datum shift between capture date and 2010.0 as well as 7 parameter Helmert transformation from ITRF14 to NAD83...

Contact me on PM or email if you want more details...

Cheers

[dpitman]

You are correct that the problem I'm having is the result that the CS in MS is converting to us survey feet and not international feet.

I was able to get the correct matching values by using the CS with meters that you used.  But the CS I have tried in MS seem to all be using us survey feet and I'm pretty sure NGS is using international feet as us survey feet was depreciated on December 31, 2022.

So far, I'm not finding an appropriate CS that uses international feet. But if I stay in metric, it matches.

Thanks again for the hand holding. 
gratuity on the way.

[Paulo]

Hi Dave,

yes probably a conversion factor...

if you look at a sample prj file using USft from MS you can edit the UNIT entry to put the correct conversion factor to m for International feet:

Code: [Select]

UNIT["US survey foot",0.3048006096012192,AUTHORITY["EPSG","9003"]]
Probably would have to correct the EPSG authority code