Excellent news.
On Fri 14 Dec 2018 at 20:00, Greg Albiston <galbis...@mail.com> wrote: > Hi Marco, > > The JTS project has been re-licenced last year as Eclipse Publish > License and Eclipse Distribution License, which are Apache compatible > AFAIK. > > Thanks, > > Greg > > On 14/12/2018 19:53, Marco Neumann wrote: > > 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
