Usability question about geof:geometryN
Opened this issue · 3 comments
In wake of the upcoming GeoSPARQL 1.1, I want to take the chance to clarify some things (maybe the answer is already clearly in the standard and I just missed it, in which case my apologies)
I have some concerns regarding the usability of the function geof:geometryN and geof:numGeometries
I understand this pair of functions might allow to access the individual geometries that make up a multipart geometry
However, to use it efficiently, one cannot use a single SPARQL query. First, the number of geometries needs to be queried, then a query to fetch each individual geometry needs to be constructed (possibly programmatically)
Could it be possible to introduce a rule instead, so that
?eachGeometry geo:dump ?multiGeometry
would induce solution bindings for each part of the multipart geometry?
Nb, we have implemented a proof of concept of this for use with Apache Jena here: https://github.com/Scaseco/jenax/blob/jena-4.8.0/jenax-arq-parent/jenax-arq-plugins-parent/jenax-arq-plugins-bundle/src/main/java/org/aksw/jena_sparql_api/sparql/ext/geosparql/STDumpPF.java#L37
I think this is a good idea. It could be done using a rule, but it may very well also be done using a function.
I would take this for discussion and as public comment feedback in the next GeoSPARQL meeting, where we could determine whether this is still GeoSPARQL 1.1 or 1.2 scope.
- @SimonBin can we please rename
geo:dumptogeo:eachGeometry? - @situx "done using a function": SPARQL doesn't support multivalued functions (
geof), so this must be a magic predicate (geo)
#476 asks for some simple clarifications to geof:geometryN and geof:numGeometries. This new magic predicate should be related to them.
@SimonBin can we please rename geo:dump to geo:eachGeometry?
this was just a suggestion, because of https://postgis.net/docs/ST_Dump.html
our proof of concept currently uses this vendor-specific name: http://jena.apache.org/spatial#st_dump
I don't have any strong feelings for any particular name