Javier Jimenez Shaw <[email protected]> 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.) _______________________________________________ PROJ mailing list [email protected] https://lists.osgeo.org/mailman/listinfo/proj
