OK yes I see, thank you for the findings. That would explain the situation.
I will take a look at geo:coordinateDimension. So I think what we would like to avoid is a situation where higher level dimensions are quietly skipped altogether. Even though using x, y access methods on higher level dimension data will lead to geographically incorrect results. Marco On Mon, Dec 13, 2021 at 12:02 PM Greg <galbis...@mail.com> wrote: > Ah, okay. That link is to the 11-52r3 version while I believe the final > version is 11-52r4. In the later draft, Req 12 became Req 9 and the > 'is3D' was removed. > I've found the OGC website can be a bit hit and miss about indicating > what are latest and deprecated versions. > > https://www.ogc.org/standards/geosparql#downloads > > https://portal.ogc.org/files/?artifact_id=47664 > > Greg > > On 12/12/2021 20:41, Marco Neumann wrote: > > I wasn't are of the geo:is3D property myself but is is apparently in Req > 12 > > of the final GeoSPARQL release V1.0 > > > > https://portal.ogc.org/files/?artifact_id=44722 > > > > maybe it's only in the requirements. > > > > > > > > On Sun, Dec 12, 2021 at 8:24 PM Greg <galbis...@mail.com> wrote: > > > >> Hi, > >> > >> The WKT parser supports XY, XYZ, XYM, and XYZM coordinate notations. The > >> presence of dimensions beyond XY should not have an impact on the > >> geomtery being used in spatial relation or other queries. The triples > >> exist in the graph and will be processed, but the GeoSPARQL 1.0 is 2D > >> only so the extra dimensions are not used in calculations. > >> > >> I'm not aware of an 'is3D' property in the v1.0 spec as this can be > >> tested using the 'geo:coordinateDimension' (either 2, 3, or 4 - i.e. XY, > >> XYZ, XYM and XYZM) and/or 'geo:spatialDimension' (either 2 or 3 - i.e. > >> XY and XYM or XYZ and XYZM) properties of geo:Geometry (Section 8.4). > >> These values are inferred in the Jena implementation and do not need to > >> asserted to be accessed. > >> > >> The standard also states that invalid geometry literals are to be > >> treated as errors, hence the 'DatatypeFormatException'. > >> > >> Thanks, > >> > >> Greg > >> > >> On 11/12/2021 19:33, Marco Neumann wrote: > >>> 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
