Visualization of geospatial SPARQL query results for QLever on a map, either as individual objects or as a heatmap. Can handle hundreds of millions of result rows, tested with over 200 million results (all streets in OSM). Implemented as a middle-end / middleware. This is still very much hacked-together, use with care.
Examples: All railway lines in OSM, All buildings in Germany in OSM
- gcc > 5.0 || clang > 3.9
- xxd
- libcurl
- libpng (for PNG rendering)
- Java Runtime Environment (for compiling the JS of the web frontend)
- zlib (for gzip compression)
- OpenMP
Compile yourself:
$ git clone --recurse-submodules https://github.com/ad-freiburg/qlever-petrimaps
$ cd qlever-petrimaps
$ mkdir -p build && cd build
$ cmake ..
$ make
via Docker:
$ docker build -t petrimaps .
To start:
$ petrimaps [-p <port=9090>] [-m <memory limit] [-c <cache dir>]
Requests can be send via the ?query get parameter.
The QLever backend to use must be specified via the ?backend get parameter.
IMPORTANT: the tool currently expects the geometry to be the last selected column.
PREFIX geo: <http://www.opengis.net/ont/geosparql#>
PREFIX osmkey: <https://www.openstreetmap.org/wiki/Key:>
SELECT ?osm_id ?geometry WHERE {
?osm_id osmkey:building ?building .
?osm_id geo:hasGeometry ?geometry .
}
The tool caches query results and memory usage will thus slowly build up. There is a primitive memory limit which can be set via the -m parameter (in GB). By default, 90% of the available system memory are used.
If a query runs out of memory, you can clear all existing caches by requesting
/clearsession
/clearsessions will also work. Optionally, you can specify the session id via `?id='.
If -c specifies a serialization cache directory, the complete geometries downloaded from a QLever backend will be serialized to disk and re-used on later startups. This significantly speeds up the loading times.