RDF4J and GEOSparql spatial functions not working (or not implemented)

Question

I'm using RDF4J as I got caught by the advertised implementation of GEOSPARQL (which I didn't find in other RDF frameworks). I followed basic guides and tutorial, but unfortunately I haven't been able to perform basically any of the advertised queries.

I read and followed all the documentation at http://docs.rdf4j.org/programming/#_geosparql , and all the examples at http://graphdb.ontotext.com/documentation/standard/geosparql-support.html , and at https://portal.opengeospatial.org/files/?artifact_id=47664 . The only spatial function that seemed to work in a SPARQL query is the geof:distance , all the others do not produce any results.

So I ultimately dug into the code in the package org.eclipse.rdf4j.query.algebra.evaluation.function.geosparql to kind of understand that there are some classes and interfaces that I should probably implements and extends, eg SpatialAlgebra , SpatialSupport , SpatialSupportInitializer . It looks like many of the function are not completely (or partially) implemented in the spatial logic. Apparently, there is a DefaultSpatialAlgebra which returns a lot of notSupported . Anyway, it's quite a mess (and undocumented) understanding what's the right procedure to have GEOSPARQL working properly. They only say that you can implement your own SpatialSupportInitializer , but how to use it afterwards is a mystery.

From the documentation, apparently there's also a way by using other SAILs, but again, nothing is clear about that.

Can anybody provide me with some guidance, or at least a snippet of code where it is shown how to actually pass to the engine a SpatialAlgebra or SpatialSupport or SpatialSupportInitializer , which is not the default one? Or is there any already existing SAIL which implements all these methods, and how can I use it? Thanks.

PS: I'm actually relying on the 2.4.0 M2 version of RDF4J, which doesn't seem to have the org.eclipse.rdf4j.query.algebra.evaluation.function.geosparql package inside (which I imported manually). I tried also with version 2.3.1, but I had the same issue.

Answer 1

Update Since RDF4J 2.4.0-M3, GeoSPARQL function support is a lot more comprehensive. The improved documentation gives a full list of all supported functions, as well as, hopefully, a better explanation on how to get started with GeoSPARQL. The short and sweet of it is that all you need to do is add this maven module:

<dependency>
    <groupId>org.eclipse.rdf4j</groupId>
    <artifactId>rdf4j-queryalgebra-geosparql</artifactId>
    <version>2.4.0-M3</version>
</dependency>

and you're good to go to use GeoSPARQL on any kind of RDF4J repository.

There are several other GeoSPARQL functions supported by RDF4J out of the box: apart from distance , union , intersection , symDifference , difference , convexHull , boundary , envelope , and getSRID are also at a minimum supported. sfContains is currently not part of the default set, unfortunately. This is mostly due to a licensing issue RDF4J had with a previous version of the JTS library (required for polygon support). However, more recent JTS releases are done as part of the LocationTech project, and those license issues have cleared up, so we should hopefully be able to extend this in the near future (there's an issue tracking this at https://github.com/eclipse/rdf4j-storage/issues/89 ).

In the meantime you will indeed need to create your own `SpatialAlgebra` class, which you can add to RDF4J by means of a `SpatialSupportInitializer`. This is a bit of a workaround hack, but you should create a class with `org.eclipse.rdf4j.query.algebra.evaluation.function.geosparql.SpatialSupportInitializer` as its fully-qualified name, and make sure that it extends the `org.eclipse.rdf4j.query.algebra.evaluation.function.geosparql.SpatialSupport` abstract class, overriding its `getSpatialContext` and `getSpatialAlgebra` methods to provide your custom variants. Add to your classpath and restart, RDF4J will pick this up and use your `SpatialAlgebra` implementation instead of its own. The bottom line is: this is all very beta. To be frank, if you think you could handle implementing additional GeoSPARQL functions using the workaround I mentioned above, then we would love to have your input (and if possible also your help) in actually adding this to RDF4J itself.