Assist. Prof. Kamil Ekštein, M.Sc., Ph.D. @ DCSE | FAS | UWB – UC310
E-mail: kekstein (AT) kiv (DOT) zcu (DOT) cz
Discord: https://discord.com/invite/f9tmnXgZBx / kamil.ekstein (Kamil Ekštein#1460)
Responsible for: Technical specification of the product (SRTM, NMEA, and other formats); acquiring,
preprocessing, processing, and fine-tuning of the geographic and air space data; geographical/geometric
computation methods; air traffic rules and regulations, air space organization, aeronautical radio communication.
The goal of the project named PigeonNavigator is to develop an air navigation application for small and ultralight aircraft flying under VFR rules1 for mobile devices (smartphones, tablets, touch screen subnotebooks) operating using the GPS coordinates acquired in real time from the device's GPS module2.
The recommended development tools are not explicitly set. However, according to extensive experience, for the development of native mobile multiplatform applications both (i) Microsoft Visual Studio/.NET MAUI, and (ii) Embarcadero RAD Studio/FireMonkey are the most efficient. The use of other tools, not listed here, is encouraged as long as they can produce native binary code for the respective mobile platform (at least Android). Non-native tools based upon e.g. JavaScript are not recommended.
Among the required functions is predominantly: (i) tracking and alerting the pilot about the boundaries of the restricted (R), temporarily segregated/reserved (TSA/TRA), prohibited (P), and dangerous (D) air spaces, as well as the air spaces that are tower-controlled (CTR, TMA, C, D), in which the VFR flight is subject to ATC clearance3, and some other restrictions; (ii) displaying the terrain level using the SRTM (= Shuttle Radar Topography Mission) data and alerting the pilot about the ground proximity; (iii) warning against the collision with the terrain of higher altitude than the actual flight altitude along the current bearing; (iv) navigation (finding the direction/bearing of the shortest route and the distance) to a given point, usually an airfield; (v) displaying important operational parameters of the flight in the real time on the display of the mobile device – particularly the ground speed (GS), the flight height above the terrain (AGL), the flight altitude (ALT) or the flight level (FL) respectively, and the current flight heading (HDG).
Of course, the software can also have a number of other features at your discretion (however, it is a good idea to consult your intention to implement new features with the project coordinator so that you do not implement something that is already provided on board of the aircraft in another way). When designing the user interface, also keep in mind that the pilot must first and foremost operate the aircraft safely and therefore the navigation controls should be as simple as possible.
An acoustic link between the navigation application and the pilot is generally possible (by connecting the line or headphone output of the mobile device to the on-board intercom), but it is not very common in small sport aircraft – most cheap or older intercoms do not have any line inputs. The data output should be given using common approved phrases and abbreviations (available in AIP C.R. GEN 2.2 Abbreviations and L Phraseology). Considering that the developed product can be used by pilots whose native language is not Czech, all communication with the product user interface should be in English, which is de facto standard in civil aviation.
Explanatory notes:
1 VFR = Visual Flight Rules, i.e. the rules under which the pilot
is operating when flying the plane "visually", by a visual reference to the ground. Of course,
the software is not meant to (and cannot) replace professional inertial navigation systems for the instrument
flight rules (IFR) flights. A more detailed specification of the terms VFR and IFR can be found in
ICAO Annex L series documents, e.g. L2 Rules of the Air, L4444 Airspace Arrangement, and elsewhere.
The ICAO Annex L documents can be found in the Czech version at
https://aim.rlp.cz/predpisy/predpisy/index.htm
and in the English version at
https://elibrary.icao.int/home.
2 GPS = Global Positioning System, details can be found at
https://en.wikipedia.org/wiki/Global_Positioning_System.
The GPS module usually communicates with the host device one-way via a serial port by continuously
transmitting messages in NMEA 0183 format, which is described e.g. at
https://www.gpsworld.com/what-exactly-is-gps-nmea-data/
or at https://en.wikipedia.org/wiki/NMEA_0183.
3 ATC = Air Traffic Control. A brief overview of the air spaces in
the Czech Republic can be found e.g. from the web flight preparation application
https://aisview.rlp.cz.
The terrain elevation data of the Czech Republic (area defined by 47°N, 12°E and 52°N, 19°E) obtained during the STS-99 SRTM (Shuttle Radar Topography Mission) of the US space shuttle Endeavour in 2000 are available in the directory https://amos.fav.zcu.cz/projects/pigeon/data/srtm3-cze/.
The .hgt files are in the Digital Terrain Elevation Data (DTED) file format. These are headerless files filled with signed short int data, i.e. a signed 16-bit integer in big-endian order (i.e. the most significant byte is at the lower address, i.e. at the first position). Each of these numbers represents the elevation of the terrain in metres above the WGS84/EGM96 reference geoid. The parameters of the reference geoid can be found on the web page of the Office of Geomatics of the National Geospatial-Intelligence Agency, or on Wikipedia at https://en.wikipedia.org/wiki/World_Geodetic_System#WGS84. The data may contain "holes" due to inaccuracies in the measuring equipment – these have been flagged with the value of (signed short int) -32768 during processing.
Each file covers an area of one geographic angular degree, sampled at 3 arc seconds, i.e. it contains 1201 rows of 1201 samples. Thus, at our latitude, one sample represents a geospheric rectangle of about 94 × 62 metres. Using the terrain elevation data directly without calculating the resolution relative to the current latitude makes no sense. The same applies for using the AMSL1 elevation data from the GPS receiver directly without reference to the digital terrain model.
Detailed information and a description of the DTED data is provided in the documents Quickstart.pdf and SRTM_Topo.pdf. Additional specialized information is available on the website of the data originator, the NASA's Jet Propulsion Laboratory.
Explanatory notes:
1 AMSL = Above Mean Sea Level.
The only currently available and usable vector data for individual airspaces is in the OpenAir format. A complete set of vector data describing the whole Czech airspace is available from the website of the Open Flightmaps initiative at https://www.openflightmaps.org/lk-czech-republic/. Outdated files (for illustration & explanation) with the airspace description of the Czech Republic are in the archive https://amos.fav.zcu.cz/projects/pigeon/data/openair-cze/oacr.zip or individually in the directory https://amos.fav.zcu.cz/projects/pigeon/data/openair-cze/.
While the above-mentioned data can be used directly in the product development, the recommended way to use it is only as a source of information for a conversion to some more suitable format. The project coordinator recommends the use of the VMX (Vector Map XML) format – this is a regular XML 1.0, whose exact structure and the tags it contains are defined by this XSD/XML scheme. A sample file (very incomplete) of the Czech airspace in the VMX format is available here.
The basic geodetic problem, which can be used as a basis for a further exploration, is described in the seminar work of Lenka Reinwartová, M.Sc., formerly a student of Geomatics at the Dept. of Mathematics, FAS UWB in Pilsen.
These links below can serve as an inspiration for the product design and development and they often lead to some important theoretical insights that should be considered when designing the product.
Design and contents © Kamil Ekštein, PARMAL | DCSE | FAS | UWB in Pilsen