The first part of this series described the different classes of INSPIRE Download Services and why a Direct Access Download Service is most versatile. It also lined out that a Download Service may be interoperable or non-interoperable and that data providers must harmonize their base data at some point in order to meet the requirement of interoperability.
Harmonized INSPIRE datasets
This is probably one of the most important ongoing efforts in INSPIRE. The goal of harmonization is that the base data from the different member states and data providers will become available as datasets that comply with a single, interoperable data model. This harmonized INSPIRE data model is specified by 34 spatial data themes, which are grouped into three Annexes.
Let’s have a rough look at one of the Annex I data themes: Addresses
The Addresses data theme deals with: “Location of properties based on address identifiers, usually by road name, house number, postal code.” Its data model captures the concept of georeferenced addresses while integrating the semantical differences from all 27 involved member states. Here’s a part of this data model as an UML diagram (click for larger image):
Encoding of harmonized datasets
The UML model is one thing, but which format does an interoperable Download Service use to encode compliant datasets? In the OGC world, the Geographic Markup Language (GML) is the lingua france for encoding geospatial information and geospatial domain objects. As INSPIRE makes heavy use of OGC specifications, it uses GML as interoperable encoding. Each INSPIRE data theme comes with a corresponding GML application schema, which provides a machine-readable encoding of the data model and can also be used for validating the syntax of GML-encoded datasets.
More information on GML encoding rules and GML application schemas can be found in the GML specification:
Here’s how a single GML-encoded Address object may look like:
<ad:Address xmlns:ad="urn:x-inspire:specification:gmlas:Addresses:3.0" gml:id="FEATURE_bf1fea07-ab3a-4db7-af10-8a669f8ab8ab">
<ad:inspireId>
<base:Identifier xmlns:base="urn:x-inspire:specification:gmlas:BaseTypes:3.2">
<base:localId>0532200000000003</base:localId>
<base:namespace>NL.KAD.BAG</base:namespace>
</base:Identifier>
</ad:inspireId>
<ad:position>
<ad:GeographicPosition>
<ad:geometry>
<gml:Point gml:id="GEOMETRY_b29eb313-0a93-4faf-8793-fabef02255e7" srsName="urn:ogc:def:crs:EPSG::4258">
<gml:pos>52.689618 5.246345</gml:pos>
</gml:Point>
</ad:geometry>
<ad:specification>entrance</ad:specification>
<ad:method>byOtherParty</ad:method>
<ad:default>true</ad:default>
</ad:GeographicPosition>
</ad:position>
<ad:locator>
<ad:AddressLocator>
<ad:designator>
<ad:LocatorDesignator>
<ad:designator>1</ad:designator>
<ad:type>2</ad:type>
</ad:LocatorDesignator>
</ad:designator>
<ad:level>unitLevel</ad:level>
</ad:AddressLocator>
</ad:locator>
<ad:validFrom>2009-01-05T23:00:00.000</ad:validFrom>
<ad:validTo>2299-12-30T23:00:00.000</ad:validTo>
<ad:beginLifespanVersion xsi:nil="true" nilReason="UNKNOWN"/>
<ad:endLifespanVersion xsi:nil="true" nilReason="UNKNOWN"/>
<ad:component xmlns:xlink="http://www.w3.org/1999/xlink" xlink:href="#FEATURE_97d67632-2a1d-42ba-8fd0-163147c61e8e"/>
<ad:component xmlns:xlink="http://www.w3.org/1999/xlink" xlink:href="#FEATURE_4fb5f232-8045-4997-9922-eeb6e72e68c0"/>
<ad:component xmlns:xlink="http://www.w3.org/1999/xlink" xlink:href="#FEATURE_26d4b71a-2436-4a76-9a79-7c30c3e0ad58"/>
</ad:Address>
Note that the information of this address is not complete on its own, as the object references other objects via xlinks. For example, the information on the street name of this address is separated into a different object:
<ad:ThoroughfareName xmlns:ad="urn:x-inspire:specification:gmlas:Addresses:3.0" gml:id="FEATURE_26d4b71a-2436-4a76-9a79-7c30c3e0ad58">
<ad:beginLifespanVersion xsi:nil="true" nilReason="UNKNOWN"/>
<ad:endLifespanVersion xsi:nil="true" nilReason="UNKNOWN"/>
<ad:validFrom xsi:nil="true" nilReason="UNKNOWN"/>
<ad:validTo xsi:nil="true" nilReason="UNKNOWN"/>
<ad:name>
<gn:GeographicalName xmlns:gn="urn:x-inspire:specification:gmlas:GeographicalNames:3.0">
<gn:language>nld</gn:language>
<gn:nativeness>Endonym</gn:nativeness>
<gn:nameStatus>Official</gn:nameStatus>
<gn:sourceOfName>Het Kadaster, Nederland</gn:sourceOfName>
<gn:pronunciation>
<gn:PronunciationOfName/>
</gn:pronunciation>
<gn:spelling>
<gn:SpellingOfName>
<gn:text>Hugo de Grootsingel</gn:text>
<gn:script>Latn</gn:script>
</gn:SpellingOfName>
</gn:spelling>
</gn:GeographicalName>
</ad:name>
</ad:ThoroughfareName>
(if you wonder: it’s the dutch address “Hugo de Grootsingel 1″)
Why is this important again? An Interoperable Download Service has to offer these GML-encoded objects in the end. Unfortunately, most WFS implementation are currently not ready to cope with providing valid GML 3.2-encodings of rich geo objects like the example. They will work perfectly for delivering GML-encodings of simple features, but can they deal with:
- Multiple properties with the same name
- Reference to other features or GML objects
- Properties that contain GML core datatypes which are not geometries (e.g. code types or units of measure)
- Properties that contain generic XML
The good news is that deegree WFS does. And it has more to offer.
Why deegree WFS stands out from the crowd
The deegree webservices documentation has a long list of features of the WFS implementation. Let me translate the important aspects into human readable language with regard to creating Direct Access Download Services:
- Implements WFS standards 1.0.0, 1.1.0 and 2.0.0.: WFS 2.0.0 support is required for Direct Access Download Services.
- High performance and excellent scalability: Important in order to meet INSPIRE Quality-of-Service requirements
- Designed for rich data models from the bottom up: Required for smooth handling of harmonized INSPIRE datasets
- Support for GetGmlObject requests and XLinks: References between individual INSPIRE features are treated and can be resolved as needed
- Backends support flexible mapping of GML application schemas to relational models: It can be used for relational storage and harmonizing of INSPIRE datasets
- Fully transactional (even for rich data models): Import harmonized INSPIRE datasets without dealing with the storage details
Not mentioned in this list is, that it has an alternative storage mode based on database BLOBs. The rationale for this is that reconstructing a rich feature from several tables can become rather slow, if the number of involved tables becomes too high. With regard to INSPIRE, it can become hard or even impossible to meet the quality-of-service requirements. However, with BLOB mode, you can store every feature in a single table column, regardless of the feature’s complexity.
And of course: It’s free and open. No license fees. Not locked down in any way. You can even change the code, if you like.
To my knowledge, this combination of features is not met by any other WFS implementation out there at the moment.
What’s next
The next part of this blog post series will describe how to install deegree webservices and how to get an interoperable, Direct Access Download Service running in a couple of minutes. Additionally, I will demonstrate how you can send requests against it and how to import INSPIRE datasets.
Like this:
Like Loading...
