Declaring current and future flight plans in a standardized fashion
As the airspace gets busier, flight schedules and associated geographic information must be shared and transmitted in a standard fashion. At the moment the flight plans are built on customized software or other opensource software. Most of these software have a the functionality to export flight plans as “standard” geo-referenced file e.g. see KML export in QGroundcontrol.
Just like KML, there are numerous other formats to capable of handling geographical information, just take a look at some proprietary and open data formats. Do they work? Yes, perfectly.. but only if you know some of the specifics and more importantly, depending on what you are trying to some work better than others.
When it comes to flight declarations, you are necessarily sharing data about future flights “to interested parties”, fortunately the Global Unmanned Traffic Management Association (GUTMA) has developed a flight declaration protocol. In our involvement with GUTMA, we developed backwards-compatible update to the declaration protocol or the “development version”, in this article you will learn the importance of standardizing flight declarations / plans and how the development version of the protocol enables you to build services.
In this article you will learn about: - Importance of standardizing flight declaration data and a analysis of the GUTMA flight declaration protocol - Key differences between the agreed protocol and the development version
Analysis of the GUTMA flight declaration protocol
While the published GUTMA protocol is a great step forward, there are certain deficiencies that we can discuss here. At this time, we would recommend you take a look at sample declarations here. There are two fundamental issues with this format:
sequence numberis a numeric field that is incremented and software is expected to read the “highest” sequence number as the current declaration overriding any other previous ones. This puts the onus on the declaring party and also causes issues around deletion e.g. should deleted flights be declared as a new sequence number?
partsfield has a numeric
idstarting with 0 that shows the flight parts and the associated parameters for that part a part can only be
- GeoJSON does not specifically allow volumetric information which is critical for flight path declarations.
sequence number and
parts are the two main things that are different in the development version of the protocol The
parts field is now a GeoJSON
FeatureCollection and every feature has a associated property that holds flight information about that part of the fight and the
sequence number is a UNIX timestamp now which is still a number but this enables temporal processing of flight declarations.
Integration with Live air-traffic
Using GeoJSON feature collection is a minor change / update over the existing one it enables us to interoperate with KML directly and use other standard tools. Finally using timestamp over numeric sequence numbers enables us to parse the declarations using standard date / time libraries. We use flight declarations in Flight Spotlight. Flight Spotlight is meant for live air-traffic and we show declared flights as a overlay as well. By integrating declared flights with live traffic data, we can build capabilities for authorizations.
A critical open issue is how volumetric information is shared in declarations. If you have ideas / formats about how this can be shared, please reach out!