This paper explores the integration of geo-spatial data into RDF (Resource Description Framework) using Apache Jena, a popular Java-based framework for building Semantic Web applications. We explain the basic representation of geo-spatial data in RDF with a focus on both the new GeoSPARQL 1.1 standard and Apache Jena. Our investigation covers advanced techniques, such as transformation of coordinate reference systems, aggregation of geo-spatial data, creation of new geo-objects, and simplification of polygons. Additionally, we discuss the usage of the H3 Grid as a Discrete Global Grid System (DGGS) for geo-spatial conversion. Furthermore, we present performance optimisations specific to Apache Jena, including per-graph geo-indexing, improved geo-index serialization for faster startup times, and manual optimisation of geo-spatial queries. We conclude with a comparison of diferent geo-functions and outline future directions for enhancing geo-spatial data management in RDF.
The importance of using geo-spatial data in a knowledge graph goes back for more than a decade, such
as the early eforts to lift OpenStreetMap data into knowledge graphs [
The potential benefit of connecting geo-spatial data with knowledge graph entities such as from
Wikidata has been noted in [
In this section, we describe how to model geo-spatial data using RDF. In the following use cases, we
contextualise the (required) standard according to the requirements and the current state with regards to
Apache Jena GeoSPARQL [
The first requirement of working with geo-spatial data should be to store it in the knowledge graph.
Initial attempts at this were to encode the latitude and longitude of an object on the earth using the
wgs84 vocabulary.3 The modern way is to use GeoSPARQL with a sub-language for geometries, this
has the advantage of supporting lines and (multi-)polygons in addition to points. The most popular
choice here is the Well-known text (WKT) representation [
"POLYGON((26.5 45, 27 45, 27 45.2, 26.5 45))"^^geo:wktLiteral ] ; geo:hasCentroid [ a geo:Geometry ;
geo:asWKT "POINT(26.83 45.07)"^^geo:wktLiteral ] Figure 1: Representation of a feature with a geometry and a centroid point using GeoSPARQL/RDF
This is possible with GeoSPARQL 1.0 (before 2022, there was an error in the specification that
prevented the use of conventional GML in conforming implementations such as the Apache Jena version
4.6.0 [
After the information is represented like this, the whole range of geo-spatial functions provided by GeoSPARQL can be used in SPARQL queries. Commonly used functions include geo:sfWithin/ geof:sfWithin, geo:sfIntersects/geof:sfIntersects, etc., and can be used in linking or querying to correlate geo-spatial objects, like ?company geo:sfWithin ?country (the geometry of a company is geographically located within the polygon of a country) or FILTER(geof:sfIntersects(?riverGeom, ?regionGeom) (only include those SPARQL results where the geometry of the river intersects the geometry of a specific region).
Additionally, there can be more than one geometry information available for an entity, for example, the polygon describing the extent of the object as well as the centre point (centroid). There are standardised properties for this information available starting with GeoSPARQL 1.1.
Finally, it is possible to do mathematical computations on geo-spatial objects. The function geof:distance (GeoSPARQL 1.0) can be used to calculate the distance between two objects, as well as the vendor function spatialF:distance in Apache Jena and geof:metricDistance in GeoSPARQL 1.1. In GeoSPARQL 1.1 it is also possible to calculate the area of an object with the functions geof:area or geof:metricArea.
Oftentimes, especially when integrating data from diferent sources, the geo-spatial data is not in the same Coordinate Reference System (CRS). For example, the same polygon as above, when expressed in the CRS with EPSG4 code 38445 looks like this: "<http://www.opengis.net/def/crs/EPSG/0/3844> POLYGON((390018.693878 618366.368293, ˓→ 390877.440409 657778.063276, 413096.430405 657224.263781, 390018.693878 ˓→ 618366.368293))"^^geo:wktLiteral
Recording the CRS in the data is supported in GeoSPARQL 1.0 and is done by adding a CRS IRI in front of the WKT literal. It is the most practical to work with integrated data if it is all expressed in the same CRS. For that, CRS transformations are required.
This possibility to transform the CRS exists in Apache Jena with a custom vendor function: spatialF:transformSRS(?originalGeometry, <http://www.opengis.net/def/crs/EPSG/0/3844>). It has been standardised in GeoSPARQL 1.1 as geof:transform(?geom, ?crsIRI).
Support for CRS transformations is currently crucial in Apache Jena to calculate metric bufers and distances. (Bufering can be used for many purposes, such as finding objects within a certain distance to the boundary or intersection checks with an error margin.) Consequently, in order to calculate a metric bufer around a polygon, the following SPARQL query is required:
BIND(geof:transform(?geo, <http://www.opengis.net/def/crs/EPSG/0/3844>) AS ?metricGeo) BIND(geof:buffer(?metricGeo, 11113.9, uom:metre) AS ?metricBuffered) BIND(geof:transform(?metricBuffered, <http://www.opengis.net/def/crs/OGC/1.3/CRS84>) AS ˓→ ?geoBufferedCrs84)
Otherwise, it is possible to calculate the bufer by adding degrees of longitude/latitude, however, this has a distorting efect due to the shape of the earth, as can be seen in Figure 2. We have opened a clarification request as GeoSPARQL issue 398. 6
In addition to the CRS, it can be desirable to transform between representation language of the geometries. On the one hand, processing of integrated data is easier when it is all using the same representation (we found WKT to be predominant). One use case is the consumption of disaster data from the Global Disaster Alert and Coordination System (GDACS). GeoJSON data is provided for various disaster events, for example, the tropical cyclone number 1001053,7 as shown in Figure 3. On the other hand, some other applications such as the map viewer Leaflet can also work more natively with GeoJSON.
Starting with GeoSPARQL 1.1, conversion functions between representations have been added.
They are using the geof:as*** naming convention: geof:asGeoJSON, geof:asGML, and geof:asWKT.
We have already implemented the required support in our JenaX extension [
VALUES ?geojsonUrl { <https://www.gdacs.org/contentdata/resources/TC/1001053/ ⌋ ˓→ geojson_1001053_2.geojson> } BIND(strdt(url:text(?geojsonUrl), geo:geoJSONLiteral) AS ?geojson) ## currently implemented: BIND(spatialF:transformDatatype(?geojson, geo:wktLiteral) AS ?wktGeom) ## standards compliant:
BIND(geof:asWKT(?geojson) AS ?wktGeom)
When assembling open geo-spatial data, the OpenStreetMap8 project is a huge treasure trove of collaboratively collected map data of the world. However, many geo-spatial objects in OSM are modelled as consisting of many parts, like many piece-wise relations of a river or a railroad network.
With GeoSPARQL 1.1, geo-spatial aggregate functions were introduced that can be used in the SPARQL queries together with the GROUP BY clause. GeoSPARQL 1.1 defines the functions geof:aggBoundingBox, geof:aggBoundingCircle, geof:aggCentroid, geof:aggConcaveHull, geof:aggConvexHull, and geof:aggUnion. 7https://gdacs.org/report.aspx?eventid=1001053&eventtype=TC 8https://www.openstreetmap.org/about SELECT ## currently implemented: (geof:lineMerge(geof:collect(?wayGeom)) AS ?riverGeom) ## possible standards suggestion? (geof:aggConcatLines(?wayGeom) AS ?riverGeom) WHERE { ?s a osm:relation ; osmkey:name "Elbe" ; osmrel:member/osm:id ?m .
?m geo:hasGeometry/geo:asWKT ?wayGeom .
} Figure 4: Example SPARQL query to reconstruct the Elbe river using aggregate functions
However, for our use case, we would also need a function to aggregate line strings. Such a function
was proposed in the GeoSPARQL 1.1 Motivations paper [
Such aggregate functions can then be used to combine the segments of a river back into a single river object, which is oftentimes more practical for our use case than having to deal with the individual pieces. This is shown in Figure 4.
It can be useful to create a connection between multiple points through a line, this also makes it easier to detect which areas are crossed by a path connecting multiple points. To assist with this, we provide the geof:makeLine function that turns a geometry collection into a line. Similarly, it can be useful to create new points, especially with longitude and latitude at hand, that may be coming from legacy properties. This can be done using the spatialF:convertLatLon function (the function name also makes it hard to mix up latitude and longitude in the parameters). The query in Figure 5 demonstrates how to achieve a visualisation of a company’s suppliers based on their coordinates. It results in line strings from Frankfurt, Germany, to a list of companies that are geo-coded using legacy latitude and longitude properties from the CoyPu project.10 These functions are implemented in our JenaX extension.
SELECT
(geof:makeLine(geof:union(?frankfurtGeom, ?supplierGeom)) AS ?lineGeom) WHERE {
GRAPH <https://data.coypu.org/cities/> { <http://www.wikidata.org/entity/Q1794> geo:hasGeometry/geo:asWKT ˓→ ?frankfurtGeom } GRAPH <https://data.coypu.org/companies/demo/> { ?s coy:isSupplierOf "ferrero" ; coy:hasLatitude ?lat ; coy:hasLongitude ?lon .
BIND(spatialF:transformSRS(spatialF:convertLatLon(?lat, ?lon), ˓→ <http://www.opengis.net/def/crs/OGC/1.3/CRS84>) AS ?supplierGeom) }
}
Some polygons, especially those of administrative boundaries, can have very detailed borders whose size in WKT representation amounts to dozens of megabytes. It can be useful to simplify such geospatial objects, either to improve the performance of map visualisation, to speed up containment checks when accuracy is less important, or to reduce the size requirements of the polygon. We are providing a function geof:simplifyDp or geof:simplifyVw that uses the Douglas-Peucker algorithm or the Visvalingam-Whyatt algorithm to simplify polygons.
These functions are implemented in our JenaX extension and have also been suggested by others on the GeoSPARQL issue 257.11 Such a function has also been suggested for inclusion in a later version of GeoSPARQL.
Discrete global grid systems (DGGS) that sub-divide the earth into a grid have gained importance,
as can be seen from [
One example of working with H3 in our current extension is shown in Figure 6. In the example, we are tracing existing public transport routes from the MoIn project13 using the H3 grid cells that contain them. This serves as a basis for analysing public transport within a region, such that reachability can be assessed on cell granularity. The next step is to align the H3 functions with GeoSPARQL 1.1. This process might identify missing functionalities for working with DGGS in the current GeoSPARQL standard.
Latitude and longitude are a source of frequent sorrow,14 because it does not seem to be clear which one is the first coordinate and which one is the second. This confusion is further emphasised by the two CRS CRS:8415 and EPSG:432616 that are both in widespread use. Both refer to the World Geodetic System 1984 (WGS 84), but CRS:84 uses the coordinate order (longitude, latitude), whereas EPSG code 4326 uses the (latitude, longitude) order. CRS:84 is also the default CRS for GeoSPARQL WKT literals. In our project, we faced raw input data where the coordinates were mixed up for some records only. Even today, the Geo-3D view on the popular SPARQL web interface Yasgui17 incorrectly plots points on the earth with latitude and longitude reversed. For this reason, we are suggesting to have explicit functions geof:lat and geof:lon that would always return the named coordinate. These functions are implemented in our JenaX extension. Such functions are also suggested in the GeoSPARQL issue 160.18 Additionally, some applications require retrieving the latitude and longitude of a point as separate columns. With GeoSPARQL 1.1, the functions geof:maxX and geof:maxY could be (ab)used to retrieve the coordinates from a point, but knowledge of the coordinate order is required.
Some system-specific (targeted) performance improvements were realised on a technical level, which are reported below.
In our use case, we have several named graphs, for example, some of which contain disaster events, others which contain administrative geo-boundaries of countries in the world, etc.. For certain use cases, we know exactly the set of graphs over which we want to query. If the question is to know which country an event is located in, it is enough to search only through the administrative regions graph. By default, the Apache Jena geo-index is global across the whole data set. So we implemented an option to create a geo-index by named graphs. For use cases with multiple graphs containing spatial data, this can provide a significant performance boost. The results of our benchmark are displayed in the following table. We tested the approach with an artificial geo-spatial data set consisting of 16 graphs with 262 144 geo-spatial objects in each and a geof:sfIntersects spatial query.
Original impl. Improved impl.
Matching objects Speed-up/slow-down Query a single named graph Query all named graphs . . .
. . . using GRAPH ?g {...} . . . using union default graph 35 seconds 5.8 minutes 1.4 minutes 5 seconds 1.4 minutes 1.4 minutes
During our project, we were hampered by the long start-up time of Apache Jena Fuseki reading the geospatial index file. To that end, we implemented an improved storage format (serialisation, deserialisation) of the database geo-index on disk. To test the efectiveness of our new implementation, a small and a larger artificial geo-spatial data set was generated containing either 16 named graphs with 512 × 512 polygon tiles, or 32 named graphs with 1024× 1024 polygon tiles each, spread equally across the globe.
Original impl. Improved impl. Speed-up/slow-down Small geo-index Large geo-index build time load time build time load time 1.4 minutes 24 seconds 9 minutes 3 minutes 1.8 minutes 2 seconds 12 minutes 8 seconds
While it takes longer to build the index, the start-up times are much faster afterwards, which was an important improvement for our project.
Currently, the geo-index in Apache Jena is static and built at start-up. This means it unfortunately does not support SPARQL UPDATE or LOAD statements to modify the data contained in the database (at least not without restarting). In our project, we had frequent updates to geo-spatial data. While the ideal goal would be to have a self-updating geo-index, for now, we have implemented a method to update the geo-index manually during the run-time of the Apache Jena Fuseki server. The code is available as a Jena Fuseki Module on our GitHub.19
At the time of writing, Apache Jena is not capable of any advanced query optimisation for GeoSPARQL queries. For example, to find all geo-spatial objects contained within the United States, a naive query might look like this: <https://data.coypu.org/country/USA/geometry/boundary> geo:sfContains ?object .
On our administrative boundaries data set with 49 535 geo-spatial objects, this query takes about 40 seconds. The reason is that the geographical region of the United States includes overseas regions, so when the server implementation is looking for objects contained within the US, it will first look up all objects in the geo-index using the bounding box of that multi-polygon, and that efectively spans the whole world (see Figure 7).
Ideally, the GeoSPARQL database could detect such situations and do query optimisation for them. For our case, we have chosen the manual way of providing some additional functions to work with the queries: spatial:st_dump can be used to break down a multi-polygon into its parts, and spatial:withinBoxMultipolygonGeom can be used to make such a geo-index lookup. Our manually tuned query is thus VALUES ?boundary { <https://data.coypu.org/country/USA/geometry/boundary> } ?boundary geo:asWKT ?boundaryGeom . ?feature spatial:withinBoxMultipolygonGeom (?boundaryGeom) . ?feature geo:hasGeometry ?object .
?boundary geo:sfContains ?object . and only takes 8 seconds to execute.
These functions are available in our JenaX extension. GeoSPARQL 1.1 has some basic support for the deconstruction of multi-polygons: geof:geometryN(?geom, ?geomIndex) can be used to extract the N th geometry and geof:numGeometries can be used to query the total number of geometries. However, using these functions is cumbersome at best and will require multiple queries and mechanical construction of queries. Hence we propose to add a property function to destructure geometry collections at GeoSPARQL issue 399.20
The following lists give an overview of the new functions in GeoSPARQL 1.1 and their availability in Apache Jena and the JenaX extension. geo:GeometryCollection, geo:FeatureCollection. (These can be used to model geometry collections using RDF.) Generic informative properties Properties to connect specific geometries to a feature
geo:hasCentroid, geo:hasBoundingBox.
Properties for resolution and accuracy information
geo:has(M)SpatialResolution, geo:has(M)SpatialAccuracy.
Properties for geometry representation
geo:asGeoJSON, geo:asKML, geo:asDGGS.
Functions
Aggregate functions geo:has(M)Size, geo:has(M)Length, geo:has(M)PerimeterLength, geo:has(M)Area, geo:has(M)Volume. GeoSPARQL 1.1 geof:metricDistance geof:metricBufer geof:concaveHull geof:boundingCircle geof:centroid geof:dimension geof:coordinateDimension geof:spatialDimension geof:geometryType geof:is3D geof:isEmpty geof:isMeasured geof:isSimple geof:transform geof:asWKT geof:asGML geof:asGeoJSON geof:asKML geof:asDGGS geof:(m)length geof:(m)perimeter geof:(m)area geof:geometryN geof:numGeometries geof:max{X,Y,Z} geof:min{X,Y,Z}
J 1 ✓ ✓ ✓ ✓ J Availability in Apache Jena JX Availability in JenaX extension 1–5 Non-standard function (M)(m) a metric variant of this function is also described, e.g. geof:(m)area → geof:area and geof:metricArea ↑ this function was upstreamed from JenaX * these functions are not the same but can be used for a similar purpose
Further functions that might be interesting for the GeoSPARQL community that are not part of the standard but available in Jena or JenaX include: • functions to create new objects such as spatialF:convertLatLon[J], geof:makeLine[JX], and spatialF:convertLatLonBox[J], • functions geof:simplifyDp[JX] and geof:simplifyVw[JX] to simplify polygons, • geof:collect[JX] to create a geometry collection, and spatial:st_dump[JX] to destructure a geometry collection into its parts, • geof:lat[JX] and geof:lon[JX] to unambiguously address the latitude and longitude of a point, • a range of functions to work with the H3 DGGS, with the possibility to specify the desired cell resolution when approximating existing geometries (JenaX), • and some functions to quickly retrieve objects from the geo-index using spatial:intersectBoxGeom[J], spatial:withinBoxGeom[J], spatial:withinCircleGeom[J], and spatial:withinBoxMultipolygonGeom[JX].
Local coordinate reference systems are being discussed in GeoSPARQL issue 500.21 They are an
important requirement for modelling local spatial data that is not rooted in any particular location
on the Earth and can operate in Euclidean space rather than on the ellipsoid. Examples of such usage
include storage warehouse robots, architecture and building planning, 3D-printing machines, or toy
building block instructions. Approaches for temporal RDF modelling have been proposed already
in 2007 [
As has been shown, there is a significant advantage of using a standardised vocabulary like GeoSPARQL to process spatial data with RDF. Furthermore, GeoSPARQL 1.1 brings many advantages compared to the first version of the standard. We are interested in contributing additional GeoSPARQL 1.1 support to Apache Jena and have already started to do so. Yet, GeoSPARQL 1.1 is still not enough for some use cases. We believe some extensions may be interesting to the larger community and thus it would be beneficial to have them standardised. In that regard, we have already begun to open some issues on the GeoSPARQL issue tracker.
The source code for this work is available on our GitHub: • Apache Jena changes as described in Section 4: https://github.com/AKSW/jena/tree/coypu • Online geo-index module for Apache Jena:
https://github.com/AKSW/fuseki-mods/tree/adaptions/jena-fmod-geosparql
• JenaX extension module: https://github.com/Scaseco/jenax
• RdfProcessingToolkit: https://github.com/SmartDataAnalytics/RdfProcessingToolkit [
Queries framework [
• Apache Jena with changes: aksw/fuseki-geoplus:5.0.0-1
• Apache Jena without changes: aksw/fuseki-vanilla:5.0.0-1
These RDF data sets were loaded in the experiments:
• geoBoundaries [
The authors acknowledge the financial support by the German Federal Ministry for Economic Afairs and Climate Action in the project CoyPu (project number 01MK21007A) and by the German Federal Ministry for Digital and Transport in the Project Moby Dex (project number 19F2266A). All map screenshots from OpenStreetMap.23