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
