Subject: [Geojson] closing #64 (proposing to merge #132)

From: Erik Wilde <[email-masked]>
Date: Sat, 30 Jan 2016 09:48:45 -0800

hello.

https://github.com/geojson/draft-geojson/issues/64 is asking to include 
a brief informal appendix about the relationship of the geojson spec and 
RFC 7464 (JSON text sequences).

https://github.com/geojson/draft-geojson/pull/132 proposes to add the 
following appendix:

------------------------

GeoJSON Text Sequences

GeoJSON as defined in this specification consists of exactly one GeoJSON 
object. However, there may be cases in which applications want to 
represent sets or sequences of GeoJSON objects. Representing sets or 
sequences of GeoJSON objects is outside of the scope of this specification.

If such a representation is needed, a new media type is required that 
has the ability to represent sets or sequences. When defining such a 
media type, it may be useful to base it on "JSON Text Sequences" 
[RFC7464], leaving the foundations of how to represent multiple JSON 
objects to that specification, and only defining how it applies to 
GeoJSON objects. However, no such definition is included here, and at 
the time of writing it is unclear if and when there will be a 
specification for "GeoJSON Text Sequences".

--------------------------

thanks for everybody who commented/contributed so far. if there are no 
objections, i will move forward to close #64 by merging #132 into the 
master branch.

thanks and cheers,

dret.

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

---

From: Stefan Hagen <[email-masked]>
Date: Sat, 30 Jan 2016 18:57:02 +0100

+1 for pushing this change now.

"Best," RS
"Stefan."

> Am 30.01.2016 um 18:48 schrieb Erik Wilde <[email-masked]>:
> 
> hello.
> 
> https://github.com/geojson/draft-geojson/issues/64 is asking to include a brief informal appendix about the relationship of the geojson spec and RFC 7464 (JSON text sequences).
> 
> https://github.com/geojson/draft-geojson/pull/132 proposes to add the following appendix:
> 
> ------------------------
> 
> GeoJSON Text Sequences
> 
> GeoJSON as defined in this specification consists of exactly one GeoJSON object. However, there may be cases in which applications want to represent sets or sequences of GeoJSON objects. Representing sets or sequences of GeoJSON objects is outside of the scope of this specification.
> 
> If such a representation is needed, a new media type is required that has the ability to represent sets or sequences. When defining such a media type, it may be useful to base it on "JSON Text Sequences" [RFC7464], leaving the foundations of how to represent multiple JSON objects to that specification, and only defining how it applies to GeoJSON objects. However, no such definition is included here, and at the time of writing it is unclear if and when there will be a specification for "GeoJSON Text Sequences".
> 
> thanks for everybody who commented/contributed so far. if there are no objections, i will move forward to close #64 by merging #132 into the master branch.
> 
> thanks and cheers,
> 
> dret.
> 
> -- 
> _______________________________________________
> GeoJSON mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/geojson

---

From: Martin Daly <[email-masked]>
Date: Sat, 30 Jan 2016 18:02:46 +0000

> objections, i will move forward to close #64 by merging #132 into the master
> branch.

I'm -1 with the current wording.

The preamble could easily be interpreted to mean that GeoJSON can only contain one *feature*, when only one *featurecollection* is the reality. Given that a featurecollection *is* a set or sequence of features, the wording is both misleading and contradicts other parts of the spec.

Also, are you expecting people to want to stream *features* or *featurecollections* or either/ both? I can't divine which it is.

Martin

---

From: Erik Wilde <[email-masked]>
Date: Sat, 30 Jan 2016 10:12:17 -0800

hello martin.

> The preamble could easily be interpreted to mean that GeoJSON can only contain one *feature*, when only one *featurecollection* is the reality. Given that a featurecollection *is* a set or sequence…

the text specifically says *object* and not *feature*. that's a direct 
quote from https://tools.ietf.org/html/draft-ietf-geojson-00#section-2 
which says exactly that: "GeoJSON always consists of a single object."

If you think that's not clear enough, please feel free to suggest 
improvements that you think are more clear.

> Also, are you expecting people to want to stream *features* or *featurecollections* or either/ both? I can't divine which it is.

please refer to the above. #64 and #132 are about RFC 7464, which talks 
about JSON-level features, not something specific to GeoJSON. as such, 
this is specifically about streaming multiple GeoJSON objects.

any improvements or suggestions are welcome, on the list or as commits 
to the PR. thanks,

dret.

---

From: Erik Wilde <[email-masked]>
Date: Sat, 30 Jan 2016 10:54:50 -0800

hello martin.

On 2016-01-30 10:12, Erik Wilde wrote:
>> The preamble could easily be interpreted to mean that GeoJSON can only
>> contain one *feature*, when only one *featurecollection* is the
>> reality. Given that a featurecollection *is* a set or sequence of
>> features, the wording is both misleading and contradicts other parts
>> of the spec.

come to think of it, maybe others are having the same confusion about 
the JSON and GeoJSON levels. please see this slight rewording and let us 
know if it makes you any happier.

https://github.com/geojson/draft-geojson/commit/608b66f63a4b00d41b0f7d5ac4740f648fbf7d23

thanks,

dret.

---

From: Martin Daly <[email-masked]>
Date: Sat, 30 Jan 2016 19:48:46 +0000

> https://github.com/geojson/draft-
> geojson/commit/608b66f63a4b00d41b0f7d5ac4740f648fbf7d23

I'd favour explicit mentions of certain things and certain concepts, for clarity, eg:

"GeoJSON objects as defined in this specification - FeatureCollection, Feature, and Geometry - consist of exactly one JSON object. However, there may be circumstances in which applications need to represent sets or sequences of these objects (over and above the grouping of Feature objects in a FeatureCollection), eg in order to efficiently 'stream' large numbers of Feature objects. The definition of such sets or sequences is outside the scope of this specification."

I'm queasy about including the example, but left it in for now.

I think that the last sentence of the second paragraph is superfluous, because it merely repeats the statement in the last sentence of the first paragraph (albeit applied specifically to RFC7464], and then speculates on the future.

Martin

---

From: Allan Doyle <[email-masked]>
Date: Sat, 30 Jan 2016 14:54:57 -0500

Yes, I like this. Agree that the last sentence of the 2nd paragraph could be left out with no ill effects.

	Allan

> On Jan 30, 2016, at 2:48 PM, Martin Daly <[email-masked]> wrote:
>

---

From: Erik Wilde <[email-masked]>
Date: Sat, 30 Jan 2016 11:55:17 -0800

hello martin.

> I'm queasy about including the example, but left it in for now.

i like that text, thanks for the suggestion. here it is:

https://github.com/geojson/draft-geojson/commit/463f76eedbe77455c2d85afb106b2b856f1c40e1

> I think that the last sentence of the second paragraph is superfluous, because it merely repeats the statement in the last sentence of the first paragraph (albeit applied specifically to RFC7464],…

i have deleted that sentence in the above commit.

thanks and cheers,

dret.

---

From: Erik Wilde <[email-masked]>
Date: Sat, 30 Jan 2016 11:56:54 -0800

in that case we have a thumbs up from you as well. great!

---

From: Martin Thomson <[email-masked]>
Date: Sun, 31 Jan 2016 09:24:20 +1100

On 31 January 2016 at 06:55, Erik Wilde <[email-masked]> wrote:
>> I think that the last sentence of the second paragraph is superfluous,
>> because it merely repeats the statement in the last sentence of the first
>> paragraph (albeit applied specifically to RFC7464], and then speculates on
>> the future.
>
>

The referenced commit shows the sentence still.  I agree with Martin
that it would be best removed.  Failing that, reducing it to "A format
based on [RFC7464] might be appropriate." would be tolerable.