geosparql Leistungsproblem

Question

Ich habe ein Triple-Store, der 150 Millionen Anweisungen hat und alle enthalten Geometrien. Ich verwende derzeit GraphDB Triple Store und seine GeoSparql-Erweiterung. Bei der Kombination von GeoSparql- und Filterabfragen macht der Endpunkt nur komische Dinge. Die GraphDB-Seite hat bestätigt, dass es Probleme mit ihrer GeoSparql-Erweiterung gibt. Ich frage mich nur, ob das bei GeoSparql-Abfragen im Allgemeinen in Kombination mit Filterabfragen normal ist. Wenn geosparql viel schneller sein sollte (zum Beispiel virtuos), könnte ich einfach auf virtuos migrieren. Ansonsten muss ich vielleicht andere Lösungen finden. Dies könnte zu einer weiteren, allgemeineren Frage führen: Was sind beim effizienten Umgang mit geografischen Daten die effizientesten Möglichkeiten für räumliche Abfragen?

Hier ist ein Beispiel für das Leistungsproblem.

Diese Abfrage (nur eine Filterabfrage ohne geosparql Komponenten) hier nehmen 2-15 sec (was immer noch eine sehr lange Zeit):

PREFIX geo-pos: <http://www.w3.org/2003/01/geo/wgs84_pos#> 
PREFIX geo: <http://www.opengis.net/ont/geosparql#> 
PREFIX geof: <http://www.opengis.net/def/function/geosparql/> 
PREFIX xsd: <http://www.w3.org/2001/XMLSchema#> 
PREFIX sf: <http://www.opengis.net/def/sf#> 
select ?a 
WHERE { 
    ?a :hasPrimaryName ?o . 
    FILTER (contains(?o,'Paris')) 
} 

Diese Abfrage (die geosparql Erweiterung in GraphDB verwenden) dauert etwa 5 Sekunden mit oder ohne Limit:

PREFIX geof: <http://www.opengis.net/def/function/geosparql/> 
PREFIX geo-pos: <http://www.w3.org/2003/01/geo/wgs84_pos#> 
PREFIX geo: <http://www.opengis.net/ont/geosparql#> 
PREFIX omgeo: <http://www.ontotext.com/owlim/geo#> 
PREFIX xsd: <http://www.w3.org/2001/XMLSchema#> 
select * 
WHERE { 
    ?a geo:hasGeometry ?aGeom . 
    ?aGeom geo:asWKT ?aWKT . 
    FILTER (geof:sfWithin(?aWKT, '''<http://www.opengis.net/def/crs/OGC/1.3/CRS84> POLYGON((1.549072265625 49.468124067331644,3.31787109375 49.468124067331644,3.31787109375 48.436489955944154,1.549072265625 48.436489955944154,1.549072265625 49.468124067331644))'''^^geo:wktLiteral)) 
} 

beide Abfragen Kombination wird eine Zeitüberschreitung (nach 60sec), ob wir eine Grenze oder nicht verwenden:

PREFIX geo-pos: <http://www.w3.org/2003/01/geo/wgs84_pos#> 
PREFIX geo: <http://www.opengis.net/ont/geosparql#> 
PREFIX geof: <http://www.opengis.net/def/function/geosparql/> 
PREFIX xsd: <http://www.w3.org/2001/XMLSchema#> 
PREFIX sf: <http://www.opengis.net/def/sf#> 
select ?a 
WHERE { 
    ?a geo:hasGeometry ?aGeom . 
    ?aGeom geo:asWKT ?aWKT . 
FILTER (geof:sfWithin(?aWKT, '''<http://www.opengis.net/def/crs/OGC/1.3/CRS84> POLYGON((1.549072265625 49.468124067331644,3.31787109375 49.468124067331644,3.31787109375 48.436489955944154,1.549072265625 48.436489955944154,1.549072265625 49.468124067331644))'''^^geo:wktLiteral)) 
    ?a :hasPrimaryName ?o . FILTER (contains(?o,'Paris')) 
} 

Da wir in der Regel den Triple Store als Server für unsere Web Map-Schnittstelle verwenden und viele räumliche Abfragen in unserer Webkarte durchführen, ist die Effizienz von GeoSparql-Abfragen für uns wichtig. Abfragezeit wie 60s ist für uns nicht akzeptabel. Gibt es eine Möglichkeit, diese Situation zu verbessern? Entweder mit der Server-Seite (Geosparql-Abfragen) oder mit der Web-Map-Seite (wir verwenden Javascript)? Vielen Dank!

Answer 1

Die GeoSPARQL-Unterstützung von GraphDB verwendet einen Index für Prädikat-basierte Abfragen (z. B. ?a geo:sfWithin ?b), während funktionsbasierte Abfragen (z. B. filter(geof:sfWithin(?a, ?b))) einen vollständigen Scan erfordern. Sie können Ihre Abfragen neu schreiben, um den Prädikat-Index zu nutzen, z.

PREFIX geo-pos: <http://www.w3.org/2003/01/geo/wgs84_pos#> 
PREFIX geo: <http://www.opengis.net/ont/geosparql#> 
PREFIX geof: <http://www.opengis.net/def/function/geosparql/> 
PREFIX xsd: <http://www.w3.org/2001/XMLSchema#> 
PREFIX sf: <http://www.opengis.net/def/sf#> 
select ?a 
WHERE { 
    ?a geo:hasGeometry ?aGeom . 
    ?aGeom geo:asWKT ?aWKT . 
    ?aWKT geo:sfWithin '''<http://www.opengis.net/def/crs/OGC/1.3/CRS84> POLYGON((1.549072265625 49.468124067331644,3.31787109375 49.468124067331644,3.31787109375 48.436489955944154,1.549072265625 48.436489955944154,1.549072265625 49.468124067331644))'''^^geo:wktLiteral . 
} 

Beachten Sie, dass Literale als Objekt des Prädikats geo:sfWithin ist eine GraphDB-Erweiterung und kein Standard GeoSPARQL Funktion. In Ihrer vollständigen Abfrage verwenden Sie auch contains(?o, 'Paris'). Dies ist ein langsamer Vorgang, da ein vollständiger Scan erforderlich ist. Wenn Sie eine Volltextsuche benötigen, können Sie einen der GraphDB Lucene Connector ausprobieren, siehe http://graphdb.ontotext.com/documentation/free/lucene-graphdb-connector.html für weitere Informationen. Die Enterprise Edition von GraphDB verfügt auch über Konnektoren für Solr und Elasticsearch.