Subject: [Geojson] PR #199: CRS

From: Martin Thomson <[email-masked]>
Date: Thu, 21 Apr 2016 13:23:50 +1000

Surprising no one, this issue turns out to be tricky.

If I understand the discussion this is the intended statements we want to make:

1. Using a different CRS is not advised.
2. Using a different CRS with lat, long ordering of coordinates is prohibited.
3. Anyone using a different CRS is responsible for ensuring that their
GeoJSON-like data is properly understood by all potential recipients.
They can do that by limiting the set of recipients.

The second point is one I'd like to get some clarity on.  It seems
that there is a fuzzy line here and I think we could be crisper about
where that line is.

I get that this particular error has caused interoperability problems,
but what about other sorts of confusion.  Is the problem specific to
an inversion of lat/lng?

Specifically, would the same sort of problem occur for a ECEF
Cartesian CRS?  Would the same problem occur for a CRS with a
dramatically different prime meridian (such as one that passes through
Mundubbera, or Vienna)?

If the former is a problem, but not the latter, then point 2 might
become "Using a CRS that uses a form other than long, lat or long,
lat, alt is prohibited."

Whereas if both issues are a concern, then it looks like we're
creating a rule that is based on some sort of subjective similarity to
WGS84.  Isn't it better to prohibit the use of alternative coordinate
reference systems entirely?  If we accept that, then people doing
their own thing, like Sean's UTM-based pipeline, are simply using
GeoJSON-like structures.

---

From: <[email-masked]>
Date: Thu, 21 Apr 2016 03:55:29 +0000

Could also be phrased

"use of a right-handed crs is mandatory".

________________________________
From: GeoJSON <[email-masked]> on behalf of Martin Thomson <[email-masked]>
Sent: Thursday, 21 April 2016 3:23:50 AM
To: [email-masked]
Subject: [Geojson] PR #199: CRS

_______________________________________________
GeoJSON mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/geojson

---

From: James Winterbottom <[email-masked]>
Date: Thu, 21 Apr 2016 15:31:34 +1000

I would prefer not to say right-hand, but more explicitly lat,long or long,lat.

Sent from my iPhone

> On 21 Apr 2016, at 1:55 pm, <[email-masked]> wrote:
>

---

From: jrom <[email-masked]>
Date: Thu, 21 Apr 2016 08:30:25 +0200

Hi all,

2016-04-21 7:31 GMT+02:00 James Winterbottom <[email-masked]
>:

> I would prefer not to say right-hand, but more explicitly lat,long or

I completely agree with James. This is one document where we should avoid
concept that could be easily misunderstood for non specialist.
If something can be written explicitly, then we should always write it this
way.

Regards

Jérôme

-- 
Jérôme Gasperi
Web: https://mapshup.com
Mobile: +33 6 19 59 17 35
Skype: jerome.gasperi
Twitter: @jrom

---

From: Martin Daly <[email-masked]>
Date: Thu, 21 Apr 2016 06:50:31 +0000

> 1. Using a different CRS is not advised.

Correct.

> 2. Using a different CRS with lat, long ordering of coordinates is prohibited.

Incorrect.

Use, or reference, any CRS definition you want, but coordinates are still *always* lon/lat or easting/northing.

> 3. Anyone using a different CRS is responsible for ensuring that their GeoJSON-
> like data is properly understood by all potential recipients.

Correct.

> The second point is one I'd like to get some clarity on.  It seems that there is a
> fuzzy line here and I think we could be crisper about where that line is.

So fuzzy that we don't even seem to have agreement on where the line is :(

> I get that this particular error has caused interoperability problems, but what
> about other sorts of confusion.  Is the problem specific to an inversion of
> lat/lng?

No, there are southing/westing projected CRS definitions, ie the order is switched *and* the sign is reversed.

> Specifically, would the same sort of problem occur for a ECEF Cartesian CRS?
> Would the same problem occur for a CRS with a dramatically different prime
> meridian (such as one that passes through Mundubbera, or Vienna)?

We can't anchor everything to the intersection of the Greenwich meridian and the equator, because of projected (and other) CRSs, so we have to live with alternative prime meridians being a possibility (albeit with the interoperability warning applying).

> If the former is a problem, but not the latter, then point 2 might become
> "Using a CRS that uses a form other than long, lat or long, lat, alt is prohibited."

No, see the answer to 2, above.

> Whereas if both issues are a concern, then it looks like we're creating a rule
> that is based on some sort of subjective similarity to WGS84.  Isn't it better to
> prohibit the use of alternative coordinate reference systems entirely?  If we
> accept that, then people doing their own thing, like Sean's UTM-based pipeline,
> are simply using GeoJSON-like structures.

Interoperability when using different CRSs is possible, just less likely with the wider population of GeoJSON consumers.

We discussed the possibility of banning other CRSs, but there was no consensus (quite the opposite, I think). I doubt that that has changed.

Martin

---

From: Martin Thomson <[email-masked]>
Date: Thu, 21 Apr 2016 21:22:26 +1000

> Use, or reference, any CRS definition you want, but coordinates are still *always* lon/lat or easting/northing.

Ok, I think that I understand what the parameters are now.

Now I think that I'd like to understand why those particular parameters.

How is it that a projected CRS is OK and even ECEF, but only if
easting is put before northing?  From the outside, it seems a little
arbitrary.  What is the principle that you are attempting to preserve
with this restriction?

---

From: <[email-masked]>
Date: Thu, 21 Apr 2016 12:29:03 +0000

Except in some crs it is called easting/northing, or even westing/soothing in some systems, and a few others. The axis names are not the same in all crs. So lat/long is not necessarily as explicit as you imply

________________________________
From: James Winterbottom <[email-masked]>
Sent: Thursday, 21 April 2016 5:31:34 AM
To: Cox, Simon (L&W, Clayton)
Cc: <[email-masked]>; <[email-masked]>
Subject: Re: [Geojson] PR #199: CRS

Sent from my iPhone

Could also be phrased

________________________________
From: GeoJSON <[email-masked]<mailto:[email-masked]>> on behalf of Martin Thomson <[email-masked]<mailto:[email-masked]>>
Sent: Thursday, 21 April 2016 3:23:50 AM
To: [email-masked]<mailto:[email-masked]>
Subject: [Geojson] PR #199: CRS

_______________________________________________
GeoJSON mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/geojson
_______________________________________________
GeoJSON mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/geojson

---

From: Tim Schaub <[email-masked]>
Date: Thu, 21 Apr 2016 08:58:53 -0600

> Now I think that I'd like to understand why those particular parameters.

The reason to have the spec describe which coordinate is easting and
which is northing is that it lets people write clients that can render
(or otherwise process) the data *without* having to carry around a
lookup table of all possible CRS identifier to axis order
relationships that you might encounter.

A CRS-agnostic GeoJSON client can successfully render data to users in
a way that makes sense: render the first coordinate along a horizontal
axis and the second along a vertical axis.  Once you say that you can
only understand the axis order if you also have a database of every
possible CRS, you make lightweight web clients impractical.

Tim

---

From: Martin Thomson <[email-masked]>
Date: Fri, 22 Apr 2016 17:04:41 +1000

On 22 April 2016 at 00:58, Tim Schaub <[email-masked]> wrote:
> Once you say that you can

That's a very narrow use case.  I find that geographical data tends to
be much less useful without being able to relate it to other
geographical data (such as maps, other features I know about, etc...).

Quoting now from some smart individual on github (not me):

>>>
>From @martinthomson's comment above:

> GeoJSON documents MUST NOT use a coordinate reference system other than the one defined here.

This is such clear, simple language. I think the spec would be
significantly approved if we would use it. I'm wondering what negative
outcomes we might expect if we adopted it.

Many of us use GeoJSON-like serializations in situations like
@sgillies describes above, and I imagine we would continue to write
and/or use lenient parsers to do this. I don't think that these
lenient (or CRS agnostic) parsers would disappear if the spec mandated
that alt-CRS not be used.

Even a strict parser would have to allow a crs member (as a foreign
member), so existing alt-CRS GeoJSON documents would still be valid in
tomorrow's compliant parsers. GeoJSON doesn't specify the range of
allowed numbers for coordinates, so writing a parser that throws in
the face of large/small values would be going beyond what is specified
(and fragile).

Maybe this is discussion for a mailing list, but I'm curious to hear
(again) objections to this language[...]

---

From: Sean Gillies <[email-masked]>
Date: Fri, 22 Apr 2016 16:38:41 -0600

On Thu, Apr 21, 2016 at 12:50 AM, Martin Daly <[email-masked]>
wrote:
...

Interoperability when using different CRSs is possible, just less likely
> with the wider population of GeoJSON consumers.
>
> We discussed the possibility of banning other CRSs, but there was no
> consensus (quite the opposite, I think). I doubt that that has changed.
>

Martin,

Interoperability when using different CRS is hardly possible for GeoJSON
because we don't specify a way to identify the intended CRS. If I serve you
a file with coordinates like

    [4200.0, 4200.0] ...

with no other information, how are you going to use this data? There's no
interoperability here.

My reading of https://github.com/geojson/draft-geojson/pull/39 and other
issues is that support for "other CRS are allowed but NOT RECOMMENDED" was
actually lukewarm at best. Tim, Howard, and I preferred to drop CRS, along
with Raj Singh. Allan originally did and then switched. I don't think
consensus is settled here at all and that it is okay to revisit the
question.

In https://github.com/geojson/draft-geojson/pull/6 it was clear that folks
who were serving projected GeoJSON were doing so without any CRS definition
at all, within their own tightly coupled client-server systems (web map
front ends dedicated to a particular database). Their interoperability
needs: zero. The impact on their work from a change to "other CRS NOT
ALLOWED": zero. As I've written elsewhere, I'm doing the same thing in
production at work and am perfectly content with my representations being
only GeoJSON-like, not actual standard GeoJSON.

What I'm not content with is receiving application/geo+json GeoJSON from
others that uses arbitrary and unidentified coordinate reference systems.

Changing SHOULD NOT to "GeoJSON documents MUST NOT use a coordinate
reference system other than the one defined here" (
https://github.com/geojson/draft-geojson/pull/197#issuecomment-212898200)
is my strong preference. If we can't do this, we should consider writing
http://geojson.org/geojson-spec.html#coordinate-reference-system-objects
into the draft or writing a replacement for it.

-- 
Sean Gillies

---

From: Erik Wilde <[email-masked]>
Date: Fri, 22 Apr 2016 16:08:08 -0700

On 2016-04-22 15:38, Sean Gillies wrote:
> reference system other than the one defined here"
> (https://github.com/geojson/draft-geojson/pull/197#issuecomment-212898200)

i think at the current state, "MUST NOT" is the only sensible option.

the draft has taken the slippery slope of trying to rewrite history by 
completely removing "crs" and behaving as if it never existed. in doing 
so, it should at least be consistent and say that there is only one CRS 
which must be used. saying anything else is thoroughly confusing in that 
new one-CRS world.

iff the draft acknowledged "crs", then the huge headache would be what 
to say about it. make it mandatory to ignore it? or even making it 
mandatory to scream and stop processing? anything else in my mind would 
mean to still "support" "crs", one way or another.

"crs" violates our own extension rule (extensions cannot change 
semantics of the core vocabulary), so it has to be banned.

here is my proposal:

a) leave the spec as it is (no mention of "crs") and make it crystal 
clear that all data MUST be WGS84. even mentioning the fact that 
essentially broken implementations may put something else there may 
plant the idea id dev's heads that this might be a good idea, or at 
least a workable idea. i would try to avoid that.

b) have a non-normative appendix mentioning "crs" and acknowledging that 
at one point it was part of GeoJSON, but that now it is not, and that 
any implementation supporting it is broken, because it is a broken 
extension, in the new GeoJSON world. (if we had a test suite we could 
have test cases against that, but sadly we don't.)

this latter part may sound harsh, but there's no way around it. at least 
i cannot see one, even after all these discussions we've had.

cheers,

dret.

-- 
erik wilde | mailto:[email-masked] |
            | http://dret.net/netdret    |
            | http://twitter.com/dret    |

---

From: Allan Doyle <[email-masked]>
Date: Fri, 22 Apr 2016 19:08:45 -0400

If I’m the lone holdout, I’ll go with the consensus of dropping it. I’m just very sensitive to backwards compatibility. OGC switched coordinate order on WMS between 1.1.1 and 1.3 and it was a mess.

> On Apr 22, 2016, at 6:38 PM, Sean Gillies <[email-masked]> wrote:
> 
> On Thu, Apr 21, 2016 at 12:50 AM, Martin Daly <[email-masked] <mailto:[email-masked]>> wrote:
> ...
> 
> Interoperability when using different CRS is hardly possible for GeoJSON because we don't specify a way to identify the intended CRS. If I serve you a file with coordinates like
> 
>     [4200.0, 4200.0] ...
> 
> with no other information, how are you going to use this data? There's no interoperability here.
> 
> My reading of https://github.com/geojson/draft-geojson/pull/39 <https://github.com/geojson/draft-geojson/pull/39> and other issues is that support for "other CRS are allowed but NOT RECOMMENDED" was actually lukewarm at best. Tim, Howard, and I preferred to drop CRS, along with Raj Singh. Allan originally did and then switched. I don't think consensus is settled here at all and that it is okay to revisit the question.
> 
> In https://github.com/geojson/draft-geojson/pull/6 <https://github.com/geojson/draft-geojson/pull/6> it was clear that folks who were serving projected GeoJSON were doing so without any CRS definition at all, within their own tightly coupled client-server systems (web map front ends dedicated to a particular database). Their interoperability needs: zero. The impact on their work from a change to "other CRS NOT ALLOWED": zero. As I've written elsewhere, I'm doing the same thing in production at work and am perfectly content with my representations being only GeoJSON-like, not actual standard GeoJSON.
> 
> What I'm not content with is receiving application/geo+json GeoJSON from others that uses arbitrary and unidentified coordinate reference systems.
> 
> Changing SHOULD NOT to "GeoJSON documents MUST NOT use a coordinate reference system other than the one defined here" (https://github.com/geojson/draft-geojson/pull/197#issuecomment-212898200 <https://github.com/geojson/draft-geojson/pull/197#issuecomment-212898200>) is my strong preference. If we can't do this, we should consider writing http://geojson.org/geojson-spec.html#coordinate-reference-system-objects <http://geojson.org/geojson-spec.html#coordinate-reference-system-objects> into the draft or writing a replacement for it.
> 
> -- 
> Sean Gillies

---

From: Erik Wilde <[email-masked]>
Date: Fri, 22 Apr 2016 16:22:24 -0700

hello allan.

On 2016-04-22 16:08, Allan Doyle wrote:
> If I’m the lone holdout, I’ll go with the consensus of dropping it. I’m
> just very sensitive to backwards compatibility.

that's always an important concern when working on deployed formats. so 
what are the cases we have to be sensitive about?

- if people just used a different CRS without properly identifying it, 
then their data is a lost cause anyway, right? it did not even work in 
the old days, and that it may work in a closed world with implicit 
agreement on some non-WGS84 CRS is not something we even have to 
mention. imho, it even would be a bad idea to mention it. that's tight 
coupling at its worst.

- if people used "crs" and assumed it worked, then it sometimes worked, 
and sometimes it didn't, right? that's the problem that "crs" had. in 
the new "thou shalt not use 'crs'" world, it also sometimes works and 
sometimes doesn't, only the other way around. that's not a very precise 
statement to make, but would you agree?

since we changed the media type, well-done implementations can actually 
distinguish the old-school and the new GeoJSON. maybe that's something 
that also could be mentioned in the "crs appendix": old media type 
GeoJSON might have a "crs" member and then implementations would be 
smart to assume that they shouldn't just go ahead and interpret data as 
WGS84. new media type GeoJSON should not have "crs", and if they do, 
implementations MUST NOT interpret coordinates as non-WGS84. they should 
either raise an error or continue and use WGS84, but they MUST NOT 
change the semantics of coordinates.

that leaves us with the unpleasant case of GeoJSON that's not clearly 
labeled by media type, which probably will happen quite frequently. my 
guess is that there's little we can do about that, and it would be 
essentially up to applications to decide how to process this type of 
data: as old GeoJSON or as new GeoJSON.

does all of that sounds reasonable? i think in the end, there is no 
silver bullet here that will make everybody happy in all cases. afaict, 
the solution outlined above at least is clean and well-defined, and 
shouldn't be too hard to communicate to devs.

cheers,

dret.

---

From: <[email-masked]>
Date: Fri, 22 Apr 2016 23:54:26 +0000

Have been following this conversation with great interest. Sean's description of the situation seems very accurate to me.

The influence of Geojson is not limited to strictly conforming applications. For example I used the GeoJSON geometry formulation within a JSON implementation of O&M published through OGC last year, but did not claim that OM-JSON was therefore GeoJSON, because it otherwise wasn't. Other elaborations and extensions and deviations will be created, including the ones Sean describes that use other crs. Under the regime proposed none of these are GeoJSON, but they are still useful, and it is better to tweak something that works than start again.

This all seems like a very useful direction, furthermore would cease offending the precious petals in the community that care so much about crs, and thus diminish the total level of conflict in the world just a little bit. 😉

Simon

________________________________
From: GeoJSON <[email-masked]> on behalf of Sean Gillies <[email-masked]>
Sent: Friday, 22 April 2016 10:38:41 PM
To: Martin Daly
Cc: Martin Thomson; [email-masked]
Subject: Re: [Geojson] PR #199: CRS

On Thu, Apr 21, 2016 at 12:50 AM, Martin Daly <[email-masked]<mailto:[email-masked]>> wrote:
...

Martin,

    [4200.0, 4200.0] ...

My reading of https://github.com/geojson/draft-geojson/pull/39 and other issues is that support for "other CRS are allowed but NOT RECOMMENDED" was actually lukewarm at best. Tim, Howard, and I preferred to drop CRS, along with Raj Singh. Allan originally did and then switched. I don't think consensus is settled here at all and that it is okay to revisit the question.

In https://github.com/geojson/draft-geojson/pull/6 it was clear that folks who were serving projected GeoJSON were doing so without any CRS definition at all, within their own tightly coupled client-server systems (web map front ends dedicated to a particular database). Their interoperability needs: zero. The impact on their work from a change to "other CRS NOT ALLOWED": zero. As I've written elsewhere, I'm doing the same thing in production at work and am perfectly content with my representations being only GeoJSON-like, not actual standard GeoJSON.

Changing SHOULD NOT to "GeoJSON documents MUST NOT use a coordinate reference system other than the one defined here" (https://github.com/geojson/draft-geojson/pull/197#issuecomment-212898200) is my strong preference. If we can't do this, we should consider writing http://geojson.org/geojson-spec.html#coordinate-reference-system-objects into the draft or writing a replacement for it.

--
Sean Gillies

---

From: Allan Doyle <[email-masked]>
Date: Fri, 22 Apr 2016 20:10:05 -0400

I was mainly thinking of the discussion in these threads

http://lists.geojson.org/pipermail/geojson-geojson.org/2013-June/000790.html <http://lists.geojson.org/pipermail/geojson-geojson.org/2013-June/000790.html>

http://lists.geojson.org/pipermail/geojson-geojson.org/2013-December/000880.html <http://lists.geojson.org/pipermail/geojson-geojson.org/2013-December/000880.html>

https://github.com/geojson/draft-geojson/pull/15 <https://github.com/geojson/draft-geojson/pull/15>

Martin Daly, Howard Butler and I were generally on the side of keeping CRS. As I said earlier, if I’m the lone holdout, I’m not going to stand in the way of closing this issue.

	Allan

> On Apr 22, 2016, at 7:54 PM, <[email-masked]> <[email-masked]> wrote:
>

---

From: Carl Reed <[email-masked]>
Date: Fri, 22 Apr 2016 20:02:30 -0600

If I might make a suggestion. Consider OASIS CAP as an example of a simple
CRS expression/requirement.

The OASIS Common Alert Protocol (CAP) has been in use and broadly
implemented since March 2004. As with GeoJSON, the OASIS TC group that
developed CAP wanted to keep the alerting protocol as light weight and as
simple as possible for anyone - especially non GIS developers - to
implement. Early on they decided to specify one and only one CRS. There are
no words about using other CRS.

*Version 1.2 of CAP states:*

*Geographic locations in CAP are defined using [WGS 84] (World Geodetic
System 1984), equivalent to EPSG (European Petroleum Survey Group) code
4326 (2 dimensions). CAP does not assign responsibilities for coordinate
transformations from and to other Spatial Reference Systems. See section
1.5 Terminology for the format of coordinate pairs within CAP elements.*

*1.5 *

*The term “coordinate pair” is used in this document to refer to a
comma-delimited pair of decimal values describing a geospatial location in
degrees, unprojected, in the form “[latitude],[longitude]”.  Latitudes in
the Southern Hemisphere and longitudes in the Western Hemisphere are signed
negative by means of a leading dash.*

CAP is now integrated into many alerting systems and mandated as legal
policy related to EM alerting systems in many countries. Now, I am not
suggesting that the same wording be used. However, CAP provides an exemplar
of a standard that specifies a simple CRS rule without any additional
"clutter", such as SHALL NOTs.

Now, as a side note, getting this simple wording took many conference
calls, emails, and several months! I know - I participated in those
discussions.

Regards

Carl

On Fri, Apr 22, 2016 at 6:10 PM, Allan Doyle <[email-masked]>
wrote:

> http://lists.geojson.org/pipermail/geojson-geojson.org/2013-June/000790.html
>
>
> http://lists.geojson.org/pipermail/geojson-geojson.org/2013-December/000880.html
>
> https://github.com/geojson/draft-geojson/pull/15
>
> Martin Daly, Howard Butler and I were generally on the side of keeping
> CRS. As I said earlier, if I’m the lone holdout, I’m not going to stand in
> the way of closing this issue.
>
> Allan
>
> Have been following this conversation with great interest. Sean's
> description of the situation seems very accurate to me.
>
> The influence of Geojson is not limited to strictly conforming
> applications. For example I used the GeoJSON geometry formulation within a
> JSON implementation of O&M published through OGC last year, but did not
> claim that OM-JSON was therefore GeoJSON, because it otherwise wasn't.
> Other elaborations and extensions and deviations will be created, including
> the ones Sean describes that use other crs. Under the regime proposed none
> of these are GeoJSON, but they are still useful, and it is better to tweak
> something that works than start again.
>
> This all seems like a very useful direction, furthermore would cease
> offending the precious petals in the community that care so much about crs,
> and thus diminish the total level of conflict in the world just a little
> bit. 😉
>
> Simon
>
> ------------------------------
> *From:* GeoJSON <[email-masked]> on behalf of Sean Gillies <
> [email-masked]>
> *Sent:* Friday, 22 April 2016 10:38:41 PM
> *To:* Martin Daly
> *Cc:* Martin Thomson; [email-masked]
> *Subject:* Re: [Geojson] PR #199: CRS
>
> In https://github.com/geojson/draft-geojson/pull/6 it was clear that
> folks who were serving projected GeoJSON were doing so without any CRS
> definition at all, within their own tightly coupled client-server systems
> (web map front ends dedicated to a particular database). Their
> interoperability needs: zero. The impact on their work from a change to
> "other CRS NOT ALLOWED": zero. As I've written elsewhere, I'm doing the
> same thing in production at work and am perfectly content with my
> representations being only GeoJSON-like, not actual standard GeoJSON.
>

-- 
Carl Reed, PhD
Carl Reed and Associates

Mobile: 970-402-0284

---

From: Sean Gillies <[email-masked]>
Date: Mon, 25 Apr 2016 16:12:54 -0600

> calls, emails, and several months! I know - I participated in those

Carl, thanks for pointing out the CAP choice.

Based on the comments in this thread, I think we're nearing consensus on
making the changes I'm suggesting in

  https://github.com/geojson/draft-geojson/pull/202

As I wrote there, I don't think backwards compatibility is much of an
issue, Allan. Support for the original (and badly designed) GeoJSON CRS
object has always been poor and has been dwindling. Software that does
support it, such as GDAL, will continue to do so for some time. Nothing
really changes for the users of this obsolete feature (GeoJSON CRS, not the
idea of CRS in general).

-- 
Sean Gillies

---

From: Carl Reed <[email-masked]>
Date: Mon, 25 Apr 2016 16:31:58 -0600

Am happy with the suggested approach!

Thanks for your continued patience and hard work in resolving this (always)
sticky issue

Carl

On Mon, Apr 25, 2016 at 4:12 PM, Sean Gillies <[email-masked]>
wrote:

>> If I might make a suggestion. Consider OASIS CAP as an example of a
>> simple CRS expression/requirement.
>>

-- 
Carl Reed, PhD
Carl Reed and Associates

Mobile: 970-402-0284

---

From: Martin Daly <[email-masked]>
Date: Tue, 26 Apr 2016 05:59:41 +0000

> As I wrote there, I don't think backwards compatibility is much of an issue, Allan. Support for the original (and badly designed)
> GeoJSON CRS object has always been poor and has been dwindling. Software that does support it, such as GDAL, will continue
> to do so for some time. Nothing really changes for the users of this obsolete feature (GeoJSON CRS, not the idea of CRS in general).

You cannot possibly assert these "facts" with any certainty whatsoever. We don't know who or what uses the GeoJSON CRS object.

I'm queasy about making this - the only, I think - backwards incompatible change just because we can't agree on wording for warning text, and with such flimsy evidence of the effect on existing software and data.

Martin

---

From: Howard Butler <[email-masked]>
Date: Tue, 26 Apr 2016 11:36:32 -0500

> On Apr 26, 2016, at 12:59 AM, Martin Daly <[email-masked]> wrote:
> 

Indeed we can't assert that with certainty. We do know there are a number folks using GeoJSON with non-WGS84 coordinate systems. When we solicited feedback on the topic before the IETF process, some came and said so. Does ditching these people in exchange for future simplicity make interop of GeoJSON worse in the long run? IMO, no. When the IETF spec is released, and the Changelog is produced, and it says "GeoJSON is WGS84-only from now on," I'll be comfortable knowing it is a better spec for it, even though my inner Geoperson™ will shake his head indignantly.

2008 GeoJSON's original sin was letting coordinate systems evolve and not really specifying them. The two most common coordinate system scenarios (WGS84 and Web Mercator) were already in the front of mind for most of us. Reprojection on the (JavaScript) client was evolving from a curiosity to an expected capability (The thinking was "If I can't easily reproject on the client but I can on the server, I'll need to make sure my transport supports coordinate system description."). The facts of the time didn't clearly point to YAGNI* for GeoJSON's niche, but in retrospect, I think they do.

> I'm queasy about making this - the only, I think - backwards incompatible change just because we can't agree on wording for warning text, and with such flimsy evidence of the effect on existing sof…

I am too, but the warning text is just as flimsy, and it puts the burden on the developers to do the right thing. Most will, but some inevitably won't. Chucking this now takes it out of the realm of gentle agreement and gives people in violent opposition a way forward.  

Howard

* I know you are going to need them if you're doing a) high(er) precision anything, b) geodesy anything, or c) commutative high precision data transport. GeoJSON isn't your archival all purpose geo format, and if you are using it that way, you're probably using it wrong.

---

From: Erik Wilde <[email-masked]>
Date: Tue, 26 Apr 2016 09:44:11 -0700

On 2016-04-26 09:36, Howard Butler wrote:
> 2008 GeoJSON's original sin was letting coordinate systems evolve and not really specifying them.

agreed. and in my mind, the biggest subsin there was to not be clear 
about CRS identifiers. had there been a registry where people could look 
up well-known identifiers and find documentation about which CRS they 
define, that might have prevented quite a bit of interop headache 
already. but this train has left the station a long time ago...

cheers,

dret.

---

From: Howard Butler <[email-masked]>
Date: Tue, 26 Apr 2016 11:59:14 -0500

> On Apr 26, 2016, at 11:44 AM, Erik Wilde <[email-masked]> wrote:
> 
> agreed. and in my mind, the biggest subsin there was to not be clear about CRS identifiers. had there been a registry where people could look up well-known identifiers and find documentation about which CRS they define, that might have prevented quite a bit of interop headache already. but this train has left the station a long time ago...

That was Chris Schmidt and myself's original intent of http://spatialreference.org, which was a realization that there was never going to be a single coordinate system definition standard going backward in time even if one going forward materialized. I don't know if the site was very successful in achieving that goal, but it has proved useful in other contexts. 

CRS identifiers themselves were out of scope for 2008 GeoJSON, and the spec contorted to avoid making pronouncements about them. The trouble came when the spec provided strong language about coordinate ordering. I disagree there's been a ton of interop headache though, because the interop of using WGS84 was originally noted and used in practice by most. The headache has been for us discussing the specification...

Howard

---

From: Sean Gillies <[email-masked]>
Date: Tue, 26 Apr 2016 15:16:30 -0600

On Tue, Apr 26, 2016 at 10:36 AM, Howard Butler <[email-masked]> wrote:

> issue, Allan. Support for the original (and badly designed)
> >> GeoJSON CRS object has always been poor and has been dwindling.
> Software that does support it, such as GDAL, will continue
> >> to do so for some time. Nothing really changes for the users of this
> obsolete feature (GeoJSON CRS, not the idea of CRS in general).
> >
> > You cannot possibly assert these "facts" with any certainty whatsoever.
> We don't know who or what uses the GeoJSON CRS object.
>
> Indeed we can't assert that with certainty. We do know there are a number
> folks using GeoJSON with non-WGS84 coordinate systems. When we solicited
> feedback on the topic before the IETF process, some came and said so. Does
> ditching these people in exchange for future simplicity make interop of
> GeoJSON worse in the long run? IMO, no. When the IETF spec is released, and
> the Changelog is produced, and it says "GeoJSON is WGS84-only from now on,"
> I'll be comfortable knowing it is a better spec for it, even though my
> inner Geoperson™ will shake his head indignantly.
>
>
Howard, I'd like to point out again that these people using non-WGS84
coordinate systems were not even using CRS objects.

https://github.com/geojson/draft-geojson/pull/6#issuecomment-18511869
https://github.com/geojson/draft-geojson/pull/6#issuecomment-18514807

As I see it, we're not ditching them because they were never on board to
begin with.

Consider that a GeoJSON doc originates from a server that either does
(GeoServer, say) or does not (HTTP-served flat files) reproject on demand
and that it is received by a client that either does (OpenLayers, say) or
does not (Leaflet, say) reproject CRS-identified coordinates to another
CRS. Of the four different combinations of these clients and servers, the
one that may be impacted by the change we're talking about is the
combination of flat files in non-WGS84 coordinates (lets say you've got a
worldwide dataset broken up by UTM zone) and a client that reprojects them
(to, say, Web Mercator) for display or analysis. None of the other 3
combinations depend crucially on there being a CRS identified in the
GeoJSON file.

Making GeoJSON WGS84 only doesn't delete those UTM files from the server or
stop the client from reprojecting their data in any unpredictable way. It's
pretty clear how this application can eventually break: when the client
software makes a breaking change of its own to match our GeoJSON draft
(dropping support for CRS between version X and Y) and the developers of
this application are forced to upgrade (for security reasons or end of
support for their operating system) to the new version of that client
software before they can migrate their flat files. That's how breaking
backwards compatibility breaks this application. Getting the maintainers of
client software that support the old GeoJSON CRS objects today to keep that
support as a favor for legacy data can cover backwards compatibility, can
it not?

-- 
Sean Gillies

---

From: Howard Butler <[email-masked]>
Date: Tue, 26 Apr 2016 16:18:51 -0500

> On Apr 26, 2016, at 4:16 PM, Sean Gillies <[email-masked]> wrote:
> 
> Getting the maintainers of client software that support the old GeoJSON CRS objects today to keep that support as a favor for legacy data can cover backwards compatibility, can it not?

Yes, as far as I'm concerned.

---

From: Martin Daly <[email-masked]>
Date: Tue, 26 Apr 2016 21:27:13 +0000

> Howard, I'd like to point out again that these people using non-WGS84 coordinate systems were not even using CRS objects.

A self-selected minority can hardly be regarded as representative of anything other than themselves.

Martin

---

From: Howard Butler <[email-masked]>
Date: Tue, 26 Apr 2016 16:25:20 -0500

> On Apr 26, 2016, at 4:27 PM, Martin Daly <[email-masked]> wrote:
> 

But isn't that notion this entire exercise? ;)

---

From: Martin Daly <[email-masked]>
Date: Tue, 26 Apr 2016 21:34:01 +0000

> But isn't that notion this entire exercise? ;)

No-one likes a smart-arse. (I speak from a position of authority because I have no friends.)

Martin

---

From: Martin Daly <[email-masked]>
Date: Tue, 26 Apr 2016 22:04:16 +0000

> Getting the maintainers of client software that support the old GeoJSON CRS objects today to keep that support as a favour
> for legacy data can cover backwards compatibility, can it not?

That is missing the point.

What the spec says now (effectively) is that such legacy data is *not* GeoJSON, and cannot be claimed to be GeoJSON, even though it was yesterday. That, in my opinion, is beyond the pale.

I don't actually object (well, maybe a tiny bit) to WGS 84-only henceforth, but do object to attempting to (effectively) rewrite history, and to banishing a little/some/plenty/lots/who knows how much data from the GeoJSON kingdom. That, in my opinion, is no way to treat developers and data suppliers who used the CRS object in good faith, however ill-conceived it was.

If someone can find wording that conveys that, I'd gladly endorse it.

Good night and good luck,
Martin

---

From: Martin Thomson <[email-masked]>
Date: Wed, 27 Apr 2016 13:28:52 +1000

> What the spec says now (effectively) is that such legacy data is *not* GeoJSON, and cannot be claimed to be GeoJSON, even though it was yesterday. That, in my opinion, is beyond the pale.

Is there any way we can say that such data is not *this* GeoJSON, it's
that other GeoJSON.  Maybe by declaring this GeoJSON v2?

---

From: Erik Wilde <[email-masked]>
Date: Tue, 26 Apr 2016 20:58:25 -0700

> that other GeoJSON.  Maybe by declaring this GeoJSON v2?

there is a different media type. in theory, that should be enough to 
allow people to distinguish between old and new rules. in practice it 
probably won't work like this, though.

---

From: Martin Thomson <[email-masked]>
Date: Wed, 27 Apr 2016 14:05:22 +1000

On 27 April 2016 at 13:58, Erik Wilde <[email-masked]> wrote:
> there is a different media type. in theory, that should be enough to allow
> people to distinguish between old and new rules. in practice it probably
> won't work like this, though.

I understand Martin's concern to be one of appearances.  Being able to
say that you are using "GeoJSON" is important, even if might seem a
bit superficial to some.

---

From: Martin Daly <[email-masked]>
Date: Wed, 27 Apr 2016 06:27:20 +0000

> people to distinguish between old and new rules. in practice it probably won't
> work like this, though.

There's a big bad world out there that isn't on the web, so this isn't enough.

Martin