BTW this (the implementation of the property function) would be a great project for members in the community to make a contribution to the Jena project and the geosparql modul in particular. I would think that this could be a well manageable task for an experienced java developer with an interest in geospatial data processing.
On Sat, Dec 11, 2021 at 6:19 PM Marco Neumann <marco.neum...@gmail.com> wrote: > That said, I am just looking at the code base and I think we are missing a > property function for is3D which is mentioned in the v1.0 spec. > > On Sat, Dec 11, 2021 at 5:14 PM Marco Neumann <marco.neum...@gmail.com> > wrote: > >> good to see some discussion around this at GeoSPARQL 1.1. But from what I >> can see it is still in an early phase with regards to 3D. >> >> The name geosparql++ was just used as a flag to indicate to the user >> that we are operating outside of the realm of OGC geosparql 1.0 spec. >> >> similar to what we do with sparql vs arq syntax >> >> >> >> On Sat, Dec 11, 2021 at 5:01 PM Lorenz Buehmann < >> buehm...@informatik.uni-leipzig.de> wrote: >> >>> It's on the way with GeoSPARQL 1.1, isn't it? At least there are tickets >>> related to it, e.g. [1] and many functions will be stated to work on 3D >>> as well [2] >>> >>> > I personally think we should go beyond GeoSPARQL soon with Jena to >>> provide >>> > users with more advanced features. Possibly flag it as geosparql++ or >>> the >>> > like. >>> You mean because there was already this GeoSPARQL+ thing from Steffen >>> Staab group with support for rasterized data? It's a shame that those >>> stuff does never make it into the main public projects they are based >>> on. What a waste of resources and time (from my point of view) >>> >>> [1] https://github.com/opengeospatial/ogc-geosparql/issues/238 >>> [2] >>> >>> https://opengeospatial.github.io/ogc-geosparql/geosparql11/spec.html#_b_1_functions_summary_table >>> >>> On 11.12.21 17:39, Marco Neumann wrote: >>> > That's correct Jean-Marc, no comma. >>> > >>> > And yes the OGC GeoSPARQL spec is not supporting 3D access methods. >>> And if >>> > you record a third dimension, which is of course possible, it will be >>> > ignored in Jena. Unfortunately the entire record will be. We could >>> record >>> > this as a bug but it's really not supported at the moment by the spec. >>> Many >>> > of the spatial functions in the OGC GeoSPARQL spec operate with a 2D >>> > reference system. >>> > >>> > I personally think we should go beyond GeoSPARQL soon with Jena to >>> provide >>> > users with more advanced features. Possibly flag it as geosparql++ or >>> the >>> > like. >>> > >>> > Best, >>> > Marco >>> > >>> > >>> > >>> > >>> > On Sun, Dec 5, 2021 at 4:15 PM Jean-Marc Vanel < >>> jeanmarc.va...@gmail.com> >>> > wrote: >>> > >>> >> I fixed the WKT not having the right datatype, as said before; here >>> are the >>> >> SPARQL used to check and fix: >>> >> COUNT-spatial-wkt-as-string.rq >>> >> < >>> >> >>> https://github.com/jmvanel/semantic_forms/blob/master/sparql/COUNT-spatial-wkt-as-string.rq >>> >> FIX-spatial-wkt-as-string.upd.rq >>> >> < >>> >> >>> https://github.com/jmvanel/semantic_forms/blob/master/sparql/FIX-spatial-wkt-as-string.upd.rq >>> >> Now this is not the end of the road . Another imperfect data causing >>> >> geosparql initialization to fail : >>> >> >>> >> *Exception: Build WKT Geometry Exception - Type: point, Coordinates: >>> >> (2.353821,48.83399,0). Index 1 out of bounds for length 1* >>> >> 2021-12-05T15:48:54.166Z [application-akka.actor.default-dispatcher-5] >>> >> ERROR jena - Exception class:class >>> >> org.apache.jena.datatypes.DatatypeFormatException >>> >> 2021-12-05T15:48:54.167Z [application-akka.actor.default-dispatcher-5] >>> >> ERROR jena - Exception >>> >> org.apache.jena.datatypes.DatatypeFormatException: Build WKT Geometry >>> >> Exception - Type: point, Coordinates: (2.353821,48.83399,0). Index 1 >>> out of >>> >> bounds for length 1 >>> >> >>> >> >>> org.apache.jena.geosparql.implementation.parsers.wkt.WKTReader.buildGeometry(WKTReader.java:141) >>> >> >>> >> >>> org.apache.jena.geosparql.implementation.parsers.wkt.WKTReader.<init>(WKTReader.java:50) >>> >> >>> >> >>> org.apache.jena.geosparql.implementation.parsers.wkt.WKTReader.extract(WKTReader.java:292) >>> >> >>> >> >>> >> >>> org.apache.jena.geosparql.implementation.datatype.WKTDatatype.read(WKTDatatype.java:89) >>> >> >>> >> >>> org.apache.jena.geosparql.implementation.index.GeometryLiteralIndex.retrieveMemoryIndex(GeometryLiteralIndex.java:69) >>> >> >>> >> >>> org.apache.jena.geosparql.implementation.index.GeometryLiteralIndex.retrieve(GeometryLiteralIndex.java:51) >>> >> >>> >> >>> org.apache.jena.geosparql.implementation.datatype.GeometryDatatype.parse(GeometryDatatype.java:57) >>> >> >>> >> >>> org.apache.jena.geosparql.implementation.GeometryWrapper.extract(GeometryWrapper.java:1176) >>> >> >>> >> >>> >> >>> org.apache.jena.geosparql.implementation.GeometryWrapper.extract(GeometryWrapper.java:1137) >>> >> >>> >> >>> org.apache.jena.geosparql.implementation.GeometryWrapper.extract(GeometryWrapper.java:1147) >>> >> >>> org.apache.jena.geosparql.configuration.ModeSRS.search(ModeSRS.java:61) >>> >> >>> >> >>> org.apache.jena.geosparql.configuration.GeoSPARQLOperations.findModeSRS(GeoSPARQLOperations.java:520) >>> >> >>> >> Is it because the WKT separator should be a space instead of a comma, >>> or >>> >> because 3D is not allowed ? >>> >> >>> >> Jean-Marc Vanel >>> >> < >>> >> >>> http://semantic-forms.cc:9112/display?displayuri=http://jmvanel.free.fr/jmv.rdf%23me >>> >> +33 >>> >> (0)6 89 16 29 52 >>> >> >>> >> >>> >> Le dim. 5 déc. 2021 à 13:03, Jean-Marc Vanel < >>> jeanmarc.va...@gmail.com> a >>> >> écrit : >>> >> >>> >>> After looking at this code, failing line in bold: >>> >>> >>> >>> >>> >> >>> jena-geosparql/src/main/java/org/apache/jena/geosparql/configuration/ModeSRS.java >>> >>> >>> >> >>> https://github.com/apache/jena/blob/main/jena-geosparql/src/main/java/org/apache/jena/geosparql/configuration/ModeSRS.java >>> >>> ExtendedIterator<RDFNode> nodeIter = >>> >>> model.listObjectsOfProperty(Geo.HAS_SERIALIZATION_PROP); >>> >>> boolean isGeometryLiteralsFound = nodeIter.hasNext(); >>> >>> if (!isGeometryLiteralsFound) { >>> >>> NodeIterator wktNodeIter = >>> >>> model.listObjectsOfProperty(Geo.AS_WKT_PROP); >>> >>> NodeIterator gmlNodeIter = >>> >>> model.listObjectsOfProperty(Geo.AS_GML_PROP); >>> >>> nodeIter = wktNodeIter.andThen(gmlNodeIter); >>> >>> } >>> >>> >>> >>> while (nodeIter.hasNext()) { >>> >>> RDFNode node = nodeIter.next(); >>> >>> if (node.isLiteral()) { >>> >>> * GeometryWrapper geometryWrapper = >>> >>> GeometryWrapper.extract(node.asLiteral());* >>> >>> >>> >>> I did SELECT queries to try to understand what is wrong . >>> >>> It appears that these triples are not present: >>> >>> ?S <http://www.opengis.net/ont/geosparql#hasSerialization> ?O . >>> >>> ?S <http://www.opengis.net/ont/geosparql#asGML> ?O . >>> >>> >>> >>> BUT, there is a bunch of these triples: >>> >>> ?S <http://www.opengis.net/ont/geosparql#asWKT> ?O . >>> >>> >>> >>> Here is one example of the object values: >>> >>> "POINT(-4.189911,54.880557,0)" >>> >>> I probably imported them by hacking a JSON API as JSON-LD , I have to >>> >>> check my journals ... >>> >>> >>> >>> Looking at the OGC GeoSPARQL standard, I saw that the WKT strings >>> should >>> >>> have this datatype : >>> >>> http://www.opengis.net/ont/geosparql#wktLiteral >>> >>> >>> >>> So I can make a SPARQL update to FIX my data . >>> >>> But maybe Jena GeoSPARQL could be forgiving about the string >>> datatype for >>> >>> WKT data . >>> >>> And the error message should be more explicit ... >>> >>> >>> >>> Thanks Andy for the quick answer. >>> >>> >>> >>> Jean-Marc Vanel >>> >>> < >>> >> >>> http://semantic-forms.cc:9112/display?displayuri=http://jmvanel.free.fr/jmv.rdf%23me >>> > >>> >> +33 >>> >>> (0)6 89 16 29 52 >>> >>> >>> >>> >>> >>> Le dim. 5 déc. 2021 à 11:52, Jean-Marc Vanel < >>> jeanmarc.va...@gmail.com> >>> >> a >>> >>> écrit : >>> >>> >>> >>>> After having fixed bad data in the TDB database (latitude is >>> present but >>> >>>> not longitude, coordinates as strings , see issue >>> >>>> https://issues.apache.org/jira/browse/JENA-2202 ), >>> >>>> there is an exception, probably related to the database content. >>> >>>> Here is the log: >>> >>>> Dec 05, 2021 9:57:33 AM >>> >>>> org.apache.sis.referencing.factory.sql.EPSGFactory <init> >>> >>>> WARNING: The “SIS_DATA” environment variable is not set. >>> >>>> 2021-12-05T09:57:33.940Z >>> [application-akka.actor.default-dispatcher-9] >>> >>>> INFO jena - SpatialIndex: isFunctionRegistered true >>> >>>> 2021-12-05T09:57:33.941Z >>> [application-akka.actor.default-dispatcher-9] >>> >>>> INFO jena - Before setupSpatialIndex >>> >>>> 2021-12-05T09:57:33.948Z >>> [application-akka.actor.default-dispatcher-9] >>> >>>> INFO o.a.j.g.c.GeoSPARQLOperations - Find Mode SRS - Started >>> >>>> >>> >>>> And here is the exception: >>> >>>> *Exception: Unrecognised Geometry Datatype: >>> >>>> http://www.w3.org/2001/XMLSchema#string >>> >>>> <http://www.w3.org/2001/XMLSchema#string> Ensure that Datatype is >>> >> extending >>> >>>> GeometryDatatype.* >>> >>>> >>> >>>> >>> >> >>> org.apache.jena.geosparql.implementation.datatype.GeometryDatatype.get(GeometryDatatype.java:78) >>> >>>> >>> >> >>> org.apache.jena.geosparql.implementation.datatype.GeometryDatatype.get(GeometryDatatype.java:86) >>> >>>> >>> >> >>> org.apache.jena.geosparql.implementation.GeometryWrapper.extract(GeometryWrapper.java:1175) >>> >>>> >>> >> >>> org.apache.jena.geosparql.implementation.GeometryWrapper.extract(GeometryWrapper.java:1137) >>> >>>> >>> >> >>> org.apache.jena.geosparql.implementation.GeometryWrapper.extract(GeometryWrapper.java:1147) >>> >>>> >>> org.apache.jena.geosparql.configuration.ModeSRS.search(ModeSRS.java:61) >>> >>>> >>> >>>> >>> >> >>> org.apache.jena.geosparql.configuration.GeoSPARQLOperations.findModeSRS(GeoSPARQLOperations.java:520) >>> >>>> >>> >> >>> org.apache.jena.geosparql.spatial.SpatialIndex.buildSpatialIndex(SpatialIndex.java:336) >>> >>>> >>> >> >>> org.apache.jena.geosparql.configuration.GeoSPARQLConfig.setupSpatialIndex(GeoSPARQLConfig.java:263) >>> >>>> >>> >> >>> deductions.runtime.jena.RDFStoreLocalJenaProviderObject$.createDatabase(RDFStoreLocalJenaProvider.scala:175) >>> >>>> I use the latest Jena release 4.2.0 . Note that there is no trouble >>> on >>> >> my >>> >>>> development machine, only on the production site , although the >>> source >>> >> is >>> >>>> the same . >>> >>>> >>> >>>> Jean-Marc Vanel >>> >>>> >>> >>>> >>> > >>> >> >> >> -- >> >> >> --- >> Marco Neumann >> KONA >> >> > > -- > > > --- > Marco Neumann > KONA > > -- --- Marco Neumann KONA
