Problems with stardog and geospatial

[engst...@gmail.com]

Hello,

I have some problems getting the geospatial extension to work. 

First: 

It seems that the geospatial extension is disabled in the community edition. It accepts the parameters on db creation but does not create a spatial index like the developer+ version.

Second:

Either I am doing something wrong or the spatial.use.jts option does not work.

I get "Invalid configuration option: spatial.use.jts." when I try to create a database with this option. I simply drop the JTS jars in the server/dbms folder, perhaps I need to include them in the CLASSPATH explicitly.

(According to jinfo <ps> the jts-1.8 is in the CLASSPATH)

Third: 

I can not get spatial queries to work.

Here is a minimum example:

@prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> .
@prefix owl: <http://www.w3.org/2002/07/owl#> .
@prefix geof: <http://www.opengis.net/def/function/geosparql/> .
@prefix xsd: <http://www.w3.org/2001/XMLSchema#> .
@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> .
@prefix geo: <http://www.opengis.net/ont/geosparql#> .


<urn:rede/geodata/resource/18955c8b-61f0-4549-988e-0b1e1ea132d5> a geo:Geometry ;
 <urn:rede/properties#uuid> "18955c8b-61f0-4549-988e-0b1e1ea132d5" ;
 geo:asWKT "POINT(7.861 52.812)"^^geo:wktLiteral .


<urn:rede/geodata/resource/3b9d8275-4b1b-4f5f-a823-cfa8f69343a6> a geo:Geometry ;
 <urn:rede/properties#uuid> "3b9d8275-4b1b-4f5f-a823-cfa8f69343a6" ;
 geo:asWKT "POINT(8.703 50.735)"^^geo:wktLiteral .


<urn:rede/geodata/resource/3b9d8275-4b1b-4f5f-a823-cfa8f69343a9> a geo:Geometry ;
 <urn:rede/properties#uuid> "3b9d8275-4b1b-4f5f-a823-cfa8f69343a9" ;
 geo:asWKT "POINT(8.703 50.735)"^^geo:wktLiteral .

bin/stardog-admin db create -o spatial.enabled=true spatial.use.jts=true -n g1 geosparqltest.ttl

 --> fails with "Invalid configuration option: spatial.use.jts=true."

bin/stardog-admin db create -o spatial.enabled=true  -n g2 geosparqltest.ttl
Bulk loading data to new database g2.
Loaded 9 triples to g2 from 1 file(s) in 00:00:00.058 @ 0,2K triples/sec.
Successfully created database 'g2'.

with the queries (more or less c&p from the docs):

I either get a

ERROR 2015-10-07 15:38:26,729 [SPEC-Server-1-1] com.complexible.stardog.protocols.server.SPECServerFunction:query(523): There was an error executing query: prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#>
prefix owl: <http://www.w3.org/2002/07/owl#>
prefix xsd: <http://www.w3.org/2001/XMLSchema#>
prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#>


select * where {
   
  ?loc geof:nearby (?hq 2 <http://www.qudt.org/qudt/owl/1.0.0/unit/Instances.html#Kilometer> ).
} limit 50 offset 0
org.openrdf.query.QueryEvaluationException: com.complexible.stardog.plan.eval.ExecutionException: There was an error while creating a new query plan
 at com.complexible.stardog.query.DefaultQueryFactory$TupleQuery.execute(DefaultQueryFactory.java:226) ~[stardog-4.0-RC1.jar:?]
 at com.complexible.stardog.query.DefaultQueryFactory$TupleQuery.execute(DefaultQueryFactory.java:209) ~[stardog-4.0-RC1.jar:?]
 at com.complexible.stardog.protocols.server.SPECServerFunction.query(SPECServerFunction.java:499) [stardog-protocols-spec-server-4.0-RC1.jar:?]
 at com.complexible.stardog.protocols.server.SPECServerFunction.handleMessage(SPECServerFunction.java:149) [stardog-protocols-spec-server-4.0-RC1.jar:?]
 at com.complexible.stardog.protocols.http.annex.QueryPanelEndpoint.handleMessage(QueryPanelEndpoint.java:89) [stardog-webconsole-annex-4.0-RC1.jar:?]
 at com.complexible.common.protocols.server.rpc.ServerHandler.handleMessage(ServerHandler.java:295) [stardog-protocols-api-server-4.0-RC1.jar:?]
 at com.complexible.common.protocols.server.rpc.ServerHandler.channelRead(ServerHandler.java:187) [stardog-protocols-api-server-4.0-RC1.jar:?]
 at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:308) [netty-all-4.0.30.Final.jar:4.0.30.Final]
 at io.netty.channel.AbstractChannelHandlerContext.access$600(AbstractChannelHandlerContext.java:32) [netty-all-4.0.30.Final.jar:4.0.30.Final]
 at io.netty.channel.AbstractChannelHandlerContext$7.run(AbstractChannelHandlerContext.java:299) [netty-all-4.0.30.Final.jar:4.0.30.Final]
 at io.netty.util.concurrent.DefaultEventExecutor.run(DefaultEventExecutor.java:36) [netty-all-4.0.30.Final.jar:4.0.30.Final]
 at io.netty.util.concurrent.SingleThreadEventExecutor$2.run(SingleThreadEventExecutor.java:110) [netty-all-4.0.30.Final.jar:4.0.30.Final]
 at io.netty.util.concurrent.DefaultThreadFactory$DefaultRunnableDecorator.run(DefaultThreadFactory.java:137) [netty-all-4.0.30.Final.jar:4.0.30.Final]
 at java.lang.Thread.run(Thread.java:745) [?:1.8.0_45]
Caused by: com.complexible.stardog.plan.eval.ExecutionException: There was an error while creating a new query plan
 at com.complexible.stardog.plan.eval.QueryEngine.getExecutablePlan(QueryEngine.java:219) ~[stardog-4.0-RC1.jar:?]
 at com.complexible.stardog.plan.eval.QueryEngine.executeSelect(QueryEngine.java:119) ~[stardog-4.0-RC1.jar:?]
 at com.complexible.stardog.query.DefaultQueryFactory$TupleQuery.execute(DefaultQueryFactory.java:223) ~[stardog-4.0-RC1.jar:?]
 ... 13 more
Caused by: com.complexible.stardog.plan.PlanException: There was an error while creating a new query plan
 at com.complexible.stardog.plan.PlanGenerator.createPlan(PlanGenerator.java:720) ~[stardog-4.0-RC1.jar:?]
 at com.complexible.stardog.plan.PlanGenerator.createPlan(PlanGenerator.java:670) ~[stardog-4.0-RC1.jar:?]
 at com.complexible.stardog.plan.PlanContext.planFor(PlanContext.java:85) ~[stardog-4.0-RC1.jar:?]
 at com.complexible.stardog.plan.eval.QueryEngine.getExecutablePlan(QueryEngine.java:199) ~[stardog-4.0-RC1.jar:?]
 at com.complexible.stardog.plan.eval.QueryEngine.executeSelect(QueryEngine.java:119) ~[stardog-4.0-RC1.jar:?]
 at com.complexible.stardog.query.DefaultQueryFactory$TupleQuery.execute(DefaultQueryFactory.java:223) ~[stardog-4.0-RC1.jar:?]
 ... 13 more
Caused by: java.lang.IllegalStateException: http://www.qudt.org/qudt/owl/1.0.0/unit/Instances.html#Kilometer is not a known unit.
 at com.complexible.stardog.spatial.db.query.NearbyPropertyFunction$NearbyPlanNodeBuilder.validate(NearbyPropertyFunction.java:217) ~[stardog-spatial-core-4.0-RC1.jar:?]
 at com.complexible.stardog.plan.AbstractPlanNodeBuilder.build(AbstractPlanNodeBuilder.java:94) ~[stardog-4.0-RC1.jar:?]
 at com.complexible.stardog.plan.AbstractPropertyFunctionNodeBuilder.build(AbstractPropertyFunctionNodeBuilder.java:21) ~[stardog-4.0-RC1.jar:?]
 at com.complexible.stardog.plan.PropertyFunctions$PropertyFunctionReplacer.transform(PropertyFunctions.java:284) ~[stardog-4.0-RC1.jar:?]
 at com.complexible.stardog.plan.TransformingPlanNodeVisitor.visit(TransformingPlanNodeVisitor.java:670) ~[stardog-4.0-RC1.jar:?]
 at com.complexible.stardog.plan.ScopeNodeImpl.accept(ScopeNodeImpl.java:122) ~[stardog-4.0-RC1.jar:?]
 at com.complexible.stardog.plan.TransformingPlanNodeVisitor.unaryVisit(TransformingPlanNodeVisitor.java:518) ~[stardog-4.0-RC1.jar:?]
 at com.complexible.stardog.plan.TransformingPlanNodeVisitor.unaryTransform(TransformingPlanNodeVisitor.java:78) ~[stardog-4.0-RC1.jar:?]
 at com.complexible.stardog.plan.TransformingPlanNodeVisitor.transform(TransformingPlanNodeVisitor.java:305) ~[stardog-4.0-RC1.jar:?]
 at com.complexible.stardog.plan.TransformingPlanNodeVisitor.visit(TransformingPlanNodeVisitor.java:726) ~[stardog-4.0-RC1.jar:?]
 at com.complexible.stardog.plan.ProjectionPlanNodeImpl.accept(ProjectionPlanNodeImpl.java:107) ~[stardog-4.0-RC1.jar:?]
 at com.complexible.stardog.plan.TransformingPlanNodeVisitor.unaryVisit(TransformingPlanNodeVisitor.java:518) ~[stardog-4.0-RC1.jar:?]
 at com.complexible.stardog.plan.TransformingPlanNodeVisitor.unaryTransform(TransformingPlanNodeVisitor.java:78) ~[stardog-4.0-RC1.jar:?]
 at com.complexible.stardog.plan.TransformingPlanNodeVisitor.transform(TransformingPlanNodeVisitor.java:315) ~[stardog-4.0-RC1.jar:?]
 at com.complexible.stardog.plan.TransformingPlanNodeVisitor.visit(TransformingPlanNodeVisitor.java:718) ~[stardog-4.0-RC1.jar:?]
 at com.complexible.stardog.plan.SlicePlanNodeImpl.accept(SlicePlanNodeImpl.java:103) ~[stardog-4.0-RC1.jar:?]
 at com.complexible.stardog.plan.PropertyFunctions.apply(PropertyFunctions.java:168) ~[stardog-4.0-RC1.jar:?]
 at com.complexible.stardog.plan.PlanGenerator$PlanBuilder.build(PlanGenerator.java:969) ~[stardog-4.0-RC1.jar:?]
 at com.complexible.stardog.plan.PlanGenerator.createPlan(PlanGenerator.java:715) ~[stardog-4.0-RC1.jar:?]
 at com.complexible.stardog.plan.PlanGenerator.createPlan(PlanGenerator.java:670) ~[stardog-4.0-RC1.jar:?]
 at com.complexible.stardog.plan.PlanContext.planFor(PlanContext.java:85) ~[stardog-4.0-RC1.jar:?]
 at com.complexible.stardog.plan.eval.QueryEngine.getExecutablePlan(QueryEngine.java:199) ~[stardog-4.0-RC1.jar:?]
 at com.complexible.stardog.plan.eval.QueryEngine.executeSelect(QueryEngine.java:119) ~[stardog-4.0-RC1.jar:?]
 at com.complexible.stardog.query.DefaultQueryFactory$TupleQuery.execute(DefaultQueryFactory.java:223) ~[stardog-4.0-RC1.jar:?]
 ... 13 more

It seems that the qudt: namespace is unknown.

This query works but returns no results:

select * where {
 


  ?loc geof:nearby (?hq 2000 <http://www.opengis.net/def/uom/OGC/1.0/metre> ).
}

This query produces a NullPointerException and no stardog.log entry

select * where {
 
   ?loc geof:area (?o <http://www.opengis.net/def/uom/OGC/1.0/metre>)


}

which is probably not wrong, because Points should not have an area but still confusing.

This does not produce an error but also no result

select * where {
 
  ?loc geof:nearby (?hq 0 <http://www.opengis.net/def/uom/OGC/1.0/degree> ).
}

Also I have some confusion with the namespace. 

Usually the geo namespace is <http://www.opengis.net/ont/geosparql#> which denotes all the classes and concepts and basic relations that can be used in a GraphPattern while the

geof: <http://www.opengis.net/def/function/geosparql/> namespace contains the functions that can be used in filters.

In the example in the docs the geof namespace is used in GraphPattern and as a prefix for :hasGeometry. 

(This seems to be partly fixed, "The operators supported... still has the geo: namspace)

Right now it is very unclear for me, how to use the implemented relations or functions and which relations/functions are actually implemented and can be used in a filter or a graph pattern. For example: geof:relate is more Jack of all Trades function, which connects two geo:geomLiterals via the DE-9IM Matrix while geof:nearby does not seem to be part of the official geosparql standard.

I think it would be very help full to have a working "copy and paste" example on the website and a list with all the implemented functions and its signatures similar to the Appendix -> SPARQL Query Functions.

Greetings,

Robert Engsterhold

[Michael Grove]

On Wed, Oct 7, 2015 at 10:32 AM, <engst...@gmail.com> wrote:

Hello,

I have some problems getting the geospatial extension to work. 

First: 

It seems that the geospatial extension is disabled in the community edition. It accepts the parameters on db creation but does not create a spatial index like the developer+ version.

Correct, geospatial is not available in the community edition.

 

Second:

Either I am doing something wrong or the spatial.use.jts option does not work.

I get "Invalid configuration option: spatial.use.jts." when I try to create a database with this option. I simply drop the JTS jars in the server/dbms folder, perhaps I need to include them in the CLASSPATH explicitly.

(According to jinfo <ps> the jts-1.8 is in the CLASSPATH)

`spatial.use.jts` is a server option to be set in stardog.properties.  It is not per-database, and cannot be specified when creating one.  And it applies to all databases in the system when enabled.

The correct URL for the QUDT namespace is `http://qudt.org/vocab/unit#`; the docs have a typo.  So the current URL for Kilometer is http://qudt.org/vocab/unit#Kilometer

 

It seems that the qudt: namespace is unknown.

This query works but returns no results:

select * where {
 


  ?loc geof:nearby (?hq 2000 <http://www.opengis.net/def/uom/OGC/1.0/metre> ).
}

I'd have to see the data to know if that's correct or not.

 

This query produces a NullPointerException and no stardog.log entry

select * where {
 
   ?loc geof:area (?o <http://www.opengis.net/def/uom/OGC/1.0/metre>)


}

which is probably not wrong, because Points should not have an area but still confusing.

Yeah, NPE's are obviously a bug, we'll look into that.

 

This does not produce an error but also no result

select * where {
 
  ?loc geof:nearby (?hq 0 <http://www.opengis.net/def/uom/OGC/1.0/degree> ).
}

I'm not entirely sure what the expected answer would be in this case.  I'd think either nothing or the bindings where ?loc and ?hq are always the same feature.

 

Also I have some confusion with the namespace. 

Usually the geo namespace is <http://www.opengis.net/ont/geosparql#> which denotes all the classes and concepts and basic relations that can be used in a GraphPattern while the

geof: <http://www.opengis.net/def/function/geosparql/> namespace contains the functions that can be used in filters.

In the example in the docs the geof namespace is used in GraphPattern and as a prefix for :hasGeometry. 

(This seems to be partly fixed, "The operators supported... still has the geo: namspace)

That's how they're defined.  The docs are not clear about this.  We'll update those.

 

Right now it is very unclear for me, how to use the implemented relations or functions and which relations/functions are actually implemented and can be used in a filter or a graph pattern. For example: geof:relate is more Jack of all Trades function, which connects two geo:geomLiterals via the DE-9IM Matrix while geof:nearby does not seem to be part of the official geosparql standard.

First note that our support is not an implementation of the geosparql standard. We chose to re-use terms from the common geospatial vocabularies in the hope that would make it easier to use existing geospatial data and/or queries.  But we could have chosen arbitrary names within our own namespace to make the distinction more clear.

The supported functions are geof:area, geof:distance, geof:relate, geof:within, and geof:nearby.  Area computes the area of a feature, distance is the distance between features.  If either or both of the features are non-Point geometries, the mid-point is used for distance calculations.  Relate returns the spatial relationship between two features.  Within returns all features within a feature and nearby returns all features within a certain distance of a given feature.  Under the hood we're using spatial4j & lucene, so these functions map pretty closely with what's available there.

Cheers,

Mike

 

I think it would be very help full to have a working "copy and paste" example on the website and a list with all the implemented functions and its signatures similar to the Appendix -> SPARQL Query Functions.

Greetings,

Robert Engsterhold

--
-- --
You received this message because you are subscribed to the C&P "Stardog" group.
To post to this group, send email to sta...@clarkparsia.com
To unsubscribe from this group, send email to
stardog+u...@clarkparsia.com
For more options, visit this group at
http://groups.google.com/a/clarkparsia.com/group/stardog?hl=en

[engst...@gmail.com]

Hi, 

I have also made some test with the new geospatial functions and stumbled on some oddities.

I have created a simple testset and run it against stardog4 on a mac with java version "1.8.0_45".

The attached zip includes some ttl with Features and some tsv files with the result to helpful postgis queries.

Lower_Saxony.ttl contains the urn:mph-[feature | geometry] that is the federal state of Lower Saxony in Germany represented as a Multipolygon with a hole.

ConvexHull_of_Lower_Saxony.ttl, Bounding_Box_of_Lower_Saxony.ttl

contain the ,well, convex hull and bounding box of the geometry.

without the jts-1.12 or 1.13 in your stardog/server/dbms folder and spatial.use.jts=true in your stardog.properties you can only load the Bounding_Box_of_Lower_Saxony.ttl

Then some Cities represented as Points:

Bremen.ttl : is within the convex hull and bounding box of Lower Saxony but not in Lower Saxony itself (its in the "hole")

Berlin.ttl is outside of everything

Goettingen.ttl, Hannover.tll is inside everything.

All these features are also in dataset_with_graphs.nq, but there seems to be a BUG, that loading a quad does not trigger the creation of the spatial index.

I have included a playground-config.properties file for easy setup.

So, you can setup the DB with 

bin/stardog-admin db create -c <path-to-geotest>/playground-config.properties <path-to-geotest>/*.ttl

The test queries:

prefix geo: <http://www.opengis.net/ont/geosparql#>
prefix geof: <http://www.opengis.net/def/function/geosparql/>


select * where {
 
  ?featureFix geo:hasGeometry ?geomFix ; rdfs:label ?nameFix .  
  ?featureVar geo:hasGeometry ?geomVar ; rdfs:label ?nameComp .
 
 
  #?geomVar geof:nearby (?geomFix 95 <http://qudt.org/vocab/unit#Kilometer>). #1 Var -> Fix
  #?geomFix geof:nearby (?geomVar 95 <http://qudt.org/vocab/unit#Kilometer>). #2 Fix -> Var
  #?dist geof:distance (?geomFix ?geomVar <http://qudt.org/vocab/unit#Kilometer>) . #3 Dist (Fix, Var)
  #?dist geof:distance (?geomVar ?geomFix <http://qudt.org/vocab/unit#Kilometer>) . #4 Dist (Var, Fix)
  #?geomFix geof:within (?geomVar). #5 Fix within Var
  #?geomVar geof:within (?geomFix). #6 Var within Fix
  #?rel geof:relate (?geomVar ?geomFix). #7 rel (Var, Fix)
  #?rel geof:relate (?geomFix ?geomVar). #8 rel (Fix, Var)
  #?area geof:area (?geomVar <http://qudt.org/vocab/unit#Kilometer>) . #9 Area Var
  #?area geof:area (?geomFix <http://qudt.org/vocab/unit#Kilometer>) . #10 Area Fix
 
}  values (?featureFix) {
  (<urn:goettingen-feature>) #A
                          #(<urn:berlin-feature>) # B
                        }

The oddities:

Activating #2 returns the expected results:

featureFix geomFix nameFix featureVar geomVar nameComp

 urn:goettingen-feature urn:goettingen-geometry Goettingen urn:goettingen-feature urn:goettingen-geometry Goettingen

 urn:goettingen-feature urn:goettingen-geometry Goettingen urn:hannover-feature urn:hannover-geometry Hannover

but activating #1 returns:

featureFix geomFix nameFix featureVar geomVar nameComp

 urn:goettingen-feature urn:mph-geometry Goettingen urn:ch-feature urn:ch-geometry ConvexHull of Lower Saxony

 urn:goettingen-feature urn:hannover-geometry Goettingen urn:ch-feature urn:ch-geometry ConvexHull of Lower Saxony

 urn:goettingen-feature urn:goettingen-geometry Goettingen urn:ch-feature urn:ch-geometry ConvexHull of Lower Saxony

 urn:goettingen-feature urn:bremen-geometry Goettingen urn:ch-feature urn:ch-geometry ConvexHull of Lower Saxony

 urn:goettingen-feature urn:bb-geometry Goettingen urn:ch-feature urn:ch-geometry ConvexHull of Lower Saxony

 urn:goettingen-feature urn:ch-geometry Goettingen urn:ch-feature urn:ch-geometry ConvexHull of Lower Saxony

 urn:goettingen-feature urn:mph-geometry Goettingen urn:bb-feature urn:bb-geometry Bounding Box of Lower Saxony

 urn:goettingen-feature urn:hannover-geometry Goettingen urn:bb-feature urn:bb-geometry Bounding Box of Lower Saxony

 urn:goettingen-feature urn:goettingen-geometry Goettingen urn:bb-feature urn:bb-geometry Bounding Box of Lower Saxony

 urn:goettingen-feature urn:bremen-geometry Goettingen urn:bb-feature urn:bb-geometry Bounding Box of Lower Saxony

 urn:goettingen-feature urn:bb-geometry Goettingen urn:bb-feature urn:bb-geometry Bounding Box of Lower Saxony

 urn:goettingen-feature urn:ch-geometry Goettingen urn:bb-feature urn:bb-geometry Bounding Box of Lower Saxony

 urn:goettingen-feature urn:berlin-geometry Goettingen urn:berlin-feature urn:berlin-geometry Berlin

 urn:goettingen-feature urn:mph-geometry Goettingen urn:bremen-feature urn:bremen-geometry Bremen

 urn:goettingen-feature urn:bremen-geometry Goettingen urn:bremen-feature urn:bremen-geometry Bremen

 urn:goettingen-feature urn:bb-geometry Goettingen urn:bremen-feature urn:bremen-geometry Bremen

 urn:goettingen-feature urn:ch-geometry Goettingen urn:bremen-feature urn:bremen-geometry Bremen

 urn:goettingen-feature urn:hannover-geometry Goettingen urn:goettingen-feature urn:goettingen-geometry Goettingen

 urn:goettingen-feature urn:goettingen-geometry Goettingen urn:goettingen-feature urn:goettingen-geometry Goettingen

 urn:goettingen-feature urn:mph-geometry Goettingen urn:hannover-feature urn:hannover-geometry Hannover

 urn:goettingen-feature urn:hannover-geometry Goettingen urn:hannover-feature urn:hannover-geometry Hannover

 urn:goettingen-feature urn:goettingen-geometry Goettingen urn:hannover-feature urn:hannover-geometry Hannover

 urn:goettingen-feature urn:bb-geometry Goettingen urn:hannover-feature urn:hannover-geometry Hannover

 urn:goettingen-feature urn:ch-geometry Goettingen urn:hannover-feature urn:hannover-geometry Hannover

 urn:goettingen-feature urn:mph-geometry Goettingen urn:mph-feature urn:mph-geometry Lower Saxony

 urn:goettingen-feature urn:hannover-geometry Goettingen urn:mph-feature urn:mph-geometry Lower Saxony

 urn:goettingen-feature urn:goettingen-geometry Goettingen urn:mph-feature urn:mph-geometry Lower Saxony

 urn:goettingen-feature urn:bremen-geometry Goettingen urn:mph-feature urn:mph-geometry Lower Saxony

 urn:goettingen-feature urn:bb-geometry Goettingen urn:mph-feature urn:mph-geometry Lower Saxony

 urn:goettingen-feature urn:ch-geometry Goettingen urn:mph-feature urn:mph-geometry Lower Saxony

It seems that ?geomFix somehow lose its binding. There is only one entry for geomVar=Berlin because Berlin is only with itself within 95km 

But if i add a second value to geomFix by uncommenting #B (and #1), I get way less results but still some false

featureFix geomFix nameFix featureVar geomVar nameComp

 urn:goettingen-feature urn:goettingen-geometry Goettingen urn:ch-feature urn:ch-geometry ConvexHull of Lower Saxony

 urn:goettingen-feature urn:goettingen-geometry Goettingen urn:bb-feature urn:bb-geometry Bounding Box of Lower Saxony

 urn:berlin-feature urn:berlin-geometry Berlin urn:berlin-feature urn:berlin-geometry Berlin

 urn:goettingen-feature urn:goettingen-geometry Goettingen urn:goettingen-feature urn:goettingen-geometry Goettingen

 urn:goettingen-feature urn:goettingen-geometry Goettingen urn:hannover-feature urn:hannover-geometry Hannover

 urn:goettingen-feature urn:goettingen-geometry Goettingen urn:mph-feature urn:mph-geometry Lower Saxony

Uncommenting #B and #2 returns the expected results

featureFix geomFix nameFix featureVar geomVar nameComp

 urn:berlin-feature urn:berlin-geometry Berlin urn:berlin-feature urn:berlin-geometry Berlin

 urn:goettingen-feature urn:goettingen-geometry Goettingen urn:goettingen-feature urn:goettingen-geometry Goettingen

 urn:goettingen-feature urn:goettingen-geometry Goettingen urn:hannover-feature urn:hannover-geometry Hannover

for #3, #4 there seems to be the same problem, that variables lose there binding in the brackets

#5 works as expected, #6 returns all combinations of within

#7 returns all combination. If I also activated #B I get the expected results for berlin and goettingen

featureFix geomFix nameFix featureVar geomVar nameComp rel

 urn:berlin-feature urn:berlin-geometry Berlin urn:ch-feature urn:ch-geometry ConvexHull of Lower Saxony ns1:disjoint

 urn:berlin-feature urn:berlin-geometry Berlin urn:bb-feature urn:bb-geometry Bounding Box of Lower Saxony ns1:disjoint

 urn:berlin-feature urn:berlin-geometry Berlin urn:hannover-feature urn:hannover-geometry Hannover ns1:disjoint

 urn:berlin-feature urn:berlin-geometry Berlin urn:goettingen-feature urn:goettingen-geometry Goettingen ns1:disjoint

 urn:berlin-feature urn:berlin-geometry Berlin urn:bremen-feature urn:bremen-geometry Bremen ns1:disjoint

 urn:berlin-feature urn:berlin-geometry Berlin urn:mph-feature urn:mph-geometry Lower Saxony ns1:disjoint

 urn:berlin-feature urn:berlin-geometry Berlin urn:berlin-feature urn:berlin-geometry Berlin ns1:equals

 urn:goettingen-feature urn:goettingen-geometry Goettingen urn:goettingen-feature urn:goettingen-geometry Goettingen ns1:equals

 urn:goettingen-feature urn:goettingen-geometry Goettingen urn:ch-feature urn:ch-geometry ConvexHull of Lower Saxony ns1:contains

 urn:goettingen-feature urn:goettingen-geometry Goettingen urn:bremen-feature urn:bremen-geometry Bremen ns1:disjoint

 urn:goettingen-feature urn:goettingen-geometry Goettingen urn:berlin-feature urn:berlin-geometry Berlin ns1:disjoint

 urn:goettingen-feature urn:goettingen-geometry Goettingen urn:bb-feature urn:bb-geometry Bounding Box of Lower Saxony ns1:contains

 urn:goettingen-feature urn:goettingen-geometry Goettingen urn:hannover-feature urn:hannover-geometry Hannover ns1:disjoint

 urn:goettingen-feature urn:goettingen-geometry Goettingen urn:mph-feature urn:mph-geometry Lower Saxony ns1:contains

Some for #8 with and without #B

#10 returns results for an unbound geomFix

if i replace ?geomFix with <urn:goettingen-geometry> in for example #1

i get following error:

com.complexible.stardog.plan.eval.ExecutionException: There was an error while creating a new

query plan


ERROR 2015-11-24 12:19:56,296 [SPEC-Server-1-3] com.complexible.stardog.protocols.server.SPECServerFunction:query(527): There was an error executing query: prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#>

prefix owl: <http://www.w3.org/2002/07/owl#>
prefix xsd: <http://www.w3.org/2001/XMLSchema#>
prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#>

prefix geo: <http://www.opengis.net/ont/geosparql#>
prefix geof: <http://www.opengis.net/def/function/geosparql/>


select * where {
 
  ?featureFix geo:hasGeometry ?geomFix ; rdfs:label ?nameFix .  
  ?featureVar geo:hasGeometry ?geomVar ; rdfs:label ?nameComp .
 
 
  ?geomVar geof:nearby (<urn:goettingen-geometry> 95 <http://qudt.org/vocab/unit#Kilometer>). #1 Var -> Fix
  #?geomFix geof:nearby (?geomVar 95 <http://qudt.org/vocab/unit#Kilometer>). #2 Fix -> Var
  #?dist geof:distance (?geomFix ?geomVar <http://qudt.org/vocab/unit#Kilometer>) . #3 Dist (Fix, Var)
  #?dist geof:distance (?geomVar ?geomFix <http://qudt.org/vocab/unit#Kilometer>) . #4 Dist (Var, Fix)
  #?geomFix geof:within (?geomVar). #5 Fix within Var
  #?geomVar geof:within (?geomFix). #6 Var within Fix
  #?rel geof:relate (?geomVar ?geomFix). #7 rel (Var, Fix)
  #?rel geof:relate (?geomFix ?geomVar). #8 rel (Fix, Var)
  #?area geof:area (?geomVar <http://qudt.org/vocab/unit#Kilometer>) . #9 Area Var
  #?area geof:area (?geomFix <http://qudt.org/vocab/unit#Kilometer>) . #10 Area Fix
 
}  values (?featureFix) {
  (<urn:goettingen-feature>) #A
                          (<urn:berlin-feature>) # B
                        }

org.openrdf.query.QueryEvaluationException: com.complexible.stardog.plan.eval.ExecutionException: There was an error while creating a new

query plan
 at com.complexible.stardog.query.DefaultQueryFactory$TupleQuery.execute(DefaultQueryFactory.java:226) ~[stardog-4.0.jar:?]
 at com.complexible.stardog.query.DefaultQueryFactory$TupleQuery.execute(DefaultQueryFactory.java:209) ~[stardog-4.0.jar:?]
 at com.complexible.stardog.protocols.server.SPECServerFunction.query(SPECServerFunction.java:503) [stardog-protocols-spec-server-4.0.jar:?]
 at com.complexible.stardog.protocols.server.SPECServerFunction.handleMessage(SPECServerFunction.java:149) [stardog-protocols-spec-server-4.0.jar:?]
 at com.complexible.stardog.protocols.http.annex.QueryPanelEndpoint.handleMessage(QueryPanelEndpoint.java:89) [stardog-webconsole-annex-4.0.jar:?]
 at com.complexible.common.protocols.server.rpc.ServerHandler.handleMessage(ServerHandler.java:324) [stardog-protocols-api-server-4.0.jar:?]
 at com.complexible.common.protocols.server.rpc.ServerHandler.channelRead(ServerHandler.java:207) [stardog-protocols-api-server-4.0.jar:?]
 at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:308) [netty-all-4.0.32.Final.jar:4.0.32.Final]
 at io.netty.channel.AbstractChannelHandlerContext.access$600(AbstractChannelHandlerContext.java:32) [netty-all-4.0.32.Final.jar:4.0.32.Final]
 at io.netty.channel.AbstractChannelHandlerContext$7.run(AbstractChannelHandlerContext.java:299) [netty-all-4.0.32.Final.jar:4.0.32.Final]
 at io.netty.util.concurrent.DefaultEventExecutor.run(DefaultEventExecutor.java:36) [netty-all-4.0.32.Final.jar:4.0.32.Final]
 at io.netty.util.concurrent.SingleThreadEventExecutor$2.run(SingleThreadEventExecutor.java:112) [netty-all-4.0.32.Final.jar:4.0.32.Final]
 at io.netty.util.concurrent.DefaultThreadFactory$DefaultRunnableDecorator.run(DefaultThreadFactory.java:137) [netty-all-4.0.32.Final.jar:4.0.32.Final]

 at java.lang.Thread.run(Thread.java:745) [?:1.8.0_45]
Caused by: com.complexible.stardog.plan.eval.ExecutionException: There was an error while creating a new

query plan
 at com.complexible.stardog.plan.eval.QueryEngine.getExecutablePlan(QueryEngine.java:223) ~[stardog-4.0.jar:?]
 at com.complexible.stardog.plan.eval.QueryEngine.executeSelect(QueryEngine.java:120) ~[stardog-4.0.jar:?]
 at com.complexible.stardog.query.DefaultQueryFactory$TupleQuery.execute(DefaultQueryFactory.java:223) ~[stardog-4.0.jar:?]

 ... 13 more
Caused by: com.complexible.stardog.plan.PlanException: There was an error while creating a new

query plan
 at com.complexible.stardog.plan.PlanGenerator.createPlan(PlanGenerator.java:656) ~[stardog-4.0.jar:?]
 at com.complexible.stardog.plan.PlanGenerator.createPlan(PlanGenerator.java:608) ~[stardog-4.0.jar:?]
 at com.complexible.stardog.plan.PlanContext.planFor(PlanContext.java:85) ~[stardog-4.0.jar:?]
 at com.complexible.stardog.plan.eval.QueryEngine.getExecutablePlan(QueryEngine.java:200) ~[stardog-4.0.jar:?]
 at com.complexible.stardog.plan.eval.QueryEngine.executeSelect(QueryEngine.java:120) ~[stardog-4.0.jar:?]
 at com.complexible.stardog.query.DefaultQueryFactory$TupleQuery.execute(DefaultQueryFactory.java:223) ~[stardog-4.0.jar:?]
 ... 13 more
Caused by: java.lang.IllegalStateException: Expected a variable or a wktLiteral typed literal
 at com.complexible.stardog.spatial.db.query.SpatialQueries.assertWktLiteralOrVariable(SpatialQueries.java:94) ~[stardog-spatial-core-4.0.jar:?]
 at com.complexible.stardog.spatial.db.query.NearbyPropertyFunction$NearbyPlanNodeBuilder.validate(NearbyPropertyFunction.java:174) ~[stardog-spatial-core-4.0.jar:?]
 at com.complexible.stardog.plan.AbstractPlanNodeBuilder.build(AbstractPlanNodeBuilder.java:94) ~[stardog-4.0.jar:?]
 at com.complexible.stardog.plan.AbstractPropertyFunctionNodeBuilder.build(AbstractPropertyFunctionNodeBuilder.java:20) ~[stardog-4.0.jar:?]
 at com.complexible.stardog.plan.PropertyFunctions$PropertyFunctionReplacer.lambda$transform$83(PropertyFunctions.java:236) ~[stardog-4.0.jar:?]
 at com.complexible.stardog.plan.PropertyFunctions$PropertyFunctionReplacer$$Lambda$166/1158343024.accept(Unknown Source) ~[?:?]
 at java.lang.Iterable.forEach(Iterable.java:75) ~[?:1.8.0_45]
 at com.complexible.stardog.plan.PropertyFunctions$PropertyFunctionReplacer.transform(PropertyFunctions.java:218) ~[stardog-4.0.jar:?]
 at com.complexible.stardog.plan.TransformingPlanNodeVisitor.visit(TransformingPlanNodeVisitor.java:680) ~[stardog-4.0.jar:?]
 at com.complexible.stardog.plan.ScopeNodeImpl.accept(ScopeNodeImpl.java:122) ~[stardog-4.0.jar:?]
 at com.complexible.stardog.plan.TransformingPlanNodeVisitor.unaryVisit(TransformingPlanNodeVisitor.java:528) ~[stardog-4.0.jar:?]
 at com.complexible.stardog.plan.TransformingPlanNodeVisitor.unaryTransform(TransformingPlanNodeVisitor.java:78) ~[stardog-4.0.jar:?]
 at com.complexible.stardog.plan.TransformingPlanNodeVisitor.transform(TransformingPlanNodeVisitor.java:305) ~[stardog-4.0.jar:?]
 at com.complexible.stardog.plan.TransformingPlanNodeVisitor.visit(TransformingPlanNodeVisitor.java:736) ~[stardog-4.0.jar:?]
 at com.complexible.stardog.plan.ProjectionPlanNodeImpl.accept(ProjectionPlanNodeImpl.java:107) ~[stardog-4.0.jar:?]
 at com.complexible.stardog.plan.PropertyFunctions.apply(PropertyFunctions.java:168) ~[stardog-4.0.jar:?]
 at com.complexible.stardog.plan.PlanGenerator$PlanBuilder.build(PlanGenerator.java:785) ~[stardog-4.0.jar:?]
 at com.complexible.stardog.plan.PlanGenerator.createPlan(PlanGenerator.java:651) ~[stardog-4.0.jar:?]
 at com.complexible.stardog.plan.PlanGenerator.createPlan(PlanGenerator.java:608) ~[stardog-4.0.jar:?]
 at com.complexible.stardog.plan.PlanContext.planFor(PlanContext.java:85) ~[stardog-4.0.jar:?]
 at com.complexible.stardog.plan.eval.QueryEngine.getExecutablePlan(QueryEngine.java:200) ~[stardog-4.0.jar:?]
 at com.complexible.stardog.plan.eval.QueryEngine.executeSelect(QueryEngine.java:120) ~[stardog-4.0.jar:?]
 at com.complexible.stardog.query.DefaultQueryFactory$TupleQuery.execute(DefaultQueryFactory.java:223) ~[stardog-4.0.jar:?]
 ... 13 more

 

Also a simple

prefix geo: <http://www.opengis.net/ont/geosparql#>
prefix geof: <http://www.opengis.net/def/function/geosparql/>
select * where { ?geomFix geof:nearby (?geomVar 95 <http://qudt.org/vocab/unit#Kilometer>)}

returns 0 results.

I need to bind at least the ?geomVar to a geo:Geometry:

prefix geo: <http://www.opengis.net/ont/geosparql#>
prefix geof: <http://www.opengis.net/def/function/geosparql/>


select * where {
?featureVar geo:hasGeometry ?geomVar ; rdfs:label ?nameComp .
?geomFix geof:nearby (?geomVar 95 <http://qudt.org/vocab/unit#Kilometer>).
}

returns all combinations (as expected).

It seems to me, that you need to bind a variable inside the brackets to a geo:Geometry but that binding somehow get lost during processing.

I hope this helps somehow,

Robert Engsterhold

[Michael Grove]

On Tue, Nov 24, 2015 at 6:52 AM, <engst...@gmail.com> wrote:

Hi,

I have also made some test with the new geospatial functions and stumbled on some oddities.

I have created a simple testset and run them against stardog4 (17.10.2015) on a macbook pro 13' (2015) and java version "1.8.0_45"

The attached zip includes some ttl with Features and some tsv files with the result to helpful postgis queries.

First, thanks for the comprehensive resources for the bug report, it's very helpful.

 

Lower_Saxony.ttl contains the urn:mph-[feature | geometry] that is the federal state of Lower Saxony in Germany represented as a Multipolygon with a hole.

ConvexHull_of_Lower_Saxony.ttl, Bounding_Box_of_Lower_Saxony.ttl

contain the ,well, convex hull and bounding box of the geometry.

without the jts-1.12 or 1.13 in your stardog/server/dbms folder and spatial.use.jts=true in your stardog.properties you can only load the Bounding_Box_of_Lower_Saxony.ttl

Then some Cities represented as Points:

Bremen.ttl : is within the convex hull and bounding box of Lower Saxony but not in Lower Saxony itself (its in the "hole")

Berlin.ttl is outside of everything

Goettingen.ttl, Hannover.tll is inside everything.

All these features are also in dataset_with_graphs.nq, but there seems to be a BUG, that loading a quad does not trigger the creation of the spatial index.

Currently, we are only extracting features from the default graph.  We'll extend this to extract features from the entire database, the issue number for this is #2681 and we'll resolve this for the next release.

This is a bug pertaining to the handling of VALUES with property functions, in this case, nearby.  The issue for this #2680 and it will be fixed in the next release. 

 

But if i add a second value to geomFix by uncommenting #B (and #1), I get way less results but still some false

featureFix geomFix nameFix featureVar geomVar nameComp
 urn:goettingen-feature urn:goettingen-geometry Goettingen urn:ch-feature urn:ch-geometry ConvexHull of Lower Saxony
 urn:goettingen-feature urn:goettingen-geometry Goettingen urn:bb-feature urn:bb-geometry Bounding Box of Lower Saxony
 urn:berlin-feature urn:berlin-geometry Berlin urn:berlin-feature urn:berlin-geometry Berlin
 urn:goettingen-feature urn:goettingen-geometry Goettingen urn:goettingen-feature urn:goettingen-geometry Goettingen
 urn:goettingen-feature urn:goettingen-geometry Goettingen urn:hannover-feature urn:hannover-geometry Hannover
 urn:goettingen-feature urn:goettingen-geometry Goettingen urn:mph-feature urn:mph-geometry Lower Saxony

Uncommenting #B and #2 returns the expected results

featureFix geomFix nameFix featureVar geomVar nameComp
 urn:berlin-feature urn:berlin-geometry Berlin urn:berlin-feature urn:berlin-geometry Berlin
 urn:goettingen-feature urn:goettingen-geometry Goettingen urn:goettingen-feature urn:goettingen-geometry Goettingen
 urn:goettingen-feature urn:goettingen-geometry Goettingen urn:hannover-feature urn:hannover-geometry Hannover

for #3, #4 there seems to be the same problem, that variables lose there binding in the brackets

This seems like the same issue.

 

#5 works as expected, #6 returns all combinations of within

#7 returns all combination. If I also activated #B I get the expected results for berlin and goettingen

featureFix geomFix nameFix featureVar geomVar nameComp rel
 urn:berlin-feature urn:berlin-geometry Berlin urn:ch-feature urn:ch-geometry ConvexHull of Lower Saxony ns1:disjoint
 urn:berlin-feature urn:berlin-geometry Berlin urn:bb-feature urn:bb-geometry Bounding Box of Lower Saxony ns1:disjoint
 urn:berlin-feature urn:berlin-geometry Berlin urn:hannover-feature urn:hannover-geometry Hannover ns1:disjoint
 urn:berlin-feature urn:berlin-geometry Berlin urn:goettingen-feature urn:goettingen-geometry Goettingen ns1:disjoint
 urn:berlin-feature urn:berlin-geometry Berlin urn:bremen-feature urn:bremen-geometry Bremen ns1:disjoint
 urn:berlin-feature urn:berlin-geometry Berlin urn:mph-feature urn:mph-geometry Lower Saxony ns1:disjoint
 urn:berlin-feature urn:berlin-geometry Berlin urn:berlin-feature urn:berlin-geometry Berlin ns1:equals
 urn:goettingen-feature urn:goettingen-geometry Goettingen urn:goettingen-feature urn:goettingen-geometry Goettingen ns1:equals
 urn:goettingen-feature urn:goettingen-geometry Goettingen urn:ch-feature urn:ch-geometry ConvexHull of Lower Saxony ns1:contains
 urn:goettingen-feature urn:goettingen-geometry Goettingen urn:bremen-feature urn:bremen-geometry Bremen ns1:disjoint
 urn:goettingen-feature urn:goettingen-geometry Goettingen urn:berlin-feature urn:berlin-geometry Berlin ns1:disjoint
 urn:goettingen-feature urn:goettingen-geometry Goettingen urn:bb-feature urn:bb-geometry Bounding Box of Lower Saxony ns1:contains
 urn:goettingen-feature urn:goettingen-geometry Goettingen urn:hannover-feature urn:hannover-geometry Hannover ns1:disjoint
 urn:goettingen-feature urn:goettingen-geometry Goettingen urn:mph-feature urn:mph-geometry Lower Saxony ns1:contains

Some for #8 with and without #B

#10 returns results for an unbound geomFix

I'm not sure if these are supposed to be the correct answers or not.  But if not, then it's probably the same issue since these all still are related to the issue with optimization of VALUES.

 

if i replace ?geomFix with <urn:goettingen-geometry> in ,for example, #1

i get following error:

com.complexible.stardog.plan.eval.ExecutionException: There was an error while creating a new

query plan


ERROR 2015-11-24 12:19:56,296 [SPEC-Server-1-3] com.complexible.stardog.protocols.server.SPECServerFunction:query(527): There was an error executing query: prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#>

prefix owl: <http://www.w3.org/2002/07/owl#>
prefix xsd: <http://www.w3.org/2001/XMLSchema#>
prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#>

prefix geo: <http://www.opengis.net/ont/geosparql#>

prefix geof: <http://www.opengis.net/def/function/geosparql/>


select * where {
 
  ?featureFix geo:hasGeometry ?geomFix ; rdfs:label ?nameFix .  
  ?featureVar geo:hasGeometry ?geomVar ; rdfs:label ?nameComp .
 
 
  ?geomVar geof:nearby (<urn:goettingen-geometry> 95 <http://qudt.org/vocab/unit#Kilometer>). #1 Var -> Fix
  #?geomFix geof:nearby (?geomVar 95 <http://qudt.org/vocab/unit#Kilometer>). #2 Fix -> Var
  #?dist geof:distance (?geomFix ?geomVar <http://qudt.org/vocab/unit#Kilometer>) . #3 Dist (Fix, Var)
  #?dist geof:distance (?geomVar ?geomFix <http://qudt.org/vocab/unit#Kilometer>) . #4 Dist (Var, Fix)
  #?geomFix geof:within (?geomVar). #5 Fix within Var
  #?geomVar geof:within (?geomFix). #6 Var within Fix
  #?rel geof:relate (?geomVar ?geomFix). #7 rel (Var, Fix)
  #?rel geof:relate (?geomFix ?geomVar). #8 rel (Fix, Var)
  #?area geof:area (?geomVar <http://qudt.org/vocab/unit#Kilometer>) . #9 Area Var
  #?area geof:area (?geomFix <http://qudt.org/vocab/unit#Kilometer>) . #10 Area Fix
 
}  values (?featureFix) {
  (<urn:goettingen-feature>) #A
                          (<urn:berlin-feature>) # B
                        }

org.openrdf.query.QueryEvaluationException: com.complexible.stardog.plan.eval.ExecutionException: There was an error while creating a new

query plan
 at com.complexible.stardog.query.DefaultQueryFactory$TupleQuery.execute(DefaultQueryFactory.java:226) ~[stardog-4.0.jar:?]

 at com.complexible.stardog.query.DefaultQueryFactory$TupleQuery.execute(DefaultQueryFactory.java:209) ~[stardog-4.0.jar:?]
 at com.complexible.stardog.protocols.server.SPECServerFunction.query(SPECServerFunction.java:503) [stardog-protocols-spec-server-4.0.jar:?]
 at com.complexible.stardog.protocols.server.SPECServerFunction.handleMessage(SPECServerFunction.java:149) [stardog-protocols-spec-server-4.0.jar:?]
 at com.complexible.stardog.protocols.http.annex.QueryPanelEndpoint.handleMessage(QueryPanelEndpoint.java:89) [stardog-webconsole-annex-4.0.jar:?]
 at com.complexible.common.protocols.server.rpc.ServerHandler.handleMessage(ServerHandler.java:324) [stardog-protocols-api-server-4.0.jar:?]
 at com.complexible.common.protocols.server.rpc.ServerHandler.channelRead(ServerHandler.java:207) [stardog-protocols-api-server-4.0.jar:?]
 at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:308) [netty-all-4.0.32.Final.jar:4.0.32.Final]
 at io.netty.channel.AbstractChannelHandlerContext.access$600(AbstractChannelHandlerContext.java:32) [netty-all-4.0.32.Final.jar:4.0.32.Final]
 at io.netty.channel.AbstractChannelHandlerContext$7.run(AbstractChannelHandlerContext.java:299) [netty-all-4.0.32.Final.jar:4.0.32.Final]
 at io.netty.util.concurrent.DefaultEventExecutor.run(DefaultEventExecutor.java:36) [netty-all-4.0.32.Final.jar:4.0.32.Final]
 at io.netty.util.concurrent.SingleThreadEventExecutor$2.run(SingleThreadEventExecutor.java:112) [netty-all-4.0.32.Final.jar:4.0.32.Final]
 at io.netty.util.concurrent.DefaultThreadFactory$DefaultRunnableDecorator.run(DefaultThreadFactory.java:137) [netty-all-4.0.32.Final.jar:4.0.32.Final]

 at java.lang.Thread.run(Thread.java:745) [?:1.8.0_45]
Caused by: com.complexible.stardog.plan.eval.ExecutionException: There was an error while creating a new

query plan
 at com.complexible.stardog.plan.eval.QueryEngine.getExecutablePlan(QueryEngine.java:223) ~[stardog-4.0.jar:?]
 at com.complexible.stardog.plan.eval.QueryEngine.executeSelect(QueryEngine.java:120) ~[stardog-4.0.jar:?]
 at com.complexible.stardog.query.DefaultQueryFactory$TupleQuery.execute(DefaultQueryFactory.java:223) ~[stardog-4.0.jar:?]

 ... 13 more
Caused by: com.complexible.stardog.plan.PlanException: There was an error while creating a new

query plan
 at com.complexible.stardog.plan.PlanGenerator.createPlan(PlanGenerator.java:656) ~[stardog-4.0.jar:?]

 at com.complexible.stardog.plan.PlanGenerator.createPlan(PlanGenerator.java:608) ~[stardog-4.0.jar:?]
 at com.complexible.stardog.plan.PlanContext.planFor(PlanContext.java:85) ~[stardog-4.0.jar:?]
 at com.complexible.stardog.plan.eval.QueryEngine.getExecutablePlan(QueryEngine.java:200) ~[stardog-4.0.jar:?]

 at com.complexible.stardog.plan.eval.QueryEngine.executeSelect(QueryEngine.java:120) ~[stardog-4.0.jar:?]
 at com.complexible.stardog.query.DefaultQueryFactory$TupleQuery.execute(DefaultQueryFactory.java:223) ~[stardog-4.0.jar:?]
 ... 13 more

Caused by: java.lang.IllegalStateException: Expected a variable or a wktLiteral typed literal
 at com.complexible.stardog.spatial.db.query.SpatialQueries.assertWktLiteralOrVariable(SpatialQueries.java:94) ~[stardog-spatial-core-4.0.jar:?]
 at com.complexible.stardog.spatial.db.query.NearbyPropertyFunction$NearbyPlanNodeBuilder.validate(NearbyPropertyFunction.java:174) ~[stardog-spatial-core-4.0.jar:?]
 at com.complexible.stardog.plan.AbstractPlanNodeBuilder.build(AbstractPlanNodeBuilder.java:94) ~[stardog-4.0.jar:?]
 at com.complexible.stardog.plan.AbstractPropertyFunctionNodeBuilder.build(AbstractPropertyFunctionNodeBuilder.java:20) ~[stardog-4.0.jar:?]
 at com.complexible.stardog.plan.PropertyFunctions$PropertyFunctionReplacer.lambda$transform$83(PropertyFunctions.java:236) ~[stardog-4.0.jar:?]
 at com.complexible.stardog.plan.PropertyFunctions$PropertyFunctionReplacer$$Lambda$166/1158343024.accept(Unknown Source) ~[?:?]
 at java.lang.Iterable.forEach(Iterable.java:75) ~[?:1.8.0_45]
 at com.complexible.stardog.plan.PropertyFunctions$PropertyFunctionReplacer.transform(PropertyFunctions.java:218) ~[stardog-4.0.jar:?]
 at com.complexible.stardog.plan.TransformingPlanNodeVisitor.visit(TransformingPlanNodeVisitor.java:680) ~[stardog-4.0.jar:?]
 at com.complexible.stardog.plan.ScopeNodeImpl.accept(ScopeNodeImpl.java:122) ~[stardog-4.0.jar:?]
 at com.complexible.stardog.plan.TransformingPlanNodeVisitor.unaryVisit(TransformingPlanNodeVisitor.java:528) ~[stardog-4.0.jar:?]
 at com.complexible.stardog.plan.TransformingPlanNodeVisitor.unaryTransform(TransformingPlanNodeVisitor.java:78) ~[stardog-4.0.jar:?]
 at com.complexible.stardog.plan.TransformingPlanNodeVisitor.transform(TransformingPlanNodeVisitor.java:305) ~[stardog-4.0.jar:?]
 at com.complexible.stardog.plan.TransformingPlanNodeVisitor.visit(TransformingPlanNodeVisitor.java:736) ~[stardog-4.0.jar:?]
 at com.complexible.stardog.plan.ProjectionPlanNodeImpl.accept(ProjectionPlanNodeImpl.java:107) ~[stardog-4.0.jar:?]
 at com.complexible.stardog.plan.PropertyFunctions.apply(PropertyFunctions.java:168) ~[stardog-4.0.jar:?]
 at com.complexible.stardog.plan.PlanGenerator$PlanBuilder.build(PlanGenerator.java:785) ~[stardog-4.0.jar:?]
 at com.complexible.stardog.plan.PlanGenerator.createPlan(PlanGenerator.java:651) ~[stardog-4.0.jar:?]

 at com.complexible.stardog.plan.PlanGenerator.createPlan(PlanGenerator.java:608) ~[stardog-4.0.jar:?]
 at com.complexible.stardog.plan.PlanContext.planFor(PlanContext.java:85) ~[stardog-4.0.jar:?]
 at com.complexible.stardog.plan.eval.QueryEngine.getExecutablePlan(QueryEngine.java:200) ~[stardog-4.0.jar:?]

 at com.complexible.stardog.plan.eval.QueryEngine.executeSelect(QueryEngine.java:120) ~[stardog-4.0.jar:?]
 at com.complexible.stardog.query.DefaultQueryFactory$TupleQuery.execute(DefaultQueryFactory.java:223) ~[stardog-4.0.jar:?]
 ... 13 more
 

Correct.  Currently the location used for nearby is expected to be a variable, a lat/long pair, or a wkt formatted literal.  We'll extend the support to take a specific value as well, the issue number for that is 2682.

 

Also a simple

prefix geo: <http://www.opengis.net/ont/geosparql#>

prefix geof: <http://www.opengis.net/def/function/geosparql/>

select * where { ?geomFix geof:nearby (?geomVar 95 <http://qudt.org/vocab/unit#Kilometer>)}

returns 0 results.

I need to bind at least the ?geomVar to a geo:Geometry:

prefix geo: <http://www.opengis.net/ont/geosparql#>

prefix geof: <http://www.opengis.net/def/function/geosparql/>

select * where {

?featureVar geo:hasGeometry ?geomVar ; rdfs:label ?nameComp .

?geomFix geof:nearby (?geomVar 95 <http://qudt.org/vocab/unit#Kilometer>).

}

returns all combinations (as expected)

It seems that the geospatial function need a bound geometry inside the brackets, but lose the binding somehow during processing

If a variable is used with a spatial function, the current assumption is that some other BGP will bind values for that variable.  That's why your second query produces results, the additional BGPs provide the set of values for `geomVar` whereas with the first, the set of values is assumed to be empty because the variable is not used elsewhere.

However, it's a reasonable assumption that in absence of other BGPs providing the input for that variable, that it would automatically bind to all features with in the spatial index.  We created a ticket, #2683 for this improvement, and we'll include it in a future release.

 

I hope this helps somehow,

Yes, this was a very helpful bug report.

Cheers,

Mike