In this paper, we analyze the achievable secrecy rates in the two-hop wiretap channel with four nodes, where the transmitter and the receiver have multiple antennas while the relay and the eavesdropper have only a single antenna each. The relay is operating in amplify-and-forward mode and all the channels between the nodes are known perfectly by the transmitter. We discuss different transmission and protection schemes like artificial noise (AN). Furthermore, we introduce interference neutralization (IN) as a new protection scheme. We compare the different schemes regarding the high-SNR slope and the high-SNR power offset and illustrate the performance by simulation results. It is shown analytically as well as by numerical simulations that the high SNR performance of the proposed IN scheme is better than the one of AN.

No description available.

In heterogeneous dense networks where spectrum is shared, users' privacy remains one of the major challenges. On a multi-antenna relay-assisted multi-carrier interference channel, each user shares the spectral and spatial resources with all other users. When the receivers are not only interested in their own signals but also in eavesdropping other users' signals, the cross talk on the spectral and spatial channels becomes information leakage. In this paper, we propose a novel secrecy rate enhancing relay strategy that utilizes both spectral and spatial resources, termed as information leakage neutralization. To this end, the relay matrix is chosen such that the effective channel from the transmitter to the colluding eavesdropper is equal to the negative of the effective channel over the relay to the colluding eavesdropper and thus the information leakage to zero. Interestingly, the optimal relay matrix in general is not block-diagonal which encourages users' encoding over the frequency channels. We proposed two information leakage neutralization strategies, namely efficient information leakage neutralization (EFFIN) and local-optimized information leakage neutralization (LOPTIN). EFFIN provides a simple and efficient design of relay processing matrix and precoding matrices at the transmitters in the scenario of limited power and computational resources. LOPTIN, despite its higher complexity, provides a better sum secrecy rate performance by optimizing the relay processing matrix and the precoding matrices jointly. The proposed methods are shown to improve the sum secrecy rates over several state-of-the-art baseline methods.

Les technologies du numérique modifient profondément la manière dont les sociétés appréhendent et se représentent leur espace. La cartographie n’est pas à l’écart de ces changements et les cartes sont de plus en plus nombreuses et sont utilisées sous de nouvelles formes. C’est en particulier le cas de la consultation d’itinéraires uniques, rendue plus aisée par les évolutions techniques et technologiques. L’usage de ces itinéraires est aujourd’hui l’une des principales fonctionnalités des cartes numériques, dont un grand nombre sont issues de sociétés implantées aux États-Unis.Comment appréhender, dans le cadre d’une analyse diachronique et comparatiste, le rôle des cartes d’itinéraire dans la cartographie numérique? S’agit-il d’une nouveauté ou de la réactualisation d’une forme cartographique plus ancienne ? Quelle place tient ce type de représentations dans une perspective croisée?La thèse propose de répondre à ces questions par une analyse large à trois entrées : cartobibliographique, sémiologique et processuelle, en se basant sur des corpus de cartes issus de la Bibliothèque nationale de France et de laNewberry Library. Les principaux résultats de ce travail apportent un éclairage sur les changements en cours avec le passage d’une cartographie majoritairement papier à une cartographie majoritairement écran. Ils invitent finalement à penser ces changements à travers une redéfinition du statut de la carte à l’ère numérique. / Digital technologies deeply change the way in which societies grasp their environment and represent space Cartography is not exempt from these changes, maps are more widespread than ever and are being used for new purposes. Among them, the use of route specific maps, made easier by technical and technological developments. Many online maps are used for itineraries, and most of them come from United States-based corporations.These observations raise the questions of how to understand this specific use of maps when put in a chronological and comparative perspective ? Is this an innovation or rather an actualization of a previous type of mapping practice ? What is the status of these itineraries when studied in a multifaceted perspective ?This research addresses these questions using three main approches : cartobibliographical, semiological and processual, and relying on extensive map collections from the Bibliothèque nationale de France and the Newberry Library. The main results bring new insights on the changes taking place with the transition from a primarily paper cartography to a primarily on-screen cartography and call for a redefinition of the status of maps in the digital era.

No description available.

Práce je zaměřena na nalezení optimálního a nového motoru pro PS-28 Sport Cruiser, pro větší výkon a tah. Rotax 912 ULS je v současné době jediným motorem, který klient této práce (Czech Aircraft Works, dále jen CZAW) instaluje do letadel Sport Cruiser. Tato čtyřválcová pohonná jednotka má maximální vzletový výkon 100 hp. Pro náročnější zákazníky bude nabídka rozšířena o Lycoming O-235-L2C, což je také čtyřválcový motor s maximálním vzletovým výkonem 118 koní. Což znamená, že společnost bude mít větší možnost a klient bude mnohem spokojenější.

Práce je zaměřena na nalezení optimálního a nového motoru pro PS-28 Sport Cruiser, pro větší výkon a tah. Rotax 912 ULS je v současné době jediným motorem, který klient této práce (Czech Aircraft Works, dále jen CZAW) instaluje do letadel Sport Cruiser. Tato čtyřválcová pohonná jednotka má maximální vzletový výkon 100 hp. Pro náročnější zákazníky bude nabídka rozšířena o Lycoming O-235-L2C, což je také čtyřválcový motor s maximálním vzletovým výkonem 118 koní. Což znamená, že společnost bude mít větší možnost a klient bude mnohem spokojenější.

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

This dissertation engages with the production and use in late medieval England (c.1200–c.1500) of manuscript codices copied, in whole or in part, on offcuts: cheap, low-quality parchment scraps created as a byproduct of parchment manufacturing. After presenting a method for identifying offcuts, it explores the material through statistical techniques and case studies. Applying this mixed methodology to a corpus of 140 offcut-bearing production units spread across 75 handwritten books, it delineates a range of manuscript production stages, examining the sociocultural contexts of books recruiting offcuts as writing support. The dissertation pursues this study in four chapters. Opening with a terminological discussion, chapter one describes medieval parchment-making, clarifying how offcut traits arose during manufacture, distinguishing offcuts from similar types of parchment, and describing medieval uses for offcuts. Chapter two discusses quantitative codicology, justifying the mixed quantitative–qualitative approach, then delineates its dual-stage methodology: (i) establishing offcut diagnostic traits via linear regression analysis; (ii) assembling the corpus and analyzing it via a descriptive statistical lens. It finishes with an overview of the analysis’ main findings, noting that the corpus is dominated by Fachliteratur; lacking in texts often regarded as ‘popular’ (e.g., vernacular romances); and largely copied for personal consultation in professional, educational, or domestic contexts. Chapters three and four take up the primary subcorpora—one comprising common law books; another, miscellaneous, but chiefly theological and medical, provisionally sorted based on the medieval division of disciplines, quadrivium and trivium—engaging each via descriptive statistical overviews and case studies of representative books: London, British Library, Harley MS 912, Harley MS 1261, Harley MS 6644; Oxford, Bodleian Library, MSS Ashmole 1378, Digby 2, Digby 24. / Graduate / 2023-09-09