Mit dem Übergang von bauwerksorientierter zu prozessorientierter Arbeitsweise erlangt die domänenübergreifende Bereitstellung von Informationen wachsende Bedeutung. Das betrifft bspw. die Erstellung von Controlling-Kennwerten, die Vorbereitung von Simulationen oder die Betrachtung neuer Aspekte wie Energieeffizienz. Aktuelle Datenformate und Erschließungsmethoden können diese Herausforderung jedoch nicht befriedigend bewältigen. Daher bedarf es einer Methode, welche interdisziplinäre Bauinformationsprozesse uneingeschränkt ermöglicht. Vorhandene Kommunikationsprozesse und Fachanwendungen sollen dabei beibehalten und weitergenutzt werden können. Mit der Multimodell-Methode wird ein Lösungsansatz für die strukturellen Probleme interdisziplinärer Bauinformationsprozesse vorgestellt. Multimodelle bündeln heterogene Fachmodelle unterschiedlicher Domänen und erlauben die Verbindung ihrer Elemente in externen, ID-basierten Linkmodellen. Da die Fachmodelle unberührt bleiben, wird auf diesem Weg eine lose und temporäre Kopplung ermöglicht. Durch den Verzicht auf ein führendes oder integrierendes Datenschema werden keine Transformationsprozesse benötigt, können etablierte und heute übliche Datenformate weitergenutzt und die verlinkten Fachmodelle neutral ausgetauscht werden. Die in Multimodellen verknüpften Daten bieten einen informationellen Mehrwert gegenüber alleinstehenden Fachmodellen. Zusammengehörende Informationen können über die persistenten Links automatisch ausgewertet werden, anstelle manuell vom Menschen immer wieder flüchtig neu zugeordnet werden zu müssen. Somit erscheint ein Multimodell gegenüber einem Benutzer wie ein einziger abgeschlossener Informationsraum. Um solche datenmodell-, datenformat- und domänenübergreifenden Informationsräume komfortabel erstellen und filtern zu können, wird die deklarative Multimodell-Abfragesprache MMQL eingeführt. Diese erlaubt einen generischen Zugriff auf die Originaldaten und bildet die Kernkonzepte der Multimodell-Erschließung - mehrwertige Linkerzeugung und strukturelle Linksemantik - ab. Ein zugehöriger Interpreter ermittelt den Lösungsweg für konkrete Anweisungen und führt diesen auf realen Daten aus. Die Umsetzung und Bereitstellung der Konzepte als IT-Komponenten auf verschiedenen Ebenen - von der Datenstruktur über Bibliotheken und Services bis hin zur alleinstehenden, universellen Multimodell-Software M2A2 - erlaubt die sofortige und direkte Anwendung der Multimodell-Methode in der Praxis.:1. Einleitung 1 1.1. Motivation 1 1.2. Ausgangspunkt 2 1.3. Zielsetzung 3 1.4. Lösungsansatz 5 1.5. Aufbau der Arbeit 7 2. Informationsräume im Bauwesen 9 2.1. Grundlagen der Datenmodelle 10 2.2. Baufachmodelle 17 2.3. Domänenübergreifende Bauinformationsräume 25 2.4. Resümee 39 3. Das Multimodellkonzept 41 3.1. Das Multimodell-Paradigma 42 3.2. Multimodellbasierte Arbeitsweise 48 3.3. Prinzip und Aufbau von Multimodellen 55 3.4. Anwendbare Fachmodelle 67 3.5. Multimodell-Spezialisierung 72 3.6. Multimodell-Operationen 78 3.7. Resümee 81 4. Die Multimodell-Abfragesprache MMQL 83 4.1. Konzeption 84 4.2. Zugriff auf Originaldaten 90 4.3. Multimodell-Filtern 102 4.4. Linkmanipulation 118 4.5. Resümee 124 5. Interpretation von MMQL-Anweisungen 127 5.1. Grundlagen der Ausführung der Sprache 128 5.2. Ermittlung von Multimodell-Views 134 5.3. Links erstellen 148 5.4. Links löschen 153 5.5. Diskussion und Resümee 153 6. Implementierung und Anwendung 159 6.1. Universelle Multimodell-Software M2A2 160 6.2. Multimodell-Spezialisierung für das Bauprojektmanagement 165 6.3. Multimodellbasierte Ermittlung von Zahlungsplänen 167 6.4. Bewertung und Resümee 174 7. Fazit 177 7.1. Zusammenfassung 177 7.2. Ergebnisdiskussion 178 7.3. Ausblick 183 A. Datenmodelle und Spezifikationen 185 A.1. Das Generische Multimodell 185 A.2. Fachmodell Dokumentencontainer 187 A.3. MMQL: Formale Sprachbeschreibung 188 B. Elementarmodell-Vokabulare 191 B.1. Domain 191 B.2. Phase 192 B.3. Level of Detail 196 B.4. Status 196 C. Implementierungsdetails 197 C.1. Liste der in M2A2 implementierten Baufachmodelle 197 C.2. Implementierte Erweiterungen der M2A2-Plattform 198 C.3. XML-Schema des Mefisto-Multimodell-Containers 199 Literaturverzeichnis 201 / With the transition of building-oriented to process-oriented work, the provision of cross-domain information gained growing importance - for example in the creation of controlling parameters, the preparation of simulations or when considering new aspects such as energy efficiency. However, current data formats and access methods cannot cope with this challenge satisfactory. Therefore, a method is required, that enables interdisciplinary construction information processes fully. Thereby existing communication processes and domain applications have to be retained and continued to be used as possible. With the multi-model method, an approach to structural problems of such interdisciplinary construction information processes is presented. Multi-models combine heterogeneous models of different domains and allow the connection of their elements in external ID-based link models. As the domain models remain unaffected, a loose and temporary coupling is possible in this way. By not using a leading or integrating data schema, no transformation processes are required, common established data formats can be retained and the linked domain models can be exchanged neutrally. The linked data in multi-models offer an additional value of information over single domain models. Information belonging together can be automatically evaluated by the persistent links - instead of being repeatedly reassigned by people in a volatile way. Thus, a multi-model appears to a user as a single self-contained information space. In order to create and filter such cross-format and cross-domain information spaces comfortably, the declarative multi-model query language MMQL is introduced. It allows for generic access to the original data and integrates the core concepts of the multi-model development - n-ary link generation and structural link semantics. An associated interpreter determines the approach for specific instructions and executes it on real data. The implementation and deployment of the concepts as IT components at various levels - from the data structure via libraries and services, to the universal multi-model software M2A2 - allows an immediate and direct application of the multi-model method in practice.:1. Einleitung 1 1.1. Motivation 1 1.2. Ausgangspunkt 2 1.3. Zielsetzung 3 1.4. Lösungsansatz 5 1.5. Aufbau der Arbeit 7 2. Informationsräume im Bauwesen 9 2.1. Grundlagen der Datenmodelle 10 2.2. Baufachmodelle 17 2.3. Domänenübergreifende Bauinformationsräume 25 2.4. Resümee 39 3. Das Multimodellkonzept 41 3.1. Das Multimodell-Paradigma 42 3.2. Multimodellbasierte Arbeitsweise 48 3.3. Prinzip und Aufbau von Multimodellen 55 3.4. Anwendbare Fachmodelle 67 3.5. Multimodell-Spezialisierung 72 3.6. Multimodell-Operationen 78 3.7. Resümee 81 4. Die Multimodell-Abfragesprache MMQL 83 4.1. Konzeption 84 4.2. Zugriff auf Originaldaten 90 4.3. Multimodell-Filtern 102 4.4. Linkmanipulation 118 4.5. Resümee 124 5. Interpretation von MMQL-Anweisungen 127 5.1. Grundlagen der Ausführung der Sprache 128 5.2. Ermittlung von Multimodell-Views 134 5.3. Links erstellen 148 5.4. Links löschen 153 5.5. Diskussion und Resümee 153 6. Implementierung und Anwendung 159 6.1. Universelle Multimodell-Software M2A2 160 6.2. Multimodell-Spezialisierung für das Bauprojektmanagement 165 6.3. Multimodellbasierte Ermittlung von Zahlungsplänen 167 6.4. Bewertung und Resümee 174 7. Fazit 177 7.1. Zusammenfassung 177 7.2. Ergebnisdiskussion 178 7.3. Ausblick 183 A. Datenmodelle und Spezifikationen 185 A.1. Das Generische Multimodell 185 A.2. Fachmodell Dokumentencontainer 187 A.3. MMQL: Formale Sprachbeschreibung 188 B. Elementarmodell-Vokabulare 191 B.1. Domain 191 B.2. Phase 192 B.3. Level of Detail 196 B.4. Status 196 C. Implementierungsdetails 197 C.1. Liste der in M2A2 implementierten Baufachmodelle 197 C.2. Implementierte Erweiterungen der M2A2-Plattform 198 C.3. XML-Schema des Mefisto-Multimodell-Containers 199 Literaturverzeichnis 201

The Tibetan Plateau with an extent of about 2,5 million square kilometers at an average altitude higher than 4,700 meters has a significant impact on the Asian monsoon and regulates with its snow and ice reserves the upstream headwaters of seven major south-east Asian rivers. Upon the water supply of these rivers depend over 1,4 billion people, the agriculture, the economics, and the entire ecosystem in this region. As the increasing number of floods and droughts show, these seasonal water reserves however are likely to be influenced by climate change, with negative effects for the downstream water supply and subsequently the food security. The international cooperation project CEOP-AEGIS – funded by the European Commission under the Seventh Framework Program – aims as a result to improve the knowledge of the hydrology and meteorology of the Qinghai-Tibetan Plateau to further understand its role in climate, monsoon and increasing extreme meteorological events. Within the framework of this project, a large variety of earth observation datasets from remote sensing products, model outputs and in-situ ground station measurements are collected and evaluated. Any foreground products of CEOP-AEGIS will have to be made available to the scientific community by an online data repository which is a contribution to the Global Earth Observation System of Systems (GEOSS). The back-end of the CEOP-AEGIS Data Portal relies on a Dapper OPeNDAP web server that serves data stored in the NetCDF file format to a DChart client front-end as web-based user interface. Data from project partners are heterogeneous in its content, and also in its type of storage and metadata description. However NetCDF project output data and metadata has to be standardized and must follow international conventions to achieve a high level of interoperability. Out of these needs, the capabilities of NetCDF, OPeNDAP, Dapper and DChart were profoundly evaluated in order to take correct decisions for implementing a suitable and interoperable NetCDF data model for CEOP-AEGIS data that allows a maximum of compatibility and functionality to OPeNDAP and Dapper / DChart as well. This NetCDF implementation is part of a newly developed upstream data interface that converts and aggregates heterogeneous input data of project partners to standardized NetCDF datasets, so that they can be feed via OPeNDAP to the CEOP-AEGIS Data Portal based on the Dapper / DChart technology. A particular focus in the design of this data interface was set to an intermediate data and metadata representation that easily allows to modify its elements with the scope of achieving standardized NetCDF files in a simple way. Considering the extensive variety and amount of data within this project, it was essential to properly design a data interface that converts heterogeneous input data of project partners to standardized and aggregated NetCDF output files in order to ensure maximum compatibility and functionality within the CEOP-AEGIS Data Portal and subsequently interoperability within the scientific community. / Das Hochplateau von Tibet mit einer Ausdehnung von 2.5 Millionen Quadratkilometer und einer durchschnittlichen Höhe von über 4 700 Meter beeinflusst wesentlich den asiatischen Monsun und reguliert mit seinen Schnee- und Eisreserven den Wasserhaushalt der Oberläufe der sieben wichtigsten Flüsse Südostasiens. Von diesem Wasserzufluss leben 1.4 Milliarden Menschen und hängt neben dem Ackerbau und der Wirtschaft das gesamte Ökosystem in dieser Gegend ab. Wie die zunehmende Zahl an Dürren und Überschwemmungen zeigt, sind diese jahreszeitlich beeinflussten Wasserreserven allen Anscheins nach vom Klimawandel betroffen, mit negativen Auswirkungen für die flussabwärts liegenden Stromgebiete und demzufolge die dortige Nahrungsmittelsicherheit. Das internationale Kooperationsprojekt CEOP-AEGIS – finanziert von der Europäischen Kommission unter dem Siebten Rahmenprogramm – hat sich deshalb zum Ziel gesetzt, die Hydrologie und Meteorologie dieses Hochplateaus weiter zu erforschen, um daraus seine Rolle in Bezug auf das Klima, den Monsun und den zunehmenden extremen Wetterereignissen tiefgreifender verstehen zu können. Im Rahmen dieses Projektes werden verschiedenartigste Erdbeobachtungsdaten von Fernerkundungssystemen, numerischen Simulationen und Bodenstationsmessungen gesammelt und ausgewertet. Sämtliche Endprodukte des CEOP-AEGIS Projektes werden der wissenschaftlichen Gemeinschaft auf Grundlage einer über das Internet erreichbaren Datenbank zugänglich gemacht, welche eine Zuarbeit zur Initiative GEOSS (Global Earth Observing System of Systems) ist. Hintergründig basiert das CEOP-AEGIS Datenportal auf einem Dapper OPeNDAP Internetserver, welcher die im NetCDF Dateiformat gespeicherten Daten der vordergründigen internetbasierten DChart Benutzerschnittstelle auf Grundlage des OPeNDAP Protokolls bereit stellt. Eingangsdaten von Partnern dieses Projektes sind heterogen nicht nur in Bezug ihres Dateninhalts, sondern auch in Anbetracht ihrer Datenhaltung und Metadatenbeschreibung. Die Daten- und Metadatenhaltung der im NetCDF Dateiformat gespeicherten Endprodukte dieses Projektes müssen jedoch auf einer standardisierten Basis internationalen Konventionen folgen, damit ein hoher Grad an Interoperabilität erreicht werden kann. In Anbetracht dieser Qualitätsanforderungen wurden die technischen Möglichkeiten von NetCDF, OPeNDAP, Dapper und DChart in dieser Diplomarbeit gründlich untersucht, damit auf Grundlage dieser Erkenntnisse eine korrekte Entscheidung bezüglich der Implementierung eines für CEOP-AEGIS Daten passenden und interoperablen NetCDF Datenmodels abgeleitet werden kann, das eine maximale Kompatibilität und Funktionalität mit OPeNDAP und Dapper / DChart sicher stellen soll. Diese NetCDF Implementierung ist Bestandteil einer neu entwickelten Datenschnittstelle, welche heterogene Daten von Projektpartnern in standardisierte NetCDF Datensätze konvertiert und aggregiert, sodass diese mittels OPeNDAP dem auf der Dapper / DChart Technologie basierendem Datenportal von CEOP-AEGIS zugeführt werden können. Einen besonderen Schwerpunkt bei der Entwicklung dieser Datenschnittstelle wurde auf eine intermediäre Daten- und Metadatenhaltung gelegt, welche mit der Zielsetzung von geringem Arbeitsaufwand die Modifizierung ihrer Elemente und somit die Erzeugung von standardisierten NetCDF Dateien auf eine einfache Art und Weise erlaubt. In Anbetracht der beträchtlichen und verschiedenartigsten Geodaten dieses Projektes war es schlussendlich wesentlich, eine hochwertige Datenschnittstelle zur Überführung heterogener Eingangsdaten von Projektpartnern in standardisierte und aggregierte NetCDF Ausgansdateien zu entwickeln, um damit eine maximale Kompatibilität und Funktionalität mit dem CEOP-AEGIS Datenportal und daraus folgend ein hohes Maß an Interoperabilität innerhalb der wissenschaftlichen Gemeinschaft erzielen zu können.

The Tibetan Plateau with an extent of about 2,5 million square kilometers at an average altitude higher than 4,700 meters has a significant impact on the Asian monsoon and regulates with its snow and ice reserves the upstream headwaters of seven major south-east Asian rivers. Upon the water supply of these rivers depend over 1,4 billion people, the agriculture, the economics, and the entire ecosystem in this region. As the increasing number of floods and droughts show, these seasonal water reserves however are likely to be influenced by climate change, with negative effects for the downstream water supply and subsequently the food security. The international cooperation project CEOP-AEGIS – funded by the European Commission under the Seventh Framework Program – aims as a result to improve the knowledge of the hydrology and meteorology of the Qinghai-Tibetan Plateau to further understand its role in climate, monsoon and increasing extreme meteorological events. Within the framework of this project, a large variety of earth observation datasets from remote sensing products, model outputs and in-situ ground station measurements are collected and evaluated. Any foreground products of CEOP-AEGIS will have to be made available to the scientific community by an online data repository which is a contribution to the Global Earth Observation System of Systems (GEOSS). The back-end of the CEOP-AEGIS Data Portal relies on a Dapper OPeNDAP web server that serves data stored in the NetCDF file format to a DChart client front-end as web-based user interface. Data from project partners are heterogeneous in its content, and also in its type of storage and metadata description. However NetCDF project output data and metadata has to be standardized and must follow international conventions to achieve a high level of interoperability. Out of these needs, the capabilities of NetCDF, OPeNDAP, Dapper and DChart were profoundly evaluated in order to take correct decisions for implementing a suitable and interoperable NetCDF data model for CEOP-AEGIS data that allows a maximum of compatibility and functionality to OPeNDAP and Dapper / DChart as well. This NetCDF implementation is part of a newly developed upstream data interface that converts and aggregates heterogeneous input data of project partners to standardized NetCDF datasets, so that they can be feed via OPeNDAP to the CEOP-AEGIS Data Portal based on the Dapper / DChart technology. A particular focus in the design of this data interface was set to an intermediate data and metadata representation that easily allows to modify its elements with the scope of achieving standardized NetCDF files in a simple way. Considering the extensive variety and amount of data within this project, it was essential to properly design a data interface that converts heterogeneous input data of project partners to standardized and aggregated NetCDF output files in order to ensure maximum compatibility and functionality within the CEOP-AEGIS Data Portal and subsequently interoperability within the scientific community.:Task of Diploma Thesis ii Declaration of academic honesty vii Abstract ix Acknowledgments xiii Dedication xv Table of Contents xvii List of Figures xxi List of Tables xxiii List of Listings xxv Nomenclature xxvii 1 Introduction 1 1.1 CEOP-AEGIS project . . . . . . . . . . . . . . . . . . . . . . 3 1.2 Problem statement . . . . . . . . . . . . . . . . . . . . . . . . 5 1.3 Objective of this thesis . . . . . . . . . . . . . . . . . . . . . . 8 1.4 Structure of this work . . . . . . . . . . . . . . . . . . . . . . 10 2 Theoretical foundations 13 2.1 NetCDF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 2.1.1 Data models . . . . . . . . . . . . . . . . . . . . . . . . 16 2.1.2 Datasets . . . . . . . . . . . . . . . . . . . . . . . . . . 17 2.1.3 Dimensions . . . . . . . . . . . . . . . . . . . . . . . . 17 2.1.4 Variables . . . . . . . . . . . . . . . . . . . . . . . . . . 19 2.1.5 Attributes . . . . . . . . . . . . . . . . . . . . . . . . . 20 2.1.6 NetCDF 3 . . . . . . . . . . . . . . . . . . . . . . . . . 21 2.1.7 NetCDF 4 . . . . . . . . . . . . . . . . . . . . . . . . . 27 2.1.8 Common Data Model . . . . . . . . . . . . . . . . . . . 31 2.1.9 NetCDF libraries and APIs . . . . . . . . . . . . . . . 33 2.1.10 NetCDF utilities . . . . . . . . . . . . . . . . . . . . . 34 2.1.11 NetCDF textual representations . . . . . . . . . . . . . 35 2.1.12 NetCDF conventions . . . . . . . . . . . . . . . . . . . 36 2.2 OPeNDAP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39 2.2.1 Architecture . . . . . . . . . . . . . . . . . . . . . . . . 41 2.2.2 OPeNDAP servers . . . . . . . . . . . . . . . . . . . . 42 2.2.3 OPeNDAP clients . . . . . . . . . . . . . . . . . . . . . 47 2.2.4 Data Access Protocol . . . . . . . . . . . . . . . . . . . 48 2.2.5 OPeNDAP data models and data types . . . . . . . . . 49 2.2.6 OPeNDAP and NetCDF . . . . . . . . . . . . . . . . . 53 2.3 Dapper . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56 2.3.1 Climate Data Portal . . . . . . . . . . . . . . . . . . . 57 2.3.2 System architecture and Dapper services . . . . . . . . 58 2.3.3 Data aggregation . . . . . . . . . . . . . . . . . . . . . 60 2.3.4 Supported conventions of Dapper . . . . . . . . . . . . 61 2.4 DChart . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62 2.4.1 Design goals . . . . . . . . . . . . . . . . . . . . . . . . 63 2.4.2 Functionality . . . . . . . . . . . . . . . . . . . . . . . 63 2.4.3 System architecture . . . . . . . . . . . . . . . . . . . . 64 2.5 Dapper and DChart configuration . . . . . . . . . . . . . . . . 66 2.5.1 License and release notes . . . . . . . . . . . . . . . . . 67 2.5.2 Dapper and DChart system requirements . . . . . . . . 67 3 Implementation 69 3.1 Scientific data types . . . . . . . . . . . . . . . . . . . . . . . 69 3.1.1 Gridded data . . . . . . . . . . . . . . . . . . . . . . . 70 3.1.2 In-situ data . . . . . . . . . . . . . . . . . . . . . . . . 71 3.2 NetCDF for CEOP-AEGIS . . . . . . . . . . . . . . . . . . . . 71 3.2.1 CF Climate and Forecast Convention . . . . . . . . . . 73 3.2.2 Dapper In-situ Convention . . . . . . . . . . . . . . . . 80 3.2.3 NetCDF implementation for CEOP-AEGIS . . . . . . 89 3.3 CEOP-AEGIS Data Interface . . . . . . . . . . . . . . . . . . 93 3.3.1 Intermediate data model . . . . . . . . . . . . . . . . . 95 3.3.2 Data Interface dependencies . . . . . . . . . . . . . . . 98 3.3.3 Data Interface usage . . . . . . . . . . . . . . . . . . . 98 3.3.4 Data Interface modules . . . . . . . . . . . . . . . . . . 105 3.4 Final products . . . . . . . . . . . . . . . . . . . . . . . . . . . 107 4 Conclusion 111 4.1 Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111 4.2 Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114 4.3 Outlook . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117 A Appendix 119 A.1 CD-ROM of project data . . . . . . . . . . . . . . . . . . . . . 119 A.2 Flood occurrence maps . . . . . . . . . . . . . . . . . . . . . . 121 A.2.1 Flood occurrence May . . . . . . . . . . . . . . . . . . 122 A.2.2 Flood occurrence August . . . . . . . . . . . . . . . . . 123 A.3 CEOP-AEGIS Data Portal . . . . . . . . . . . . . . . . . . . . 124 A.3.1 Capture image of CEOP-AEGIS Data Portal . . . . . . 125 A.3.2 Dapper configuration file . . . . . . . . . . . . . . . . . 126 A.3.3 DChart configuration file . . . . . . . . . . . . . . . . . 127 A.4 NetCDF data models for CEOP-AEGIS . . . . . . . . . . . . 130 A.4.1 Data model for gridded data . . . . . . . . . . . . . . . 131 A.4.2 Data model for in-situ data . . . . . . . . . . . . . . . 132 A.5 Upstream data interface . . . . . . . . . . . . . . . . . . . . . 133 A.5.1 Data Interface and service chain . . . . . . . . . . . . . 134 A.5.2 Data Interface data flow . . . . . . . . . . . . . . . . . 135 A.5.3 Data Interface data flow 2 . . . . . . . . . . . . . . . . 136 A.5.4 Data Interface modules and classes . . . . . . . . . . . 137 A.5.5 Data Interface NetCDF metadata file for gridded data 138 A.5.6 Data Interface NetCDF metadata file for in-situ data . 139 A.5.7 Data Interface coordinate metadata file for gridded data140 A.5.8 Data Interface coordinate metadata file for in-situ data 140 A.5.9 Data Interface UI main program . . . . . . . . . . . . . 141 A.5.10 Data Interface UI GrADS component . . . . . . . . . . 142 A.5.11 Data Interface UI GDAL component . . . . . . . . . . 143 A.5.12 Data Interface UI CSV component . . . . . . . . . . . 144 A.5.13 Data Interface settings file for gridded data . . . . . . . 145 A.5.14 Data Interface settings file for in-situ data . . . . . . . 146 A.5.15 Data Interface batch file for data conversion via GrADS146 A.5.16 Data Interface batch file for data conversion via GDAL 147 A.5.17 Data Interface batch file for data conversion via CSV . 148 A.6 Pydoc documentation for upstream data interface . . . . . . . 149 A.6.1 grads_2Interface.py . . . . . . . . . . . . . . . . . . . . 150 A.6.2 gdal_2Interface.py . . . . . . . . . . . . . . . . . . . . 155 A.6.3 csv_2Interface.py . . . . . . . . . . . . . . . . . . . . . 162 A.6.4 interface_Main.py . . . . . . . . . . . . . . . . . . . . 167 A.6.5 interface_Settings.py . . . . . . . . . . . . . . . . . . . 172 A.6.6 interface_Control.py . . . . . . . . . . . . . . . . . . . 175 A.6.7 interface_Model.py . . . . . . . . . . . . . . . . . . . . 179 A.6.8 interface_ModelUtilities.py . . . . . . . . . . . . . . . 185 A.6.9 interface_Data.py . . . . . . . . . . . . . . . . . . . . . 189 A.6.10 interface_ProcessingTools.py . . . . . . . . . . . . . . 191 Bibliography 197 Index 205 / Das Hochplateau von Tibet mit einer Ausdehnung von 2.5 Millionen Quadratkilometer und einer durchschnittlichen Höhe von über 4 700 Meter beeinflusst wesentlich den asiatischen Monsun und reguliert mit seinen Schnee- und Eisreserven den Wasserhaushalt der Oberläufe der sieben wichtigsten Flüsse Südostasiens. Von diesem Wasserzufluss leben 1.4 Milliarden Menschen und hängt neben dem Ackerbau und der Wirtschaft das gesamte Ökosystem in dieser Gegend ab. Wie die zunehmende Zahl an Dürren und Überschwemmungen zeigt, sind diese jahreszeitlich beeinflussten Wasserreserven allen Anscheins nach vom Klimawandel betroffen, mit negativen Auswirkungen für die flussabwärts liegenden Stromgebiete und demzufolge die dortige Nahrungsmittelsicherheit. Das internationale Kooperationsprojekt CEOP-AEGIS – finanziert von der Europäischen Kommission unter dem Siebten Rahmenprogramm – hat sich deshalb zum Ziel gesetzt, die Hydrologie und Meteorologie dieses Hochplateaus weiter zu erforschen, um daraus seine Rolle in Bezug auf das Klima, den Monsun und den zunehmenden extremen Wetterereignissen tiefgreifender verstehen zu können. Im Rahmen dieses Projektes werden verschiedenartigste Erdbeobachtungsdaten von Fernerkundungssystemen, numerischen Simulationen und Bodenstationsmessungen gesammelt und ausgewertet. Sämtliche Endprodukte des CEOP-AEGIS Projektes werden der wissenschaftlichen Gemeinschaft auf Grundlage einer über das Internet erreichbaren Datenbank zugänglich gemacht, welche eine Zuarbeit zur Initiative GEOSS (Global Earth Observing System of Systems) ist. Hintergründig basiert das CEOP-AEGIS Datenportal auf einem Dapper OPeNDAP Internetserver, welcher die im NetCDF Dateiformat gespeicherten Daten der vordergründigen internetbasierten DChart Benutzerschnittstelle auf Grundlage des OPeNDAP Protokolls bereit stellt. Eingangsdaten von Partnern dieses Projektes sind heterogen nicht nur in Bezug ihres Dateninhalts, sondern auch in Anbetracht ihrer Datenhaltung und Metadatenbeschreibung. Die Daten- und Metadatenhaltung der im NetCDF Dateiformat gespeicherten Endprodukte dieses Projektes müssen jedoch auf einer standardisierten Basis internationalen Konventionen folgen, damit ein hoher Grad an Interoperabilität erreicht werden kann. In Anbetracht dieser Qualitätsanforderungen wurden die technischen Möglichkeiten von NetCDF, OPeNDAP, Dapper und DChart in dieser Diplomarbeit gründlich untersucht, damit auf Grundlage dieser Erkenntnisse eine korrekte Entscheidung bezüglich der Implementierung eines für CEOP-AEGIS Daten passenden und interoperablen NetCDF Datenmodels abgeleitet werden kann, das eine maximale Kompatibilität und Funktionalität mit OPeNDAP und Dapper / DChart sicher stellen soll. Diese NetCDF Implementierung ist Bestandteil einer neu entwickelten Datenschnittstelle, welche heterogene Daten von Projektpartnern in standardisierte NetCDF Datensätze konvertiert und aggregiert, sodass diese mittels OPeNDAP dem auf der Dapper / DChart Technologie basierendem Datenportal von CEOP-AEGIS zugeführt werden können. Einen besonderen Schwerpunkt bei der Entwicklung dieser Datenschnittstelle wurde auf eine intermediäre Daten- und Metadatenhaltung gelegt, welche mit der Zielsetzung von geringem Arbeitsaufwand die Modifizierung ihrer Elemente und somit die Erzeugung von standardisierten NetCDF Dateien auf eine einfache Art und Weise erlaubt. In Anbetracht der beträchtlichen und verschiedenartigsten Geodaten dieses Projektes war es schlussendlich wesentlich, eine hochwertige Datenschnittstelle zur Überführung heterogener Eingangsdaten von Projektpartnern in standardisierte und aggregierte NetCDF Ausgansdateien zu entwickeln, um damit eine maximale Kompatibilität und Funktionalität mit dem CEOP-AEGIS Datenportal und daraus folgend ein hohes Maß an Interoperabilität innerhalb der wissenschaftlichen Gemeinschaft erzielen zu können.:Task of Diploma Thesis ii Declaration of academic honesty vii Abstract ix Acknowledgments xiii Dedication xv Table of Contents xvii List of Figures xxi List of Tables xxiii List of Listings xxv Nomenclature xxvii 1 Introduction 1 1.1 CEOP-AEGIS project . . . . . . . . . . . . . . . . . . . . . . 3 1.2 Problem statement . . . . . . . . . . . . . . . . . . . . . . . . 5 1.3 Objective of this thesis . . . . . . . . . . . . . . . . . . . . . . 8 1.4 Structure of this work . . . . . . . . . . . . . . . . . . . . . . 10 2 Theoretical foundations 13 2.1 NetCDF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 2.1.1 Data models . . . . . . . . . . . . . . . . . . . . . . . . 16 2.1.2 Datasets . . . . . . . . . . . . . . . . . . . . . . . . . . 17 2.1.3 Dimensions . . . . . . . . . . . . . . . . . . . . . . . . 17 2.1.4 Variables . . . . . . . . . . . . . . . . . . . . . . . . . . 19 2.1.5 Attributes . . . . . . . . . . . . . . . . . . . . . . . . . 20 2.1.6 NetCDF 3 . . . . . . . . . . . . . . . . . . . . . . . . . 21 2.1.7 NetCDF 4 . . . . . . . . . . . . . . . . . . . . . . . . . 27 2.1.8 Common Data Model . . . . . . . . . . . . . . . . . . . 31 2.1.9 NetCDF libraries and APIs . . . . . . . . . . . . . . . 33 2.1.10 NetCDF utilities . . . . . . . . . . . . . . . . . . . . . 34 2.1.11 NetCDF textual representations . . . . . . . . . . . . . 35 2.1.12 NetCDF conventions . . . . . . . . . . . . . . . . . . . 36 2.2 OPeNDAP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39 2.2.1 Architecture . . . . . . . . . . . . . . . . . . . . . . . . 41 2.2.2 OPeNDAP servers . . . . . . . . . . . . . . . . . . . . 42 2.2.3 OPeNDAP clients . . . . . . . . . . . . . . . . . . . . . 47 2.2.4 Data Access Protocol . . . . . . . . . . . . . . . . . . . 48 2.2.5 OPeNDAP data models and data types . . . . . . . . . 49 2.2.6 OPeNDAP and NetCDF . . . . . . . . . . . . . . . . . 53 2.3 Dapper . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56 2.3.1 Climate Data Portal . . . . . . . . . . . . . . . . . . . 57 2.3.2 System architecture and Dapper services . . . . . . . . 58 2.3.3 Data aggregation . . . . . . . . . . . . . . . . . . . . . 60 2.3.4 Supported conventions of Dapper . . . . . . . . . . . . 61 2.4 DChart . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62 2.4.1 Design goals . . . . . . . . . . . . . . . . . . . . . . . . 63 2.4.2 Functionality . . . . . . . . . . . . . . . . . . . . . . . 63 2.4.3 System architecture . . . . . . . . . . . . . . . . . . . . 64 2.5 Dapper and DChart configuration . . . . . . . . . . . . . . . . 66 2.5.1 License and release notes . . . . . . . . . . . . . . . . . 67 2.5.2 Dapper and DChart system requirements . . . . . . . . 67 3 Implementation 69 3.1 Scientific data types . . . . . . . . . . . . . . . . . . . . . . . 69 3.1.1 Gridded data . . . . . . . . . . . . . . . . . . . . . . . 70 3.1.2 In-situ data . . . . . . . . . . . . . . . . . . . . . . . . 71 3.2 NetCDF for CEOP-AEGIS . . . . . . . . . . . . . . . . . . . . 71 3.2.1 CF Climate and Forecast Convention . . . . . . . . . . 73 3.2.2 Dapper In-situ Convention . . . . . . . . . . . . . . . . 80 3.2.3 NetCDF implementation for CEOP-AEGIS . . . . . . 89 3.3 CEOP-AEGIS Data Interface . . . . . . . . . . . . . . . . . . 93 3.3.1 Intermediate data model . . . . . . . . . . . . . . . . . 95 3.3.2 Data Interface dependencies . . . . . . . . . . . . . . . 98 3.3.3 Data Interface usage . . . . . . . . . . . . . . . . . . . 98 3.3.4 Data Interface modules . . . . . . . . . . . . . . . . . . 105 3.4 Final products . . . . . . . . . . . . . . . . . . . . . . . . . . . 107 4 Conclusion 111 4.1 Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111 4.2 Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114 4.3 Outlook . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117 A Appendix 119 A.1 CD-ROM of project data . . . . . . . . . . . . . . . . . . . . . 119 A.2 Flood occurrence maps . . . . . . . . . . . . . . . . . . . . . . 121 A.2.1 Flood occurrence May . . . . . . . . . . . . . . . . . . 122 A.2.2 Flood occurrence August . . . . . . . . . . . . . . . . . 123 A.3 CEOP-AEGIS Data Portal . . . . . . . . . . . . . . . . . . . . 124 A.3.1 Capture image of CEOP-AEGIS Data Portal . . . . . . 125 A.3.2 Dapper configuration file . . . . . . . . . . . . . . . . . 126 A.3.3 DChart configuration file . . . . . . . . . . . . . . . . . 127 A.4 NetCDF data models for CEOP-AEGIS . . . . . . . . . . . . 130 A.4.1 Data model for gridded data . . . . . . . . . . . . . . . 131 A.4.2 Data model for in-situ data . . . . . . . . . . . . . . . 132 A.5 Upstream data interface . . . . . . . . . . . . . . . . . . . . . 133 A.5.1 Data Interface and service chain . . . . . . . . . . . . . 134 A.5.2 Data Interface data flow . . . . . . . . . . . . . . . . . 135 A.5.3 Data Interface data flow 2 . . . . . . . . . . . . . . . . 136 A.5.4 Data Interface modules and classes . . . . . . . . . . . 137 A.5.5 Data Interface NetCDF metadata file for gridded data 138 A.5.6 Data Interface NetCDF metadata file for in-situ data . 139 A.5.7 Data Interface coordinate metadata file for gridded data140 A.5.8 Data Interface coordinate metadata file for in-situ data 140 A.5.9 Data Interface UI main program . . . . . . . . . . . . . 141 A.5.10 Data Interface UI GrADS component . . . . . . . . . . 142 A.5.11 Data Interface UI GDAL component . . . . . . . . . . 143 A.5.12 Data Interface UI CSV component . . . . . . . . . . . 144 A.5.13 Data Interface settings file for gridded data . . . . . . . 145 A.5.14 Data Interface settings file for in-situ data . . . . . . . 146 A.5.15 Data Interface batch file for data conversion via GrADS146 A.5.16 Data Interface batch file for data conversion via GDAL 147 A.5.17 Data Interface batch file for data conversion via CSV . 148 A.6 Pydoc documentation for upstream data interface . . . . . . . 149 A.6.1 grads_2Interface.py . . . . . . . . . . . . . . . . . . . . 150 A.6.2 gdal_2Interface.py . . . . . . . . . . . . . . . . . . . . 155 A.6.3 csv_2Interface.py . . . . . . . . . . . . . . . . . . . . . 162 A.6.4 interface_Main.py . . . . . . . . . . . . . . . . . . . . 167 A.6.5 interface_Settings.py . . . . . . . . . . . . . . . . . . . 172 A.6.6 interface_Control.py . . . . . . . . . . . . . . . . . . . 175 A.6.7 interface_Model.py . . . . . . . . . . . . . . . . . . . . 179 A.6.8 interface_ModelUtilities.py . . . . . . . . . . . . . . . 185 A.6.9 interface_Data.py . . . . . . . . . . . . . . . . . . . . . 189 A.6.10 interface_ProcessingTools.py . . . . . . . . . . . . . . 191 Bibliography 197 Index 205

Das Leibniz-Institut für ökologische Raumentwicklung (IÖR) verfolgt u. a. das Ziel, präzise Kenntnisse über das Mengengerüst des deutschen Gebäudebestandes und seiner Eigenschaften zu gewinnen und räumlich hochauflösende Indikatoren als Grundlage einer nachhaltigen Raumentwicklung für Planer und Entscheidungsträger zu erarbeiten. Dieser Beitrag fokussiert auf Ansätze der räumlichen Analyse, die eine Quantifizierung und Charakterisierung des Gesamtbestandes von Wohn- und Nichtwohngebäuden unterstützen. Vorgestellt werden erste Ergebnisse einer deutschlandweiten Auswertung amtlicher Hauskoordinaten und Hausumringe. Der Gebäudebestand wird nach Bundesländern und nach Raumstrukturtypen des Bundesinstituts für Bau-, Stadt- und Raumforschung (BBSR) gegliedert. Es besteht Bedarf, nicht nur Datenmodelle zu entwickeln, sondern daraus auch Erklärungs- und Messmodelle abzuleiten, die einen expliziten Raumbezug aufweisen und sich zur bestandsorientierten Wissensgewinnung sowie zur Strategieentwicklung eignen – auch im europäischen Kontext.