Skip to content


Repository files navigation


Semantic WFS with a Linked Data Backend

This project is a Java wrapper connecting to a triple store and exposing results of SPARQL queries including a geometry literal as a WFS geospatial webservice.

The project maps FeatureTypes to SPARQL queries and allows the configuration of said SPARQL queries in a webinterface.

This webservice supports the following WFS types:

  • WFS 1.0, 1.1.0 and 2.0
  • OGC API Features Core, OGC API Features CRS and OGC API Features CQL partly

SemanticWFS Infrastructure

Getting started

Currently, there are two ways to deploy the SemanticWFS service.

Installation using Docker

To deploy the SemanticWFS using Docker, you can follow these steps:

  • Clone the repository
  • Modify the triplestoreconf.json and wfsconf.json according to your needs
  • Build the Docker image, e.g.
docker build . -t semanticwfs
  • Deploy the Docker image, e.g.
docker run -p 8080:8080 semanticwfs
  • Access SemanticWFS via browser at BASE_URL/semanticwfs

A Gitlab CI workflow is included in this repository.

Installation as a web application using Tomcat

To deploy the SemanticWFS as a web application in Apache Tomcat, you can follow these steps:

  • Build the application using Maven
  • Copy and/or modify the following configuration files into the Tomcat root folder:
    • htmltemplate.txt
    • htmltemplate2.txt
    • htmlcovtemplate.txt
    • triplestoreconf.json
    • wfsconf.json
  • Copy the resulting .war file into the Tomcat webapps directory

A machine readable version of this installation process is documented in the included Dockerfile.

Supported literal types

The SemanticWFS currently supports reading the following literal types found in RDF graphs:

  • OGC WKTLiterals as defined in the GeoSPARQL standard
  • OGC GMLLiterals as defined in the GeoSPARQL standard
  • GeoJSON literals
  • Well-Known-Binary literals

Export formats

The SemanticWFS currently supports the following formats for export:

Adding Triple Stores

Triple stores can be added to the SemanticWFS using the triplestoreconf.json file. The file needs a SPARQL endpoint address, and certain configurations:

  "name":"Triple Store Configuration",

A triple store needs a queryable SPARQL endpoint address and a designation (name) to identify it in the SemanticWFS configuration. In addition, several property names need to be given to the SemanticWFS in order to create correctly formatted queries:

  • type-Property: The property depicting the relation rdf:type in the respective triplestore
  • geo-Property: A list of properties depicting geometry literals in the respective triplestore
  • label-Property: A property which represents the property used for labels

Finally, a limit for boundingbox queries may be defined. A bounding box query is sent on initialization to get bounding boxes for the respective feature collections defined for the triple store.

Adding Collections

Once a triple store has been configured in the SemanticWFS implementation, a OGC API Feature Collection may be defined from a SPARQL query and a CRS definition. These collections are stored in the wfsconf.json configuration file.

  "servicetitle":"BKG WFS Service",
  "servicedescription":"Testwebservice with a Triple Store backend",
      "description":"Cities in Wikidata",
      "query":"SELECT ?item ?itemLabel ?the_geom WHERE{ ?item wdt:P31 wd:Q515 . ?item wdt:P625 ?the_geom . SERVICE wikibase:label { bd:serviceParam wikibase:language '[AUTO_LANGUAGE],en'. } }",

The wfsconf includes as baseurl which configures the URL under which the SemanticWFS will be hosted, the name of the webservice and a servicedescription. To add a new feature collection, the datasets array needs to be extended with a JSON object formatted as follows:

  • name: The name of the FeatureCollection as it should appear in the SemanticWFS interface
  • description: A short description of the FeatureCollection to be defined
  • type: The type of FeatureCollection, either vector data (WFS) or raster data (WCS)
  • query: The SPARQL query to retrieve the FeatureCollection. The SPARQL query needs to include the variable defined in the indvar property and at least one variable ending in _geom to identify the geometry literal.
  • triplestore: The address of the SPARQL endpoint
  • indvar: The variable in the SPARQL query which retrieves instances
  • targetCRS: The CRS used for geometries which are queried from the triple store defined as an EPSG code
  • useorderby: Adds an orderBy statement to the query (may run into performance issues in certain triple stores
  • class: The main class to be queried. Should be the same class as defined in the SPARQL query
  • geometrytype: The type of geometry which is expected as a result from the SPARQL endpoint. Relevant for downlift formats which only allow to only represent one geometry type.
  • namespace: The namespace used for the classes which are queried