[PROJ] Strange values with NAVD88

[Javier Jimenez Shaw]

Wow. Thank you very much, Even and Greg. I was not expecting such a long
and detailed explanation/discussion.

My bigger surprise when I looked at the data was the 1m height difference.
The "america geoids" I was checking were the NGA ones, like Geoid2018,
geoid12b and so on. Not EGM96 or 2008. Now I understand that the difference
comes from the transformations used, with a Helmert transformation or not.
Now I have much more clear the impact of the different datums in the WGS84
ensemble. I knew about the topic due to a previous email from Even in this
list. But didn't go deep until now.

My final use case is C++ transformation. More exactly via GDAL, using
"OGRCreateCoordinateTransformation" and "Transform". There you do not have
that many options. I assume that cs2cs is similar to that.
The final problem I am facing is that data is usually tagged as WGS84.
That's all. I would be very happy (and surprised) if ,for instance, a drone
with RTK is telling the user that the coordinates are in WGS84(G1762).

As you mentioned, with EPSG:4326 you cannot expect sub-metre accuracy.

Let's see how it goes with the "North American Terrestrial Reference Frame
of 2022 (NATRF2022)" + NAPGD2022 ... in a couple of years ;)

Thanks again.
Javier
.___ ._ ..._ .. . ._.  .___ .. __ . _. . __..  ... .... ._ .__
Entre dos pensamientos racionales
hay infinitos pensamientos irracionales.



On Sat, 31 Oct 2020 at 15:45, Greg Troxel <gdt at lexort.com> wrote:

>
> Stepping back, some complexities, some of which need to addressed with
> EPSG (once someone(tm) has dug in enough to be sure what to ask for).  I
> realize some of this has been discussed before; hoping it is helpful for
> Javier.
>
>   NADCON5 would be a big help.
>
>   EPSG database currently seems to not include a number of NAD83ish
>   things, including the notion that you can convert among any NAD83
>   flavor with a null transform, and this conversion is better than any
>   transform involving WGS84.
>
>   The current NAD83 label is not obviously NAD83(1986), at least to
>   people who are not already well read in NAD83.
>
>   NAD83 isn't listed as a datum ensemble.
>
>   It's not clear how a datum ensemble should be handled when there are
>   2D and 3D CRSs in the same family.  Perhaps two of them, one 2D and
>   one 3D.  Maybe NAD83 is the only ensemble that isn't all the same
>   kind.
>
>   Perhaps proj should somehow have a validity flag for the third
>   coordinate and throw errors if someone provides coordinates with the
>   third value present as an input for a CRS which is 2D.
>
>   As discussed before, accuracy values for transforms in EPSG are
>   imported into EPSG at face value, and thus cannot be compared against
>   each other.  Doing this right is hard, but seems necessary for proj's
>   transform-search approach to be sound.
>
>   I realize proj doesn't really want to go down this path, but it would
>   be nice to be able to have proj add transforms/etc. locally that
>   aren't in EPSG but should be.  There's a "too much work" aspect, and
>   then there's perhaps a licensing issue, perhaps not.
>
>
> I will try to understand the "NAD83 in EPSG" situation once I get caught
> up on proj updates in pkgsrc.  That's probably the best way to get
> improvement for hours spent as a first step.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/proj/attachments/20201101/fccb2dbb/attachment.html>