In addition could you or someone with an Apache connection clarify the situation around the JTS license. I remember that the Lucene project voted not to include the JTS dependencies due to its LGPL license. Is that not an issue anymore? Is there a different situation for the Jena project?
On Fri 14 Dec 2018 at 19:17, Greg Albiston <galbis...@mail.com> wrote: > 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 > >> > >> > >> > -- --- Marco Neumann KONA
