Probleme bei der Umsetzung der Interoperabilitätsanforderungen

Durch die Art der Modellierung des Themas Transport Networks kann nicht garantiert werden, dass die INSPIRE-Identifier bei Fortführungen identisch bleiben (wie von Artikel 9 VERORDNUNG (EG) Nr. 1089/2010 gefordert). Außerdem sind die so modellierten Daten in vielen Fällen für eine Nutzung ungeeignet.

D2.8.I.7_v3.2 - Data Specification on Transport Networks - Technical Guidelines, 5.3.2, 5.4.2, 5.6.2, 5.7.2

Corrigendum

Im Thema Transport Networks erfolgt eine aus unserer Sicht unangemessene Nutzung des Generic Network Models dergestalt, dass viele eigenständige Features (ohne Geometrie) entstehen, die in vielen Ausgangsdatenbeständen als Attribute zu Objekten geführt werden (z.B. Straßenbreiten, Straßennamen, Spurbreiten von Eisenbahnen etc. etc.). Für diese neu entstehenden Features müssen Inspire-Identifikatoren gebildet werden, und diese müssen bei Fortführungen identisch bleiben. Dies gelingt nur so lange, wie die Attribute im Ausgangsdatenbestand nicht multipel belegt sind.

Nach unserer Auffassung handelt es sich bei diesen Features auch nicht um Geo-Objekte im Sinne der Inspire-Richtlinie.

Außerdem führt diese Form der Modellierung dazu, dass die Daten in gängigen GIS-Systemen nicht ohne Weiteres genutzt werden können, weil zusammengehörende Informationen auf viele Objekte verteilt sind, die nur über Relationen miteinander verbunden sind (z.B. bis zu 10 Objekte für einen Straßenabschnitt). Für die Nutzung müssen die Daten i.d.R. über teilweise themenspezifische Lösungen so verflacht werden, dass aus den Features wieder Attribute werden.

GDI-NW
(Düren)

Die Nutzung des (Meta-)Datentyps "CI_Citation" beim Attribut "legalFoundationDocument" der Objektart "ProtectedSite" bewirkt

• eine Inkonsistenz zwischen Annex I und Annex III (da für dasselbe Konzept unterschiedliche Datentypen verwendet werden)
• eine unnötige Aufblähung des Protected Sites Schemas
• ein Implementierungsproblem, da INSPIRE-konforme Datensätze in der Praxis mit einigen am Markt befindlichen Datenmodelltransformations-Tools an dieser Stelle nicht korrekt generiert werden können

Verordnung (EG) Nr. 1089/2010, Anhang II, Nr. 9.1.1.; D2.8.I.9 Data Specification on Protected SitesProtected Sites – Technical Guidelines 5.3.1.2, 5.3.2

Corrigendum

D2.8.I.9 Data Specification on Protected SitesProtected Sites – Technical Guidelines 11.1.1

 D2.8.I.4 Data Specification on Administrative Units – Technical Guidelines

Corrigendum

2017.2 Alternative encodings for INSPIRE data

2017.3 Improved client support for INSPIRE data

D2.8.III.12 Data Specification on Natural Risk Zones – Technical Guidelines

Corrigendum

Prinzipiell sollten die Begrifflichkeiten von zentraler Stelle (mindestens national) in die Codelists eingepflegt werden. Beispiel:

Der Fluttyp gemäß HWRM-RL ist ein erstes Klassifikationsmerkmal, dass für eine sinnvolle Interoperabilität wichtig ist: Fluvial, Pluvial, Groundwater, SeaWater, Artifical Water-Bearing Infrastructure, Other

Als Lösung könnte SpecificHazardTypeValue mit den Begriffen aus der HWRM-RL als Katalog (möglichst zentral) bereitgestellt werden.

Solche Maßnahmen erfordern aber eine bessere Abstimmung des INSPIRE-Modells mit der Fachrichtlinie/den ReportingSheets zur Berichtspflicht und erfordern dort eine genauere Definition, welche Objekte wie umzusetzen sind (Beispielfrage: Sind APSFR nach Art. 4 oder 5 oder erst nach Art.6 HazardAreas oder RiskZones, wann sind Punkte, Linien oder Flächen gefragt). Unklare Begrifflichkeiten führen zu vielen Auslegungsmöglichkeiten, die die nationale Abstimmung wieder erschweren.

Es werden Wassertiefenkarten überschwemmter Bereiche gefordert (Tiefenklassen). Eine geeignete Umsetzung über die Attribute magnitudeOrIntensity, levelOrIntensity scheitert technisch an den dann viel zu komplexen Geometrien. Eine Umsetzung als WMTS (bunte transparente Layer) ist sinnvoll möglich- ist aber wohl kein INSPIRE-Standard.

NLWKN

(D. Weber)