Subject: [Geojson] "coordSys" member extension?

From: Lorand Kedves <[email-masked]>
Date: Tue, 1 Dec 2020 08:09:50 +0100

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?

Thank you
  Lorand Kedves

---

From: Allan Doyle <[email-masked]>
Date: Wed, 2 Dec 2020 09:48:51 -0500

On Dec 1, 2020, at 2:09 AM, Lorand Kedves <[email-masked]> 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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/geojson