and as you have mentioned earlier GeoSPARQL 1.0 is 2D. If we go beyond that (and we should at some point) we will have to indicate that in the references.
For now GeoSPARQL 1.0 is the point of reference for the Apache Jena GeoSPARQL implementation. On Mon, Dec 13, 2021 at 12:30 PM Marco Neumann <[email protected]> wrote: > 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 <[email protected]> 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 <[email protected]> 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 < >> [email protected]> >> >>> 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 < >> [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 >> >>>> >> >>>> >> > >> > > > -- > > > --- > Marco Neumann > KONA > > -- --- Marco Neumann KONA
