[gdal-dev] Transformations with same horizontal datum but different geoid outputs the same Z value

[Greg Troxel]

Andrew C Aitchison <andrew at aitchison.me.uk> writes:

> On Mon, 17 Oct 2022, Diogo wrote:
>
>> Hi Andrew. Thanks for taking the time to read my email and reply it.
>> I'm aware of Copernicus land and other datasets like SMRT3 and ASTER
>> however I need the best possible elevation resolution available. To do so,
>> I'm getting the elevation dataset directly from countries geographic
>> institutes and converting them into the coordinate system 4326+3855. But as
>> described in my previous email, I'm having some trouble with some geoids.
>> Do you have an idea why I'm having these transformation issues? To be
>> honest, I'm a bit lost because I can't understand it.
>
> Sorry, I know no more (and probably less) than you about the transforms.

Basically, one needs to pick a worldwide height system and then
transform data from multiple regions into it.  This is hard because

  - The only global height system I'm aware of is "WGS84 Orthometric
    Height".  One in practice accesses that via WGS84 Height Above
    Ellipsoid and the EGM2008 full-resolution gravity model.  In other
    words, WGS84 Orthometric Height is defined relative to a specific
    potential, and the geoid model is just how you get a value.

    A nuance (sorry Javier :-) is that WGS84 is an ensemble and you
    really should say "WGS84(G2159) Orthometric Height" to mean that you
    are using recent WGS84 HAE and then EGM2008.

    (If there is another global height system, I'd like to hear about it.)

  - It is often hard to find transformations from national height datums
    to WGS84 Orthometric Height.  In the US, I don't know of any.  But
    there are published geoid models from NAVD88 to NAD83 HAE, and then
    one can transform to WGS84(G2159) HAE, and then use EGM2008 to get
    WGS84 Orthometric Height.

  - You being able to find and understand transforms is one thing.  But
    them being in EPSG and being handled correctly is another.

> From what others have said, I suspect that there is no *meaningful*
> way to have better elevation resolution over such a large area than
> the Copernicus data.

I think it's likely meaningful, just way too hard.

> I do know that 4326 uses a geoid which is less accurate *over Great
> Britain* than the one the Great Britain Ordnance Survey have been
> using for a century or two (OSGB36 Datum 1936, Airy Spheriod 1830!).
> I suspect that other national geo-organisations do the same thing and
> you will lose the extra accuracy in standardising on one coordinate
> system over Europe.

I don't follow this at all.  EPSG:4326 is a 2D system, so it doesn't
even have height, and has no associated geoid.

I'm sure there is a CRS that's essentially that with HAE, but I use
ITRF2014 (EPSG:7912), to avoid the ensemble issues.

I would expect an EPSG codepoint that is WGS84 lat/lon and WGS84
Orthometic Height.  But that CRS doesn't really "use" a geoid, it's that
the transformation from WGS84(LL)+WGS84OH to WGS84(LLh) is done by
EGM2008.

If you mean that OSGB36 datum (meaning the position of the ellipsoid) is
a better fit for the geoid over GB, then that isn't really relevant
because the issue here is the error in the geoid model, not the
difference between geoid heights and ellipsoidal heights.

For example, I'm at ~ -30m geoid height, and I was able to obtain an
NAVD88 height for a benchmark via RTK GNSS in NAD83 and then using
GEOID18, and ending up within 10-20 cm of the published value (from a
mark last leveled in NGVD29).

So this is likely doable; it's probably just too much work.
-------------- 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/gdal-dev/attachments/20221017/ffd34aa5/attachment-0001.sig>