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


Reply via email to