SW Maps – How is Ortho Height derived

I have an RTK Express and am using SW Maps. The RTK Express (not SW Maps) gets the RTK data from mount point P776_RTCM3 at rtgpsout.unavco.org. SW Maps connects to the RTK Express using Bluetooth. I have not provided SW Maps a Geoid File.

When I record a point in SW Maps and download the Excel file, I get the following:

ID 233

Remarks road

Time 08/29/2023 13:31:48.000 EDT

Geometry POINT Z (-71.15969189 44.14395690 480.087)

Latitude 44.1439569

Longitude -71.15969189

Elevation 480.087

Ortho Height 513.999

Instrument Ht 2.038

Fix ID 4

Speed 0.005

Bearing 0

Horizontal Accuracy 0.024

Vertical Accuracy 0.039

Subtracting 480.087 (SW Maps Elevation) from 513.999 (SW Maps Ortho Height) yields 33.912 M. The Geoid12b for 44.1439569 lat, -71.15969189 lon is 27.054 M.

I am guessing that the Elevation of 480.087 M is the height above the ellipsoid?

I would have guessed that the Ortho Height of 513.999 M was the height above the ellipsoid, but this does not seem to make sense.

If I take 480.087 M and add 27.054 M (from https://geodesy.noaa.gov/), I get 507.141 M. Converting 507.141 M to feet is 1,663.848 feet.

Data from the New Hampshire site (https://granitview.unh.edu/ ) for the LiDAR derived 2 foot Hypsographic Contours has this point between 1,666 and 1,668 feet.

It seems that taking the SW Maps 480.087 M and adding the NOAA GEOID12B of 27.054 for this location gets me within about 3 vertical feet (1,663.848 vs the topo of ~1,667).

With all of that, I have two main questions.

  1. Where does the SW Maps Ortho Height of 513.999 come from and how is it derived?

  2. Why doesn’t using the Elevation from SW Maps, and adding the GEOID12B delta come closer than 3 vertical feet of the LiDAR derived 2 foot Hypsographic Contours?

There are many things that need to be perfect to get spot-on elevations. I’m not a regular SWMaps user, but there are a couple things I can suggest:

  1. I find it best to set SWMaps to use the geoid I work in. I work in the 2018 geoid, so I put the 2018 geoid file on my iPhone and set SWMaps to use it. But that’s not the point of your question.

  2. The ZED-F9P in the Sparkfun units has a coarse geoid built-in, you’re probably seeing the orthometric height the ZED is reporting. I’m not sure exactly; I like to look at the $GGA NMEA strings to be sure I understand what’s going on.

  3. “Fix ID 4” to me says you have an RTK Fixed solution. Good. For your CORS station, what datum is it using? (I’m not familiar with the mountpoint you’re using.) US CORS stations generally use NAD83. So ellipsoid heights will be off the GRS80 ellipsoid, not the WGS84 ellipsoid. Generally the coordinates the rover reports will be in the same datum the base (CORS) station is set to. Also, how far away is the base station? Distance greatly affects accuracy.

  4. What’s the datum for the contours you are using? Is it based on ITRF, NAD83, or something else? It Which geoid? Does it match that of the base coordinates?

  5. Is your instrument height (HI) correct? How about the ARP-APC offset? I don’t recall if you need to manually add ARP-APC offset for your antenna to your HI.

  6. I would find something better to check your elevation against than a random point on the ground that you’re using LIDAR estimate an elevation.

I looked up P776. The ITRF2014 and NAD83(2011) ellipsoid heights differ by about 1.176m, or about 3.85’, FWIW.

I don’t use the UNAVCO NTRIP servers, do they transmit reference locations in ITRF14 or NAD83?

 ITRF2014 POSITION (EPOCH 2010.0)                                            |
| Computed in Jun 2019 using data through gpswk 1933.                         |
|     X =   1478720.127 m     latitude    =  43 32 35.75568 N                 |
|     Y =  -4388494.011 m     longitude   = 071 22 42.80184 W                 |
|     Z =   4371775.899 m     ellipsoid height =  476.944   m                 |
|                                                                             |
| ITRF2014 VELOCITY                                                           |
| Computed in Jun 2019 using data through gpswk 1933.                         |
|     VX =  -0.0158 m/yr      northward =   0.0058 m/yr                       |
|     VY =  -0.0015 m/yr      eastward  =  -0.0155 m/yr                       |
|     VZ =   0.0045 m/yr      upward    =   0.0005 m/yr                       |
|                                                                             |
|                                                                             |
| NAD_83 (2011) POSITION (EPOCH 2010.0)                                       |
| Transformed from ITRF2014 (epoch 2010.0) position in Jun 2019.              |
|     X =   1478720.909 m     latitude    =  43 32 35.72066 N                 |
|     Y =  -4388495.433 m     longitude   = 071 22 42.78904 W                 |
|     Z =   4371775.925 m     ellipsoid height =  478.120   m                 |
|                                                                             |
| NAD_83 (2011) VELOCITY                                                      |
| Transformed from ITRF2014 velocity in Jun 2019.                             |
|     VX =   0.0020 m/yr      northward =  -0.0014 m/yr                       |
|     VY =  -0.0000 m/yr      eastward  =   0.0019 m/yr                       |
|     VZ =  -0.0013 m/yr      upward    =  -0.0004 m/yr

@toeknee very helpful, thank you.

Thank you for explaining the built-in geoid on the ZED-F9P. I only take measurements in two locations, so I will determine what the geoid offsets are for those two locations and add them to the ellipsoid elevation (once I figure out what the proper offsets are).

I don’t know what datum P776_RTCM3 uses. I went to the P776 overview page, but it did not seem to be listed (https://www.unavco.org/instrumentation/ … rview/P776).

The contours are referenced to New Hampshire State Plane Feet, North American Datum 1983 (NAD83) - Zone: 4676 (This is the USGS zone. The FIPSZONE is 2800.)

This afternoon I was in a different geographical location, and I placed my RTK Express on the windowsill (not a great view of the sky). I captured a fair number of NEMA strings which I will post below. I don’t know if these strings will provide either the datum or ellipsoid that P776 is using?

Here are some of the NEMA strings I captured this afternoon:

$GAGSV,2,2,07,18,12,214,08,19,85,009,24,33,34,162,21,7*4A

$GAGSV,1,1,02,27,03,074,30,01,026,0*75

$GBGSV,2,1,08,14,24,073,34,24,25,078,44,27,44,264,27,28,30,204,15,1*78

$GBGSV,2,2,08,30,19,317,34,32,16,268,32,33,50,062,35,41,66,298,39,1*77

$GBGSV,1,1,01,14,24,073,38,B*38

$GBGSV,1,1,03,25,20,137,26,07,033,42,02,078,0*4C

$GQGSV,1,1,00,0*64

$GNGST,175450.50,45195,1.6,1.0,4.7,0.65,0.41,1.2*5C

$GNRMC,175450.75,A,4338.6913162,N,07011.6468587,W,0.018,300823,A,V*00

$GNGGA,175450.75,4338.6913162,N,07011.6468587,W,1,12,0.57,34.373,M,-31.806,M,*45

$GNGSA,A,3,05,10,13,15,18,27,23,24,0.99,0.57,0.81,1*03

$GNGSA,A,3,86,73,80,87,70,71,72,0.99,0.57,0.81,2*00

$GNGSA,A,3,33,04,10,11,12,19,0.99,0.57,0.81,3*06

$GNGSA,A,3,14,24,27,28,30,41,33,32,0.99,0.57,0.81,4*04

$GNGSA,A,3,0.99,0.57,0.81,5*0E

$GNGST,175450.75,45195,1.6,1.0,4.7,0.65,0.41,1.2*5B

$GNRMC,175451.00,A,4338.6913155,N,07011.6468581,W,0.018,300823,A,V*01

$GNGGA,175451.00,4338.6913155,N,07011.6468581,W,1,12,0.57,34.372,M,-31.806,M,*45

$GNGSA,A,3,05,10,13,15,18,27,23,24,0.99,0.57,0.81,1*03

$GNGSA,A,3,86,73,80,87,70,71,72,0.99,0.57,0.81,2*00

$GNGSA,A,3,33,04,10,11,12,19,0.99,0.57,0.81,3*06

$GNGSA,A,3,14,24,27,28,30,41,33,32,0.99,0.57,0.81,4*04

$GNGSA,A,3,0.99,0.57,0.81,5*0E

$GNGST,175451.00,45195,1.6,1.0,4.7,0.65,0.41,1.2*58

$GNRMC,175451.25,A,4338.6913152,N,07011.6468574,W,0.015,300823,A,V*06

$GNGGA,175451.25,4338.6913152,N,07011.6468574,W,1,12,0.57,34.367,M,-31.806,M,*4B

$GNGSA,A,3,05,10,13,15,18,27,23,24,0.99,0.57,0.81,1*03

$GNGSA,A,3,86,73,80,87,70,71,72,0.99,0.57,0.81,2*00

$GNGSA,A,3,33,04,10,11,12,19,0.99,0.57,0.81,3*06

Looking at your last GGA sentence:

$GNGGA,175451.25,4338.6913152,N,07011.6468574,W,1,12,0.57,34.367,M,-31.806,M,,*4B

The fix type is 1, so autonomous, this is just on your windowsill for testing. You don’t have an RTK Fixed solution, were you getting RTCM from P776? Doesn’t really matter for this conversation right now, just curious.

The ```
34.367,M


The ```
-31.806,M
``` is the built-in geoid height (N) in meters. I forget which geoid is built-in, probaby EGM2008; we've discussed this this forum before and it's probably in the u-blox documentation.

If a software program displays ellipsoid height (h), it's almost surely backing it out from H and N. 

The geoid height N is generally negative in the 48 US states.

H = h - N, or

Ellipsoid height: h = H + N = 34.367 + (-31.806) = 2.561 meters.

----

The usual statement is "contact your network provider to determine what datum they are using". 

The NMEA from your receiver in my experience will not tell you much about the reference station. The data you want is in the RTCM feed from the reference station.

I imagine you could capture and decode the RTCM you're receiving from your network station, look at the RTCM 1005 or 1006 messages, examine the coordinates in the messages, and compare them to the ITRF and NAD coordinates for the station. There are some tools (SNIP, BNC, etc. that reportedly do this but I haven't used them. See [https://surveyorconnect.com/community/g ... ggestions/](https://surveyorconnect.com/community/gnss-geodesy/rtcm-message-viewer-suggestions/)

HOWEVER due to the <B>**AWESOME and AMAZING FOLKS AT SPARKFUN**</B>, the SparkFun RTK firmware since v3.4 will decode the RTCM 1005/1006 messages and log them if you turn this decoding and logging on. You should be able to compare the logged ECEF X,Y,Z against the published ECEF coordinates for P776 and figure it out.

See this RTK Firmware github comment for more info:

[https://github.com/sparkfun/SparkFun_RT ... 1567961142](https://github.com/sparkfun/SparkFun_RTK_Firmware/issues/447#issuecomment-1567961142)

Manual link:

[https://docs.sparkfun.com/SparkFun_RTK_ ... -interface](https://docs.sparkfun.com/SparkFun_RTK_Firmware/menu_data_logging/#serial-interface)

And more general info on how configure the software via the Serial Menu here

[https://docs.sparkfun.com/SparkFun_RTK_ ... th_serial/](https://docs.sparkfun.com/SparkFun_RTK_Firmware/configure_with_serial/)

Hope that helps -- and definitely let us know how it goes!

Tony.

I just now downloaded a free evaluation of SNIP (use-snip.com), installed it, and connected it to one of the CORS casters that I use (I work in two states with free CORS networks provided by the state Dept of Trans - live free or die baby :). It provided me with the ECEF decoded 1005 RTCM record coordinates from my CORS station, and they agreed with the NAD83(2011) published ECEF coordinates to within 3mm. So I believe I’ve confirmed that this CORS station reference is in NAD83(2011), and that any RTK Fixed solutions from my rover will be in NAD83(2011).

Would someone be so kind as to explain in plain language how to acquire the geoid file and get it into .gtx format so SW maps can use it. I’ve been wandering around NOAA website with no luck in actually finding any files.

I found a file called g2018u5.bin
is this the geoid file I use for sw maps (western US)?
do I have to convert it to .gtx ?

@steve1428 Which Geoid do you want ?

NAD83 and NAVD88
More information about NOAA/NGS's GEOID18 GEOID18 136 MB
More information about NOAA/NGS's GEOID12B GEOID12B 92.48 MB
More information about NOAA/NGS's GEOID12A GEOID12A 92.48 MB
More information about NOAA/NGS's GEOID09 GEOID09 48.8 MB

These are .GTX files once uncompressed. Here’s the Geoid18 File contents as an example:

Great thanks, I loaded some cli software from NOAA and got this g2018u5 file which I think is for my area in Arizona but it’s a .bin not .gtx so I think I went down the wrong rabbit hole.

Pretty sure my area in Arizona is GEOID18.

I downloaded and unzipped from your link and found that .gtx files but how can I be sure which one if for my area?

The simple answer is use the G2018u5.gtx file :wink:

thanks for your help!
do you use SW maps?
it doesn’t seem to output XYZ when recording tracks, only long and lat. It gives you XYZ as well when recording individual features though.

I don’t think the program can be changed but I’ve seen hints of conversion software out there but it seems to only do them one at a time.
I’m trying to put 3D terrain on my building plan in Home Developer Pro but it wants X,Y,Z coordinates.

You can Export your project as a Spreadsheet, and select UTM. You can then structure your X,Y,Z points file however Home Developer Pro wants it.

This is the coverage area for g2018u5.gtx
It appears you were correct, it covers West Arizona

I got it loaded up, waiting on a fix, they don’t like the middle of the day, I wonder what temperature inversions do to fix data?
does it indicate it’s actually recording orthometric elevations in the data?
I tried it both geoid on and off and get the same elevation pretty much, unless there’s no deviation in this particular spot or the geoid built into the chip is right on

The Elevation (height above Ellipsoid) wont change at all.
The reported Ortho Height will, depending on which Geoid is used.

Examine a stored point in SW Maps.
The metadata will list both:
Elevation:
Ortho Ht:

A GNSS device sends the Ellipsoidal Height, and the Geoid Separation in the NMEA GGA Sentence.
The Geoid Separation is from it’s internal (usually decimated) Geoid File.
The device reports the Geoid Separation used so any external software (like SW Maps) can apply it’s own Geoid to the position (g2018u5.gtx for you).

There will be a difference in Ortho Height from a native position verses applying GEIOD18.
It might only be a tiny bit, depends on your location and the (2) geoids used for comparison.

I’m only getting gps coord from track exports even with show UTM coord checked.
it outputs in both comma and space delimited format, I need to pay microsoft for the full excel to masage the data i guess.

I got the demo for fieldgenius, maybe we can do more with it