Subject: [Geojson] Interoperability guidelines for geometry collections

From: Sean Gillies <[email-masked]>
Date: Wed, 2 Dec 2015 11:20:55 -0700

In https://github.com/geojson/draft-geojson/issues/74 we have rough
consensus for recommending against nested geometry collections and I plan
to make the appropriate edit (in a pull request linked from that issue)
unless there's any new information or arguments to change that consensus.

I feel like interoperability would be helped if we recommended that
GeometryCollections only be used when needed, eg, not doing single member
collection like this

  { "type": "GeometryCollection", "geometries": [ { "type": "Point", ... }
] }

but am not 100% sure that's needed.

Jeff Yutzler suggested that we make the non-alterable semantics of
GeometryCollection more clear like

Maximally interoperable GeoJSON clients will treat all elements of a
> GeometryCollection as part of a whole and will not apply any specialized
> interpretation or semantic meaning to them.
>

I am in favor of this.

-- 
Sean Gillies

---

From: Martin Thomson <[email-masked]>
Date: Thu, 3 Dec 2015 14:28:09 +1100

>> interpretation or semantic meaning to them.

Meaning that a collection of 1 feature is not the same as the feature itself.

---

From: Sean Gillies <[email-masked]>
Date: Thu, 3 Dec 2015 11:30:59 -0700

> Meaning that a collection of 1 feature is not the same as the feature

Yes, this is true. Geometry collections are different.

Feature collections are aggregations of features. Geometry collections are
compositions; a whole with one or more dependent parts. They appear to be
the same kind of collection to implementers because JSON lacks semantics to
make the distinction (other than array vs object, perhaps) and because we
authors were averse to adding a semantic difference when we wrote the
original spec.

I don't think it's appropriate to bring definitions of aggregation and
composition into the draft. I think it will suffice to say that the
semantics of GeometryCollection are that it is just a geometry object
composed of other geometry objects and that extensions can not change its
semantics. Precise wording to be worked out in a pull request linked from
https://github.com/geojson/draft-geojson/issues/74.

-- 
Sean Gillies

---

From: <[email-masked]>
Date: Thu, 3 Dec 2015 20:13:03 +0000

Elsewhere the distinction is made between geometry _complex_ and geometry _collection_. The former is where there are dependencies within a set that make up the whole, while the latter is a loose aggregation, more like the feature collection case.

Simon J D Cox
Research Scientist
Environmental Information Infrastructures
Land and Water
CSIRO

E [email-masked] T +61 3 9545 2365 M +61 403 302 672
Physical: Reception Central, Bayview Avenue, Clayton, Vic 3168
Deliveries: Gate 3, Normanby Road, Clayton, Vic 3168
Postal: Private Bag 10, Clayton South, Vic 3169
http://people.csiro.au/Simon-Cox
http://orcid.org/0000-0002-3884-3420
http://researchgate.net/profile/Simon_Cox3

________________________________
From: GeoJSON on behalf of Sean Gillies
Sent: Thursday, 3 December 2015 6:30:59 PM
To: Martin Thomson
Cc: [email-masked]
Subject: Re: [Geojson] Interoperability guidelines for geometry collections

On Wed, Dec 2, 2015 at 8:28 PM, Martin Thomson <[email-masked]<mailto:[email-masked]>> wrote:

Feature collections are aggregations of features. Geometry collections are compositions; a whole with one or more dependent parts. They appear to be the same kind of collection to implementers because JSON lacks semantics to make the distinction (other than array vs object, perhaps) and because we authors were averse to adding a semantic difference when we wrote the original spec.

I don't think it's appropriate to bring definitions of aggregation and composition into the draft. I think it will suffice to say that the semantics of GeometryCollection are that it is just a geometry object composed of other geometry objects and that extensions can not change its semantics. Precise wording to be worked out in a pull request linked from https://github.com/geojson/draft-geojson/issues/74.

--
Sean Gillies

---

From: <[email-masked]>
Date: Thu, 3 Dec 2015 20:13:06 +0000

Simon J D Cox
Research Scientist

--
Sean Gillies

---

From: Martin Thomson <[email-masked]>
Date: Fri, 4 Dec 2015 15:37:42 +1100

> Yes, this is true. Geometry collections are different.

Ahh, an important distinction.  I think that what you describe is
fine, though I missed this distinction when reading through.  Perhaps
a little acknowledgment of this difference would be helpful.

---

From: <[email-masked]>
Date: Fri, 4 Dec 2015 11:05:42 +0000

Like I said, use of the term "complex" rather than "collection" might help. There is good precedent in the geospatial literature.

Simon J D Cox

Research Scientist

Land and Water

CSIRO

people.csiro.au/Simon-Cox

orcid.org/0000-0002-3884-3420

researchgate.net/profile/Simon_Cox3

________________________________
From: GeoJSON on behalf of Martin Thomson
Sent: Friday, 4 December 2015 4:37:42 AM
To: Sean Gillies
Cc: [email-masked]
Subject: Re: [Geojson] Interoperability guidelines for geometry collections

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