Semantische Modelltransformation im Kontext von INSPIRE

Transkript

1 Unterschrift des Begutachters D I P L O M A R B E I T Semantische Modelltransformation im Kontext von INSPIRE Ausgeführt am Institut für Geoinformation und Kartographie der Technischen Universität Wien unter der Anleitung von O. Univ. Prof. Dipl.-Ing. Dr. techn. Andrew U. Frank Institut für Geoinformation und Kartographie und Priv.-Doz. Dipl.-Ing. Dr. techn. Gerhard Navratil Institut für Geoinformation und Kartographie Dipl.-Ing. Stefan Klotz Bundesamt für Eich- und Vermessungswesen als verantwortlich mitwirkende Betreuer durch Eva-Maria Unger Schottenfeldgassse 56/36, 1070 Wien Datum Unterschrift

2 I Vorwort Durch den Aufbau einer Europäischen Geodateninfrastruktur (EGDI), die in der EU-Richtlinie INSPIRE (Infrastructure for Spatial Information in the European Community) 2007/2/EG festgelegt und definiert wurde, müssen die länderspezifischen Geodaten in eine INSPIRE konforme Spezifikation gebracht werden. Die Richtlinie verlangt von allen Mitgliedstaaten der Europäischen Union, Geodaten mithilfe von Web Services entsprechend, einheitlich definierten Datenmodellen und Netzdiensten bereitzustellen. Länder bzw. deren Behörden (Vermessungsverwaltungen und andere Datenhersteller) halten aber ihre Geodaten in unterschiedlichen Systemen, Datenmodellen und -formaten vorhalten. Diese Datenmodelle können mitunter sehr stark voneinander abweichen. Um das INSPIRE- Datenmodell innerhalb Europa mit möglichst geringem Aufwand zu etablieren, sollen die unterschiedlichen Datenmodelle mithilfe von Modelltransformationsdiensten in ein einheitliches Zielmodell übergeführt werden. Durch diese Modelltransformationsdienste sollen jedoch nicht die originären Datenbestände geändert werden, sondern nur die Abgabedaten in das Zielmodell transformiert werden. In diesem Zusammenhang ist der Begriff der Interoperabilität sehr wichtig. Unter Interoperabilität wird die Fähigkeit zur Zusammenarbeit von Systemen, unabhängig von Hard- und Software, verstanden. Daher wird es durch Interoperabilität ermöglicht, über Webservices auf verschiedene Geodaten zuzugreifen und diese auch zu verwenden, ohne dass diese in den eigenen Datenbestand integriert sind. ([Hin10],[Eis10]) Der eigentliche Vorgang der Modelltransformation kann in zwei Phasen unterteilt werden: in die Konfigurationsphase und in die Ausführungsphase. In der Konfigurationsphase werden das Quell- und Zielmodell analysiert. Das Quellmodell und das Zielmodell werden in dieser Phase zueinander in Beziehung gesetzt. Es wird bestimmt, welche Elemente aus dem Quellschema in Elemente aus dem Zielschema überführt werden können. Die Transformationsregeln legen fest, wie die Abbildung durchzuführen ist. In der anschließenden Ausführungsphase werden die zuvor erstellten Transformationsregeln auf das Modell angewendet. Ziel dieser Diplomarbeit ist die Erarbeitung und Durchführung einer semantischen Modelltransformation. Dabei wird als Quellmodell ein Testdatensatz der Digitalen Katastralmappe und Sachdaten aus der Grundstücksdatenbank des Bundesamt für Eich- und Vermessungswesen und als Zielmodell das INSPIRE Datenmodell Cadastral Parcels verwendet.

3 II Abstract The directive 2007/2/EC of the European Parliament and the Council of 14 March 2007 established an Infrastructure for Spatial Information in the European Community (INSPIRE). The INSPIRE directive entered into force on the 15th May This directive wants to ensure that the spatial data infrastructures of all Member States are compatible and usable in a community and transboundary context. Its main aim is to support policy-making for the protection of the environment. The European Spatial Data Infrastructure shall be based on the existing National Spatial Data Infrastructures. Due to this directive all European Member States have to harmonise their geo data. INSPIRE wants to achieve this harmonisation of datasets through interoperable services. These services offer the users the opportunity to find, browse, share and download spatial data. The problem is that every state or the Federal Offices have their own geo data in different systems, models and data formats. These models may differ considerably, so that data from one state does not fit to data from another state. To harmonise this data there is the possibility to define a schema transformation from the source model to the target model. [INSPIRE 2010] A schema model transformation can be divided into two phases. First, the configuration phase and second, the implementation phase. Within the configuration phase you have to analyse both models (source and target). After analysing the meaning of the attributes, the connection between both models is easier. Within the implementation phase the transformation rules will be defined. The aim of this thesis is to analyse, implement and validate such a schema transformation. The digital cadastral map with some additions serves as a source model. This source model has to be transformed into the INSPIRE Cadastral Parcels model.

4 Inhaltsverzeichnis III 1. Einleitung Modelltheorie Modell Syntax und Semantik Merkmale von Modellen Model Driven Architecture Metamodelle Modellierungssprachen Unified Modelling Language UML Extensible Markup Language (XML) und Geography Markup Language (GML) Modellbasierter Ansatz Modelltransformation Modelltransformation von Geodaten Phasen der Modelltransformation Ausführung der Modelltransformation für Geodaten Transformationssprachen und -Werkzeuge Geeignete Transformationssprachen Transformationswerkzeuge Anforderungen für Transformationswerkzeuge Derzeit angebotene Transformationswerkzeuge Analyse des Quellmodells Bundesamt für Eich- und Vermessungswesen Das Quellmodell im Kontext von digitaler Katastralmappe und Grundbuch...38

5 Inhaltsverzeichnis IV 5.3 Digitale Katastralmappe (DKM) Koordinatenreferenzsystem der DKM Das Quellmodell Analyse des Zielmodells Koordinatenreferenzsystem für INSPIRE Das Zielmodell Humboldt Alignment Editor Aufbau von HALE Transformationsfunktionen von HALE Testdatensatz Vorarbeiten für die Transformation Österreichweiter Transformationsparametersatz MGI - ETRS Durchführung der Transformation Verzweigungstabelle Validierung der Transformation Fazit Zusammenfassung kritische Betrachtung Ausblick...78

6 1. Einleitung Mit der Richtlinie 2007/2/EG des Europäischen Parlaments und des Rates vom 14. März 2007 zur Schaffung einer Geodateninfrastruktur in der Europäischen Gemeinschaft (INSPIRE 1 ) wurde ein Instrument geschaffen, um den Zugang zu und die Nutzung von Geodaten für die Bürger, Verwaltung und Wirtschaft zu vereinfachen. Diese Richtlinie soll bis 2019 von allen Mitgliedstaaten vollständig umgesetzt werden. Durch sie sollen die Geodateninfrastrukturen der Mitgliedstaaten so gestaltet werden, dass diese in der Europäischen Union für eine gemeinsame Umweltpolitik und andere umweltrelevante Themen genutzt werden können. Durch diese gemeinsame europäische Geodateninfrastruktur sollen Entscheidungsträger bei grenzüberschreitenden Themen unterstützt werden. Die Richtlinie stellt einen Rahmen für die Geodateninfrastrukturen in der Europäischen Union dar. Aufgrund der föderalen Struktur in Österreich wird die Richtlinie rechtlich durch länderspezifische Durchführungsbestimmungen konkretisiert begannen die ersten Arbeiten zur Umsetzung dieser Richtlinie wurde der erste Vorschlag der Europäischen Kommission vorgelegt. Eine solch umfassende Richtlinie bedarf eines langen Ausarbeitungsprozesses und daher hat die Festlegung der endgültigen Richtlinie bis 2007 gedauert. Motivation für INSPIRE Die Motivation für INSPIRE war die Notwendigkeit einer einheitlichen, grenzübergreifenden Geodateninfrastruktur (GDI) mit harmonisierten Datensätzen für ganz Europa. Zwar gibt es innerhalb der Europäischen Union bereits vereinzelt Mitgliedsstaaten mit einer Geodateninfrastruktur, jedoch sind diese meist nur auf bestimmte Themengebiete bzw. auf Staats- Bundeslandgrenzen begrenzt und in seltenen Ausnahmefällen grenzübergreifend. Einzelne Projekte, die sich staatenübergreifend mit dieser Problematik auseinandersetzen sind z.b. das gemeinschaftliche Projekt der Länder Deutschland, Österreich und der Schweiz mit dem Titel Vergleichende Untersuchungen zur Modellierung und Modelltransformation in der Region Bodensee im Kontext von INSPIRE oder das Projekt Grenzüberschreitende Homogenisierung von Geobasisdaten zwischen dem Freistaat Sachsen und der Tschechischen Republik, welches von den Landesvermessungsämtern Sachsen 1 engl. Infrastructure for Spatial Information in the European Community Seite 1

7 und der Tschechischen Republik koordiniert wird. Die von den Ländern in Auftrag gegebenen, unterschiedlichen Projekte sind aber nur auf wenige Länder begrenzt und genügen bei Weitem nicht dem gesamteuropäischen Kontext. Die fehlende Standardisierung war einer der Hauptgründe für INSPIRE. Meist sind die Geodatensätze, die man von anderen Ländern bezieht, Seite 2

8 Einleitung inkompatibel, beziehen sich auf unterschiedliche Normen und weisen verschiedene geodätische Bezugssysteme auf, die eine grenzüberschreitende Nutzung der Daten erschwert. INSPIRE basiert auf folgende Grundsätze: Die Bereitstellung von Geodaten aus verschiedenen Quellen über ganz Europa. Diese sollen miteinander kombinierbar sein und so vielen Nutzern wie möglich zur Verfügung gestellt werden. Geodaten sollten nur einmal erfasst und dort gepflegt und aufbewahrt werden, wo es am effektivsten ist. Es wird nicht die Erfassung neuer Geodaten verlangt, vielmehr soll die Nutzung bereits vorhandener Daten optimiert werden. Geodaten, die von einer bestimmten Verwaltungsebene erfasst worden sind, müssen auch anderen Verwaltungsebenen zur Verfügung gestellt werden. Zugangs- und Nutzungskonditionen dürfen die umfassende Nutzung nicht einschränken. Daher sollte der Zugang leicht möglich sein und die Konditionen, an denen der Zugang und die Nutzung geknüpft sind, erkennbar sein. Durch die Durchführungsbestimmungen, welche eine Konkretisierung der einzelnen Harmonisierungsschritte der INSPIRE- Richtlinie darstellen, sollen die Voraussetzungen geschaffen werden, die von den Mitgliedstaaten geschaffenen Geodateninfrastrukturen kompatibel und europaweit zu nutzen. Ein weiteres Ziel der Durchführungsbestimmungen ist, einheitliche Formate und Datenstrukturen festzulegen. Damit soll die Interoperabilität der Geodatensätze sichergestellt werden. Zur Erarbeitung der Entwürfe für die Durchführungsbestimmungen von INSPIRE wurden fünf Arbeitsgruppen (Drafting Teams) eingerichtet. Die Erarbeitung der Entwürfe für die Ausführungsbestimmungen erfolgt durch die Drafting Teams aus den Expertengruppen (SDICs: Spatial Data Interest Communities und LMOs: Legally Mandated Organisations) der Mitgliedstaaten. Jede Expertengruppe besteht aus einem Leiter (Chair), einem Kernteam (Drafting Team) und einem Unterstützungsteam (Support Team). Die Hauptaufgabe der Expertengruppe ist die Analyse und Untersuchung der Unterlagen, um somit die Ausführungsbestimmungen erstellen zu können. 5 Expertengruppen mit folgenden Spezialisierungen wurden bestimmt: Metadaten (Metadata for spatial data) Datenspezifikationen (Spatial data specification and harmonisation) Netzwerkdienste und Interoperabilität (Network services and interoperability) Gemeinsame Nutzung von Daten und Diensten (Data and service sharing) Überwachung und Berichterstattung Seite 2

9 Einleitung (Monitoring and reporting) Der Inhalt dieser Diplomarbeit ist thematisch in der Gruppe Netzwerkdienste und Interoperabilität angesiedelt, genauer gesagt, den innerhalb dieser Gruppe zugewiesenen Transformationsdiensten. Die Gruppe befasst sich, von den Transformationsdiensten abgesehen, auch mit den Suchdiensten, Darstellungsdiensten, Download-Diensten und den Diensten zum Abrufen von Geodatendiensten. [Hin10] Motivation für diese Arbeit Diese oben beschriebene Entwicklung in Richtung einer Geodateninfrastruktur der Europäischen Gemeinschaft und der damit verbundenen Harmonisierung von Geodaten und deren Datenmodellen, war der Anstoß für diese Arbeit. Das Thema der Modelltransformationen ist sehr aktuell und unterliegt ständiger Neuerungen. Derzeit wird in diesem Themenbereich sehr viel geforscht und entwickelt. Das Thema der Transformationsdienste ist nicht nur auf die Europäische Gemeinschaft beschränkt. Es ist anzunehmen, dass die Harmonisierung der Daten und Datenmodelle auch außerhalb von Europa immer mehr an Bedeutung gewinnt. Es gilt die von vielen Geodatenbereitstellern gewonnenen Geodaten miteinander zu kombinieren und einen dadurch gewonnenen Mehrwert zu generieren. Ziel der Arbeit Ziel dieser Arbeit ist, das der Digitale Katastralmappe (DKM) zugrundeliegende Datenmodell in die INSPIRE konforme Spezifikation Cadastral Parcels zu überführen. Dabei soll untersucht werden, ob die Inhalte des Datenmodells ausreichend sind und welches Transformationswerkzeug sich für diesen Einsatz eignet. Die Hypothese dieser Arbeit lautet wie folgt: Das vorhandene Datenmodell der DKM kann mithilfe einer semantischen Modelltransformation in das INSPIRE konforme Zielmodell Cadastral Parcels überführt werden. Erwartetes Ergebnis Das Ergebnis dieser Arbeit setzt sich aus mehreren Teilergebnissen zusammen: Auffinden und Untersuchen von geeigneten Transformationswerkzeugen und deren zugrundeliegenden Transformationssprachen Analyse des Quellmodells durch eine tabellarische Übersicht und Beschreibung der zur Verfügung stehenden Attribute Analyse des Zielmodells auf die gleiche Art und Weise Durchführung und anschließende Validierung der Transformation Seite 3

10 Einleitung Aufbau der Arbeit Prinzipiell lässt sich die Arbeit in drei Teile unterteilen. Um einen Zugang zu dieser Materie zu bekommen, werden die zugrundeliegenden Begriffe untersucht. Sind die theoretischen Grundlagen geschaffen, kann die Analyse und die anschließende Implementierung durchgeführt werden. I. Theoretischer Teil Das zweite Kapitel der Arbeit ist eine Einführung und Begriffserklärung für Modelle. Dadurch wird ein Einstieg in die Welt der Datenmodelle gewährleistet. Er bildet den theoretischen Teil dieser Arbeit. Dafür werden zuerst die allgemein zugrundeliegenden Begriffe erläutert, wie z.b. Modell, Semantik und Syntax. Anhand deren Definition wird um eine Stufe tiefer in die Materie der Modelltheorie vorgedrungen. Es werden dabei die Merkmale und unterschiedlichen Schichten der Modelle erläutert. Anschließend erfolgt eine Untersuchung der in dieser Arbeit verwendeten Modellierungssprachen. In Kapitel 3 erfolgt eine Einführung und Begriffserklärung für Modelltransformationen. Dabei werden die grundlegenden Konzepte einer Modelltransformation beschrieben. Es werden der prinzipielle Vorgang sowie auch die unterschiedlichen Phasen beschrieben. In Kapitel 4 werden die Transformationssprachen und Transformationswerkzeuge untersucht, wobei das Hauptaugenmerk auf die tatsächlich verwendete Transformationssprache sowie das verwendete Transformationswerkzeug gelegt wird. Dieses Kapitel basiert auf einer Untersuchung des INSPIRE Transformation Network Service und wurde durch eigene Erfahrungen mit den Transformationssprachen und Werkzeugen ergänzt. Es soll einen Überblick darüber liefern, welche Programme derzeit auf dem Markt angeboten werden, um solche Modelltransformationen durchführen zu können. Es ist dabei zu beachten, dass dieses Thema sehr aktuell ist und daher immer wieder neue Entwicklungen und Erkenntnisse hervorruft. II. Analyse Der zweite Teil der Arbeit beschäftigt sich mit der Analyse des Quell- und Zielmodells. Mithilfe einer genauen Analyse kann der komplexe Vorgang der Transformation erleichtert werden. Daher ist eine sorgfältige Untersuchung unumgänglich. Dadurch erhält man einen Überblick über die vorhandenen Ausgangsdaten und die geforderten Zieldaten. Das Kapitel 5 beschäftigt sich mit der Analyse des Quellmodells. Bei dem verwendeten Quellmodell in dieser Arbeit handelt es sich um das Datenmodell der Digitalen Katastralmappe (DKM) mit einer Ergänzung durch die Grundstücksdatenbank. Dafür wurde vom Bundesamt für Eich- und Vermessungswesen ein Testdatensatz zur Verfügung gestellt. Bei der Analyse wird das Seite 4

11 Einleitung zugrundeliegende Datenmodell untersucht. Dabei ist vor allem der Aufbau des Modells wichtig. Es wird darauf geachtet, welche Datentypen verwendet wurden und in welchem Kontext diese definiert wurden. Die Informationen (Attribute) des Modells bedürfen einer genauen Betrachtung, um bei einer anschließenden Zusammenführung (Merge) den Überblick zu bewahren. Es wurde auch das zugrundeliegende Koordinatenreferenzsystem untersucht und dessen Eigenschaften aufgezeigt. Im Kapitel 6 wird das Zielmodell untersucht. Dabei handelt es sich um das Datenmodell Cadastral Parcels der Durchführungsbestimmung Interoperabilität von Geodaten- und Geodatensätzen, welches im Anhang I der INSPIRE Direktive beschrieben ist. Die Analyse erfolgte auf die gleiche Art und Weise wie auch beim Quellmodell. Die im Anhang befindlichen tabellarischen Aufschlüsselungen sind die Ergebnisse dieser. Im Kapitel 7 wird das in dieser Arbeit verwendete Transformationswerkzeug, der Humboldt Alignment Editor, vorgestellt. Dieses Tool wurde im Zuge des Humboldt Projektes erstellt. Es wird erläutert, wie es zu diesem Projekt kam, von wem es koordiniert wird und welche Softwarepakete in diesem Rahmen bereits erstellt wurden. Ebenso werden die für den Import und Export verwendeten Dateiformate aufgezeigt. Es wird ein Überblick über die von HALE zur Verfügung gestellten Transformationsfunktionen gegeben. Das Kapitel 8 beschreibt den von dem Bundesamt für Eich- und Vermessungswesen (BEV) zur Verfügung gestellten Testdatensatz. Ebenso wird die Datenaufbereitung beschrieben. Dies beinhaltet den Dateiformatübergang sowie einen kurzen Überblick der mittels der Software ArcGIS durchgeführten Koordinatentransformation. III. Implementierung Dieser Teil der Arbeit beschäftigt sich mit der Implementierung der Modelltransformation. Die Modelltransformation wird mithilfe des Humboldt Alignment Editors, kurz HALE, durchgeführt. Die tatsächlich durchgeführte Transformation erfolgt mithilfe der in Kapitel 9 dargestellten Verzweigungsvorlage. Diese dient als Grundlage bei der Definition der Transformationsregeln. Im Fazit werden nochmals Einzelheiten der durchgeführten Schematransformation behandelt. Abschließend befinden sich im Kapitel 10 die Zusammenfassung, eine kritische Betrachtung und der Ausblick. Im Anhang befindet sich eine detaillierte tabellarische Beschreibung des Quell- und Zielmodells, eine Mind Map des INSPIRE Datenthemas Cadastral Parcels, ein Überblick über die relevanten ISO Normen, ein Auszug aus der Grundstücksdatenbank des Testdatensatzes, sowie die verwendeten EPSG Codes. Seite 5

12 Kapitel 2 2. Modelltheorie 2.1 Modell Um einen theoretischen Einstieg in diese Thematik zu gewähren, wird zuerst einmal der Begriff des Modells definiert. Laut Frank ist ein Modell übersetzt: Ein System das einen Teil der Realität repräsentiert. 2 ([Fra06] Seite 29) Abbildung 1: Zusammenhang zwischen Realität und Modell [Fra06] Abbildung 1 verdeutlicht, dass anhand eines Modelles nur, der für den Modellierenden interessante Teil der Realität, abgebildet wird. Ein Modell repräsentiert daher nicht die ganze Realität. Eine weitere Definition verdeutlicht diesen Begriff. Ein Modell ist seinem Wesen nach eine in Maßstab, Detailliertheit und/oder Funktionalität 2 A model represents a system that is a part of reality, Frank 2006, Seite 29 Seite 6

13 verkürzte bzw. abstrahierte Darstellung des originalen Systems. [Sta73] Modelldefinition laut Stachowiak. Modelle präsentieren einen Teil der Realität. Dieser Teil wird in der Fachsprache auch als Seite 7

14 Kapitel 1: Modelltheorie Realweltausschnitt 3 bezeichnet. Es handelt sich dabei um einen Ausschnitt aus der realen oder gedachten Welt, welcher für das Verständnis des Modells wichtig ist. Der Teil der Realität wird abstrahiert. Dieser Realweltausschnitt ist jedoch nicht niedergeschrieben und daher nur gedacht. Sobald er definiert wird, spricht man laut ISO Geographic information Referenzmodell 4 von einem konzeptuellen Modell 5. Wird das Modell im nächsten Schritt formell niedergeschrieben, so spricht man von einem konzeptuellen Schema 6. [Eis10] In Abbildung 2 werden diese Modellierungsschritte grafisch dargestellt. Abbildung 2: Übergang vom Universe of Discourse zum konzeptuellen Schema ([Eis10] Seite 11, verändert) In der Dissertation von Peter Staub wird ein Datenmodell wie folgt mathematisch definiert: Ein Datenmodell M ist eine Abstraktion der Realität. Die Semantik S eines durch eine fachliche Sicht V charakterisierenden Realweltausschnitts R wird mittels definierter Formalismen L beschrieben und schließlich kodiert. ([Sta09] Seite 9) M Wie oben ersichtlich stellt die Datenmodellierung die Abbildung des Realweltausschnitts R auf ein Datenmodell M dar. Dabei wird die Ausprägung des Datenmodells von 3 Faktoren bestimmt: die dem Realweltausschnitt zugrundeliegenden Semantik S die angewendeten Formalismen bzw. die Modellierungssprache L und die fachliche Sicht V. 3 engl. Universe of Discourse 4 engl. Reference model 5 engl. conceptual model 6 engl. conceptual schema Seite 8

15 Kapitel 1: Modelltheorie Abbildung 3: Modellierung ([Sta09] Seite 9, verändert) 2.2. Syntax und Semantik Die Syntax beschreibt die Form des Modells, d.h. die Regeln, nach denen das Modell strukturiert werden muss. Zudem legt die Syntax jene Regeln fest, nach denen Programmtexte bzw. Modelle gebildet werden dürfen. Dabei sind Bedeutung oder Sinn der Modelle (noch) nicht relevant. Semantik legt die Bedeutung fest. Bei Programmiersprachen bzw. Modellierungssprachen bestimmt die Semantik, welche Bedeutung ein Programmtext hat. [Eis10] Anhand des Satzes Das Wetter ist schön lässt sich die Bedeutung von Syntax und Semantik erklären. Die Syntax des Satzes beschreibt den Aufbau des Satzes. Der Satz besteht aus bestimmten Satzgliedern. In diesem Fall sind diese: Subjekt, Prädikat und Adjektiv. Der Satzbau ist reglementiert und hat nach den gegebenen Regeln zu erfolgen. Die Semantik bestimmt die Bedeutung des Satzes. So ruft dieser Satz in unserem Gehirn das Bild von schönem Wetter hervor. Man weiß daher, welche Bedeutung dieser Satz hat. 2.3 Merkmale von Modellen Stachowiak nennt drei wichtige Hauptmerkmale eines Modells. ([Sta73] Seite 131f) Abbildungsmerkmal Modelle sind stets Modelle von etwas, nämlich Abbildungen, Repräsentationen natürlicher oder künstlicher Originale, die selbst wieder Modelle sein können. ([Sta73] Seite 131) Modelle bilden immer ein Original ab und leiten sich daher von diesem Original ab. Originale können in diesem Zusammenhang beliebige Objekte sein. Im Bereich der Geoinformation handelt es sich meist um reale Objekte. Verkürzungsmerkmal Modelle erfassen im Allgemeinen nicht alle Attribute des durch sie repräsentierten Originals, sondern nur solche, die den jeweiligen Modellerschaffern und/oder Modellbenutzern relevant scheinen. ([Sta73] Seite 132) Daher stellen Modelle in der Regel nicht den ganzen Teil der Realität dar. Die für den Modellierer wichtig erscheinenden Teile werden beschrieben. Das Seite 9

16 Kapitel 1: Modelltheorie Modell weist daher nicht alle Eigenschaften des Originals auf. Es findet eine Reduktion des Realweltausschnitts statt. Das wird darauf begründet, dass Modelle für einen bestimmten Zweck erstellt werden. Deswegen beinhaltet das Modell auch nur jene Informationen/ Eigenschaften, die diesem Zweck dienen. Pragmatisches Merkmal Modelle sind ihren Originalen nicht per se eindeutig zugeordnet. Sie erfüllen ihrer Ersetzungsfunktion a) für bestimmte erkennende und/oder handelnde, modellbenutzende Subjekte, b) innerhalb bestimmter Zeitintervalle und c) unter Einschränkung auf bestimmte gedankliche oder tatsächliche Operationen. ([Sta73] Seite 132) Durch dieses Merkmal werden die Fragen für wen, wozu und wann beantwortet. Modelle werden für jemanden, zu einem bestimmten Zeitpunkt und für einen bestimmten Zweck erstellt. Die Modellierung findet daher immer zweck-, kultur- und umfeldbedingt statt. Anhand eines Modells von einem Grundstück lassen sich diese 3 Modellmerkmale veranschaulichen. Abbildungsmerkmal: Das Modell eines Grundstückes repräsentiert eine Abbildung. Dabei wird das Original eines Grundstückes abgebildet. Verkürzungsmerkmal: Bei dem Modell eines Grundstückes werden nicht alle Attribute abgebildet. Es werden nur jene abgebildet, die für den Modellierer essentiell sind. Pragmatisches Merkmal: Das Modell eines Grundstückes wird je nach Zweck unterschiedlich abgebildet. Das Modell eines Grundstückes beinhaltet unterschiedliche Attribute für z.b. einen Notar (der den Auftrag hat das Grundstück zu verkaufen) oder einen Vermesser (der den Auftrag hat das Grundstück zu teilen). Dabei werden unterschiedliche Modelle, welche den gleichen Realweltausschnitt zugrundeliegen haben, für bestimmte Subjekte, innerhalb eines bestimmten Zeitintervalls und aus einem bestimmten Zweck modelliert. 2.4 Model Driven Architecture Unter den Begriff Model Driven Architecture, kurz MDA, versteht man einen modellbasierten Ansatz für die Softwareentwicklung. Dieser wurde von der Object Management Group (OMG) entwickelt. Als Einleitung werden dafür die vier MDA Modelle erklärt. Diese Modelle sind, wie man in Abbildung 4 sehen kann, das Computation Independent Model (CIM), das Platform Independent Model (PIM), das Platform Specific Model (PSM) und das Platform Model (PM). Seite 10

17 Kapitel 1: Modelltheorie Computation Independent Model (CIM) Damit werden nur die fachlichen Anforderungen technologieunabhängig beschrieben. Es werden keine technikbezogenen Aspekte modelliert. Dadurch beschreibt dieses Modell nicht das Verhalten oder die Innenarchitektur des Systems. In dieser Ebene wird das System allgemein beschrieben. Diese Ebene besitzt daher das höchste Abstraktionsniveau. Dabei werden lediglich die Geschäftsprozesse und deren Aspekte modelliert. z.b. Geschäftsmodell als Fluss- oder UML Aktivitätsdiagramme. Platform Independent Model (PIM) Dieses Modell erfasst und modelliert die Struktur und das Verhalten des Softwaresystems, plattformunabhängig. Dadurch ist dieses Modell gegenüber Maschinen- oder Technologieänderungen konsistent. Das Plattform Independent Model baut auf dem CIM auf. Das CIM beinhaltet, wie vorher beschrieben, keine Informationen über die innere Struktur des Systems. Dieses Modell ist daher etwas detaillierter als das CIM. Es werden hier Aspekte des Software-Systems betrachtet. Jedoch handelt es sich hierbei nach wie vor um ein systemunabhängiges System. Dieses Modell erleichtert durch den höheren Detailierungsgrad die Implementierung eines plattformspezifischen Systems. z.b UML Klassendiagramme Platform Specific Model (PSM) Das Platform Specific Model erweitert das PIM um plattformspezifische Aspekte. Es werden technische Aspekte, die sich auf eine bestimmte Plattform beziehen, miteingebunden. Bei einer Plattform handelt es sich um ein Setup aus bestimmten Architekturen, Technologien und Funktionalitäten. z.b. UML Klassendiagramm mit weiteren Spezialisierungen wie z.b. get(), set() Methoden Abbildung 4: MDA-Modell Platform Model (PM) Dieses Modell beinhaltet alle Komponenten und Elemente, die zur Modellierung eines Platform Model, kurz PM, notwendig sind (z.b. den Programmcode). Dieses Modell repräsentiert die Modellebene. Seite 11

18 Kapitel 1: Modelltheorie [Pet06] Das Ziel der Model-Driven Architecture ist, aus einem plattformunabhängigen PIM-Modell ein Modell für eine gewünschte Plattform zu generieren. Die Hauptziele der Model-Driven Architecture sind die Verbesserung der Portabilität durch Plattformunabhängigkeit, die Stärkung der Interoperabilität durch Standards und die Wiederverwendbarkeit der Software. Dadurch soll der Aufwand der Softwareentwicklung verringert und die Adaptierbarkeit gleichzeitig gesteigert werden. Diese Ziele können durch eine Trennung von fachlichen Geschäftsprozessen und technischen Informationen erreicht werden. Dadurch ist es möglich, gleiche Softwaresysteme auf verschiedenen Plattformen zu implementieren. Dafür sollten plattformspezifische Modelle möglichst automatisiert aus plattformunabhängigen Modellen abgeleitet werden können. Die Strategie der Modell-Driven Architecture wird in Abbildung 5 verdeutlicht. Die innerste Schicht, der Kern, beschreibt die Modellierung (CIM), die eigentliche Kernkompetenz der MDA. Folgender von der Object Management Group (OMG) spezifizierten Standards sind in dieser Ebene angesiedelt: Unified Modeling Language (UML), Common Warehouse Metamodel (CWM) und Meta Object Facility (MOF). Die darüber liegende Schicht (PIM) repräsentiert die für die Modellierung benötigten Technologien. Dazu zählen: Common Object Request Broker Architecture (COBRA), Extensible Markup Language (XML),.NET, JAVA, Web Services. In der äußersten Schicht werden unterstützendende Dienste wie Leitende Dienste, Sicherheit, Ereignisse, Transaktionen und Datenverzeichnisse aufgeführt. Die nach außen zeigenden Pfeile verweisen auf die verschiedenen Anwendungsgebiete, für welche die unterschiedlichsten Software Systeme entwickelt werden. [Pet06] Seite 12

19 Kapitel 1: Modelltheorie Abbildung 5: MDA Architektur [OMG10] 2.5 Metamodelle Die Vorsilbe Meta stammt aus dem Griechischen und bedeutet über, hinter. [DUD11] Ein Metamodell ist also ein Modell über einem oder mehreren Modellen. Damit ein Modell erstellt werden kann, wird eine eigene Sprache benötigt, die auf einer Syntax und Semantik basiert. Diese werden in Metamodellen definiert. Das Metamodell ist daher die Grundlage für jedes beliebige Modell. Ein Metamodell wird wie folgt definiert: Ein Metamodell ist ein Modell, welches die Sprache definiert um ein Modell zu formulieren. 7 [OMG10] Ein Metamodell definiert somit die Regeln und den Aufbau, welche zur Erstellung eines Modells benötigt werden. Metamodelle sind in einer Metasprache verfasst. Diese Metasprache muss wiederum in einem Metametamodell definiert sein. Dieser Kreislauf könnte aufgrund der obigen Definition unendlich weitergehen, weil jede Sprache wiederum in einem Modell definiert sein muss. Damit dem nicht so ist, sind Metametamodelle selbst definierend beschrieben. Dies bedeutet, dass das Metamodell des Metametamodells wiederum das Metametamodell ist. Aus diesem Grund wurde zum Beispiel bei der OMG die Meta Object Facility (MOF) als Metasprache definiert. [Kar06] Das Prinzip kann sehr gut anhand der MDA 4-Schichten Architektur verdeutlicht werden, welche von der OMG definiert wurde. [Pet06] Sie ermöglicht, alle Arten von Daten, deren 7 Orig. A meta-model is a model that defines the language for expressing a model [OMG 2010] Seite 13

20 Kapitel 1: Modelltheorie Strukturen und deren Einflüsse, als Modell zu beschreiben. In Abbildung 6 sind die einzelnen Schichten mit Beispielen dieser Architektur dargestellt, die wie folgt beschrieben werden können: M0 System/Instanz Ebene Auf dieser Ebene werden die Objekte definiert, die im Modell verwendet werden. Es handelt sich hierbei z.b. um die Geodaten. M1 Modellebene Auf der Ebene M1 befindet sich, das Modell zum Abbilden der Realwelt (Universe of Discourse). Dieses Modell wird mithilfe einer Modellierungssprache z.b UML beschrieben. Jeder Modellierungssprache liegt natürlich wieder ihrer eigener Syntax und Semantik zu Grunde. Das M1 Modell definiert die Eigenschaften der Objekte auf der M0 Ebene. Es handelt sich hierbei z.b. um UML Modelle. M2 Metamodellebene Auf dieser Metamodell-Ebene werden die Sprachkonstrukte, also Syntax und Semantik der jeweiligen Modellierungssprachen, definiert. Im Falle einer MDA-Model Driven Architecture wird das Metamodell UML verwendet. Diese Metamodelle werden auch durch eine eigene Modellierungssprache mit eigener Syntax und Semantik beschrieben. Es handelt sich hierbei z.b. um UML Metamodelle. M3 Metametamodellebene Diese Ebene, die sogenannte Metametamodell-Ebene, ist die oberste Ebene der 4-Schichten Architektur. Sie beinhaltet die Beschreibung der Syntax und Semantik des Metamodells aus der Ebene M2. Die OMG definiert auf der Metametamodellebene die Meta Object Facility (MOF). MOF beschreibt den Aufbau der Metamodelle UML (Unified Modeling Language) und CWM (Common Warehouse Metamodel). Damit das Metametamodell nicht nur das Modell von M2 beschreibt, sondern auch sich selbst, ist diese Ebene rekursiv. Würde es diese Rekursivität nicht geben, würde dieser Kreislauf, wie auf der vorigen Seite bereits erwähnt, unendlich weitergehen. Es handelt sich hierbei z.b. um MOF. Seite 14

21 Kapitel 1: Modelltheorie Abbildung 6: MDA 4-Schichten-Architektur ([Eis10] Seite 23, verändert) 2.6 Modellierungssprachen Modellierungssprachen sind Sprachen, mit deren Hilfe Modelle erstellt bzw. beschrieben werden. Es wird dabei zwischen textuellen und visuellen Modellierungssprachen unterschieden. Visuelle Modellierungssprachen benutzen des Öfteren Diagramme zur Darstellung. Auch Modellierungssprachen haben eine ihnen zugrundeliegende Syntax und Semantik. Bei formalen Modellierungssprachen ist die Semantik präzise definiert. Bei informellen Modellierungssprachen ist die Semantik in der Sprachdefinition nur umgangssprachlich festgelegt. [Eis10] Beispiele für Modellierungssprachen sind: informell, textuell: informell, visuell: formal, textuell: formal, visuell: natürliche Sprachen Diplomarbeit Programmcode (XML-Datei) UML - Modelle Die Modellierungssprachen wurden in dem Dokument Development of Technical Guidance for the INSPIRE Transformation Network Service von der INSPIRE Network Service Group untersucht. Sie wurden dann anhand folgender Kriterien beurteilt. [Bea10] Beurteilungskriterien für Modellierungssprachen Ausdruckskraft Seite 15

22 Kapitel 1: Modelltheorie Die Modellierungssprache sollte in der Lage sein, alle Informationen, die zur Definition des Quell- und Zielmodells notwendig sind, repräsentieren zu können. Web Kompatibilität Die Modellierungssprache sollte in Web Services verwendet werden können. Programmunterstützung Die Modellierungssprache muss von Programmen zum Editieren und Ableiten von bereits vorhandenen Modellen unterstützt werden. Technologische Unabhängigkeit Die Modellierungssprache sollte nicht an einem bestimmten Hersteller gebunden sein. Mithilfe der Modellierungssprache wird eine konzeptuelle Beschreibung des Modells erstellt. Anwendbarkeit Die Modellierungssprache sollte eine einfache und prägnante Darstellungsform aufweisen. Dadurch ist es für die Modellierer einfacher mit dieser Modellierungssprache zu arbeiten Unified Modelling Language UML Die Unified Modeling Language UML ist eine objektorientierte, grafische Modellierungssprache. Sie wurde von der Object Management Group (OMG) entwickelt. UML ist die am weitesten verbreitete und standardisierte Sprache. Sie dient zur Visualisierung, Spezifikation, Konstruktion und Dokumentation von Systemen. UML ist kein Programm, sondern lediglich eine Modellierungssprache, welche ein Wörterbuch an Symbolen zur Verfügung stellt, von denen jedes eine definierte Bedeutung hat. UML bietet eine Reihe verschiedener Diagrammformen. Seite 16

23 Kapitel 1: Modelltheorie Wie in Abbildung 7 ersichtlich ist, können diese in 2 Gruppen unterteilt werden, den Strukturdiagrammen und den Verhaltensdiagrammen. Mit diesen standardisierten Diagrammtypen können komplexe Sachverhalte, Abläufe und Systeme einfach, übersichtlich und verständlich dargestellt werden. Ein wesentlicher Vorteil der UML ist die Verbesserung der Zusammenarbeit zwischen Technikern und Nicht-Technikern. Abbildung 7: UML Diagramm Struktur ([Ste09] Seite 13) Durch die leichte Lesbarkeit der Diagramme ist es möglich, Systeme besser zu verstehen. Ebenfalls besteht die Möglichkeiten der Vereinfachung und/oder Wiederverwendbarkeit. Das Entscheidende dabei ist, dass durch die Visualisierung der Prozesse diese leichter analysierbar und verbesserbar sind. [Ste09] Für die Umsetzung von INSPIRE wurde die UML Version 2.1 verwendet. Als Austauschformat wird das Format XMI Metadata Interchange verwendet. Dieses Format ist vielseitig einsetzbar und ist ein Standard für den Austausch von Metadaten, welche mithilfe von XML erstellt worden sind. Es tauscht die Objekte auf Basis von Meta-Metamodellen nach der Meta Objekt Faciltiy aus, d.h. solange sich die Daten mithilfe von MOF ausdrücken lassen, können sie beliebig ausgetauscht werden. Die meisten UML Tools bieten einen XMI Import und Export an. Generell lässt sich sagen, dass UML Klassendiagramme für die strukturierte Datenmodellierung ideal geeignet sind. Zum Editieren von UML Modellen gibt es sehr viele Programme, darunter auch einige open-source-programme. Es unterstützen jedoch nicht alle Programme wie z.b. Shape Change und FullMoon, welche zur Transformation von UML Modelle in GML verwendet werden, die UML Version 2. [Bea10] Extensible Markup Language (XML) und Geography Markup Language (GML) GML wurde vom Open Geospatial Consortium (OGC) entwickelt, wobei XML vom World Wide Web Consortium (W3C) entwickelt wurde. GML basiert auf XML. Bei XML handelt es sich um eine Auszeichnungssprache zur Beschreibung von strukturierten Daten. GML wurde eigens für die Integration von geographischen Informationen, z.b. verschiedene Arten von Geometrien, Seite 17

24 Kapitel 1: Modelltheorie entwickelt. GML ist eine standardisierte Sprache, die in OGC-Webservices als Schnittstelle verwendet wird. Extensible weist darauf hin, dass die Sprache erweiterbar ist. Daher kann sie immer an verschiedene Aufgabenstellungen angepasst werden. Ein besonderer Vorteil ist, dass GML unabhängig vom Betriebssystem- in verschiedensten Aufgabengebieten einsetzbar ist. Da XML-Dokumente als Textdateien gespeichert werden, können sie von jedem beliebigen Text Editor geöffnet und bearbeitet werden. GML ist eine Implementierungsspezifikation mit der geographische Informationen formulierbar sind. ([Bor05], [Hub06], [Bea10]) In dieser Arbeit wird nur auf diese beiden Modellierungssprachen (XML und GML) eingegangen, da hauptsächlich diese in dieser Arbeit verwendet wurden. In der INSPIRE Studie wurde zusätzlich die Modellierungssprache Ressource Description Framework (RDF) untersucht und beurteilt. In Kapitel 8.1 wird die direkte Anwendung dieser Modellierungssprachen gezeigt. 2.7 Modellbasierter Ansatz Die Datenmodellierung kann mithilfe des modellbasierten Ansatzes veranschaulicht und erklärt werden. Der wesentlichste Punkt dabei ist die Verwendung einer konzeptuellen Schemasprache. Diese erlaubt, die Modelle unabhängig von Systemen und Transferformaten wie z.b. XML oder GML zu beschreiben. Der Ansatz ist hierarchisch in vier Arbeitsschritte unterteilt. Abbildung 8 veranschaulicht den modellbasierten Ansatz und schafft somit eine Brücke zwischen Semantik S, Realweltausschnitt R, MDA-Architektur, 4-Schichten-Architektur und den Modellierungssprachen. [Sta09] 1. Der erste Arbeitsschritt des modellbasierten Ansatzes ist die Spezifizierung des Realweltausschnitts R. Dabei wird die Semantik S durch eine textuelle Beschreibung bestimmt. Bei diesem Schritt spricht man von der räumlichen Modellierung. 2. Spezifizierung einer konzeptuellen Schemasprache L mithilfe eines UML Metamodells, dem Meta Object Facility (MOF). 3. Im dritten Schritt wird die formale Abbildung mit der zuvor bestimmten konzeptuellen Schemasprache beschrieben. Diese formale Abbildung wird auch als konzeptuelles Schema oder plattformunabhängiges Modell (PIM) bezeichnet. 4. Im vierten und letzten Schritt erfolgt die Ableitung eines beliebigen Datenbank- oder Transferformat-Schemas. Dieser Schritt beinhaltet den Übergang vom plattformunabhängigen zum plattformabhängigen/spezifischen Modell (PSM). Anschließend erfolgt die eigentliche Datenkodierung (Encoding). Seite 18

25 Kapitel 1: Modelltheorie Abbildung 8: Modellbasierter Ansatz ([Sta09] Seite 10 verändert) Seite 19

26 Kapitel 3 3. Modelltransformation Modelltransformation bedeutet, dass ein Modell (Quellmodell) in ein anderes Modell (Zielmodell) überführt wird. In der Model Driven Architecture unterscheidet man zwei Arten von Modelltransformationen: [Don08] 1. Horizontale Transformation Dabei erfolgt die Transformation innerhalb derselben Ebene. Sie wird daher auch als Modell- nach Modell-Transformation bezeichnet. (z.b. PIM PIM) 2. Vertikale Transformation Hierbei findet die Transformation zwischen verschiedenen Ebenen statt. Bei dieser Art der Transformation ist jedoch zu beachten, dass die Semantik, welche in der übergeordneten Ebene definiert wurde, in der darunterliegenden Ebene nicht verändert werden darf. Diese Art der Transformation wird auch als Modell- nach Text Transformation bezeichnet. (z.b. PIM PSM, PSM PM) Bei einer Modelltransformation werden Informationen, die das Zielmodell benötigt, dem Quellmodell hinzugefügt und Informationen, die nicht benötigt werden, herausgefiltert. Die Modelltransformation ermöglicht es, aus einem vorhandenen Modell ein neues Modell zu erzeugen, welches dann einer bestimmten Vorstellung entspricht bzw. für eine bestimmte Anwendung geeignet ist. Für die Transformation werden mittels einer geeigneten Transformationssprache die Transformationsregeln definiert. Diese bestimmen, wie die Abbildung zu erfolgen hat. Die Transformation selbst wird auf den Modellen durchgeführt. Dazu liest ein Transformationswerkzeug das Quell- und Zielmodell ein und führt die Transformationsregeln auf dem Quellmodell aus. Dadurch wird ein neues Modell erzeugt, welches dem Zielmodell entspricht. Das grundlegende Konzept dieser Transformation ist in Abbildung 9 dargestellt. Ein Hauptaugenmerk liegt auf der automatischen Durchführbarkeit der Transformation. Dies bedeutet, dass die Modelle maschineninterpretierbar sein sollten. Maschineninterpretierbarkeit Seite 20

27 beinhaltet, dass ein Text von einem Computerprogramm automatisch gelesen und ausgeführt werden kann. Dementsprechend muss der Text genau strukturiert sein und darf keinen Spielraum für Interpretationsmöglichkeiten offen lassen. Liegen Modelle in visueller Form vor, wie z.b. UML-Modelle, müssen diese zuerst über entsprechende Transferformate in textuelle Modelle (z.b. XML) transformiert werden. Ein solches Transferformat stellt z.b. das XML Metadata Interchange XMI dar. Anschließend kann dieses ursprüngliche, visuelle Modell mithilfe von Transformationswerkzeugen Seite 21

28 Kapitel 2: Modelltransformation weiterverarbeitet werden. [Eis10] Abbildung 9: Grundlegendes Konzept der Modelltransformation [Eis10] 3.1 Modelltransformation von Geodaten Geodaten sind ein wesentliches Element der gemeinsamen europäischen Umweltpolitik. Die von den Ländern und Datenbereitstellern produzierten geographischen Datensätze werden benutzt, um öffentliche Dienstleistungen zu gewährleisten, sowie Regierungspolitik, Umweltüberwachung und Berichterstattung zu unterstützen. Der von der INSPIRE-Richtlinie festgelegte Rahmen ermöglicht, auf Daten schnell und flexibel via Webservices zuzugreifen. Durch die von der Europäischen Kommission spezifisch festgelegten Durchführungsbestimmungen können Datensätze verschiedenster Datenthemen aus vielen verschiedenen Organisationen bzw. Ländern miteinander kombiniert werden. Dadurch wird eine allgemeine Nutzung der Geodaten ermöglicht. Aufgrund der unterschiedlichen Erhebungsmethoden der Geodaten und unterschiedlichen Verwaltungssystemen ist man innerhalb der EU mit vielen verschiedenen Datenformaten und Datenmodellen konfrontiert. Für eine interoperable Nutzung müssen diese Datenmodelle in INSPIRE-Klassen und -Attribute transformiert und in ein Standard-Austauschformat übertragen werden. In diesem Kapitel wird die Modelltransformation von Geodaten näher beschrieben. Dabei Seite 22

29 Kapitel 2: Modelltransformation sollte beachtet werden, dass es einen entscheidenden Unterschied zwischen der oben beschriebenen Modelltransformation und der Modelltransformation von Geodaten gibt. Bei der Modelltransformation werden die für das Metamodell geeigneten Transformationsregeln direkt auf den Modellen ausgeführt. Bei der Modelltransformation von Geodaten werden die Transformationsregeln jedoch auf der Ebene der Geodaten und nicht auf der Modellebene angewendet. [Eis10] Prinzipiell kann die Transformation zwischen zwei Modellen auf verschiedenen Ebenen ausgeführt werden. Bei den Ebenen handelt es sich um die konzeptuelle, die logische/physische und die Datenebene. [Don08] Abbildung 10: Ebenen der Modelltransformation Es bieten sich zwei Möglichkeiten für eine modellbasierte Transformation von Geodaten an: [Eis10] Syntaktische Transformation Bei einer syntaktischen Transformation wird die Syntax der Geodaten umgebaut. Dies heißt konkret, dass eine Formatumwandlung stattfindet, z.b. Shape-Dateien in GML-Dateien umgewandelt werden. Diese Art der Transformation ist für die von INSPIRE geforderte Transformation unzureichend. Von INSPIRE wird nicht einfach nur eine Formatumwandlung gewünscht, vielmehr ist die Überführung des zugrundeliegenden Datenmodells (Quellmodell) in das von INSPIRE spezifizierte Modell (Zielmodell) gefordert. Seite 23

30 Kapitel 2: Modelltransformation Für diese Aufgabe ist die semantische Transformation vielversprechender. Auch wenn diese, wie im nächsten Absatz ersichtlich, einige Probleme aufweist. Semantische Transformation Bei einer semantischen Transformation werden die Daten umstrukturiert, ergänzt und reduziert, so dass sie der Semantik eines anderen Datenmodells (Zielmodell) entsprechen. Durch die semantische Transformation ist es möglich, heterogene Datenbestände auszutauschen. Jedoch können möglicherweise nicht die ganzen Informationen eines Datenbestands transformiert werden. Die semantische Transformation birgt zwei große Probleme: ([Sta09] Seite 3) 1. es ist nicht möglich, die komplette Semantik eines Datenmodells verlustfrei auf ein anderes Datenmodell abzubilden Wenn ein Quell-Datenmodell M Q auf ein Ziel- Datenmodell M Z abgebildet werden soll, so kann im Allgemeinen nur eine Teilmenge aller Datenobjekte und Eigenschaften in einer Transformation eindeutig dem Ziel-Datenmodell M Z zugeordnet werden. ( [Sta09] Seite 3) 2. die Bijektivität der Abbildungsregeln von Quell- auf Zielmodell ist nicht gewährleistet Eine Transformation ist ohne Informationsverlust nicht direkt umkehrbar: Für die Rücktransformation vom Ziel- ins Quellmodell muss daher eine neue Transformation definiert werden. ( [Sta09] Seite 3) Diese Probleme werden anhand eines einfachen Beispiels verdeutlicht: Das Quellmodell besitzt die Klasse Auftraggeber mit den Attributen: Vorname, Nachname, Geb. Datum, und die Klasse Anschrift bestehend aus Straße, Hausnummer, PLZ, Seite 24

31 Kapitel 2: Modelltransformation Bundesland und Land. Das Zielmodell besitzt nur die Klasse Rechnung mit den Attributen: Name, Adresse und Bankverbindung. Die Klassen und Attribute des Quell- und Zielmodells sind in Abbildung 11 übersichtlich dargestellt. Das Attribut Name setzt sich aus dem Vor- und dem Nachnamen zusammen. Das Attribut Adresse wiederum setzt sich aus den Attributen: Straße, Hausnummer, PLZ und Land zusammen. Abbildung 11: Probleme bei der semantischen Transformation ([Sta09] Seite 4, verändert) Anhand dieses UML Diagramms kann man erkennen, dass zum einen nicht alle Attribute der Klasse Auftraggeber des Quellmodells abgebildet werden können (Geb. Datum) und dass zum anderen nicht alle Attribute der Klasse Rechnung des Zielmodells gefüllt werden können (Bankverbindung). Des Weiteren wird durch die Transformation die Semantik/Struktur der Daten verändert. Gibt es im Quellmodell noch zwei Klassen, so gibt es im Zielmodell nur noch eine Klasse. Es gehen daher Informationen, wie z.b. das Geb. Datum verloren. Andere Informationen, welche vom Zielmodell gefordert werden, können nicht gefüllt werden. Durch die stattfindende Strukturveränderung ist es daher auch nicht möglich, das Quellmodell aus dem Zielmodell durch eine Rücktransformation zu rekonstruieren. Wie in Abbildung 12 dargestellt lassen sich verlorengegangene bzw. darstellbare Informationen anschaulich durch ein Schnittmengen Abbild darstellen. Abbildung 12: Schnittmenge zweier Datenmodelle ([Sta09] Seite 5) Dabei kann bei zwei verschiedenen Datenmodellen nur eine Schnittmenge M Q M Z der Daten dargestellt werden. Die Bereiche/Daten außerhalb der Schnittmenge, M Z \ M Q und M Q \ M Z fehlen bzw. gehen bei der semantischen Transformation verloren. [Sta09] Die Vorteile der semantischen Transformation sind: [RTG10] Seite 25

32 Kapitel 2: Modelltransformation - Systemunabhängigkeit - Nachhaltigkeit (Nachnutzung der Geodaten) - Vielseitigkeit (Transformationsregeln können wieder verwendet werden) 3.2 Phasen der Modelltransformation In der Studie Vergleichende Untersuchungen zur Modellierung und Modelltransformation in der Region Bodensee im Kontext von INSPIRE ( [Eis10] Seite 29) wird beschrieben, dass eine Modelltransformation in zwei Phasen, Konfigurations- und Ausführungsphase, unterteilt werden kann. Konfigurationsphase Die Konfigurationsphase beschäftigt sich mit der Definition der Transformation. Dabei werden Quell- und Zielmodell anhand der in beiden Modellen gleich vorkommenden Attribute in Verbindung gesetzt. Es erfolgt die Definition der Abbildung, welche Attribute in welche Attribute des Zielmodells überzuführen sind. Dadurch lassen sich die Transformationsregeln definieren. Ausführungsphase Mithilfe der Ergebnisse aus der Konfigurationsphase werden in der Ausführungsphase die Transformationsregeln definiert. Diese Transformationsregeln beschreiben die Abbildung zwischen Quell- und Zielmodell. Damit diese von einem Transformationswerkzeug gelesen werden können, müssen sie maschinenlesbar und maschineninterpretierbar sein. 3.3 Ausführung der Modelltransformation für Geodaten In der im vorherigen Kapitel genannten Studie werden zwei verschiedene Möglichkeiten der Schematransformationsausführung angeführt. [Eis10] On-the-fly Transformation On-the-fly bedeutet -wortwörtlich übersetzt- im Flug. In der Informatik ist damit jedoch gemeint, bestimmte Aktionen/Daten dynamisch (just-in-time) zu erzeugen bzw. abzufragen. Die on-the-fly Transformation wird erst zu dem Zeitpunkt an dem der Anwender transformierte Daten abrufen möchte durchgeführt. Dadurch ergibt sich der große Vorteil, dass Daten nur im Seite 26

33 Kapitel 2: Modelltransformation ursprünglichen System bereitgehalten werden müssen und die Transformation direkt zum Anfragezeitpunkt nur für den angefragten Ausschnitt durchgeführt werden muss. On-the-fly Transformation wird vor allem dort eingesetzt, wo die Aktualität eine wichtige Rolle spielt. Die Performance der Transformation kann durch große Datenmengen beeinträchtigt werden. Diesem Problem kann man aber durch geeignete Modellierung entgegenwirken. Offline-Transformation Diese Art der Transformation wird im Voraus durchgeführt und die Ergebnisse werden in einer Abgabedatenbank festgehalten. Der Anwender stellt seine Anfrage direkt an diese Datenbank und bekommt als Ergebnis die bereits vorliegenden, transformierten Daten, ohne dass eine nochmalige Transformation durchgeführt werden muss. Die Modelltransformation ist in diesem Fall als Prozess beim Datenbereitsteller etabliert und im Produktionszyklus eingebettet. Ein großer Nachteil dieser Transformationsart ist, dass bei sich kontinuierlich ändernden Geodaten die Nachführung in die Abgabedatenbank nicht in Echtzeit passiert was zu Einbußen bei der Aktualität der Daten führt. Erst durch eine erneute Transformation der Daten des Quellmodells sind die Daten im Zielmodell wieder aktuell. Welche der beiden Transformationen eingesetzt wird, ist von der Anwendung, der Komplexität des Datenmodells sowie den Nutzeranforderungen abhängig. Der aktuelle Stand der Technik lässt derzeit nur eine Offline-Transformation zu. Aufgrund der Performance gängiger PC- Systemen ist eine on-the-fly Schematransformation noch nicht möglich. Die Softwarehersteller arbeiten jedoch bereits an einer Lösung. Vor allem für die Geodatenbereitsteller, welche die INSPIRE- Richtlinie verpflichtend umsetzen müssen, ist eine on-the-fly Schematransformation zielführend. Seite 27

34 Kapitel 4 4. Transformationssprachen und -Werkzeuge Um Daten von einem Datenmodell in ein anderes Datenmodell zu transformieren muss ein Transformationsservice gewisse Anforderungen und Bedingungen erfüllen. Für das INSPIRE- Schematransformationsservice wurden u. a. die Kriterien für Ausdrucksfähigkeit der Transformationssprache und Anforderungen an Transformationswerkzeuge als wesentliche Erfolgsfaktoren identifiziert. 4.1 Geeignete Transformationssprachen In diesem Kapitel wird auf die unter Tabelle 1 angegebenen Transformationssprachen eingegangen. Diese wurden in der von der INSPIRE Network Service Group veröffentlichten Studie näher untersucht. [Bea10] Transformationssprache Version oder Urheber Datum Rule Interchange Format (RIF) 1.0 W3C Query/View/Transform (QVT) 1.0 OMG Extensible Stylesheet Language for Transformations (XSLT) 2.0 W3C Ontology Mapping Language (OML) 06/10/05 DERI OMWG Tabelle 1: Überblick Transformationssprachen ([Bea10], verändert) QVT wird hier nur anfangs erwähnt, da in dieser Arbeit vorwiegend die Sprachen OML, XSLT Seite 28

35 und RIF verwendet werden. Diese Transformationssprachen werden daher auch ausführlicher behandelt. Um aber das breite Spektrum der zur Verfügung stehenden Transformationssprachen nicht noch mehr einzugrenzen, werden zumindest die von der Studie empfohlenen 4 Sprachen vorgestellt. Seite 29

36 Kapitel 3: Transformationssprachen und Werkzeuge Query/View/Transform (QVT) QVT ist eine Entwicklung der OMG (Object Management Group) und spezifiziert eine Sprache für die Beschreibung von Modell zu Modell Transformation. Die Abkürzung QVT steht für "Queries" (Anfragen), "Views" (Sichten) und "Transformations" (Transformationen). Unter Anfragen versteht man formale Ausdrücke, mit denen einzelne Elemente eines Modells ausgewählt werden können. Sichten sind komplexe Anfragen, mit denen ganze Abschnitte aus einem Modell ausgewählt werden. Mit Transformationen werden Beziehungen zwischen Modellen dargestellt. Es gibt viele Dialekte von QVT z.b. QVT Relations ist der zentrale deklarierende Teil der Sprache, QVT Operational Mapping Language (QVTo) ist ein imperativer Dialekt, welcher konzeptuelle Transformationen erlaubt. QVT Operational Mapping Language ist der laut der INSPIRE Studie am besten geeignete Dialekt von QVT für eine solche Modelltransformation. [Bea10] Extensible Stylesheet Language for Transformations (XSLT) XSLT ist ein Standard des W3C und definiert eine Sprache zur Transformation von hauptsächlich XML-Dateien. XSLT ist auf das XML-Paradigma ausgerichtet, weshalb seine Einsatzmöglichkeit mit anderen Formaten nur beschränkt möglich ist. XML/XSLT ist eine weit verbreitete Transformationssprache, um Informationen entsprechend darzustellen. Stylesheets, die mit XSLT kodiert wurden, sind besonders geeignet, um präzise und nachweisbare Transformationen zwischen Quell- und Ziel- XML- Modellen durchzuführen. Eine Schwäche von XSLT ist, dass es stark auf XML ausgerichtet und daher nicht leicht mit anderen Formaten einsetzbar ist. [Bea10] Rule Interchange Format (RIF) Das Rule Interchange Format wird zurzeit vom W3C (World Wide Web Consortium) im Rahmen des Semantic Web entwickelt. Dieses Format erlaubt den Austausch von Regeln zwischen verschiedenen Systemen. Dafür wird das standardisierte XML Schema verwendet. RIF setzt sich aus drei Dialekten zusammen: RIF Core, RIF Basic Logic Dialect (BLD) und RIF Production Rule Dialect (PRD). RIF ist in der Lage, eine große Bandbreite von Regeln auszudrücken. Es unterstützt alle Standard-Datentypen wie z.b. string, number, boolean sowie Klassen und Vererbungen. RIF- CORE und RIF-BLD ermöglichen die Definition von logischen Regeln. RIF-PRD ermöglicht, Aktionen wie gewünscht zu definieren. RIF-PRD unterstützt daher auch negative Ausdrücke (IF NOT this, THEN that). RIF ist eine ausdrucksstarke Sprache, mit der es möglich ist, die geforderten Modelltransformationen für INSPIRE durchzuführen. Jedoch ist es derzeit noch schwierig, einen Zugang zu dieser Sprache zu bekommen, weil offiziell keine Tutorials bzw. Informationen zur Verfügung stehen. Programmierer die mithilfe dieser Sprache ein System implementieren wollen, sollten daher ein Grundwissen der Sprache besitzen. Dennoch haben Seite 30

37 Kapitel 3: Transformationssprachen und Werkzeuge mehrere große Software-Produzenten Werkzeuge entwickelt, welche RIF unterstützen. Dies ist wiederum ein Indikator dafür, dass es in Zukunft vielleicht vermehrt zum Einsatz kommt. [W3C10] Ontology Mapping Language (OML) Die Ontology Mapping Language (OML) wurde gemeinsam von Arbeitsgruppen der WSMO (Web Service Modeling Ontology), der OMWG (Ontology Management Working Group) und der EU Projekte Semantically Enabled Knowledge Technology (SEKT) und Data, Information and Process Integration with Semantic Webservices (DIP) entwickelt. Die nun dafür verantwortliche Organisation ist die Ontology Management Working Group (OMWG). OML wurde mit XML/RDF erweitert, wodurch die Geospatial Ontology Mapping Language (goml) entstand. Diese Sprache wurde vom Humboldt-Team auf ihre Eignung als Transformationssprache in Hinblick auf INSPIRE geprüft. Der größte Nachteil dieser Sprache ist, dass es sich bei OML bisher noch um keinen Standard handelt, der z.b. von W3C oder OGC anerkannt wurde. [Bea10] Zusammenfassend lässt sich sagen, dass alle 4 Sprachen ihre Vor- und Nachteile haben. Alle würden theoretisch den Ansprüchen für INSPIRE entsprechen. Das in dieser Arbeit verwendete Transformationstool verwendet OML. [Rei10] Der Export der Transformation kann mit XSLT oder RIF erfolgen, wobei RIF als Export-Format für den INSPIRE- Prototypen empfohlen wurde. Bei diesem Prototypen handelt es sich lediglich um eine derzeitige Empfehlung. Aufgrund des Entwicklungsprozesses von Transformationssprachen als auch Werkzeugen ist davon auszugehen, dass sich dieser Prototyp noch ändern kann. 4.2 Transformationswerkzeuge In der Technical Guidance for the INSPIRE Transformation Network Service wurden von Matthew Beare und seinem Team die unterschiedlichen Transformationswerkzeuge untersucht. Es wurden bestimmte Anforderungen definiert, welche die Werkzeuge erfüllen sollten, damit sie für die Transformation in INSPIRE verwendet werden können. [Bea10] Alle in der Studie erwähnten Transformationstools erfüllen die von INSPIRE gestellten Anforderungen. In dieser Arbeit wird das Tool HALE verwendet. Ein Kriterium war die Vielzahl der unterstützenden Dateiformate. Ein weiteres Entscheidungskriterium war, dass die Software kostenlos zur Verfügung steht. Das Programm ist durch das ansprechende Interface sehr intuitiv und so gut wie selbsterklärend. Ebenso steht ein gutes Handbuch sowie ein Videotutorial zur Verfügung. Treten während der Implementierung der Transformation Fragen auf, steht hinter HALE ein sehr gut zusammenarbeitendes Team, welches auf jegliche Fragen innerhalb weniger Tage Antworten liefert. Seite 31

38 Kapitel 3: Transformationssprachen und Werkzeuge Während der Erstellung dieser Diplomarbeit wurde von INSPIRE ein Prototype Paper veröffentlicht, in dem HALE als Transformationstool empfohlen wird. [Bea101] Durch diese Empfehlung wurde die zuvor getroffene Wahl bestätigt Anforderungen für Transformationswerkzeuge In diesem Abschnitt werden die einzelnen Anforderungen genauer beschrieben, welche INSPIRE an die Transformationstools stellt. Sie wurden auch zur späteren Beurteilung verwendet. 1. Bedingung Umbenennung von Klassen und Attributen Das Transformationswerkzeug sollte in der Lage sein, Attribute und Klassen umbenennen zu können. Der Aufbau von Quell- und Zielmodell sollte im Vorhinein schon so gut wie möglich aneinander angeglichen sein, damit eine anschließende Umbenennung keinen großen Mehraufwand bereitet. 2. Bedingung einfache Derivation/Ableitung von Attributen Attribute im Zielmodell werden vom Quellmodell aufgrund von einfachen Basisableitungsfunktionen verändert. Ableitungen der Attribute beinhalten: Datentypen transformieren (z.b. numbers zu text oder string zu timestamps) Transformationen durchführen, die auf einfachen geometrischen Funktionen basieren (z.b. convex_hull, area) Transformationen durchführen, die nicht auf räumlichen Funktionen basieren (z.b. uppercase, substring) Für Standardwerte Werte bestimmen, wenn Daten nicht bekannt sind Werte ersetzen, die auf lookup Tabellen basieren (z.b. code lists) Eingabe von Identifikatoren für referenzierte Objekte 3. Bedingung Verbindung von Eingabedatensätzen/Berichten Diese Bedingung erlaubt den Aufbau von Attribute als wären sie individuelle Objektmerkmale, basierend auf mehreren Speicherberichten im Quellschema. Dies wird besonders dann empfohlen, wenn die Quelldaten in einer relationalen Datenbank gespeichert sind. Seite 32

39 Kapitel 3: Transformationssprachen und Werkzeuge 4. Bedingung komplexe Ableitung und dynamische Auswahl von Typen Eine einzelne Klasse des Quellmodelles kann auf mehreren verschiedenen Klassen des Zielmodells abgebildet werden. Dies ist abhängig von den Werten der Attribute in der Klasse. Die neuen Typen und die zu unterstützenden, logischen Operationen sind Folgende: Bedingungen (if...then...else) Überprüfung für skalare Verbindungen (equals, less than, greater than) Überprüfung von logischen Kombinationen (or, and, not) Beurteilung von einfachen Ableitungsregeln Verbindung über Attribute oder abgeleitete Werte (for each element in array, for each part in complex geometry) 5. Bedingung Ableitung von auf mehreren Besonderheiten basierenden Werte Die Bedingung erlaubte die Erstellung von einem Ausgabeattribut, welches auf einem einzelnen Quellattribut basiert. In dieser Bedingung werden kontextabhängige Informationen verwendet, um Werte des Zielattributs abzuleiten. Dies beinhaltet: Beurteilung von räumlichen Beziehungen (within, overlaps, intersects) Beurteilung referenzierter Beziehungen (z.b. Fremdschlüssel, oder Beziehungen über Identifkatoren) universelle Qualifikationen (z.b. für alle Features x dann...) existentielle Qualifikationen (z.b. es existiert ein Merkmal x das,...) 6. Bedingung Verschmelzung und Modellgeneralisierung Attribute des Zielmodells können auch von mehreren Quellmodellattributen erstellt werden. Umgekehrt können auch mehrere Zielmodellattribute von einem Attribute des Quellmodells erstellt werden. Es ist daher möglich, dass Attribute des Zielmodells, die sich auf ein Attribut des Quellmodells beziehen, in mehreren Klassen oder auch in Seite 33

40 Kapitel 3: Transformationssprachen und Werkzeuge mehreren Quellschemen vorhanden sind. Die Erstellung von separaten Merkmalen, die Polygone und Grenzlinien, oder Polygone und Positionspunkte repräsentieren, zu einem einzelnen Quellmerkmal. Die Erstellung eines Zielmerkmals von einem Quellmerkmal vom Schema A mit zusätzlichen Attributen von einem separaten Merkmal vom Quellmerkmal B. Die Erstellung eines einzelnen Zielmerkmals von zwei übereinstimmenden Quellmerkmalen. Die Generalisierung mehrerer berührender Quellmerkmalen zu einem größeren Zielmerkmal Derzeit angebotene Transformationswerkzeuge Tabelle 2 wurde für die Technical Guidance for the INSPIRE Transformation Network Service erstellt und listet alle derzeit kommerziellen und Open-Source-Werkzeuge zur Durchführung von Modelltransformationen auf. Anbieter Name Version Verfügbarkeit Humboldt Humboldt Alignment Editor HALE M1 OpenSource interactive instruments GmbH Xtra Server 3.2 kommerziell SAFE Software FME Server 2010 kommerziell Snowflake Software GO Publisher 2.0 kommerziell lat / long GmbH Deegree 3.0 OpenSource 1Spatial Radius Studio - kommerziell Tabelle 2: Transformationswerkzeuge ([Bea10], verändert) Humboldt Alignment Editor Dieser Editor wurde im Rahmen des Humboldt Projektes entwickelt. Das Hauptziel des Humboldt Projektes ist es, den Organisationen bzw. den Verwaltungsämtern die Seite 34

41 Kapitel 3: Transformationssprachen und Werkzeuge Dokumentation, Veröffentlichung und Harmonisierung ihrer Geodaten zu ermöglichen. Das technische Ziel ist es, die Implementierung von Geodaten-Infrastrukturen (GDI) zu unterstützen. Dafür werden im Zuge des Projektes Programme entwickelt, die Lösungen für alle Benutzer, Datenbereitsteller und auch für den privaten Endnutzer liefern und jedem zur Verfügung stehen. Mithilfe der Software von Humboldt ist es möglich, die Modelle zu spezifizieren und die Transformation zwischen ihnen zu definieren. Die Software steht zum freien Download auf der Homepage zur Verfügung. [Rei10] Das Hauptaugenmerk des Projektes liegt auf INSPIRE. Daher sind die Werkzeuge direkt für diese Anwendung entwickelt worden. Durch den Model Editor fällt es dem Anwender leicht, den direkten Zusammenhang zwischen Modelldefinition und Transformation zu erkennen. Als Kernabbildungsformat wurde die Ontology Mapping Language gewählt. Die Wahl dieser Sprache könnte sich aufgrund der fehlenden Standardisierung negativ auf die Interoperabilität auswirken. Der Umgang mit großen Datenmengen ist noch zu wenig erforscht. Daher kann noch nicht gesagt werden, ob große Datenmengen verarbeitet werden können. [Bea10] XtraServer Xtra Server ist eine auf XML basierende Software, entwickelt von Interactive Instruments GmbH. XtraServer dient dem Aufbau von Geo-Web-Services nach den Spezifikationen des Open Geospatial Consortium (OGC). XtraServer kann z.b. in ArcGIS eingebunden werden. Die Modellierungen können in UML vorgenommen werden. Dieses Transformationstool unterstützt viele Datenformate, ebenso das von INSPIRE geforderte GML 3.2. Eine Nachteil ist, die proprietäre Abbildungssprache. [Xtr10] FME Server Der von Safe Software entwickelte FME Server ermöglicht es, Abbildungen zwischen Daten zu definieren und Transformationen durchzuführen. Der FME Server arbeitet auf Format- und Modellebene. Auf Formatebene erfolgt das Einlesen und Schreiben der Daten. Auf Modellebene können konzeptuelle Datenmodelle gelesen und geschrieben werden. Ein großer Schwachpunkt dieses Transformationstools ist die proprietäre Abbildungssprache. Daher können Transformationen nicht mit anderen Werkzeugen ausgetauscht werden. [FME10] GO Publisher v1.4 GO Publisher wurde von Snowflake Software entwickelt. Das Programm ist für Datenmengen von bis zu 10 MB als Open Source Version verfügbar. Die Version v1.4 ist über das Internet downloadbar. Das Interface von GO Publisher ist intuitiv aufgebaut und ermöglicht dadurch Seite 35

42 Kapitel 3: Transformationssprachen und Werkzeuge eine leichte Handhabung. Das Programm unterstützt Transformationen vom Datentyp KML, GML 2, GML und GML. GO Publisher verwendet ebenfalls eine proprietäre Abbildungssprache. [GOP11] Deegree 3.0 Deegree ist eine Open Source Software, die einfach übers Internet downloadbar ist. Sie wurde unter der Beachtung der OGC- und ISO- Standards implementiert. Deegree ist ein umfassendes Programm, welches WMS und WFS, ein Geoportal, eine Desktop Anwendung, einen Sicherheitsmechanismus und verschiedene Werkzeuge für die Implementierung von Prozessen, die mit Geodaten arbeiten, zur Verfügung stellt. Deegree basiert auf einer 5- Ebenen-Struktur und unterstützt die Datenformate GML, KML, CityGML, CS-W. Vektordaten und Datenanbindungen können einfach hinzugefügt werden wie z.b. ESRI Shapefile, PostgreSQL/PostGIS, Oracle Spatial/Locator, MIF, ArcSDE und JDBC. [Dee10] Seite 36

43 Kapitel 5 5. Analyse des Quellmodells Bei dem Quellmodell handelt es sich um die vom Bundesamt für Eich- und Vermessungswesen (BEV) geführte, österreichische digitale Katastralmappe (DKM). Dieses soll für INSPIRE transformiert werden. Daher müssen folgende Punkte geklärt werden: 5.1 Bundesamt für Eich- und Vermessungswesen Die DKM wird vom BEV geführt. Das BEV ist eine dem Bundesministerium für Wirtschaft, Familie und Jugend nachgeordnete Bundesbehörde. Der Aufgabenbereich setzt sich aus Vermessung und Geoinformation und dem Mess- und Eichwesen zusammen. Die Zentrale befindet sich in Wien. In ganz Österreich verteilt gibt es zurzeit 41 Vermessungsämter und 9 Eichämter. Dadurch können die vor Ort zu tätigenden Arbeiten (Beratung, Grenzverhandlung, Einmessungen usw.) effizient geleistet werden. Aufgabenschwerpunkte für den Fachbereich der Vermessung und Geoinformation sind die Grundlagenvermessung, die Anlegung und Führung des Katasters zur Dokumentation der räumlichen Zuordnung der Eigentumsrechte an Grund und Boden und die topographische Landesaufnahme. Die Ergebnisse dieser Arbeiten werden aufbereitet und in den diversen Shops zur Verfügung gestellt. Das BEV ist einer der größten öffentlichen Geodatenersteller und Geodatenanbieter Österreichs. Die vom BEV zur Verfügung gestellten Produkte können vielseitig verwendet und in verschiedenen Produkten eingearbeitet werden. Sie finden z.b. Anwendung in den Bereichen Raumplanung, Telematik/Navigation, Energieversorgung, Landesverteidigung, Umwelt- und Katastrophenschutz. Der Fachbereich Mess- und Eichwesen umfasst das Nationale Metrologie-Institut und die nationale Eichbehörde. [BEV10] Seite 37

44 Kapitel 4: Analyse des Quellmodells 5.2 Das Quellmodell im Kontext von digitaler Katastralmappe und Grundbuch Das Österreichische System der Eigentumssicherung an Grund und Boden beruht auf zwei Säulen. Die eine Säule ist der Kataster und dessen technische Ausführung, die Digitale Katastralmappe, in der die technischen Daten des Grundstücks gespeichert werden. Die digitale Katastralmappe dient dem Nachweis der Grenzen der Grundstücke und der Veranschaulichung tatsächlicher Grundstücksverhältnisse. Die andere Säule stellt das Grundbuch dar, in dem die eigentumsrechtlich relevanten Daten geführt werden. Bei dem Grundbuch handelt es sich um ein öffentliches Verzeichnis. Unter diesen rechtlich relevanten Daten sind die bestehenden dinglichen Rechte gemeint. Diese öffentlichen Bücher, Grundbuch und (Grenz-) Kataster, werden automationsunterstützt in der Grundstücksdatenbank (GDB) geführt. Jedermann kann gegen Entgelt bei den Bezirksgerichten, den Vermessungsämtern und über das Internet Einsicht erhalten. Die Grundstücksdatenbank wird vom Bundesamt für Eich- und Vermessungswesen in Zusammenarbeit mit dem Bundesministerium für Justiz geführt. [Ern05] 5.3 Digitale Katastralmappe (DKM) Die Digitale Katastralmappe (DKM) ist der grafische Datenbestand des Katasters im österreichischen Landeskoordinatensystem. Sie wird von den zuständigen Vermessungsämtern geführt. Mithilfe der DKM wird die Lage der Grundstücke dargestellt. Sie enthält: die Grenzen der Grundstücke die Grundstücksnummern die Abgrenzungen der Benützungsarten / Nutzungsarten die Fest- und Grenzpunkte mit deren Nummern Die Daten der DKM sind mit den Datenbanken des Katasters (Grundstücksdatenbank, Koordinatendatenbanken) konsistent. [BEV10] Die Anlegung einer digitalen Katastralmappe war zum einen durch die Bestimmung 9 VermG und zum anderen auf Wunsch der Landwirtschaft initialisiert. Der 9 VermG besagt: Der Grenzkataster besteht aus dem technischen Operat (Abs. 2), dem Grundstücksverzeichnis (Abs. 3) und dem Adressregister ( 9a). Er ist, soweit technisch möglich, automationsunterstützt zu führen. (Grundstücksdatenbank). [Jus10] Seite 38

45 Kapitel 4: Analyse des Quellmodells Hochwartner definiert die Digitale Katastralmappe auf folgende Weise: Die DKM ist zentraler Bestandteil eines raumbezogenen Informationssystems, das flächendeckend im System der Landesvermessung jene Basisdaten zur Verfügung hält, die für die Sicherung der Grundstücksgrenzen, die Dokumentation der Verhältnisse an Grund und Boden, sowie für die Einrichtung von und die Verknüpfung mit anderen bodenbezogenen Datenbeständen erforderlich sind. [Hoc91] Zielsetzungen der DKM Bei der Anlegung der digitalen Katastralmappe wurden folgende Zielsetzungen definiert: Qualitätsverbesserung durch korrekte und homogene Lagedarstellung der Grundstücke Aktualisierung der Bodennutzung [Ern05] Aufgrund des INSPIRE Zielmodells musste das der DKM zugrundeliegende Datenmodell um die für INSPIRE relevanten Daten aus der Grundstücksdatenbank ergänzt werden. Abbildung 13: Quellmodell im Kontext von DKM und GDB Seite 39

46 Kapitel 4: Analyse des Quellmodells Seite 40

47 Kapitel 4: Analyse des Quellmodells 5.3 Koordinatenreferenzsystem der DKM Das österreichische Koordinatenreferenzsystem MGI (Militär-Geographisches Institut) findet seinen Ursprung bereits Ende des 19. Jhdt. Es wurde damals für die gesamte Monarchie geschaffen und bildet nach wie vor die Grundlage des österreichischen Vermessungssystems. Als Bezugsellipsoid wurde das Bessel-Ellipsoid definiert (a = ,155 m, b= ,963 m). Dieses ist im Fundamentalpunkt am Hermannskogel (Habsburgwarte) gelagert. Mithilfe von astronomischen Messungen wurden Breite (B= ,29, Länge L = ,06 östlich von Ferro) und das Azimut A = ,70 ) zum Hundsheimer Berg bestimmt. Der Maßstab wurde mit der Basis von Josefstadt definiert. Diese Werte wurden fehlerfrei als ellipsoidische Werte übernommen. Die Lotabweichungen, sowie die Geoidundulation im Fundamentalpunkt Hermannskogel wurden auf null gesetzt. Die kleine Halbachse des Ellipsoids wurde parallel zur Erdrotationsachse festgelegt. [Bre04] Das Koordinatensystem wurde durch ein Festpunktfeld Ordnung, bestehend aus ca Triangulierungspunkten (TPs) und ca nachgeordneten Einschaltpunkten (EPs), realisiert. (Stand 2011) Längenangaben in Österreich beziehen sich aus historischen und praktischen Gründen auf Ferro und nicht auf Greenwich. Ferro ist die westlichste der kanarischen Inseln und galt bis ins Mittelalter als westlichster Punkt, der zum damaligen Zeitpunkt bekannten Welt. Der Bezugsmeridian Ferro liegt laut Definition 20 westlich der Sternwarte Paris. Dies bedeutet, dass die österreichische Längenzählung eigentlich auf die Sternwarte Paris bezogen ist. Die definierte Umrechnung zwischen den Bezugsmeridian Greenwich und Ferro lautet wie folgt: LGreenwich = LFerro [Bre04] Das österreichische Staatsgebiet ist für die Kartenprojektion Gauß Krüger in drei Meridianstreifen mit je 3 Längenausdehnung eingeteilt. Die Meridiane liegen 28, 31 und 34 östlich von Ferro. Zusätzlich zu den Koordinaten muss auch der Meridianstreifen (M28, M31, M34) in dem abgebildet wird, angegeben werden. [Bre04] Seite 41

48 Kapitel 4: Analyse des Quellmodells Abbildung 14: Bezugsmeridiane M28, M31 und M34 [Ern05] Beispielhaft werden hier die Parameter des MGI / Austria GK Central, mit dem EPSG Code 31255, angegeben. Die EPSG Codes sind eine Schlüsselnummer für Koordinatenreferenzsysteme bzw. Koordinatentransformationen. Diese wurden vom OGP Geomatics Committee entwickelt. MGI / Austria GK Central (EPSG Code: 31255) geodätisches Datum Militär-Geographische Institut (MGI) Ellipsoid Bessel 1841 große Achse (a) ,155 m Abplattung: 1/f 299, Meridian Greenwich Bezugspunkt Hermannskogel geografische Breite: ,29 N geografische Länge: ,06 E (von Greenwich) verwendete Fläche Österreich zwischen E und E von Greenwich, und E von Ferro Projektionsmethode Österreich Gauß Krüger Central, Transverse Mercator Maßstabsfaktor 1 Add. Konst. Rechtswert 0 m Add. Konst. Hochwert m Tabelle 3: MGI / Austria GK Central Seite 42

49 Kapitel 4: Analyse des Quellmodells 5.4 Das Quellmodell Das Datenmodell der Abgabedatenbank des Bundesamtes für Eich- und Vermessungswesen besteht aus den Klassen: - Grundstueck - Grundstueck_EZ - KG Abbildung 15 stellt das UML Modell dar. Abbildung 15: Quellmodell Seite 43

50 Kapitel 4: Analyse des Quellmodells Tabelle Grundstueck Diese Tabelle beinhaltet die Informationen der DKM bezüglich eines Grundstücks in Österreich. Ein Grundstück in Österreich ist wie folgt gesetzlich definiert [Jus10] : 7a VermG (1) Ein Grundstück ist jener Teil einer Katastralgemeinde, der im Grenzkataster oder im Grundsteuerkataster als solcher mit einer eigenen Nummer bezeichnet ist. (2) Grundstücke werden durch Grundbuchsbeschluss oder im Zuge der Neuanlegung des Grundbuches neu gebildet oder gelöscht. Ein Grundstück besteht aus einem oder mehreren Benützungsabschnitten. Die Geometrie der Grundstücke ist durch ein Polygon festgelegt. Eine für INSPIRE relevante Information des Quellmodells ist die Nummer der Katastralgemeinde (KG_NUMMER). Diese ist in Österreich eine eindeutige Nummer. Das Grundstück ist durch die Nummer der Katastralgemeinde und der Grundstücksnummer definiert (KG_GNR). Die Grundstücksnummer selbst setzt sich aus dem Zeichen, das angibt ob es sich um eine Baufläche handelt (Punkt), der Stammnummer und der Unterteilungsnummer zusammen. Abbildung 16: KG_GNR Der Rechts- und Hochwert sind die YX- Koordinaten eines Referenzpunktes in dem Grundstück. Die Bundeslandkennziffer, Bezirkskennziffer und eine eindeutige Kennziffer geben zusammen die in Österreich eindeutige Gemeindekennziffer (GEMNR) an. Seite 44

51 Kapitel 4: Analyse des Quellmodells Abbildung 17: Gemeindekennziffer Grundstueck_EZ Diese Tabelle wurde aus der Grundbuchsdatenbank entnommen. Sie beinhaltet die Sachdaten zu einem Grundstück. Das Attribut Nummer repräsentiert die Grundstücksnummer. Flaeche_Gst gibt die vermessungstechnisch bestimmte Fläche des Grundstücks an. Das Attribut Grundbuch verkörpert die Grundbuchsnummer. Die Einlagezahl ist durch das Attribut Einlage gegeben. Unter der Einlagezahl versteht man die kleinste Einheit von Eigentum. Sie wird vom zuständigen Grundbuchsgericht geführt und in der Grundstücksdatenbank (GDB) eingetragen. Dabei sind der Einlagezahl (EZ) die rechtsgültigen Grundstücke zugewiesen. Zusätzlich beinhaltet diese Tabelle die Attribute KG_NR, welches die Katastralgemeindenummer darstellt, und KG_GNR, welches die Katastralgemeindenummer in Verbindung mit dem Grundstück darstellt. In dem Attribut GB_EZ ist das Grundbuch in Verbindung mit der EZ dargestellt. KG_14168 Diese Tabelle bezieht sich auf die Katastralgemeinde, welche die für die Zuweisung der Grundstücke kleinste Hierarchie in der Unterteilung des Österreichischen Staatsgebietes darstellt. Die Hierarchie setzt sich wie folgt zusammen: Abbildung 18: Hierarchie Übersicht Bei den in der Grafik angeführten Zahlen handelt es sich jeweils um die dazugehörige Anzahl. Ihre Attribute überdecken sich komplett mit der zuvor beschriebenen Klasse Grundstueck. Deshalb wird diese hier auch nicht näher beschrieben. Im Anhang I ist eine Tabelle angeführt, in welcher alle Attribute des Quellmodells angeführt sind. Hier wurden nur die für die Transformation notwendigen Attribute angeführt. Seite 45

52 Kapitel 6 6. Analyse des Zielmodells Bei dem Zielmodell handelt es sich um Cadastral Parcels welches in Anhang I der INSPIRE- Richtlinie (Infrastructure for Spatial Information in the European Community) definiert ist. Der Begriff Cadastral Parcels wird im Zuge von INSPIRE wie folgt definiert: Areas defined by cadastral registers or equivalent Im Geodateninfrastrukturgesetz (GeoDIG) wird es übersetzt als: Gebiete, die anhand des Grundbuchs oder gleichwertiger Verzeichnisse bestimmt werden. [Hin10] Jeder europäische Mitgliedsstaat führt für die Landadministration einen Kataster, ein Register in dem die Grundstücke des Landes erfasst sind. Für die Verwaltung und Erfassung ist in Österreich das Vermessungsamt zuständig. Dieser Zuständigkeitsbereich liegt europaweit meistens in der öffentlichen Hand. Das Ziel von Cadastral Parcels ist es, die Daten in eine möglichst einfache und somit flexible Struktur zu bringen. Cadastral Parcels ist deshalb ein im Anhang 1 definiertes Datenthema, weil sich darauf auch im Anhang II und III aufgeführten Datenthemen (z.b. Schutzgebiete usw.) beziehen können. 6.1 Koordinatenreferenzsystem für INSPIRE Im Jahre 1987 wurde durch die International Association of Geodesy (IAG) die EUREF- Subkommission geschaffen. Diese hatte die Aufgabe, ein europäisches Referenzsystem zu Seite 46

53 entwickeln. Im Jahre 1990 wurde auf dem EUREF-Symposium in Florenz der Koordinatenreferenzrahmen ETRS wie folgt definiert: Das ETRS ist mit dem ITRS zur Epoche gleichzusetzen. Das ETRS ist fest mit dem stabilen Teil der eurasischen Platte verbunden. Seite 47

54 Kapitel 5: Analyse des Zielmodells Das neue System wird ETRS89 genannt, da es 1989 erstmals realisiert wurde. Dabei wurde ein Teil der VLBI- und SLR- Stationen verwendet. Im selben Jahr erfolgte eine Verdichtung der ersten Lösung mittels 92 Messstationen. Dadurch wurde eine Genauigkeit von 4,3 cm in der Lage und 6,2 cm in der Höhe erreicht. Anschließend wurden bis zum Jahr Punkte durch 24 GPS-Kampagnen gemessen. Dabei handelte es sich um Epochenmessungen, welche an die bestehenden ITRS- und ETRS- Punkte angebunden wurden. Die nächste Ausbaustufe wurde durch die Installation einer großen Zahl von GPS- Permanentstationen, Mitte der 90er Jahre, realisiert. Auch diese Koordinaten unterliegen, aufgrund verschiedener Einflüsse Änderungen. Deswegen gibt es auch beim ETRS, wie auch beim ITRS, mehrere Realisierungen. Beim ETRS liegen die Koordinatenänderungen pro Jahr ca. im Bereich von 1 2 mm. [Hög02] ETRS 89 / UTM zone 33N (EPSG Code: 25833) geodätisches Datum European Terrestrial Reference System 1989, ETRS89 Ellipsoid GRS 1980 große Achse (a) m Abplattung: 1/f 298, Meridian Greenwich Bezugspunkt ITRF 89 (Massenschwerpunkt / Geozentrum der Erde) verwendete Fläche Europa zwischen 12 E und 18 E, Norwegen und Svalbard (Inselgruppe Spitzbergen) 12 E und 21 E Projektionsmethode UTM zone 33N, Transverse Mercator Maßstabsfaktor 0,9996 Add. Konst. Rechtswert m Add. Konst. Hochwert 0 m Tabelle 4: ETRS 89 / UTM zone 33N 6.2 Das Zielmodell Das Zielmodellmodell von INSPIRE wurde als UML Modell bzw. als Schema Datei (.xsd) zur Verfügung gestellt. Das Modell besteht aus folgenden Klassen: - BasicPropertyUnit - CadastralBoundary - CadastralParcel Seite 48

55 Kapitel 5: Analyse des Zielmodells - CadastralZoning Zielmodell: Seite 49

56 Kapitel 5: Analyse des Zielmodells Abbildung 19: Zielmodell Cadastral Parcels [INS11] Seite 50

57 Kapitel 5: Analyse des Zielmodells BasicPropertyUnit Der englische Begriff Basic Property Unit entspricht in Österreich der Einlagezahl. Daher enthält diese Klasse alle Informationen bezüglich der Einlagezahl bzw. der Sachdaten. Bei der Basic Property Unit handelt es sich um die kleinste Einheit für Eigentum. Die Basic Property Unit besteht aus ein oder mehreren Cadastral Parcels. Das erste Attribut dieser Klasse ist wieder der für jedes Land eindeutig definierte, externe Objektidentifikator. nationalcadastralreference besteht aus der Katastralgemeindenummer und der Einlagezahlnummer. Das Attribut areavalue fordert, wie bereits im Unterkapitel 5.4 beschrieben, die im Grundbuch nachgewiesene Flächenangabe des Grundstücks. Die Attribute validfrom und validto beschreiben ab welchem Datum und Zeitpunkt die Einlagezahl rechtswirksam festgelegt bzw. aufgehoben wurde. Die Attribute beginlifespanversion und endlifespanversion geben Auskunft über das Datum und den Zeitpunkt, zu welchem diese Version der Einlagezahl eingefügt oder verändert bzw. ersetzt oder entfernt worden ist. Diese Klasse beinhaltet die Verknüpfung administrativeunit und die Bedingungen areavalueuom, endlifespanversion und validto. CadastralBoundary Der englische Begriff Cadastral Boundary entspricht in Österreich der Grenze/Begrenzung eines Grundstücks im Kataster. Es stellt somit die Abgrenzung für das CadastralParcel dar. Diese Klasse enthält daher alle Informationen bezüglich dieser Grenze. Die Geometrie der Begrenzung ist durch das Attribut geometry festgelegt. Die inspireid ist wieder der Identifkator. Die Attribute beginlifespanversion, endlifespanversion, estimatedaccuracy, validfrom und validto haben in dieser Klasse die gleiche Bedeutung wie in der Klasse CadastralParcel mit der einzigen Änderung, dass sich diese auf die Grundstücksgrenze beziehen. Diese Klasse beinhaltet die Verbindung parcel. Ebenso sind wieder die Bedingungen endlifespanversion, estimatedaccuracyuom und validto in dieser Klasse eingebunden. CadastralParcel Der englische Begriff Cadastral Parcel entspricht in Österreich dem Grundstück. Dabei handelt es sich um die kleinste identifizierbare Landeinheit. Diese Klasse enthält daher alle Informationen bezüglich des Grundstücks. Das Attribut geometry definiert die Geometrie des Grundstücks. Die inspireid ist ein für jedes Land eindeutiger, externer Objektidentifikator. Mit dem Attribut label wird die Nummer des Grundstücks verknüpft. NationalCadastralReference beschreibt die Nummer des Grundstücks im Kontext mit dem nationalen Code. Das Attribut areavalue fordert die offizielle Flächenangabe des Grundstücks, laut der Grundstücksdatenbank. referencepoint fordert die Angabe eines Referenzpunktes innerhalb des Grundstücks. Die Attribute validfrom und validto beschreiben, ab welchem Datum und Zeitpunkt das Grundstück offiziell rechtswirksam festgelegt bzw. aufgehoben wurde. Die Attribute beginlifespanversion und endlifespanversion geben Auskunft über das Datum und Seite 51

58 Kapitel 5: Analyse des Zielmodells den Zeitpunkt, zu welchem diese Version des Grundstücks in die DKM eingefügt oder verändert bzw. ersetz oder entfernt wurde. In dieser Klasse eingebunden sind die Verknüpfungen administrativeunit, basicpropertyunit und zoning und die Bedingungen 8 areavalueuom, endlifespanversion, geometrytype und validto. CadastralZoning Der englische Begriff Cadastral Zoning entspricht in Österreich der Katastralgemeinde. Dabei handelt es sich um die administrative Einheit, in der der Kataster geführt wird. Daher enthält diese Klasse alle Informationen bezüglich der Katastralgemeinde, in der das Grundstück liegt. Cadastral Zoning besteht aus ein oder mehreren Basic Property Units. Die Geometrie der Katastralgemeinde ist durch das Attribut geometry festgelegt. Die inspireid stellt wieder den externen Objektidentifikator dar. Das Attribut label ist der Name der Katastralgemeinde. nationalcadastralzoningreference ist die Nummer der Katastralgemeinde. Die Attribute beginlifespanversion und endlifespanversion geben Auskunft über das Datum und den Zeitpunkt, zu welchem diese Version der Katastralgemeinde eingefügt oder verändert bzw. ersetzt oder entfernt wurde. Das Attribut estimatedaccuracy gibt die zu erwartende, abgeschätzte, absolute Positionsgenauigkeit im verwendeten INSPIRE- Koordinatenreferenzsystem an. level gibt die Ebene (entweder 1 Gemeinde oder 2 Katastralgemeinde) der Katastralgemeinde in der Hierarchie des österreichischen Katasters an. levelname gibt lediglich den Namen der Ebene an. Das Attribut name legt den Namen der Katastralgemeinde fest. In Österreich deckt sich dieses Attribut mit dem oben angeführten Attribut label. Der originalmapscaledenominator gibt die Maßstabszahl der Original- Papiermappe an. Die Attribute validfrom und validto beschreiben, ab welchem Datum und Zeitpunkt die Katastralgemeinde rechtswirksam festgelegt bzw. aufgehoben wurde. referencepoint fordert die Angabe eines Referenzpunktes innerhalb der Katastralgemeinde. Diese Klasse enthält die Verbindung upperlevelunit und die Bedingungen endlifespanversion, estimatedaccuracyuom und validto und eine zusätzliche Bedingung zoninglevelhierachy. 8 Engl. constraints Seite 52

59 Kapitel 7 7. Humboldt Alignment Editor Die Software Humboldt Alignment Editor(HALE) wurde im Zuge des HUMBOLDT-Projektes entwickelt. Dieses Projekt wurde von der EU initiiert und behandelt die europaweite Problematik der Geodaten- Harmonisierung. Das Hauptziel des HUMBOLDT-Projektes ist es, den Geodatenbereitstellern eine Möglichkeit zu geben ihre Geodaten zu dokumentieren, zu harmonisieren und zu veröffentlichen. Das HUMBOLDT Projekt wird von 28 Partnern aus 14 europäischen Staaten unterstützt und unter der Leitung des Fraunhofer Instituts für graphische Datenverarbeitung (IGD) koordiniert. Ein Anliegen des HUMBOLDT Projektes ist es, möglichst nicht invasiv zu sein. Bereits existierende Systeme sollen nicht ersetzt werden, sondern unterstützt und mit zusätzlichen Funktionen ausgestattet werden. Für die Modelltransformation wurden drei Softwarepakete implementiert: [Hum11] Humboldt GeoModel Editor, unterstützt die Spezifizierung von Quell- und Zielmodell Humboldt Alignment Editor, ein Werkzeug, das die Definition von Modelltransformationen unterstützt Humboldt Conceptual Schema Transformer, ist verantwortlich für die Ausführung der Transformation Alle drei Softwarepakete befinden sich noch in der Entwicklungsphase. 7.1 Aufbau von HALE Der hier für die Modelltransformation verwendete HALE ist ein intuitiv gestaltetes und, wie man in Kapitel 7.2 lesen kann, funktionsumfassendes Werkzeug. Durch das fast selbsterklärende Interface ist die Handhabung auch für nicht erfahrene Programmierer gegeben. Mit dessen Hilfe lassen sich überschaubar und verständlich die Seite 53

60 Transformationsregeln definieren. Seite 54

61 Kapitel 6: Humboldt Alignment Editor Die Transformation wird mithilfe der Ontology Mapping Language (OML) ausgeführt. Das Interface des Programmes beinhaltet: Der Schema Explorer zeigt eine Übersicht der Struktur des Quell- (links) und des Zielmodells (rechts) in verschiedenen Ansichtsmöglichkeiten. Die Mapping View zeigt Informationen über die aktuell definierten Transformationsregeln. Die Map View zeigt die kartografische Repräsentation der Referenzdaten des Quellmodells und den bereits transformierten Daten. Diese Darstellung kann jedoch nur erfolgen, wenn man diese auch geladen hat. Die Ansicht kann dynamisch verändert und navigiert werden. Reference Data zeigt eine tabellarische Übersicht der Referenzdaten. Transformed Data zeigt wie oben, eine tabellarische Übersicht, damit die bereits transformierten Daten untersucht werden können. Tasks zeigt eine Übersicht über die noch durchzuführenden Aufgaben. Die Mapping Graph View zeigt eine grafische Übersicht über die Transformation. Das Error Log zeigt einen Einblick in die Log Benachrichtigungen des Programmes. Diese können als log files exportiert werden. Seite 55

62 Kapitel 6: Humboldt Alignment Editor Abbildung 20: Screenshot des Transformationswerkzeugs HALE Seite 56

63 Kapitel 6: Humboldt Alignment Editor Es können XSD-Dateien als Quell- und Zielschema importiert werden. Bei den GML Dateien werden zurzeit folgende Versionen unterstützt: GML 2.1 GML 3.1 GML 3.2 HALE ermöglicht das Importieren von Shape Dateien. Außerdem können Schemen direkt oder über ein Web Feature Service geladen werden. Die importierten Schemen werden mithilfe einer Baumstruktur dargestellt. Die Transformation selbst erfolgt mithilfe von OML. Die Projektdatei wird automatisch in XML gespeichert. Die Transformationsergebnisse können als GML-Datei exportiert werden. Die Transformation an sich kann in verschiedenen Formaten exportiert werden: Rule Interchange Format (RIF), Comma-Seperated Values (CSV), Ressource Description Framework (RDF) und Hypertext Markup Language (HTML). Abbildung 21 zeigt anschaulich die Ein- und Ausgabeformate von HALE: Abbildung 21: Ein- und Ausgabe Formate von HALE [Rei10] Seite 57

64 Kapitel 6: Humboldt Alignment Editor 7.2 Transformationsfunktionen von HALE Folgende in HALE zur Verfügung stehende Transformationsfunktionen können verwendet werden: Attribute Rename Function zur Umbenennung von Attributen, um diese in Beziehung zu setzen. Generic Math Function zur Generierung mathematischer Ausdrücke, wobei Attribute des Quellmodells als Variablen dienen können. Bounding Box Function und Centroid Function zur Ableitung geometrischer Funktionen von Attributen. Buffer Function zur Erzeugung von Pufferzonen für Linien- oder Punkt- Geometrien. Classification Mapping Function ermöglicht die Transformation von Code-Listen und Klassifizierungswerten. Ordinates to Point Geometry Function akzeptiert die Eingabe von zwei numerischen Werten und erzeugt auf deren Basis eine Punkt-Geometrie. Attribute Concatenation Function erlaubt die Verknüpfung von Attributen und benutzerdefinierten Strings. Date Extraction Function zur Umformatierung eines Zeitpunkts. Create GML Reference Function ermöglicht die Erzeugung einer Referenz zu einem anderen Element in demselben oder einen anderen Datensatz. Seite 58

65 Kapitel 6: Humboldt Alignment Editor INSPIRE Identifier Function ermöglicht die Erzeugung eines IdentifierProperty-Type. INSPIRE Geographic Name Function ermöglicht dasselbe für Geographic-NamePropertyTypes. User Defined Function Diese Funktion arbeitet als Platzhalter für Transformationsfunktionen, die derzeit im HALE noch nicht implementiert sind. Es gibt auch sogenannte Augmentation Funktionen, welche nur dem Zielmerkmal zugeordnet werden. Beispiele dafür sind z.b. NilReason Function und Attribute Default Value. In der im nächsten Kapitel dargestellten Verzweigungstabelle sind die für diese Transformation verwendeten Funktionen ersichtlich. Seite 59

66 Kapitel 8 8. Testdatensatz Als Quelldatensatz wurde vom BEV die Katastralgemeinde (KG) Umbach mit der KG-Nummer zur Verfügung gestellt. Aufgrund der noch fehlenden Erfahrungen bezüglich der Ladezeit größerer Datenmengen mit HALE wurde diese kleine KG gewählt. Die Katastralgemeinde Umbach liegt in Niederösterreich. Das zuständige Vermessungsamt ist St. Pölten. Das zuständige Grundbuchsgericht ist Melk. Die Katastralgemeinde Umbach liegt in der politischen Gemeinde Dunkelsteinerwald mit der Gemeindekennziffer Das Zentrum liegt in der Ortsmitte von Umbach und hat die Koordinaten: y Koord. / östl. Greenw m / x Koord. / nördl. Breite m / Die Katastralgemeinde umfasst 100 Grundstücke davon, befinden sich 6 Grundstücke im Grenzkataster. Die ganze Katastralgemeinde weist eine Fläche von m² auf. Abbildung 22: Bildausschnitt aus dem BEV Shop der KG [BEV10] Seite 60

67 Seite 61

68 Kapitel 7: Testdatensatz 8.1 Vorarbeiten für die Transformation Bei der zur Verfügung gestellten Datei, handelte es sich um Mithilfe des e-geodata Austria Portal (EGA) generierten Shapefiles des ausgewählten Interessensgebietes der DKM. Diese Shapefiles (Grundstueck und KG) wurden in ArcGIS importiert und in eine Personal Geodatabase (.mdb) gespeichert. Aufgrund der fehlenden Sachdaten wurde zusätzlich ein Auszug aus der Grundstücksdatenbank (GDB) herangezogen. Dieser Zugang wurde ebenfalls mithilfe des BEV Shops auf der Homepage gewährt. Der im Ascii-Format downloadbare Auszug wurde in eine Access Datenbank eingefügt. Für das richtige Importieren der Daten wurde der vom BEV erstellte Satzspiegel verwendet. Für die Erstellung einer Tabelle, welche alle notwendigen Attribute des Quellmodells beinhaltet, wurden in Access mehrere Abfragen generiert. Diese Tabelle wurde dann in die Personal Geodatabase importiert. Das gewählte bzw. von INSPIRE empfohlene Transformationswerkzeug befindet sich noch in der Entwicklungsphase. Da noch nicht alle Funktionen umgesetzt sind, ist es derzeit noch nicht möglich, die Tabellen zueinander in Beziehung zu setzen. Daher musste das Quellmodell zur vollständigen Beschreibung der Attribute des Zielmodells abgeändert werden. Eine Änderung des Quellmodells sollte eigentlich vermieden werden, es war jedoch für die derzeit machbare Transformation notwendig. Wegen der INSPIRE Kodierungsvorschrift ergab sich der Zwang, bei der Grundstücksnummer den Schrägstrich durch einen Bindestrich zu ersetzen, da der Wertebereich für dieses INSPIRE-Feld keine Schrägstrich zulässt. Abbildung 23 zeigt das abgeändert Quellmodell. In diesem wurden die Tabellen Grundstueck und Einlage_SD miteinander kombiniert. Als eindeutiger Schlüssel dafür diente das Attribut KG_GNR. Seite 62

69 Kapitel 7: Testdatensatz Abbildung 23: geändertes Quellmodell Nach Abänderung des Quellmodells wurde dieses in das von INSPIRE gewünschte Koordinatensystem transformiert. INSPIRE fordert die Abgabe der Daten im Koordinatensystem ETRS89 vor. Diese Koordinatensystem-Transformation wurde mithilfe der ESRI Software ArcGIS durchgeführt. Dabei wurde das von der DKM verwendete Quellkoordinatensystem (MGI/Austria GK Central mit dem EPSG-Code 31255) in das von INSPIRE geforderte Zielkoordinatensystem (ETRS89/UTM zone 33N mit dem EPSG-Code 25833) transformiert. Als Transformationsparameter wurden die Parameter des EPSG-Codes 1619 verwendet. Die durch die vorangegangenen Schritte veränderten Daten der Personal Geodatabase wurden mithilfe der Software FME Translator in eine GML- und XSD-Datei übersetzt. Die XSD-Datei konnte dann im HALE als Schema-Datei für das Quell-Datenmodell und die GML-Datei (im Format GML 3.1.1) als Quelldatensatz importiert werden. Das Zielmodell wurde mit der von INSPIRE zur Verfügung gestellten XSD in das Transformationswerkzeug geladen. In Abbildung 24 werden die Vorarbeiten der Schematransformation veranschaulicht. Seite 63

70 Kapitel 7: Testdatensatz Abbildung 24: Vorarbeiten für die Schematransformation Seite 64

71 Kapitel 7: Testdatensatz 8.2 Österreichweiter Transformationsparametersatz MGI - ETRS89 INSPIRE sieht vor, dass die Daten im ETRS89 Koordinatenreferenzsystem abgegeben werden. Daher wurde der Testdatensatz, wie bereits im Kapitel 8.1 beschrieben, mithilfe von ArcGIS in ETRS89 transformiert. Die genaue Vorgehensweise bzw. der Transformationsprozess wird innerhalb dieser Arbeit nicht untersucht. Vielmehr soll dieser Abschnitt nur die Parameter die für eine solche 7-Parameter Transformation benötigt werden, kurz aufzeigen. In Tabelle 5Tabelle 5 sind die Parameter für die Transformation vom österreichischen Bezugssystem MGI in das europäische Bezugssystem ETRS89, welche ebenfalls vom OGP Geomatics Committee unter dem EPSG-Code 1619 publiziert sind, aufgelistet. Variable Wert Erklärung X 577,326 m Koordinatendifferenz in X Y 90,129 m Koordinatendifferenz in Y Z 463,919 m Koordinatendifferenz in Z α(x) 5,137 Rotation um X-Achse α(y) 1,474 Rotation um Y-Achse α(z) 5,297 Rotation um Z-Achse dm 0, Maßstabsdifferenz zwischen den beiden Systemen Tabelle 5: Transformationsparameter MGI ETRS89 Seite 65

72 Kapitel 9 9. Durchführung der Transformation Bei der hier durchgeführten Transformation handelt es sich um eine semantische Modelltransformation. Diese wird auf der physischen/logischen Ebene durchgeführt. Zum jetzigen Zeitpunkt ist es noch nicht möglich, die Transformation auf konzeptueller Ebene durchzuführen. Wie im Kapitel 7 bereits erwähnt, werden die Schemadateien des Quell- und Zielmodells eingelesen und auf deren Grundlage die Transformationsregel definiert. Die Definition der Transformationsregeln wurde mithilfe der unter Kapitel 9.1 angeführten Verzweigungstabelle erstellt. In dieser Tabelle sind die von INSPIRE geforderten Attribute in der 1. Spalte und die dafür vorgesehenen Attribute des Quellmodells in der 2. Spalte dargestellt. In der 3. Spalte wird angeführt ob, es sich um ein verpflichtendes oder ein nicht verpflichtendes Attribut von INSPIRE handelt. Dabei stellen die verpflichtenden Attribute den kleinsten gemeinsamen Nenner aller Mitgliedsstaaten dar. Für diese Transformation wurden alle Attribute, die zur Verfügung standen verwendet. In Spalte 4 ist nochmals übersichtlich dargestellt welche Attribute im Quellmodell vorhanden sind oder nicht. In der letzten Spalte sind die für die Transformation verwendeten Transformationsfunktionen angeführt. Die hellgrau hinterlegten Zeilen sind Verknüpfungen. Folgende Verknüpfungen sind in den Klassen definiert: BasicPropertyUnit administrativeunit: CadastralBoundary diese Verknüpfung bezieht sich auf die unterste administrative Verwaltungsebene des INSPIRE-Datenthemas Administrative Unit, mit der die Einlagezahl (Basic Property Unit) in Beziehung steht. Dies ist in Österreich die Gemeinde mit ihrer eindeutig definierten Gemeindenummer. Seite 66

73 parcel: damit wird die Verknüpfung (Relation) der Grundstücksgrenze zu einem oder zwei Grundstücke aufgezeigt. Im Quellmodell hat die Grundstücksgrenze keine eigene Identität, wodurch eine Zuordnung der Grundstücksgrenze zu einem Grundstück in dieser Form nicht möglich ist. Es wird daher nur die KG_NR zugewiesen. CadastralParcel administrativeunit: basicpropertyunit: zoning: CadastralZoning upperlevelunit: wie oben diese Verknüpfung ist durch das Attribut GB_EZ erfüllt. Es stellt die Verbindung von Grundbuch und Einlagezahl dar. diese Verknüpfung stellt die Verbindung des Grundstücks zu der Katastralgemeinde dar. Durch das Attribut KG_GNR ist diese Verknüpfung gegeben. diese Relation bezieht sich auf die in der Hierarchie nächst höhere Verwaltungseinheit. Für die Katastralgemeinde ist die nächst höhere Verwaltungseinheit die Gemeinde. Seite 67

74 Kapitel 8: Durchführung der Transformation 9.1 Verzweigungstabelle Gegenüberstellung der INSPIRE-Vorlage Cadastral Parcels mit dem österreichischem Kataster (DKM) [INSPIRE Data Specification on Cadastral Parcels] Land: Österreich Datenbereitsteller: Bundesamt für Eich- und Vermessungswesen Datum: Bestand von räumlichen Attributen und Verknüpfungen M mandatory (verpflichtend) V voidable (nicht verpflichtend) vorhanden nicht vorhanden INSPIRE Elemente DKM Element M/V Bestand HALE Transformationsfunktion BasicPropertyUnit Grundstueck_14168_UTM33 Retype Feature administrativeunit GEMNR V Attribute Rename Function auf Untertyp title areavalue Flaeche_Gst V Attribute Rename Function beginlifespanversion V INSPIRE NilReason Function endlifespanversion V INSPIRE NilReason Function inspireid GB_EZ M INSPIRE Identifier Function nationalcadastralreference GB_EZ M Attribute Rename Function Seite 68

75 Kapitel 8: Durchführung der Transformation validfrom V INSPIRE NilReason Function validto V INSPIRE NilReason Function INSPIRE Elemente DKM Element M/V Bestand HALE Transformationsfunktion CadastralBoundary Grundstueck_14168_UTM33 Retype Feature beginlifespanversion V INSPIRE NilReason Function endlifespanversion V INSPIRE NilReason Function estimatedaccuracy V Default Wert Function geometry SurfaceProperty M Attribute Rename Function inspireid KG_NR M INSPIRE Identifier Function: gibt keine eindeutige lokale ID parcel KG_GNR V Attribute Rename Function auf Untertyp title validfrom V NilReason Function validto V NilReason Function INSPIRE Elemente DKM Element M/V Bestand HALE Transformationsfunktion CadastralParcel Grundstueck_14168_UTM33 Retype Feature administrativeunit GEMNR Attribute Rename Function auf Untertyp title areavalue Flaeche_GST M Attribute Rename Function Seite 69

76 Kapitel 8: Durchführung der Transformation basicpropertyunit GB_EZ V Attribute Rename Function auf Untertyp title beginlifespanversion V NilReason Function endlifespanversion V NilReason Function geometry SurfaceProperty M Attribute Rename Function inspireid KG_GNR M INSPIRE Identifier Function label NUMMER M Attribute Rename Function nationalcadastralzoningreference KG_GNR M Attribute Rename Function referencepoint HOCHWERT RECHTSWERT V Ordinates to Point Geometry Function validfrom V NilReason Function validto V NilReason Function zoning KG_NUMMER V Attribut Rename Function auf Untertyp title INSPIRE Elemente DKM Element M/V Bestand HALE Transformationsfunktion CadastralZoning KG_14168_UTM33 Retype Feature beginlifespanversion V NilReason Function endlifespanversion V NilReason Function estimatedaccuracy Default Value V Default Value: 20 Meter geometry SurfaceProperty M Attribute Rename Function Seite 70

77 Kapitel 8: Durchführung der Transformation inspireid KG_NUMMER M INSPIRE Identifier Function label KGNAME M Attribute Rename Function level Default Value V Attribute Default Value: 2 levelname Default Value V Attribute Default Value: Katastralgemeinde name KGNAME V INSPIRE Geographic Name Function nationalcadastralzoningreference KG_NR M Attribute Rename Function originalmapscaledenominator Default Value V Attribute Default Value: 2000 referencepoint SurfaceProperty V Centroid Function in späteren Datenmodell aber zu berücksichtigen, da vorhanden upperlevelunit GEMNR V Attribute Rename Function validfrom V NilReason Function validto V NilReason Function Tabelle 6: Verzweigungsvorlage [[INS09], verändert] Anhand dieser Verzweigungsvorlage kann man sehen, dass das Datenmodell alle verpflichtenden (mandatory) Attribute beinhaltet. Seite 71

78 Kapitel 8: Durchführung der Transformation 9.2 Validierung der Transformation Dem Transformationswerkzeug wurde während der Erstellung dieser Arbeit eine Validierungsfunktion hinzugefügt. Dabei wird die erstellte Transformationsdatei gegen die Schemadatei des Zielmodells validiert. Eine erfolgreiche Validierung der Transformationsdatei ist für die Weiterverwendung Voraussetzung. 9.3 Fazit Die Implementierung mit dem Humboldt Alignment Editor verlief gut. Die in Tabelle 6 dargestellte Verzweigungstabelle wurde während der Implementierung schrittweise abgearbeitet. Aufgrund der vorhergehenden genauen Analyse traten bei der Erstellung der Transformation keinerlei Probleme auf. Den Attributen beginlifespanversion, endlifespanversion, validfrom und validto wurden jeweils als INSPIRE Nil Reason deklariert. Diesen Attributen konnten keine Werte zugewiesen werden, da keine passenden Attribute im Quellmodell vorhanden sind. Die INSPIRE ID setzt sich wie folgt zusammen: Abbildung 25: Screenshot der Transformationsregel INSPIRE ID in HALE INSPIRE verwendet den im ISO-Standard 3166 definierten zweistelligen Ländercode, der für Österreich mit AT angegeben ist. Der Provider Name wurde, wie in Abbildung 25 ersichtlich, mit BEV angegeben. Dieser Name wird aber, laut einer Konvention von INSPIRE.AT, in Zukunft für jeden Datenprovider eine eindeutig zugeordnete Nummer sein. Da diese Zuordnungsnummer bisher nicht beschlossen wurde konnte diese noch nicht angegeben werden. Der Produkt-Name setzt sich aus dem betroffenen INSPIRE Datenthema (CadastralParcels) und der Objektart (CadastralZoning) zusammen. Die Objektart wird vom Transformationswerkzeug automatisch erkennt und hinzugefügt. Der Produkt Name sollte jedoch auch in Zukunft als Nummer entsprechend seiner Position in der INSPIRE- Seite 72

79 Kapitel 8: Durchführung der Transformation Durchführungsbestimmung angegeben werden. Die sprechende INSPIRE ID würde dann wie in Abbildung 26 aussehen: Abbildung 26: Beispiel des Schemas der INSPIRE ID Das Attribut estimatedaccuracy wurde mit einem default-wert von 20 m angegeben. Dieser Wert gibt den maximalen Fehlerwert des Katasters in Österreich im Hochgebirge an. Bei den Angaben für die default-werte habe ich mich an die für die Metadaten angegebenen Werte gehalten. Bei dem Attribut level, welches die hierarchischen Einheiten des österreichischen Katasters wiedergibt, wurde der Katastralgemeinde der default-wert: 2 zugewiesen. Dadurch ergibt sich, dass das Attribut levelname den default-wert Katastralgemeinde hat. Dem Attribut originalmapscaledenominator, welches den Maßstab angibt, wurde auch der default-wert der in den Metadaten angegeben wurde, zugewiesen. Dieser lautet für die DKM in Österreich 1:2000. Das Attribut referencepoint, welches den Referenzpunkt innerhalb eines Polygons darstellt, wurde in der Klasse CadastralParcels mithilfe des Hoch- und Rechtswertes angegeben. In der Klasse CadastralZoning war dies nicht möglich, weil dazu die Angaben im Quellmodell nicht vorhanden sind. Daher wurde dieser Referenzpunkt mithilfe der Centroid Function erstellt. Diese ermittelt den geometrischen Mittelpunkt der zugrundeliegenden Geometrie. Diese Funktion kann aber nicht auf jedem Datensatz angewendet werden, weil aufgrund der unterschiedlichen geometrischen Formen der Katastralgemeinden der generiert Referenzpunkt nicht immer innerhalb der Katastralgemeindegrenzen zu liegen kommt. In Abbildung 27 sind jeweils ein Beispiel für ein positives (links) sowie ein negatives (rechts) Ergebnis der Centroid-Funktion dargestellt. Seite 73

80 Kapitel 8: Durchführung der Transformation Abbildung 27: Positives (links) und negatives (rechts) Ergebnis einer Centroid-Funktion Da der Referenzpunkt der Katastralgemeinde in der Grundstücksdatenbank vorhanden ist, sollte dieser dem Quellmodell hinzugefügt werden. Dadurch kann dieser Fehler vermieden werden. Der Verknüpfung parcel mit CadastralBoundary wurde das Attribut der Katastralgemeindenummer (KG_NR) zugewiesen. In Zukunft sollte jeder Grundstücksgrenze mithilfe eines Geoinformationssystems z.b. ArcGIS eine eindeutige Identifikation zugewiesen werden. Dann kann die Relation zwischen parcel und CadastralBoundary eindeutig angegeben werden. Dieses Ergebnis sollte durch eine Zwischentabelle dem Datenmodell hinzugefügt werden. Seite 74

81 Kapitel Zusammenfassung Das Thema der semantischen Modelltransformation ist sehr aktuell und bildet auch in der Durchführung der INSPIRE-Richtlinie eine Kernaufgabe. Für die Harmonisierung der unterschiedlichen nationalen Datenmodelle in ein einheitliches INSPIRE-Zielmodell ist eine Modelltransformation unumgänglich. Aufgrund der Aktualität dieses Themas wurden im letzten Jahr immer wieder neue Studien veröffentlicht und auch neue Werkzeuge entwickelt. Um eine solche Transformation gestalten und durchführen zu können, müssen zuerst die Definitionen und die Aufgaben eines Datenmodells greifbar gemacht werden? Welche Informationen sollten darin enthalten sein und wie werden diese beschrieben? Viele Modelle werden heutzutage mittels der Modellierungssprache UML beschrieben. Diese visuelle Form der Modellierung ist auch für nicht Programmierer sehr gut geeignet und leicht verständlich. Jedes Modell hat seine Eigenheiten, die untersucht werden müssen, denn erst wenn das Modell verstanden wird kann mit der Modelltransformation begonnen werden. (Kapitel 2) Bei der Modelltransformation handelt es sich um eine Abbildung des Quellmodells in das gewünschte Zielmodell. Zuerst werden diese beiden Modelle analysiert, anschließend werden mithilfe der definierten Transformationsregeln die Daten des Quellmodells ins Zielmodell transformiert. Aufgrund der genauen Definitionen seitens INSPIRE und der immer aktuellen Veröffentlichung von Spezifikationen sind die Ziele klar abgesteckt. Die Spezifikationen sind sehr umfassend und greifen sehr stark ineinander. Daher ist zu Beginn viel Lesearbeit zu leisten. (Kapitel 3) Die Problematik der Modelltransformation nutzen viele Softwarehersteller um, dafür geeignete Software zu implementieren. Daher ist man mit vielen neuen Transformationswerkzeugen (Kapitel 4) konfrontiert. Das INSPIRE Network Service Drafting Team hat mehrere Tools evaluiert, um Licht in diesen Dschungel zu bringen. In mitten dieser Diplomarbeit ist von INSPIRE ein Prototyp für eine erfolgreiche Durchführung einer solchen Modelltransformation entwickelt und veröffentlicht worden. In Seite 75

82 dieser Veröffentlichung wird die gleiche Software empfohlen, mit der diese Modelltransformation durchgeführt wurde. HALE erfüllt alle Anforderungen, die INSPIRE an ein Transformationswerkzeug stellt. Durch den inkludierten MapView kann sofort überprüft werden, ob die Geometrien richtig abgebildet werden. Durch das Aufgaben- und das Transformationsregelfenster wird ein guter Überblick gegeben, wodurch die einzelnen Schritte auch leicht nachvollziehbar sind. (Kapitel 8) Seite 76

83 Kapitel 10: Zusammenfassung Die tatsächliche Implementierung der Transformation ist durch die intuitiv gestaltete Benutzeroberfläche ohne große Schwierigkeiten durchzuführen. Die erstellte Transformationsdatei wird vor dem tatsächlichen Export validiert. Dabei wird sie auf Konformität gegenüber dem Zielmodell geprüft. Die ausgeführte Transformation wird als Abschluss exportiert. Mithilfe eines Viewers (z.b. Gaia oder GML Viewer) kann die exportierte GML Datei mit allen transformierten und generierten Attributen dargestellt werden kritische Betrachtung Prinzipiell erfüllt das Quellmodell alle geforderten Angaben für das INSPIRE-Datenthema Cadastral Parcels. Vor der tatsächlichen Umsetzung der Modelltransformation für INSPIRE sollte jedoch das Quellmodell noch inhaltlich ergänzt werden, da- soweit dies seitens des Bundesamtes für Eich- und Vermessungswesen gewünscht ist- wesentlich mehr Informationen vom Quellmodell in das Zielmodell übertragen werden könnten. Eine Ergänzung wäre die in Kapitel 9.3 bereits erwähnte Angabe des Referenzpunktes innerhalb der Katastralgemeinde, da dieser, wie in dieser Arbeit mithilfe der Transformationsfunktion Centroid Function erstellte Punkt, nicht für jede Katastralgemeinde generiert werden kann. Sollte eine Katastralgemeinde z.b. die Form eines U darstellen, so führt diese Generierung zu einem falschen Ergebnis. Hierbei handelt es sich nur um eine kleine Ergänzung, die wenig Mehraufwand bedeutet, da diese Information in der Grundstücksdatenbank bereits vorhanden ist. Für die Klasse CadastralBoundary gibt es keine eindeutige lokale ID. In dieser Diplomarbeit wurde dafür die Katastralgemeindenummer (KG_Nr) verwendet. Bei der tatsächlichen Umsetzung sollte daher die Erstellung der ID wie auf Seite 62 beschrieben durchgeführt werden. Durch den zulässigen Wertebereich für INSPIRE musste der Schrägstrich in allen Datensätzen in einen Bindestrich abgeändert werden. Dies muss auf jeden Fall auch bei der tatsächlichen Implementierung beachtet werden. Durch die Abänderung des Schrägstriches in den Daten kann es zu Problemen bei einer möglichen Rückführung kommen. Ein weiterer offener Punkt ist, wie das Transformationswerkzeug Humboldt Alignment Editor mit einer großen Datenmenge umgehen kann. Dahingehend gibt es noch keine aussagekräftigen Informationen. Das Humboldt Team arbeitet stets an einer Verbesserung des Transformationswerkzeuges. Eine Abänderung des Quell-Datenmodells, wie es in dieser Arbeit gemacht werden musste, ist nicht gewünscht. Es sollte lediglich das tatsächlich zugrundeliegende Datenmodell verwendet werden. Daher ist die Funktion, mit der Tabellen in Beziehung gesetzt werden können, essentiell. Die Seite 77

84 Kapitel 10: Zusammenfassung Implementierung dieser Funktion in HALE ist aber nur eine Frage der Zeit Ausblick Mit der Durchführung und der vorhergehenden Untersuchung einer semantischen Modelltransformation für das Bundesamt für Eich- und Vermessungswesen wurde ein weiterer Schritt für eine erfolgreiche INSPIRE-Umsetzung gesetzt. Der nächste Schritt für das BEV wird die tatsächliche Umsetzung der Schematransformation für das Datenthema Cadastral Parcels sein. Im Zuge der Umstellung auf die neue Grundstücksdatenbank (GDB neu) findet eine komplette Überarbeitung des Datenmodells statt. GDB neu entsteht durch eine Kooperation des BEV mit dem Justizministerium. Es ist davon auszugehen, dass das neue Datenmodell wesentlich mehr Informationen hinsichtlich der rechtlichen Sachdaten enthalten wird. Dadurch wird sich das Quell- Datenmodell ändern und die Transformationsregeln erneut definiert werden. Wie die für diese Diplomarbeit durchgeführte Modelltransformation zeigt, ist die Software HALE für die Durchführung einer solchen derzeit noch nicht umfassend geeignet. Erst wenn HALE es ermöglicht, Tabellen in Beziehung zu setzen, kann diese Software als geeignet angesehen werden. Es werden in der nächsten Zeit aber sicher noch weitere Transformationswerkzeuge auf den Markt kommen. Auch die Firma ESRI wird ein solches Werkzeug implementieren. Daran kann gesehen werden, wie aktuell dieses Thema ist und es darf gespannt in die Zukunft geblickt werden. Seite 78

85 Literaturverzeichnis VI [Bar05] Bartelme, Norbert Geoinformatik: Modelle, Strukturen, Funktionen. s.l. : Springer, 4. Auflage, [Bea101] Beare, Matt, Payne, Simon und Sunderland, Richard Prototype Report for the INSPIRE Schema Transformation Network Service [Bea10] Beare, Matthew, et al Development of Technical Guidance fot the INSPIRE Transformation Network Service [BEV10] BEV Bundesamt für Eich- und Vermessungswesen. [Online] [Zitat vom: ] [DUD11] Bibliographisches Institut GmbH Duden. [Online] [Zitat vom: ] [Bor05] Born, Günter Jetzt lerne ich XML. s.l. : Markt + Technik Verlag, [Bre04] Bretterbauer, Kurt und Schuh, Harald Skriptum zur Vorlesung Höhere Geodäsie. Technische Universität Wien : Institut für Geodäsie und Geophysik, [Dee10] Deegree Deegree. [Online] [Zitat vom: ] [Don08] Donaubauer, Andreas, et al Web-basierte Modelltransformation - eine Lösung für INSPIRE. Zeitschrift für Geoinformatik [Eis10] Eisenhut, Claude und Kutzner, Tatjana Vergleichende Untersuchung zur Modellierung und Modelltransformation in der Region Bodensee im Kontext von INSPIRE. München : Technische Universität München, [Ern05] Ernst, Julius Skriptum zur Vorlesung Katasterwesen I. Technischen Universität Wien : Institut für Geoinformation und Kartographie, [FME10] FME FME Server. [Online] [Zitat vom: ] [Fra06] Frank, Andrew U Practical Geometry - The Mathematics for Geographic Information Systems. Skriptum zur Vorlesung GIS Theory. Technische Universität Wien : Institut für Geoinformation und Kartographiee, [GOP11] Go Publisher Snowflake Software: Go Publisher. [Online] [Zitat vom: ] [OMG10] Group, Object Managment OMG. [Online] [Zitat vom: ] [Hin10] Hinterleitner, Rainer und Twaroch, Christoph GeoDIG Geodateninfrastrukturgesetz. s.l. : Neuer wissenschaftlicher Verlag, [Hoc91] Hochwartner, August Digitale Katastralmappe. s.l. : evm- Eich- und Vermessungsmagazin Heft 63, [Hög02] Höggerl, Norbert, et al Realisierung moderner 3-D Referenzsysteme für Wissenschaft und Praxis. Österreichische Zeitschrift für Vermessung und Geoinformation. Heft [Hub06] Hubert, Martin UNIGIS Modul OpenGIS und verteilte Geoinformationsverarbeitung. [Hum11] Humboldt Humboldt Community Project. [Online] [Zitat vom: ]

86 Literaturverzeichnis VII [INS11] INSPIRE INSPIRE. [Online] [Zitat vom: ] [INS09] INSPIRE Thematic Working Group Cadastral Parcels D2.8.I.6 INSPIRE Data Specification on Cadastral Parcels - Guidlines [ISO101] ISO Norm ISO Geographic Information - Reference model. [ISO103] ISO Norm ISO Geographic Information - Conceptual schema language. [ISO105] ISO Norm ISO Geographic Information - Conformance and Testing. [ISO106] ISO Norm ISO Geographic Information - Profiles. [ISO107] ISO Norm ISO Geographic Information - Spatial schema. [ISO108] ISO Norm ISO Geographic Information - Temporal Schema. [ISO109] ISO Norm ISO Geographic Information - Rules for applicationo schema. [ISO110] ISO Norm ISO Geographic Information - Methodology for feature cataloguing. [ISO111] ISO Norm ISO Geographic Information - Spatial referencing by coordinates. [ISO112] ISO Norm ISO Geographic Information - Spatial referencing by geographic identifiers. [ISO113] ISO Norm ISO Geographic Information - Quality principles. [ISO114] ISO Norm ISO Geographic Information - Quality evalutaion procedures. [ISO115] ISO Norm ISO Geographic Information - Metadata. [ISO116] ISO Norm ISO Geographic Information - Positioning services. [ISO128] ISO Norm ISO Geographic Information - Web map server interface. [ISO136] ISO Norm ISO Geographic Information - Geography Markup Language. [ISO071] ISO Norm ISO Geographic Information - Metadata-XML schema implementation. [Jus10] Jusline Österreich Jusline Österreic h. [Online] [Zitat vom: ] [Kar06] Karner, Arnold Model Driven Architecture - Vollständige Codegenerierung mittels AndroMDA, Magisterarbeit. Business Informatics Group : Technische Universität Wien, [Leh01] Lehto, Lassi Real-time Content Transformations in a Web Service-based Delivery Architecture for Geographic Information, Dissertation. s.l. : Helsinki University of Technology, [Nav06] Navratil, Gerhard Skriptum zur Vorlesung Ausgleichsrechnung II. Technische Universität Wien : Institut für Geoinformation, [Pet06] Petrasch, Roland und Meimberg, Oliver Model Driven Architecture: Eine praxisorientierte Einfürhung in die MDA. s.l. : Dpunkt. Verlag, [Rei10] Reitz, Thorsten und Templer, Simon Humbodlt Alignment Editor Manual. s.l. : [Rie08] Riedl, Doris und Riedl, Andreas Skriptum zur Vorlesung Einführung in die Geoinformation. Universität Wien : Institut für Geographie und Regionalforschung, [RTG10] RTG Semantische Datenmodellierung im Kontext von INSPIRE, Ergebnisse des Expertenworkshops des Runden Tisches GIS e.v.. Technischen Universität München : Runder Tisch

87 Literaturverzeichnis VIII GIS e.v, [Sta73] Stachowiak, Herbert Allgemeine Modelltheorie. s.l. : Springer, [Sta09] Staub, Peter Über das Potenzial und die Grenzen der semantischen Interoperabilität von Geodaten, Dissertation. s.l. : ETH Zürich, [Ste09] Steinpichler, Dietmar Projektabwicklung mit UML und Enterprise Architect. s.l. : SparxSystems Software; Auflage: 7.5, [W3C10] W3C World Wide Web Consortium. [Online] [Zitat vom: ] [Wik10] Wikipedia Wikipedia - Query/View/Transform. [Online] [Zitat vom: ] [Xtr10] XtraServer XtraServer. [Online] [Zitat vom: ]

88 Abbildungsverzeichnis VIII Abbildung 1: Zusammenhang zwischen Realität und Modell... 6 Abbildung 2: Übergang vom Universe of Discourse zum konzeptuellen Schema... 8 Abbildung 3: Modellierung... 9 Abbildung 4: MDA-Modell Abbildung 5: MDA Architektur Abbildung 6: MDA 4-Schichten-Architektur Abbildung 7: UML Abbildung 8: Modellbasierter Ansatz Abbildung 9: Grundlegendes Konzept der Modelltransformation Abbildung 10: Ebenen der Modelltransformation Abbildung 11: Probleme bei der semantischen Transformation Abbildung 12: Schnittmenge zweier Datenmodelle Abbildung 13: Quellmodell im Kontext von DKM und GDB Abbildung 14: Bezugsmeridiane M28, M31 und M Abbildung 15: Quellmodell Abbildung 16: KG_GNR Abbildung 17: Gemeindekennziffer Abbildung 18: Hierarchie Übersicht Abbildung 19: Zielmodell Cadastral Parcels Abbildung 20: Screenshot des Transformationswerkzeugs HALE Abbildung 21: Ein- und Ausgabe Formate von HALE Abbildung 22: Bildausschnitt aus dem BEV Shop der KG Abbildung 23: geändertes Quellmodell Abbildung 24: Vorarbeiten für die Schematransformation Abbildung 25: Screenshot der Transformationsregel INSPIRE ID in HALE Abbildung 26: Beispiel des Schemas der INSPIRE ID Abbildung 27: Positives (links) und negatives (rechts) Ergebnis einer Centroid-Funktion Abbildung 28: Mind Map für Cadastral Parcels... XXVI Abbildung 29: Mapping Grundstueck_14168_UTM - BasicPropertyUnit... XXVII Abbildung 30: Mapping Grundstueck_14168_UTM33 - CadastralBoundary... XXVII Abbildung 31: Mapping KG_14168_UTM33 - CadastralZoning... XXVIII Abbildung 32: Mapping Grundstueck_14168_UTM33 - CadastralParcels... XXIX Abbildung 33: Screenshot Attribute CadastralParcels... XXX Abbildung 34: Screenshot Attribute CadastralZoning... XXX

89 Tabellenverzeichnis IX Tabelle 1: Überblick Transformationssprachen Tabelle 2: Transformationswerkzeuge Tabelle 3: MGI / Austria GK Central Tabelle 4: ETRS 89 / UTM zone 33N Tabelle 5: Transformationsparameter MGI ETRS Tabelle 6: Verzweigungsvorlage Tabelle 7: Grundstueck Einlagezahl...XV Tabelle 8: Katastralgemeinde...XVII Tabelle 9: Basic Property Unit...XIX Tabelle 10: Cadastral Boundary...XX Tabelle 11: Cadastral Parcel...XXII Tabelle 12: Cadastral Zoning... XXV

90 Anhang X I. Detaillierte tabellarische Beschreibung des Quellmodells Der Aufbau des Datenmodells wird hier mit einem Grundstück.5/1 als Beispielgrundstück aus der Katastralgemeinde Umbach verdeutlicht. Die für die Transformation nicht verwendeten Attribute sind mit grauer Schriftfarbe dargestellt. Grundstueck OBJECTID Shape KG_NUMMER MERIDIAN KG_GNR NUMMER BAUFLAECHE Datentyp: Object ID Definition: fortlaufende Nummer Datentyp: Geometry Geometrietyp: Polygon darf 0 sein: Ja Datentyp: Text Definition: Nummer der Katastralgemeinde Länge: 5 darf 0 sein: Nein Beispiel: Datentyp: Short Integer Definition: Meridianbezeichnung darf 0 sein: Nein Beispiel: 34 Datentyp: Text Definition: Grundstücksnummer mit Nummer der Katastralgemeinde Länge: 17 darf 0 sein: Nein Beispiel: Datentyp: Text Definition: Grundstücknummer Länge: 12 darf 0 sein: Nein Beispiel:.5-1

91 Anhang XI Datentyp: Short Integer Definition: beschreibt ob es sich bei dem Grundstück um eine Baufläche handelt darf 0 sein: Nein Beispiel: 1 wird als (Punkt) dargestellt und bedeutet, dass es sich um eine Baufläche handelt STAMMNUMMER Datentyp: Long Integer Definition: Stammnummer der Grundstücksnummer darf 0 sein: Nein Beispiel: 5 UNTERTEILUNGSNUMMER Datentyp: Long Integer Definition: Unterteilungsnummer der Grundstücksnummer Länge: 4 darf 0 sein: Ja Beispiel: 1 AUSPRAEGUNG Datentyp: Long Integer Definition: beschreibt die Beschriftung 1 einzeilige Grundstücksnummer 2 zweizeilige Grundstücksnummer 3 Pfeilnummer darf 0 sein: Ja Beispiel: 3 RECHTSSTATUS Datentyp: Text Definition: beschreibt den Rechtsstatus des Grundstücks E Grundsteuerkataster G Grenzkataster Länge: 1 darf 0 sein: Nein Beispiel: E ANLEGUNGSMASSSTAB Datentyp: Long Integer Definition: Maßstab 1 1: : :5000

92 Anhang XII darf 0 sein: Nein Beispiel: 1 RECHTSWERT Datentyp: Double Definition: Y-Koordinate darf 0 sein: Nein Beispiel: ,062 HOCHWERT Datentyp: Double Definition: X- Koordinate darf 0 sein: Nein Beispiel: ,524 ROTATION Datentyp: Double Definition: Grundstücksnummer wird in diesem Rotationswinkel angezeigt darf 0 sein: Nein Beispiel: 0 RW_OFFSET Datentyp: Double Definition: Die Grundstücksnummer wird mit einer Referenzierung (Punktkoordinate), die innerhalb des Grundstücks liegt, positioniert. Die Grundstücksnummer wird in der DKM vom Referenzpunkt aus gesehen um diesen Rechtswert verschoben angezeigt. darf 0 sein: Nein Beispiel: 9,918 HW_OFFSET Datentyp: Double Definition: Die Grundstücksnummer wird mit einer Referenzierung (Punktkoordinate), die innerhalb des Grundstücks liegt, positioniert. Die Grundstücksnummer wird in der DKM vom Referenzpunkt aus gesehen um diesen Hochwert verschoben angezeigt. darf 0 sein: Nein Beispiel: 3,381 ROTATION_ARROW Datentyp: Double Definition: Rotation des Pfeils, der bei einer zu kleinen Geometrie auf das Zentrum des Grundstücks weist

93 Anhang XIII GEMNR BEZNR LNDNR VANR KGNAME GEMNAME BEZNAME darf 0 sein: Nein Beispiel: 198,824 Datentyp: Long Integer Definition: Gemeindekennziffer darf 0 sein: Ja Beispiel: Datentyp: Short Integer Definition: Bezirkskennziffer darf 0 sein: Ja Beispiel: 315 Datentyp: Short Integer Definition: Bundeslandkennziffer darf 0 sein: Ja Beispiel: 3 Datentyp: Text Definition: Vermessungsamtsnummer Länge: 2 darf 0 sein: Ja Beispiel: 19 Datentyp: Text Definition: Katastralgemeindename Länge: 32 darf 0 sein: Ja Beispiel: Umbach Datentyp: Text Definition: Gemeindename Länge: 32 darf 0 sein: Ja Beispiel: Dunkelsteinerwald Datentyp: Text Definition: Bezirksname Länge: 32 darf 0 sein: Ja

94 Anhang XIV LNDNAME VANAME Shape_Length Shape_Area Beispiel: Melk Datentyp: Text Definition: Bundeslandname Länge: 16 darf 0 sein: Ja Beispiel: Niederösterreich Datentyp: Text Definition: Name des Vermessungsamts Länge: 50 darf 0 sein: Ja Beispiel: St.Pölten Datentyp: Double Definition: Länge darf 0 sein: Ja Beispiel: 30, Datentyp: Double Definition: Fläche darf 0 sein: Ja Beispiel: 39, Grundstueck_EZ Beinhaltet die Sachdaten das Grundstück betreffend. OBJECTID Nummer Flaeche_Gst Datentyp: Definition: Datentyp: Definition: Object ID fortlaufende Nummer Text Länge: 255 darf 0 sein: Grundstücksnummer Nein Beispiel:.5-1 Datentyp: Definition: Long Integer Fläche des Grundstücks

95 Anhang XV Grundbuch Einlage KG_NR KG_GNR GB_EZ darf 0 sein: Nein Beispiel: 40 Datentyp: Text Definition: Grundbuchsnummer darf 0 sein: Nein Beispiel: Datentyp: Text Definition: Einlagezahl Länge: 255 darf 0 sein: Nein Beispiel: 8 Datentyp: Text Definition: Nummer der Katastralgemeinde Länge: 5 darf 0 sein: Nein Beispiel: Datentyp: Text Definition: Grundstücksnummer mit Nummer der Katastralgemeinde Länge: 17 darf 0 sein: Nein Beispiel: Datentyp: Text Definition: Grundbuch in Verbindung mit der Einlagezahl darf 0 sein: Nein Beispiel: Tabelle 7: Grundstueck Einlagezahl KG Beinhaltet die Daten die Katastralgemeinde betreffend. OBJECTID Datentyp: Definition: Object ID fortlaufende Nummer

96 Anhang XVI Shape KG_NUMMER MERIDIAN GEMNR BEZNR LNDNR VANR KGNAME Datentyp: Geometry Geometrietyp: Polygon darf 0 sein: Ja Datentyp: Text Definition: Nummer der Katastralgemeinde Länge: 5 darf 0 sein: Nein Beispiel: Datentyp: Short Integer Definition: Meridianbezeichnung darf 0 sein: Nein Beispiel: 34 Datentyp: Long Integer Definition: Gemeindekennziffer darf 0 sein: Ja Beispiel: Datentyp: Short Integer Definition: Bezirkskennziffer darf 0 sein: Ja Beispiel: 315 Datentyp: Short Integer Definition: Bundeslandkennziffer darf 0 sein: Ja Beispiel: 3 Datentyp: Text Definition: Vermessungsamtsnummer Länge: 2 darf 0 sein: Ja Beispiel: 19 Datentyp: Text Definition: Katastralgemeindename Länge: 32

97 Anhang XVII GEMNAME BEZNAME LNDNAME VANAME Shape_Length Shape_Area darf 0 sein: Ja Beispiel: Umbach Datentyp: Text Definition: Gemeindename Länge: 32 darf 0 sein: Ja Beispiel: Dunkelsteinerwald Datentyp: Text Definition: Bezirksname Länge: 32 darf 0 sein: Ja Beispiel: Melk Datentyp: Text Definition: Bundeslandname Länge: 16 darf 0 sein: Ja Beispiel: Niederösterreich Datentyp: Text Definition: Name des Vermessungsamts Länge: 50 darf 0 sein: Ja Beispiel: St.Pölten Datentyp: Double Definition: Länge darf 0 sein: Ja Beispiel: 30, Datentyp: Double Definition: Fläche darf 0 sein: Ja Beispiel: 39, Tabelle 8: Katastralgemeinde

98 Anhang XVIII II. Detaillierte tabellarische Beschreibung des Zielmodells Angaben welche aufgrund von fehlenden Daten nicht gemacht werden können werden mit grauer Schrift versehen. BasicPropertyUnit Attribute areavalue Datentyp: Area Definition: im Grundbuch nachgewiesene Fläche Bestand: vorhanden Quellmodell: Flaeche_Gst beginlifespanversion Datentyp: DateTime Definition: Datum und Zeitpunkt zu welchem diese Version der EZ im Geodatensatz eingefügt oder verändert wurde Bestand: nicht vorhanden endlifespanversion Datentyp: DateTime Definition: Datum und Zeitpunkt, zu welchem diese Version der EZ ersetzt oder entfernt wurde Beispiel: nicht vorhanden inspireid Datentyp: Identifier Definition: Externer Objektidentifikator Beispiel: wird generiert nationalcadastralreference Datentyp: CharacterString Definition: Einlagezahl im nationalen Kontext bestehend aus KG_NR und EZ Beispiel: vorhanden Quellmodell: KG_NR + EZ validfrom Datentyp: DateTime Definition: Datum und Zeitpunkt an dem die EZ rechtswirksam festgelegt wurde Beispiel: nicht vorhanden

99 Anhang XIX validto administrativeunit areavalueuom endlifespanversion validto Datentyp: DateTime Definition: Datum und Zeitpunkt an dem die EZ rechtswirksam aufgehoben wurde Verbindung (association) Verbindungsart: Die in der Hierarchie am niedrigsten administrative Einheit, welche die Einlagezahl enthält Quellmodell: GEMNR Bedingungen (constraints) Bedingungsart: die Flächenangabe muss in m² erfolgen Bedingungsart endlifespanversion muss später als beginlifespanversion sein Bedingungsart: validto muss gleich oder später als validfrom sein Tabelle 9: Basic Property Unit CadastralBoundary beginlifespanversion endlifespanversion estimatedaccuracy Attribute Datentyp: DateTime Definition: Datum und Zeitpunkt, zu dem diese Version der Grundstücksgrenze in die DKM eingefügt oder verändert wurde Bestand: nicht vorhanden Datentyp: DateTime Definition: Datum und Zeitpunkt, zu dem diese Version der Grundstücksgrenze in der DKM entfernt wurde Beispiel: nicht vorhanden Datentyp: Length Definition: Die zu erwartende abgeschätzte absolute Positionsgenauigkeit im verwendeten INSPIRE- Koordinatenreferenzsystem Bestand: vorhanden Quellmodell: Default Wert: 20

100 Anhang XX geometry Datentyp: GM_Curve Definition: Geometrie der Grundstücksgrenze Bestand: vorhanden inspireid Datentyp: Identifier Definition: Externer Objektidentifikator Beispiel: wird generiert validfrom Datentyp: DateTime Definition: offizielles Datum und Zeitpunkt an dem die Grundstücksgrenze rechtswirksam festgelegt wurde Beispiel: nicht vorhanden validto Datentyp: DateTime Definition: Datum und Zeitpunkt an dem die Grundstücksgrenze rechtswirksam gelöscht wurde Beispiel: nicht vorhanden Verbindung (association) parcel Verbindungsart: Das Grundstück welches zu der Grundstücksgrenze gehört Quellmodell: KG_NR Bedingungen (constraints) endlifespanversion Bedingungsart endlifespanversion muss später als beginlifespanversion sein estimatedaccuracyuom Bedingungsart der Wert der Genauigkeit muss in m (Meter) angegeben werden validto Bedingungsart: validto muss gleich oder später als validfrom sein Tabelle 10: Cadastral Boundary CadastralParcel areavalue Datentyp: Attribute Area

101 Anhang XXI Definition: Bestand: Quellmodell: beginlifespanversion Datentyp: Definition: Bestand: endlifespanversion Datentyp: Definition: Beispiel: geometry Datentyp: Definition: Beispiel: inspireid Datentyp: Definition: Beispiel: label Datentyp: Definition: Beispiel: Quellmodell: nationalcadastralreference Datentyp: Definition: Beispiel: Quellmodell: referencepoint Datentyp: Definition: Beispiel: Quellmodell: offizielle Flächenangabe des Grundstücks laut Grundstücksdatenbank (GDB) vorhanden Flaeche_Gst DateTime Datum und Zeitpunkt zu welchem diese Version des Grundstücks in die DKM eingefügt oder verändert wurde nicht vorhanden DateTime Datum und Zeitpunkt zu dem diese Version des Grundstückes in der DKM ersetzt oder entfernt wurde nicht vorhanden GM_Object Geometrie des Grundstücks vorhanden Identifier Externer Objektidentifikator wird generiert CharacterString Nummer des Grundstücks vorhanden NUMMER CharacterString Nummer des Grundstücks im Kontext mit dem nationalen Code vorhanden KG_GNR GM_Point Referenzpunkt innerhalb des Grundstücks vorhanden RECHTSWERT / HOCHWERT

102 Anhang XXII validfrom validto administrativeunit basicpropertyunit zoning areavalueuom endlifespanversion geometrytype validto Datentyp: DateTime Definition: offizielles Datum und Zeitpunkt an dem das Grundstück rechtswirksam festgelegt wurde Beispiel: nicht vorhanden Datentyp: DateTime Definition: Datum und Zeitpunkt an dem das Grundstück offiziell rechtswirksam aufgehoben wurde Beispiel: nicht vorhanden Verbindung (association) Verbindungsart: Die in der Hierarchie am niedrigsten administrative Einheit, welche dieses Grundstück enthält Quellmodell: GEMNR Verbindungsart: Die Einlagezahl welche dieses Grundstück enthält Quellmodell: KG_NR+EZ Verbindungsart: Die Katastralgemeinde, welche dieses Grundstück enthält Quellmodell: KG_NR Bedingungen (constraints) Bedingungsart: die Flächenangabe muss in m² erfolgen Bedingungsart endlifespanversion muss später als beginlifespanversion sein Bedingungsart: der Geometrietyp muss GM_Surface oder GM_MultiSurface sein Bedingungsart: validto muss gleich oder später als validfrom sein Tabelle 11: Cadastral Parcel CadastralZoning beginlifespanversion Attribute

103 Anhang XXIII endlifespanversion estimatedaccuracy geometry inspireid label level Datentyp: DateTime Definition: Datum und Zeit zu welchem diese Version der Katastralgemeinde in die DKM eingefügt oder verändert wurde Bestand: nicht vorhanden Datentyp: DateTime Definition: Datum und Zeitpunkt zu dem diese Version der Katastralgemeinde in der DKM ersetzt oder entfernt wurde Bestand nicht vorhanden Datentyp: Length Definition: Die zu erwartende abgeschätzte absolute Positionsgenauigkeit im verwendeten INSPIRE- Koordinatenreferenzsystemn Bestand: vorhanden Quellmodell: Defaultwert: 20 Meter Datentyp: GM_MultiSurface Definition: Geometrie der KG Bestand: vorhanden Datentyp: Identifier Definition: Externer Objektindentifikator Bestand wird generiert Datentyp: CharacterString Definition: Name der Katastralgemeinde Bestand: vorhanden Quellmodell: KGNAME Datentyp: CadastralZoningLevelValue Definition: Ebene der KG in der Hierarchie des österreichischen Katasters 1 Gemeinde 2 Katastralgemeinde 3 gibt es in Österreich nicht Bestand: vorhanden Quellmodell: Defautlwert: 2

104 Anhang XXIV levelname Datentyp: LocalisedCharacterString Definition: Name der Ebene Bestand: vorhanden Quellmodell: Defaultwert: Katastralgemeinde name Datentyp: GeographicalName Definition: Name der Katastralgemeinde (deckt sich in Österreich mit dem oben angeführten Attribut label) Bestand: vorhanden Quellmodell: KGNAME nationalcadastralzoningreference Datentyp: CharacterString Definition: Nummer der Katastralgemeinde Bestand: vorhanden Quellmodell: KG_NR originalmapscaledenominator Datentyp: Integer Definition: Maßsta bszahl der Original-Papiermappe Bestand: vorhanden Quellmodell: Defaultwert: 1:2000 referencepoint Datentyp: GM_Point Definition: Referenzpunkt innerhalb der KG Bestand: nicht vorhanden, wird aber mit Centroid Function generiert validfrom Datentyp: DateTime Definition: offizielles Datum und Zeit an dem die KG rechtswirksam festgelegt wurde Bestand: nicht vorhanden validto Datentyp: DateTime Definition: Datum und Zeit an dem die KG rechtswirksam aufgehoben wurde Bestand: nicht vorhanden Verbindung (association) upperlevelunit

105 Anhang XXV Verbindungsart: Die nächste in der Hierarchie übergeordnete administrative Einheit, welche diese Katastralgemeinde enthält Quellmodell: GEMNR Bedingungen (constraints) endlifespanversion Bedingungsart: endlifespanversion muss später als beginlifespanversion estimatedaccuracyuom Bedingungsart der Wert der Genauigkeit muss in m (Meter) angegeben sein validto Bedingungsart: validto muss gleich oder später als validfrom sein zoninglevelhierachy Bedingungsart: Ein Katasterbezirk einer niedrigeren Ebene muss Teil eines Katasterbezirks einer höheren Ebene sein Tabelle 12: Cadastral Zoning

106 Anhang XXVI III. Mind Map für Cadastral Parcels Abbildung 28: Mind Map für Cadastral Parcels

107 Anhang XXVII IV. Durchgeführte Transformation Grundstueck_14168_UTM33 BasicPropertyUnit Abbildung 29: Mapping Grundstueck_14168_UTM - BasicPropertyUnit Grundstueck_14168_UTM33 CadastralBoundary Abbildung 30: Mapping Grundstueck_14168_UTM33 - CadastralBoundary KG_14168_UTM33 CadastralZoning

108 Anhang XXVIII Abbildung 31: Mapping KG_14168_UTM33 - CadastralZoning Grundstueck_14168_UTM33 CadastralParcel

109 Anhang XXIX Abbildung 32: Mapping Grundstueck_14168_UTM33 - CadastralParcels