The Problem Space
Pilots who also operate drones share a common frustration. The airspace restrictions that govern where drones can and cannot fly — Control Zones, Aerodrome Traffic Zones, Restricted areas, Prohibited areas, Danger areas, Temporary Flight Restrictions, and their various regional equivalents — are publicly available information. They are published in Aeronautical Information Publications, charted on sectionals, and maintained in structured databases. What they are not, generally, is available as a single consolidated layer that can be toggled on and off inside the Electronic Flight Bag applications that pilots already use for flight planning.
This is a gap that matters more than it might appear at first glance. There is a notable overlap between the general aviation community and the drone community, and those who fall into both camps tend to have experience with EFB applications such as ForeFlight. For this group, a reasonable preference for some might be to keep everything in one tool rather than switching between purpose-built drone applications and the EFB they already rely on for manned flight planning. ForeFlight provides excellent coverage of manned aviation airspace, but it does not natively offer a consolidated view of all restriction types relevant to drone operations across multiple regions in a single toggleable layer.
The data exists. The pipeline to make it easily consumable in an EFB did not — at least not in a form that served this use case. This project is an attempt to close that gap for pilots operating in the United States, the United Kingdom, across Europe, and in Canada.
Data Sources and Regional Considerations
Airspace classification and nomenclature varies by region, though the underlying concepts are broadly consistent. What the United States designates as a TFR (Temporary Flight Restriction) may appear as a NOTAM-based temporary restriction in the UK, while controlled airspace around major airports is structured as Class B in the US and CTRs or TMAs in European ICAO-aligned systems. The differences in naming are significant enough to cause confusion, but the fundamental information — a geographic boundary, an altitude floor and ceiling, and a set of operating restrictions — is the same regardless of the jurisdiction.
For the purposes of this project, the scope is limited to permanent airspace structures. These are the restrictions that are effectively always in place: Control Zones, Aerodrome Traffic Zones, Military Aerodrome Traffic Zones, Restricted areas, Prohibited areas, Danger areas, Control Areas, and Terminal Manoeuvring Areas, along with their regional equivalents. Temporary restrictions are deliberately excluded; they change on a timescale that demands a fundamentally different approach to data management and are better served by tools designed specifically for that purpose.
An alternative approach would be to scrape national AIPs directly and extract airspace geometries from the published documents. In practice, many AIPs are heavily PDF-driven, and the known complexity of parsing airspace boundaries from that format made it a less attractive option. OpenAIP, by contrast, provides a structured API that returns airspace geometries as GeoJSON, filterable by country and airspace classification — making it the more sensible starting point from an API consumer's perspective. The platform provides solid coverage across Europe, the United States, and Canada. The data is community-maintained against official AIPs and updated regularly from well-known sources. In general, it has proven to be relatively reliable; but as any good pilot knows, you should always verify against primary sources before making operational decisions. For the purposes of this project, it represented the most practical starting point.
The Pipeline
ForeFlight supports custom map layers via KMZ files — a zipped variant of KML (Keyhole Markup Language) that can contain styled geographic overlays. This means that if we can transform OpenAIP's airspace data into properly formatted KML with appropriate styling, the result can be imported directly into ForeFlight and toggled on and off like any other map layer.
The implementation is straightforward Python. The pipeline performs four operations in sequence:
- Query the OpenAIP v2 API for airspace in the target region, filtering to the permanent classifications relevant to that region.
- Convert each airspace polygon into a KML Placemark element with colour-coded styling — red for Prohibited and Restricted areas, amber for Danger areas, and blue for controlled airspace.
- Zip the resulting KML document into a KMZ archive.
- Publish the KMZ as a GitHub Release asset, making it available for download.
The pipeline currently generates separate layers for the United States, the United Kingdom, broader European coverage, and Canada. Each region produces its own KMZ, allowing users to import only the layers relevant to their operating area rather than loading a single oversized global file.
The entire script is approximately 200 lines of Python. There is nothing particularly clever about the implementation; the value is in the fact that it exists as an automated, repeatable process rather than a one-off manual exercise.
Keeping the Data Current
Static exports of airspace data have a shelf life. While permanent airspace structures do not change frequently, they do change — and they change on a predictable schedule. The international aviation community operates on the Aeronautical Information Regulation and Control (AIRAC) cycle, which dictates that changes to aeronautical information take effect on fixed dates, spaced 28 days apart. This means that any published airspace layer has a maximum useful life of 28 days before it should be regenerated to ensure accuracy.
This is where the project moves from a simple conversion script to something more useful. The repository includes a GitHub Actions workflow configured to run on a weekly cron schedule:
on:
schedule:
- cron: '0 3 * * 4' # Weekly on Thursday at 03:00 UTC
workflow_dispatch:
Every Thursday at 03:00 UTC, the workflow fires, regenerates the KMZ files for all supported regions from the current OpenAIP data, and publishes new releases. If nothing has changed in the underlying airspace data, the resulting files are identical and no action is required on the part of the end user. If an AIP has been amended as part of an AIRAC cycle, the new boundaries are automatically reflected in the next generated layer.
This approach effectively turns the GitHub repository into a self-refreshing distribution point for drone airspace data across multiple regions. The automation is minimal — perhaps 15 lines of YAML — but it eliminates a significant weakness of static airspace exports: the tendency for data to go stale without anyone noticing.
Importing into ForeFlight
The import process for end users is deliberately simple. Download the latest KMZ release for your region from the repository, transfer the file to iCloud Drive or Dropbox, and in ForeFlight navigate to More, then Files, and tap the KMZ file to import. The layer then appears under Maps, Layer Options, Custom, where it can be toggled on or off. Once imported, the relevant set of permanent restrictions overlays the chart.
It is worth noting that these layers are intended to supplement, not replace, standard airspace awareness practices. Pilots and drone operators should continue to consult NOTAMs and TFRs for temporary restrictions, and the layers deliberately exclude temporary airspace structures for this reason. Mixing permanent and temporary data into a single layer would compromise the reliability of both; it is debatable, but a stale temporary restriction could be more dangerous than no data at all.
Scope for Contribution
The repository is open source and there are several areas where contributions would be particularly valuable:
Additional regions. The pipeline is architected around OpenAIP's API, so extending it to additional countries within their coverage area should require minimal modification — primarily a change to the country filter parameter and potentially adjustments to the colour scheme if local airspace classifications differ significantly from the currently supported regions. Users in other regions are welcome to fork the repository or submit pull requests to add support for their area.
Flight Restriction Zones. The current implementation covers traditional airspace classifications but does not yet include drone-specific FRZs — known variously as FRZs, TFRs, Prohibited, or Restricted areas depending on the jurisdiction — around prisons, nuclear facilities, and other sensitive sites. These are relevant to the UAS community specifically and would make the layers more comprehensive for their target audience.
Styling improvements. The current colour scheme is functional but not particularly refined. There is room for improvement in label placement, transparency levels, and altitude annotation.
The repository is available on GitHub (https://github.com/ybotspawn/ForeFlight-DroneLayers). Issues and pull requests are welcome. If you are a drone operator or GA pilot and find the layers useful, feedback on coverage gaps or inaccuracies in any of the supported regions would be particularly helpful in improving the data quality over time.
