Hi Markus,
If you are seeing this behaviour from isql then why not provide the command
line out of the query executions showing this behaviour ?
As this works for me against our LOD Cloud Cache server:
SQL> SPARQL PREFIX rdfs: <http://www.w3.org/2000/01/rdf-schema#> PREFIX ogc:
<http://www.opengis.net/ont/geosparql#> PREFIX geom:
<http://geovocab.org/geometry#> PREFIX wgs:
<http://www.w3.org/2003/01/geo/wgs84_pos#> PREFIX lgd:
<http://linkedgeodata.org/> PREFIX lgdo: <http://linkedgeodata.org/ontology/>
PREFIX lgdm: <http://linkedgeodata.org/meta/> PREFIX lgd-tr:
<http://linkedgeodata.org/triplify/> PREFIX lgd-geo:
<http://linkedgeodata.org/geometry/> PREFIX dcterms:
<http://purl.org/dc/terms/> SELECT ?name, ?wkt, bif:st_distance(?wkt,
?centroid ) AS ?distance FROM <http://linkedgeodata.org> { ?lgd a lgdo:City;
rdfs:label ?name; geom:geometry [ogc:asWKT ?wkt ]. BIND (
bif:st_point(10.447683, 51.163375) AS ?centroid ) FILTER (
bif:st_distance(?wkt, ?centroid) <= 100 ) FILTER ( langMatches(lang(?name),
'') ) FILTER NOT EXISTS { ?lgd a lgdm:Way. } } ;
name
wkt
distance
VARCHAR
VARCHAR
VARCHAR
_______________________________________________________________________________
Kassel
POINT(9.4763 51.309)
69.50083019481481
Göttingen
POINT(9.93521 51.5328)
54.31867540296261
Jena
POINT(11.5833 50.9331)
83.3635333416363
Erfurt
POINT(11.0329 50.9776)
45.78644999395271
4 Rows. -- 284 msec.
SQL> SPARQL PREFIX rdfs: <http://www.w3.org/2000/01/rdf-schema#> PREFIX ogc:
<http://www.opengis.net/ont/geosparql#> PREFIX geom:
<http://geovocab.org/geometry#> PREFIX wgs:
<http://www.w3.org/2003/01/geo/wgs84_pos#> PREFIX lgd:
<http://linkedgeodata.org/> PREFIX lgdo: <http://linkedgeodata.org/ontology/>
PREFIX lgdm: <http://linkedgeodata.org/meta/> PREFIX lgd-tr:
<http://linkedgeodata.org/triplify/> PREFIX lgd-geo:
<http://linkedgeodata.org/geometry/> PREFIX dcterms:
<http://purl.org/dc/terms/> SELECT ?name, ?wkt, bif:st_distance(?wkt,
?centroid ) AS ?distance FROM <http://linkedgeodata.org> { ?lgd a lgdo:City;
rdfs:label ?name; geom:geometry [ogc:asWKT ?wkt ]. BIND (
bif:st_point(10.447683, 51.163375) AS ?centroid ) FILTER (
bif:st_intersects (?w , 100) )
name
wkt
distance
VARCHAR
VARCHAR
VARCHAR
_______________________________________________________________________________
Jena
POINT(11.5833 50.9331)
83.3635333416363
Erfurt
POINT(11.0329 50.9776)
45.78644999395271
Kassel
POINT(9.4763 51.309)
69.50083019481481
Göttingen
POINT(9.93521 51.5328)
54.31867540296261
4 Rows. -- 3332 msec.
SQL>
Best Regards
Hugh Williams
Professional Services
OpenLink Software, Inc. // http://www.openlinksw.com/
Weblog -- http://www.openlinksw.com/blogs/
LinkedIn -- http://www.linkedin.com/company/openlink-software/
Twitter -- http://twitter.com/OpenLink
Google+ -- http://plus.google.com/100570109519069333827/
Facebook -- http://www.facebook.com/OpenLinkSoftware
Universal Data Access, Integration, and Management Technology Providers
> On 16 Jan 2015, at 09:28, Markus Ackermann
> <ackerm...@informatik.uni-leipzig.de> wrote:
>
>
> Hi Hugh,
>
> I used the isql CLI provided by Virtuoso to run the queries and to my
> knowledge premature termination of query evaluation by Anytime does not
> apply there. (Please correct me if I am mistaken.)
>
> Regards,
>
> Markus
>
>
>
> On 16/01/15 02:41, Hugh Williams wrote:
>> Hi Markus,
>>
>> I ran the query against our LOD Cloud Cache server hosting 60+billion
>> LOD datasets (http://lod.openlinksw.com) including the LGD datasets,
>> and found the query with Filter A returned 4 results as you indicated
>> returning immediately. Running the query with Filter B it takes
>> appreciably longer to run and on first execution gave a timeout error
>> indicating partial results would be returned, running it again it then
>> 2 results, on the third execution it returned 4 results same as with
>> Filter A . So it would appear the Virtuoso Anytime [1] [2] query
>> feature is coming into play and returning partial results, thus have
>> you tried running the query with Filter B multiple times in succession
>> to see if more results are returned ? see:
>>
>> http://lod.openlinksw.com/sparql?default-graph-uri=&qtxt=PREFIX+rdfs%3A+%3Chttp%3A%2F%2Fwww.w3.org%2F2000%2F01%2Frdf-schema%23%3E%0D%0APREFIX+ogc%3A+%3Chttp%3A%2F%2Fwww.opengis.net%2Font%2Fgeosparql%23%3E%0D%0APREFIX+geom%3A+%3Chttp%3A%2F%2Fgeovocab.org%2Fgeometry%23%3E%0D%0APREFIX+wgs%3A+%3Chttp%3A%2F%2Fwww.w3.org%2F2003%2F01%2Fgeo%2Fwgs84_pos%23%3E%0D%0APREFIX+lgd%3A++%3Chttp%3A%2F%2Flinkedgeodata.org%2F%3E%0D%0APREFIX+lgdo%3A+%3Chttp%3A%2F%2Flinkedgeodata.org%2Fontology%2F%3E%0D%0APREFIX+lgdm%3A+%3Chttp%3A%2F%2Flinkedgeodata.org%2Fmeta%2F%3E%0D%0APREFIX+lgd-tr%3A+%3Chttp%3A%2F%2Flinkedgeodata.org%2Ftriplify%2F%3E%0D%0APREFIX+lgd-geo%3A+%3Chttp%3A%2F%2Flinkedgeodata.org%2Fgeometry%2F%3E%0D%0APREFIX+dcterms%3A+%3Chttp%3A%2F%2Fpurl.org%2Fdc%2Fterms%2F%3E%0D%0A%0D%0A%0D%0ASELECT+%3Fname%2C+%3Fwkt%2C+bif%3Ast_distance%28%3Fwkt%2C+%3Fcentroid+%29+AS+%3Fdistance%0D%0AFROM+%3Chttp%3A%2F%2Flinkedgeodata.org%3E+%7B%0D%0A+++%3Flgd+a+lgdo%3ACity%3B%0D%0A+++rdfs%3Alabel+%3Fname%3B%0D%0A+++geom%3Ageometry+%5Bogc%3AasWKT+%3Fwkt+%5D.%0D%0A%0D%0A+++BIND+%28+bif%3Ast_point%2810.447683%2C+51.163375%29+AS+%3Fcentroid+%29%0D%0A%0D%0A+++%23+choose+one+of+the+two+lines+below%3A%0D%0A+++%23+FILTER+%28+bif%3Ast_distance%28%3Fwkt%2C+%3Fcentroid%29+%3C%3D+100+%29+%23+use+this+predicate+for+query+A%0D%0A%0D%0A+++FILTER+%28+bif%3Ast_intersects+%28%3Fwkt%2C+%3Fcentroid%2C+100%29+%29+%23+use+this+predicate+for+query+B%0D%0A%0D%0A+++FILTER+%28+langMatches%28lang%28%3Fname%29%2C+%27%27%29+%29%0D%0A+++FILTER+NOT+EXISTS+%7B+%3Flgd+a+lgdm%3AWay.+%7D%0D%0A%7D%0D%0A&format=text%2Fhtml&CXML_redir_for_subjs=121&CXML_redir_for_hrefs=&timeout=30000&debug=on
>>
>> or short link:
>>
>> http://bit.ly/1Cdl5rU
>>
>> [1] http://docs.openlinksw.com/virtuoso/anytimequeries.html
>> [2]
>> http://virtuoso.openlinksw.com/dataspace/doc/dav/wiki/Main/VirtTipsAndTricksAnytimeSPARQLQuery
>>
>> Best Regards
>> Hugh Williams
>> Professional Services
>> OpenLink Software, Inc. // http://www.openlinksw.com/
>> Weblog -- http://www.openlinksw.com/blogs/
>> LinkedIn -- http://www.linkedin.com/company/openlink-software/
>> Twitter -- http://twitter.com/OpenLink
>> Google+ -- http://plus.google.com/100570109519069333827/
>> Facebook -- http://www.facebook.com/OpenLinkSoftware
>> Universal Data Access, Integration, and Management Technology Providers
>>
>>> On 14 Jan 2015, at 17:38, Markus Ackermann
>>> <ackerm...@informatik.uni-leipzig.de
>>> <mailto:ackerm...@informatik.uni-leipzig.de
>>> <mailto:ackerm...@informatik.uni-leipzig.de>>> wrote:
>>>
>>>
>>> Hi,
>>>
>>> testing some geospatial SPARQL queries using a build of the latest commit
>>> from the developt/7 branch (thus VOS OpenSource 07.10.3211)on the
>>> LinkedGeoData Dumps from Sep 9 2014 ([1]) I encountered unexpected
>>> discrepancy
>>> between the selectiveness of st_intersects versus giving an upper
>>> bound to
>>> the distance between points calculated using st_distance.
>>>
>>> I used the following query:
>>>
>>> PREFIX rdfs: <http://www.w3.org/2000/01/rdf-schema#
>>> <http://www.w3.org/2000/01/rdf-schema#>>
>>> PREFIX ogc: <http://www.opengis.net/ont/geosparql#
>>> <http://www.opengis.net/ont/geosparql#>>
>>> PREFIX geom: <http://geovocab.org/geometry# <http://geovocab.org/geometry#>>
>>> PREFIX wgs: <http://www.w3.org/2003/01/geo/wgs84_pos#
>>> <http://www.w3.org/2003/01/geo/wgs84_pos#>>
>>> PREFIX lgd: <http://linkedgeodata.org/ <http://linkedgeodata.org/>>
>>> PREFIX lgdo: <http://linkedgeodata.org/ontology/
>>> <http://linkedgeodata.org/ontology/>>
>>> PREFIX lgdm: <http://linkedgeodata.org/meta/
>>> <http://linkedgeodata.org/meta/>>
>>> PREFIX lgd-tr: <http://linkedgeodata.org/triplify/
>>> <http://linkedgeodata.org/triplify/>>
>>> PREFIX lgd-geo: <http://linkedgeodata.org/geometry/
>>> <http://linkedgeodata.org/geometry/>>
>>> PREFIX dcterms: <http://purl.org/dc/terms/ <http://purl.org/dc/terms/>>
>>>
>>>
>>> SELECT ?name, ?wkt, bif:st_distance(?wkt, ?centroid ) AS ?distance
>>> FROM <http://linkedgeodata.org <http://linkedgeodata.org/>> {
>>> ?lgd a lgdo:City;
>>> rdfs:label ?name;
>>> geom:geometry [ogc:asWKT ?wkt ].
>>>
>>> BIND ( bif:st_point(10.447683, 51.163375) AS ?centroid )
>>>
>>> # choose one of the two lines below:
>>> # FILTER ( bif:st_distance(?wkt, ?centroid) <= 100 ) # use this
>>> predicate for query A
>>> # FILTER ( bif:st_intersects (?wkt, ?centroid, 100) ) # use this
>>> predicate for query B
>>>
>>> FILTER ( langMatches(lang(?name), '') )
>>> FILTER NOT EXISTS { ?lgd a lgdm:Way. }
>>> }
>>>
>>> Using the query A (with filter by st_distance(...) <= 100), I get
>>> fourcities in my result set.
>>> Using query B, however, I only get threeout of the fourcities as result.
>>>
>>> Please see the Github gist at [2]for details.
>>>
>>> All of the four cities that should appear have distances from the
>>> centroid significantly under
>>> 100 units, so it shouldn't just be a floating point precision issue or
>>> something along that lines.
>>>
>>> As far as I understand the SQL MM standard and VOS documentation
>>> st_distance(?a, ?b) <= 100)and st_intersects (?a, ?b, 100)should be
>>> equivalent predicates
>>> provided that ?a and ?b are POINT geometries, right?If so, then this
>>> seems to be a bug.
>>> Just want to confirm my understanding before creating Github issue on
>>> this.
>>>
>>>
>>> Regards,
>>>
>>> Markus Ackermann
>>>
>>>
>>>
>>> [1]http://downloads.linkedgeodata.org/releases/2014-09-09/
>>> <http://downloads.linkedgeodata.org/releases/2014-09-09/>
>>>
>>> [2] https://gist.github.com/neradis/01cb99080baf6e29cde6
>>> <https://gist.github.com/neradis/01cb99080baf6e29cde6>
>>>
>>> ------------------------------------------------------------------------------
>>> New Year. New Location. New Benefits. New Data Center in Ashburn, VA.
>>> GigeNET is offering a free month of service with a new server in Ashburn.
>>> Choose from 2 high performing configs, both with 100TB of bandwidth.
>>> Higher redundancy.Lower latency.Increased capacity.Completely compliant.
>>> http://p.sf.net/sfu/gigenet <http://p.sf.net/sfu/gigenet>
>>> _______________________________________________
>>> Virtuoso-users mailing list
>>> Virtuoso-users@lists.sourceforge.net
>>> <mailto:Virtuoso-users@lists.sourceforge.net>
>>> https://lists.sourceforge.net/lists/listinfo/virtuoso-users
>>> <https://lists.sourceforge.net/lists/listinfo/virtuoso-users>
>>
>
>
>
> ------------------------------------------------------------------------------
> New Year. New Location. New Benefits. New Data Center in Ashburn, VA.
> GigeNET is offering a free month of service with a new server in Ashburn.
> Choose from 2 high performing configs, both with 100TB of bandwidth.
> Higher redundancy.Lower latency.Increased capacity.Completely compliant.
> http://p.sf.net/sfu/gigenet
> _______________________________________________
> Virtuoso-users mailing list
> Virtuoso-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/virtuoso-users
------------------------------------------------------------------------------
New Year. New Location. New Benefits. New Data Center in Ashburn, VA.
GigeNET is offering a free month of service with a new server in Ashburn.
Choose from 2 high performing configs, both with 100TB of bandwidth.
Higher redundancy.Lower latency.Increased capacity.Completely compliant.
http://p.sf.net/sfu/gigenet
_______________________________________________
Virtuoso-users mailing list
Virtuoso-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/virtuoso-users
