[PROJ] Unexpected no NADCON5 transformations

[Greg Troxel]

Javier Jimenez Shaw <j1 at jimenezshaw.com> writes:

> The problem is that many data providers "use" WGS84 (as you know, I am not
> a fan of it).

I think you will have to remediate the provider's use of an ensemble by
relabeling to WGS84(G2159) or equivalently ITRF2014, and then transform
selection will (should...) make more sense.  Very likely the data is not
actually in an ensemble :-)

> In some cases with a vertical CRS, sometimes without. NMEA messages
> directly include a geoid height in the elevation (I do not know which
> model they use, really).

I dug into this earlier, and the quick summary is:

  WGS84 Ellipsoidal Height is well defined (for any realization)

  WGS84 Orthometric Height is also well defined.  I think it's height
  above the reference surface actually, but in practice it is the height
  as computed from HAE by a specific geoid model which varies by
  realization.  Recent realizations specify EGM2008, and EGM2020 is
  threatened to arrive soon.  Early realizations specify EGM96.

  NMEA gives the elevation (height above geoid) and the geoid
  separation.  But in practice the receiver first computes HAE, and then
  does a lookup of geoid separation using a receiver-specific coarse
  model.  As far as I can tell almost all navigation-type receivers,
  even things that you might expect to be better like the u-blox F9P,
  use a 15 degree (degree not minute!!) version of EGM96, which can
  differ by 4m from the reference full-term EGM2008 model, at least
  around me (Boston).  Most of the difference is due to coarse
  interpolation rather than the improved model in EGM2008; the full
  EGM96 model is vastly closer.  It then subtracts the two to get
  elevation, thus imposing the error in the geoid model lookup on the
  elevations.  Nobody notices because autonomous or even WAAS elevations
  are poor, and survey usage avoids this, it seems to me.

  One can back out the reported geoid separation from the altitude to
  get HAE, and then go from there, processing more reasonably.  And, if
  wanting NAVD88 not use EGM96/EGM2008 at all.  (I am unaware of
  transforms from WGS84 Orthometric Height to NAVD88, other than going
  to WGS84 HAE, then NAD83(2011) HAE, and then via a hybrid geoid
  e.g. GEOID18 to NAVD88.)

  IMHO the only sane thing to do if you care about height being right is
  to immediately back out the receiver's geoid model and then ignore
  that model.


I do wonder if using WGS84+some_height is causing different processing
when transforming, because NAD83(1986) is a 2D CRS, while later NAD83
are 3D.  But I can't give any coherent rationale at the moment.

> So if the firmware wants to use ellipsoidal heights, has to explicitly
> do the maths (if I am wrong here, I will appreciate an
> explanation). That makes us "assume" that some devices provide
> coordinates in EPSG:4979, and some in EPSG:4326+5773.

With caveats, yes:

  All receivers that speak NMEA I have seen have a very poor version of
  EGM96.

  Surveying practice seems to be to use XYZ or LLh directly, not via
  NMEA.  But you are talking about NMEA.

  <rant>No receiver provides actually coordinates in the WGS84 ensemble.
  They provide coordinates in the realization currently in use by the
  control segment, if doing autonomous positioning.  From the date the
  data was collected, you can determine the particular realization.</>

  Most receivers are multi-constellation, and I have not seen any
  detailed, believable information about how they do datum processing.
  My default assumption is that they basically operate in recent WGS84
  == recent ITRF == recent Galileo ~== recent BDS frames, with a known
  transform to recent PZ90, but that is me guessing.  <rant>Yet, people
  still attribute this output as WGS84(ensemble).</>

  Receivers are often using SBAS, in which case coordinates are no
  longer in WGS84, but in the reference frame of the differential
  service, which is typically some recent ITRF, but often hard to pin
  down, at least for the US WAAS.  (RTK is of course in a variety of
  frames, as a fundamentally differential technique.)