Apologies for the delayed reply about the GeoSPARQL module.
There hasn't been much feedback. The main of note was around supporting
equivalent functionality to jena-spatial (property/filter functions,
lat/lon predicates and spatial index), which are now included along with
some other useful property/filter functions.
I'll get onto moving them to Maven etc. but likely next weekend.
Thanks,
Greg
On 03/04/2019 22:33, Marco Neumann wrote:
ok sounds reasonable, so I might be able to move along with jena spatial
On Wed, Apr 3, 2019 at 10:28 PM Andy Seaborne <a...@apache.org> wrote:
I'm only suggesting removing it from Fuseki, not remove the module.
Fuseki merely includes it.
Putting it back does not even need repacking:
java -cp fuseki-jar:spatial.jar <main class> $@
should work - JenaSystem.init will happen and ServiceLoader cause
spatial to be available as before.
Andy
On 03/04/2019 22:11, Marco Neumann wrote:
ok Andy, I will prepare for the removal of jena spatial from the jena
project. but since I use jena spatial in production it will take a while
to
switch and I will stay with 3.10 here. what exactly will you do with the
code base? just remove the code from the fuseki release and the jena
spatial folder in the source?
On Wed, Apr 3, 2019 at 9:17 PM Andy Seaborne <a...@apache.org> wrote:
We have three major streams outstanding.
Have I missed anything?
1/ GeoSPARQL
2/ Prometheus metrics
3/ ​SurroundQueryParser
== GeoSPARQL
Greg - apologies for being tardy on this one. It looks in good shape.
Did you hear from anyone after the request for feedback?
This is two modules: geosparql-jena and geosparql-fuseki
A suggestion for how to proceed if you have the time for 3.11.0 is that
we include these basically as-is and remove jena-spatial from Fuseki
which we have been signalling for a while.
Suggestion:
jena-geosparql
jena-fuseki/jena-fuseki-geospatial
and under org.apache.jena.geosparql and org.apache.jena.fuseki.geosparql
It would have to be maven.
Documentation:
This does not have to timed with the release though desirable to have
some instructions on the website.
Looking the modules, it has its own specialised Fuseki incarnation with
command line arguments and also internally a system wide configuration.
maybe, later, we might want to merge the Fuseki setup but exactly how
and whether separate is better for users due to the specialised nature
can wait. Release should get feedback after it is incorporated -
"release early, release often".
Greg - how does that sound?
PMC - having more eyes on this would be helpful.
If the timing is OK, we can work on details on the ticket JENA-664 (or
email on dev@).
== JENA-1691 : Prometheus metrics
This is getting there. We have the code worked out, the packaging needs
a bit of discussion; importantly it is missing L&N changes due to
BSD-binaries in the combined jars mean some L&N changes.
== JENA-1690 : ​SurroundQueryParser
Looks like this is ready and waiting for someone to merge it.
With all that, it looks like some things to sort out.
We can wait a bit longer for 3.11.0, or do 3.11.0 fairly soon with
whatever is ready, including getting things in and expect to further
refine, then advance the timing on 3.12.0.
Thoughts?
Andy
