[PROJ] Altitude

[Greg Troxel]

Roger Oberholtzer <roger.oberholtzer at gmail.com> writes:

> Our typical scenario is that we collect data from a receiver (high-end
> dual antenna - so good quality) in a moving vehicle. We collect
> LAT/LONG in WGS84, and then project it using proj. For example to
> SWEREF99. So it's basically EPSG:4326 ->  EPSG:3006, or the inverse.
> Of course we don't only use SWEREF99. It's just an example.
>
> The receivers are configured to collect altitude as the geoid in
> EGM96. I think it is in fact the default for our receivers. So I guess
> it is a common altitude.

You got good advice from Javier and I don't mean to contradict any of
it.  Beware that height is quite difficult to really understand, more so
than most people realize.

Yes, EGM96 is a gravity model that is used to convert WGS84 ellipsoidal
height to "WGS84 orthometric height".

You say lat/long is WGS84.  I would advise you to try to avoid WGS84, as
it refeers to a family of datums, and if your data is at all recent
(2013+) it is surely in WGS84(G1762), for non-differential GPS.  This
labeling would, or could -- another difficult subject -- avoid
transformation errors in many circumstances.

If your receiver is doing SBAS (EGNOS I'd guess), then your coordinates
are not in WGS84 but in the EGNOS reference frame.  If your receiver is
not doing SBAS and is receiving multiple constellations, then which
frame it's in is a really good questionn for the receiver manufacturer.
However, the answer seems to be that all of thsese are more or less
equal to ITRF2008 at the few mm level so it's mostly academic.

If your receiver is doing RTK, then it's in the RTK base station's
frame.  But it will then likely apply EGM96 to the HAE in that frame.
In the US, RTK is usually in NAD83, and using EGM96 with NAD83 HAE is
basically a wrong thing to do.

EGM96 is a geoid model published by the US NGA, and it's fairly coarse.
EGM2008 is current.  Receivers typically don't have the full models and
use a reduced-resolution grid.  They typically output the geoid
separation in an NMEA sentence, and when I've dug into this the value
they are using can be several meters off.  This was true even for an
F9P.

Your receiver is surely computing an XYZ position, which is an
~error-free transform lat/lon and ellipsoidal height.  If you are able
to log the raw data before EGM96 and use the ellipsoidal height you will
be better off accuracy wise.

I am heading to, in NMEA, recording the geoid height reported and
backing that out and storing HAE.

I hope this helps, even if only to realize your problem is harder than
you might have thought.

Greg
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 194 bytes
Desc: not available
URL: <http://lists.osgeo.org/pipermail/proj/attachments/20210325/51f33246/attachment.sig>