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 <[email protected]> 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 < > [email protected]> 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 < >> [email protected]> >> > 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 <[email protected]> >> 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 < >> [email protected]> >> >> 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
