[GeoJSON] Mailman works in mysterious ways/Consequences of the GeoJSON 1.0 axis order policy

[Volker Mische]

Hi all,

On 04/12/2013 05:11 PM, Martin Daly wrote:
> Please see the message below, from Adrian Custer.
> ***********************************************************
> Subject: Consequences of the GeoJSON 1.0 axis order policy
> 
> 
> Hey all,
> 
> The scope of GeoJSON 1.0 is limited by its axis order policy. This limitation should be acknowledged explicitly in the standard or the standard should be amended with a different axis order policy.
> 
> 
> In various previous discussions and emails with several of you, I have pointed this out but I have never formally presented the issue to this list. I have been informed that this is the 'official' list so this email can act as the formal statement of the issue for archival purposes. This email is informative; it is not an attempt to bring about action within your group. Dealing with the issue is up to each of you. It seems that you are persuaded that your axis order policy works and is 'simple'; I suspect, that in actual practice, its failings fall outside of your problem domain (perhaps stated as mid-latitude, geographic scale, approximative positioning?) so you do not run into it.
> 
> Unfortunately, your axis order policy makes GeoJSON 1.0 unsuitable for use in general purpose geospatial applications, notably as an exchange format for OGC services. That is unfortunate since otherwise you have a good standard.
> 
> 
> 
> 
> The GeoJSON axis order policy appears to be stated in full in section 2.1.1:
> 
>   The order of elements must follow x, y, z order (easting, northing,
>   altitude for coordinates in a projected coordinate reference system,
>   or longitude, latitude, altitude for coordinates in a geographic
>   coordinate reference system).
>     - http://www.geojson.org/geojson-spec.html#positions (Section 2.1.1)
> 
> The GeoJSON standard also places no restrictions on the CRS definitions which can be used.
> 
> However, these two are in conflict.
> 
> 
> 
> 
> Implicitly, the axis order policy actually restricts the CRSs which can be used in GeoJSON to ProjectedCRS and Geographic CRS (the only two mentioned in 2.1.1). Assuming those two groups of projections can be unambiguously defined, there are still a whole lot of ProjectedCRSs that cannot be mapped unambiguously to 'Easting', 'Northing'; the easiest example are the polar stereographic projected CRSs which have no 'easting' and either neither or both axes map to 'northing'. Unambiguous communication requires that two parties can determine the order of the ordinates used in all coordinate tuples and lack of an unambiguous mapping prevents this. So GeoJSON is limited by the axis order policy to an ambiguous (because undefined) group of CRSs, those that can map to 'easting'/'northing' or 'long'/'lat'.
> 
> 
> 
> 
> There are, of course, multiple approaches to resolving the issue. I suspect these are split between
>  * solutions that maintain the current axis order policy and define
>    more explicitly the handling of different CRSs, and
>  * solutions that break backwards compatibility and follow the axis
>    order of the CRS.
> 
> The former group of solutions gets hard quickly.
> 
> One choice would be to define a canonical list of allowed CRSs. Given your problem domain that is probably the easiest for you and your users: you limit CRSs to a specific list or to the set of Geographic CRS's with axes called 'lat' and 'long' and Projected CRSs that use axes with 'easting' and 'northing' in the names (or some such policy). This allows full backwards compatibility and requires only a modification of the standard to document this restriction, but does acknowledge the limited scope of GeoJSON.
> 
> A more extended effort could allow more Projected CRS's by providing standardized mappings from Projected CRS's with other axis names, e.g. explaining what to do for 'southing' 'westing' projection systems, the rotated projections, and others. This would generalize GeoJSON but, as you will see after trying for a while, is exceedingly difficult to define and a pain to code against.
> 
> An earlier thread on the list raised the possibility of a hack wherein GeoJSON creators can add a field describing the mapping from CRS axis order to the axis order of the policy; however, this combines all the disadvantages: (1) the CRS order becomes canonical breaking backwards compatibility and forcing GeoJSON users need to know about those data structures, (2) the mapping system must be defined and all software must be able to process it, and (3) GeoJSON remains limited to only those CRSs that map directly to 'easting' and 'northing'. This is backwards incompatible, complicated, and restricted.
> 
> The only simple, general solution is *not* to dictate axis order and to follow the order in the CRS. This breaks backwards compatibility and places the burden on recipients to parse and handle the CRS field which is something I think you have been trying to avoid. (For elegance and ease of use by simple client code, you could have an *optional* mapping field listing the order of ordinates in the coordinate tuple that map to 'easting' and 'northing' when applicable; clients that just want a pretty picture would thereby not need to parse the CRS when using such data.)
> 
> 
> That's the breaks. On a three dimensional rock floating in space, 'easting' and 'northing' are not the only directions we end up needing. Our geodetic history also uses more than those directions. With your axis order policy, you can have a standard that is simple and restricted (although currently it does not fully explain that). With some modification, you can keep the axis order policy and have a standard that is more general but trades complexity for generality. Alternatively, you could have a standard that is simple and general, but with a different axis order policy.
> 
> 
> 
> cheers,
>   ~adrian custer
> 
> 
> P.S.
> If you have questions about this statement, email me directly and I will try to clarify. Given the history of this discussion, I suspect it may raise the blood of certain of you and I have no desire for such a discussion: arguments, explosions, and other wastes of my time will go strait to /dev/null. If I am wrong: great, have fun and keep on hacking!
> 
> Unless I am mistaken you have a choice to make, which choice you follow is entirely up to those who do the work to address the ambiguity in the current standard.
> 
> My own argument lies in a different community: first, that, absent some clear statement of the CRS restriction, the OGC cannot standardize on use of GeoJSON even for the limited set of CRS where it works, and second, that unless a general solution is provided by GeoJSON, the OGC will have to fork its own OgcJSON standard, identical to GeoJSON except for the axis order policy so that we can support the breadth of CRSs encountered in our domain.

Breaking backwards compatibility would only break if you use a CRS that
is not using the easting, northing order.

I wonder how many people use custom CRS? Is it really common? So far the
GeoJSON I got was almost always using the default WGS84.

If changing it to using the CRS order would make it possible for the OGC
to adapt it, I'd be for it. Though I'm sure I miss a lot of implications
and it's really bad idea. Please enlighten me.

Cheers,
  Volker