Subject: [Geojson] Geometry ids

From: Sean Gillies <[email-masked]>
Date: Wed, 17 Feb 2016 15:53:19 -0700

Hi all,

I'm bring up a comment of mine from
https://github.com/geojson/draft-geojson/issues/150 for a wider audience
here.

Feature ids give us a way to select within a collection and a way to assert
identity across collections. Geometries, on the other hand, have no
existence outside the feature that contains them. They are just a property
of the feature. Features can't share them or have more than one of them, so
the utility of an id seems nearly zero.

Here I've asserted some differences between features and geometries that
aren't exactly backed up by the text in the draft. I'd like to fix that
unless there are objections.
-- 
Sean Gillies

---

From: Erik Wilde <[email-masked]>
Date: Thu, 18 Feb 2016 00:56:44 +0100

hello sean.

On 2016-02-17 23:53, Sean Gillies wrote:
> Feature ids give us a way to select within a collection and a way to
> assert identity across collections. Geometries, on the other hand, have
> no existence outside the feature that contains them. They are just a
> property of the feature. Features can't share them or have more than one
> of them, so the utility of an id seems nearly zero.

i am not sure why that's the case. a geometry can be a top-level GeoJSON 
object, in which case it very well may have an identity. i agree that if 
geometry is contained in a feature that it's questionable whether the 
identity shouldn't be with on the feature-level only. but if there are 
geometry top-level objects, why wouldn't those have identity and want to 
represent that somehow?

cheers,

dret.

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

---

From: Tim Schaub <[email-masked]>
Date: Wed, 17 Feb 2016 17:45:06 -0700

In the original spec, we suggested adding an "id" member to features
so that GeoJSON would work well with other software that operates on
geospatial data - where generally features have identifiers and
geometries don't.

This suggestion (to add language about an "id" member for all GeoJSON
objects) appears to me to be coming from an examination of the spec in
isolation - not necessarily considering its place among other
geospatial data interchange formats or processing software.

While I understand the questions that are being brought up, I am more
compelled by arguments about fitting in with the rest of the
geospatial ecosystem rather than arguments about logical consistency
of the spec in isolation.

Tim

On Wed, Feb 17, 2016 at 4:56 PM, Erik Wilde <[email-masked]> wrote:
> _______________________________________________
> GeoJSON mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/geojson

---

From: Tim Schaub <[email-masked]>
Date: Wed, 17 Feb 2016 17:51:30 -0700

And, while Sean doesn't believe in slippery slopes, if we suggest an
"id" member for geometries, it is not hard to imagine that someone
would suggest that implementations MUST maintain the "id" members, and
then GeoJSON would no longer work in systems where there is no place
for "id" in geometry.

🎈

---

From: Sean Gillies <[email-masked]>
Date: Thu, 18 Feb 2016 11:46:27 -0700

Erik,

> geometry top-level objects, why wouldn't those have identity and want to

Yes, a geometry can be a top-level object. And a GeometryCollection can be
a top-level object, too.

I've written and maintain software that reads and writes sequences of
feature-less GeoJSON geometries (Rasterio's feature extraction works like
this), so this isn't a hypothetical issue for me. I am content with
geometries being an anonymous, literal thing. Maybe there are some
important uses for geometry identifiers, but I don't know what they are.

I feel like giving ids to the parts of a GeometryCollection would be
contrary to what we've written in
https://github.com/geojson/draft-geojson/blob/master/considerations.mkd#geometry-collections
:

> Geometry collections have a different syntax from single type geometry
> objects (points, line strings, and polygons) and homogeneously typed
> multipart geometry objects (multipoints, multiline strings, and
> multipolygons) but have no different semantics. Although a geometry
> collection object has no "coordinates" member, it does have coordinates:
> the coordinates of all its parts belong to the collection. The "geometries"
> member of a geometry collection describes the parts of this composition.
> Implementations SHOULD NOT apply any additional semantics to the
> "geometries" array.
>
> To maximize interoperability implementations SHOULD avoid nested geometry
> collections. Furthermore, geometry collections composed of a single part or
> a number of parts of a single SHOULD be avoided when that single part or a
> single object of multi-part type (MultiPoint, MultiLineString, or
> MultiPolygon) could be used instead.
>
We're asserting here that parts of a GeometryCollection have no identity of
their own. How would we square this with geometry ids?

-- 
Sean Gillies

---

From: <[email-masked]>
Date: Thu, 18 Feb 2016 21:56:06 +0000

Sean Gillies wrote:

Ø  Maybe there are some important uses for geometry identifiers, but I don't know what they are.

The one I’m aware of is where a geometry is used in more than one feature. E.g. fence, edge of road.
So serializing once and using multiple times by-reference is both efficient and error-avoiding.
This requires a reliable geometry identifier framework.

Not sure if this is in scope for GeoJSON, but definitely for geometry identifiers ☺

Simon

---

From: Martin Daly <[email-masked]>
Date: Thu, 18 Feb 2016 22:13:59 +0000

By that argument we could allow id’s for everything, eg reference string property values because those can be long and error-prone, right?

TopoJSON is the geometry sharer’s friend, not GeoJSON.

Martin

From: GeoJSON [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: 18 February 2016 21:56
To: [email-masked]; [email-masked]
Cc: [email-masked]
Subject: Re: [Geojson] Geometry ids

Sean Gillies wrote:

Simon

---

From: Sean Gillies <[email-masked]>
Date: Thu, 18 Feb 2016 15:12:55 -0700

On Thu, Feb 18, 2016 at 2:56 PM, <[email-masked]> wrote:

> Not sure if this is in scope for GeoJSON, but definitely for geometry
> identifiers J
>
>
>
> Simon
>
>
>

Simon,

TopoJSON does this already, and without geometry identifiers. It uses
nothing more than array indexes.

  https://github.com/mbostock/topojson-specification/blob/master/README.md

Absorbing TopoJSON into GeoJSON is out of scope, yes.

-- 
Sean Gillies

---

From: <[email-masked]>
Date: Thu, 18 Feb 2016 22:26:06 +0000

Cool – thanks for the clarification/pointer.

In that case I agree that we should resist the urge to explicitly identify everything.
Features, definitely, because that is the fundamental organizing unit in the agreed meta-model.
Everything else (particularly including geometry) is subordinate.

Simon

From: Martin Daly [mailto:[email-masked]]
Sent: Friday, 19 February 2016 9:14 AM
To: Cox, Simon (L&W, Clayton) <[email-masked]>; [email-masked]' <[email-masked]>; [email-masked]' <[email-masked]>
Cc: [email-masked]' <[email-masked]>
Subject: RE: [Geojson] Geometry ids

Martin

From: GeoJSON [mailto:[email-masked]] On Behalf Of [email-masked]<mailto:[email-masked]>
Sent: 18 February 2016 21:56
To: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [Geojson] Geometry ids

Sean Gillies wrote:

Simon

---

From: Erik Wilde <[email-masked]>
Date: Fri, 19 Feb 2016 09:40:37 +0100

hello sean.

On 2016-02-18 19:46, Sean Gillies wrote:
> We're asserting here that parts of a GeometryCollection have no identity
> of their own. How would we square this with geometry ids?

well, i'd say that all "id" were proposed to be optional so it would be 
up to applications to decide whether they want to make any of those 
objects identifiable or not. but it seems like there's little enthusiasm 
for blessing "id" for anything other than a "feature", so i am going to 
close #150 without action.

thanks for the discussion and cheers,

dret.