Hi,
I've been looking at the jena-spatial module and Marco's feedback for
transferring the GeoSPARQL-Jena/Fuskei projects into Jena. I've done
some work on providing the jena-spatial property function for backward
compatibility, but using the core elements from GeoSPARQL-Jena.
This means that both Lat/Lon and Geometry Literal arguments can be used.
It will also support different coordinate reference systems and
serialisations. There is a spatial index in JTS that would be suited to
the jena-spatial property functions and this has been utilised. Some
additional work is needed on transferring/replicating the testing.
For users to transition, I've added filter functions for converting
Lat/Lon to Geometry Literal in queries and a method for adding
Feature-Geometry-Geometry-Literal relations to a Feature-Lat/Lon dataset.
Also, I checked in the GeoSPARQL-Jena code for the “geo” prefix and
there is only use of the full URI
(<http://www.opengis.net/ont/geosparql#>). It does exist in the
GeoSPARQL schema document provided by OGC but isn't used in any of the
statements. So the prefix naming choice would seem to sit at the level
of user query and the documentation.
At the moment all the indexes are using static instances so aren't ideal
for multiple datasets. This is only an actual issue with the query
rewrite and spatial indexes but I'll tidy them all up.
Looking at the spatial-jena code, it seems the current spatial index is
retrieved from the Dataset's Context but I haven't seen where the
Context is setup and assigned. Does this take place as part of the
Assembler?
There is some work to do on this so it would be useful for me to delay
the switchover if the release is before New Year.
Thanks,
Greg
On 13/12/2018 12:13, Marco Neumann wrote:
I would certainly recommend to keep jena-spatial for now and continue
testing jena-GeoSPARQL in parallel an upcoming release. Also I am not sure
if you can manage to hook GeoSPARQL into 3.10 in a timely fashion for a
2018 release. Keep in mind the switch from W3C geo:lat/long to OGC
WKT:Point will cause some pain to jena users. no need to take away
jena-spatial at this point.
On Thu, Dec 13, 2018 at 12:01 PM Andy Seaborne <a...@apache.org> wrote:
On 04/12/2018 12:56, Greg Albiston wrote:
> There is probably a broader question as to how/if these options should
> be integrated in with Fuseki, whether it should be a separate
> application or they should be left out. I think they are useful to a
> user who is looking for a GeoSPARQL solution. Currently,
> GeoSPARQL-Fuseki is using the main/embedded server so doesn't have a
> GUI etc.
The ideal way is to have an assembler for the GeoSPARQL dataset - does
that style work here? If it also needs server-wide settings, they can be
either done on the server level object or done in the GeoSPARQL dataset
assembler with the caution of what happens if there are 2+ such datasets
and different settings.
Given that, would it be better to not immediately jump to retiring
jena-spatial (given that we had a users@ email this week and that's a
rare occurrence!). I'm neutral and wil go with whatever people who have
better knowledge determine to be the best approach.
Andy
