Metaatlasgraphy is a new theoretic-epistemological concept with synthesis of cartographic/cartosemiotic traditions and atlasgraphic/ atlassemiotic traditions. The monograph presents a new trend from a map-centric concept to a multidisciplinary atlas-centric concept. Further, it projects a new metascience direction: from metacartography to metaatlasgraphy.:Table of contents Introduction 4 1. Cartography 1970s-2020s: Digitalitization, Semiotization, Ubiquitization... 5 1.1. Selected scientific structures and concepts of cartography (1970-2020) 1.2. About paradigmatic transformations of cartography 1.3. Critical cartography as post-critical paradigm 1.4. Cybercartography: Canadian model of interactive atlascartography and theory- technological concept 2. Theoretical-Semiotic Evolution in Cartography 2010s - 2020s without Mainstream Cartography 15 2.1. Cartographic thinking and cartosemiotics 2.2. Atlases and atlascartography 2.3. Semiotic-related atlassing 2.4. Evolutionary trajectories in cartography and cartosemiotics 3. New Atlassemiotic Тrend: Photoаtlassing 35 3.1. Ubiquitous thematic photoatlases 3.2. Semiotik of photoatlases 3.2.1. Structure-semiotic features of photoatlases 3.2.2. Derivative photoatlases 3.2.3. Photoatlas design of one, two and three slide/parts layout 3.2.4.Methodic-analytical photoatlases 3.2.5. Meta-photoatlases 3.2.6. On robotic photoatlases 3.3. Cyberphotoatlassing – a new interdiscipline synthesis 3.4. Photoatlas science as academic discipline 4. About Metaatlasgraphy 59 4.1. Models of metatheoretical research and metacartographic epicenters 4.2. From metacartography and metacartosemiotics to metaatlasgraphy 4.3. Metaatlasgraphy 4.3.1. Terminological aspects 4.3.2. From cartosemiotic models to atlassemiotic models 4.3.3. Structural model of metaatlasgraphy 4.3.4. New metatheoretic epicenters 4.3.5 Metaatlasgraphic democratic principles 5. Conclusion 70 6. References 72 7. List of selected photoatlases 77 8. Short atlas semiotic dictionary 78 9. Information-semiotic profile and potential of book 81

Vorzustellen ist ein kurioses Werk aus der Kartensammlung der SLUB, das in bibliophilen Kreisen nicht ganz unbekannt ist: In einer pittoresken „Karte des Bücherlandes“ stellte der Münchner Graphiker und Illustrator Alphons Woelfle (1884 –1951) 1938 das deutsche Buch- und Verlagswesen dar, in barocker Manier mit Kartusche, Allegorie und antiken Lettern. Schon 1941 neu aufgelegt, erlebte die ursprünglich handkolorierte Lithographie auf Büttenpapier bis heute zahlreiche Nachdrucke, sogar im Postkartenformat: Dabei misst das Blatt im Original 40 mal 29 cm.

Der Radweg Berlin–Dresden ist ein Routenvorschlag für Fahrradtouren zwischen Berlin und Dresden, der seit 2012 von Mitgliedern des Allgemeinen Deutschen Fahrrad-Clubs (ADFC) ausgearbeitet wird. Die Route streckt sich über 251km zwischen der Frauenkirche in Dresden und dem Brandenburger Tor in Berlin. Eine Beschilderung der Route wird langfristig angestrebt. Obwohl die Strecke heute nur „auf dem Papier“ existiert, ist sie schon gut befahrbar: Alle Wege (bis auf kleine unvermeidbare Lücken) sind asphaltiert oder gut verdichtet und frei oder wenig belastet vom motorisierten Verkehr. Auf www.radweg-berlin-dresden.de finden Sie aktuelle Informationen zur Route und es steht eine GPX-Datei für GPS-Geräte kostenlos zur Verfügung.:Der Radweg Berlin–Dresden Übersichtskarte der ganzen Route Anfang — Detail Berlin Detail Berlin/Schulzendorf Detail Zeuthen Detail Königs Wusterhausen Dahmeradweg Dahmeradweg/Hofjagdweg Gurkenradweg Detail Lübben Niederlausitzer Bergbautour und andere Detail Vetschau Niederlausitzer Bergbautour und Fürst-Pückler-Radweg Niederlausitzer Bergbautour und Niederlausitzer Kreisel Detail Ruhland und Schwarzheide Übersicht mit Radeburg Detail Radeburg Übersicht Dresden Detail Dresden-Hellerau Detail Dresden

Although many terminologies, taxonomies and also first ontologies for visualization have been suggested, there is still no unified and formal knowledge representation including the various fields of this interdisciplinary domain. We moved a step towards such an ontology by systematically reviewing existing models and classifications, identifying important fields and discussing inconsistently used terms. Finally, we specified an initial visualization ontology which can be used for both classification and synthesis of graphical representations. Our ontology can also serve the visualization community as a foundation to further formalize, align and unify its existing and future knowledge.

No description available.

OpenStreetMap (OSM) konnte sich seit der Gründung 2004 sehr schnell etablieren und stellt mittlerweile eine konkrete Alternative gegenüber vergleichbaren kommerziellen Anwendungen dar. Dieser Erfolg ist eindeutig auf das revolutionäre Grundkonzept des Projektes zurückzuführen. Weltweit werden räumliche Daten durch Mitglieder erhoben und dem Projekt OSM zur Verfügung gestellt. Über die zugrunde liegenden Lizenzbestimmungen wird sichergestellt, dass OSM-Daten frei verfügbar und kostenfrei weiter verwendbar sind. Vor allem die Vorstellung der Unabhängigkeit von proprietären Daten hat zu starker, weiterhin zunehmender globaler Beteiligung geführt. Resultierend daraus erreichen die verfügbaren Daten inzwischen hohe Dichte sowie Genauigkeit. Visualisierungen in Form von interaktiven, frei skalierbaren Weltkarten, welche über die vollständig automatisierten Softwarelösungen Mapnik und Osmarender erstellt werden, sind am weitesten verbreitet. Infolgedessen müssen kartographische Grundsätze und Regeln formalisiert und implementiert werden. Insbesondere in Bezug auf kartographische Generalisierung treten teils erhebliche Mängel in den entsprechenden Umsetzungen auf. Dies bildet den Ausgangspunkt der Untersuchung. Ausgehend von einer Ist-Analyse werden vorhandene Defizite identifiziert und anschließend Möglichkeiten zur Integration von Generalisierungsfunktionalitäten untersucht. Aktuelle Entwicklungen streben die Anwendung interoperabler Systeme im Kontext kartographischer Generalisierung an, mit dem Ziel Generalisierungsfunktionalitäten über das Internet bereitzustellen. Grundlage hierfür bilden die vom Open Geospatial Consortium (OGC) spezifizierten Web Processing Services (WPS). Sie ermöglichen die Analyse und Verarbeitung räumlicher Daten. In diesem Zusammenhang werden Web Generalization Services (WebGen-WPS) auf mögliche Integration in die Softwarelösungen untersucht und bilden somit einen zentralen Untersuchungsgegenstand der vorliegenden Arbeit. Mapnik stellt, nicht zuletzt durch dessen offengelegten Quelltext („Open Source“), optimale Voraussetzungen für jene Implementierungen zur Verfügung. Zur Verarbeitung von OSM-Daten verwendet Mapnik die freie Geodatenbank PostGIS, welche ebenfalls Funktionalitäten zur Analyse und Verarbeitung räumlicher Daten liefert. In diesem Kontext wird zusätzlich untersucht, inwiefern PostGIS-Funktionen Potential zur Anwendung kartographischer Generalisierung aufweisen.:Inhaltsverzeichnis Aufgabenstellung ii Zusammenfassung iii Abstract iv Abbildungsverzeichnis viii Tabellenverzeichnis ix Abkürzungsverzeichnis x 1 Einleitung 1 1.1 Motivation 1 1.2 Aufbau der Arbeit 4 2 Grundlagen 5 2.1 OpenStreetMap 5 2.1.1 Ablauf der Erstellung von OSM-Karten 6 2.1.2 Mapnik 9 2.2 Web Services 12 2.2.1 OGC Web Processing Services 12 2.2.2 Web Generalization Services 14 2.2.3 Verkettung von OGC Web Services 16 2.3 Kartographische Generalisierung 17 2.3.1 Konzeptionelle Modellvorstellungen 18 2.3.2 Generalisierungsoperatoren 22 3 OpenStreetMap & Generalisierung – aktueller Stand 24 3.1 Allgemeine Analyse und Kritik 25 3.2 OSM & konzeptionelle Modelle 28 4 Theoretische Überlegungen 31 4.1 Einbindung des WebGen-WPS 32 4.1.1 Direkteinbindung des WebGen-WPS 32 4.1.2 Einbindung von WebGen-WPS für „MRDB-OSM“ 34 4.2 PostGIS-Funktionen 36 4.3 OpenStreetMap - Generalisierungscommunity 38 5 Implementierungen & Ergebnisse 40 5.1 Technische Voraussetzungen 41 5.1.1 Systemvoraussetzungen 41 5.1.2 Testgebiet 41 5.2 Einbindung des WebGen-WPS in Mapnik 42 5.2.1 Einbindung in den automatischen Prozess 42 5.2.1.1 Allgemeiner Programmablauf 43 5.2.1.2 Implementierungsansätze 44 5.2.2 Praktische Umsetzung einer „MRDB-OSM“ 47 5.2.2.1 Verfahrensablauf 48 5.2.2.2 Polygonvereinfachung 51 5.2.2.3 Linienvereinfachung 57 5.3 Implementierung von PostGIS-Funktionen 59 5.3.1 Auswahl 59 5.3.2 Betonung 60 5.3.3 Linienvereinfachung 61 5.3.4 Polygonvereinfachung 61 6 Schlussfolgerungen und Ausblicke 65 6.1 Diskussion der Ergebnisse 65 6.2 Fazit 71 7 Quellennachweise 72 7.1 Literaturverzeichnis 72 7.2 Internetquellennachweis (ohne eindeutige Autoren) 77 8 Anhang 79 / OpenStreetMap (OSM) has established very quickly since its founding in 2004 and has become a suitable alternative to similar commercial applications. This success is clearly due to the revolutionary concept of the project. Spatial data is collected by members world-wide and is provided to the project OSM. The underlying license aggreement ensures that OSM-Data is freely available and can be used free of charge. Primarily, the idea of independence from proprietary data has led to strong, still growing, global participation. Resulting from that, the available data is now achieving high density and accuracy. Visualizations in form of interactive, freely scalable maps of the world, which are constructed by the fully automated software solutions Mapnik and Osmarender are most common. In consequence cartographic principles and rules must be formalized and implemented. Particularly with respect to cartographic generalization, some serious faults appear in the corresponding implementations. This is the starting point of this diploma thesis. Based on an analysis of the current state, actual existing deficiencies are identified and then examined for possibilities to integrate generalization functionalities. Recent developments aim at the deployment of interoperable systems in the context of cartographic generalization, with the intention of providing generalization functionalities over the Internet. This is based on Web Processing Services (WPS) that where developed by the Open Geospatial Consortium (OGC). They enable the analysis and processing of spatial data. In this context, Web Generalization Services (Webgen-WPS) are examined for possible integration into the software solutions and represent therefore a central object of investigation within that examination. Mapnik provides, not least through its “open source” code, ideal conditions for those implementations. Mapnik uses the “open source” spatial database PostGIS for the processing of OSM-Data, which also provides capabilities to analyze and process spatial data. In this context is examined in addition, to what extent the features have potential for implementation of cartographic generalization.:Inhaltsverzeichnis Aufgabenstellung ii Zusammenfassung iii Abstract iv Abbildungsverzeichnis viii Tabellenverzeichnis ix Abkürzungsverzeichnis x 1 Einleitung 1 1.1 Motivation 1 1.2 Aufbau der Arbeit 4 2 Grundlagen 5 2.1 OpenStreetMap 5 2.1.1 Ablauf der Erstellung von OSM-Karten 6 2.1.2 Mapnik 9 2.2 Web Services 12 2.2.1 OGC Web Processing Services 12 2.2.2 Web Generalization Services 14 2.2.3 Verkettung von OGC Web Services 16 2.3 Kartographische Generalisierung 17 2.3.1 Konzeptionelle Modellvorstellungen 18 2.3.2 Generalisierungsoperatoren 22 3 OpenStreetMap & Generalisierung – aktueller Stand 24 3.1 Allgemeine Analyse und Kritik 25 3.2 OSM & konzeptionelle Modelle 28 4 Theoretische Überlegungen 31 4.1 Einbindung des WebGen-WPS 32 4.1.1 Direkteinbindung des WebGen-WPS 32 4.1.2 Einbindung von WebGen-WPS für „MRDB-OSM“ 34 4.2 PostGIS-Funktionen 36 4.3 OpenStreetMap - Generalisierungscommunity 38 5 Implementierungen & Ergebnisse 40 5.1 Technische Voraussetzungen 41 5.1.1 Systemvoraussetzungen 41 5.1.2 Testgebiet 41 5.2 Einbindung des WebGen-WPS in Mapnik 42 5.2.1 Einbindung in den automatischen Prozess 42 5.2.1.1 Allgemeiner Programmablauf 43 5.2.1.2 Implementierungsansätze 44 5.2.2 Praktische Umsetzung einer „MRDB-OSM“ 47 5.2.2.1 Verfahrensablauf 48 5.2.2.2 Polygonvereinfachung 51 5.2.2.3 Linienvereinfachung 57 5.3 Implementierung von PostGIS-Funktionen 59 5.3.1 Auswahl 59 5.3.2 Betonung 60 5.3.3 Linienvereinfachung 61 5.3.4 Polygonvereinfachung 61 6 Schlussfolgerungen und Ausblicke 65 6.1 Diskussion der Ergebnisse 65 6.2 Fazit 71 7 Quellennachweise 72 7.1 Literaturverzeichnis 72 7.2 Internetquellennachweis (ohne eindeutige Autoren) 77 8 Anhang 79

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