Re: [Geojson] [Technical Errata Reported] RFC7946 (7261)

[Sean Gillies <[e-mail]>]

Mark,

Martin Thomson reminded me after I sent you to
https://www.rfc-editor.org/errata.php that this issue is beyond errata. A
new RFC may be required.

I want to be certain that it's worth the effort before opening any cans of
worms. Here are a few things that concern me:

* I don't know how widely used elevation values are or how applications use
them. If people don't use them or ignore them, is it worth writing an RFC?
* Are people who want more precision going to ditch GeoJSON for the OGC's
Feature JSON anyway for this or other reasons? If so, is it worth writing
an RFC?

My sense is that people are using elevation as "above mean sea level"
instead of as written in the spec, but "above ground level" might be
common, too. I honestly don't know.

On Thu, Dec 8, 2022 at 7:37 AM RFC Errata System <[e-mail]>
wrote:

> The following errata report has been submitted for RFC7946,
> "The GeoJSON Format".
>
> --------------------------------------
> You may review the report below and at:
> https://www.rfc-editor.org/errata/eid7261
>
> --------------------------------------
> Type: Technical
> Reported by: mark hedley <[e-mail]>
>
> Section: 4
>
> Original Text
> -------------
> An OPTIONAL third-position element SHALL be the height in meters above or
> below the
> WGS84 reference ellipsoid.
>
> Corrected Text
> --------------
> 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).
>
> Notes
> -----
> Vertical coordinates, where used within GeoJSON shall be interpreted as
> with respect to the EGM2008 vertical datum.  Transformations from WGS84
> vertical coordinate values to EGM2008 coordinate values shall not be
> implemented (unless by prior arrangement between involved parties) .
>
> 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
>
> Common usage of altitude vertical coordinates is with respect to mean sea
> level. However, the original text within rfc7946 state that a vertical
> coordinate is with respect to the WGS84 reference ellipsoid.
>
> The WGS84 reference ellipsoid is an oblate spheroid that only partially
> approximates mean sea level. The EGM2008 (superseding EGM96) vertical
> datum provides
> "Zero-height surface resulting from the application of the EGM2008 geoid
> model to the WGS 84 ellipsoid." (
> https://epsg.org/crs_3855/EGM2008-height.htm)
> EGM2008 closely models mean sea level as a global vertical datum.
>
> Distortions are global position dependent, discrepancies can range from
> less than a metre to 10s of metres.  For example, at a location of  (50.218
> -5.327 (WGS84)) the discrepancy between a WGS84 vertical coordinate and a
> EGM2008 vertical coordinate is 53.4 metres.
> This is a really significant vertical discrepancy for a positional
> coordinate.
>
> The update within this errata matches the specification to the widespread
> and common use of vertical position with respect to mean sea level, as
> measured by national mapping agencies and satellite earth observations.
>
> Instructions:
> -------------
> This erratum is currently posted as "Reported". If necessary, please
> use "Reply All" to discuss whether it should be verified or
> rejected. When a decision is reached, the verifying party
> can log in to change the status and edit the report, if necessary.
>
> --------------------------------------
> RFC7946 (draft-ietf-geojson-04)
> --------------------------------------
> Title               : The GeoJSON Format
> Publication Date    : August 2016
> Author(s)           : H. Butler, M. Daly, A. Doyle, S. Gillies, S. Hagen,
> T. Schaub
> Category            : PROPOSED STANDARD
> Source              : Geographic JSON
> Area                : Applications and Real-Time
> Stream              : IETF
> Verifying Party     : IESG
>


-- 
Sean Gillies