Include all functions already described in Simple Features for SQL

[lvdbrink]

Official change request: [OGC CR 599](Include all functions already described in Simple Features for SQL)

GeoSPARQL describes a number of SPARQL functions that can be implemented by developers of SPARQL endpoints. It would be beneficial for working with spatial data in SPARQL if more ways of interacting with spatial data were available. The routines and functions described in the Simple Features for SQL specification (06-104r4) are well known and have been implemented in different libraries and data storage systems. It could be a relatively simple effort to transpose the existing definitions to RDFS/OWL, so developers of SPARQL systems can implement those often very useful functions, either by using existing libraries, or by new development.

[jabhay]

MoSCoW poll created

[FransKnibbe]

This change request overlaps with other change requests asking for specific sets of additional functions.

[situx]

I have created a table illustrating functions present in Simple Features SQL and in the respective GeoSPARQL versions to further this discussion. Please add corrections or items I missed to this table.

N/A=Not available

Simple Features SQL	GeoSPARQL Equivalent	Since GeoSPARQL	Related Property Available	Since GeoSPARQL
2.1.1.1 Basic Methods on Geometry
Dimension():Double	N/A	-	geo:dimension	1.0
GeometryType():String	Class of geometry instance	1.0	N/A	-
SRID():Integer	geof:getSRID	1.0	geo:inSRS	1.1
Envelope():Geometry	geof:envelope	1.0	geo:hasBoundingBox	1.1
AsText():Geometry	geof:asWKT	1.1	geo:asWKT	1.0
AsBinary():Geometry	N/A	-	N/A	-
IsEmpty():Geometry	N/A	-	geo:isEmpty	1.0
IsSimple():Geometry	N/A	-	geo:isSimple	1.0
Boundary():Geometry	geof:boundary	1.0	N/A	-
2.1.1.2 Spatial Relations
Equals(Geometry):Integer	geof:sfEquals	1.0	geo:sfEquals	1.0
Disjoint(Geometry):Integer	geof:sfDisjoint	1.0	geo:sfDisjoint	1.0
Intersects(Geometry):Integer	geof:sfIntersects	1.0	geo:sfIntersects	1.0
Touches(Geometry):Integer	geof:sfTouches	1.0	geo:sfTouches	1.0
Crosses(Geometry):Integer	geof:sfCrosses	1.0	geo:sfCrosses	1.0
Within(Geometry):Integer	geof:sfWithin	1.0	geo:sfWithin	1.0
Contains(Geometry):Integer	geof:sfContains	1.0	geo:sfContains	1.0
Overlaps(Geometry):Integer	geof:sfOverlaps	1.0	geo:sfOverlaps	1.0
Relate(Geometry, IntersectionpatternMatrix:String):Integer	geof:relate	1.0	N/A	-
2.1.1.3 Spatial Analysis
Buffer(Distance:double):Geometry	geof:buffer	1.0	N/A	-
ConvexHull():Geometry	geof:convexHull	1.0	N/A	-
Intersection():Geometry	geof:intersection	1.0	N/A	-
Union():Geometry	geof:union	1.0	N/A	-
Difference():Geometry	geof:difference	1.0	N/A	-
SymDifference():Geometry	geof:symDifference	1.0	N/A	-
2.1.2.1 GeometryCollection
NumGeometries():Integer	N/A	-	N/A	-
GeometryN(N:integer):Geometry	N/A	-	N/A	-
2.1.3.1 Point
X():Double	N/A	-	N/A	-
Y():Double	N/A	-	N/A	-
Z():Double (not in the SQL spec, but a logical extension)	N/A	-	N/A	-
M():Double (not in the SQL spec, but a logical extension)	N/A	-	N/A	-
2.1.5.1 Curve
Length():Double	N/A	-	geo:hasLength	1.1
StartPoint():Point	N/A	-	N/A	-
EndPoint():Point	N/A	-	N/A	-
IsClosed():Point	N/A	-	N/A	-
IsRing():Point	N/A	-	N/A	-
2.1.6.1 LineString
NumPoints():Integer	N/A	-	N/A	-
PointN():Point	N/A	-	N/A	-
2.1.9.1 Surface
Area():Double	N/A	-	geo:hasArea	1.1
Centroid():Point	geof:centroid	1.1	geo:hasCentroid	1.1
PointOnSurface():Point	N/A	-	N/A	-
2.1.10.1 Polygon
ExteriorRing():LineString	N/A	-	N/A	-
NumInteriorRing():Integer	N/A	-	N/A	-
InteriorRingN(N:Integer):LineString	N/A	-	N/A	-

[FransKnibbe]

@situx: nice work! The table provides a good overview.
Some questions:

• What does N/N mean?
• I could not find geof:centroid in funcsrules.ttl. Does it exist somewhere?
• I have added geo:hasArea to the table.

[situx]

N/N=Not needed, I updated the comment.
geof:centroid is a function we defined in the SpatialAggregate definition
You can for now find it in the sa_functions.ttl file, but we should probably merge this file with funcsrules before release.
I created it because we first anticipated to create a different namespace for spatial aggregate functions.

[FransKnibbe]

@situx, why is GeometryType() classified as not needed? I think it would be useful to be able to select geometries by type.
Issue 42 asks for a property to indicate geometry type.

[situx]

I think that the geometry type should be represented by the class, e.g. a geometry classified as sf:Polygon should be classification enough. If it is an even more special polygon, one could subclass sf:Polygon.
Do you think this approach is not sufficient?
Revisiting #42 it seems that there are differing opinions on this and indeed the property might be warranted. Maybe something to discuss in the next meeting

[FransKnibbe]

I think the main point is to have access to the geometry type. Indeed that could be accomplished by subclassing Geometry too. It should be a good topic for discussion. On one hand, having many subclasses could be perceived as bloat. On the other hand, it allows better semantics. For example, properties like hasArea could be defined only on geometry types that actually have an area.

[jabhay]

TODO

• @jabhay tol add the table above into Annex C, Mapping to Simple Features for SQL.

[situx]

This has been closed by mistake.
Yes, we added the equivalence table to the standard, but what we actually wanted to achieve here is add all functions to the standard.