Re: [Geojson] vertical datum definition

Howard Butler <howard@hobu.co> Sun, 16 October 2022 14:52 UTC

Return-Path: <howard@hobu.co>
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 D20C7C14CF19 for <geojson@ietfa.amsl.com>; Sun, 16 Oct 2022 07:52:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.908
X-Spam-Level:
X-Spam-Status: No, score=-1.908 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=hobu-co.20210112.gappssmtp.com
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 6q1PLgr1gErJ for <geojson@ietfa.amsl.com>; Sun, 16 Oct 2022 07:52:30 -0700 (PDT)
Received: from mail-il1-x135.google.com (mail-il1-x135.google.com [IPv6:2607:f8b0:4864:20::135]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 55F81C14CF0F for <geojson@ietf.org>; Sun, 16 Oct 2022 07:52:30 -0700 (PDT)
Received: by mail-il1-x135.google.com with SMTP id 8so4749998ilj.4 for <geojson@ietf.org>; Sun, 16 Oct 2022 07:52:30 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hobu-co.20210112.gappssmtp.com; s=20210112; h=to:references:message-id:content-transfer-encoding:cc:date :in-reply-to:from:subject:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=5zQU3XnDlYj8iT/zs5a02eb89lrSEs/vh8kmkqZrPjY=; b=WJ46WHmwH+KToYked507XzlyQnspp62QNxN6BHTDC2PG3EXseWWfJJqYJqIy7A2ruE 8bT2esDXtegINlQv7UPM/HWAt+KRHABXTG2mw8Ft/pI0PcJAb4YYeiL5aDZ28+YOSIDj BYYXmadEMO+C1A0wzgd9gFZGfTaP7QIxuMffckKqiQHpbSnYZ0Y6+jTxy9yNHsr2DfuP nRCgOaw3VKtSYu+7lUPJA4CGYDu+lwHRUwwuIC23qu87rduvS/IDV4DIBUP1W2GLSjxQ o0RSD+QXxDb/fYTHEaJqyc3zTO9CISNAIumbYfaWfF4/dpxNG7wSH+sagFsV3LaARpJ9 6Ntg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=to:references:message-id:content-transfer-encoding:cc:date :in-reply-to:from:subject:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=5zQU3XnDlYj8iT/zs5a02eb89lrSEs/vh8kmkqZrPjY=; b=q8wh/9+ako6yOHeoYdf1YsbETLLHc1UkpXX6NSQUMrz0vsHykwsmR90L7rz8YzhWgX 4jiH9dlKu+oM8ChgFbbxIfvlU1EwhsaB3+6Ij1Q/ASkRU7cCvjiIq+ze0vx6YAPSo+WH +/XifR9i+f7hiG81qhBWgQFMJ08Gq+DbWeVIRMFR2K4avye8K0JDQVp2HatRKe4c2Z/1 OUnfOGyT3AZ2LN5islZsQUV4T1sws/Gc0wtTUiauWw0aeUFOblnkKeJj0NkHytbdl8NY wOTj91kuhSUJz7HIot2y76DiWYRnh4LGPukzFtExUB+NHPJGf90fbefV533+S81s5Vyk JDsg==
X-Gm-Message-State: ACrzQf0AlueQChioZt8ZGMbAq3PwA8Y+uCSzNW4WwtexgA8berMD4n58 ELMd5R5Z0PnoBtXUJ70MV8SSbVfmeUPO2w==
X-Google-Smtp-Source: AMsMyM79xjtTdY3OxvPNxGLlSsAlwlNgqIxHRQeJeqW+1Aph8Wz1WIilvAFJu0EEyXhD6gR0NggxfQ==
X-Received: by 2002:a05:6e02:15c9:b0:2da:c33e:49c7 with SMTP id q9-20020a056e0215c900b002dac33e49c7mr2892044ilu.26.1665931949486; Sun, 16 Oct 2022 07:52:29 -0700 (PDT)
Received: from smtpclient.apple (204-141-213-205.cgn.imoncommunications.net. [204.141.213.205]) by smtp.gmail.com with ESMTPSA id bv14-20020a056638448e00b0036384f898a0sm3335990jab.133.2022.10.16.07.52.28 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Sun, 16 Oct 2022 07:52:28 -0700 (PDT)
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3696.120.41.1.1\))
From: Howard Butler <howard@hobu.co>
In-Reply-To: <CWLP265MB3139622B41CE8A9F8916F90EC44F9@CWLP265MB3139.GBRP265.PROD.OUTLOOK.COM>
Date: Sun, 16 Oct 2022 09:52:27 -0500
Cc: "geojson@ietf.org" <geojson@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <35ED155D-B851-4567-A6F8-387BC6292CFC@hobu.co>
References: <CWLP265MB3139622B41CE8A9F8916F90EC44F9@CWLP265MB3139.GBRP265.PROD.OUTLOOK.COM>
To: "Hedley, Mark" <mark.hedley=40metoffice.gov.uk@dmarc.ietf.org>
X-Mailer: Apple Mail (2.3696.120.41.1.1)
Archived-At: <https://mailarchive.ietf.org/arch/msg/geojson/leX7EFZx6VGANPXkmD8CQfT8arA>
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: Sun, 16 Oct 2022 14:52:34 -0000


> On Sep 21, 2022, at 10:15 AM, Hedley, Mark <mark.hedley=40metoffice.gov.uk@dmarc.ietf.org> wrote:
> 

> 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.

I read this to mean (and am pretty sure we meant):

1) if you encode heights, they should be height-above-elipsoid WGS84
2) if you don't, applications should interpret them as MSL

But *which* MSL? is the question you ask. The GeoJSON specification doesn't answer that. Purposefully. As you've explained this is not satisfactory, especially for an organization that cares about the 3rd dimension and wishes to use GeoJSON as a long-term storage format. My retort is the specification authors did not want to impose geodetic description consumption and interpretation on GeoJSON users and this ambiguity is a consequence. GeoJSON is not a storage format for precisely described 3D geographic data. 

EGM2008 didn't exist when the specification was first written. WGS84 is a patchwork datum ensemble rather than a single unified datum. The geodetic world is moving to describing velocity models, and these challenges are not getting simpler to encode in data formats. All of these issues were why OGC is making OGC Feature Geometry https://www.ogc.org/projects/groups/featgeojsonswg

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


GeoJSON is more than 15 years old. That's like 75 in internet technology dog years. It's a surviver because it made simple choices, the specification examples are easy for a developer to follow, and it doesn't impose knowing finger-waving geodesy and computational geometry complexity on users who don't need to care about it. The latter is indeed sometimes a hindrance.

GeoJSON was designed to interchange OGC simple features data inside of JSON between web applications. It was not designed to be an archival data format, a high performance network interchange, or an internally organized data structure that supported spatial selectivity. 

The pre-IETF version of GeoJSON "supported" alternative coordinate references by attempting to defer them to the consumer. This hurt interoperability on the fringes in exchange for very little value because most were using WGS84 and there was no JSON-based coordinate system description specification. We have PROJJSON now, but that isn't recognized as a standard, and we're 15+ years past the creation of GeoJSON. 

I don't have a satisfactory answer for you, but I will say our instinct to prevent coordinate system complexity from being an implementor and data consumer's responsibility was validated by its widespread adoption. GeoJSON's feature matrix is not right for everyone and every application, however.

Howard