Introduction

GraphDB-SE has special support for 2-dimensional geo-spatial data, which uses the WGS84 Geo Positioning RDF vocabulary (World Geodetic System 1984). Special indices can be used for this data, which permit the efficient evaluation of special query forms and extension functions that allow finding locations, which are:

• within a certain distance of a point, i.e. within the specified circle on the surface of the sphere (Earth), using the nearby(...) construction;
• within rectangles and polygons, where the vertices are defined using spherical polar coordinates, using the within(...) construction.

The WGS84 ontology can be found at: http://www.w3.org/2003/01/geo/wgs84_pos and contains several classes and predicates:

Creating Geo-spatial Index

The following jar files (included with the GraphDB distribution) must be on the classpath, in order for the geo-spatial extensions to function correctly: jsi-1*.jar, log4j-1*.jar, sil-0*.jar, trove4j-2*.jar

Before the geo-spatial extensions can be used, the geo-spatial index must be built. This is achieved by inserting and committing a dummy statement (that is not actually stored), which uses a special predicate:

PREFIX ontogeo: <http://www.ontotext.com/owlim/geo#>
INSERT DATA { _:b1 ontogeo:createIndex _:b2. }

If the indexing is successful, the above update succeeds, otherwise an exception is thrown. Information about the indexing process and any errors can be found in the log. Note that this update will fail if there is no geo-spatial data in the repository, i.e. no statements describing resources with latitude and longitude properties.

Geo-spatial query syntax

The Geo-spatial query syntax is the SPARQL's RDF Collections syntax. This syntax uses round brackets as a shorthand for the statements, connecting a list of values using rdf:first and rdf:rest predicates with terminating rdf:nil. Statement patterns that use one of the special geo-spatial predicates, supported by GraphDB-SE, are treated differently by the query engine. The following special syntax is supported when evaluating SPARQL queries. All descriptions use the namespace:

omgeo: <http://www.ontotext.com/owlim/geo#>

PREFIX geo-pos: <http://www.w3.org/2003/01/geo/wgs84_pos#>
PREFIX geo-ont: <http://www.geonames.org/ontology#>
PREFIX omgeo: <http://www.ontotext.com/owlim/geo#>
SELECT distinct ?airport
WHERE {
  ?base geo-ont:name "Seoul" .
  ?base geo-pos:lat ?latBase .
  ?base geo-pos:long ?longBase .
  ?link omgeo:nearby(?latBase ?longBase "50mi") .
  ?link geo-ont:name ?airport  .
  ?link geo-ont:featureCode geo-ont:S.AIRP .
}

PREFIX geo-pos: <http://www.w3.org/2003/01/geo/wgs84_pos#>
PREFIX geo-ont: <http://www.geonames.org/ontology#>
PREFIX omgeo:   <http://www.ontotext.com/owlim/geo#>
SELECT ?feature ?lat ?long
WHERE {
  ?link omgeo:within(45.85 9.15 48.61 13.18) .
  ?link geo-ont:featureCode geo-ont:R.TNL .
  ?link geo-ont:name ?feature .
  ?link geo-pos:lat ?lat .
  ?link geo-pos:long ?long .
}

PREFIX geo-pos: <http://www.w3.org/2003/01/geo/wgs84_pos#>
PREFIX geo-ont: <http://www.geonames.org/ontology#>
PREFIX omgeo:   <http://www.ontotext.com/owlim/geo#>
SELECT ?feature ?lat ?long
WHERE {
?link omgeo:within( "51.45" "-2.59"
  "54.99" "-3.06"
  "55.81" "-2.03"
  "52.74"  "1.68"
  "51.17"  "1.41" ) .
  ?link geo-ont:featureCode geo-ont:S.CAVE .
  ?link geo-ont:name ?feature .
  ?link geo-pos:lat ?lat .
  ?link geo-pos:long ?long .
}

Extension query functions

At present there is just one SPARQL extension function.

PREFIX geo-pos: <http://www.w3.org/2003/01/geo/wgs84_pos#>
PREFIX geo-ont: <http://www.geonames.org/ontology#>
PREFIX omgeo:   <http://www.ontotext.com/owlim/geo#>

SELECT distinct ?airport_name
WHERE {
  ?a1 geo-ont:name "Bournemouth" .
  ?a1 geo-pos:lat ?lat1 .
  ?a1 geo-pos:long ?long1 .
  ?airport omgeo:nearby(?lat1 ?long1 "80mi" ) .
  ?airport geo-ont:name ?airport_name .
  ?airport geo-ont:featureCode geo-ont:S.AIRP .
  ?airport geo-pos:lat ?lat2 .
  ?airport geo-pos:long ?long2 .
  ?a2 geo-ont:name "Brize Norton" .
  ?a2 geo-pos:lat ?lat3 .
  ?a2 geo-pos:long ?long3 .
  FILTER( omgeo:distance(?lat2, ?long2, ?lat3, ?long3) < 80)
}
ORDER BY ASC( omgeo:distance(?lat2, ?long2, ?lat3, ?long3) )

Implementation details

Knowledge of the implementation's algorithms and assumptions allow users to make the best use of the GraphDB-SE geo-spatial extensions. The following points are significant and can affect the expected behaviour during query answering:

• Spherical Earth – the current implementation treats the Earth as a perfect sphere with a radius of 6371.009km;
• Only 2-Dimensional points are supported, i.e. there is no special handling of geo:alt (metres above the reference surface of the Earth);
• All latitude and longitude values must be specified using decimal degrees, where East and North are positive and -90 <= latitude <= +90 and -180 <= longitude <= +180;
• Distances must be in units of kilometres (suffix 'km') or statute miles (suffix 'mi'). If the suffix is omitted, kilometres are assumed;
• omgeo:within( rectangle ) construct uses a 'rectangle' whose edges are lines of latitude and longitude, so the north-south distance is constant, and the rectangle described forms a band around the Earth, which starts and stops at the given longitudes;
• omgeo:within( polygon ) joins vertices with straight lines on a cylindrical projection of the Earth tangential to the equator. A straight line starting at the point under test and continuing East out of the polygon is examined to see how many polygon edges it intersects. If the number of intersections is even, then the point is outside the polygon. If the number of intersections is odd, the point is inside the polygon. With the current algorithm, the order of vertices is not relevant (clockwise or anticlockwise);
• omgeo:within() may not work correctly when the region (polygon or rectangle) spans the +/-180 meridian;
• omgeo:nearby() uses the great circle distance between points.