Subject: [Geojson] Call for adoption draft-butler-geojson

From: Martin Thomson <[email-masked]>
Date: Wed, 28 Oct 2015 06:47:57 +0900

This is a two week call for adoption of draft-butler-geojson [1].

Please reply to this email before 2015-11-11 indicating whether (or
not) you want to adopt draft-butler-geojson into the working group.

This draft is mentioned in our charter.  If you object to adoption,
please explain your reasoning.

Note that adopting this draft indicates that the working group
believes that this is a good basis for the work of the charter.  It
does not mean that it is free of issues. The most relevant aspect of
adoption is that change control is transferred to the working group.

[1] https://tools.ietf.org/html/draft-butler-geojson-06

---

From: Sean Gillies <[email-masked]>
Date: Tue, 27 Oct 2015 16:07:08 -0600

Yes for adoption.

On Tue, Oct 27, 2015 at 3:47 PM, Martin Thomson
<[email-masked]> wrote:
> _______________________________________________
> GeoJSON mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/geojson

-- 
Sean Gillies

---

From: <[email-masked]>
Date: Tue, 27 Oct 2015 22:10:29 +0000

+1

-----Original Message-----
From: GeoJSON [mailto:[email-masked]] On Behalf Of Martin Thomson
Sent: Wednesday, 28 October 2015 8:48 AM
To: [email-masked]
Subject: [Geojson] Call for adoption draft-butler-geojson

This draft is mentioned in our charter.  If you object to adoption, please explain your reasoning.

Note that adopting this draft indicates that the working group believes that this is a good basis for the work of the charter.  It does not mean that it is free of issues. The most relevant aspect of adoption is that change control is transferred to the working group.

---

From: Martin Daly <[email-masked]>
Date: Tue, 27 Oct 2015 22:38:03 +0000

Yes.

Martin

> Sent: 27 October 2015 21:48
> To: [email-masked]
> Note that adopting this draft indicates that the working group believes that this
> is a good basis for the work of the charter.  It does not mean that it is free of
> issues. The most relevant aspect of adoption is that change control is
> transferred to the working group.
>

---

From: Jerry Sievert <[email-masked]>
Date: Tue, 27 Oct 2015 15:47:13 -0700

yes.

---

From: Erik Wilde <[email-masked]>
Date: Wed, 28 Oct 2015 00:18:56 +0100

yes.

erik wilde.

-- 
erik wilde | mailto:[email-masked]  -  tel:+1-510-2061079 |
            | UC Berkeley  -  School of Information (ISchool) |
            | http://dret.net/netdret http://twitter.com/dret |

---

From: Carl Reed <[email-masked]>
Date: Tue, 27 Oct 2015 18:01:52 -0600

Martin -

No objections to adopting the draft-butler-geojson into the working group.
I am assuming that this motion is simply to approve this draft as the basis
of work for the Group.

Thanks and regards

Carl

-- 
Carl Reed, PhD
Carl Reed and Associates

Mobile: 970-402-0284

-- 
Carl Reed, PhD
Carl Reed and Associates

Mobile: 970-402-0284

---

From: Allan Doyle <[email-masked]>
Date: Tue, 27 Oct 2015 20:07:25 -0400

Yes.

-- 

> On Oct 27, 2015, at 17:47, Martin Thomson <[email-masked]> wrote:
>

---

From: Howard Butler <[email-masked]>
Date: Tue, 27 Oct 2015 20:13:59 -0500

Yes. 

> On Oct 27, 2015, at 7:07 PM, Allan Doyle <[email-masked]> wrote:
> 
> Yes.
> 
> -- 
> 
> 
>

---

From: "Panagiotis (Peter) A. Vretanos" <[email-masked]>
Date: Tue, 27 Oct 2015 22:21:43 -0400

+1

-- 
Panagiotis (Peter) A. Vretanos         CubeWerx Inc.
Big Kahuna (CTO, Senior DB Developer)  http://www.cubewerx.com
Tel. 416-701-1985  Fax. 416-701-9870   [email-masked]

One man's 'magic' is another man's engineering.  'Supernatural'
is a null word.    Robert A. Heinlein

---

From: Scott Simmons <[email-masked]>
Date: Tue, 27 Oct 2015 21:54:43 -0600

yes

> On Oct 27, 2015, at 3:47 PM, Martin Thomson <[email-masked]> wrote:
>

---

From: Stefan Hagen <[email-masked]>
Date: Wed, 28 Oct 2015 06:32:11 +0100

Yes for adoption.

Best,
Stefan.

-- 
Stefan Hagen
read://stefan-hagen.website

---

From: Alexandre Petrescu <[email-masked]>
Date: Wed, 28 Oct 2015 13:01:44 +0100

Hi,

I do not object to adoption, but I continue pondering over the following.

The draft says in its abstract:
>    This document recommends a single coordinate reference system based
>    on WGS 84.  Other coordinate reference systems are not recommended.

I still think this looks reductive, because tehre are many more such 
systems out there, not just WGS 84.  For example, a recent consumer 
Internet-connected product mentions WGS84, UTM, MGRS, BNG, ETRS-TM35FIN, 
KKJ, IG, RT90, CH1903, NAD27, NAD83.

Conversion has some times some inconvenients, that's why these systems 
exist.

Why the exclusivity of WGS 84?

Alex

---

From: Calvin Metcalf <[email-masked]>
Date: Wed, 28 Oct 2015 13:05:51 +0000

yes for adoption

---

From: Calvin Metcalf <[email-masked]>
Date: Wed, 28 Oct 2015 13:13:35 +0000

It is precisely because there are so many systems that only one was chosen,
the situation where different implementations supported different sets of
systems was one that the spec tries to avoid.

---

From: Alexandre Petrescu <[email-masked]>
Date: Wed, 28 Oct 2015 16:48:39 +0100

So many systems present also means there are many products on the market 
using them.  These products would be barred from using the GeoJSON 
result if the WGS84 exclusivity is pursued.

I agree different implementations supporting different sets of systems 
may lead to lack of interoperability.  But this situation can be avoided 
by providing 'knobs' in the implementations, by playing rightfully with 
RFC2119 words and ultimately by letting the market decide.

Is the intention to IETF rubber-stamping other standard?

Is JSON fundamentally designed to deal with only one CRS?

Alex

Le 28/10/2015 14:13, Calvin Metcalf a écrit :
> It is precisely because there are so many systems that only one was
> chosen, the situation where different implementations supported
> different sets of systems was one that the spec tries to avoid.
>
> On Wed, Oct 28, 2015 at 8:02 AM Alexandre Petrescu
> <[email-masked] <mailto:[email-masked]>> wrote:
>
>     Hi,
>
>      > [email-masked] <mailto:[email-masked]>
>     [email-masked] <mailto:[email-masked]>

---

From: Carl Reed <[email-masked]>
Date: Wed, 28 Oct 2015 10:45:42 -0600

Alex -

There is no reason that a JSON encoding cannot contain a reference for any
coordinate reference system. This could be a uri reference to an entry in
the EPSG geodetic parameter registry http://www.epsg-registry.org/ . This
registry is normatively referenced by other standards IETF, OGC, OASIS,
OMA, etc.You could also include the CRS parameters in the JSON encoding if
uri's are not desired.

Check out Testbed 11 Implementing JSON/GeoJSON in an OGC Standard -
Engineering Report
<https://portal.opengeospatial.org/files/?artifact_id=64595> for numerous
examples and recommendations.

As for GeoJSON, how to express a CRS other than WGS 84 depends on uses
cases and requirements. If you check out the 2008 version of GeoJSON (
http://geojson.org/geojson-spec.html#coordinate-reference-system-objects)
you can see what the original CRS approach was. However, there were (if
memory serves me) some issues such as with the requirement, "CRS shall not
change coordinate ordering (see 2.1.1. Positions
<http://geojson.org/geojson-spec.html#positions>). Others can provide a
much better background on how this issue was resolved.

Regards

Carl

On Wed, Oct 28, 2015 at 9:48 AM, Alexandre Petrescu <
[email-masked]> wrote:

> using them.  These products would be barred from using the GeoJSON result
> if the WGS84 exclusivity is pursued.
>
> I agree different implementations supporting different sets of systems may
> lead to lack of interoperability.  But this situation can be avoided by
> providing 'knobs' in the implementations, by playing rightfully with

-- 
Carl Reed, PhD
Carl Reed and Associates

Mobile: 970-402-0284

---

From: Calvin Metcalf <[email-masked]>
Date: Wed, 28 Oct 2015 16:58:05 +0000

the EPSG registry is several mb which is prohibitive for a web library,
also from my experience with proj4js there is a long tail of crazy when it
comes to coordinate reference systems and supporting some reasonable subset
of them really doesn't mesh well with geojson's aim to be the 80% solution
that solves most but not all problems.

On Wed, Oct 28, 2015 at 12:45 PM Carl Reed <[email-masked]> wrote:

> memory serves me) some issues such as with the requirement, "CRS shall
> not change coordinate ordering (see 2.1.1. Positions
>> may lead to lack of interoperability.  But this situation can be avoided by

---

From: Christine Waigl <[email-masked]>
Date: Wed, 28 Oct 2015 09:03:53 -0800

yes

-- 
Christine (Chris) Waigl - [email-masked] -  +1-907-474-5483 - Skype:
cwaigl_work
Geophysical Institute, UAF, 903 Koyukuk Drive, Fairbanks, AK 99775-7320, USA

---

From: Howard Butler <[email-masked]>
Date: Wed, 28 Oct 2015 12:34:05 -0500

> On Oct 28, 2015, at 11:45 AM, Carl Reed <[email-masked]> wrote:
> 
> Alex -
> 
> There is no reason that a JSON encoding cannot contain a reference for any coordinate reference system. This could be a uri reference to an entry in the EPSG geodetic parameter registry http://www.epsg-registry.org/ . This registry is normatively referenced by other standards IETF, OGC, OASIS, OMA, etc.You could also include the CRS parameters in the JSON encoding if uri's are not desired.
> 
> Check out Testbed 11 Implementing JSON/GeoJSON in an OGC Standard - Engineering Report for numerous examples and recommendations.
> 
> As for GeoJSON, how to express a CRS other than WGS 84 depends on uses cases and requirements. If you check out the 2008 version of GeoJSON (http://geojson.org/geojson-spec.html#coordinate-reference-system-objects) you can see what the original CRS approach was. However, there were (if memory serves me) some issues such as with the requirement, "CRS shall not change coordinate ordering (see 2.1.1. Positions). Others can provide a much better background on how this issue was resolved.

That particular statement was *the* issue with SRS in GeoJSON, and coincidently a linchpin of interoperability that allowed GeoJSON to proliferate where others struggled. It is a compromise that takes away the burden of SRS interpretation in favor of the web people who don't care so much about that part instead of the map people who do. The original GeoJSON specification tried to have its cake with SRS by allowing people to define other coordinate systems but side stepping the coordinate ordering issue with this language. It caused issues with the SRS pedants, and it has caused issues with GeoJSON's alignment with other standards.

The full mailing list archives, back to the beginning of (GeoJSON) time, are available for anyone to go back and catch up on this topic. It has been discussed many times over the years. The IETF doc is a recognition of how people have actually developed and interoperated in-the-wild software with GeoJSON in the 7+ years since the specification was pushed out.

http://lists.geojson.org/pipermail/geojson-geojson.org/

The SRS interoperability story for GeoJSON has been WGS84 or Web Mercator because that's been the web mapping story for the past ten years. Other SRSs are fine, but GeoJSON isn't going to wade into the swamp of CRS/SRS definition (2008 doc was a half-hearted attempt to sidestep that!). The list archives have all of this discussion in full detail.

Howard

---

From: Christine Waigl <[email-masked]>
Date: Wed, 28 Oct 2015 09:39:41 -0800

A few notes on this:

> It is precisely because there are so many systems that only one was
chosen, the situation where different implementations supported different
sets of systems was one that the spec tries to avoid.
>> >    on WGS 84.  Other coordinate reference systems are not recommended.

1. Thinking, say, 25 years ahead, is everyone still going to be happy with
this formulation?

2. Going back to the RFC2119 language:

> SHOULD NOT
> This phrase, or the phrase "NOT RECOMMENDED" mean that
> there may exist valid reasons in particular circumstances when the
> particular behavior is acceptable or even useful, but the full
> implications should be understood and the case carefully weighed
> before implementing any behavior described with this label.

It seems likely that
implementers and users will consider to have "valid reasons", so it would
be useful to get clarity ahead of time what these reasons and use cases may
be and how, if necessary, they could be made explicit in the standard.

3. As for use cases, if the application that processes GeoJSON is concerned
with measuring features (lengths, areas) or even simply comparing their
size, then it would be likely to want to use a projected CRS with suitable
conformity or preservation properties. This is especially the case if the
system does not "
have access to
coordinate reference systems databases
" as the very same paragraph sets out should be expected (that there is no
such access).

4. Another use case I can think of relates to systems that retrieve
coordinate information from older topo map products. In the US, a frequent
problem stems from these being in NAD27. If the format that is chosen to
transmit this data does not indicate the old datum/coordinate reference
information then future users lose the information. Errors such as these
are hard to correct and frequent in GIS databases run by institutions.
Worse, data may be merged with no regard with NAD83 and WGS84 data and
become impossible to disentangle.

Chris

---

From: Carl Reed <[email-masked]>
Date: Wed, 28 Oct 2015 11:42:38 -0600

Calvin -

I am not an EPSG expert - although I know many who are. Anyway, Maybe I am
confused. Just because GeoJSON could (or an extension could) allow the
encoding to specify a CRS other than WGS 84, this does not mean that a
server or client service/app actually needs to support those CRSs. There is
absolutely no problem with stating that the default CRS is WGS 84 with a
reference to the actual parameters. This is what GeoJSON currently does.
This is also what KML does. See Annex B in
http://docs.opengeospatial.org/is/12-007r2/12-007r2.html . Please note that
KML references the appropriate EPSG codes but references the OGC registry
as opposed to the EPSG registry.

Question: Why is a registry of several MBytes to large to be a web
registry? Your API and/or JSON encoding should only be requesting a single
CRS entry and not the entire dataset.

Regards

Carl

On Wed, Oct 28, 2015 at 10:58 AM, Calvin Metcalf <[email-masked]>
wrote:

>> There is no reason that a JSON encoding cannot contain a reference for
>> any coordinate reference system. This could be a uri reference to an entry
>> in the EPSG geodetic parameter registry http://www.epsg-registry.org/ .
>> This registry is normatively referenced by other standards IETF, OGC,
>> OASIS, OMA, etc.You could also include the CRS parameters in the JSON
>> encoding if uri's are not desired.
>>
>> <https://portal.opengeospatial.org/files/?artifact_id=64595> for
>> numerous examples and recommendations.
>>

-- 
Carl Reed, PhD
Carl Reed and Associates

Mobile: 970-402-0284

---

From: Christine Waigl <[email-masked]>
Date: Wed, 28 Oct 2015 09:46:03 -0800

On Wed, Oct 28, 2015 at 9:34 AM, Howard Butler <[email-masked]> wrote:
>
>
> That particular statement was *the* issue with SRS in GeoJSON, and
coincidently a linchpin of interoperability that allowed GeoJSON to
proliferate where others struggled.

This is an important point.

> The full mailing list archives, back to the beginning of (GeoJSON) time,
are available for anyone to go back and catch up on this topic. It has been
discussed many times over the years. The IETF doc is a recognition of how
people have actually developed and interoperated in-the-wild software with
GeoJSON in the 7+ years since the specification was pushed out.

That you're getting new people who aren't aware of the full history (or
even the most heroic moments in the history) of GeoJSON is, I guess, both a
bug and a feature of this standardisation process. I understand it must be
frustrating, but not everyone who has use cases different from web mapping
is a pedant.

---

From: Calvin Metcalf <[email-masked]>
Date: Wed, 28 Oct 2015 18:03:02 +0000

re registry, web libraries tend to be measured in KB and large MB range
files would be a burden to user on mobile devices, if it was an api service
that means your app breaks if you can't reach it for some reason like you
are on a cellphone or the site is down. And are you hosting it yourself?
relying on a service? is that service actively supported? etc.  It's not an
impossible task but it is a burden for web libraries.

On Wed, Oct 28, 2015 at 1:42 PM Carl Reed <[email-masked]> wrote:

> http://docs.opengeospatial.org/is/12-007r2/12-007r2.html . Please note
> that KML references the appropriate EPSG codes but references the OGC
> registry as opposed to the EPSG registry.
>
> On Wed, Oct 28, 2015 at 10:58 AM, Calvin Metcalf <[email-masked]
> > wrote:
>
>>>> So many systems present also means there are many products on the
>>>> market using them.  These products would be barred from using the GeoJSON

---

From: Howard Butler <[email-masked]>
Date: Wed, 28 Oct 2015 13:09:05 -0500

> On Oct 28, 2015, at 12:46 PM, Christine Waigl <[email-masked]> wrote:
> 
> That you're getting new people who aren't aware of the full history (or even the most heroic moments in the history) of GeoJSON is, I guess, both a bug and a feature of this standardisation process.

Thanks for the reminder. I'm anxious about ripping open the SRS pillow again and having to try to stuff all the feathers back in. 

> I understand it must be frustrating, but not everyone who has use cases different from web mapping is a pedant.

One of GeoJSON's strengths is that it has stayed pretty true to who brung it to the dance (web, browsers, data interop -- in that order I would say). It is used everywhere. The original group has taken great care to not disrupt the interoperability story of GeoJSON in favor of being more correct, more flexible, or more compact in future versions. In fact, we've never done a future version. The IETF effort represents the very first attempt at iterating the document in any meaningful way. 

Howard

---

From: Martin Thomson <[email-masked]>
Date: Thu, 29 Oct 2015 06:55:08 +0900

> Why the exclusivity of WGS 84?

If this is a serious issue for you, then please open a thread and we
can discuss it.

---

From: Sean Gillies <[email-masked]>
Date: Wed, 28 Oct 2015 16:08:10 -0600

Hi Alex,

On Wed, Oct 28, 2015 at 6:01 AM, Alexandre Petrescu
<[email-masked]> wrote:
> I still think this looks reductive, because tehre are many more such systems
> out there, not just WGS 84.  For example, a recent consumer

We wanted to standardize on a single global reference system and
couldn't think of a reason why that single system shouldn't be WGS84.
WGS84 isn't perfect, but is very widely used, and it seems like a
location standard benefits from a single reference system just as much
as date and time on the internet (RFC 3339) benefits from a single
calendar system (Gregorian). That's all. Nothing is implied about the
fitness of MGRS or BNG in their domains.

I'm happy that adoption has your support and happy to have your participation!

-- 
Sean Gillies