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
