Find a source of ARINC 424 data for good airport geometries #157

Open
opened 2026-08-18 15:04:51 +00:00 by art · 2 comments
Owner

The airports layer is contractually runways-and-taxiways only (the 2026-08-18 fix that dropped the whole-airport-area blobs). Two countries cannot fill it properly, and both need the same thing: real runway geometry from a proper aviation source.

Poland — no runway geometry exists in BDOT10k, measured:

  • OT_KUKO_A rodzaj 'lotnisko lub lądowisko' (the old #106 source) is a whole-airport land-use blob, which is exactly what the contract now excludes. The layer has no pl partition at all until a runway source lands; Warsaw Chopin renders as plain landcover.
  • The runways themselves are inside OT_PTKM_A (powierzchnia komunikacyjna, the transport-surface cover), which has no RODZAJ column to split them out — the same wall #118's overlay-carve staging kind is about. There is no OT_SKJ*/runway class in the fetched BDOT10k set.

Finland — MTK's lentokenttaalue ladder classifies most runways as 32411/32412, but 5 airfields (Mäntsälä, Lapinlahti, Savikko, Wredeby, Torbacka) have their grass strip drawn as a 32416 "muu lentokenttäalue" grounds area with no runway polygon at all, so the runway-only filter draws nothing for them (labels survive via airport_points).

What would help: a source of ARINC 424 data (the aviation industry's published navigation-data format — precise runway centreline/end coordinates, lengths, widths, taxiways). Candidates: openAIP, OurAirports (derived), FAA's DO-272/ARINC 424 distribution, or a commercial feed. The goal is per-runway polygons (or at least centreline+width) for Poland and the Finnish stragglers, so every country's airports layer can be filled from real runway geometry.

We'd have to implement ARINC 424 support in the importer which is just useful functionality and we'd get all airports with the same quality both in the current countries and all future countries. The difference between Sweden and Iceland is huge right now. I have seen someone import airport data from an ARINC 424 feed (it was a paid product though) and the level of detail was spectacular.

Related: #106 (Poland's old KUKO airports layer, now removed), #110 (Finland's lentokenttaalue import), #118 (importer overlay-carve kind — the mechanism a PTKM carve would need).

The `airports` layer is contractually runways-and-taxiways only (the 2026-08-18 fix that dropped the whole-airport-area blobs). Two countries cannot fill it properly, and both need the same thing: real runway geometry from a proper aviation source. **Poland** — no runway geometry exists in BDOT10k, measured: - OT_KUKO_A `rodzaj 'lotnisko lub lądowisko'` (the old #106 source) is a whole-airport land-use blob, which is exactly what the contract now excludes. The layer has no `pl` partition at all until a runway source lands; Warsaw Chopin renders as plain landcover. - The runways themselves are inside OT_PTKM_A (powierzchnia komunikacyjna, the transport-surface cover), which has no RODZAJ column to split them out — the same wall #118's overlay-carve staging kind is about. There is no OT_SKJ*/runway class in the fetched BDOT10k set. **Finland** — MTK's `lentokenttaalue` ladder classifies most runways as 32411/32412, but 5 airfields (Mäntsälä, Lapinlahti, Savikko, Wredeby, Torbacka) have their grass strip drawn as a 32416 "muu lentokenttäalue" grounds area with no runway polygon at all, so the runway-only filter draws nothing for them (labels survive via airport_points). **What would help**: a source of ARINC 424 data (the aviation industry's published navigation-data format — precise runway centreline/end coordinates, lengths, widths, taxiways). Candidates: openAIP, OurAirports (derived), FAA's DO-272/ARINC 424 distribution, or a commercial feed. The goal is per-runway polygons (or at least centreline+width) for Poland and the Finnish stragglers, so every country's `airports` layer can be filled from real runway geometry. We'd have to implement ARINC 424 support in the importer which is just useful functionality and we'd get all airports with the same quality both in the current countries and all future countries. The difference between Sweden and Iceland is huge right now. I have seen someone import airport data from an ARINC 424 feed (it was a paid product though) and the level of detail was spectacular. Related: #106 (Poland's old KUKO airports layer, now removed), #110 (Finland's lentokenttaalue import), #118 (importer overlay-carve kind — the mechanism a PTKM carve would need).
Collaborator

Research: what ARINC 424 can and cannot give us, and what we already have

Measured 2026-08-18 against the live database and the published sources.

The premise needs splitting in two

ARINC 424 will not give us taxiways. It is an FMS navigation-database format: airports, heliports, runways, waypoints, navaids, airways, procedures. The runway (PG) record carries threshold coordinates, length, bearing and width — points and lines, no surface geometry. Taxiways, aprons, stands and markings are the AMDB standards' domain — RTCA DO-272 / ARINC 816 — which this issue already half-names. The "spectacular" detail seen in a paid import was almost certainly AMDB; that is why it was paid. Jeppesen, NAVBLUE and Hexagon/Luciad are the suppliers and there is no free AMDB feed.

So this issue is really two asks: runway polygons (achievable free, today) and apron/taxiway/stand detail (commercial, or not at all).

Poland's runways ARE in BDOT10k

The issue says "no runway geometry exists in BDOT10k, measured". That is too strong. What is missing is the runway-vs-taxiway distinction, not the geometry — and the split does not need RODZAJ, it needs the KUKO polygon as a spatial mask:

pl_ptkm ∩ pl_kuko_a WHERE rodzaj = 'lotnisko lub lądowisko'

Measured:

  • Chopin: the 15.38 km² KUKO blob yields 1.97 km² of pavement in 2 polygons, and both OurAirports runway centrelines lie 100% inside it (computed centreline lengths 2799 m / 3686 m against published 2800 / 3690 — the two sources cross-validate each other).
  • Nationwide, against all 53 Polish runways OurAirports georeferences: 40 lie ≥90% inside the PTKM pavement, 3 partial, 9 not covered — 85% of total centreline length.
  • The 9 misses are mostly military (EPMI Mirosławiec, EPSN Świdwin, EPRU, EPML, PL-0264/0265 — concrete, 2 km+). That is BDOT10k redacting military installations, not a survey gap.

This is not #118's carve. #118 is a nationwide ST_Difference against the whole cover cascade; this is an intersection restricted to 140 airport polygons. Conflating the two is what made this look blocked.

Watch the SRIDs: pl_ptkm is EPSG:2180, pl_kuko_a is 3857, and geometry_columns reports srid 0 for both — an explicit ST_Transform is required.

The honest caveat: PTKM∩KUKO is runways + taxiways + aprons fused, not per-runway polygons. Iceland's source is already "runways plus taxiways", so this sits inside the layer contract as written; the aprons are the arguable part.

Source survey

Source Licence What it gives Verdict
OurAirports "All data is released to the Public Domain" (verbatim, ourairports.com/data) Runway thresholds, length, width, surface. FI: 105 open runways, 79 with both ends. PL: 135 open, 53 with both ends — including every large airport's main runway Best free option. ST_Buffer(centreline, width/2, 'endcap=flat') → polygons
openAIP CC BY-NC 4.0 (verified on openaip.net) Runways, airspaces Non-commercial — conflicts with our CC0/permissive preference
EUROCONTROL EAD Registered-access service Authoritative AIXM for all of ECAC Not an open download; only viable with an account
National eAIP (PANSA ais.pansa.pl, Fintraffic ais.fi) Per-state, needs checking AD 2.12: THR coordinates, dimensions, surface, per runway Authoritative and matches our national-source pattern, but it is HTML/PDF scraping on an AIRAC cycle
AMDB (DO-272 / ARINC 816) Commercial Taxiways, aprons, stands, markings The "spectacular" one. Paid
OSM ODbL aeroway=runway/taxiway polygons Excluded by the no-OSM framing

Two OurAirports caveats: width_ft carries field width on grass strips (Poznań 02/20 = 984 ft ≈ 300 m), so it needs clamping against length_ft; and reconstruction from one threshold + heading + length yields zero extra runways — every row is both-ends or nothing.

For Finland's grass-strip stragglers: EFLL, EFNS and EFTO have both thresholds + width in OurAirports; EFMN (Mäntsälä) and EFWB (Wredeby) do not.

  1. Poland, now, no new source: build airports from pl_ptkm ∩ pl_kuko_a, and put the KUKO area into cover as airport. Fills the contract for the civil airports today without waiting on this issue.
  2. Then, public domain: an OurAirports runway importer for what step 1 misses — Polish military fields, Finnish grass strips, and future countries with no national survey. This is the reusable "all airports at the same quality" mechanism the issue is really asking for, and it is CC0-clean.
  3. Only if apron/stand detail is wanted: price an AMDB feed. Nothing free reaches that level.

Suggest retitling this issue accordingly — "ARINC 424" names a format that cannot deliver the taxiways in its own description, while OurAirports plus the local PTKM∩KUKO split together cover more than it would.

## Research: what ARINC 424 can and cannot give us, and what we already have Measured 2026-08-18 against the live database and the published sources. ### The premise needs splitting in two **ARINC 424 will not give us taxiways.** It is an FMS navigation-database format: airports, heliports, runways, waypoints, navaids, airways, procedures. The runway (PG) record carries threshold coordinates, length, bearing and width — points and lines, no surface geometry. Taxiways, aprons, stands and markings are the **AMDB** standards' domain — **RTCA DO-272 / ARINC 816** — which this issue already half-names. The "spectacular" detail seen in a paid import was almost certainly AMDB; that is why it was paid. Jeppesen, NAVBLUE and Hexagon/Luciad are the suppliers and there is no free AMDB feed. So this issue is really two asks: **runway polygons** (achievable free, today) and **apron/taxiway/stand detail** (commercial, or not at all). ### Poland's runways ARE in BDOT10k The issue says "no runway geometry exists in BDOT10k, measured". That is too strong. What is missing is the **runway-vs-taxiway distinction**, not the geometry — and the split does not need `RODZAJ`, it needs the KUKO polygon as a *spatial mask*: ```sql pl_ptkm ∩ pl_kuko_a WHERE rodzaj = 'lotnisko lub lądowisko' ``` Measured: * **Chopin**: the 15.38 km² KUKO blob yields **1.97 km² of pavement in 2 polygons**, and **both OurAirports runway centrelines lie 100% inside it** (computed centreline lengths 2799 m / 3686 m against published 2800 / 3690 — the two sources cross-validate each other). * **Nationwide**, against all 53 Polish runways OurAirports georeferences: **40 lie ≥90% inside the PTKM pavement**, 3 partial, 9 not covered — **85% of total centreline length**. * The 9 misses are mostly **military** (EPMI Mirosławiec, EPSN Świdwin, EPRU, EPML, PL-0264/0265 — concrete, 2 km+). That is BDOT10k redacting military installations, not a survey gap. **This is not #118's carve.** #118 is a nationwide `ST_Difference` against the whole cover cascade; this is an intersection restricted to 140 airport polygons. Conflating the two is what made this look blocked. Watch the SRIDs: `pl_ptkm` is EPSG:2180, `pl_kuko_a` is 3857, and `geometry_columns` reports srid 0 for both — an explicit `ST_Transform` is required. The honest caveat: PTKM∩KUKO is runways **+ taxiways + aprons fused**, not per-runway polygons. Iceland's source is already "runways plus taxiways", so this sits inside the layer contract as written; the aprons are the arguable part. ### Source survey | Source | Licence | What it gives | Verdict | |---|---|---|---| | **OurAirports** | *"All data is released to the Public Domain"* (verbatim, ourairports.com/data) | Runway thresholds, length, width, surface. **FI**: 105 open runways, 79 with both ends. **PL**: 135 open, 53 with both ends — including every large airport's main runway | **Best free option.** `ST_Buffer(centreline, width/2, 'endcap=flat')` → polygons | | **openAIP** | **CC BY-NC 4.0** (verified on openaip.net) | Runways, airspaces | Non-commercial — conflicts with our CC0/permissive preference | | **EUROCONTROL EAD** | Registered-access service | Authoritative AIXM for all of ECAC | Not an open download; only viable with an account | | **National eAIP** (PANSA `ais.pansa.pl`, Fintraffic `ais.fi`) | Per-state, needs checking | AD 2.12: THR coordinates, dimensions, surface, per runway | Authoritative and matches our national-source pattern, but it is HTML/PDF scraping on an AIRAC cycle | | **AMDB (DO-272 / ARINC 816)** | Commercial | Taxiways, aprons, stands, markings | The "spectacular" one. Paid | | OSM | ODbL | `aeroway=runway/taxiway` polygons | Excluded by the no-OSM framing | Two OurAirports caveats: `width_ft` carries *field* width on grass strips (Poznań 02/20 = 984 ft ≈ 300 m), so it needs clamping against `length_ft`; and reconstruction from one threshold + heading + length yields **zero** extra runways — every row is both-ends or nothing. For Finland's grass-strip stragglers: **EFLL, EFNS and EFTO have both thresholds + width** in OurAirports; EFMN (Mäntsälä) and EFWB (Wredeby) do not. ### Recommended order of work 1. **Poland, now, no new source**: build `airports` from `pl_ptkm ∩ pl_kuko_a`, and put the KUKO area into `cover` as `airport`. Fills the contract for the civil airports today without waiting on this issue. 2. **Then, public domain**: an OurAirports runway importer for what step 1 misses — Polish military fields, Finnish grass strips, and future countries with no national survey. This is the reusable "all airports at the same quality" mechanism the issue is really asking for, and it is CC0-clean. 3. **Only if apron/stand detail is wanted**: price an AMDB feed. Nothing free reaches that level. Suggest retitling this issue accordingly — "ARINC 424" names a format that cannot deliver the taxiways in its own description, while OurAirports plus the local PTKM∩KUKO split together cover more than it would.
Author
Owner

Marking the issue as blocked because we simply don't need it anymore.

Marking the issue as blocked because we simply don't need it anymore.
Sign in to join this conversation.
No milestone
No project
No assignees
2 participants
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
art/ismap#157
No description provided.