GeoSPARQL Docs update request

[lalewis1]

Hi Jena Team,

I just discovered that SPARQL queries using geosparql spatial relations like

FILTER(geof:sfWithin(?geom1, ?geom2))

do not hit the spatial index. But property functions like

?geom geo:sfWithin ?envelope .,

do utilize the spatial index.

The docs state that the Index is optional for geosparql spatial relations which kind of makes it sound like they would use the index if it is provided.

I think that a disclaimer to this effect would be great to include on the geosparql docs page.

A second point:

There also seems to be a massive difference in performance with the spatial index for rectangular polygons and free form polygons.

Would love to see a write-up of why that is and perhaps a warning or something to explain that this is the case. (if it is!?). Noting that this hasn't been an issue until recently when we have started to use Fuseki against ~ 600GB sized datasets.

I note that there is clearly lots of work going on in this space for Jena 6. So this might all be changing soon anyway.

Thanks

[Aklakan]

Some notes that could be relevant for doc updates:

There also seems to be a massive difference in performance with the spatial index for rectangular polygons and free form polygons.

The spatial index only stores (feature, bounding box) entries. So all exact geometry processing happens outside of the index.

We are using this pattern involving the (non-standard) property function spatialF:intersectBoxGeom alot:

SELECT * {
  BIND("POLYGON ((6.475457372470345 51.7037981703763, 6.475457372470346 51.2481032780451, 7.544268491722988 51.24810327804511, 7.544268491722988 51.70379817037631, 6.475457372470345 51.7037981703763))"^^geo:wktLiteral AS ?areaWkt)

  # Pre-filter features by the bbox of the area that DOES use the spatial index
  ?feature spatialF:intersectBoxGeom(?areaWkt) .

  # Get the feature's wkt literal(s)
  ?feature geo:hasGeometry/geo:asWKT ?featureWkt .

  # Exact post-filter that does NOT use the spatial index
  FILTER(!bound(?areaWkt) || geof:sfIntersects(?featureWkt, ?areaWkt))
}

In the code, the SpatialIndex is only used in the property functions (based on the GenericPropertyFunction and GenericSpatialPropertyFunction class hierarchies). I don't see any use of the spatial index in any of the filter functions.

For FILTER(geof:sfWithin(?geom1, ?geom2)) to use the spatial index, one way this could be accomplished (in the future) is an additional algebra rewrite in the optimizer that

• expands the FILTER into the described pattern
• places the ?feature spatialF:intersectBoxGeom(?areaWkt) property function appropriately (usually as early as possible). If the query filters features by both spatial and thematic dimensions, then in general statistics would be needed to decide on which plan is better.

[lalewis1]

We had actually ended up doing a similar pre-bbox filter which was working but we weren't sure why, so this is all good information.

We might move to the same pattern you have mentioned and see how that goes.

Thanks Claus