Raising an existing SDI to INSPIRE level

A practical example from Germany


Armin Retterath / German Working Group for Geoservices, Frankfurt, Germany

Some notes about me

  1. Architect of the SDI for the German Federal State Rhineland-Palatinate since 2005
  2. Chair of the German Working Group for Geoservices (~Spatial Data Services) since 2006

Key areas of activity

  1. Conception of the SDI and the central geoportal for Rhineland-Palatinate
  2. Consultation in technical matters
    • Implementation of SDI Infrastructure components with OpenSource Software
    • Implementation of geoportals at different levels of public authorities
  3. Contribution to different INSPIRE review processes
  4. Software development for FOSS project mapbender

Some further notes at the beginning

  • The presentation does not show the official position of the German Working Group Geoservices
  • It should only be seen as a best practise example for a regional SDI



Historical development of the SDI

Architectural concept

Implementation of INSPIRE





- Somewhere in Europe


Where else?

- Somewhere in Germany


So small?

It depend on the used scale ;-)


Some statistics:

  • Population: 4 Mio (~0.8% of the EU)
  • Area: 20.000 km2 (~0.5% of the EU)
  • Wine production: 6 Mio hectolitre (~3.4% of the EU)

Administrative Boundaries

NUTS 3 Level: 36


Administrative Boundaries

LAU 1 Level (Collective municipalities): 198


Administrative Boundaries

LAU 2 Level (Municipalities): 2459


Historical development of the SDI


  • Political decision to establish a SDI for Rhineland-Palatinate (by cabinet order)
  • Initial concept for the SDI and the geoportal
  • Europe-wide tender for a geoportal that should be freely distributable


  • Preparing of a fine-concept
  • Phase of implementation


  • 8th January - Opening to public access

Architectural concept (1)

General conditions in 2005

  • Many unclean implementations of OGC WMS/WFS
  • Only few servers available
  • No standards or spec for exchanging metadata (ISO19139 in a draft version)
  • No real idea how to model service-metadata (only UML graphics from ISO19119)

Architectural concept (2)

The basic ideas for service-metadata management

  1. Build an own relational information model for OWS
  2. Allow searching for WMS layer and WFS featuretype objects
  3. Let providers register/manage their OWS in the central database
  4. Extract all needed information from the service-capabilities
  5. Allow editing of some capabilities information
  6. Create persistant service urls to allow permanent integration into external GIS
  7. Monitoring of all distributed services and notify users/providers

Architectural concept (3)

Other concepts

  1. Central management of users and groups (authorities)
  2. CMS for WebGIS applications

Architectural concept (3)



OGC Newsletter June 2008 - Website of the month

OGC website of month screenshot

"... a perfect example of an interoperable service architecture and a living example of the emerging INSPIRE directive."

But - was this correct?

Til this time we didn't care about dataset-metadata and interoperable metadata

The viewpoint changes in december 2008 when we got a nice Christmas present from INSPIRE:

INSPIRE Metadata Regulation INSPIRE Metadata Regulation

OK - some time to think about - nearly 2 years :-)


- 10 month later -

The next present:

INSPIRE Network Services Regulation INSPIRE Network Services Regulation

Let's think a little bit deeper!

Status quo 2008

  • Many OWS
    • ~40 service providers
    • ~70 WMS (1.1.1)
    • ~15 WFS (1.0.0)
  • No metadata
  • Complex requirements from INSPIRE
  • A operational capabilities/security proxy for OWS
  • Some thousand registrated users

Solution: Solve the problems via a fascade
- INSPIRE proxy -


  • Use the old - but well known - standards
  • As less as possible effort for the data providers
  • Generate all metadata and capabilities documents on the fly
  • Solve the data-service-coupling problem in a reasonable way

What was done

  • Extension of the internal information model for dataset-metadata
  • Non-redundant management of layer-dataset and featuretype-dataset relations
  • 4 different possibilities to solve the data-service-coupling problem were implemented

Solution of the fundamental coupling problem

Options for the data providers

  • A priori coupling
    • Support given MetadataURL tags from capabilities
  • Coupling after service registration
  • Metadata Addon image

In Consequence 2011

We were able to fulfil following requirements

INSPIRE Metadata Regulation INSPIRE Network Services Regulation
  • Including all claimed complex relationships between the different xml documents
  • Without confronting the data providers with those things!

The END?

Not really

What we can do in the end of 2011

  • find and evaluate information by its metadata
  • view the found datasets via INSPIRE Viewing Services

Next in the tight schedule of the INSPIRE Directive

  • 2012 - Implementation of the access to the identified datasets via conformant download services
  • INSPIRE Network Services Regulation - Amendment for Download and Transformation Services INSPIRE Network Services Regulation

    Quite a bigger challenge!

    • The concret Guidance Paper came in June 2012
    • Conformant Download Services for Annex I + II should be available til 28.12.2012
    • No software fully implemented the prefered WFS 2.0 (ISO19142)
    • We had already download services which are based on older WFS 1.0 and WFS 1.1.0

    Our keys to solve that problem

    • Do it on a similar way as for the View Services - implement a fascade (proxy)
    • Use the ATOM Feed technology which was described in the Guidance Paper
    • Make every thing as easy as possible for the data providers

    In 2012 we had nearly 80 different data (service) providers (many municipalities) with more than 350 services

    Overview registrating departments

    Concrete implementation for INSPIRE Download Services

    • On the fly generation of ATOM Feeds (service and dataset feed) based on following information
      • Dataset metadata
      • Dataset - service - relations from our information model
      • Dynamically generated GetMap/GetFeature urls

    Example for protected sites

    Some other things we have done with help of the service-registry approach

    All components are based on FOSS

  • Mapbender
  • Postgres
  • Debian
  • Typo3
  • Conclusions

    • It is possible to implement INSPIRE without too much effort
    • You have to inform your data providers as early as possible and let them do only those things, which are really needed for the implementation
    • You can only stay on schedule, if some things are done at a central point
    • Keep it simple! - Provide simple and reliable interfaces allowing the users to access your INSPIRE/SDI infrastructure.
    • RLP Motto

      Ambiguous motto (RP): We just do it. and We make it easy.

    We have to see INSPIRE as a chance

    But we should enhance some things

    • Harvesting of metadata: The metadata propagation takes to long - in the ongoing time, many relevant infomation may change and then INSPIRE is not longer operative! We have to implement triggers that update metadata directly in the next upper catalogue in our catalogue hierachy.
    • Persistant URLS: It it quite relevant for a service-oriented architecture, that a URL don't change. INSPIREs current infrastructure is not resistant against such changes!
    • Metadata itself: Many authorities think, that metadata maintenance is something for editors, which edit xml documents. That's not true - we have to store metadata directly beside the datastore and extract as many as possible metadata from the dataset itself. Further on, the service configuration should be build automatically.


    Not yet

    - I forgot a little challenge ;-) -

    Let's harmonize the data

    Try it!

    RLP Motto

    Productive implementations