Hi Greg,
thanks for your reply. For the record, we have seen several uses of the
(older) geo:lat/long properties in the wild and have used them ourselves
for demos etc. I have therefore updated our integration of GeoSPARQL to
allow mixing both styles. I had to duplicate
SpatialIndex.getGeometryLiteralIndexItems as that is private, so maybe
this could be made public in a future version.
Overall it's a very nice feature and I thank you for your efforts to
integrate this with Jena!
Thanks
Holger
On 2/05/2020 21:17, Greg Albiston wrote:
The use of mixed datasets is not recommended and could be argued to be a
somewhat niche use case. Conversion functions are provided to change
Lat/Lon geometries to GeoSPARQL geometry. A user could also run two
instances and direct the relevant spatial queries to either.
Support for Lat/Lon was included to allow easier transition from the
exisiting Apache Jena Spatial module and not lose the Spatial functions
offered. There is support for both types in the Spatial functions as
this did not introduce excessive additional complexity.
However, there needs to be a boundary to the design at some point and
this was an area where it was deemed more "nice" than "need".
Particularly since the user has several options to access the tool; it
is a variation from the primary use case; and supporting Lat/Lon in any
manner is an enhancement.
Thanks,
Greg
On 01/05/2020 03:59, Holger Knublauch wrote:
See
https://github.com/apache/jena/blob/c9b1ae25f4e73066f3832ba4c4adc0250f42f1de/jena-geosparql/src/main/java/org/apache/jena/geosparql/spatial/SpatialIndex.java#L382
//Only add one set of statements as a converted dataset will duplicate
the same info.
It appears that the index will skip any geo:lat/long triples as soon
as one geosparql:hasGeometry is in the graph. This feels rather
arbitrary as some graphs may well contain a mix of those. If I
understand the comment correctly, this was done under the assumption
that lat/long would also be duplicated as WKT or GML triples. (Maybe
this is a step I am missing somewhere).
Wouldn't it be then more consistent to include both but skip duplicate
lat/long or Points that describe the same Feature?
Thanks
Holger
