GeoSparql not working

I encountered a problem in GeoSparql using the examples from the manual. I have been exploring the GeoSPARQL functions in Stardog. I started with the example in the manual, but it doesn`t work. I created a new repository and enabled the spatial index.

I added these object based on the manual example:

@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> .
@prefix geo:     <http://www.w3.org/2003/01/geo/wgs84_pos#> .
@prefix wgs:  <http://www.w3.org/2003/01/geo/wgs84_pos#> .

:whiteHouse a geo:Feature ;
    rdfs:label "White House";
    geo:hasGeometry [
        a geo:Geometry ;
        geo:asWKT "Point(-77.036541 38.897680)"^^geo:wktLiteral
    ] .
	
:LincolnMemorial a geo:Feature ;
    rdfs:label "Lincoln Memorial";
    geo:hasGeometry [
        a geo:Geometry ;
        geo:asWKT "Point(-77.050188 38.889279)"^^geo:wktLiteral
    ] .
	
	
:BlairHouse a geo:Feature ;
    rdfs:label "Blair House";
    geo:hasGeometry [
        a geo:Geometry ;
        geo:asWKT "Point(-77.038676 38.898207)"^^geo:wktLiteral
    ] .

And then I use the Sparql Query from the manual as well. I runs but gives zero results. I would expect to find the other two objects since they are at least within 2 km from the white house:

prefix geo: <http://www.w3.org/2003/01/geo/wgs84_pos#> 
prefix geof: <http://www.opengis.net/def/function/geosparql/>

select ?name where {
  ?loc rdfs:label ?name .
  ?loc geo:hasGeometry ?feature .
  ?hq geo:hasGeometry ?hqGeo ; rdfs:label "Complexible Headquarters" .
  ?feature geof:nearby (?hqGeo 5 <http://qudt.org/vocab/unit#Kilometer>).
}

What do I do wrong?

Did you enable spatial indexing when you created the db by setting the option spatial.enabled=true?

Are you using a developer, enterprise or 30-day evaluation license?

Is there anything of note in the logs?

Not during creation, but after creation by enabling spatial indexing. I use the enterprise edition.
Is there any difference between spatial indexing in the frontend and enabling spatial.enabled=true?

I assumed they were the same and enabling on the command line gives an error (Unable to connect to server at http://localhost:5820 localhost:5820 failed to respond) since we use https for some reason.

You should be able to enable spatial indexing after you’ve created the database and it should be the same as if you had set it when you created the database. It sounds as if you weren’t successful in enabling it. You can check if it’s enabled by running stardog-admin --server https://localhost:5820 metadata get -o spatial.enabled myDb

Running https can make using the cli a little more tricky since the defaults that make it simple to run default to http. You’ll need to pass the --server option with the server and protocol options you’re using. ie. --server https://localhost:5820 or you can set the JVM argument -Dstardog.default.cli.server=https://localhost:5820

You can set the JVM arg by setting the STARDOG_CLIENT_JAVA_ARGS environment variable.

Ok checked some stuff. If I run the stardog-admin --server https://localhost:5820 metadata get -o spatial.enabled myDb command. Stardog returns:

 +-----------------+-------+
 |     Option      | Value |
 +-----------------+-------+
 | spatial.enabled | true  |
 +-----------------+-------+

Concluded that spatial is working for this repository. Used the same basic triples as in the first post.
And used the following sparql query:

PREFIX geof: <http://www.opengis.net/def/function/geosparql/>
PREFIX geo: <http://www.w3.org/2003/01/geo/wgs84_pos#>
PREFIX wgs: <http://www.w3.org/2003/01/geo/wgs84_pos#>
 
select ?name where {
  ?loc rdfs:label ?name .
  ?loc geo:hasGeometry ?feature .
  ?hq geo:hasGeometry ?hqGeo ; rdfs:label "White House" .
  ?feature geof:nearby (?hqGeo 10 <http://qudt.org/vocab/unit#Kilometer>).
}

Which is slightly different than the one in the first post. As I understand the query, I use the geometry of the White House object and try to find all features within 10 kilometers. But still no results.

We use Stardog Version: 5.0.5.1 Enterprise edition.

The prefix “geo” on your data and query is expected to be defined as follows

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

Give that a try…

1 Like

Tried:

Updated the data:

@prefix rdfs: http://www.w3.org/2000/01/rdf-schema# .
@prefix geo: http://www.opengis.net/ont/geosparql# .
@prefix wgs: http://www.w3.org/2003/01/geo/wgs84_pos# .

:whiteHouse a geo:Feature ;
rdfs:label “White House”;
geo:hasGeometry [
a geo:Geometry ;
geo:asWKT “Point(-77.036541 38.897680)”^^geo:wktLiteral
] .

:LincolnMemorial a geo:Feature ;
rdfs:label “Lincoln Memorial”;
geo:hasGeometry [
a geo:Geometry ;
geo:asWKT “Point(-77.050188 38.889279)”^^geo:wktLiteral
] .

:BlairHouse a geo:Feature ;
rdfs:label “Blair House”;
geo:hasGeometry [
a geo:Geometry ;
geo:asWKT “Point(-77.038676 38.898207)”^^geo:wktLiteral
] .

Used updated SPARQL:

PREFIX geof: http://www.opengis.net/def/function/geosparql/
PREFIX geo: http://www.opengis.net/ont/geosparql# .
PREFIX wgs: http://www.w3.org/2003/01/geo/wgs84_pos#

select ?name where {
?loc rdfs:label ?name .
?loc geo:hasGeometry ?feature .
?hq geo:hasGeometry ?hqGeo ; rdfs:label “White House” .
?feature geof:nearby (?hqGeo 10 http://qudt.org/vocab/unit#Kilometer).
}

Still without any result.

I believe you may have discovered a bug. I’ve noticed that the query will return if you bulk load the database when it’s created but will not return if you load the data after it’s created. It looks like there may be an issue with Stardog not indexing data being loaded after db creation.

(Tested on Stardog 5.2)

stardog-admin db create -n test -o spatial.enabled=true -- test.ttl
stardog-admin query test test.rq

three results

stardog-admin db create -n test -o spatial.enabled=true --
stardog data add test test.ttl
stardog-admin query test test.rq

no results

Query and data were from previously posted in this topic.

Checked it myself. Replicated your steps and if I upload the data with creation, it works. After creation it doesn’t.
Seems like a bug indeed.

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.