Share:
Notifications
Clear all

What is the resampling size used by Trimble to derive H using a large Geoid file.

GISJoel
(@gisjoel)
100+ posts Member

The Trimble Geoid Model Configuration tool  https://www.trimble.com/globalTRLTAB.asp?Nav=Collection-71 allows a Trimble geoid file *.ggf to be interpolated based on the local ellipsoid or Global (WGS84) ellipsoid.  My question digs deeper - what resampling method is Trimble using either in TBC or in Access when H is being displayed, or used in the software.  Another more simplistic way to say this, if two points are shot 2 meters apart, the Orthometric H is different.  This can only be possible if the *.ggf file is interpolated between the edges of the grid.

I am asking this question since were going to interpolate the same file (Geoid 12A Alaska) to process the DSM from manned aerial SfM data being acquired by our team.  We are holding ellipsoidal heights in our output from AGISOFT processing, then planning on using on-the-fly surface generation to derive orthometric hieights of PPK measurements.  Matching the same resampling grid size of the geoid 12 Alaska grid that Trimble deploys would be ideal.  Every software has to interpolate this large grid to relate data.  In our case the R7 being deployed in the aircraft is event marking at 10HZ, resulting in a requirement to resample the Geoid grid.  Software performs interpolation based on the ellipsoid chosen, but we need to know the method/resmapling size.

I hope I did not hack this topic too bad.  This might not be solved if its held as a trade secret by Trimble.

Note: Trimble Access Version 2011.00 and Survey Controller Version 12.47 and later, perform geoid model interpolation based on the setting within the geoid model file. In all previous versions of the software the interpolation of all geoid models was always based on the WGS-84 (Global) ellipsoid.

Joel

Quote
Topic starter Posted : February 3, 2019 12:08 pm
Gene Kooper
(@gene-kooper)
1,000+ posts Member

A question rather than an answer.  When using GEOID12A or GEOID12B, does the Trimble software compute values for H that are the same as the NGS online algorithm?

 

Edit for grammer and spellin

ReplyQuote
Posted : February 3, 2019 12:19 pm
GISJoel
(@gisjoel)
100+ posts Member

Gene,

Excellent question and I'm ashamed I haven't done a rigorous test.  I'm guessing I could use the NGS tool  https://geodesy.noaa.gov/GEOID/GEOID12B/computation.html and compare in TBC the same lat/long.  It is my assumption (and only an assumption with the black box) that Trimble, or any other GPS company who exports H from ellipsoid, is the same interpolation that NGS uses at the tail end of say an OPUS solution.

 

Joel

ReplyQuote
Topic starter Posted : February 3, 2019 4:13 pm

Loyal
(@loyal)
1,000+ posts Member

Bear in mind that the value extracted from the GEOID12a/b Model is the 'N' value (the difference between the NAD83 Ellipsoid Height and the NAVD88 "elevation" at the given NAD83 Latitude and Longitude). In North America that value is always a negative number (about -15 meters at my house). 

Just say'n

ReplyQuote
Posted : February 3, 2019 4:31 pm
GISJoel
(@gisjoel)
100+ posts Member

Loyal,

Point taken.  It is these N values we will use to generate H.  If we had a combo GRID FACTORY tool that clips, and a densifyer tool, we would be good to pass this file into our scripts.  

 

Joel

ReplyQuote
Topic starter Posted : February 3, 2019 4:56 pm
Gene Kooper
(@gene-kooper)
1,000+ posts Member

Loyal,

GISJoel is asking about GEOID12A for Alaska.  N values up there are the other way around.  For example, N is +17 meters for Anchorage.

I've never used Trimble software so have no idea how things are done.  However, I doubt very much that the algorithm for interpolating GEOID12A, GEOID12B or their predecessors varies from the NGS interpolation method.  The NGS uses a 6x6 grid of the 1 arc-minute grid values in the GEOID12A/B models (and before).  The method is a bi-linear spline algorithm first published in:

FAST ONE-DIMENSIONAL EQUIDISTANT SPLINE INTERPOLATION FUNCTION.
* REFERENCE: JOSEF STOER: EINFUHRUNG IN DIE NUMERISCHE MATHEMATIK, SPRINGER 1972, PAGE 81.

In 1983, Rene Forsberg wrote the original code used in the NGS software.

I created a spreadsheet for my own purposes so that I could better understand the algorithm and specifically the 6 nautical mile by 6 nautical mile grid values in mountainous terrain that gives the "magic black box" value for both geoid separation and the two deflection of the vertical components.

Forsberg's code computes the 6 spline values in one direction and then uses those values to compute the spline value at the point (in the other direction).  I think it computes the values along the six latitudes at the longitude of the point and then those six values at the latitude of the point to get the interpolated value.  Sorry, but I'm having a senior moment and too lazy to find my spreadsheet.  The convention could be the other way around, but it really shouldn't matter as both methods should give the same answer (within roundoff error).  

ReplyQuote
Posted : February 3, 2019 5:02 pm
JKinAK liked

Loyal
(@loyal)
1,000+ posts Member

Gene,

Me bad!

ReplyQuote
Posted : February 3, 2019 5:06 pm
Gene Kooper
(@gene-kooper)
1,000+ posts Member

Hey, not really.  Neither one of us work up there.  Despite all of my senior moments, for some reason I remembered a slide from a presentation where the geoid surface "inverts" in Alaska so that ellipsoid heights are higher than orthometric heights.

ReplyQuote
Posted : February 3, 2019 5:33 pm
Loyal
(@loyal)
1,000+ posts Member
Posted by: Gene Kooper

Hey, not really.  Neither one of us work up there.  Despite all of my senior moments, for some reason I remembered a slide from a presentation where the geoid surface "inverts" in Alaska so that ellipsoid heights are higher than orthometric heights.

Actually I DID work up in Alaska (briefly), but it was "pre-GPS."

Loyal

ReplyQuote
Posted : February 3, 2019 6:32 pm

GISJoel
(@gisjoel)
100+ posts Member

Gene,

Excellent. Will pass the reference above to our programmer. Next, I'll dig a bit deeper with Trimble Coordinate group and confirm their algorithm.  We have plenty of data to test and validate with Check points run with single base RTK based on 4 hour OPUS observations all over our state.  

Thanks.

ReplyQuote
Topic starter Posted : February 3, 2019 11:27 pm
Jacob Wall
(@jacob-wall)
100+ posts Member

I remembered this article from a few years ago, may be of use  https://www.xyht.com/surveying/geoid-model-interpolation/

ReplyQuote
Posted : February 4, 2019 9:07 pm
Lee D
(@lee-d)
1,000+ posts Member

I've never seen Trimble software produce a different N value than OPUS or any other NGS tool. Leica either for that matter.

ReplyQuote
Posted : February 5, 2019 5:29 am

Gene Kooper
(@gene-kooper)
1,000+ posts Member

Leica's LGO gives the same values for N as the NGS online tools.  Columbus LSA software does too.

BTW....the below table of Xi component of the deflection of the vertical in the middle of the Colorado mountains shows the large range of values (-19.4066 to 11.4173) used to compute the interpolated value.

Xi values for 6x6 NGS subgrid used by the interpolation algorithm

-1.6449 0.248 1.6321 -1.8004 2.4172 1.9466
-5.6435 -3.0267 -8.7072 -6.3892 -7.4179 -4.7211
-7.7080 -12.8362 -10.8212 -9.7004 -19.4066 -10.7142
-3.5739 -7.1276 -3.036 -17.0125 -19.0924 -9.3133
8.8663 0.7181 -5.9355 -12.676 -3.6132 -1.7959
3.9594 -5.2776 3.0002 11.4173 10.6959 0.8103

The final Xi value for the station is -14.09.

ReplyQuote
Posted : February 5, 2019 6:14 am
GISJoel
(@gisjoel)
100+ posts Member

Quick update:

Thanks to NGS tools online at  https://www.ngs.noaa.gov/GEOID/GEOID12B/GEOID12B_data.shtml and some help with guidance on our approach by Dr. Michael Dennis (NGS), were going to use a spline interpolation, which is NOT the same as the ESRI interpolation.  We will use the code  and so now were off to the races with what our programmer so we can store alongside our raster mosaic a clipped and resampled Geoid12A file which will utilize the N values to get to H.  Its apparent to our team who uses AGISOFT for processing they are not getting proper orthometric heights using the software.  Not sure how Pix4D handles the final computation, but were taking the tact to calculate this outside of AgiSoft and use the capacity in ESRI to conduct on-the-fly processing.

thanks for the guidance from all who responded (and corrections).  Joel

ReplyQuote
Topic starter Posted : February 23, 2019 12:27 pm
Share: