MASTER THESIS

Deploying contrail forecasting service to reduce the impact of aviation on Environment

Supervisors:

Dr. Wolfram Hardt Dirk Schindler Chair of Computer Engineering Technical Manager - Faculty of Computer Science Operations Support Systems TU Chemnitz AIRBUS Defence & Space

A thesis submitted in fulfilment of the requirements for the degree of Master of Science in

AUTOMOTIVE SOFTWARE ENGINEERING TUCHEMNITZ

by Tejashree Chhajed MTR.-NO. : 335478

FEBRUARY 14, 2016 ABSTRACT

he principal objective of this thesis is to propose a Contrail forecasting Service for Aviation(ConSA) and a ConSA client to demonstrate the service. The subject Tis motivated by the fact that Contrails have a very harmful effect on the environ- ment and it has been researched thoroughly by scientists. But still we do not have an infrastructure to include these researches in the Aviation industry. This thesis has been conducted at , Friedrichshafen, .

The first part of the thesis investigates the existence of contrails. The object of interest i.e. Contrails is caused by the passage of aeroplanes in ice-saturated areas. The algorithm which is used by the service is a part of the research conducted by Prof. Dr. Ulrich Schumann. The input dataset provided by Meteo is a 4D weather cube. The algorithm computes a threshold temperature and ice supersaturation condition. When both of these conditions are satisfied Contrail formation is certain.

In the second part we explain the architecture and solution used i.e. OGC (Open Geospa- tial Consortium) and LuciadLightspeed to develop Web Services to deploy contrail forecasting methods. Such an architecture fast forwards and eases the task of developer by having inbuilt methods and interfaces. The OGC web services infrastructure has de- fined web feature service and client interface which ease development of geoinformatics solutions. We also use certain standards like WXXM for exchange of contrail information which will be stated in this chapter.

The third part is about the detailed implementation of the ConSA service and client. In this chapter we explain the service and client with uml diagrams to clarify the development concepts.

The final part of the thesis explains the results of ConSA service and client, operational benefits of ConSA and concludes the thesis.

i ACKNOWLEDGEMENTS

oremost, I would like to express my gratitude to my supervisor Dirk Schindler for his immense knowledge, guidance, patience and support. Without his rigorous Fefforts this thesis would not have been completed. He has been a mentor every student would like to learn from.

I would like to thank Robin Houtmeyers from Luciad for his guidance, support and for being there for all the queries. I would like to thank Prof. Ulrich Schumann for his guidance and support. I thank Airbus Defence and Space, Luciad, DLR and Meteo France for graciously providing their research, software and dataset. My experience at Airbus Defence and Space has been a journey of research, I always wanted to undertake.

I thank my boyfriend Surajit Dutta for his love, encouragement and care. He has been besides me for everything, everytime. A special thanks to Merecedes Cabezos Bueno who has been more than a landlady. I thank her for making settling in Deutschland so easy. I also thank her for teaching German, offering the delicious food, the car rides and the hardwork in shifting belongings to new flats. I thank all my friends in Lindau, Jekin Trivedi, Prajakta Bhagwat and Shashikant Chavan for the boat rides, amazing dinners and parties.

I finish with India, where my source of inspiration resides: my family. My mother Sunita Chhajed loved me unconditionally no matter I failed or succeeded. It was her who was always besides me. My father Rajkumar Chhajed taught me to always try and never give up. I owe them my entire self. My grand parents loved me and gave up many things for my dreams and my brother Kunal Chhajed was my companion in studies, fun and in the stupidest things in life. I thank them all and wish to have them forever in my life.

ii To my parents TABLEOF CONTENTS

Page

1 Introduction1 1.1 Background...... 2 1.1.1 Formation of Contrails...... 4 1.1.2 Impacts to Environment...... 5 1.1.3 Radiative forcing...... 7 1.2 Challenges...... 7 1.3 Contributions and Thesis Overview...... 8

2 State of the art 11 2.1 Related Work ...... 12 2.1.1 Statistical Contrail Forecasting...... 12 2.1.2 Prediction of Persistent Contrail Occurrence...... 12 2.1.3 Contrail Cirrus Prediction Tool ...... 13 2.2 Proposed approach ...... 14 2.2.1 Meteo Dataset...... 14 2.2.2 Flight Dataset...... 16 2.2.3 Algorithm...... 18

3 Architecture and Solution 22 3.1 Geographic Information Systems...... 22 3.2 LuciadLightspeed...... 24 3.2.1 Powerful Features...... 28 3.2.2 Benefits of Geospatial display ...... 29 3.3 Web Services ...... 29 3.3.1 Open Geospatial Consortium...... 29 3.3.2 OGC standards ...... 30 3.4 OGC Web Services...... 31 3.4.1 Web Map Service...... 32 3.4.2 Web Feature Service ...... 34 3.4.3 Web Coverage Service ...... 37

iv TABLE OF CONTENTS

3.5 Information exchange format...... 39 3.6 OGC Web Server Suite...... 43 3.6.1 LuciadLightspeed NetCDF Industry Specific Component . . . . 46 3.6.2 LuciadLightspeed WXXM Industry Specific Component . . . . 48

4 Implementation 49 4.1 Inputs from other projects...... 50 4.2 Service overview ...... 51 4.3 Service interface specifications...... 52 4.3.1 ConSA Service...... 52 4.3.2 ConSA Client...... 54 4.4 Service dynamic behaviour...... 55 4.4.1 The ConSA Service...... 55 4.4.2 The ConSA Client ...... 55 4.5 Technical Architecture ...... 56

5 Results and Evaluation 59 5.1 Algorithm Evaluation...... 59 5.2 Validation and Verification ...... 64 5.3 ConSA evaluation...... 64

6 Conclusion 65 6.1 Thesis implications...... 66 6.2 Benefits ...... 68 6.3 Future Scope ...... 71

7 Appendix A 72 7.1 ConSA service physical interface description ...... 72 7.2 ConSA service: OGC WFS capabilities...... 72 7.3 Example of a Contrail object representation in WXXM 2.0 ...... 77

Bibliography 79

v LISTOF TABLES

TABLE Page

5.1 The above table is a given by DLR. It has input and output data to check the correctness of the Contral forecasting algorithm. The G and U values are given and we check if the algorithm outputs the TLC and TLM (temperature) values as given in the table. As it matched completely the algorithm was correct...... 63

vi LISTOF FIGURES

FIGURE Page

1.1 Sesar Objectives...... 3 1.2 Exhaust Contrails...... 4 1.3 Aero dynamic Contrails...... 4 1.4 Persistent Contrails...... 5 1.5 Countries ratifying the Doha amendment...... 6 1.6 Radiative Forcing induced by aviation...... 7

2.1 Contrails...... 11 2.2 MET-GATE...... 15 2.3 MET-ATM SWIM services...... 16 2.4 ADS-B ...... 17 2.5 Schmidt-Appleman Criterion...... 20

3.1 Model View Controller mind map ...... 25 3.2 Application development process...... 25 3.3 An aerodrome style descriptor and aerodrome layer...... 27 3.4 Airspace in 3D ...... 27 3.5 Airspace in 3D ...... 27 3.6 OGC standards ...... 31 3.7 OGC Web Service...... 32 3.8 Web Map Service...... 33 3.9 Web Feature Service ...... 35 3.10 Web Coverage Service ...... 37 3.11 WXXM...... 41 3.12 NetCDF...... 43 3.13 Architecture of the Luciad WMS server...... 44 3.14 Architecture using the Luciad WCS server...... 45 3.15 Architecture using the Luciad WFS server...... 46 3.16 Integrating NetCDF imagery into your application...... 47

4.1 Contrail Service - flow of data ...... 50

vii LISTOF FIGURES

4.2 ConSA Client- flow of data...... 51 4.3 ConSA overview [Operational node connectivity description ...... 52 4.4 ConSA Service interface specification ...... 53 4.5 ConSA Service interface specification ...... 54 4.6 The sequence diagram illustrates the dynamic behaviour of the ConSA Service 55 4.7 The sequence diagram illustrates the dynamic behaviour of the ConSA Client 56 4.8 The sequence diagram illustrates the dynamic behaviour of the ConSA Client 57 4.9 The sequence diagram illustrates the dynamic behaviour of the ConSA Client 58

6.1 4D corridor showing contrail probability along a trajectory from ConSA . . 67 6.2 Overview on ATM Stakeholders ...... 68

viii T hc om h ai fti hssi ecigoe he domains: three over reaching is thesis this of basis the forms which ATM the to information forecasting contrail provide to not, or possible be will it whether rhtcueadslto hl epoie nti hss h nlsso non research ongoing of analysis adequate The an thesis. yes, this is in provided answer be the shall if of solution Furthermore, effect and processes. the architecture daily consider their to in functions assess forming related to aviation contrail is of thesis operators this enable of to Aim stakeholders, systems. IT and bases information data enhance thereby modern to hours, of made 24 introduction are for by efforts persist flow program, or SESAR minutes the in Within formed evaporate clouds. can trails forming impact trails alike an These cloud has aircraft. which are an contrails behind Trails) of Contrails(Condensation forming environment. the Earth’s is aviation to intense from coming effect One aspects key the for are program environment CO2 SESAR Earth’s of the protecting production of and the costs reduce ATM to Reducing fuel flight. saving improveeach decision at to collaborative invested aims and been SESAR processes has Simultaneously structure, Euro making. infra billion ATM 2.1 operations, of related budget traffic a air effort this In Management) gate. Traffic destination (Air ATM Sky [ European program (Single Research) SESAR The considered. be to • • vain nesadn prtoa ed n pin,cretadftr ATM future and current options, and needs operational Understanding Aviation: paradigm. and Services Network, Data, Understanding Technology): (Information IT ie ec ti biu htteipc faito noerhevrnetneeds environment earth onto aviation over of increase impact to the still that is obvious Europe is over it flights Hence of every time. number (SES) Sky the European for Single tendency the The crossing day. are flights 30.000 of average an oday 1 ist piiealflgt cosErp rmdpruegt to gate departure from Europe across flights all optimize to aims ] 1 I NTRODUCTION

C HAPTER 1 CHAPTER 1. INTRODUCTION

concept based on the ATM Master Plan. • Meteo: Understanding availability of met data, ways to analysis of weather data, establishment of forecast data and contrail forming effects.

This thesis aims to investigate the task of forecasting contrails using knowledge of both fields, Aviation and Meteorology. The aim of this thesis is achieved by deploying a contrail forecasting service and client. The service and client are abbreviated to CONSA service and client where CONSA stands for CONtrail Service for Aviation.

Throughout the thesis the focus is on implementing the algorithm, deploying the service and client, however there were many challenges working with diverse services, informa- tion exchange standards and frameworks. The task crucially involves deploying a service which is fast, reliable, real-time and integrable with any aviation platform, in spite of presence of such an imbalanced infrastructure. Specifically the focus is on the future of the service, which will be deployment of the service in the European Aviation infras- tructure. This thesis hence proposes solutions to develop a generalized infrastructure model of the entire Service and framework involved in the light of the future integration. Generalized in this sense means to provide high productivity on previously unknown circumstances.

The aviation industry is undergoing a revolutionary change which includes using such aforementioned infrastructure. This means the task is to choose the service interface, the information exchange standards and the framework very wisely, i.e. in our case depends on the use of forecasted information. The selection should be an information exchange standard which can hold and carry the contrail information unambiguously and uninterrupted. Next task is to select the service interface which would be in sync with the information exchange standard and is reliable. Last and the most important of all the need is to select a framework which would support the selected information exchange standard and the service interface.

To put it in a nutshell, in aviation best infrastructure selection plays an important role and is investigated in this thesis. The following sections describe Contrails essentials, the and related work. The chapter concludes with an overview of the thesis and a summary of our contributions.

1.1 Background

Knowledge of the three described domains has been gathered at Airbus Defence and Space (Germany). The department at Immenstaad participates actively in the SESAR

2 CHAPTER 1. INTRODUCTION work package “SESAR WP11.01”, from where access to latest aviation research under the current ATM Master Plan could be gained. Based on the knowledge of the software development team further research in latest IT had been carried out, in order to understand options and limits of current paradigms. The objectives of SESAR are shown in the pi chart in figure 1.1. The objective of the thesis is one of this objective, i.e. Reduction in environmental impact per flight - the green arc.

Increase in Reduction in Europe’s airspace capacity cost per flight

6% 27%

24.2% Other SESAR goals 40% 2.8% Reduction in Reduction in accident risk per flight environmental impact per flight

Figure 1.1: This diagram explains the objectives of SESAR. SESAR which is an initiative by , Air Traffic Management(ATM) of Europe. This is the first step which has a deadline until 2020. SESAR has several WP which are distributed between public-private firms to achieve the goal of SES.

This was one among the major tasks the team works on, which is a very challenging field in the market of a growing global pollution. Contrail research work has started centuries ago but none of them posses an infrastructure which can be integrated in the existing Aviation environment without major changes. This also means that the forecast information needs to be knowledgeable and flexible enough to work with any aviation scenario. This is only possible with Open Standards. The Airbus Defence and Space exploits all its in-depth expertise in software development and also uses the expertise of major research institutes and companies to maintain a world-leading standard. The research institutes which contributed to the thesis are Deutschen Zentrums für Luft- und Raumfahrt (DLR) and Meteo France. The company which gracefully gave the software framework for the thesis is Luciad. The following subsections provide an overview of the formation of Contrails, the impact to the environment and the radiative forcing index.

3 CHAPTER 1. INTRODUCTION

1.1.1 Formation of Contrails The exhaust contrails. They are formed when water vapour condenses and freezes around small particles (aerosols) that exist in aircraft exhaust. The water vapour comes from the air around the plane and the exhaust of the aircraft. The factors leading to these contrails are relative humidity, temperature, pressure and aircraft exhaust [2][3] and aircraft engine. Various researchers have given their equations, criterion’s, threshold values to predict a contrail occurrence.

The aero dynamic contrails. The contrails occurs due to condensation by rapid de- pression of air which is accelerated. The common one are near the sharp tips [4]. For this the air needs to be very humid and almost saturated and the temperature must be warm (to hold the water vapour) [4]. The phenomenon can be explained with thermodynamics as follows: When the air flowing over the wing has a lower pressure than that flowing underneath it, and because the air flows from high pressure to low pressure, the air also flows from the wing’s bottom to its top. These movements create a vortex, at the tip of the wings. These vortices are lower pressure and temperature areas leading condensation of water vapour.

The figure 3.4 and 3.5 shows each of the contrails. The exhaust contrails are the ones which affect the environment and hence the objective of the thesis is limited to it.

Figure 1.2: Exhaust Contrails Figure 1.3: Aero dynamic Contrails

Cirrus Clouds For the contrails to persist the ice crystals need to be supersaturated [5]. These new ice crystals will grow in size as time passes. When contrails persist for longer duration they form anthropogenic cirrus clouds [6]. The cirrus clouds differ from natural clouds considering their micro-physical properties. Any naive observer must have observed transformation of contrails into cirrus clouds. The image 1.4 shows the sky filled with contrails and cirrus.

4 CHAPTER 1. INTRODUCTION

Figure 1.4: Persistent Contrails.

The contrail stretches for long distances behind an aircraft. Contrails which can persist, last for hours while growing to several kilometers in width and 200 to 400 meters in height. Contrails spread because of many reasons like the air turbulence generated by the passing aircraft or varied wind speed across the flight track. In the upper troposphere there are strong winds to spread the contrails across continents. In the experiment done by Minnis et al. [6] the observed contrails by geostationary satellites lasted from 7 to over 17 hours and expanded across 35000km2. Later the cirrus gets unrecognisable as contrails to the surface observer.

1.1.2 Impacts to Environment After September 9 attacks the national airspace was closed for 3 days from September 11-14 and as in these days no airplanes flew, there were no contrails in the sky. The meteorologists and researchers took advantage of this time. It was concluded that the difference between the day and night temperatures in these days was significant than the other temperature difference observed normally in the US [7]. Hence it was proofed that Contrail affects climate change.

Their radiative properties strongly depend on micro-physical characteristics such as number concentration, crystal shapes, size distribution, and the crystal diameter. Small ice crystals below 20-mm diameter would strongly affect radiative transfer through a cloud if they were present in larger numbers [8].

The contrails reduce the radiation reaching Earth’s surface and also blocks the radiation reflected back from the Earth to the skies(greenhouse effect) [3]. This means there is less radiation reaching the Earth and more radiation trapped in the Earth’s surface and atmosphere. Researchers have declared ’global warming’ in the areas they mostly

5 CHAPTER 1. INTRODUCTION occur [9]. It has its own positive effect and negative effect. But researchers claim the overall net effect is negative.

Another important impact is that the water vapour which would be normally used for the formation of normal cirrus, it gets absorbed for the formation of contrail cirrus [10]. Hence, contrail cirrus have the potential to inflect the optical properties of natural clouds, delaying their formation and substituting them.

Figure 1.5: The diagram above shows the countries participating in the Doha agreement which is extension of the Kyoto protocol. In Kyoto protocol 192 states have an agreement and as of 28 May 2015, 32 countries have ratified the Doha agreement. But for the acceptance of it a total of 144 states should accept it.

The United Nations Framework Convention on Climate Change was extended in 1992 to the Kyoto protocol. It is an international agreement which regulates the emissions harmful to the environment. The Kyoto Protocol was adopted in Kyoto, a city which is naturally decorated in Japan, on 11 December 1997 but came into effect on 16 February 2005. The parties involved have two commitment periods. The first commitment period, has the agenda to reduce the overall emissions by at least 5 percent below 1990 levels between 2008 and 2012. For the second commitment period, the same Parties have agreed, to reduce their emissions by at least 18 percent below 1990 levels between 2013 and 2020. But the Kyoto protocol till today does not concentrate on the contrails, even though it has a huge impact on the climate. The environmental affect of the contrails is estimated to be worst than the affect of CO2 emissions [10]. Aircraft engine emissions like smoke, nitrogen oxides and hydrocarbons are currently regulated (in airport zones) by the FAA and the ICAO [11]. Carbon dioxide regulation is in process. Next in the row will be the Contrail regulation, hence the thesis prepares the aviation community for such a change.

6 CHAPTER 1. INTRODUCTION

1.1.3 Radiative forcing In IPCC Radiative forcing is defined as "It is a measure of the influence a factor has in altering the balance of incoming and outgoing energy in the Earth-atmosphere system." The following are the findings in 1992 and 2000 [12]. It is an index of the importance of the factor as a potential climate change mechanism. In this report radiative forcing values are for changes relative to preindustrial conditions defined at 1750 and are expressed in Watts per square meter (W/m2).

50

40

30

]

2 RF [mW/m2] RF 20 1992 2000

RF [mW/m 10

0

-10

-20 CO2 03 CH4 H20 Direct Direct Contrails Total SulphateSoot Cirrus Aviation induced products

Figure 1.6: The bar graph above gives the radiative forcing from aviation based on Sausen et al. [12].The graph shows the affect of

1.2 Challenges

Irrespective of the clear idea of how there are formed and what effects they have, the algorithm selection problem persisted. In such a forecast problem using artificial intelligence and machine learning could be the best solution, but that required a specific dataset. The dataset should have the airplane properties i.e. airplane speed, engine type and of course the meteorological properties of similar latitude-longitude-altitude of flying. As such a dataset was not available for this thesis, the search was for alternatives.

It was clear that an ideal algorithm development needed meteorological expertise. And hence got allies from this field to help in this thesis.

7 CHAPTER 1. INTRODUCTION

The algorithm used in this thesis needed meteorological dataset of temperature, humidity and pressure of Europe. This dataset should include real-time and forecast numerical data, which should also be accurate. Hence in this thesis a client interface, which could connect to such service and decode the data to numerical format, has been implemented. However, having such connectors and decoders doing real-time operations usually exhibits huge computational complexity. In addition, having a clear display of the output contrail information is also not of less complexity. For this reason, this thesis focuses on a Geo- Informatics System which uses OpenGL and OpenCL for computation and graphics.

1.3 Contributions and Thesis Overview

The main contribution of this thesis is the proposal of the infrastructure, which can forecast contrails in real time and can be instantly used by pilots, ATC(Air Traffic Controllers) to avoid contrails while flying. An Service and Client implementation has been developed with a number of strategies, which will be introduced in next chapters. In addition, the proposed method is very flexible, fast and is able to obtain a 4D display of contrails which will enable end users visualize contrails in order to avoid it.

The presented approach is implemented in form of a Java OGC(Open Geospatial Consor- tium) Web Services. The meteorological services are accessed and decoded in real-time and accurately so that the Contrail output is also precise. Th OGC standards of data exchange, i.e. NetCDF and WXXM are used to seamlessly integrate with the existing infrastructure. A Contrail forecasting algorithm has been integrated in the service itself to deliver fast results. The meteorology data updates to the service are scheduled every 5 minutes with the OpenGL functions of software framework. With similar functions the computation of Contrail points with similar rate is possible.

The strategy is to inform ATM authorities about the contrail predictions so that they use another travel route. The modified route does not necessarily be too much deviated with the original route as the flying altitude is a one of the potential factors to decide if contrails will be formed or not. This means, even a small change in the flying altitude has potential to avoid contrail formation.

The access to the input services and the software framework was provided by the SWIM (System Wide Information Management) with its SWIM Master Class 2015 Competition. This competition is arranged by Eurocontrol, Europe’s ATM. With Eurocontrol’s earlier attempts with SESAR (Single European Sky ATM Research) [4], a public private part- nership project, a number of key changes for the future had already been proposed by the projects team members. SWIM [5, 6] is an important part of SESAR which enables assured standards, information flow, infrastructure and governance. SWIM Master Class

8 CHAPTER 1. INTRODUCTION is held every year and participants from all over the world become a part of it. The aim is to enable global interoperability in the ATM community. In the challenge it provides access to the latest SWIM developments and services through a SWIM registry. With this thesis we participated in the SWIM Master Class competition 2015 and hence had access to various software frameworks and data services.

The thesis proposes to bridge two sides: the latest meteorological research outcome and the aviation community. The purpose of this thesis could be perfectly achieved through SWIM. The determining factors to select the service and framework were, to make best use of the SWIM environment, to build the solution upon existing widespread and SWIM- adopted standards for any demanded transfer of data, to consider a high-performance and user-friendly Software Engine, to cope with mass data of highly complex structures, to build the solution upon existing and fielded systems to demonstrate advantages of enhanced technology and work flow, to foresee open interfaces to existing SWIM services and to consider variable perspectives from different ATM stakeholders (FOC/WOC, ASM, NM).

The web service will work as follows:

• (A built-in OGCWeb Coverage Service client is developed to access live weather data.)

• (This data is fed into the Contrail Calculation Algorithm, which outputs contrail objects based on the given meteorological data.)

• (The resulting contrail forecast information is published via an OGC Web Feature Service.)

To demonstrate the capabilities of the ConSA Service, building on a SWIM environment, and its use in a real mission planning environment, a ConSA Client has been developed. The client as the receiving part of the ConSA SWIM-based service has been implemented as standalone application capable of consuming and analysing contrail forecast data served by the ConSA service, together with live weather data and ADS-B flight tracks. The aim is to provide a means of support to ATM operators in identifying areas (in 4D) of intense contrail forming which in turn leads to forming of cirrus clouds. By use of the service probable environmental impact to the climate can be recognized.

The structure of the thesis document is as follows. The second chapter of the thesis investigates the existence of contrails and provides all relevant details with regards to the object of interest i.e. Contrails. In the third chapter the relevant aspects of the state of the

9 CHAPTER 1. INTRODUCTION art approaches along with our approach is explained. The fourth chapter introduces our software framework to deal with various formats, to develop the services and of course to manage the computational complexity of entire implementation. In the fifth chapter details of the implemented solution are specified and clearly described in detail. In the sixth results of the thesis and conclusion is explained. The last chapter is Appendix which stats the physical interface description of service and client and gives an introduction about the syntax of the service and output standard.

10

T vrteps eaeCnrisrsace aegie uepa.Tecnri pre- contrail The peak. huge a gained have researches Contrails decade past the Over at conditions atmospheric the of glimpse altitude. a below gives an the photograph such excellent and The formation emissions. contrail engine thick shows aircraft over vapour water exhaust of iue21 htgahsoigcnrispoue rmBen 4.CprgtJsfP Willems P. Josef Copyright 747. Boeing from produced contrails showing photograph A 2.1: Figure htcnrisaecmoe fiecytl hc r anyfr ycondensation by form mainly are which crystals ice of composed are contrails like that chemicals emit fuel aircraft the H of burning temperature high he 2 O , CO , SOx , HC eoo n ot[ soot and aerosol , 11 13 1.1.1 section 1 Chapter seen is This ]. S AEO H ART THE OF TATE

C HAPTER CO 2 2 , NOx , CHAPTER 2. STATE OF THE ART diction theory was started by Schmidt (1945) and Appleman (1953). Since then the Schmidt-Appleman criteria [2] has been the basis of various researches in this area. This chapter aims to introduce to you important state-of-the-art contrail forecasting researches.

2.1 Related Work

In the next subsections the aim is to show a short overview of the approaches towards contrail detection and introduce different algorithms. Finally, this section concludes by discussing related work on the problem of integrating such researches in the aviation community.

2.1.1 Statistical Contrail Forecasting This technique was proposed by Jackson et al. [14]

Dataset The dataset used is from the Contrail Field Program which collected aircraft observations and co-incident radiosonde observations for a 10 day period. The aircraft ob- servations included aircraft data like latitude, longitude, altitude, type, speed and whether it produced a contrail or not(manually). The radiosonde data included temperature, pressure, relative humidity and winds within the projects domain.

Algorithm. The Statistical Contrail Forecast Model was built. It is multi-variate linear regression model as the relationship between the predictand (Contrail-yes/no observa- tions) and the predictors (radiosonde weather data) is linear. Input (Predictors) were chosen using a stepwise regression function and performing tests with a null model. This followed with the concept of using only those predictors which would produce the maximum variance in the predictand. Four regression models were developed each with respect to three data quadrants and the last quadrant was used for testing. The output prediction was a probability value.

Disadvantages The dataset was small(557 observations) and the radiosonde data is not accurate. Moreover the radiosonde data is nearly co-incident to aircraft observations but the the algorithm accuracy might depend vastly on this factor.

2.1.2 Prediction of Persistent Contrail Occurrence This technique was proposed by Duda and Minnis [15]

12 CHAPTER 2. STATE OF THE ART

Dataset. Dataset consists of meteorological data (of 15 months from the Advanced Regional Prediction System (ARPS) and the Rapid Update Cycle (RUC)) and the contrail occurrence data (from the surface and satellite observations). Satellite observations consisted visual inspection multi-spectral satellite data to detect persistent contrails. The surface observations were taken by school children in a program called GLOBE. The meterological data was matched with the contrail observation data with the method of linear interpolation.

Algorithm Logistic regression technique was used here too.

where P is the predictand (probability of persistent contrail formation) and predictors x1 (meteoro-logical quantities) to the model. The maximum likelihood method is used to estimate the unknown coefficients of βi and to fit the logistic regression model to the data. Same as proposed by Jackson etall 2.1.1 stepwise regression technique was used to find number optimal number of predictors. Two groups of logistic models were developed. One model used the surface and satellite data along with meteorological data and the other one used just the satellite data along with meteorological data.

Disadvantages As contrail altitude information is missing, it is difficult to use this information. The classification between real cloud and contrails is not possible in the satellite data, hence it results in false positives and false negatives. Moreover the meteo- rological data collection by RUC and ARPS have a drawback in measuring inaccurate relative humidity.

2.1.3 Contrail Cirrus Prediction Tool A new model to predict contrails was developed by Prof. Dr. Ulrich Schumann from DLR. The model is implemented in a tool called Contrail Cirrus Prediction Tool (CoCiP). The model is mathematical model and represented with a Lagrangian Gaussian plume model. This tool uses the Modified Schmidt-Appleman algorithm which was modified by Prof. Dr. Schumann himself in 1996 [16].

Dataset. Dataset consists of meteorological data and air traffic data. The meteoro- logical dataset is taken from European Centre for Medium-Range Weather Forecasts (ECMWF)which is 1-h forecast data at 0.5° resolution in numerical weather prediction.

13 CHAPTER 2. STATE OF THE ART

The air traffic data is taken from Aviation Climate Change Research Initiative (ACCRI) which is forecasted every 12 h.

Algorithm. The CoCiP tool computes contrail prediction in 3 model phases. In the phase 0 - initial conditions of contrail formation; phase 1 - the spreading of contrails shown with a Lagrangian plume model; Phase 2 - contrail evolution until dry-out. The contrail calculation requires about 10 s computing time on a single processor Laptop.

Disadvantages. The tool does not have state-of-the-art interfaces and implementation to be integrated in the aviation domain.

2.2 Proposed approach

In this thesis the focus is on integrating the state-of-the-art contrail forecasting approaches with the existing aviation infrastructure. By this the aviation community would benefit by the contrail forecasting researches. This thesis proposes to develop a contrail forecasting service which is based on a part of the CoCiP tool which was given to us gracefully by Prof. Dr. Ulrich Schumann.

2.2.1 Meteo Dataset The input to the algorithm is meteorological data provided by the MET Information Services Generation, ATM tailoring and Exchange (MET-GATE) schema. The following figure shows the MET-GATE Schema. The schema is accessed by the ATM clients.

The shaded 4D cube is indeed a 4D cube for weather information (4DWxCube). This innovative solution was developed to work with ATM infrastructure. It is formed by the sharing of meteorological information by European MET providers.

MET-GATE services The services are defined such that the information exchange is open and supports international standard. The following are the services offered by the MET-GATE till today.

The service which are used to retrieve weather data is the Wind/Temperature AROME grids. AROME is the high-resolution Meteo France’s model. The aim of the Arome project is to improve local forecasts, especially for dangerous convective phenomena (thunderstorms, flood risk, heavy precipitation) and low-level conditions (wind, tem- perature, ground state, fog, heat islands, etc. ). One of the most interesting features is that Arome will assimilate radar data (Doppler winds and 3D reflectivities) and satellite radiances. The higher resolution of the model improves the meteorological impact of

14 CHAPTER 2. STATE OF THE ART

Figure 2.2: MET-GATE geography in a spectacular way. For instance, the meteorological effects of cities, coasts and large valleys are well represented: urban heat islands, diurnal cycle of sea breezes and valley breezes, frost zones, local winds forced by orography etc. Arome is intended to improve and diversify towards new applications. The geographical area covered by the model is the area defined by (38N, 9W ; 55N, 14E) with a resolution of 0.025° ( 2.5km). AROME provides forecast up to 36h with a 1h time step. It is updated every 6 hours There is one coverage per physical parameter: Relative humidity, Geopotential, Reflectivity, Temperature, Wind speed, Wind direction.

The list of available vertical levels (FL) is [50, 65, 80, 100, 120, 140, 160, 180, 210, 240, 270, 300, 320, 340, 360, 390, 410, 450, 530] for all coverages except for the Reflectivity for which it is [50, 65, 80, 100, 120, 140, 160, 180, 210, 240, 270, 300, 340, 390].

WCS Service The data from the Arome model can be accessed by a WCS service. The details of the WCS service can be found in chapter3 section 3.4.3. The details of the WCS service is mentioned as below: The Server Endpoint: http://claudius.meteo.fr and the Resource: /geoserver/metgate/wcs/

Supported methods: GET queries for retrieving metadata about the service in order to

15 CHAPTER 2. STATE OF THE ART

Figure 2.3: MET-ATM SWIM services know how to use it and coverages of MET Information.

Query Parameters: service [WCS], The service version 2.0, request [GetCapabilities | GetCapabilitiesEnsemble | DescribeCoverage | DescribeEnsemble GetCoverage] The operation name to be requested to the service: coverageId [optional, string], The unique id of a coverage ensembleId[optional, string], The unique id of an ensemble subset [optional, time | height | latitude | longitude], The sub selection coordinates to trim or slice a coverage. The syntax accepted by the subset values is: Slice by time (minValue, maxValue), Trim by time (value). The same applies to height, latitude and longitude. The data output format NetCDF.

2.2.2 Flight Dataset The flight dataset is required by the client to calculate contrails on the path specified. It is provided by Flightradar 24. Flightradar 24 provides real time flight track data from various aircraft around the world. Flightradar24 merges the track data from many different data sources including MLAT (Multilateration), ADS-B (Automatic dependent surveillance- broadcast) and FAA (Federal Aviation Administration.). The data is amassed together with the agenda and flight status data from airports and airlines to create a exclusive flight tracking experience. The tracking information the users receive consists of arrivals,

16 CHAPTER 2. STATE OF THE ART destinations, flight tracks, flight numbers, aircraft types, positions, altitudes, headings and speeds.

Automatic dependent surveillance-broadcast One of the technology which is used by Flightradar24 is called automatic dependent surveillance-broadcast (ADS-B) [17]. The technology can be explained clearly with the image figure 2.4. The location of the aircraft is sent to the aircraft via GPS in satellites. The aircraft have a ADS-B transponder on plane which would transmit a signal containing the location and aircraft data. The signal sent by the ADS-B transponder can be received by certain receivers which are connected to Flightradar24. Receivers recieve the signal and feed it to Flightradar24.

Figure 2.4: ADS-B

Aircraft currently use primary Radar mechanism. The technology ADS-B itself is very advanced in time and is rarely used the aviation authorities. The statistics on the website of Flightradar 24 estimates that in commercial aircraft category : 80% in Europe and 55% in the US are equipped with ADS-B transponder. However ADS-B used in general

17 CHAPTER 2. STATE OF THE ART aviation is below 20%. The technology is greatly appreciated around the world and hence the demand for this technology is increasing evenly. It is predicted that by 2020 ADS-B will be mandatory for all aircraft.

Flightradar24 receives data from more than 8000 ADS-B receivers around the globe and this information is further sent to the company servers. The frequency used for the ADS-B signals is 1090 MHz and the coverage range from the receiver is 250-450 km in all directions but depending on location. Hence there is one shortcoming when flying above the oceans. Generally the aircraft has to fly higher to be covered by the receiver.

There is good coverage in Canada, Mexico, Caribbean, Venezuela, Colombia, Ecuador, Peru, Brazil, South Africa, Russia, Middle East, Pakistan, India, China, Taiwan, Japan, Thailand, Malaysia, Indonesia, Australia and New Zealand.

Estimations Flightradar24 uses estimations to predict the position of aircraft for upto 1 hour, provided the destination of the aircraft is known. The aircraft whose destination is unknown, FR 24 estimated the position for 10 minutes. the position estimated is calculated on the basis of a lot of aircraft data and is generally accurate and in case of long flights it may be about 100km deviation from the estimated path.

SWIM service Flightradar24 is participating in SWIM Master Class 2015 and giving the ADS-B tracking information for free of charge to the participants of SWIM Mas- ter Class 2015. The ConSA service is consumed in ConSA client and show contrail occurrence because of aircraft and how it could be avoided.

2.2.3 Algorithm The contrail formation depends on the atmospheric parameters - temperature, pressure and relative humidity. Before going in to the details of the algorithm, the following paragraphs will explain the properties.

Relative Humidity. Water vapour exist in the atmosphere and is responsible for var- ious green house effect, for cloud formation , precipitation, condensation and freez- ing, etc. The measure of water vapour can be done in simplest way by measuring the number of water molecules per mass of air. It is called absolute humidity. So Relative humidity can be defined as the ratio of partial pressure of water molecules to the partial pressure of water molecules at saturation. It lies in the known percentage range ı.e. 0% to 100%. Relative humidity is used more popular among the scientists being a driven factor for many research topics, including cloud formation. It is entirely property of water vapour and not of any other particles in the air.

18 CHAPTER 2. STATE OF THE ART

Atmospheric Pressure. Pressure is defined as force per unit area. The standard unit for pressure is Pascal. Atmospheric pressure is the force exerted by the weight of air on the Earth’s surface. By this meaning if the number of air molecules increases above a surface, the force exerted by those molecules on the surface increases and thereby the pressure increases and the vice-versa is also true. The pressure measuring instrument is called as barometer and hence atmospheric pressure is also called as barometric pressure. With the increase in altitude above the Earth’s surface, the atmospheric pressure decreases. The atmospheric pressure also plays a key part in Contrail formation.

Ice Supersaturation. Supersaturation means a state of solution that contains dissolved substance than normally it would contain it or in terms of physics, vapour of a compound having higher pressure than normal vapour pressure of that compound. At higher altitudes areas in the troposphere the water saturation often leads to ice supersaturation. However water saturation will not directly lead to ice formation, it requires the relative humidity of ice over atmosphere to be above 100% for ice supersaturation. In upper troposphere the temperatures are generally very low i.e. t > -40°C where pure water will freeze immediately. Ice supersaturation is responsible for formation of clouds and evolution and hence is vital to maintain habitable weather and climate.

Ice formation in the atmosphere is a totally different thing from ice saturation. For ice formation a very high supersaturation would be needed. Ice supersaturation is a metastable state and not an unstable state because ice supersaturation would persist in the atmosphere for long time (more than 24 hours). Ice Supersaturation is very important for Cirrus cloud persistence.

The first observations of Ice supersaturation were made by A.Wegener in 1906 but he and W.Findeisen thought that ice formation came from deposition on solid particles, it was by L.Krastanow and E.Wall who came up with thermodynamic equations of the idea that ice phase originated from liquid phase. But it was in 1945, E.Glückauf and H.K.Weickmann who measured ice saturation in research flights. Later in 1984 Detweiler and Pratt came up with the word ’ice-supersaturated region’ (ISSR). The major important step came with the implementation of ISSR’s into the forecast model of the European Centre for Medium -Range Weather Forecasts(ECWMF) in September 2006.

Graphical Method The pioneers of contrail formation process are Schmidt(1943) and Appleman(1953). Contrail formation is like breathing on cold air; the condensation that becomes visible is due to isobaric mixing of two air masses of different temperature and different moisture content. Mixing of air masses can lead to condensation because the saturation pressure of water vapour decreases almost exponentially with decreasing temperature. Isobaric mixing thus can end up in a supersaturated state even if none of

19 CHAPTER 2. STATE OF THE ART the two mixed air masses was saturated before. The figure 2.5 represents the graphical method to compute contrails. The figure indicates the ’Always’, ’Possible’ and ’Never’ conditions for contrail formation. These conditions are function of atmospheric pressure, temperature and relative humidity.

Relative Humidity (%) 0 60 90 100 100

200

300

400 Pressure (mb) Pressure 500

600

700

800 900 1000 -80 -70 -60 -50 -40 -30 -20 Temperature (°C)

Figure 2.5: A graph of the required relative humidity for contrail formation as a function for pressure and temperature of the environment. The dashed lines are empirically derived curves of contrail probability in percentage.

Mathematical formulation The Schimdt- Appleman criterion (SAC) [2] calculates a threshold temperature such that if ambient temperature lies above the threshold tempera- ture contrail formation is certain. At this threshold temperature the mixture of ambient air and engine exhaust reaches saturation. Contrails can persist for not more than a few minutes if the air is subsaturated with respect to ice; but contrails can persist for up to

20 CHAPTER 2. STATE OF THE ART several hours if the supersaturation with respect to ice occurs, i.e. (RHice > 100%). The input to this algorithm is ambient temperature, pressure and relative humidity.

2 TLM = −46.46 + 9.43 ln(G − 0.053) + 0.72[ln(G − 0.053)]

-1 where G is the gradient of mixing line, unit of G is Pa K and TLM in °C.

c pEI 2 G = p H O (MH2O/Mair)Qfuel(1 − η) where cp = 1004 J (kg K)p is pressure EI

21

ihgorpi oain hsproe r ufildb I plctosb rvdn a providing by applications GIS by fulfilled are purposes This location. geographic with h ups fGSssesrnefo nigadess nigrue,sac for search routes, finding addresses, finding from range systems GIS of purpose The information various obtaining for it use data, geographical huge manage systems These nomto n upr apn n ur oti nomto.Teepit r the are points application. These GIS information. a select this to to this criteria query major share and and mapping display support application information, GIS and this by information process done information, processes geospatial important associated most assemble The are: information functions. of and form interfaces any of display list or criteria a match that interest of point a decision the through us takes application. and through market GIS goes the one section on choosing This available of application. applications GIS GIS is of what digital number resolve manages a to can aimed systems is GIS section these This information. maps. geospatial visualize to analysts. to geoinformation patterns by used be that could libraries that software interfaces of and set functions or predefined frameworks have are (GIS) Systems Information Geographic Systems Information Geographic needs. 3.1 our suite would which service web services a web select of thereby number and a market describes the also in chapter available The implementation. ConSA for GIS I GS,tersfwr irre n hi etrsaedsusdadteeyslc one select thereby and discussed are features their and libraries software their (GIS), oaheeteojcie ftetei.Anme fGorpi nomto System Information used Geographic be of could number which A architecture thesis. of the type of the objectives select the to achieve is to discussion the chapter this n A CIETR AND RCHITECTURE 22 S OLUTION

C HAPTER 3 CHAPTER 3. ARCHITECTURE AND SOLUTION

Applications The GIS applications evaluated in this thesis are Carmenta Engine, Esri ArcGIS Runtime, WorldWindJava, Envitia Maplink Pro and LuciadLightspeed. All latest versions of these products are compared in this thesis.

Carmenta Engine is the product of Swedish software company named Carmenta. The programming languages supported by Carmenta Engine are C++, C#, .NET, Java and Python. A major effort is needed by the developer to visualize data. The approach of Carmenta Engine is to give flexibility to developers to visualize the dataset as required and hence only fundamental visualization tools are provided. OGC web services support is limited in this engine. Carmenta Engine is ISO 9001 certified for its quality.

Esri ArcGIS Runtime is provided by Esri, an international American company. The various SDK’s supported by it are Java, WPF, C++ and .Net. Regarding reading file formats, ArcGIS Runtime can only read package files created in ArcGIS Desktop. These package files can include various data formats. There is limited support for OGC web services.

WorldWindJava is developed by NASA and is an open source map engine. As stated implicitly by its name- it is written in Java. It used Java OpenGL technology to display information in three-dimension. OGC web services and data formats are not completely supported by it.

Envitia is a British company and thier software product MapLink Pro has been examined in this thesis. The API which are supported by it are C++, .NET and COM. But the full-featured one is the C++ API. It uses Microsoft Foundation classes (MFC) to provide a graphical user interface. It support a variety of data formats but to read these data formats at runtime is upto the developers efforts.

LuciadLightpseed is a product of the Belgian GIS software company Luciad. It is platform independent and runs on mobile, tablet, embedded or server-with or without GPU. The classes and functions provided are in Java and it also provided functions and interfaces for easy integration of C#, C and C++ applications. It has pre-implemented OGC interfaces for web services and exchange formats. I found the documentation provided with LuciadLightpseed sufficient for any person who is new to GIS technology. It supports both 2D ad 3D visualization. It has predefined interfaces, classes and functions to read data formats, process information and display them and the developer efforts are completely minimized.

Comparison This section compares the previously introduced GIS applications. As Carmenta Engine is ISO certified it is very reliable product. However it has fundamental

23 CHAPTER 3. ARCHITECTURE AND SOLUTION tools library only. The fact that it has limited OGC support is not a good fact for this thesis as OGC standards implementation are widely required in the aviation community. Esri ArcGIS Runtime seems very much like Carmenta Engine. Although Esri ArcGIS Runtime accepts variety of input formats, it depends on its ArcGIS Desktop application heavily to preprocess data. WorldWindJava has a big advantage of displaying data in 3D but the primary source of data in it is the code itself. Due to this it seems very difficult to understand it, especially for a new comer. MapLink Pro reads very few formats at runtime, this is also a limitation and cannot be accepted because this matters to this thesis a lot. LuciadLightspeed has exceptional features of displaying information in 2D and 3D, large number of libraries support and huge support for OGC standards. Out of all previously mentioned comparisons LuciadLightspeed seems to be performing very well and best amongst all. Hence we choose LuciadLightspeed as the GIS application. The next section explains some features, functions and interfaces of LuciadLightspeed which are used in this thesis.

3.2 LuciadLightspeed

The LuciadLightspeed API is based on the Model-View-Controller (MVC) architecture. This separation results in a simpler design of the application and a higher flexibility and re-usability of code.

Model, View and Controller and their relation among each other is explained as follows:

• Model stores and describes geographical data regardless of how to visualize and interact with the data. • View contains all information for the representation of data contained in models. A view does not contain data itself. • Controller interprets user interaction and performs the required action on models and views regardless of the type of model and view.

By separating the different parts of the application flexibility can be gained in the develop- ment. Reuse of objects for different purposes and redefine objects without changing other objects. For example, change a view without making changes to the models represented in the view. Or redefine user interaction on a view without changing the view. Object reuse shortens the time for writing an application. In addition, it enhances a consistent functionality and design of all your applications.

24 CHAPTER 3. ARCHITECTURE AND SOLUTION

View

Model Controller

Figure 3.1: The underlying concept of the MVC architecture is to separate the data (model), representation of the data (view), and the user interaction (controller) from each other.

Building applications with LuciadLightspeed The process to create an application covers the following functions:

• Define the model. • Create layers for the model. • Define View and add layers to the view. • Define controller for the view.

Model Layer View Controller

Figure 3.2: The separate components of LuciadLightspeed application.

There is flexibility of adding layers to an existing view, adding multiple layers onto the same view, update and display views when model data changes. One can select or deselect the layers which shall be visible on the map. This is helpful at times when the user needs to focus on one model.

Data formats support It supports use of various standards of data formats through:

• Model decoders, encoders provided with the API • Self-created Custom model decoders and encoders are easily developed for un- definded data formats.

25 CHAPTER 3. ARCHITECTURE AND SOLUTION

Styling data with OGC SLD A Styled Layer Descriptor (SLD) [18] is an XML schema specified by the Open Geospatial Consortium (OGC) for describing the appear- ance of geospatial layers. It allows to define uniform styling information for geospatial data through symbology encoding. Symbology encoding is based on the paradigm that style and content should be separated. As Luciad- Lightspeed adheres to the same paradigm, it is particularly well-suited to implement SLD. Although the styling model may be constructed programmatically, it is usually decoded from XML files. This facility helps us to speed up the development process. SLD addresses to the requirements of the individuals and software itself to have the ability to control the visual sketch of the geospatial data. In case of a client server architecture the styling rules are required to be understood by both sides.

It was initially designed for Web Map Service (WMS) but later it was found useful in applications and other services too. WeThe next chapter will introduce the details about OGC web services. Below is a part of Aerodrome SLD.

Listing 3.1: MyAerodromeType.sld Aerodrome</ Title> <WellKnownName>circle</ WellKnownName> < S t r o k e > <SvgParameter name="stroke −o p a c i t y">1.0</SvgParameter> < / S t r o k e > <Size>17.0</Size> <Rotation>0.0</Rotation> < / Graphic ></p><p>26 CHAPTER 3. ARCHITECTURE AND SOLUTION</p><p>Figure 3.3: The xml file above is an example of a style layer descriptor. This sld is a part of an aerodrome SLD from CAPS. The screen shot below it shows the aerodrome layer. The circle icons are the aerodromes. There are different layers in the application, as shown in a grey tab. One can select/deselect layers in real time. As the selection is HomeBase layer hence the maps shows aerodromes.</p><p>Figure 3.4: Airspace in 3D Figure 3.5: Airspace in 3D</p><p>Switching between 2D and 3D views LuciadLightspeed supports two-dimensional (2D) as well as three-dimensional (3D) visualization of the same data. Switching between the two visualization types is made easy by the availability of the class TLspViewTrans- formationUtil, which has methods to configure a view as either 2D or 3D. If a toolbar</p><p>27 CHAPTER 3. ARCHITECTURE AND SOLUTION is added to our java frame, a switch between a 2d view and 3D view type at runtime is possible.</p><p>3.2.1 Powerful Features Object oriented. It follows object oriented rules and patterns like, Model-View- Controller architecture, use of interfaces and the event mechanism for dynamic behaviour.</p><p>Open. All the components are fully customizable. There are no restrictions on data source format, user interface, platform or architecture.</p><p>Modular and scalable. The modular setup of LuciadLightspeed allows to write a basic application, extend it to your needs, and add specialized functionality to it by using one or more of the LuciadLightspeed Additional and Industry Specific Components.</p><p>GPU leveraging. It uses the OpenGL API for 2D and 3D rendering in a hardware accelerated view. This allows LuciadLightspeed to leverage the full parallel processing power of the GPU.</p><p>Asynchronous processing. Expensive computations that cannot be offloaded to the GPU are performed in background threads. This makes applications responsive all the time.</p><p>Bulk operations. To reduce low-level overhead from recurring actions, such as re- peated method calls, LuciadLightspeed operates on batches of data rather than individual data items wherever possible. For instance, when rendering a large number of placemark icons on the screen, LuciadLightspeed collects the coordinates of these placemarks, and sends them to the GPU in a single batch, rather than drawing them one by one with separate rendering calls. This improves concurrency between the CPU and GPU.</p><p>Lazy loading of data. Applications are able to retrieve large data sets without prepro- cessing [19], and visualize the data on the fly.</p><p>Caching. LuciadLightspeed uses caching for many operations, particularly to optimize the speed for visualizing data. Caching is, for example, used for performing repeated geographical transformations.</p><p>Fast spatial queries. LuciadLightspeed uses spatial indexes to efficiently perform spatial queries.</p><p>28 CHAPTER 3. ARCHITECTURE AND SOLUTION</p><p>Sustainable. The regular LuciadLightspeed releases provide up-to-date functionality with a strong focus on backwards compatibility.</p><p>3.2.2 Benefits of Geospatial display • High resolution displays: By the parallel handling of pixels, lightspeed views scale well.</p><p>• Open All the components are fully customizable. There are no restrictions on data source format, user interface, platform or architecture.</p><p>• Antialiasing: The smoothing of jagged edges of curves and diagonal lines increases display quality. This is achieved with no performance laws.</p><p>• Fluent animations: this views are designed with high frame rates.</p><p>• Density painting: Uses a GPU in the view, which allows for interactive analysis capabilities such as density plots n air traffic.</p><p>• Hypsometry: Analysis of terrain analysis is instantaneous through judicious use of the GPU in the terrain analysis components.</p><p>3.3 Web Services</p><p>In this section the discussion is the web service interfaces available on the market. A web service is simply any service available through web. The simple example of a web service is the Google weather check service, where a person enters the name of the place and in return the web service provides detailed weather of that place. As this thesis is weather and geographical location related and its main objective is to be integrated in the aviation environment OGC web services are best candidate for this work. The next section details about what OGC stands for, the different types of OGC web services and select one OGC web service for ConSA implementation.</p><p>3.3.1 Open Geospatial Consortium The OGC originated in 1994, is an international consortium with 517 members, which include universities, companies and government agencies. It uses a consensus process to develop publicly available interface standards. The standards includes Geo-Solutions for the IT, Internet and the Wireless. With such standards the developers get the power to create complex software and services which would be useful for everyone.</p><p>OGC standards are used in the following domains</p><p>29 CHAPTER 3. ARCHITECTURE AND SOLUTION</p><p>Aviation. The Aeronautical Information Exchange Model (AIXM) and the Weather Information Exchange Model (WIXM) are two information exchange formats which are very ahead in the development and usage by several aviation organisations. Both are using OGC Geography Markup Language (GML) Encoding Standard.</p><p>Defence and Intelligence. The defense and intelligence organisations around the globe are walking towards the direction of web-based information system which are designed to use open standards, of course including OGC standards, now that everyone understands that custom or proprietary approaches cannot provide interoperability across the global processes and domains. OGC web services, file exchange formats and other standards are been used in this domain.</p><p>Mobile and Internet. The OGC GeoMobile Concept Development initiative was aimed to investigate and address mobile location issues. This initiative brought the OGC Open GeoSMS Standard and the Augmented Reality Markup Language (ARML).</p><p>Energy & Utilities. One of the electric power industry standard for the Smart Grid is the Common Information Model (CIM). CIM enables application software to exchange information about the configuration and status of an electrical network. CIM is synchro- nized with WXXM. Similarly various other standards in the energy sector have started using the OGC standards.</p><p>My thesis lies in the aviation domain. During the research internship the AIXM model for the airspaces had been used. This time for contrails the WXXM model is selected for Contrails. This chapter details these models in context of the thesis.</p><p>3.3.2 OGC standards Geospatial web services or applications have specific requirements like uninterrupted access of location information, working with different coordinate reference system of the Earth, meta data, etc. With OGC standards in place the aforementioned requirements are met, plus additional interfaces which would ease software development are also achieved. The standards deliver everything from satellite based Earth imaging system to presenting GeoInformatic System (GIS) data layers. All the standards are developed keeping interoperability in mind and hence it is first choice of not only developers but also the consumers. Another advantage is it accelerates development, i.e. when the team uses Open standards, weeks of development time are saved.</p><p>OGC standards are technical documents which have detail information about the in- terfaces and encodings. The software developers use these documents to build open</p><p>30 CHAPTER 3. ARCHITECTURE AND SOLUTION interfaces and encodings into their products and services. An important point is plug and play functionality because of use of OGC standards, this can be explained as follows: when two developers work independently implementing OGC standards, the resulting products would plug and play. The standards and the documents are freely available to users. Some of the OGC standards which are used in my thesis are listed in the diagram below and would be explained in the following sections.</p><p>OGC</p><p>Information Web Services exchange models WMS GML</p><p>WFS NetCDF</p><p>WCS WXXM</p><p>AIXM</p><p>Figure 3.6: The tree above covers some of the OGC standards. Of course this tree is not complete, the above tree only represents the services and models relevant to the thesis work. I have grouped them in ’web services’ and ’information exchange models’.</p><p>3.4 OGC Web Services</p><p>A functionality of a OGC web service can be summarized by the diagram below.</p><p>A web service is a communication between any two electronic devices on web. OGC Web Services (OWS) came into being for a specific purpose of exchanging and process- ing geospatial information. OWS use open internet standards like Uniform Resource Locator (URL), World Wide Web (WWW), Extensible Markup Language (XML), etc. It has several advantages for geoinformatics domain and also have advantages of build- ing independent, self-illustrating and modular applications which can be published and accessed from any where across the globe.</p><p>The types of web services and their respective domains are discussed in next sections.</p><p>31 CHAPTER 3. ARCHITECTURE AND SOLUTION</p><p>Figure 3.7: The above diagram shows the architecture of an OGC Web Service. There are three tiers as shown in the figure. The data tier has various formats according to the service in operation. The client can be a HTML client, a standalone application or an applet, depends upon the user requirements.</p><p>3.4.1 Web Map Service The OGC Web Map Service (WMS) was developed in 1999. The WMS defines a protocol standard to transfer geospatial maps from the servers to the client through the internet. It caters a HTTP interface to transfer this information. A single WMS client can access more than one WMS service and accept map images from all of them. The WMS service works very fast, as it transfers only those map images which the user is currently looking at rather than downloading all the data.</p><p>The communication between the server and client is done with the following interfaces:</p><p>GetCapabilities. The client sends GetCapabilities request to understand what the WMS server offers. The offers include the services, data and operations. A example of WMS client request is:</p><p> http://localhost:8080/geoserver/wms? service=wms& version=1.1.1& request=GetCapabilities</p><p>This request passes three parameters to the WMS server, service, version and request. The service parameter acknowledges the server that a WMS request is in on the way.</p><p>32 CHAPTER 3. ARCHITECTURE AND SOLUTION</p><p>Figure 3.8: The above figure shows block diagram of the working principle of a WMS. Initially a Client request Map from the server. The gray box above is the server. The server tasks include to load and filter data, apply style rules and then render an image. It then sends an image as response to the clients query. Please note there is one request block drawn in the figure (because of space adjustments) but in reality there are other requests which are explained below</p><p>The WMS standard requires the specification of these three parameters. The reply from the server is a XML document giving a description of the service. The main sections of the reply are the service metadata, the functions provided by the WMS service and the layers.</p><p>GetFeatureInfo. This operation requests the attribute data of the features. Generally this operation is never used for getting feature information, there is another service namely Web Feature Service which is in many ways advantageous to use than this operation.</p><p>GetMap. This operation requests the server a map. The parameters include a spatial reference, height, width of the output. The output is a map image, and the image format depends on the format requested. But it is always only an image.</p><p> http://localhost:8080/geoserver/wms? request=GetMap& service=WMS & version=1.1.1 &</p><p>33 CHAPTER 3. ARCHITECTURE AND SOLUTION</p><p> layers=toppstyles=population & srs=EPSGbbox=-145.1510405,21.73191979,-57.15489421,58.96105864 & width=780 & height=330 & format=image</p><p>DescribeLayer. This operation is used for the convenience of Style Layer Descrip- tor (SLD) based WMS as the developer needs to know the structure of the data. This operation is also available in WFS.</p><p>GetLegendGraphic. This operation generates legend graphics as images. It can agen- erate the style defined by the server or by the as requested by the user.</p><p>3.4.2 Web Feature Service The maps returned by a Web Map Service are generally rendered in a pictorial format such as PNG, GIF or JPEG. Consequently, it is not possible to select individual objects on a map. This makes the WMS less suitable for clients that want to do further analysis on the returned map besides displaying it. Through the GetFeatureInfo request, one can only request more information about specific points on a map. This limitation contrasts with the OGC Web Feature Service interface (WFS) for example. WFS provides geographic information in the OGC Geography Markup Language, a ”rich” vector format, without any prior interpretation or rendering. In WMS service the exchange format was images, whereas in WFS service the exchange standard is the source code behind these images. HTTP is the platform and GML (a sub part of XML) is the information exchange format. A WFS client can access various WFS server’s together and combine their result.</p><p>Some of the interfaces defined for the WFS standard for access and manipulation of geographic feat</p><p>GetCapabilities. The client sends GetCapabilities request to understand what geo- graphic features, which range, which formats are offered by the service.</p><p>This request is same as the WMS server’s GetCapabilities request. This request passes three parameters to the WFS server, service, version and request. The service parameter acknowledges the server that the client wants to access the WFS service. The version parameter always should be a full version number like 1.1.0. And the request param- eter mentions the request name. It is important as there are more request types. The GetCapabilites response is a huge XML file.</p><p>34 CHAPTER 3. ARCHITECTURE AND SOLUTION</p><p>Figure 3.9: The above figure shows block diagram of the working principle of a WFS. Initially a WFS Client request Features from the WFS server. The gray box above is the server. The server tasks include to load and filter data and encode features. It then sends a GML file as response to the clients query. Please note there is one request block drawn in the figure (because of space adjustments) but in reality there are other requests which are explained below</p><p>A example of WMS client request is:</p><p> http://example.com/geoserver/wfs? service=wfs & version=1.1.0 & request=GetCapabilities</p><p>DescribeFeatureType. This operation requests a description of the type of feature, the datatype, the operations performed on them. It is sent before sending a GetFeature request to have a clear understanding of which feature should be asked before hand.</p><p> http://example.com/geoserver/wfs? service=wfs& version=2.0.0& request=DescribeFeatureType</p><p>GetFeature. This operation requests geographical features. The basic request is as follows:</p><p>35 CHAPTER 3. ARCHITECTURE AND SOLUTION</p><p> http://example.com/geoserver/wfs? service=wfs& version=2.0.0& request=GetFeature& typeNames=namespace:featuretype</p><p>The response to this request will be the geometries of all requested features, usually this request returns a very huge response. The other ways to make this request more specific is by passing several additional parameters.</p><p>To request one single features, one can use the featureID of the important feature. But sometimes the featureID is unknown at such time one can limit the maximum features by a count parameter. With this approach one can also add an attribute parameter to be able to sort the data with sort parameter. If a user want request GetFeature by only attribute value rather than on feature value, parameter propertyname could be used. User can also set multiple attributes separated by commas.</p><p>Until now the requests were being non-spatial, independent of geometry but GetFeature can also be request features based on geometry. Filtering by bounding box, BBOX approach can be used for this. This parameter asks for features situated inside this box. The following is an example of bounding box:</p><p> http://example.com/geoserver/wfs? service=wfs& version=2.0.0& request=GetFeature& typeNames=namespace:featuretype& srsName=CRS & bbox=a1,b1,a2,b2 bbox=a1,b1,a2,b2 where a1,b1,a2,b2 are the coordinates where the coordinates order depends on the coordinate system used by the user. And the two corners specified in the bounding box can be bottom left and top right or bottom right and top left.</p><p>LockFeature. The lock feature is used to achieve consistency in the write mechanism. When one client fetches a features, edits it and submits it back to the WFS, no other client is allowed to retrieve the same feature at that time. This mechanism is not supported by many servers, but the user will get the knowledge if the server supports this or not in the GetCapabilities response itself.</p><p>36 CHAPTER 3. ARCHITECTURE AND SOLUTION</p><p>Transaction. The transaction operation supervises the transaction of the WFS service. Its tasks include creation, deletion and modification of features piblished by the WFS.</p><p>3.4.3 Web Coverage Service Coverages is the term used for geographical information especially which varies on location. The Web Coverage Service (WCS) deals with this type of data. Unlike the WMS which gets the image of the map, it gets the raw imagery of the map. There are a lot of similarities between WMS and WCS like they can return the same output format, but the dissimilarities are important. WCS deals with images and their metadata, and thus allows requests for backend data returns data in original format, which can be processed after receiving not just displayed. WCS is used for delivery of data such as satellite images, climate information, weather forecasts and other such domains.</p><p>Figure 3.10: The above figure shows block diagram of the working principle of a WCS. Initially a WCS Client request Coverages from the WCS server. The gray box above is the server. The server tasks include to load and filter data and encode data. It then sends a file as response to the clients query. Please note there is one request block drawn in the figure (because of space adjustments) but in reality there are other requests which are explained below.</p><p>The Web Feature Service (WFS) returns the discrete features whereas the WCS returns the coverages which vary with location and are temporal in nature.</p><p>WCS can perform the following operations:</p><p>37 CHAPTER 3. ARCHITECTURE AND SOLUTION</p><p>GetCapabilities. The GetCapabilities request is to query the server on which opera- tions are services are supported by it. The WCS GetCapabilities request is as follows:</p><p> http://localhost:8080/geoserver/wcs? service=wcs& version=1.1.0& request=GetCapabilities</p><p>This request passes three parameters to the WcS server, service, version and request. The service parameter acknowledges the server that a WCS request is in on the way. The WCS standard requires the specification of these three parameters. The reply from the server is a XML document giving a description of the service. The main sections of the reply are the service metadata, the functions provided by the WCS service and the layers.</p><p>DescribeCoverage. The DescribeCoverage request is done before GetCoverage to get a knowledge about which coverages the service offers, what is the format of the coverage, which is the area of the coverage etc.</p><p> http://localhost:8080/geoserver/wcs? service=wcs& version=1.1.0& request=DescribeCoverage& coverageId=TMP</p><p>GetCoverage. The GetCoverage operation requests the spatial-temporal data. It queries coverages and the data can be filtered with a lot of parameters. It can also encode the data formats and return the resulting file in various formats.</p><p> http://localhost:8080/geoserver/wcs? service=wcs& version=1.1.0& request=GetCoverage& coverageId=TMP</p><p>Comparison WMS displays information in the form of images. WFS on the contrary is useful for displaying geographic feature information, which can be created, modified and deleted from the maps. WCS is used to display coverages - i.e. displaying features covering an area. For processing, sharing and using Contrail information interactively WFS service would be the best candidate and hence it is selected for the ConSA service implementation.</p><p>38 CHAPTER 3. ARCHITECTURE AND SOLUTION</p><p>3.5 Information exchange format</p><p>Information sharing is an important part of the aviation community. There are different tools, systems and various domains who require information from each other. Earlier these systems used paper to exchange information and the exchange scenario was person to person based. But with the systems updating to the new technology the old methods are outdated. For exchange of Contrail information a data standard which can represent Contrail and can be visualized geographically is needed.</p><p>OGC consortium created standards for the dissemination of information though which in- formation exchange is possible at sensor to sensor level and near realtime. Through these interfaces information is now portable and interoperability between different domains is established. In this section some of the standards used in the thesis are discussed. Aero- nautical Information Exchange Model (AIXM) and the Weather Information Exchange Model (WXXM) both are derived from the OGC Geography Markup Language (GML) Encoding Standard. The NetCDF (Network Common Data Format) standard is also a OGC standard used by GIS and various research oriented data.</p><p>Geography Markup Language The Geography Markup Language (GML) is based on XML language. GML was exclusively created to be support Geopsatial community as it has specific and wide variety of applications. GML encodes geographical feature information, also encoding many features together forming a feature bundle. It facili- tates open international standard for geographic applications to exchange information freely and compactly. A GML document has two parts, one is the schema-describes the document and second is the actual content of the document. The OGC WFS Service uses GML to exchange the information between client and server. Features make up a GML document. A feature includes geometry, location, time and other list of properties. Geometries include point, line, rectangle, polygon. Properties include name, type, value and description. GML consists of a spatial reference system which references features to geographic co-ordinates on Earth. To see how a GML is build for a particular feature below is a XML string:</p><p>Listing 3.2: GML <Feature fid="101" featureType="School"> <Description>Class</Description>> <Property Name="Students" type="Integer" value="10"/> <Polygon name="extent" srsName="epsg:156"> <LineString name="extent" srsName="epsg:156"> <CData></p><p>39 CHAPTER 3. ARCHITECTURE AND SOLUTION</p><p>481898.9999999,5358055.9999999 485804.9999999,5468144.9999999 481918.9999999,5358074.9999999 482924.9999999,5448264.9999999 481935.9999999,5358089.9999999 491977.9999999,5468720.9999999 481963.9999999,5358017.9999999 </ CData> < /LineString> < /Polygon> < /Feature></p><p>As seen above how easily a feature can be written in GML. If the need is to add more details, it is easily editable. GML also has the property of transforming into other XML files or SVG image file. While GML could serve a broad domain of aviation systems, GML got further divided into special formats on the basis of its use. Aeronautical Information Exchange Model(AIXM), Weather Information Exchange Model (WXXM) and Flight Information Exchange Model(FIXM) are some of the standards in Aviation based on GML. WXXM is explained below in details.</p><p>Weather Information Exchange Model As the digitization of information process continued, the weather information was also modified and advanced to be able to integrate in modern systems. Eurocontrol, Federal Aviation Administration (FAA) came together with World Meteorological Organisation (WMO) to form this open integrated weather standard, which was later named as WXXM. WXXM support the ICAO and remaining user requirements of various meteorological information by simple representation in one file in and one format. It supports standardisation as it is in alignment with ISO standards for geographic information, which includes the inheritance of the GML. It is in order with OGC best practices for geospatial information. Its modular architecture is built in such a ways that it can be extended to support future needs.</p><p>In the above diagram the component development agility is low at the XML block and increases as one travels to more abstract layers upwards, becoming maximum at the top layer.</p><p>WXXM document has two parts:</p><p>• The WXXM Conceptual Model (WXCM): The model is designed using UML. The model desribes features and its properties, giving a abstract idea of meteorological domain.</p><p>40 CHAPTER 3. ARCHITECTURE AND SOLUTION</p><p>Figure 3.11: WXXM data model</p><p>• The WXXM XML Schema (WXXS): The Schema is the final model for weather exchange. The schema is an implementation of the Conceptual Model.</p><p>Before WXXM an example METAR information is given as follows:</p><p>METAR KTTN 051853Z 04011KT 0800 SN BKN003 OVC010 M02/M02 Q1013 NOS</p><p>The above format is very compact, consumes very less bandwidth and is ideal for humans. But it is not ideal for machines. Below is an example of WXXM METAR information of the above line. Due to space limitations I have only shown a part of the METAR information, the actual WXXM file is larger than this.</p><p>Listing 3.3: WXXM <om:featureOfInterest xlink:href ="#id2"/> <om:result> <avwx:AerodromeWx gml:id ="id10"> <avwx:airPressure uom =" mBar">900</avwx:airPressure> <avwx:airTemperature uom ="C">30</ avwx:airTemperature></p><p>41 CHAPTER 3. ARCHITECTURE AND SOLUTION</p><p><avwx:dewpointTemperature uom ="C">20</ avwx:dewpointTemperature> <avwx:verticalVisibility uom ="NM">2</ avwx:verticalVisibility> <avwx:windDirection uom ="deg">30</ avwx:windDirection> <avwx:horizontalVisibility gml:id ="hv1"> <avwx:minimumVisibility uom ="NM">5</ avwx:minimumVisibility> <avwx:directionMinimum >NW</ avwx:directionMinimum> < /avwx:horizontalVisibility> <avwx:windSpeed uom =" kt">15</ avwx:windSpeed> <avwx:qnh uom =" mBar">900</avwx:qnh> <avwx:qfe uom =" mBar">900</avwx:qfe> <avwx:cloudCondition gml:id ="cc1"> <wx:base uom =" ft">2000</wx:base> <wx:cloudType >CUMULUS< /wx:cloudType> < / avwx:cloudCondition> <avwx:cloudCondition gml:id ="cc2"> <wx:base uom =" ft">15000</wx:base> <wx:cloudType >CIRRUS< /wx:cloudType> < / avwx:cloudCondition> < / avwx:AerodromeWx> < /om:result></p><p>Network Common Data Form This project is supported by University Corporation for Atmospheric Research (UCAR). The file format Network Common Data Form (netCDF) is platform independent and used for storing multidimensional scientific data. It represents multidimensional data in array-orientations. An example of such data can be weather data like windspeed, pressure and humidity. See the image below to understand the multidimensional representations clearly.</p><p>Such files can be filtered for a specific value like only pressure, or for a specific dimension like time. The NetCDF file format is an OGC open standard and is developed to help digitizing the scientific data for modern technology. NetCDF can be edited and visualized by a lot of freely available libraries and toolkits easily available on the web. This format is very common in atmospheric scientific observations and as well as numerical modelling.</p><p>The NetCDF file come with 3 binary formats:</p><p>• The Classic format: It is the default format for file creation</p><p>• The 64 bit offset format: It was introduced to have larger files.</p><p>42 CHAPTER 3. ARCHITECTURE AND SOLUTION</p><p>Figure 3.12: NetCDF file format: The data cube can be 3 dimensional or even hyper-dimensional. The data represented in NetCDF file is weather data represented at a location (x,y) at an altitude and time. As it is very difficult to visualize 4D data, this was the best way to understand how NetCDF stores this type of data.</p><p>• The HDF5(Hierarchical Data Format) format: It is the HDF5 data format which has advantages of having larger files and multiple unlimited dimensions.</p><p>In all formats there are two parts the header which specifies the structure of the whole file and the other part is the actual data.</p><p>3.6 OGC Web Server Suite</p><p>This section explains LuciadLightspeed’s OGC web server suite which offers the inter- faces defined by OGC and additionally it also provides the developers with additional plug-ins so that the speed of the development of software accelerates. For example it has built in encoders and decoders for accessing data sources in any data type. Also if user has certain different data formats the user can create custom encoders and decoders easily using existing LuciadLightspeed functions. To illustrate this, the WFS server sample plugs in the LuciadLightspeed encoder for the GeoJSON format. The LuciadLightspeed OGC servers are delivered as Java servlets, which need to be installed in a servlet con- tainer. The servlet container by default is Jetty but users can switch to another container if they want.</p><p>Luciad WMS server A Luciad Web Map Service is inline to OGC Web Map Service. The following figure shows the architecture of a Luciad Web Map service. The architec- ture shows at the data tier which types of file formats are compatible with the Luciad WMS server. The client can be an HTML client, a standalone application or an applet.</p><p>43 CHAPTER 3. ARCHITECTURE AND SOLUTION</p><p>The styling of the geospatial data Luciad has additional classes. Different visualizations of the same geographical data can be achieved by the WMS by defining a number of styles per map. When requesting a map for which multiple styles are available on the WMS, the user can specify which style must be used for its rendering. Sometimes there are more custom needs for highly advanced rendering options, for which the map-styling language, called the Styled Layer Descriptor (SLD) is used. The SLD section can be found in depth at 3.2.</p><p>Figure 3.13: Architecture of the Luciad WMS server: The architecture is divided into data tier, middle tier which is the server tier and the client tier. The Luciad WMS server supports various file formats and database formats as shown in the data tier. The client tier has a Luciad WMS client which can be visualized in HTML or in standalone application or in applet in any system which supports OGC WMS.</p><p>Luciad WCS server A Luciad Web Coverage Service is inline to OGC Web Map Service. The following figure shows the architecture of a Luciad Web Coverage service. The OGC WCS specification defines a standard web service interface for the querying of coverages. Coverage data is information which changes with change of space. Typical examples of coverages are demographic information, such as population density, weather charts showing temperature for example, or elevation maps. You can find the Web Cover- age Service specification in section 3.4.3. A WCS client initially queries a WCS to know which coverages are offered. This type of request is called the GetCapabilities request. Based on the returned information, the client can decide to retrieve more information about a coverage or to request a certain coverage. The DescribeCoverage request gives a full description of one or more coverages served by the WCS. The GetCoverage request allows to retrieve a coverage in a known coverage format, for example GeoTIFF.</p><p>The Luciad WCS server offers support for versions 1.0.0 and 1.1.0/1.1.1 of the WCS</p><p>44 CHAPTER 3. ARCHITECTURE AND SOLUTION</p><p>Figure 3.14: Architecture using the Luciad WCS server: The architecture is divided into data tier, middle tier which is the server tier and the client tier. The Luciad WCS server supports various file formats and database formats as shown in the data tier. The client tier has a Luciad WCS client which can be visualized in standalone application or in Luciad WMS in any system which supports OGC WMS. specification, and is certified OGC-compliant. A Luciad WCS clien is used to accept 4D information from METEO France WCS server.</p><p>Luciad WFS server The OGC WFS specification defines a standard interface for querying and manipulating geographic data. The queries you formulate can be based on various spatial and non-spatial constraints, as defined by the OGC Filter specification. You can find the Web Feature Service specification in section 3.4.2.</p><p>Typically, a WFS client starts querying a WFS server to know which geographic features are offered. This type of request is called the GetCapabilities request. Based on the returned information, the client can decide to retrieve more information about a feature or to request a feature. The DescribeFeatureType request gives a full description of one or more geographic features served by the WFS. The GetFeature request allows to retrieve a geographic feature in a known format. Next to these requests, a set of optional operations are defined that allow a WFS to service transaction requests. A transaction request can be used to create, update or delete geographic features. The WFS specification uses GML, another OGC standard, as the default exchange format for geographic features. A Web Feature Service provides geographic information in a rich format, without any prior interpretation or rendering, and with full georeferencing. This contrasts with the WMS interface, which renders maps on the server side and returns simple images to the client.</p><p>45 CHAPTER 3. ARCHITECTURE AND SOLUTION</p><p>Figure 3.15: Architecture using the Luciad WFS server: The architecture is divided into data tier, middle tier which is the server tier and the client tier. The Luciad WFS server supports various file formats and database formats as shown in the data tier. The client tier has a Luciad WFS client which can be visualized in standalone application or in Luciad WFS in any system which supports OGC WMS.</p><p>3.6.1 LuciadLightspeed NetCDF Industry Specific Component The NetCDF Industry Specific Component in LuciadLightspeed decodes rectilinear grids with equally spaced coordinates. The grid can be defined in geodetic longitude and latitude coordinates, or in grid coordinates. The supported measurements can be defined along a list of time values, a list of height values, or both. With the NetCDF Industry Specific Component, it is possible to:</p><p>• Decode NetCDF files into models with rasters</p><p>• Visualize the NetCDF rasters in different ways</p><p>The NetCDF component decodes grids of NetCDF measurement data into ALcdImage objects, which you can visualize on your map. The measurement values are mapped to an appropriate color set for visualization. By default, the NetCDF component decodes all variables, but it also allows to select a subset of data, and decode the data for one variable only. You can also filter the decoded NetCDF data, and visualize just the data measured at a specific point along the available data dimensions. For example, you can visualize just the temperatures recorded at a specific altitude and time.</p><p>46 CHAPTER 3. ARCHITECTURE AND SOLUTION</p><p>Integrating NetCDF imagery into your application The basic steps to visualize NetCDF data in an application are shown in figure 3.16. To decode the NetCDF model, pass a NetCDF file with the extension .nc or .netcdf to a TLcdNetCDFModelDecoder. The resulting model is a TLcdNetCDFFilteredModel, containing one or more NetCDF objects, or an ILcdModelTreeNode containing one or more TLcdNetCDFFilteredModel objects, depending on the structure of the NetCDF file. A NetCDF domain object is an ILcdDataObject with an image property that contains an ALcdImage. For more information about the model structure, refer to the reference documentation of the TLcdNetCDFModelDecoder.</p><p>Adding the layer to the map</p><p>Creating a NetCDF layer for the model</p><p>Decoding a NetCDF model</p><p>Setting up a map</p><p>Figure 3.16: Integrating NetCDF imagery into your application: The above steps are taken to access NetCDF data, process it and visualize it.</p><p>Customizing the decoding and visualization process NetCDF allows multiple sets of measurement grids in a single file. One single set of measurements, such as humidity or temperature, constitutes a variable. By default, the TLcdNetCDFModelDecoder class decodes all variables, creating an ILcdModel class for each variable. You can retrieve the list of variables of a particular dataset by calling the decoder’s getDataSources method. To decode only a subset of the file, pass one of the returned data sources to the decoder’s decode method again.</p><p>Many NetCDF models contain a set of measurement grids, each of which is associated with a particular point in time and/or a vertical position. To visualize a particular mea- surement grid, the NetCDF model is able to filter itself. TLcdNetCDFFilteredModel class allows querying the dimensions that can be filtered, and configuring a parameter or interval for every dimension, time and altitude for example, to filter out the desired</p><p>47 CHAPTER 3. ARCHITECTURE AND SOLUTION measurement grids. You can filter out the measurement grid captured at an altitude of 827 meters on January 20, for instance.</p><p>LuciadLightspeed allows you to customize the visualization of NetCDF data, either by mapping data values to colored pixels, or by displaying a grid of icons. The latter method is suitable for NetCDF models containing multiple values. It combines the values of different parameters for the same position, and displays them as a single icon. A symbol for the wind combines both intensity and direction in a single icon, for example.</p><p>3.6.2 LuciadLightspeed WXXM Industry Specific Component The WXXM Industry Specific Component in LuciadLightspeed is still in its prototype state and hence there is not enough information about its working. But summarizing at an abstract level it can be seen that it consist of three components:</p><p>• a Java domain model, representing the WXXM 2.0 domain objects explained in detail in section 3.5. This domain model has been generated using the WXXM 2.0 XML Schema.</p><p>• a decoder, capable of reading WXXM 2.0 XML into the java domain model</p><p>• an encoder, capable of encoding the java domain model into XML</p><p>48</p><p>Rdcino niomna matb 0 e ih” h evc,teinformation the service, The flight”. per 10% by impact environmental of “Reduction T let( tnaoeapiain sas eeoe odmntaeteproeo the of purpose the demonstrate to developed also is application) standalone (a client A h eeoe WMbsdCnASriecluae otalojcso h ywith fly the on objects contrail calculates Service ConSA SWIM-based developed The an 3.6.1 , section data. 3 weather chapter aviation-related in on explained focused format format WXXM exchange contrail the data The in in changed. explained and defined outputs modified is is which selected, output Service years be service Feature many can Web which since OGC features an field contrail is 4D this service geospatial in The 2.2.3. expert subsection recognized Schumann 2 Ulrich a chapter Prof. to is with algorithm a who corporation The in DLR in 3.5. is developed subsection from data is 3 weather objects chapter The contrail in data. explained the as forecast calculate NetCDF also – but format current 4D using complex – data weather time real participants all to charge of free Class. available Master made SWIM been the have of which in 3, explained chapter as of components service 3.2 software the section LuciadLightspeed 3 and the chapter client using in the developed explained Both been as have solution. standards universal OGC a on developing based thereby is are subsection3.3.2, which client objective the prime and SESAR’s models the exchange of one Service with Contrail named line been in has is service It The identifying (ConSA). forming. Aviation in contrail operator for intense the of supports 4D) service (in The environment. areas earths’ the on aviation of WMSriet upr T tkhlesi h fott eueteimpact the reduce to effort SWIM the competition in stakeholders a developed ATM Luciad support of with to part together Service Space a SWIM and a was Defence thesis AIRBUS 2015. master Class the Master in developed service he 49 I MPLEMENTATION</p><p>C HAPTER 4 CHAPTER 4. IMPLEMENTATION service. The user can visualize the weather data, contrail objects and trajectories, which cause them, in 4D. In this way it can be demonstrated that already today it is possible to take influence on the forming of contrails from aviation by applying existing SWIM technology.</p><p>The resulting Contrail information definition can be used by Airspace Users in general. Among them:</p><p>• Mission Planners as an input for Mission Planning Systems (WOC)</p><p>• Flight Planners as an input for Flight Planning Systems (FOC)</p><p>• Airspace Managers for analysis of environmental aspects</p><p>• Network Manager operators to support situation analysis and improve earths environmental awareness, whilst optimizing sectors</p><p>• ATC controllers, evaluating impact on the earths environment of flights.</p><p>4.1 Inputs from other projects</p><p>Services from other projects are taken into consideration to provide required data for the Contrail Service for Aviation (ConSA). ConSA has been built on existing SWIM services (e.g. METGATE service from METEO France, DWD and UKMO) allowing to reuse functionality and shorten development time. Furthermore, the combination of the data delivered by multiple other services creates additional value for the user. The figure 4.1 shows the flow of data from various other projects and our development on them.</p><p>ConSA takes into account research conducted in various OGC testbed initiatives [20] and [21], in which the use of OGC web services in combination with weather-related data delivery and processing has been studied and successfully tested.</p><p>Figure 4.1: Servicedata</p><p>The weather client receives information from EUMETNET’s SWIM based web ser- vice named “MET-GATE Services”. EUMETNET consist of Météo-France, DWD and</p><p>50 CHAPTER 4. IMPLEMENTATION</p><p>UKMO, which provide the MET-GATE Services within the framework of the SWIM Master Class 2015. This weather data is used by a Contrail Algorithm to create a 4D contrail model. This model is further fed to the Contrail forecasting Service.</p><p>Figure 4.2: Client Flow of Data</p><p>4.2 Service overview</p><p>Figure 8 below provides an overview of ConSA. It describes involved nodes, context of the service and the interaction between nodes.</p><p>ConSA consists of the ConSA Service and the ConSA Client, where the latter has been developed in order to demonstrate the potential of the ConSA Service. The ConSA Service is shown in the yellow background and the ConSA Client is shown in the grey background.</p><p>ConSA Service The service has three nodes: the WCS Client, the Contrail Algorithm and the WFS Server. The WCS Client establishes a connection with the METEO France WCS Server. The WCS Client retrieves 4D weather data (NetCDF) and forwards it to the Contrail Algorithm. The Contrail Algorithm computes 4D Contrail Objects and forwards it to the WFS Server.</p><p>ConSA Client The client has three nodes: the WCS Client which connects to the METEO France WCS Server, the WFS Client which connects to the ConSA Service and the FlightRadar24 Client which connects to the FlightRadar24 ADS-B service. The Client displays 4D weather data, 4D contrail data and the ADS-B flight tracks.</p><p>51 CHAPTER 4. IMPLEMENTATION</p><p>Figure 4.3: ] ConSA overview</p><p>4.3 Service interface specifications</p><p>This chapter describes the details of the classes and interfaces of the ConSA Service and Client, as well as the used information exchange formats.</p><p>4.3.1 ConSA Service Figure 9: ConSA Service interface specification shows the interface specification of the ConSA Service. At the heart of the Service, the Contrail Algorithm is used to process weather data and calculate contrail objects. The input weather data is retrieved via the Luciad Client, which implements the OGC WCS 2.0 Client interface to consume the data from an external OGC WCS Service. The used information exchange format is OGC NetCDF. Communication with the OGC WCS Service relies on HTTP(S), using GET</p><p>52 CHAPTER 4. IMPLEMENTATION requests with key-value pairs. The following WCS operations are used by the Luciad Client:</p><p>• The GetCapabilities operation, to query the available weather data products from the service. • The DescribeCoverage operation, to retrieve additional details (geographic bounds, location, resolution. . . ) about the weather data products. • The GetCoverage operation, to retrieve an actual weather data product for a given area, altitude and time.</p><p>Figure 4.4: ConSA Service interface specification</p><p>The calculated contrail objects are served via the Luciad Server, which implements the OGC WFS 2.0 Service interface, an ISO standardized web service specification to exchange geographical feature data. Following the OGC WFS terminology, the Server defines one feature type to represent the Contrail data. The information exchange format used by the service is WXXM 2.0. Communication with the Server relies on HTTP(S), either via key-value pair request or via XML POST requests. The following WFS operations are supported by the Luciad Server:</p><p>The GetCapabilities operation: this operations gives a physical interface description of the service, including metadata, information about the Contrail Object data (geograph- ical area, geographic reference . . . ) as well as possible operations that are supported by the service.</p><p>53 CHAPTER 4. IMPLEMENTATION</p><p>The GetFeature operation this operation allows to query Contrail Object data from the service. A variety of query filter parameters can be specified using the OGC Filter 2.0 specification, such as an area or a trajectory, an altitude, a time, etc.</p><p>The DescribeFeatureType operation this operation allows to query the WXXM 2.0 XML Schema that defines the format of the Contrail Object data.</p><p>4.3.2 ConSA Client Figure 10 shows the interface specification of the ConSA Client.</p><p>The ConSA client includes the following client components and corresponding interfaces:</p><p>• The Luciad WCS Client, which implements the OGC WCS 2.0 Client interface to retrieve weather data (similar to the Luciad WCS Client used by the ConSA service discussed in Section 5.1).</p><p>• The Luciad WFS Client, which implements the OGC WFS 2.0 Client interface to retrieve Contrail Objects. This relies on the WFS operations provided by the ConSA Service, as listed in Section 5.1.</p><p>• The Luciad FR24 ADS-B Client, which implements a HTTP GET Client interface to retrieve ADS-B flight tracks. All the retrieved information is used by the Display class to visualize and analyze the data.</p><p>Figure 4.5: ConSA Service interface specification</p><p>54 CHAPTER 4. IMPLEMENTATION</p><p>4.4 Service dynamic behaviour</p><p>4.4.1 The ConSA Service Figure 11 shows the sequence diagram of the ConSA Service. The Luciad WFS Server sends an asynchronous message to the Luciad WCS Client. The Luciad WCS Client establishes a connection with the METEO France WCS to retrieve NetCDF Weather data. The Luciad WCS Client then forwards the weather data to the Contrail Algorithm. The contrail algorithm computes 4D Contrail model and forwards it to the WFS Server. All these steps happen in a loop every 5 minutes and hence the ConSA Server always updated.</p><p>Figure 4.6: ConSA Service Sequence Diagram</p><p>4.4.2 The ConSA Client The sequence diagram in Figure 12: The sequence diagram illustrates the dynamic behaviour of the ConSA Client explains the dynamic behaviour of the ConSA Client:</p><p>• The user can send an asynchronous request to the Luciad WCS Client to retrieve 4D weather data. Same as in the ConSA Service, the Luciad WCS Client connects to the METEO France WCS and retrieves weather coverage data in NetCDF 2.0. The Client processes this information and sends a 4D weather cube model to the display as a layer.</p><p>55 CHAPTER 4. IMPLEMENTATION</p><p>• Similarly, the user can also send an asynchronous request to the Luciad WFS Client to retrieve the Contrail Model. The Luciad WFS Client connects to the ConSA Server and retrieves the Contrail features in WXXM 2.0. The Client processes the WXXM data and generates a 4D contrail model. It further forwards this to the display as a layer.</p><p>• The Client sends every 10 seconds an ADS-B feed request to the FlightRadar24 service and receives flight tracks represented in the JSON format.</p><p>All the above data visualization happens in parallel, hence shown by the condition in green- par.</p><p>Figure 4.7: ConSA Client Sequence Diagram</p><p>4.5 Technical Architecture</p><p>The service consists of a set of components that are developed on top of the Luciad COTS product LuciadLightspeed. LuciadLightspeed provides the building blocks to work with geospatial data and it also provides an application framework for rapid application development. The product has Model-View-Controller (MVC) architecture</p><p>56 CHAPTER 4. IMPLEMENTATION to ease customizations and extensions. Chapter 3.2 discusses the use of these products in more detail. The following components are developed on top of these products:</p><p>Luciad WCS Client The Luciad WCS client requests and retrieves the data from EUMETNET WCS weather service. The EUMETNET WCS is consulted every 5 minutes, to make sure that the Contrail WFS Service remains up-to-date. The data is in NetCDF format. After the Luciad WCS client receives weather data it passes this information to the Data Processing block.</p><p>Figure 4.8: ConSA Client Sequence Diagram</p><p>Data Processing The Data Processing block contains the Real-time Contrail algorithm. The input for the algorithm is 4D weather data such as humidity, temperature and pressure. The algorithm computes contrail areas on the fly on the input data and outputs contrail objects. Figure 5 illustrates the data processing block.</p><p>Luciad WFS Server The WFS server sends response to the client requesting contrail data by encoding the data in WXXM. The WXXM data holds the contrails objects in space and time.</p><p>ConSA Client The architecture diagram of the ConSA Client is shown in Figure 6. The client is a standalone application and its main purpose is to interact with the SWIM services and demonstrate the potential use of the contrail service. It features a 2D/3D hybrid, graphics accelerated map with 4D data visualization. It access to a wide range of</p><p>57 CHAPTER 4. IMPLEMENTATION</p><p>SWIM services, and provides the means to the user to visualize and analyze the contrail data.</p><p>Figure 4.9: ConSA Client Sequence Diagram</p><p>58</p><p>0 ) uptaeTCadTMi evn L strsodtmeauefrgvnU given for temperature threshold is TLC Kelvin. in TLM and TLC are Output %). 100 h weather The 2.2.3. subsection 2 chapter in explained is ConSA the for algorithm The Ulrich Prof. with collaboration in developed is contrails forecasting module software The nKadTMi hehl eprtr o = nK. = in 1 U=1 (non-dimensional; for U temperature and threshold Pa/K is in TLM G and are K IU Input in U. and and IG G of over values loop The humidity. mixing a relative of of is gradient indices U is just the the diagram2.5. G are give Appleman test correctly". values - works to U Schmidt algorithm and him in the G by TLM, line given and given the TLC was "If of : table output is given following criteria outputs The evaluation and algorithm DLR. inputs The at the algorithm. comparing instance by Dr. algorithm done Prof. his was by algorithm to gracefully to the us algorithm of to the testing given with was the processed algorithm Schumann then the and As client temperature. WCS threshold ConSA output the by collected was data model. CoCiP the of for part implemented is been service has 2015 which Class has algorithm Master which Schuhmann The SWIM forecasting contrails. the Prof. contrail predict field. for to accuracy model this 80% Prediction) in gives Cirrus researcher (Contrail leading CoCiP a the developed is who DLR Schuhmann, Evaluation Algorithm 5.1 I fti hpe steeauto fteagrtm etts tt aiaeadverify and service. validate ConSa to the it part and task main libraries Next The LuciadLightspeed algorithm. presented. of the is correctness of evaluation evaluation the its the and is thesis chapter the this of of results the chapter this n R SLSAND ESULTS 59 E VALUATION</p><p>C HAPTER 5 CHAPTER 5. RESULTS AND EVALUATION</p><p>IG IU G/(Pa/K) U/1 TLC/K TLM/K 1 1 0.25 1 213.31 213.31 1 2 0.25 0.99 212.21 213.31 1 3 0.25 0.98 211.78 213.31 1 4 0.25 0.97 211.46 213.31 1 5 0.25 0.96 211.2 213.31 1 6 0.25 0.5 207.15 213.31 1 7 0.25 0.4 206.71 213.31 1 8 0.25 0.3 206.32 213.31 1 9 0.25 0.2 205.97 213.31 1 10 0.25 0.1 205.65 213.31 1 11 0.25 0 205.36 213.31 2 1 2.25 1 234.58 234.58 2 2 2.25 0.99 233.22 234.58 2 3 2.25 0.98 232.68 234.58 2 4 2.25 0.97 232.29 234.58 2 5 2.25 0.96 231.96 234.58 2 6 2.25 0.5 226.98 234.58 2 7 2.25 0.4 226.44 234.58 2 8 2.25 0.3 225.96 234.58 2 9 2.25 0.2 225.53 234.58 2 10 2.25 0.1 225.14 234.58 2 11 2.25 0 224.78 234.58 3 1 4.25 1 241.7 241.7 3 2 4.25 0.99 240.24 241.7 3 3 4.25 0.98 239.67 241.7 3 4 4.25 0.97 239.24 241.7 3 5 4.25 0.96 238.9 241.7 3 6 4.25 0.5 233.57 241.7 3 7 4.25 0.4 233 241.7 3 8 4.25 0.3 232.49 241.7 3 9 4.25 0.2 232.03 241.7 3 10 4.25 0.1 231.62 241.7 3 11 4.25 0 231.23 241.7 4 1 6.25 1 246.27 246.27 4 2 6.25 0.99 244.74 246.27</p><p>60 CHAPTER 5. RESULTS AND EVALUATION</p><p>IG IU G/(Pa/K) U/1 TLC/K TLM/K 4 3 6.25 0.98 244.15 246.27 4 4 6.25 0.97 243.71 246.27 4 5 6.25 0.96 243.35 246.27 4 6 6.25 0.5 237.8 246.27 4 7 6.25 0.4 237.2 246.27 4 8 6.25 0.3 236.67 246.27 4 9 6.25 0.2 236.19 246.27 4 10 6.25 0.1 235.76 246.27 4 11 6.25 0 235.36 246.27 5 1 8.25 1 249.69 249.69 5 2 8.25 0.99 248.11 249.69 5 3 8.25 0.98 247.5 249.69 5 4 8.25 0.97 247.04 249.69 5 5 8.25 0.96 246.67 249.69 5 6 8.25 0.5 240.95 249.69 5 7 8.25 0.4 240.33 249.69 5 8 8.25 0.3 239.79 249.69 5 9 8.25 0.2 239.3 249.69 5 10 8.25 0.1 238.85 249.69 5 11 8.25 0 238.44 249.69 6 1 10.25 1 252.45 252.45 6 2 10.25 0.99 250.82 252.45 6 3 10.25 0.98 250.2 252.45 6 4 10.25 0.97 249.73 252.45 6 5 10.25 0.96 249.35 252.45 6 6 10.25 0.5 243.49 252.45 6 7 10.25 0.4 242.85 252.45 6 8 10.25 0.3 242.29 252.45 6 9 10.25 0.2 241.79 252.45 6 10 10.25 0.1 241.34 252.45 6 11 10.25 0 240.92 252.45 7 1 12.25 1 254.76 254.76 7 2 12.25 0.99 253.11 254.76 7 3 12.25 0.98 252.46 254.76 7 4 12.25 0.97 251.99 254.76 7 5 12.25 0.96 251.6 254.76</p><p>61 CHAPTER 5. RESULTS AND EVALUATION</p><p>IG IU G/(Pa/K) U/1 TLC/K TLM/K 7 6 12.25 0.5 245.62 254.76 7 7 12.25 0.4 244.97 254.76 7 8 12.25 0.3 244.4 254.76 7 9 12.25 0.2 243.89 254.76 7 10 12.25 0.1 243.42 254.76 7 11 12.25 0 242.99 254.76 8 1 14.25 1 256.77 256.77 8 2 14.25 0.99 255.08 256.77 8 3 14.25 0.98 254.43 256.77 8 4 14.25 0.97 253.94 256.77 8 5 14.25 0.96 253.54 256.77 8 6 14.25 0.5 247.46 256.77 8 7 14.25 0.4 246.8 256.77 8 8 14.25 0.3 246.22 256.77 8 9 14.25 0.2 245.7 256.77 8 10 14.25 0.1 245.23 256.77 8 11 14.25 0 244.79 256.77 9 1 16.25 1 258.54 258.54 9 2 16.25 0.99 256.82 258.54 9 3 16.25 0.98 256.16 258.54 9 4 16.25 0.97 255.67 258.54 9 5 16.25 0.96 255.26 258.54 9 6 16.25 0.5 249.08 258.54 9 7 16.25 0.4 248.42 258.54 9 8 16.25 0.3 247.83 258.54 9 9 16.25 0.2 247.3 258.54 9 10 16.25 0.1 246.82 258.54 9 11 16.25 0 246.38 258.54 10 1 18.25 1 260.13 260.13 10 2 18.25 0.99 258.39 260.13 10 3 18.25 0.98 257.72 260.13 10 4 18.25 0.97 257.22 260.13 10 5 18.25 0.96 256.81 260.13 10 6 18.25 0.5 250.54 260.13 10 7 18.25 0.4 249.87 260.13</p><p>62 CHAPTER 5. RESULTS AND EVALUATION</p><p>IG IU G/(Pa/K) U/1 TLC/K TLM/K 10 8 18.25 0.3 249.27 260.13 10 9 18.25 0.2 248.73 260.13 10 10 18.25 0.1 248.25 260.13 10 11 18.25 0 247.8 260.13 11 1 20.25 1 261.57 261.57 11 2 20.25 0.99 259.81 261.57 11 3 20.25 0.98 259.13 261.57 11 4 20.25 0.97 258.62 261.57 11 5 20.25 0.96 258.21 261.57 11 6 20.25 0.5 251.87 261.57 11 7 20.25 0.4 251.18 261.57 11 8 20.25 0.3 250.58 261.57 11 9 20.25 0.2 250.04 261.57 11 10 20.25 0.1 249.54 261.57 11 11 20.25 0 249.09 261.57 12 1 22.25 1 262.9 262.9 12 2 22.25 0.99 261.12 262.9 12 3 22.25 0.98 260.42 262.9 12 4 22.25 0.97 259.91 262.9 12 5 22.25 0.96 259.49 262.9 12 6 22.25 0.5 253.08 262.9 12 7 22.25 0.4 252.39 262.9 12 8 22.25 0.3 251.78 262.9 12 9 22.25 0.2 251.23 262.9 12 10 22.25 0.1 250.73 262.9 12 11 22.25 0 250.27 262.9</p><p>Table 5.1: The above table is a given by DLR. It has input and output data to check the correctness of the Contral forecasting algorithm. The G and U values are given and we check if the algorithm outputs the TLC and TLM (temperature) values as given in the table. As it matched completely the algorithm was correct.</p><p>63 CHAPTER 5. RESULTS AND EVALUATION</p><p>5.2 Validation and Verification</p><p>The foundation of the developed service is provided by the Luciad COTS product LuciadLightspeed, which is a very mature and widely used product in Aviation, Defense & Security and Maritime markets for over 15 years. The product provides support for many standards and formats in a well-tested implementation. The product includes certified implementations of several OGC standards and tests against industry standards such as Eurocontrol’s DQTS and the NGA’s GeoTrans systems and GOLD dataset.</p><p>For example, the Luciad geodetic datum transformations and geodesic distance and az- imuth calculations have been compared with the DQTS Datum tool and Join-Inverse tools in specific. From these tests, Luciad is able to state that its algorithms and calculations are accurate up to one inch in world scale.</p><p>5.3 ConSA evaluation</p><p>The ConSA Service has been validated and verified using a set of queries that represent the targeted use cases. This includes queries to retrieve the probable contrail formation for a given trajectory or airspace, defined in time and space (4D). The query results have been verified using the ConSA Client, by visually correlating the contrail information with relative humidity and temperature data - which form the foundation of the contrail formation calculations.</p><p>Due to time constraints of the thesis, further validation and verification exercises could not be performed.</p><p>64</p><p>T hc hw hc icatwudcueacnri n hc o.Aayi rmthe from Analysis not. which and contrail a cause would aircraft which shows which o es niomna matfo otalfriga h aetm epdt aefuel safe to helped time same optimized the been had at which forming path contrail flight from a impact when environmental cases were least there for that see to interesting was It the integration this of makes visualisation thesis ConSA. this actual deploying But by into before. into possible possible forecasting further never contrail was step in environment researches aviation a previous the goes of integration ConSA The And points. aformentioned found. be to needs between: trade-off a generally that proven, client had ConSA DLR deploying whether by know reduction to contrail a sought effective in in also objective result has SESAR can study this contrails The forecasting support way. to user-friendly per designed and 10% been comfortable by most has impact environmental Service of ConSA “Reduction The the flight”. is SESAR of objectives prime the telatevrnetlimpact environmental least the • profile flight optimum the • path flight shortest the • nagrtmt eeaecnri omn rbblt.A ttderiroeof one earlier stated As probability. forming in contrail it processes generate input, to methods forecast algorithm forecasting weather contrail an accepts forecast which to ConSA methods developed deploy has to and out set was study he 65 C ONCLUSION</p><p>C HAPTER 6 CHAPTER 6. CONCLUSION and therefore saved money and reduced production of CO2. Hence, although higher cost might be taken into consideration to gain a reduction in the environmental impact for a lot of flights, there are occasions where cost increase is negligible (or costs might be even lower) and a valuable contribution to the environment can be gained coincidently.</p><p>There might be cases in which contrails can create a positive effect by blocking radiation from the sky towards Earth’s surface. But any positve effect will only be temorarily or locally. The overall effect of contrail forming in the atmosphere will always be negative. In any case, it is recommended to obtain advice from a meteorologist. In this way positive and/or negative environmental impact from contrail occurrence can be assessed. Furthermore, environmental as well as tactical aspects on contrail forming can be discussed before the flight or mission.</p><p>Currently Aircraft engine emissions like smoke, nitrogen oxides and hydrocarbons are currently regulated (in airport zones) by the FAA and the ICAO (see Ref. [10]). Carbon dioxide regulation is also in process but currently there are no plans for a contrail regulation. Hence it might be the case that rules and regulations on contrail insertion into air masses might be implemented in the future, especially with increasing airborne traffic around the globe.</p><p>With ConSA, the solution to this increasing problem is available before the problem has reached global attention! Enhancing ConSA based on SWIM in the near future will provide the basis for greener aviation. By applying the principles of ConSA based on SWIM to an increasing number of flights, the positive effect on the environmental aspect will also increase!</p><p>Therefore the ConSA Service can be seen already as a step into global SWIM Services which will reach beyond the Single European Sky (SES). An illustration of the output of ConSA can be seen in Figure 3. If feed with accurate worldwide weather data the service would work across the globe!</p><p>Even without official regulations regarding contrail generation into the Earths’ environ- ment in place, distribution and use of ConSA would bring a lot of advantages to the ATM community:</p><p>6.1 Thesis implications</p><p>Based on the ConSA calculation result Airspace Users will be able to create flight plans i.e. 4D mission trajectories with a reduced or desired environmental impact regard- ing contrail forming, by balancing the trade-off factors of flight/mission planning (see</p><p>66 CHAPTER 6. CONCLUSION</p><p>Figure 6.1: 4D corridor showing contrail probability along a trajectory from ConSA above).</p><p>Airspace Managers are supported in finding optimal solutions to place ARES (Airspace Reservations) while being aware of any intense forming of contrails. Dynamic mobile airspace (DMA) reservations can be established taking probable impact of contrail and cirrus forming into account.</p><p>Air Traffic Controllers are supported in the same way as Airspace Managers. ConSA based on SWIM makes obvious which flights (Aircraft Identifier) have a high potential for the production of contrails. As this information is displayed in real time, ConSA has a future potential to be considered from ATC to influence the amount of contrail forming in the Single European Sky (SES).</p><p>67 CHAPTER 6. CONCLUSION</p><p>NM operators will be able to use ConSA Service for quick analysis of the probable environmental impact created through 4D trajectories from the network by contrail forming.</p><p>Of course ConSA service is just the beginning of bringing awareness about the environ- mental impact of contrails to a wide number of aviation stakeholders (see Figure 4), by combining a huge amount of complex 4D data in a single service:</p><p>Figure 6.2: Overview on ATM Stakeholders</p><p>As the ConSA Service builds on several other available SWIM Services it can be seen as a second level of Services, which copes with higher complexity and therefore brings new added value to the operators and users in ATM.</p><p>6.2 Benefits</p><p>Business benefits (processes) If successful configured for web connection, the ConSA based on SWIM client provides support in the real time analysis of complex 4-dimensional meteorological information. The benefits of high performance data-processing, on-the-fly 4D solution calculation and network connectivity can enhance ATM-business processes with regard to reduction of environmental impact. Positive aspects on future improved</p><p>68 CHAPTER 6. CONCLUSION</p><p>ATM-business achievable when ConSA based on SWIM service (or client) is deployed will be described in the following subchapters.</p><p>In future there will be options for optimizing not only one flight but a lot of flights / 4D trajectories within the SWIM data base. Analysis from the DLR have proven, that generally a trade of between shortest flight path, optimum flight profile and least environmental impact needs to be found. It was interesting to see that there were cases when a flight path which had been optimized for least environmental impact from contrail forming at the same time helped to safe fuel and therefore saved money and reduced production of CO2. Hence although higher cost might be taken into consideration to gain a reduction in the environmental impact for a lot of flights there are occasions where cost increase is negligible (or costs might be even lower) and a valuable contribution to the environment can be gained coincidently.</p><p>Better situational awareness The ConSA based on SWIM service provides users with an improved awareness on weather factors, especially on areas of (intense) contrail forming. Due to the fact that there are contrails with negative but also with positive effects to the Earth’ climate, it is recommended to obtain advice from a meteorologist. In this way positive and/or negative environmental impact from contrail occurrence can be assessed (see also chapter 4.1.4). Furthermore, environmental as well as tactical aspects on contrail forming can be discussed before the flight or mission.</p><p>Improved transparency Bringing the ConSA based on SWIM function to all stake- holders in the ATM domain, will enable similar understanding of the meteorological situation of contrail forming for everybody. If Airspace Users, Airspace Managers, Air Traffic Controllers and/or NM Operators share the same view on environmental aspects, during planning or execution phase, transparency on options and decisions will strongly improve. Enhanced transparency will enable bridging gaps between ATM stakeholders.</p><p>Improved currentness Planning and execution phases can gain improved quality with regards to the environmental impact from contrail generation, if decisions are based on the latest data provided by ConSA based on SWIM. Changes to Flight Plans (4D trajectories) or ARES definition can be analysed for probable environmental impact. Furthermore, by continuously updating the data in ConSA via existing SWIM services, re-assessments can be done quickly and existing plans can be updated with little effort. Consequently, a valuable contribution to environmental protection can be gained.</p><p>Environmental benefit In cases where high temperatures develop on the Earth’s sur- face, it might be desirable to reduce the impact of radiation coming from the sun. Thus,</p><p>69 CHAPTER 6. CONCLUSION forming of cirrus from contrail production caused by aviation might be a positive contri- bution to reduce heat on the Earth’s surface. Any positive effect from contrail or cirrus will be temporary or local, the overall effect on the Earth’s climate will be negative. At night when radiation is released from the Earth’s surface, contrail and cirrus will hamper the escape of radiation into the sky. Hence it will be desirable not to cause additional contrail or cirrus by aviation during evening or night. Complex situation analysis and high-speed solution calculation supported by the ConSA based on SWIM can increase decision making within ATM operators and Airspace Users. The service will support operators in real-time but also in forecast judgement of contrail forming. Decisions on trajectories or traffic will be much faster than nowadays using a SWIM service like ConSA. Hence, ATM workflows will be more aware or environmental effects towards contrail forming when ConSA functionality and service is provided to ATM stakeholders.</p><p>SESAR Benefits Rules and regulations on contrail insertion into air masses might follow in the future, especially with increasing airborne traffic around the globe. The solution to this increasing problem is available before the problem has reached global attention! Enhancing ConSA based on SWIM in the near future will provide the basis for greener aviation. By applying the principles of ConSA based on SWIM to an increasing number of flights, the positive effect on the environmental aspect will also increase!</p><p>Technology benefits</p><p>• Standardized representation of Contrail data The Contrail data generated by the system is representing using the AIRM-based WXXM 2.0 weather data standard, making it ideally suited for integration in a SWIM environment and in other systems based upon OGC web services. The WXXM format is quickly becom- ing a mature data format with a strong industry adoption, and it is the weather information exchange format of choice within next-generation ATM systems.</p><p>• Reusable, interoperable approach to calculate Contrail forming The ConSA based on SWIM service is entirely built upon open and proven SWIM-adopted standards and protocols to maximize interoperability. Any application that supports OGC WFS and WXXM can directly connect with the ConSA service, query Contrail formation and start using the data operationally.</p><p>• Interactive state-of-the-art visual analytics Visual analytics is concerned with representing and visualizing data in such a way that relevant information becomes visually clear to the human observer. It is vital that the visualization is extremely efficient to allow the observer to adapt, update and steer the visual analytics process in an interactive way, especially when working with large data sets. This approach</p><p>70 CHAPTER 6. CONCLUSION</p><p> has successfully been implemented by the ConSA based on SWIM client, where it demonstrates how users can interactively visualize and analyse in 4D vast amounts of contrail data provided by the ConSA service in 4D and immediately correlate it with weather data and flight tracks in real-time.</p><p>• Reusability of software components The services in the SWIM registry use a variety of data formats and protocols to serve different purposes, with standardization (WXXM, NetCDF, XML, OGC . . . ) and openness as common features. This enhances the reusability of software components and interoperability in general. ConSA demonstrates this by relying on a COTS product that provided the building blocks to work with OGC services, WXXM, NetCDF, etc. It also showed the feasibility of tapping and combining a multitude of SWIM data sources in a short time to produce useful functionality. The underlying idea is to have one single implementation of each function or service in use for all ATM stakeholders.</p><p>6.3 Future Scope</p><p>As stated in Chapter2 the current version of the ConSA client is a part of the COCIP model designed by DLR. This was because of respecting time and budgetary constraints that a contrail forecast algorithm which has been reduced in complexity has been imple- mented in ConSA. In future our plan to implement the entire COCIP model in ConSA. The climate impact of contrails depends not only on flight routes for given weather conditions but also on fuel used, emissions and engine types of aircraft. Therefore the plan is to integrate these details and refine the algorithm in future. This thesis aims to reduce the environmental impact of aviation, and to realize this aim research should also be done in solving other impacts by aviation which are stated in chapter1 subsection 1.1.3 page number7. Similar to ConSA the other aviation induced pollution parameters can also be calculated before a flight. This forecast algorithm is based on 4D data con- sisting of values for temperature, pressure and humidity data services, like the one from METGATE. In future, the existing algorithm needs to be enhanced to take additional factors into account, such as fuel consumption, type of engine and engine emissions. With this information from ConSA the aviation industry can optimize the flight routes thereby minimizing the environmental impacts.</p><p>ConSA is already a step beyond the European initiative into a worldwide solution, by contributing to the efforts on reduction of environmental impacts from aviation and in general. In future the aim is that, and hence it will be necessary to connect to worldwide weather data services, which – on a technical level – can quite easily be done based on the open standards upon which the ConSA solution has been build.</p><p>71</p><p>. oS evc:OCWScapabilities WFS OGC service: ConSA 7.2 service. ConSA the of capabilities XML the includes A.1.1 description interface physical service ConSA 7.1 sc sWX .) nOCWSsriei dnie ya M-ae capabili- XML-based an by identified is service WFS OGC An 2.0). WXXM as (such hsfauetp smdle n xhne ytesrieuigWX ..Section 2.0. WXXM using service the by exchanged and modelled is type feature This a defines which specification, 2.0 WFS OGC the upon based is service ConSA The aaiiis ple oteCnAuecs,asnl etr yei end Contrail. defined: is type feature single a filtering case, and use operations ConSA available the of overview to the an Applied (representing and capabilities. types service) feature the more by or handled one datatypes metadata, service schema defining application document, 3.2 ties GML a using data vector exchange to approach standardized " 0 . 2 / wfs / t e n . s i g n e p o /www. / : p t t h =" xmlns:wfs s e i t i l i b a p a C _ S F W : s f w < <? > n o i t a c i f i t n e d I e c i v r e S : s w o < version o i s r e v xml hsXLdcmn WFS e h t > s e t l n t e i T s : e s r w p o e r SWIM< / on document XML based e This c > i t v c r a e r S t s b A : >ConSA s w e o l < t i T : s w o < ftheCnAservicebsdo SWIM, on based e c i v r e s ConSA e h t of s e i t i l i b a p a c ’ UTF = encoding ’ 0 . 1 ’ = itn .:MyAerodromeType.sld 7.1: Listing " 1 . 1 / ows / t e n . s i g n e p o /www. / : p t t h " xmlns:ows= n o i s r e v " 0 . 2 / s e f / t e n . s i g n e p o / www. / : p t t h =" s e f : s n l m x " k n i l x / 9 9 9 1 / org . /wwww3 . / : p t t h =" k n i l x : s n l m x "> 0 . 0 . 2 =" 72 − ?> ’ 8 A PPENDIX</p><p>C HAPTER 7 A CHAPTER 7. APPENDIX A</p><p> a web service targeted towards the calculation of contrail o b j e c t s . </ows:Abstract> <ows:Keywords> <ows:Keyword>ConSA</ ows:Keyword> <ows:Keyword>SWIM</ ows:Keyword> <ows:Keyword>Contrail</ows:Keyword> </ows:Keywords> <ows:ServiceType>WFS</ ows:ServiceType> <ows:ServiceTypeVersion>2.0.0</ ows:ServiceTypeVersion> <ows:Fees>None</ ows:Fees> <ows:AccessConstraints>None</ ows:AccessConstraints> </ows:ServiceIdentification> <ows:OperationsMetadata> <ows:Operation name="GetCapabilities"> <ows:DCP> <ows:HTTP> <ows:Get xlink:href="http:// localhost:8080/ ContrailService/wfs?"/> <ows:Post xlink:href="http:// localhost:8080/ ContrailService/wfs?"/> </ows:HTTP> < / ows:DCP> <ows:Parameter name="AcceptVersions"> <ows:AllowedValues> <ows:Value>2.0.0</ows:Value> </ows:AllowedValues> </ows:Parameter> <ows:Parameter name="AcceptFormats"> <ows:AllowedValues> <ows:Value>text /xml</ows:Value> </ows:AllowedValues> </ows:Parameter> </ows:Operation> <ows:Operation name="DescribeFeatureType"> <ows:DCP> <ows:HTTP> <ows:Get xlink:href="http:// localhost:8080/ ContrailService/wfs?"/> <ows:Post xlink:href="http:// localhost:8080/ ContrailService/wfs?"/> </ows:HTTP> < / ows:DCP> <ows:Parameter name="outputFormat"> <ows:AllowedValues> <ows:Value>XMLSCHEMA</ ows:Value> <ows:Value>text /xml; subtype=gml/2.1.2</ows:Value> <ows:Value>GML2</ ows:Value> <ows:Value>text /xml; subtype=gml/3.1.1</ows:Value></p><p>73 CHAPTER 7. APPENDIX A</p><p><ows:Value>GML3</ ows:Value> <ows:Value>GML31</ ows:Value> <ows:Value>application /gml+xml; version=3.2</ows:Value> <ows:Value>GML32</ ows:Value> <ows:Value>application /gml+xml; subtype=gml/3.1.1/ profiles /gmlsf</ows:Value> <ows:Value>application /gml+xml; subtype=gml/3.2/ profiles /gmlsf</ows:Value> </ows:AllowedValues> </ows:Parameter> </ows:Operation> <ows:Operation name="GetFeature"> <ows:DCP> <ows:HTTP> <ows:Get xlink:href="http:// localhost:8080/ ContrailService/wfs?"/> <ows:Post xlink:href="http:// localhost:8080/ ContrailService/wfs?"/> </ows:HTTP> < / ows:DCP> <ows:Parameter name="resultType"> <ows:AllowedValues> <ows:Value>hits</ows:Value> <ows:Value>results</ows:Value> </ows:AllowedValues> </ows:Parameter> <ows:Parameter name="outputFormat"> <ows:AllowedValues> <ows:Value>GML32</ ows:Value> <ows:Value>text /xml</ows:Value> <ows:Value>text /xml; subtype=gml/3.2.1</ows:Value> <ows:Value>application /gml+xml; version=3.2</ows:Value> </ows:AllowedValues> </ows:Parameter> </ows:Operation> <ows:Operation name="GetFeatureWithLock"> <ows:DCP> <ows:HTTP> <ows:Get xlink:href="http:// localhost:8080/ ContrailService/wfs?"/> <ows:Post xlink:href="http:// localhost:8080/ ContrailService/wfs?"/> </ows:HTTP> < / ows:DCP> </ows:Operation> <ows:Operation name="LockFeature"> <ows:DCP> <ows:HTTP></p><p>74 CHAPTER 7. APPENDIX A</p><p><ows:Post xlink:href="http:// localhost:8080/ ContrailService/wfs?"/> </ows:HTTP> < / ows:DCP> </ows:Operation> <ows:Operation name="Transaction"> <ows:DCP> <ows:HTTP> <ows:Post xlink:href="http:// localhost:8080/ ContrailService/wfs?"/> </ows:HTTP> < / ows:DCP> <ows:Parameter name="inputFormat"> <ows:AllowedValues> <ows:Value>application /gml+xml; version=3.2</ows:Value> </ows:AllowedValues> </ows:Parameter> </ows:Operation> </ows:OperationsMetadata> <wfs:FeatureTypeList> <wfs:FeatureType> <wfs:Name xmlns:wxxm="http://www. wxxm.aero/ wxxm/2.0"> wxxm:Contrail</wfs:Name> <wfs:Title>Contrail objects</wfs:Title> <wfs:Abstract/> <wfs:DefaultCRS>urn:ogc:def:crs:EPSG::4329</wfs:DefaultCRS> <wfs:OutputFormats> <wfs:Format>GML32</ wfs:Format> <wfs:Format>text /xml</wfs:Format> <wfs:Format>text /xml; subtype=gml/3.2.1</wfs:Format> <wfs:Format>application /gml+xml; version=3.2</wfs:Format> </wfs:OutputFormats> <ows:WGS84BoundingBox> <ows:LowerCorner> −8.000000047683717 37.99999923833</ ows:LowerCorner> <ows:UpperCorner>11.999999952316287 53.00000076167</ ows:UpperCorner> </ ows:WGS84BoundingBox> </wfs:FeatureType> </wfs:FeatureTypeList> <fes:Filter_Capabilities> <fes:Id_Capabilities> <fes:ResourceIdentifier name="EID"/> <fes:ResourceIdentifier name="FID"/> </fes:Id_Capabilities> <fes:Scalar_Capabilities> <fes:LogicalOperators/> <fes:ComparisonOperators> <fes:ComparisonOperator name="LessThan"/></p><p>75 CHAPTER 7. APPENDIX A</p><p><fes:ComparisonOperator name="GreaterThan"/> <fes:ComparisonOperator name="LessThanEqualTo"/> <fes:ComparisonOperator name="GreaterThanEqualTo"/> <fes:ComparisonOperator name="EqualTo"/> <fes:ComparisonOperator name="NotEqualTo"/> <fes:ComparisonOperator name="Like"/> <fes:ComparisonOperator name="Between"/> <fes:ComparisonOperator name="NullCheck"/> </fes:ComparisonOperators> </fes:Scalar_Capabilities> <fes:Spatial_Capabilities> <fes:SpatialOperators> <fes:SpatialOperator name="Within"> <fes:GeometryOperands> <fes:GeometryOperand name="Envelope"/> <fes:GeometryOperand name="Point"/> <fes:GeometryOperand name="Polygon"/> <fes:GeometryOperand name="LineString"/> </fes:GeometryOperands> </fes:SpatialOperator> <fes:SpatialOperator name="Intersects"> <fes:GeometryOperands> <fes:GeometryOperand name="Envelope"/> <fes:GeometryOperand name="Point"/> <fes:GeometryOperand name="Polygon"/> <fes:GeometryOperand name="LineString"/> </fes:GeometryOperands> </fes:SpatialOperator> <fes:SpatialOperator name="Disjoint"> <fes:GeometryOperands> <fes:GeometryOperand name="Envelope"/> <fes:GeometryOperand name="Point"/> <fes:GeometryOperand name="Polygon"/> <fes:GeometryOperand name="LineString"/> </fes:GeometryOperands> </fes:SpatialOperator> <fes:SpatialOperator name="Crosses"> <fes:GeometryOperands> <fes:GeometryOperand name="LineString"/> </fes:GeometryOperands> </fes:SpatialOperator> <fes:SpatialOperator name="BBOX"> <fes:GeometryOperands> <fes:GeometryOperand name="Envelope"/> <fes:GeometryOperand name="Point"/> <fes:GeometryOperand name="Polygon"/> <fes:GeometryOperand name="LineString"/> </fes:GeometryOperands> </fes:SpatialOperator></p><p>76 CHAPTER 7. APPENDIX A</p><p><fes:SpatialOperator name="Contains"> <fes:GeometryOperands> <fes:GeometryOperand name="Envelope"/> <fes:GeometryOperand name="Point"/> <fes:GeometryOperand name="Polygon"/> <fes:GeometryOperand name="LineString"/> </fes:GeometryOperands> </fes:SpatialOperator> <fes:SpatialOperator name="Overlaps"> <fes:GeometryOperands> <fes:GeometryOperand name="LineString"/> </fes:GeometryOperands> </fes:SpatialOperator> <fes:SpatialOperator name="DWithin"> <fes:GeometryOperands> <fes:GeometryOperand name="Envelope"/> <fes:GeometryOperand name="Point"/> <fes:GeometryOperand name="Polygon"/> <fes:GeometryOperand name="LineString"/> </fes:GeometryOperands> </fes:SpatialOperator> <fes:SpatialOperator name="Beyond"> <fes:GeometryOperands> <fes:GeometryOperand name="Envelope"/> <fes:GeometryOperand name="Point"/> <fes:GeometryOperand name="Polygon"/> <fes:GeometryOperand name="LineString"/> </fes:GeometryOperands> </fes:SpatialOperator> </fes:SpatialOperators> </fes:Spatial_Capabilities> </fes:Filter_Capabilities> </wfs:WFS_Capabilities></p><p>7.3 Example of a Contrail object representation in WXXM 2.0</p><p>The following XML shows an example of a contrail object represented using WXXM 2.0. The DiscreteCoverage WXXM object is used to represent the object. The spatio-temporal characteristics are represented using the DomainSet WXXM object and GML spatial / temporal elements. The contrail formation probability itself is represented using the GML RangeSet and WXXM Amount elements.</p><p>Listing 7.2: MyAerodromeType.sld <wxxm:DiscreteCoverage</p><p>77 CHAPTER 7. APPENDIX A</p><p> xmlns:wxxm="http://www. wxxm.aero/ wxxm/2.0" xmlns:gml ="http://www.opengis.net/gml/3.2" g m l : i d ="ID0"> <wxxm:domainSet> <wxxm:DomainObject> <wxxm:elements> <gml:Point srsName="urn:ogc:def:crs:EPSG::4329"> <gml:pos>37.99999923833 −8.000000047683717 16154.4</ gml:pos > </gml:Point> <gml:TimeInstant> <gml:timePosition>2015−10−27T11:10:00.000+01:00</ gml:timePosition> </gml:TimeInstant> </wxxm:elements> </ wxxm:DomainObject> </wxxm:domainSet> <gml:rangeSet> <gml:ValueArray> <gml:valueComponents> <wxxm:Amount uom="CU">0.5</wxxm:Amount> </ gml:valueComponents> </gml:ValueArray> </gml:rangeSet> </ wxxm:DiscreteCoverage></p><p>The ConSA service wraps these WXXM DiscreteCoverage elements in a WFS FeatureC- ollection container, aligned with the OGC WFS 2.0 standard:</p><p>Listing 7.3: MyAerodromeType.sld <wfs:FeatureCollection xmlns:wfs="http://www.opengis.net/wfs/2.0"> <wfs:member> <wxxm:DiscreteCoverage /> </wfs:member> <wfs:member> <wxxm:DiscreteCoverage /> </wfs:member></p><p></wfs:FeatureCollection></p><p>78 BIBLIOGRAPHY</p><p>[1] Sesarju.eu, “Sesar | partnering for smarter aviation,” 2015. [Online]. Available: http://www.sesarju.eu/</p><p>[2] H. Appleman, “The formation of exhaust condensation trails by jet aircraft,” Bulletin American Meteorological Society, vol. 34, no. 1, 1953.</p><p>[3] U. Schumann, “Formation, properties and climatic effects of contrails,” The Comptes Rendus Physique, vol. 6, no. 4, 2005.</p><p>[4] B. Kärcher, B. Mayer, K. Gierens, U. Burkhardt, H. Mannstein, and R. Chatterjee, “Aerodynamic contrails: Microphysics and optical properties,” Journal of the Atmospheric Sciences, vol. 66, no. 2, 2009.</p><p>[5] K. Gierens, P. Spichtinger, and U. Schumann, “Ice supersaturation,” in Atmospheric Physics, ser. Research Topics in Aerospace, 2012. [Online]. Available: http://dx.doi.org/10.1007/978-3-642-30183-4_9</p><p>[6] P. Minnis, D. F. Young, D. P. Garber, L. Nguyen, W. L. Smith, and R. Palikonda, “Transformation of contrails into cirrus during success,” Geophysical Research Letters, vol. 25, no. 8, 1998.</p><p>[7] D. J. Travis, A. M. Carleton, and R. G. Lauritsen, “Regional variations in us diurnal temperature range for the 11-14 september 2001 aircraft groundings: evidence of jet contrail influence on climate,” Journal of climate, vol. 17, no. 5, 2004.</p><p>[8] F. Schröder, B. Kärcher, C. Duroure, J. Ström, A. Petzold, J.-F. Gayet, B. Strauss, P. Wendling, and S. Borrmann, “On the transition of contrails into cirrus clouds,” Journal of the atmospheric sciences, vol. 57, no. 4, 2000.</p><p>[9] R. Meerkötter, U. Schumann, D. R. Doelling, P. Minnis, T. Nakajima, and Y. Tsushima, “Radiative forcing by contrails,” Annales Geophysicae, vol. 17, no. 8, 1999. [Online]. Available: http://www.ann-geophys.net/17/1080/1999/</p><p>79 BIBLIOGRAPHY</p><p>[10] U. Burkhardt and B. Kärcher, “Global radiative forcing from contrail cirrus,” Nature climate change, vol. 1, no. 1, 2011.</p><p>[11] Adg.stanford.edu, “Emissions regulations,” 2015. [Online]. Available: http: //adg.stanford.edu/aa241/emissions/emissions.html</p><p>[12] R. Sausen, I. Isaksen, V. Grewe, D. Hauglustaine, D. S. Lee, G. Myhre, M. O. Köhler, G. Pitari, U. Schumann, F. Stordal et al., “Aviation radiative forcing in 2000: An update on ipcc (1999),” Meteorologische Zeitschrift, vol. 14, no. 4, 2005.</p><p>[13] U. Schumann, “Atmospheric physics,” 2012.</p><p>[14] A. Jackson, B. Newton, D. Hahn, and A. Bussey, “Statistical contrail forecasting,” Journal of Applied Meteorology, vol. 40, no. 2, 2001.</p><p>[15] D. P. Duda and P. Minnis, “Basic diagnosis and prediction of persistent contrail occurrence using high-resolution numerical weather analyses/forecasts and logistic regression. part ii: Evaluation of sample models,” Journal of applied meteorology and climatology, vol. 48, no. 9, 2009.</p><p>[16] U. Schumann, “On conditions for contrail formation from aircraft exhausts,” Mete- orologische Zeitschrift, vol. 5, no. 44, 1996.</p><p>[17] M. Strohmeier, V. Lenders, and I. Martinovic, “On the security of the automatic dependent surveillance-broadcast protocol,” IEEE Communications Surveys and Tutorials, vol. 17, no. 2, 2015.</p><p>[18] S. Bacharach, “The ogc announces styled layer descriptor & symbol encoding specifications,” 2007. [Online]. Available: http://www.opengeospatial.org/ pressroom/pressreleases/761</p><p>[19] M. Fowler, Patterns of Enterprise Application Architecture, ser. A Martin Fowler signature book. Addison-Wesley, 2003. [Online]. Available: http://books.google.de/books?id=FyWZt5DdvFkC</p><p>[20] W. Rahayu, T. Torabi, A. Taylor-Harris, and F. Puersch, “Ows-8 aviation – weather information exchange model (wxxm) engineering report,” ser. OGC ® Public Engineering Report, 2012.</p><p>[21] S. Bruno, “Ows-7 aviation – wxxm assessment engineering report,” ser. OGC® Public Engineering Report, 2010.</p><p>80 CONFIDENTIAL!</p><p>This thesis contains confidential, company internal information, which can only be accessed for assessment or examination purposes.</p><p>It is forbidden to print copies or distribute this thesis.</p><p>Signature</p> </div> </article> </div> </div> </div> <script type="text/javascript" async crossorigin="anonymous" src="https://pagead2.googlesyndication.com/pagead/js/adsbygoogle.js?client=ca-pub-8519364510543070"></script> <script src="https://cdnjs.cloudflare.com/ajax/libs/jquery/3.6.1/jquery.min.js" crossorigin="anonymous" referrerpolicy="no-referrer"></script> <script> var docId = 'ed3b80a76cc4f856f075d0785c6e44b7'; var endPage = 1; var totalPage = 96; var pfLoading = false; window.addEventListener('scroll', function () { if (pfLoading) return; var $now = $('.article-imgview .pf').eq(endPage - 1); if (document.documentElement.scrollTop + $(window).height() > $now.offset().top) { pfLoading = true; endPage++; if (endPage > totalPage) return; var imgEle = new Image(); var imgsrc = "//data.docslib.org/img/ed3b80a76cc4f856f075d0785c6e44b7-" + endPage + (endPage > 3 ? ".jpg" : ".webp"); imgEle.src = imgsrc; var $imgLoad = $('<div class="pf" id="pf' + endPage + '"><img src="/loading.gif"></div>'); $('.article-imgview').append($imgLoad); imgEle.addEventListener('load', function () { $imgLoad.find('img').attr('src', imgsrc); pfLoading = false }); if (endPage < 7) { adcall('pf' + endPage); } } }, { passive: true }); </script> <script> var sc_project = 11552861; var sc_invisible = 1; var sc_security = "b956b151"; </script> <script src="https://www.statcounter.com/counter/counter.js" async></script> </html>