Subject: Re: [Geojson] Some common ground

From: Jeff Yutzler <[email-masked]>
Date: Thu, 26 Nov 2015 15:47:20 -0500

Martin,
Thank you for this summary. Responses inline...
-Jeff

From: Martin Daly <[email-masked]>
> To: "[email-masked]'" <[email-masked]>
> Cc:
> Date: Thu, 26 Nov 2015 09:32:51 +0000
> Subject: [Geojson] Some common ground
> Among all of the previous emails we do, I think, have some common ground.
>
> Everyone *seems* to be happy:
>
> * for GeoJSON FeatureCollection and Feature objects to be allowed to carry
> additional members
> * that consumers should be allowed to ignore these additional members
> * that producers should be warned that additional members will be ignored
> by some consumers
>
> +1

> Sadly, that is it for the common ground.
>
> Now for the uncommon ground.
>
> 1. Sean, and others, would like these additional members to be called
> "extensions".
>
> +1

> 2. Sean (and others?) would like consumer->producers to make a best effort
> to maintain these additional members.
>
> -1
My view: processors SHOULD NOT maintain additional members unless they
understand the ramifications of doing so.

3. [???]

+0

> 4. Some would like additional members to be allowed on the "geometry"
> objects, eg to discover that the 3rd ordinate is M, not Z.
>
> -1 given that one of the irrefutable tenets of GeoJSON is that you can't
break any of the rules and still call it GeoJSON, it seems unreasonable to
me to allow this.

> 5. Jeff, and others, would like "extensions" to have some kind of
> discoverable description embedded in the JSON so that they are discoverable.
>
> +1

> [(Forgive me if I've forgotten it, but I don't remember seeing a concrete
> proposal to this effect, although I think that some other ones have been
> referenced.) I agree that this is required for truly useful extensions, but
> don't want it because I think that it adds complexity that is not in
> keeping with the spirit and substance of GeoJSON as it stands.]
>
> I can produce a proposal but I figured I would wait for a consensus on the
WHAT before getting into the HOW.

> If we can agree on the common ground, then can we move forward with that
> now, and then tackle the others (ie numbers 1. to 5.) individually or in
> combination, as appropriate, next?
>
> Martin
>
>

---

From: Martin Daly <[email-masked]>
Date: Thu, 26 Nov 2015 21:07:22 +0000

Poor old 3. never made it, and I can’t for the life of me remember if it ever existed. Ho hum.

For the record, I am:

+1
-1
[0]
-1
-1

For a net -2.

Jeff, I, for one, will never agree to something as potentially complex as an extension definition without seeing it first (obviously allowing for later modifications). Colloquially, to celebrate the original givers of thanks, I won’t buy a pig in a poke.

Martin

From: GeoJSON [mailto:[email-masked]] On Behalf Of Jeff Yutzler
Sent: 26 November 2015 20:47
To: [email-masked]
Subject: Re: [Geojson] Some common ground

Martin,

From: Martin Daly <[email-masked]<mailto:[email-masked]>>
To: "[email-masked]<mailto:[email-masked]>'" <[email-masked]<mailto:[email-masked]>>
Cc:
Date: Thu, 26 Nov 2015 09:32:51 +0000
Subject: [Geojson] Some common ground
Among all of the previous emails we do, I think, have some common ground.

* for GeoJSON FeatureCollection and Feature objects to be allowed to carry additional members
* that consumers should be allowed to ignore these additional members
* that producers should be warned that additional members will be ignored by some consumers
+1

1. Sean, and others, would like these additional members to be called "extensions".
+1

2. Sean (and others?) would like consumer->producers to make a best effort to maintain these additional members.
-1
My view: processors SHOULD NOT maintain additional members unless they understand the ramifications of doing so.

3. [???]

+0

4. Some would like additional members to be allowed on the "geometry" objects, eg to discover that the 3rd ordinate is M, not Z.
-1 given that one of the irrefutable tenets of GeoJSON is that you can't break any of the rules and still call it GeoJSON, it seems unreasonable to me to allow this.

5. Jeff, and others, would like "extensions" to have some kind of discoverable description embedded in the JSON so that they are discoverable.
+1

[(Forgive me if I've forgotten it, but I don't remember seeing a concrete proposal to this effect, although I think that some other ones have been referenced.) I agree that this is required for truly useful extensions, but don't want it because I think that it adds complexity that is not in keeping with the spirit and substance of GeoJSON as it stands.]
I can produce a proposal but I figured I would wait for a consensus on the WHAT before getting into the HOW.

If we can agree on the common ground, then can we move forward with that now, and then tackle the others (ie numbers 1. to 5.) individually or in combination, as appropriate, next?

Martin

---

From: Jeff Yutzler <[email-masked]>
Date: Thu, 26 Nov 2015 17:42:50 -0500

Here you go.
https://gist.github.com/jyutzler/da33f075ac416d0445e7

On Thu, Nov 26, 2015 at 4:07 PM, Martin Daly <[email-masked]>
wrote:

> Jeff, I, for one, will never agree to something as potentially complex as
> an extension definition without seeing it first (obviously allowing for
> later modifications). Colloquially, to celebrate the original givers of
> thanks, I won’t buy a pig in a poke.
>

---

From: Martin Daly <[email-masked]>
Date: Thu, 26 Nov 2015 23:04:52 +0000

Hold the turducken. What I meant was:

“Possible common ground”: +1
1. -1
2. -1
3. [0]
4. -1
5. -1

So actually a net score of -3 (“curmudgeon”).

Martin

From: GeoJSON [mailto:[email-masked]] On Behalf Of Martin Daly
Sent: 26 November 2015 21:07
To: 'Jeff Yutzler' <[email-masked]>; [email-masked]' <[email-masked]>
Subject: Re: [Geojson] Some common ground

For the record, I am:

+1
-1
[0]
-1
-1

For a net -2.

Martin

From: GeoJSON [mailto:[email-masked]] On Behalf Of Jeff Yutzler
Sent: 26 November 2015 20:47
To: [email-masked]<mailto:[email-masked]>
Subject: Re: [Geojson] Some common ground

Martin,

3. [???]

+0

Martin