Proposal for geometry.uuid property

[docuracy]

PROPOSAL: An optional uuid property that can be used in Geometry Collections to associate particular geometries with one or more of their parent feature's types. This might be used, for example, to indicate separate points for the creation, discovery, and repository of archaeological artefacts. Corresponding feature.types would have a geometries array of one or more such UUIDs.

Outlined in LP.json.

[rybesh]

I'm concerned that this potentially violates §3.1.8 of RFC 7946:

The "geometries" member of a GeometryCollection describes the parts of this composition. Implementations SHOULD NOT apply any additional semantics to the "geometries" array.

More generally, rather than coming up with ad hoc ways of relating features, types, and geometries via UUID references, these kinds of relations should be expressed in RDF. If you want to assert something about a geometry, give it an @id attribute so that it can be the subject or the object of a triple.

[docuracy]

Thanks, Ryan. Yes, @id is the logical way to go. I've updated this draft JSON Schema.

---

Regarding RFC 7946, I don't think this proposal interferes with the semantics of the geometries array itself: that would remain simply an array of GeoJSON geometry objects.

As for geometry objects, LP has already added geowkt, when, and certainty properties: this proposal is to add another.

And to clarify for other readers what RFC 7946 means:

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. [RFC 2119]

Contrast with:

MUST NOT: This phrase, or the phrase "SHALL NOT", mean that the definition is an absolute prohibition of the specification. [RFC 2119]

Do we understand the full implications? What could possibly go wrong?!?

[rybesh]

My concern here was that it changes the meaning of a GeometryCollection from a single composition of coordinates, to a set of related geometries grouped together under some heading… arguably having different geometries at different points in time already does that, but it that case it still makes sense to compose them.

How would someone decide between using a FeatureCollection vs. a single Feature with type-specific geometries in a GeometryCollection?

[docuracy]

I think that would be determined by the nature of the items in the dataset: this proposal has arisen only because we are creating sets of non-place objects (e.g. archaeological finds, drawings that can be geolocated) as noted in Issue #40. The data could be represented as a FeatureCollection of points with links to represent the objects, but that is conceptually very different from a FeatureCollection of objects each with its own GeometryCollection of type-specific geometries.