yes I would think so. looking forward to test the incorporated Fuseki release.
On Mon, Dec 10, 2018 at 8:20 AM Greg Albiston <galbis...@mail.com> wrote: > Hi Marco, > > There doesn't seem to be an option on the embedded Fuseki Server API to > set for this. > It seems like there is extra configuration done by the Fuseki release > that isn't present in the API. > > If the GeoSPARQL-Fuseki functionality is incorporated into the Fuseki > release then wouldn't this issue be resolved? > > Thanks, > > Greg > > On 09/12/2018 22:43, Marco Neumann wrote: > > Greg, I am doing further testing, when issuing queries from OpenLayers > on a > > remote machine I am getting a "No Access-Control-Allow-Origin header is > > present" error in the browser. I don't have that problem with the > standard > > fuseki release. I don't see an option in the geosparql fuseki server > > configuration to enable this with the current release. > > > > Access to XMLHttpRequest at ' > > > http://192.168.0.15:3030/ds/sparql?query=PREFIX%20PREFIX%20rdfs%3A%20%3Chttp%3A%2F%2Fwww.w3.org%2F2000%2F01%2Frdf-schema%23%3E%20PREFIX%20geo%3A%3Chttp%3A%2F%2Fwww.w3.org%2F2003%2F01%2Fgeo%2Fwgs84_pos%23%3E%20PREFIX%20geosparql%3A%3Chttp%3A%2F%2Fwww.opengis.net%2Font%2Fgeosparql%23%3E%20PREFIX%20geof%3A%3Chttp%3A%2F%2Fwww.opengis.net%2Fdef%2Ffunction%2Fgeosparql%2F%3E%20Select%20*%20WHERE%7B%3Fobject%20%3Chttp%3A%2F%2Fwww.wikidata.org%2Fentity%2FP625%3E%20%3Fgeometry%20.%3Fobject%20rdfs%3Alabel%20%3Flabel%20.%20%3Fobject%20geo%3Alat%20%3Flat%20.%20%3Fobject%20geo%3Along%20%3Flon%20.%20FILTER(geof%3AsfWithin(%3Fgeometry%2C%22POLYGON((53.329999999999984%20-6.199999999999999%2C53.329999999999984%203.8000000000000007%2C63.329999999999984%203.8000000000000007%2C63.329999999999984%20-6.199999999999999%2C53.329999999999984%20-6.199999999999999))%22%5E%5Egeosparql%3AwktLiteral))%7D&output=json > ' > > from origin 'http://192.168.0.15' has been blocked by CORS policy: No > > 'Access-Control-Allow-Origin' header is present on the requested > resource. > > > > > > On Tue, Dec 4, 2018 at 1:29 PM Marco Neumann <marco.neum...@gmail.com> > > wrote: > > > >> > >> On Tue, Dec 4, 2018 at 1:04 PM Greg Albiston <galbis...@mail.com> > wrote: > >> > >>> Hi Marco, > >>> > >>> 2. The GeoSPARQL-Fuseki application has some options for convenience in > >>> setting up the Fuseki server. It looks like the two minute delay is > >>> caused by applying RDFS inferencing to the dataset and then writing the > >>> results into the datset (i.e. Jena operations). The GeoSPARQL schema > has > >>> a class and property hierachy that a user can apply to their dataset > for > >>> some of the functionality. The inferencing is applied by default when > >>> loading a file, but also when connecting to a TDB, in case it hasn't > >>> been done manually by the user. The other potentially costly operation > >>> is creating "hasDefaultGeometry" properties, which is switched off by > >>> default. > >>> > >> ah OK that's good to know > >> > >> > >>> The following line should lead to quicker loading the second time. > >>> > >>> ./geosparql-fuseki --loopback false --tdb TDB1 --inference > >> > >> this looks useful I will check it out tonight > >> > >> > >>> I could change the setup so that file loading applies inferencing by > >>> default and TDB does not, but I thought picking one would be better for > >>> consistent behaviour. Always true means less burden for users working > >>> out why they might have a problem after loading their dataset. > >>> > >>> 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. > >> > >>> 3. I get what you mean about the invalidty of the query now. The > polygon > >>> is invalid because it is not closed. However, I'm unclear about how > >>> these errors and warnings are handled any different to if there was a > >>> SPARQL syntax error. A Query Parse Exception is thrown with full stack > >>> trace. The error highlights the specific problem while the warning > shows > >>> the context of the error and stack trace. This made it easier to hunt > >>> down these kinds of problems when they could be coming from a query or > >>> the dataset. What would you be looking for instead? > >>> > >> it would be great if we could tie this closer into query processor and > >> have the query canceled on a spatial pre processor error like the one > above > >> and report something to the user. because now it seems to hit all wkts > in > >> the dataset before finishing up (of course ignoring LIMIT in the sparql > >> query) while the user waits with no further information to be finally > >> presented with a an empty results table. > >> > >> > >> Best, > >> Marco > >> > >> > >> > >>> Thanks, > >>> > >>> Greg > >>> > >>> On 04/12/2018 12:01, Marco Neumann wrote: > >>>> comments inline > >>>> > >>>> On Mon, Dec 3, 2018 at 5:14 PM Greg Albiston <galbis...@mail.com> > >>> wrote: > >>>>> Hi Marco, > >>>>> > >>>>> 1. As mentioned this shouldn't be too difficult to support. > >>>>> > >>>> indeed not difficult but needs a decision > >>>> > >>>> you could try with the following geonames dataset > >>>> > >>>> all-geonames_lotico.ttl.gz > >>>> > >>>> > >>>> > >>>>> 2. Yes, the indexing, or rather caching, is in-memory, but it is > >>>>> on-demand. There shouldn't be any delay at start-up beyond what Jena > >>>>> needs to do. The cost comes during query execution. The key invariant > >>>>> data produced for solutions is retained for a short period of time > (but > >>>>> can be configured to be retained until termination). Some regularly > >>>>> re-used info is always kept until termination (e.g. any spatial > >>>>> reference system transformation that has been requested). > >>>>> > >>>> the following will create and populate the TDB dataset > >>>> > >>>> ./geosparql-fuseki --loopback false --rdf_file ./lm.ttl --tdb TDB1 > >>>> > >>>> I presume this message refers to the creation of the spatial cache / > >>> index > >>>> 6:05:46.685 INFO Applying GeoSPARQL Schema - Started > >>>> 6:07:44.826 INFO Applying GeoSPARQL Schema - Completed > >>>> > >>>> next time I can call TDB directly > >>>> > >>>> ./geosparql-fuseki --loopback false --tdb TDB1 > >>>> > >>>> 6:08:38.665 INFO Applying GeoSPARQL Schema - Started > >>>> 6:10:18.661 INFO Applying GeoSPARQL Schema - Completed > >>>> > >>>> takes approximately 2m for a very small data set. the same fuseki with > >>>> tdb+jena-spatial restarts almost instantaneously even with reasonably > >>> large > >>>> data sets (see geonames). > >>>> > >>>> > >>>>> The main benefit of this is de-serialising geometry literals. The > >>>>> spatial relations arguments are between a pair of geometry literals, > >>> one > >>>>> of which is likely to be the same in the next solution, so keeping > hold > >>>>> of both means in alot of cases the de-serialisation can be avoided > for > >>>>> one (and possibly both if still retained from a previous set of > >>> solutions). > >>>> might be a good idea to serialize the cache object of de-serialisized > >>>> geometries to disk to speed up the boot process. maybe Andy could > >>> assist or > >>>> even align this with tdb > >>>> > >>>> > >>>>> The aim was to only do work that's needed, not do repeat work and to > be > >>>>> generally quick (i.e. rely on JTS to be optimised for quick solutions > >>>>> between the geometry pairs and Jena to optimise queries). There are > 24 > >>>>> spatial relations and about half a dozen other functions so > >>>>> pre-computing every combination gets big quickly and produces data > that > >>>>> users might not want/use. > >>>>> > >>>>> A rough check of most the spatial relations only requires a bounding > >>> box > >>>>> intersection or type check, so negative results can be quickly > >>>>> discarded. I looked into caching and storing to file, but there just > >>>>> wasn't the benefit in my use case. It took longer to load up then > >>>>> execute than just execute from fresh and cache. Also, the spatial > >>>>> indexes implemented by JTS aren't designed/suited for the spatial > >>>>> relations. If there is a use-case that gets more benefit from > >>>>> pre-computing or storing between programme execution then I'm sure it > >>>>> can be adapted for, but in the context of GeoSPARQL this approach was > >>>>> effective. > >>>>> > >>>>> 3. If you could send me the dataset that causes these errors then > I'll > >>>>> happily have a look into it. > >>>>> > >>>> you can use this simple list of point geometries here > >>>> > >>>> http://www.lotico.com/lm.ttl.gz > >>>> > >>>> this query will parse and execute > >>>> > >>>> PREFIX geo: <http://www.opengis.net/ont/geosparql#> > >>>> PREFIX geof: <http://www.opengis.net/def/function/geosparql/> > >>>> > >>>> SELECT ?well > >>>> WHERE { > >>>> ?well <http://www.wikidata.org/entity/P625> ?geometry . > >>>> FILTER(geof:sfWithin(?geometry,"POLYGON((-10 50,2 50,2 55,-10 > 55,-10 > >>>> 50))"^^geo:wktLiteral)) > >>>> } LIMIT 10 > >>>> > >>>> this one will parse and fail > >>>> > >>>> PREFIX geo: <http://www.opengis.net/ont/geosparql#> > >>>> PREFIX geof: <http://www.opengis.net/def/function/geosparql/> > >>>> > >>>> SELECT ?well > >>>> WHERE { > >>>> ?well <http://www.wikidata.org/entity/P625> ?geometry . > >>>> FILTER(geof:sfWithin(?geometry,"POLYGON((-10 50,2 50,2 55,-10 > 55,-10 > >>>> 51))"^^geo:wktLiteral)) > >>>> } LIMIT 10 > >>>> > >>>> warn/error messages > >>>> > >>>> 6:17:45.887 ERROR Points of LinearRing do not form a closed > linestring - > >>>> Illegal WKT literal: POLYGON((-10 50,2 50,2 55,-10 55,-10 51)) > >>>> 6:17:45.887 WARN General exception in (< > >>>> http://www.opengis.net/def/function/geosparql/sfWithin> ?geometry > >>>> "POLYGON((-10 50,2 50,2 55,-10 55,-10 51))"^^< > >>>> http://www.opengis.net/ont/geosparql#wktLiteral>) > >>>> org.apache.jena.datatypes.DatatypeFormatException: Points of > LinearRing > >>> do > >>>> not form a closed linestring - Illegal WKT literal: POLYGON((-10 50,2 > >>> 50,2 > >>>> 55,-10 55,-10 51)) > >>>> at > >>>> > >>> > io.github.galbiston.geosparql_jena.implementation.datatype.WKTDatatype.parse(WKTDatatype.java:109) > >>>> at > >>>> > >>> > io.github.galbiston.geosparql_jena.implementation.GeometryWrapper.extract(GeometryWrapper.java:905) > >>>> at > >>>> > >>> > io.github.galbiston.geosparql_jena.implementation.GeometryWrapper.extract(GeometryWrapper.java:834) > >>>> at > >>>> > >>> > io.github.galbiston.geosparql_jena.geof.topological.GenericFilterFunction.exec(GenericFilterFunction.java:57) > >>>> at > >>>> > >>> > io.github.galbiston.geosparql_jena.geof.topological.GenericFilterFunction.exec(GenericFilterFunction.java:42) > >>>> at > >>>> > >>> > org.apache.jena.sparql.function.FunctionBase2.exec(FunctionBase2.java:55) > >>>> at > >>>> > org.apache.jena.sparql.function.FunctionBase.exec(FunctionBase.java:63) > >>>> at > >>>> org.apache.jena.sparql.expr.E_Function.evalSpecial(E_Function.java:89) > >>>> at > >>>> org.apache.jena.sparql.expr.ExprFunctionN.eval(ExprFunctionN.java:100) > >>>> at > >>>> org.apache.jena.sparql.expr.ExprNode.isSatisfied(ExprNode.java:41) > >>>> at > >>>> > >>> > org.apache.jena.sparql.engine.iterator.QueryIterFilterExpr.accept(QueryIterFilterExpr.java:49) > >>>> at > >>>> > >>> > org.apache.jena.sparql.engine.iterator.QueryIterProcessBinding.hasNextBinding(QueryIterProcessBinding.java:69) > >>>> at > >>>> > >>> > org.apache.jena.sparql.engine.iterator.QueryIteratorBase.hasNext(QueryIteratorBase.java:114) > >>>> at > >>>> > >>> > org.apache.jena.sparql.engine.iterator.QueryIterConvert.hasNextBinding(QueryIterConvert.java:58) > >>>> at > >>>> > >>> > org.apache.jena.sparql.engine.iterator.QueryIteratorBase.hasNext(QueryIteratorBase.java:114) > >>>> at > >>>> > >>> > org.apache.jena.sparql.engine.iterator.QueryIterSlice.hasNextBinding(QueryIterSlice.java:76) > >>>> at > >>>> > >>> > org.apache.jena.sparql.engine.iterator.QueryIteratorBase.hasNext(QueryIteratorBase.java:114) > >>>> at > >>>> > >>> > org.apache.jena.sparql.engine.iterator.QueryIteratorWrapper.hasNextBinding(QueryIteratorWrapper.java:39) > >>>> at > >>>> > >>> > org.apache.jena.sparql.engine.iterator.QueryIteratorBase.hasNext(QueryIteratorBase.java:114) > >>>> at > >>>> > >>> > org.apache.jena.sparql.engine.iterator.QueryIteratorWrapper.hasNextBinding(QueryIteratorWrapper.java:39) > >>>> at > >>>> > >>> > org.apache.jena.sparql.engine.iterator.QueryIteratorBase.hasNext(QueryIteratorBase.java:114) > >>>> at > >>>> > >>> > org.apache.jena.sparql.engine.iterator.QueryIteratorWrapper.hasNextBinding(QueryIteratorWrapper.java:39) > >>>> at > >>>> > >>> > org.apache.jena.sparql.engine.iterator.QueryIteratorBase.hasNext(QueryIteratorBase.java:114) > >>>> at > >>>> > >>> > org.apache.jena.sparql.engine.ResultSetStream.hasNext(ResultSetStream.java:74) > >>>> at > >>>> > >>> > org.apache.jena.sparql.engine.ResultSetCheckCondition.hasNext(ResultSetCheckCondition.java:55) > >>>> at > >>>> > >>> > org.apache.jena.fuseki.servlets.SPARQL_Query.executeQuery(SPARQL_Query.java:350) > >>>> at > >>>> > >>> > org.apache.jena.fuseki.servlets.SPARQL_Query.execute(SPARQL_Query.java:288) > >>>> at > >>>> > >>> > org.apache.jena.fuseki.servlets.SPARQL_Query.executeWithParameter(SPARQL_Query.java:242) > >>>> at > >>>> > >>> > org.apache.jena.fuseki.servlets.SPARQL_Query.perform(SPARQL_Query.java:217) > >>>> at > >>>> > >>> > org.apache.jena.fuseki.servlets.ActionService.executeLifecycle(ActionService.java:183) > >>>> at > >>>> > >>> > org.apache.jena.fuseki.servlets.ActionService.execCommonWorker(ActionService.java:98) > >>>> at > >>>> > org.apache.jena.fuseki.servlets.ActionBase.doCommon(ActionBase.java:74) > >>>> at > >>>> > >>> > org.apache.jena.fuseki.servlets.FusekiFilter.doFilter(FusekiFilter.java:73) > >>>> at > >>>> > >>> > org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1642) > >>>> at > >>>> > >>> > org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:533) > >>>> at > >>>> > >>> > org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:255) > >>>> at > >>>> > >>> > org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1340) > >>>> at > >>>> > >>> > org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:203) > >>>> at > >>>> > >>> > org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:473) > >>>> at > >>>> > >>> > org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:201) > >>>> at > >>>> > >>> > org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1242) > >>>> at > >>>> > >>> > org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:144) > >>>> at > >>>> > >>> > org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:132) > >>>> at org.eclipse.jetty.server.Server.handle(Server.java:503) > >>>> at > >>> org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:364) > >>>> at > >>>> > >>> > org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:260) > >>>> at > >>>> org.eclipse.jetty.io > >>> .AbstractConnection$ReadCallback.succeeded(AbstractConnection.java:305) > >>>> at org.eclipse.jetty.io > >>> .FillInterest.fillable(FillInterest.java:103) > >>>> at > >>>> org.eclipse.jetty.io.ChannelEndPoint$2.run(ChannelEndPoint.java:118) > >>>> at > >>>> > >>> > org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:765) > >>>> at > >>>> > >>> > org.eclipse.jetty.util.thread.QueuedThreadPool$2.run(QueuedThreadPool.java:683) > >>>> at java.base/java.lang.Thread.run(Thread.java:834) > >>>> > >>>> > >>>> > >>>> > >>>>> 4. The "geo:" prefix is the one used throughout the GeoSPARQL > >>>>> documentation, so has been used for consistency when needed. The code > >>>>> doesn't have a dependency on the "geo:" prefix, so there is no > >>>>> requirement on the user. It would probably cause more confusion to > >>> those > >>>>> following GeoSPARQL examples to not use the "geo:" prefix when > >>> necessary. > >>>>> > >>>> I know but it needs some discussion about re-purposing of prefixes > here > >>>> > >>>> > >>>> > >>>>> Thanks, > >>>>> > >>>>> Greg > >>>>> > >>>>> On 03/12/2018 15:46, Marco Neumann wrote: > >>>>>> Hi Greg, ok let's do it in the dev list first. > >>>>>> > >>>>>> 1. indeed the picking up of lat/long is a common if not the most > >>> common > >>>>> use > >>>>>> case for building a spatial index. last but not least to perform a > >>>>>> proximity search on 2D point geometries. (I know that the ogc > >>> recommends > >>>>> a > >>>>>> transformation path with a sparql query to turn lat / long into a > WKT > >>>>>> geometry datatypes maybe we could provide this as a convenient > option > >>>>> with > >>>>>> the release) > >>>>>> > >>>>>> 2. as far as I can see the spatial index in geosparql-jena is memory > >>>>> based. > >>>>>> it creates additional load time during server startup. Am I missing > >>>>>> something here, is there a file base spatial index as well? > >>>>>> > >>>>>> 3. error handling is disruptive. since we are hitting the spatial > >>> index > >>>>>> first during query execution I am seeing a number of unpleasant side > >>>>>> effects with syntactically correct sparql but semantically incorrect > >>>>>> spatial queries. e.g. > >>>>>> > >>>>>> PREFIX geo: <http://www.opengis.net/ont/geosparql#> > >>>>>> PREFIX geof: <http://www.opengis.net/def/function/geosparql/> > >>>>>> > >>>>>> SELECT ?well > >>>>>> WHERE { > >>>>>> ?well <http://www.wikidata.org/entity/P625> ?geometry . > >>>>>> FILTER(geof:sfWithin(?geometry,"POLYGON((-77 38,-77 0,0 38,0 > 0,0 > >>>>>> 0))"^^geo:wktLiteral)) > >>>>>> } LIMIT 10 > >>>>>> > >>>>>> 4. The re-use of the geo: prefix really isn't your problem I know > but > >>> it > >>>>>> will create confusion. Wouldn't geosparql: be a better prefix for > >>> this? > >>>>> Is > >>>>>> the OGC now married to this prefix? It used to be > >>>>>> http://www.w3.org/2003/01/geo/wgs84_pos# > >>>>>> > >>>>>> and there is more to come... > >>>>>> > >>>>>> again thank you for working on this with your team Greg, much > >>>>> appreciated. > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> On Mon, Dec 3, 2018 at 2:15 PM Greg Albiston <galbis...@mail.com> > >>> wrote: > >>>>>>> Hi Marco, > >>>>>>> > >>>>>>> I've had a look at the doucmentation for Jena Spatial and it would > >>> seem > >>>>>>> the main data change is the use of the Lat/Lon pairs. > >>>>>>> This doesn't comply with the GeoSPARQL standard so support for this > >>>>>>> would be a Jena extension. > >>>>>>> > >>>>>>> This could be accomodated by a property function to convert to a > WKT > >>>>>>> Point literal with WGS84/CRS84 spatial reference. > >>>>>>> Users would then be able to use the result in query for any of the > >>>>>>> GeoSPARQL functions. > >>>>>>> > >>>>>>> Alternatively, the spatial relations could all have an extra > property > >>>>>>> function defined, provide the conversion and hand over to the > >>> GeoSPARQL > >>>>>>> equivalent property function. This wouldn't take long to integrate > as > >>>>>>> individual spatial relation property functions are very minimal. > >>>>>>> > >>>>>>> The other item that jumps out is the Jena spatial property > functions. > >>>>>>> > >>>>>>> spatial:nearby, spatial:withinCircle, spatial:withinBox and > >>>>>>> spatial:interesectBox all seem to be variations of Simple Features > >>>>>>> spatial relations that are covered by GeoSPARQL. These property > >>>>>>> functions can be incorpated for backward compatability but it's > >>> whether > >>>>>>> these should just be offered as the current Lat/Lon pairs or > >>> expanded to > >>>>>>> accept geometry literals (i.e. WKT, GML etc.)? The latter option > >>>>>>> shouldn't be hard to provide for the same reason as above. > >>>>>>> > >>>>>>> spatial:north, spatial:south, spatial:west and spatial:east are not > >>> in > >>>>>>> GeoSPARQL. Again its a question of whether these should be provided > >>> more > >>>>>>> generally for WKT, GML geometry literals? There might need to be a > >>> bit > >>>>>>> of extra work handling both geographic and planar spatial reference > >>>>>>> systems, as Jean Spatial is only doing a spatial reference system. > >>>>>>> > >>>>>>> I don't think it would be too difficult to support the existing > Jena > >>>>>>> Spatial functionality, at least based on the webpage > >>>>>>> (https://jena.apache.org/documentation/query/spatial-query.html), > >>> as an > >>>>>>> extension to what is provided by GeoSPARQL. > >>>>>>> > >>>>>>> Is there anything else that you were concerned about? > >>>>>>> > >>>>>>> Thanks, > >>>>>>> > >>>>>>> Greg > >>>>>>> > >>>>>>> > >>>>>>> On 03/12/2018 10:53, Marco Neumann wrote: > >>>>>>>> so I've had a look at this and while I think geosparql-jena is a > >>> very > >>>>>>>> welcomed contribution to the jena project I don't think we should > >>> rush > >>>>>>> with > >>>>>>>> the retirement of jena-spatial at this point as Greg's approach > >>> will > >>>>>>>> require users to make changes to their existing data. > >>>>>>>> > >>>>>>>> I will engage Greg on us...@jena.apache.org again to clarify a > few > >>>>>>> things > >>>>>>>> and hopefully get more people involved in this conversation around > >>>>>>> spatial, > >>>>>>>> geosparql and jena. > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> On Fri, Nov 30, 2018 at 1:23 PM Marco Neumann < > >>> marco.neum...@gmail.com > >>>>>>>> wrote: > >>>>>>>> > >>>>>>>>> how quickly can you hook geosparql into the release? > >>>>>>>>> > >>>>>>>>> this would make lucene spatial obsolete in the next release. has > >>> Greg > >>>>>>>>> released performance benchmarks for his implementation? as I > said I > >>>>> will > >>>>>>>>> take a look at it over the weekend when time permits. > >>>>>>>>> > >>>>>>>>> On Fri, Nov 30, 2018 at 11:02 AM Andy Seaborne <a...@apache.org> > >>>>> wrote: > >>>>>>>>>> We could retire jena-spatial immediately after 3.10.0 - given > the > >>>>>>> Lucene > >>>>>>>>>> change that might be smoother, one release with updated > >>> dependencies. > >>>>>>>>>> If that is the way forward, I think it is (mildly) better to > take > >>> it > >>>>>>> out > >>>>>>>>>> of the Fuseki/Full build in 3.10.0. > >>>>>>>>>> > >>>>>>>>>> Andy > >>>>>>>>>> > >>>>>>>>>> On 29/11/2018 17:00, Marco Neumann wrote: > >>>>>>>>>>> I will have to look into that I guess since I am frequent user > of > >>>>>>>>>> spatial > >>>>>>>>>>> data. > >>>>>>>>>>> > >>>>>>>>>>> why not go to 7.5? was there an incompatibility? > >>>>>>>>>>> > >>>>>>>>>>> On Thu 29. Nov 2018 at 16:53, Andy Seaborne <a...@apache.org> > >>>>> wrote: > >>>>>>>>>>>> Jena 3.1.0 would be around the end of the year. I'd like to > make > >>>>> use > >>>>>>> of > >>>>>>>>>>>> Greg's GeoSPARQL project the "headline" item for the release > >>> and to > >>>>>>>>>>>> retire jena-spatial in 3.10.0 as an indication of this. > >>>>>>>>>>>> > >>>>>>>>>>>> Because retirement is a new process for the project, I'm > sending > >>>>> this > >>>>>>>>>>>> first 3.10.0 message quite early to give us discussion time. > >>>>>>>>>>>> > >>>>>>>>>>>> == Retirements > >>>>>>>>>>>> > >>>>>>>>>>>> We have talked about this before but not actually done > anything. > >>>>> See > >>>>>>>>>>>> separate thread for discussion on retirement process and for > the > >>>>>>> first > >>>>>>>>>>>> modules: > >>>>>>>>>>>> > >>>>>>>>>>>> jena-spatial > >>>>>>>>>>>> jena-fuseki1 > >>>>>>>>>>>> jena-csv > >>>>>>>>>>>> > >>>>>>>>>>>> == Headlines > >>>>>>>>>>>> > >>>>>>>>>>>> JENA-664 : GeoSPARQL support > >>>>>>>>>>>> > >>>>>>>>>>>> I'd like to make use of Greg's GeoSPARQL project the > "headline" > >>>>> item > >>>>>>>>>> for > >>>>>>>>>>>> the release and to retire jena-spatial in 3.10.0 as an > >>> indication > >>>>> of > >>>>>>>>>> this. > >>>>>>>>>>>> JENA-1621 : Lucene upgrade to 7.4 > >>>>>>>>>>>> May need to reload lucene indexes. > >>>>>>>>>>>> (e.g. the lucene index was create originally with Lucene v5.x > >>>>> (prior > >>>>>>>>>>>> Jena 3.3.0). See Lucene upgrade tool. > >>>>>>>>>>>> > >>> https://lucene.apache.org/solr/guide/7_4/indexupgrader-tool.html > >>>>>>>>>>>> JENA-1623 : Fuseki security > >>>>>>>>>>>> JENA-1627 : HTTP support > >>>>>>>>>>>> https://issues.apache.org/jira/browse/JENA-1623 > >>>>>>>>>>>> > >>> > http://jena.staging.apache.org/documentation/fuseki2/data-access-control > >>>>>>>>>>>> == JIRA: > >>>>>>>>>>>> > >>>>>>>>>>>> 31 currently. > >>>>>>>>>>>> > >>>>>>>>>>>> https://s.apache.org/jena-3.10.0-jira > >>>>>>>>>>>> > >>>>>>>>>>>> == Updates > >>>>>>>>>>>> > >>>>>>>>>>>> Only plugins. JENA-1624 > >>>>>>>>>>>> > >>>>>>>>>>>> surefire : 2.21.0 -> 2.22.1 (+ SUREFIRE-1588) > >>>>>>>>>>>> compiler : 3.7.0 -> 3.8.0 > >>>>>>>>>>>> shade : 3.1.0 -> 3.2.0 > >>>>>>>>>>>> > >>>>>>>>>>>> Andy > >>>>>>>>>>>> > >>>>>>>>> -- > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> --- > >>>>>>>>> Marco Neumann > >>>>>>>>> KONA > >>>>>>>>> > >>>>>>>>> > >> > >> -- > >> > >> > >> --- > >> Marco Neumann > >> KONA > >> > >> > -- --- Marco Neumann KONA
