Provide for topology relations between features with explicit geometries at intersections.

[rob-metalinkage]

Features that intersect with geo:touches (or other topological relationships) will have an intersection geometry that may or may not be part of the composite geometry of the features - eg. two polygons sharings a LineSegment, two solids sharing a face denoted by a linear ring.

the requirements are: 1) topological statements can be made without defining geometries (supported currently) 2) intersections are features that may have calculated geometries and metadata about how that was done, 3) intersection geometries may reference internal components (such as points) of the feature geometries by id. 4) intersection features will have constraints about the allowable geometries - e.g. a geo:Face would require a gml:LinearRing (?) 5) intersection features should be consistent with ISO19017 topology complexes, but may be a subset required for "simple features" including its existing "solid geometry" capabilities.

It is expected to be out of scope for GeoSPARQL to support calculation of these intersections or validation that internal ids are self-consistent, but if the information is expressed an implementation can perform additional integrity checking as desired.

[nicholascar]

This is out of scope for GeoSPARQL 1.1, since new features are no longer allowed, but likely in scope for 1.2 as it's an extension to GeoSPARQL but doesn't break anything, so it need not wait for 2.0+.

[nicholascar]

After a GeoSPARQL SWG meeting today, we propose a partial handling of this:

• Use provenance information to indicate the origin of a Geometry
  • use standard PROV ontology elements
  • provide patterns/examples for use of those elements
• Do NOT provide subclasses of Geometry
  • we want to avoid a potential proliferation of specialised Geometry subclasses

Our initial proposed implementation could be like this:

ex:intersection-geometry-x
    a geo:Geometry ;
    prov:wasDerivedFrom
        ex:original-geometry-1 ,
        ex:original-geometry-2 ,
        geo:sfOverlaps ;
.

So prov:wasDerivedFrom provides the list of things that this Geometry is derived from and we can see, if we have details of ex:original-geometry-1 & ex:original-geometry-2 that they are Geometry class objects and we know, from GeoSPARQL, that geo:sfOverlaps is a function that describes how the two geometries were used.

With just the listing of precursor objects we can infer that:

1. this Geometry is derived from others
2. how it is derived - in the example by overlapping

This is more powerful than just classing the Geometry statically as a specialised subclass of Geometry as there are multiple possible 'styles' of an 'IntersectionGeometry`, so we would need a class for each one.

I can see that we might be asked to provide a specialised predicate to indicate the Plan (function) used. I prefer to delegate this understanding to the class of the thing used i.e. knowing that geo:sfOverlaps is a function, as opposed to a Geometry, we know it is the method used. We could use something like sosa:usedProcedure like this:

ex:intersection-geometry-x
    a geo:Geometry ;
    prov:wasDerivedFrom
        ex:original-geometry-1 ,
        ex:original-geometry-2 ;
    ex:usedFunction
        geo:sfOverlaps ;
.

(I had hoped to do 2 x prov:wasDerivedFrom and 1 x prov:hadPlan to show that the GeoSPARQL function was used as the instructions for the derivation, but PROV doesn't allow hadPlan to be used in this way)

This can be used for Feature instances too, viz:

ex:intersection-feature-x
    a geo:Feature ;
    prov:wasDerivedFrom
        ex:original-feature-1 ,
        ex:original-feature-2 ,
        geo:sfOverlaps ;
.

Thoughts @rob-metalinkage?

[rob-metalinkage]

Not really the Use Case I had in mind - I'd be tempted just to use SOSA (which is aligned with PROV) to record observations of relationships.

The Use Case here is one of declaration and design, not observation - i.e. that two objects are known to share a boundary - even if the geometry hasnt been determined yet - so provenance of geometry wouldn't help.

I also don't think having the provenance would help with the case of determining the node, edge or face two 3D objects share in the case of sfTouches for example. Explicit topology can be reasoned over - I dont see how this solution would scale.

[VladimirAlexiev]

Using prov:wasDerivedFrom with resources of different kind (geometries vs functions) is quite displeasing.

This issue is limited only to intersection (which is a symmetric operation), right?