LinkedGeoData (LGD) is an effort to add a spatial dimension to the Web of Data / Semantic Web. LinkedGeoData uses the information collected by the OpenStreetMap project and makes it available as an RDF knowledge base according to the Linked Data principles. It interlinks this data with other knowledge bases in the Linking Open Data initiative.
The project web site can be found here. If you are running Ubuntu then this repository contains everything you need to transform OpenStreetMap data to RDF yourself. For other systems please consider contributing adaptions of the existing scripts.
The following commands should get you started with a running Monaco dataset:
git clone https://github.com/GeoKnow/LinkedGeoData.git
cd LinkedGeoData
make clean
make
docker-compose up
# Quirk: Sometimes the nominatim container startup fails
# indicated by an error message that only reverse-only search is available
# In that case restart the container:
docker-compose restart lgd-nominatim-webServices will run under these ports:
- Nominatim: http://localhost:8012/nominatim
- Sparqlify: http://localhost:8013/sparql
- Ontop: http://localhost:8014/ and http://localhost:8014/sparql
- Pubby: http://localhost:8021/
- The default settings are in env.dist.
- If the file
.env. does not exist then themakeinvocation will also create it fromenv.dist. - The
.envfile by default contains the settingPROJECT_NAME=linkedgeodata. Make sure that the project name matches the lower-case spelling of the name of the folder containing the git repo. - Most configuration changes, such as port and database settings, take effect when restarting the containers.
- Many data and config files are stored in volumes whose naming is
${parent-directory}_${service-name}-vol. For examplelinkedgeodata_lgd-osmosis-sync-vol. You can check existing volumes withdocker volume ls. - Before starting the containers the sources for the initial data and incremental updates can be configured. These settings should not be changed after starting the containers.
- SQL scripts and RDB2RDF Mappings are located in the sql and sml folders, respectively. The build process bundles these up as a debian package that gets installed in the docker container on docker build. Therefore, changes to these resources require the debian package to be updated.
- Please refer to the Update Section
The architecture shown in the image below. The docker setup is located in the linkedgeodata-docker folder.
- This project first uses Osmosis to initialize a 'raw' OpenStreetMap postgis database (using simple schema) from a
.osm.pdffile. - Then, this database is extended with additional tables containing RDF mapping - and interlinking - information. Also, helper views are provided for simplifying access to the integrated information.
- Further, a nominatim setup (based on osm2pgqsl) is performed to further enrich the initial database osm data.
- A set of RDB2RDF mappings is provided that enables running SPARQL queries over the postgis database. The SPARQL-2-SQL rewriting engine we use is Sparqlify.
- Dumps are generated by simply running preconfigured SPARQL queries.
This project requires Make and Apache Maven to build (Java 11+ required). Maven builds are not dockerized. Therefore any built artifacts will be cached in the local repository as usual.
They include the SQL files and mappings that enable rewriting SPARQL queries to SQL ones over an OpenStreetMap (and Nominatim) database. Furthermore, bash scripts are avaiable for helping setting up an LGD database. The mavenization and dockerization re-package these resources.
The following folders contain resources that are copied when building the lgd-tools-resources jar bundle
- sql SQL scripts for extending on OSM simple schema database
- sml The mapping files in SML format. Convert to e.g. r2rml using the mapping converter.
The scripts in the bin folder become part of the debian packaging of the cli tools lgd-tools-pkg-deb-cli
- bin Bash scripts for setting LinkedGeoData up (Ubuntu)
There is a pom.xml that creates a jar file from a snapshot of the nominatim git. Especially for development this is much faster than repeated clones of the full git repo.
The docker-based architecture is aimed at making it easy to contribute new or alternative components that can sit side-by-side with the core of the system - which is the a virtual knowledge graph view over an OSM database. Please open issues for discussion.
Examples include but are not limited to:
- A more modern Linked Data Interface that displays GeoSPARQL geometries out-of-the-box
Nicer SPARQL interface (YASGUI)✓- Another data virtualization engine in order to ease comparision with the already integrated ones
- Updates to the existing OSM-RDF mappings, proposals about how this system could be improved.
- Proposals for a better IRI schema. For example, the 'triplify' in the IRIs is archaic. Migration to the pattern used by Sophox seems very worthwhile. Because of the virtual knowledge graph approach there should be no problem to use the legacy approach in parallel.
- General proposals for architecture improvements (e.g. config options in the docker setup to improve modularity)
Dockerfiles for services such as a Linked Data or SPARQL interfaces should be designed to allow configuration of the target SPARQL endpoint(s), ideally via the docker environment.
The content of this project are licensed under the GPL v3 License.