Facet and SW Maps Elevation Wrong?

I am using with SW Maps on an Android Tablet. Everything seems to be working great, except the elevation is incorrect (it says -35ft when it should be around 125ft) both in float and when using it with a web based NTRIP connection through SW Maps. It moves up and down correctly, but is as if an offset has been set somewhere for elevation?

How are you obtaining what the elevation should be?

The default altitude output by most GNSS receivers (including the RTK line) is HAE or height above ellipsoid. This will vary from altitude above sea level.

Please see this tutorial (https://docs.sparkfun.com/SparkFun_RTK_ … ification/) on how to obtain a local reference NGS monument and verify your setup against a known good point.

I was curious about this as well. I was just comparing to Google Earth and noticed a large discrepancy.

How would I go about to converting these numbers to height above MSL? May of the geophysical logs I am comparing to the logs at our positions in the field reference MSL.

To elaborate on @sparky’s post:

There was a recent thread on this topic and what the SparkFun units are doing here:

viewtopic.php?f=116&t=59804

That page helps explain orthometric height (H), ellipsoid height (HAE or h), and geoid separation (N). There are many excellent web resources to explain this topic.

TLDR:

To compare the height displayed by your software (SWMaps) and your field logs:

  1. You need to figure out what vertical reference datum your field logs use. Hopefully the author of the field logs documented it and the logs are consistent.

  2. You need to figure out what type of “elevations” your software is displaying elevation in.

  3. You’ll need a good RTK Fixed solution, and you’ll need to be careful with your instrument heights and GNSS receiver antenna models.

Details, details…

ONE:

You’ll need to find out what reference your field logs used for MSL. There is no one standard for “Mean Sea Level”. If you’re in the US, common vertical reference datums include NAVD88 and NGVD29. The term “MSL” is vague, it’s considered imprecise. It’s more precise to specify the vertical datum you are using. There are many vertical datums throughout the world’s various countries and throughout history. Here is info on the two commonly used in the US:

https://www.ngs.noaa.gov/datums/vertica … 1988.shtml

https://www.ngs.noaa.gov/datums/vertica … 1929.shtml

NAVD88 is implemented via a Geoid Model. This is a mathematical model of a lumpy spheroid that represents what used to be called “Mean Sea Level”. That is, the geoid approximates where 0’ above mean sea level would be in imprecise terminology. There are multiple geoids, and the National Geodetic Survey updates the geoids as they collect and refine their data.

TWO:

GNSS receivers internally calculate the height above the ellipsoid (HAE), but often they have an imprecise, almost crude, geoid model built in to approximate orthometric height. The NMEA specification is that the GNSS receivers output the orthometric height and any geoid correction that the receiver has built-in to determine the orthometric elevation from the HAE. The software that interprets and display the “height” could be doing three things:

  1. Display the ‘crude’ orthometric elevation based on the built-in crude geoid model.

  2. Calculate the HAE by backing out the crude geoid model to determine HAE.

  3. Do #2 above and then apply a different, hopefully more accurate, geoid model chosen by the software and the user of the software.

When I look at the “GNSS Status” in SWMaps (iOS), SWMaps is very clear about what it is doing. It provides three different elevations:

a. “Ellipsoid Height”, or HAE. It is almost certainly doing #2 above to calculate this.

b. "Orthometric Height (GPS). This is almost certainly #1 above.

c. “Orthometric Height (Geoid)”. This is almost certainly #3 above

I commend SWMaps for being very clear about how it’s displaying the elevation info. This is rare among GP, mapping, and hiking applications.

You can manually calculate your geoid-ellipsoid separate (N) here: https://geodesy.noaa.gov/GEOID/GEOID18/computation.html

THREE:

GNSS elevations are very sensitive to the operating and field conditions. You can have great northings and eastings and not-so-great elevations.

–You’ll want a clear view of the sky, a good RTK Fix, and check your PDOPs.

–You’ll want to keep the baseline (distance) to the network reference station (“base”) short. People have different ideas of short, but I start to keep a close eye on things if my baseline is more than 10-20 miles.

-You’ll want to go back an hour or two later, or the next day, measure again, and compare the measurements to be sure you aren’t getting bad RTK Fixes. They happen.

It’s also important to accurately account for the elevations of your GNSS receiver antenna above the mark on the ground you are checking the elevation for. I doubt this is causing a 160’ discrepancy, but it could be 6’ of it. Surveyors use rods that have the instrument height marked on them, and they check the height with a tape measure routinely.

Hope that helps,

Tony.