Re: [Geojson] vertical datum definition

["Hedley, Mark" <[e-mail]>]

Hello Sean

many thanks for sharing your perspective with us

I also suspect that while a lot of GeoJSON is not using elevation, I also suspect that most use of elevation is with respect to what most people think it means, mean sea level, and not with respect to a specified and slightly divergent (from common use) vertical datum.

I think there is a sensible approach to explore where the specification text is altered under change management to indicate that
"An OPTIONAL third-position element SHALL be the height in meters above or below the EGM2008 geoid vertical datum, the height is defined with respect to the EGM2008 vertical coordinate reference system (providing close approximation to altitude above global mean sea level)."

I don't know how useful it would be to include footnotes or references within an errata suggestion text, perhaps better to place info in the justification for consideration by specification owners (errata notes)

Some sort of note indicating the change and drawing the attention to the long standing use of the WGS84 vertical datum might be helpful, such as in a foot note.
Noting that the differences between WGS84 & EGM2008 are position dependent (particularly affected by latitude) may be useful, as highlighted in  my earlier mail.
EGM2008 and earlier EGMs such EGM96 are derived from the WGS84 with extensive corrections from the WGS84 oblate spheroid to a the gravimetric geoid.

There is specification information within the EPSG registry on both the EGM2008 vertical datum:
https://epsg.org/crs_3855/EGM2008-height.html
and on the compound of WGS84 latitude longitude with EGM2008 altitude
https://epsg.org/crs_9518/WGS-84-EGM2008-height.html

If I raise an RFC errata proposal, will that find its way to this community easily?
i have gone ahead and posted an errata proposal:
https://www.rfc-editor.org/errata/eid7261

i look forward to exploring this errata with the community

many thanks
mark

________________________________________
From: Sean Gillies <[e-mail]>
Sent: 07 December 2022 17:31
To: Hedley, Mark
Cc: [e-mail]
Subject: Re: [Geojson] vertical datum definition

You don't often get email from [e-mail]. Learn why this is important<https://aka.ms/LearnAboutSenderIdentification>

This email was received from an external source.   Always check sender details, links & attachments.

Hi Mark,

Apologies for the late reply. I, too, suspect that users are widely interpreting elevation as relative to sea level (if they use elevation at all, this is a minor feature of GeoJSON) and am interested in exploring an elevation retro-fit. What you propose is consistent with, for example, https://developers.google.com/kml/documentation/altitudemode#absolute<https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdevelopers.google.com%2Fkml%2Fdocumentation%2Faltitudemode%23absolute&data=05%7C01%7Cmark.hedley%40metoffice.gov.uk%7C4518685cbb4340f7453f08dad878df5d%7C17f1816120d7474687fd50fe3e3b6619%7C0%7C0%7C638060310902901496%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=drJg2Yb1d243BTzb08wonBHbM8i7AiYmGFkA4BvAm%2BE%3D&reserved=0>, yes? GeoJSON has always shared some essential qualities with KML.

There is an RFC errata process, and it might be suited for making an elevation change.

Yours,

On Sat, Oct 15, 2022 at 3:37 PM Hedley, Mark <mark.hedley=[e-mail]<mailto:[e-mail]>> wrote:
Hello GeoJSON community

I would like to raise a risk regarding spatial referencing within the GeoJSON RFC specification

is this email the correct contact point for such queries?

(RFC 7946: The GeoJSON Format (rfc-editor.org<https://eur01.safelinks.protection.outlook.com/?url=http%3A%2F%2Frfc-editor.org%2F&data=05%7C01%7Cmark.hedley%40metoffice.gov.uk%7C4518685cbb4340f7453f08dad878df5d%7C17f1816120d7474687fd50fe3e3b6619%7C0%7C0%7C638060310902901496%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=Kyo0KXN53I6oC09VWmpRhlgDt7m2qtGRMNR2BrWfcpc%3D&reserved=0>) https://www.rfc-editor.org/rfc/rfc7946<https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-editor.org%2Frfc%2Frfc7946&data=05%7C01%7Cmark.hedley%40metoffice.gov.uk%7C4518685cbb4340f7453f08dad878df5d%7C17f1816120d7474687fd50fe3e3b6619%7C0%7C0%7C638060310902901496%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=TAbZyTXJEkNgiUPZXiyRCDaVx12eoHZvdKVMoCfLpuw%3D&reserved=0>)
```
   The coordinate reference system for all GeoJSON coordinates is a
   geographic coordinate reference system, using the World Geodetic
   System 1984 (WGS 84) [WGS84] datum, with longitude and latitude units
   of decimal degrees.  This is equivalent to the coordinate reference
   system identified by the Open Geospatial Consortium (OGC) URN
   urn:ogc:def:crs:OGC::CRS84.  An OPTIONAL third-position element SHALL
   be the height in meters above or below the WGS 84 reference
   ellipsoid.  In the absence of elevation values, applications
   sensitive to height or depth SHOULD interpret positions as being at
   local ground or sea level.
```

This clearly states that all heights are in metres and with respect to the WGS84 datum reference ellipsoid

The WGS84 ellipsoid is quite divergent from measured mean sea level as standardised by regional and local mapping organisations, especially at higher mid-latitudes

for example,
At 50.2° of latitude the delta between WGS84 and mean sea level is 53.4 metres

using (50.218 -5.327) as a sample location UK

So, it seems to me that any height provided within a GeoJSON payload is almost certainly not what might be expected (by the standard), as local altitude above standardised mean sea level is almost always used by data creators and the standard specifies that this needs to be adjusted to a height with respect to WGS84 (a non-trivial calculation).

But, lots of data providers likely don't know this nor understand that there are location dependent significant deviations, and so may well assume that elevation means altitude above mean sea level and provide the perceived useful number, but not to the standard.

So, as a data consumer, do i code to the spec? do i second guess based on assumptions of common usage?

An ~50 metre height difference is really significant, especially for use in aviation, sea level monitoring, ... etc.

There is an internationally standardised vertical datum built for exactly this purpose: EGM2008

EGM2008 is very suitable for use as a consistent global height datum. It is the “official” geoid model associated with the WGS84 datum. EGM2008 (and other models) attempt to realise a “mean sea level” based height but, of course, this will not exactly match legacy MSL based systems such as Newlyn (UK OSGB mean sea level datum).

It seems to me that EGM2008 could have been used within GeoJSON to make the spec very closely relate to common usage (with deltas in the mm-cm range);

But, the GeoJSON spec chose not to use this, instead standardising on the WGS84 highly approximated datum as the single way that height is encoded in GeoJSON

This is a real barrier to adoption of GeoJSON for most environmental data that my organisation uses.

Is there any opportunity to assess this facet of the GeoJSON specification alongside actual usage and assess whether the specification could & should be changed?

I am making the assumption that most creators of GeoJSON data have assumed that height is with respect to recognised mean sea level and that retro-fitting a more useful and appropriate datum to the specification would be a tangible benefit

I absolutely recognise that there may well be data that is correctly encoded with respect to the specification, taking account of differences between WGS84 datum and mean sea level, and that significant impact management would be needed in considering a specification change.

However, in its current form the issue of vertical datum difference and the risk of assuming that the specification has been correctly implemented, or that it has been assumed to be always with respect to mean sea level is so great, that this format is essentially unusable within the Earth Science community in my organisation's view.

Given that the Met Office is UK based, and the deltas between WGS84 and EGM2008 are so large (~50m) this is a particularly significant problem for us, which may not be quite so appreciated within organisations managing Earth Science data at more equatorial latitudes.

Are the GeoJSON community able to engage with us on this topic?

many thanks
Mark Hedley
Data Architect
Met Office
UK

_______________________________________________
GeoJSON mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/geojson<https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fgeojson&data=05%7C01%7Cmark.hedley%40metoffice.gov.uk%7C4518685cbb4340f7453f08dad878df5d%7C17f1816120d7474687fd50fe3e3b6619%7C0%7C0%7C638060310902901496%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=xSavMWxrlL774A0Mxqp6r6PMOoroHTFlDWhSgcyG0g0%3D&reserved=0>


--
Sean Gillies