Closed lvdbrink closed 3 months ago
This change request overlaps with other change requests asking for specific sets of additional functions.
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 | - |
@situx: nice work! The table provides a good overview. Some questions:
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.
@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.
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
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.
TODO
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.
We added all Simple Features Functions to the standard when merging #407 so this issue can be closed
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.