[PROJ] Altitude

[Javier Jimenez Shaw]

Thanks Greg. I didn't want to frighten Roger at the first chance ;)

When you say "In the US, RTK is usually in NAD83", is it NAD83(2011)? Is
there any base station using a different (older) reference?

Connected to this... is there any information in the NTRIP protocol that
tell you the coordinate reference system used? I was not able to find that.
It would be very useful if I am using the same device in Europe, USA, or
wherever, that the RTK correction protocol tells me the coordinate
reference system used for the outputs.

Cheers,
Javier
.___ ._ ..._ .. . ._.  .___ .. __ . _. . __..  ... .... ._ .__
Entre dos pensamientos racionales
hay infinitos pensamientos irracionales.



On Thu, 25 Mar 2021 at 13:57, Greg Troxel <gdt at lexort.com> wrote:

>
> 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
> _______________________________________________
> PROJ mailing list
> PROJ at lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/proj
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/proj/attachments/20210325/8c1c4553/attachment-0001.html>