Re: [Geojson] "coordSys" member extension?

Allan Doyle <adoyle@intl-interfaces.com> Wed, 02 December 2020 14:48 UTC

Return-Path: <adoyle@intl-interfaces.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 E22393A1437 for <geojson@ietfa.amsl.com>; Wed, 2 Dec 2020 06:48:55 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level:
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=intl-interfaces.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fYl0fxxEirj3 for <geojson@ietfa.amsl.com>; Wed, 2 Dec 2020 06:48:54 -0800 (PST)
Received: from mail-qk1-x72e.google.com (mail-qk1-x72e.google.com [IPv6:2607:f8b0:4864:20::72e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 210AF3A1435 for <geojson@ietf.org>; Wed, 2 Dec 2020 06:48:54 -0800 (PST)
Received: by mail-qk1-x72e.google.com with SMTP id z188so1373002qke.9 for <geojson@ietf.org>; Wed, 02 Dec 2020 06:48:54 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=intl-interfaces.com; s=google; h=from:message-id:mime-version:date:subject:in-reply-to:to:references; bh=Ln9LdzCShczypYb73OcsvkSsYhp2TmJKpRdzKt1a9dA=; b=dvTS3abrVMTnttwmaC46BrnP3pHMrrSm4tY1f3OgXLb0gWopfzrx8RNIoCg4rSmpo1 p2kAgA+f2aN4eeCr4Jtiy4ZNzkKKcO5E3u8XAkLzq0XnAjc/Q9EIfh4nO81YAJSkJSZd ZlyGsQSRNWgZVTDx9+axgwTDHhTWd422Uhz2o=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:date:subject :in-reply-to:to:references; bh=Ln9LdzCShczypYb73OcsvkSsYhp2TmJKpRdzKt1a9dA=; b=LJ0hjCuQLKZuEKDLeMd0SuNzXftMeQkCgcwRXfoao4W/IvmudtUWbKvE1BBQhWtBgl 4icdCKXSPvAJroyfFbeQ/HA+bD6ZSbziqiAwQ2ruJpbiWtCT4AuSt0eBO6N34moy6VCl SZNhLX3cgJYpYlULYHG4MJxb7vT4TVYrewFHc84bAwH4TZbGMvererNtwZ+QPsHVzvYt apkHm4aqeCcp3m5FQE6yf7DqfoJgYIAeFouNH6zd6kqQTeMTJV8x/5PMyFzIOa5cNWhb vC3AJ1luNkZl6yRUoWBTJZlQcteW6UuRhb9IawN1s/JI+MA58HZrFdrBetF+WVfoK2O0 iK0g==
X-Gm-Message-State: AOAM533EZdOiknBjRcXMS8DJYjRDP9AVRCwcm1q7dLkkB3ztOgYQovKP Qp/bkHqOt6UKlAQNel4jCyurs0/z7aK99A==
X-Google-Smtp-Source: ABdhPJyKb9JhFmDOLSjl334EdEVlD77eBlfGg8NYcNl3S77+ss5pJzBltPO3IvQt3GBKHjbzwkW/DA==
X-Received: by 2002:a05:620a:2189:: with SMTP id g9mr2912197qka.488.1606920532936; Wed, 02 Dec 2020 06:48:52 -0800 (PST)
Received: from [192.168.1.10] (pool-173-48-213-27.bstnma.fios.verizon.net. [173.48.213.27]) by smtp.gmail.com with ESMTPSA id w31sm2093237qth.60.2020.12.02.06.48.52 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Wed, 02 Dec 2020 06:48:52 -0800 (PST)
From: Allan Doyle <adoyle@intl-interfaces.com>
Message-Id: <65C4FFD4-6E4A-4AE0-BC40-73D93FE56BB5@intl-interfaces.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_9443E8A4-976B-41F6-9765-0679DF96E495"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\))
Date: Wed, 02 Dec 2020 09:48:51 -0500
In-Reply-To: <CAJrogBG1OygMxgPo343QSA=rU+A9iFLpLgafdhxEAjqnyxwf2w@mail.gmail.com>
To: geojson@ietf.org
References: <CAJrogBG1OygMxgPo343QSA=rU+A9iFLpLgafdhxEAjqnyxwf2w@mail.gmail.com>
X-Mailer: Apple Mail (2.3608.120.23.2.4)
Archived-At: <https://mailarchive.ietf.org/arch/msg/geojson/KtphUfyLwL1XVzHfIPnqNhxgu5Y>
Subject: Re: [Geojson] "coordSys" member extension?
X-BeenThere: geojson@ietf.org
X-Mailman-Version: 2.1.29
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: Wed, 02 Dec 2020 14:48:56 -0000

On Dec 1, 2020, at 2:09 AM, Lorand Kedves <lorand.kedves@gmail.com> wrote:
> 
> Dear GeoJSON Board,
> 
> 
> We created a management interface to a system with ~1GB of data, using GeoJSON to server-client interaction and integration I/O was very convenient and we could rely on sophisticated tools. (Thank you!)
> 
> However, the system used a different native coordinate system. Converting all data to WGS84 and back all the time was not feasible (displaying and saving data should be done in the system native coordinate system). We decided to still use GeoJSON as a transfer format, although the actual values were invalid. At the UI, the display component required this conversion to get valid GeoJSON. I added a "coordSys" member to the GeoJSON Object, set it to the native id on the server and used a stock tool to in-place convert the received coordinates data on load. 
> 
> I think this optional extension is useful: allows systems to use their coordinate systems, they are responsible for the conversion but still can produce valid GeoJSON. I am quite sure you had already considered and rejected this idea. What was the problem with it?
> 

https://tools.ietf.org/html/rfc7946#section-4 <https://tools.ietf.org/html/rfc7946#section-4>

"In general, GeoJSON processing software is not expected to have access to coordinate reference system databases or to have network access to coordinate reference system transformation parameters.  However, where all involved parties have a prior arrangement, alternative coordinate reference systems can be used without risk of data being misinterpreted."

You're using a prior arrangement to use an alternative coordinate system and the general users of GeoJSON are not burdened with having to access transformation parameters/databases or do transformations. Note that the spec doesn't say "...MAY be used...", it says "...can be used..." so the spec might be hinting you can do what you're doing as long as you don't call the data valid GeoJSON.

If this were an optional extension, universality would suffer because of the difficulty in dealing with coordinate transformations. I think I speak for all the GeoJSON authors if I say that we were acutely aware of the dangers of introducing underlying complexity that would impede the use of the format.


> Thank you
>   Lorand Kedves
> _______________________________________________
> GeoJSON mailing list
> GeoJSON@ietf.org
> https://www.ietf.org/mailman/listinfo/geojson