When flying, aeronautical information is an essential component to guarantee the safety of air traffic. The Aeronautical Information Services of Skyguide, the company in charge for air navigation services in Switzerland, is responsible for the procurement, evaluation and processing of necessary aeronautical information and data for the flight. All these components are now part of the new department Aeronautical Information Management (AIM). The AIM advises the crew or the airline company for pre-flight purposes and supports air traffic control and the ground service location [skyguide] . In this context, the ICAO (International Civil Aviation Organisation) specifies a range of charts which have to be published on a regular basis by the AIM, such as the Aerodrome Obstacle Chart. This chart provides the operator with necessary information on obstacles in order to develop procedures that comply with the operating limitations, i.e., with particular reference to obstacle information that limit the maximum permissible take-off mass [ICAO 2001] .
The obstacle chart has to meet high quality regarding accuracy and availability (up-to-date) of data to ensure a safe flight particularly in the case of an emergency. Updating paper charts is a time and cost intensive process. Therefore, Skyguide in cooperation with the Institute of Cartography (Swiss Federal Institute of Technology Zurich, ETH) initiates efforts to develop online applications visualising these obstacle information and other aeronautical data with interactive and automatised updating functions which serve the needs of operators and pilots. A first prototype shows the possibilities of SVG-based technologies for aeronautical charting. In a second stage, attention is focused on finding the best method for updating the data and converting the data on-the-fly into SVG, including the use of PERL and INTERLIS to assist with these tasks.
1 Aeronautical ChartsTtoday
1.1 Use and Purposes
1.2 The Situation
2 SVG-based and Digital Navigation Systems: Understanding the Chance
3 One Idea
3.1 General - The Chart and its Purpose
3.2 Guidelines and Specifications for Charting Application
3.3 Data and Formats
3.4 Transforming the Data
3.4.1 Workflow 1 - Excel 2 INTERLIS (Point Obstacles)
3.4.2 Workflow 2 - Excel 2 INTERLIS (Line Obstacles)
3.4.3 Workflow 3 - DWG 2 INTERLIS (Departure Routes)
3.4.4 Workflow 4 - GRID 2 PNG (Terrain Above Level)
3.4.5 Workflow 5 - SHP 2 SVG (Topography)
3.5 Integrating the Data
3.5.1 Integration of Dynamic Generated Data
3.5.2 Integration of Prepared (Static) Data
3.6 The Result
3.6.2 Separating Data from Presentation
4 What's next?
4.1 Task List
Aeronautical maps or charts are used for multiple purposes. On the one hand, they are used as strategy maps for flight safety and flight planning by organisation experts of air lines and air forces, and on the other hand, pilots of different categories (flights according to visual flight rules, flights according to instrument flight rules, helicopter flights, balloon flights, gliding etc.) use these charts to prepare and ensure safe flight operations.
The amount of initial data and information for those charts is enormous and is increasing constantly. For instance, the aeronautical chart ICAO of Switzerland, 1:500.000 is printed with at least 11 spot colours. Just to give one example for the data density. At the same time, those data and information do not come in one unique format. The situation is not only aggravated by this lack of a standardised format but also by the dynamic nature of data, such as changing routing patterns. But this availability (of updated data) can not be reflected on paper-based charts. One reason for this is the limited number of publication cycles for paper-based products.
Another development, the constantly increasing air traffic is asking for expanding capacities which results clearly in the goal of optimised airspace management by the air navigation services (i.e., "Single European Sky" initiated by Eurocontrol ). This optimisation of airspace requires changes within the airspace organisation which must be reflected in the aeronautical charting products. [eurocontrol] [skyguide]
Therefore, it is understandable that a better framework incorporating the technical tools and diverse data types which offers a more flexible usage and visualisation of data and information would be highly requested.
The deployment of appropriate SVG-based information systems and services can have many contexts: a new product for flight preparation and planning which combines all data sources; an SVG-based moving map solution within a digital navigation system, which is able to process and handle XML/SVG data.
At this time we have to go deeper into research on how such systems can be constructed and implemented. In particular, we need to keep in mind that several user groups should access the same information sources (i.e., database) and use the same system architecture in such a way as to enable them to use a unique, combined operation system. This system needs to provide support for: (1) avoiding redundant data, (2) updating data quickly and efficiently, and (3) generating user-specific charting products. Certainly a pilot at a specific height has different needs from a visualisation than an air traffic controller on the ground who is in charge of monitoring the environment of every aircraft in a controlled airspace.
At the same time we have to keep in mind that paper-based maps will never disappear. A printout in a certain situation might be necessary, while the same charting product in a digital context will be ineffective. Thus, printing options should always be available in the case the pilot wants to take a printed version of the charting information to the aircraft.
The intention of this paper is not to give out general recipes for finding the solutions but it does identify the problem! One way to tackle this problem is to start with small steps. Within this global project of realising a whole vision we tried to develop one digital charting product based on SVG and including functions such as data updates or specific interactions. In the following sections, this SVG-based charting application will be introduced and explained in detail.
The International Civil Aviation Organization (ICAO) advises the Aeronautical Information Services world-wide to develop an Aerodrome Obstacle Chart Type C. The purpose of such a chart is to provide certain obstacle data within a radius of 45 kilometres from the aerodrome reference point (i.e. airport). The chart is intended, among other things, to determine procedures in the event of emergency during approach and departure [ICAO 2001] .
Skyguide and and the Institute of Cartography (ETH Zurich) instigated the development of a SVG-based, interactive Aerodrome Obstacle Chart which should be able to present relevant, updated information at any time. The following guidelines had to be applied to the charting application: (1) separating data from presentation in order to allow independent data updates, (2) the implementation of appropriated interactions and (3) onscreen presentation of the data following cartographic aspects and rules, of course.
Within the scope of a global implementation, specifications regarding the technical realisation are made by Skyguide as follows: The exchange format for the obstacle information, which should be loaded into the application dynamically, had to be text-based in order to support a basic database connection in the future. The description language INTERLIS v1.0 was voted to provide this format. To search through those exchange files and to generate certain (SVG-)code, the scripting language PERL had to be used.
Note: Eurocontrol developed an Aeronautical Information Exchange Model (AIXM) which could be considered in future developments and might replace the entire use of INTERLIS in this context.
What kind of data had to be integrated into the application? Regarding the thematic information, we distinguished 3 types of obstacle information and because the chart is intended to determine procedures in the event of emergency during approach and departure, we needed as well route information:
For the topography, the landscape model distributed by the Federal Office of Topography Switzerland/Bern (swisstopo), a vector data set in the scale of 1:200 000 was used. Following elements of the model were included:
The vector data were in the shapefile format (SHP).
To follow high Swiss cartographic standards, of course a relief had to be implemented. The Relief (as raster image, tiff) was taken from the pixel map 1:200 000 [swisstopo] .
The original data formats varied quite a bit. The transformation of the data into the desired format will be described briefly within the following workflow blocks. As mentioned above, the final format for the thematic information (obstacles and routes) had to be INTERLIS.
This transformation was quick done. But it would be necessary to do it for each file separate when having more than one file for the point information: Store the Excel spreadsheet as tab-delimited text file and pasting INTERLIS transfer file header into it.
Similar done as above, but a PERL script was added within the workflow to ensure that every line consists of its necessary point coordinates and to assign every line its belonging attributes.
This transformation was quite complex. It involved the use of ArcView to generate two separate shapefiles (points and lines of the routes) and manual coding to add attributes to the objects. Before generating an INTERLIS transfer file from the shapefiles via a converter tool, the compilation of a conceptual and physical data model was necessary. After that was done, the converter tool SHP2IL completed the transformation to a INTERLIS transfer file .
The terrain data will kept in the final data format because the terrain will not change frequently. The RIMINI1 [swisstopo] terrain model existed as an ArcInfo GRID. ArcView was used to visualise the GRID, to trim it to a certain extension, and terrains above a certain height were requested. Each requested terrain level was stored as a separate GRID with 2 kinds of information: areas above this certain level and areas of NODATA. The new GRID files were exported is JPGs and later converted to PNGs via Adobe Photoshop to customise it with filters and display the areas without any information transparent.
Also the topography will be kept in the final data format because we presumed it will not change dramatically. As mentioned before, the data came as shapefiles. In ArcView, certain generalisation and cleaning steps were needed to ensure a good cartographic visualisation. In a next step, the converting tools shp2pgsql.exe (PostGIS) and ogis2svg.pl (A.Neumann) were used to generate static SVG files containing the elements of the topography. For each element, one transformation was necessary that allows the update of a single element of the topography into a SVG file.
The integration of the data in an SVG-based charting application will be checked out.
An essential part of the work was to separate the data from the application. For the thematic information of point and line obstacles and departure routes, the dynamic generation of SVG-code is realised. As mentioned, those data had to be stored as INTERLIS transfer files and later read out via PERL scripts in order to create the desired SVG-code. On demand, the SVG-code can be integrated or excluded via interactions (realised with ECMAScript) within the main SVG file (the charting application).
The other information can be integrated or excluded via interactions. The content will be taken directly from the prepared SVG (topography) or SVG files containing PNG images (terrain above level).
Under the usage of the aforementioned transformed data, a user-friendly prototype of an interactive SVG-based Aerodrome Obstacle Charting application embedded in a Graphical User Interface was developed. As expected, the charting application needs its improvements. The most urgent and obvious ones will mentioned in this context.
The charting application contains interactions, such as layer handling and selection options through lists. Also, it is possible to request meta data of the obstacles and route objects. Legend and additional map information are also included.
The separation of the data from the application is realised. The thematic information (i.e., obstacles and routes) is loaded into the charting application on-the-fly. The topography is taken from prepared SVG files.
The converting procedure of the data to INTERLIS needs improvements. A data conversion method with a more automated workflow and less manual interventions is worth further efforts especially for the DWG-data. This implies uniform data which can be realised by a database in the future.
Within the entire workflow of generating this charting application, cartographic rules were applied for such things as generalisation guidelines, graphic and layout rules, symbolisation aspects etc. For instance, the symbolisation of map objects is dependent on the zoom level.
The main shortcoming is the performance of the application that affects the visualisation directly. For example, it takes some time to load the transport network or the vegetation. In this context, new solutions (i.e., tiling) need to be developed.
The cartographic presentation can be enhanced, too; adaptive zooming can be brought in to reduce the information density at different levels of detail (LoD) and to display the content with a more appropriate symbolisation. This might enhance the loading performance as well.
Within this working step we generates an SVG-based charting application. We saw where the shortcomings and handicaps were within the environment. With the analysis of the workflow and the other implementation procedures, we were able to establish guidelines for further work. Those guidelines resulted in a task list to meet our global goal (a framework which incorporates technical tools and diverse data types as well as the ability to generate SVG-based charting products).
Of course, testing the Aerodrome Obstacle Chart on potential users to extract further user needs that influences data, technology and visualisation.
Eurocontrol: The European organisation for the safety of air navigation, which handles the implementation of Air Traffic Control strategies, technical research and development programmes, training, the collection of payments and other tasks. Eurocontrol is based in Brussels. [eurocontrol] [skyguide]
INTERLIS is a standard which has been especially composed in order to fulfil the requirements of modelling and the integration of geodata into contemporary and future geographic information systems. INTERLIS version 1 remains a Swiss standard. The INTERLIS mechanism consists of a conceptual description language and a transfer format which in particular takes into account spatially related data (shortly geodata), thus permitting compatibility among various systems and long-term availability, i.e. depositing in archives and documentation of data.[interlis]
terrain model at a 250m grid covering all of Switzerland.
XHTML rendition created by gcapaper Web Publisher v2.0, © 2001-3 Schema Software Inc.