Re: [Geojson] vertical datum definition

Alexandre Petrescu <alexandre.petrescu@gmail.com> Tue, 18 October 2022 11:57 UTC

Return-Path: <alexandre.petrescu@gmail.com>
X-Original-To: geojson@ietfa.amsl.com
Delivered-To: geojson@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8BC3DC1522C7 for <geojson@ietfa.amsl.com>; Tue, 18 Oct 2022 04:57:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.66
X-Spam-Level:
X-Spam-Status: No, score=0.66 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FORGED_GMAIL_RCVD=1, FREEMAIL_FROM=0.001, NICE_REPLY_A=-0.001, NML_ADSP_CUSTOM_MED=0.9, SPF_HELO_NONE=0.001, SPF_SOFTFAIL=0.665, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=no autolearn_force=no
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E1wehRriuxQU for <geojson@ietfa.amsl.com>; Tue, 18 Oct 2022 04:57:16 -0700 (PDT)
Received: from sainfoin-smtp-out.extra.cea.fr (sainfoin-smtp-out.extra.cea.fr [132.167.192.228]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3B026C14CE2B for <geojson@ietf.org>; Tue, 18 Oct 2022 04:57:16 -0700 (PDT)
Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin-sys.extra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id 29IBvDSM042517 for <geojson@ietf.org>; Tue, 18 Oct 2022 13:57:13 +0200
Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 6C95820497C for <geojson@ietf.org>; Tue, 18 Oct 2022 13:57:13 +0200 (CEST)
Received: from muguet2-smtp-out.intra.cea.fr (muguet2-smtp-out.intra.cea.fr [132.166.192.13]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 67893204389 for <geojson@ietf.org>; Tue, 18 Oct 2022 13:57:13 +0200 (CEST)
Received: from [10.8.32.70] (is156570.intra.cea.fr [10.8.32.70]) by muguet2-sys.intra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id 29IBvD5q019913 for <geojson@ietf.org>; Tue, 18 Oct 2022 13:57:13 +0200
Message-ID: <fd94092e-dbcf-3900-8878-df19188de2ba@gmail.com>
Date: Tue, 18 Oct 2022 13:57:13 +0200
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:102.0) Gecko/20100101 Thunderbird/102.3.3
Content-Language: fr
To: geojson@ietf.org
References: <CWLP265MB3139622B41CE8A9F8916F90EC44F9@CWLP265MB3139.GBRP265.PROD.OUTLOOK.COM>
From: Alexandre Petrescu <alexandre.petrescu@gmail.com>
In-Reply-To: <CWLP265MB3139622B41CE8A9F8916F90EC44F9@CWLP265MB3139.GBRP265.PROD.OUTLOOK.COM>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/geojson/31u3xYX2hsSJnZMN_O7UimQb57c>
Subject: Re: [Geojson] vertical datum definition
X-BeenThere: geojson@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: IETF GeoJSON WG <geojson.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/geojson>, <mailto:geojson-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/geojson/>
List-Post: <mailto:geojson@ietf.org>
List-Help: <mailto:geojson-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/geojson>, <mailto:geojson-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 18 Oct 2022 11:57:20 -0000

Since the beginning of the RFC I questioned the validity of limiting the 
ref system to WGS84.

Since then, more and more products on the market use WGS84 among others.

In these products, this RFC is limited.

Alex

Le 21/09/2022 à 17:15, Hedley, Mark a écrit :
> 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://www.rfc-editor.org/rfc/rfc7946)
> ```
>     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
> GeoJSON@ietf.org
> https://www.ietf.org/mailman/listinfo/geojson