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).