Sparql Query Geometry doing strange things - sparql

Question

I'm doing a Sparql Query right now, to find Places around a specific radius of a given Point from dbpedia Endpoint (Snorql).
My first solution (already doing at some other Endpoints) was this:
PREFIX geo: <http://www.w3.org/2003/01/geo/wgs84_pos#>
SELECT *
WHERE {
?resource rdfs:label ?label .
?resource geo:lat ?lat .
?resource geo:long ?long .
?resource geo:geometry ?coordinates .
FILTER(bif:st_within(?coordinates, bif:st_geomFromText("POINT(10.2788 47.4093)"), 1)) .
FILTER (lang(?label)= "de") .
}
I noticed that it doesn't give me any results. Then I tried the same thing with the given rounded values in geo:lat and geo:long:
PREFIX geo: <http://www.w3.org/2003/01/geo/wgs84_pos#>
SELECT *
WHERE {
?resource rdfs:label ?label .
?resource geo:lat ?lat .
?resource geo:long ?long .
?resource geo:geometry ?coordinates .
FILTER(bif:st_within(bif:st_point(?long, ?lat), bif:st_geomFromText("POINT(10.2788 47.4093)"), 1)) .
FILTER (lang(?label)= "de") .
}
Now I'm getting 2 results. When I'm increasing the radius of the first solution to 21, there are plenty results, but decreasing it to 20, there are no results. Is there a mistake I made in the first Query?
Thank you very much,
SaW

Answer 1

As I answered on Confluence...
Interesting!
Your original query (with addition of FROM <http://dbpedia.org> clause) does return the expected results when run against the LOD Cloud Cache, which is now on a somewhat older Virtuoso engine. This looks like a regression in newer versions.
To check things on DBpedia, I started with your query, and added a couple of BINDs using the st_distance() function to the WHERE clause --
BIND
( bif:st_distance
( ?coordinates,
bif:st_geomFromText("POINT(10.2788 47.4093)")
) AS ?coord_distance
) .
BIND
( bif:st_distance
( bif:st_point(?long, ?lat),
bif:st_geomFromText("POINT(10.2788 47.4093)")
) AS ?latlong_distance
)
}
I also added a final ORDER BY ?coord_distance to the query.
My results on DBpedia.org/sparql clearly show two entities within your desired radius of 1, and the calculated distances are the same whether based on ?coordinates or st_point(?long, ?lat) but they are not delivered unless bif:st_within specifies a radius of 21 or greater -- and those results include a number of other entities that are within the larger radius.
I've raised this to Virtuoso Development, and it's being tracked internally as bug#18399.
... and as followed up there ...
st_within() uses st_distance(), so given that the srid is 4326 (as is typical for DBpedia geodata), "the haversine function is used to compute a great circle distance in kilometers on Earth." You can divide your distance in meters by 1000 (or multiply it by 0.001) to get the distance in kilometers for use in the st_within() call.
The computing time is dependent on the instance host, other load on the instance, etc. The public DBpedia instance's response time may well be longer than you can tolerate. You can set up your own mirror in a local server or in the cloud (AMIs based on DBpedia 2016-10 Snapshot [current DBpedia.org/sparql], or DBpedia-Live [current live.DBpedia.org/sparql]), which you can put on any AWS instance type -- so you can give it as much processor and/or RAM as you like.
Note that the LOD Cloud Cache instance may be upgraded to a newer Virtuoso engine at any time, so you should not rely on this delivering the desired results via st_within(). A slightly adjusted DBpedia query will deliver what I think you want using only the st_distance() function (here calculated from ?coordinates, but you could also use the more complex construction based on ?long and ?lat), and not the malfunctioning st_within().