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
- Architect of the SDI for the German Federal State Rhineland-Palatinate since 2005
- Chair of the German Working Group for Geoservices (~Spatial Data Services) since 2006
Key areas of activity
- Conception of the SDI and the central geoportal for Rhineland-Palatinate
- Consultation in technical matters
- Implementation of SDI Infrastructure components with OpenSource Software
- Implementation of geoportals at different levels of public authorities
- Contribution to different INSPIRE review processes
- 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
Overview
Rhineland-Palatinate
Historical development of the SDI
Architectural concept
Implementation of INSPIRE
Conclusions/Drawback
Rhineland-Palatinate
Where?
- Somewhere in Europe
Where else?
- Somewhere in Germany
- 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
2005
- 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
2006
- Preparing of a fine-concept
- Phase of implementation
2007
- 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
- Build an own relational information model for OWS
- Allow searching for WMS layer and WFS featuretype objects
- Let providers register/manage their OWS in the central database
- Extract all needed information from the service-capabilities
- Allow editing of some capabilities information
- Create persistant service urls to allow permanent integration into external GIS
- Monitoring of all distributed services and notify users/providers
Architectural concept (3)
Other concepts
- Central management of users and groups (authorities)
- CMS for WebGIS applications
Architectural concept (3)
2008
OGC Newsletter June 2008 - Website of the month
"... 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
OK - some time to think about - nearly 2 years :-)
But
- 10 month later -
The next present:
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 -
Principles
- 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
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
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
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
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.
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.
THE END
Not yet
- I forgot a little challenge ;-) -
Let's harmonize the data
Try it!
