[PROJ] Strange values with NAVD88

[Greg Troxel]

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

First, I don't mean to contradict Even, but I will caution you that Even
is speaking from the viewpoint of proj and the EPSG databse,which is a
highly sensible place to be speaking from, especially on this lst.  I am
coming from a farther-from-proj perspective that might be described as
NGS-like.  (I do not speak for NGS; I'm just a reader of their
publications.  But I think if you asked them, they might say similar
things.)

> Doing some tests with NAVD88 (EPSG:5703), I got some unexpected results.
> See the next 5 commands
>
> a) echo 40.69 -75.04 0 | PROJ_NETWORK=ON cs2cs EPSG:4979 EPSG:4269+5703 -d 9
>      40.689991531 -75.039999022 35.046181369

So 4979 is WGS84 as a Geodetic3D CRS.  It is important to realize that
this is a a "datum ensemble", even if the proj you are using doesn't do
that yet, and formally this means an unspecified member of the set or
realizations of WGS84, including WGS84(TRANSIT) through WGS84(G1762).
Once you start off like this you don't get to complain about 2m.
TRANSIT is essentially NAD83 and G1762 is esentially ITF2008.

ESGS:4269 is NAD83.  My best guess is that this means NAD83(1986), vs
NAD83(ensemble), which seems not to have a codepoint yet.  5703 is
NAVD88, and we don't really have to deal with multiple of those.

Note that NAD83(1986) is really only 2D.

I therefore expect a null transform from 4979 to 4269, both in lat-lon
and in HAE.

here, you are transforming "WGS84 HAE" to NAV88.  Given the ensemble,
it's hard to say what that means.

I cannot explain the horizontal difference.  As I understand proj
doctrine, no transform is supportable here.

> b) echo 40.69 -75.04 0 | PROJ_NETWORK=ON cs2cs EPSG:4979 EPSG:4152+5703 -d 9
>      40.689991800 -75.039998369 35.046181369

4152 is NAD83(HARN).  In practice (and I mean for real, not as proj
computes it) this should be extremely close to NAD83.  For your
coordinates NGS estimates ~10cm shift from NAD83(1986) to NAD83(HARN).
See

  https://www.ngs.noaa.gov/NCAT/

and notice the datum choices are

  NAD83(2011)
  NAD83(NSRS2007)
  NAD83(FBN)
  NAD83(HARN)
  NAD83(1986)
  NAD27
  USSD

A huge part of the issue, the elephant that I keep shouting about, is
that one of the WGS84 ensemble members, WGS84(TRANSIT), is basically
equal to NAD83(1986), and while later NAD83 are very close to original
NAD83, later WGS84 are not close to WGS84(TRANSIT).

It's a really good question what's going on here about different
horizontal coords.

> c) echo 40.69 -75.04 0 | PROJ_NETWORK=ON cs2cs EPSG:4979 EPSG:6318+5703 -d 9
>      40.690000000 -75.040000000 33.784496002

This is NAD83(2011). The difference between NAD83(HARN) and NAD83(2011)
is tiny.  Maybe 4cm horizontal for your coordinates and 5cm for HAE.
Use NCAT and see for yourself.

> d) echo 40.69 -75.04 0 | PROJ_NETWORK=ON cs2cs EPSG:4979 EPSG:4152 -d 9
>      40.690000000 -75.040000000 0.000000000

This is NAD83(HARN), as a 2D system, so the altitude is not changed.
And it's still believing the WGS84==NAD83, bceause the oldest of each
realization basically matches, even though ~nobody has any actual data
in WGS84(TRANSIT).

> e) echo 40.69 -75.04 0 | PROJ_NETWORK=ON cs2cs EPSG:4957 EPSG:4152+5703 -d 9
>      40.690000000 -75.040000000 33.786615753

This is starting from HARN and going to HARN+NAVD88.  This is now making
sense to get a different elevation.   The basic issue is that  the
position of the NAD83  ellipsoid is different (origin) than the modern
ITRF/WGS84(G1762) ellipsoid.  So NAVD88, intended to sort of be sea
level in the US, but not really, differs from  the "WGS84 orthometric
height", which is sort of the global equipotential.

In the US, there are two kinds of geoid models:

  NAD83 to NAVD88, used within the US national datum world, eg
    https://www.ngs.noaa.gov/GEOID/GEOID18/
  defined by NGS

  WGS84 HAE to WGS84 orthometric height, defined by NGA
    https://earth-info.nga.mil/GandG/wgs84/gravitymod/egm2008/

and NAD83 HAE and WGS84(modern) HAE are different.

> Comparing b) and d), why are XY coordinates changed when NAVD88 is
> included? It is the same using EPSG:4957 instead of EPSG:4152 in d). I

That's a really good question.

> thought that NAD83(HARN) and WGS84 were considered the same. If it is

No, they really aren't considered the same. But proj has a notion that
they are because one member of the WGS84 ensemble matches.

> considering that the normal to the ellipsoid and the geoid are not the
> same, why have d) and e) the same XY coordinates (see that the source in e)
> is NAD83(HARN), not WGS84)?

proj tends to assume that NAD83 == WGS84.

Yes, ellipsoidal and geoid normals are not the same.  I guess it's a
really good question what a combined horizontal and orthometric height
CS means.  I would still expect the XYZ of the point to be reduced to
lat/lon along the ellipsoidal normal even if vertical is orthometric
height.

> In c), the altitude has more than 1 meter difference. Why? Am I doing or
> assuming something wrong? Checking all the american geoids in this area in
> cdn.proj.org, there are no more than a few centimeters difference.

By "american geoid", do you mean GEOID12 and GEOID18, or are you also
admitting the military geoid model EGM2008?  (Hint: NGS and NGA, while
I'm sure they talk to each other, are different worlds.)

> I do not know if it is related, but I have only seen ballpark (horizontal)
> transformations between NAD83(HARN) and NAD83(2011). Is that correct? I was
> expecting some transformation, either direct or a grid.

There should be a grid transform. See NCAT that I linked above.  It is
entirely possible that this precision of NGS transform is not yet
incorporated in proj.  It is pretty fair to assume NAD83(HARN) to
NAD83(2011) is a null transform, and probably at the 10 cm level this is
ok.  As with all things NAD83, and many things in American life, things
are more stable if you aren't in California.


Overall my advice is to stop using datum ensembles, particularly WGS84.
If you do use WGS84, then you should realize that everthing you are
doing has ~2m of fuzz and be unconcerned about numerical differences of
that order, including in heights.


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 194 bytes
Desc: not available
URL: <http://lists.osgeo.org/pipermail/proj/attachments/20201030/3b3e7650/attachment.sig>