The onset of the COVID-19 pandemic has resulted to a drastic change in flight traffic. Given this, it is crucial for airport operators to understand how travel restrictions impact airport operations for instance, in terms of flight distribution. Salzburg Airports just one of the many airport hubs in Europe that have been heavily affected by the COVID-19 crisis particularly due to the movement restrictions imposed by the Austrian Government since the onset of the pandemic. With this, it will be crucial for various stakeholders to easily visualize and understand the impact of the pandemic on the general direction of flights going in and out of the Salzburg Airport. Analyzing Air Traffic Distribution in Salzburg Airport Using Standard Deviational Ellipse (AirTraDis) is a GIS web application development project that aims to visualize flight data and analyze the spatial distribution of flights departing from and arriving at Salzburg Airport using standard deviational ellipse.
Therefore, the purpose of this study is to identify the central tendency, dispersion, and directional trends of the flight data in Salzburg Airport. To achieve this, among other methods, the ArcGIS tool Directional Distribution (Standard Deviational Ellipse) is used. This tool requires point or line features as input and generates an ellipse based on that, showing the overall spatial distribution of the data. The use of this form of presentation makes it easy and quick for users to recognize the spatial trends of data and to compare them easily with ellipses generated from other datasets.
In this project, the ArcGIS platform is used as the primary spatial data infrastructure to publish the map services and serves the web application while PostGIS serves as a database to store the necessary datasets. As shown in the initial idea of the system architecture, data from different sources, including air traffic data and additional auxiliary data gets stored in a PostGIS database. From there, ArcGIS Pro serves as a working environment for tasks like the creation of metadata, data processing, and the final publishing of the data and tools as services in ArcGIS Server. A geoprocessing service to calculate the Standard Deviational Ellipses, real-time flight data from a GeoEvent service, and the published WMS and WFS services all get incorporated into a web application. The application is built with the WebApp Builder tool of the ArcGIS platform and after publishing it can be accessed on a variety of different output devices.
As the work on this project progressed, however, it became clear that due to technical problems such as lack of publishing rights and unstable server connections, the practical implementation of this initial architecture was not possible. Therefore, some aspects of this plan were not implemented as intended in the initial concept. The ultimately created system architecture differs in some respects from the initial idea and includes refinements but also some compromises and imperfect replacement solutions. Below is the final system architecture used for this project.
In the following subchapters, the tasks involved in realizing this project and the applied methods get explained in detail. Additionally, problems that arose and the steps that were taken to solve them are explained and get justified.
Aside from the technical aspect, one of the goals of this course is also to develop the project management skills of the students especially in the implementation of a GIS project. A project abstract was defined at the beginning of the semester until a final topic was decided and agreed upon by the advisors and the students. Initially, a project overview document outlining all the related project management components (e.g. project goals, resource and budgeting, scheduling, work breakdown structure, and risk management plan) was submitted. As a result of the project planning, we formulated five work packages outlined below:
To monitor the issues and other project resources, GitLab was used as the main project management tool. GitLab is a powerful web-based lifecycle tool that also provides repository management for project wiki, issue tracking, milestone monitoring, etc. Issue labels corresponding to a specific work package were created to easily identify which aspect of the project is being worked on by a team member. By the end of the project implementation, most of the issues were already resolved and closed. GitLab was also used to store some code snippets used in data acquisition, data processing, and metadata management. Overall, the use of GitLab for the monitoring of the project tasks seems beneficial especially that the course was held virtually and there is less personal interaction between the team members and the advisors.
The general overview of the project can be found in the project wiki section of GitLab as well. This is particularly useful for other users who wanted to know more about the project background, its objectives, purpose, and stakeholders.
Furthermore, to track the project schedule, a Gantt chart detailing the tasks, person responsible, as well as the target dates was created as part of the project planning. Since the project budget was estimated in terms of manhours (100 hours for each member),the weighted percentage for project completion assigned to each task was based on the corresponding number of estimated man-hours. This way, the smaller tasks that require fewer man-hours will have a smaller percentage contributing to overall project completion while the significant ones such as those in the development will have a bigger impact in terms of project completion. The weighted percent complete column in the Gantt chart was also used to report the project progress to the advisors.
The basis for any geospatial project is the involved data. Therefore, the first actual task in the realization of the planned project was the identification and acquisition of freely available datasets and sources that could be used for the AirTraDis project.
Since the overall topic of this project is air traffic, the main data source was required to provide information on the air traffic of Salzburg Airport with spatial attributes. Such open access data on air traffic gets provided on the website of the OpenSky Network. In order to get access to the historical database of the OpenSky Network, an application was sent, describing the intended use of the data.
The historical database can be accessed via an SSH client and a provided username and password. The most popular dataset in the OpenSky database is called state_vectors_data4 and includes detailed information about the position of every recorded aircraft every couple of seconds. After acquiring this data for testing purposes, we realized that it does not fit the purpose and scope of this project. The AirTrDis project aims at showing grand-scale changes in the air traffic distribution over several years and for this purpose this dataset turned out to be too detailed. Instead of the state vector data, we discovered the table flights_data4. It has one entry for every flight ever recorded by the receivers and describes them with attributes like flight sign and time stamps. Most importantly, automatically estimated from the recorded flight paths of the aircraft, departure and arrival airports are included for every flight. Since the dataset does not include any spatial information like coordinates, this information is used in a later step to add spatial context to the flight data.
With this, all flights departing from, or respectively arriving in Salzburg airport (ICAO code= LOWS) since the beginning of records, got queried from the according table. Using further commands, the data displayed in the terminal can be exported as a text log-file. This can be further processed by transforming the data in a CSV file. For this project we achieved this by using the software Cygwin (https://www.cygwin.com/)which allows us to use the following Linux command in the Windows environment to accomplish the conversion from txt files to CSV files:
The combined dataset of flights departing from or arriving in Salzburg comprises almost29,000 arriving flights and 34,000 departing flights of Salzburg airport between the years 2016 and 2020.
To locate the departure and origin airports in this dataset, which at this stage are only indicated by ICAO-codes, an auxiliary dataset was needed to assign actual spatial values to the airports. For this, the website OurAirports offers the dataset ‘airports’ provided as a CSV file, containing among other attributes airport names, their ICAO-code and location information specified by latitude and longitude. Combining the information from this dataset with the prior acquired flight data a basis for the spatial analysis of air traffic of Salzburg airport was created. After some filtering approximately 27,000 flights are left in the combined dataset including all flights where geolocation information could be derived. Additionally, since this project aims at comparing usual flight traffic throughout the years with the impact of theCOVID-19 crisis, only the months January until June were retained in the dataset.
A dataset containing point features of cities and towns with according regional significance was acquired from the Natural Earth vector map. We reduced the number of entries in this dataset to 330 locations including all capitals of the countries but also other significant cities in areas without close capitals or metropolises. Secondly, the borderlines of all countries were acquired from the same source, Natural Earth. We use this data for building our own basemap in combination with the airport locations and important cities.
an auxiliary webservice was identified to be used as a basemap layer which can then be used to display web maps in a different projection. The European Environmental Agency(EEA) states that for generalizing data, statistical mapping, and analytical mapping equal-area map projections are required. Therefore, with the single purpose of bringing a different map projection in ArcGIS Online, a Lambert azimuthal (LAEA) projection basemap, as recommended by the EEA was identified and later incorporated (Pfeifer, 2011).
The OpenSky Network live API was used to retrieve real-time air traffic information. The service collects so-called state vectors of airplanes describing their position and orientation, and updates these every few seconds or when a new sensor signal is sent. We accessed the OpenSky live data stream via the REST API by sending an http-request to the server, which is followed by the desired response.
In the Node-RED workflow, an http-request is sent every 60 seconds to request the live state-vectors from the OpenSky Network server. The response is then filtered and only entries with geolocation information get passed on. After a reorganization of the structure of the data, it gets published as a topic via MQTT. This data is used as an additional source of information for the user of the AirTraDis web application to describe the frequency and directional distribution of airplane routes at the time of use.
Before the actual data loading, the datasets were converted first into a uniform GIS format and stored in a staging file geodatabase. The projection of the dataset was also set to EPSG:3035 / ETRS89 / ETRS-LAEA, the general recommended projection of the European Environmental Agency for GIS maps covering the continental EU.
When it comes to the actual data loading to the enterprise database, we used the assigned sgroup connection credentials to connect to the existing PostGIS geodatabase. For the historical flight dataset and the other auxiliary data, we loaded them manually in PostGIS using ArcGISPro. At this point, it is extremely crucial to specify a configuration keyword that contains the GEOMETRY_STORAGE parameter in the tool environment, which int his case is the PG_Geometry (the setting for the PostGIS geometry type) datatype. PostGIS follows the OGC Simple Features specification for an SQL. Settingthe configuration keyword to PG_Geometry ensures that it uses the OGC well-known binary (WKB) and well-known text (WKT) representations of geometry in the PostGIS database in compliance to the ISO 13249-3 data storage standards.
Describing the content of the spatial data is as important as the data itself which is why metadata compliant to ISO standards were created also for the datasets used in this project. Specifically, the ISO 19115 standard discusses what information should be included in geographic metadata while another companion standard, ISO19139:2007 standardizes the expression of 19115 metadata using the Extensible Markup Language (XML) and includes the logical model, Unified Modeling Language(UML).
ArcGIS supports the creation of metadata incompliance with these standards (ISO 19115, Geographic information — Metadata and the implementation specification ISO 19139, Geographic information —Metadata — XML schema implementation) so updating the datasets’ metadata was also done in ArcGIS Pro. Although there is an internal metadata validation being done within ArcGIS to ensure that metadata complies with these standards, we did a secondary validation by exporting the metadata to an XML file and uploading and validating it in the local GeoNetwork deployment in the department.
For the implementation of the real-time flight data, a GeoEvent Service was created. The defined GeoEvent Service is subscribed to the MQTT topic defined in chapter3.2.3., interprets the incoming data, reprojects it to the map projection used in this project (EPSG: 3035) and publishes it as a streaming service on ArcGIS Server.
However, while working on this project, the ArcGIS Server platform provided turned out to be very unreliable. Constant access problems meant that neither extensive, urgently necessary tests could be carried out, nor that as soon as the publication of data on this server had worked, there would have been an assurance that published services could reliably be used for further work steps. The further use of these services, however, forms the basis for all upcoming work steps such as creating and testing the geoprocessing tool and creating a web map. For this reason, the project team decided that another solution would have to be found with which these problems and uncertainties could be solved in good time. Due to the initially determined strategy that the entire project should be setup using the ArcGIS platform and the dependency of the designed geoprocessing tool on the ArcGIS environment, the publication of the map services in ArcGIS Portal of the Z_GIS Department was agreed as a solution.
Portal for ArcGIS is a component of ArcGIS Enterprise that provides a user-friendly, searchable repository for maps and apps in an organization. Together with ArcGIS Server, it can also be used to publish OGC-compliant layers such as WFS and WMS, as well as create web maps and web applications similar to ArcGIS Online. However, unlike AGOL, items shared in Portal are not explicitly shared to the public unless specified otherwise.
We wanted to create a geoprocessing service that the users can run within the application using the available flight dataset to generate ellipses showing the spatial central tendency and directional trend of flights in a specific time period (ex. January 2019) so they can easily compare and visualize the flight distribution. While the Directional Distribution tool can be used directly as it is, we wanted to allow the users to apply custom data filtering, so a model was initially developed using Model Builder.
However, after publishing the geoprocessing service, we encountered an issue in running the service due to some permission issues to the ArcGIS Server jobs folder which is being used by the GP tool to store the intermediate results. We tried to resolve it but unfortunately, we were unable to do so which is why we decided to publish it as a web tool in Portal for ArcGIS.
Upon publishing in Portal, we encountered another issue with regards to the privilege on the portal account (sgroup06 and sgroup13). Since only users with administrative privilege can publish geoprocessing services in Portal, we were also not able to publish our own GP tool because our portal usernames do not have that kind of privilege.
As a workaround, we did the data processing and the generation of the ellipses in ArcGIS Pro for all the months in the five-year time period. Then we published the results as a map service in Portal and added them in the web app. This way, users can also still query the ellipses for a specific month on a given year. While this seemed different from our original proposal, we think that the project in general still achieved its goal of creating an application to visualize the directional trends in flight data using the standard deviational ellipse and other aggregation techniques.
One of the final steps of the AirTraDis project was the creation of a web application which can be used to communicate the found insights on the spatial distribution of flights to and from Salzburg airport. To achieve this the Web AppBuilder of the ArcGIS platform was used. The Web AppBuilder provides customizable templates, a large collection of adjustable widgets and publishes the final application following the principles of responsive web design, meaning that the product can be viewed as optimized versions on a variety of platforms with different screen sizes.
The basis of a web map application is the underlying web map. This web map was created in ArcGIS Portal and incorporates all the acquired data for this project.
In retrospect, the overall project implementation of the SDI project can be deemed successful given the resulting web application developed amidst some technical difficulties encountered during the course of implementation. Although the main application was developed using a commercial solution, there is still a high degree of interoperability in the SDI project since the datasets used also comply with the open standards and the main application is also accessible by the public.
However, we still see a lot of improvements that could be made such as the inclusion of time animation for the time-aware data in the web application. Also, the main UI of the application can still be improved to become more user friendly. Right now, it is intuitive, but it may not appear as clear for beginners to figure out what exactly is being shown on the map. Custom scripts can also be used to retrieve and incorporate more real-time/streaming layers. And lastly, other spatial distribution techniques can also be incorporated to visualize the flight data in harmony with other publicly available thematic layers as well.
*This project was accomplished with the help of my colleague, Nelson Schaefer.
