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
