<div dir="ltr"><div>Wow. Thank you very much, Even and Greg. I was not expecting such a long and detailed explanation/discussion.</div><div><br></div><div>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.</div><div>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.</div><div><br></div><div>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.<br></div><div>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).</div><div><br></div><div>As you mentioned, with EPSG:4326 you cannot expect sub-metre accuracy.</div><div><br></div><div>Let's see how it goes with the "North American Terrestrial Reference Frame of 2022 (NATRF2022)" + NAPGD2022 ... in a couple of years ;)<br></div><div><br></div><div>Thanks again.</div><div>Javier<br></div><div><div><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature">.___ ._ ..._ .. . ._.  .___ .. __ . _. . __..  ... .... ._ .__<br>Entre dos pensamientos racionales <br>hay infinitos pensamientos irracionales.<br><br></div></div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sat, 31 Oct 2020 at 15:45, Greg Troxel <<a href="mailto:gdt@lexort.com">gdt@lexort.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br>
Stepping back, some complexities, some of which need to addressed with<br>
EPSG (once someone(tm) has dug in enough to be sure what to ask for).  I<br>
realize some of this has been discussed before; hoping it is helpful for<br>
Javier.<br>
<br>
  NADCON5 would be a big help.<br>
<br>
  EPSG database currently seems to not include a number of NAD83ish<br>
  things, including the notion that you can convert among any NAD83<br>
  flavor with a null transform, and this conversion is better than any<br>
  transform involving WGS84.<br>
<br>
  The current NAD83 label is not obviously NAD83(1986), at least to<br>
  people who are not already well read in NAD83.<br>
<br>
  NAD83 isn't listed as a datum ensemble.<br>
<br>
  It's not clear how a datum ensemble should be handled when there are<br>
  2D and 3D CRSs in the same family.  Perhaps two of them, one 2D and<br>
  one 3D.  Maybe NAD83 is the only ensemble that isn't all the same<br>
  kind.<br>
<br>
  Perhaps proj should somehow have a validity flag for the third<br>
  coordinate and throw errors if someone provides coordinates with the<br>
  third value present as an input for a CRS which is 2D.<br>
<br>
  As discussed before, accuracy values for transforms in EPSG are<br>
  imported into EPSG at face value, and thus cannot be compared against<br>
  each other.  Doing this right is hard, but seems necessary for proj's<br>
  transform-search approach to be sound.<br>
<br>
  I realize proj doesn't really want to go down this path, but it would<br>
  be nice to be able to have proj add transforms/etc. locally that<br>
  aren't in EPSG but should be.  There's a "too much work" aspect, and<br>
  then there's perhaps a licensing issue, perhaps not.<br>
<br>
<br>
I will try to understand the "NAD83 in EPSG" situation once I get caught<br>
up on proj updates in pkgsrc.  That's probably the best way to get<br>
improvement for hours spent as a first step.<br>
<br>
</blockquote></div>