Find a source of ARINC 424 data for good airport geometries #157
Labels
No labels
blocked
claude-wip
map-report
map:is
map:se
needs-review
No milestone
No project
No assignees
2 participants
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
art/ismap#157
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
The
airportslayer 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:
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 noplpartition at all until a runway source lands; Warsaw Chopin renders as plain landcover.Finland — MTK's
lentokenttaalueladder 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
airportslayer 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).
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:Measured:
This is not #118's carve. #118 is a nationwide
ST_Differenceagainst 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_ptkmis EPSG:2180,pl_kuko_ais 3857, andgeometry_columnsreports srid 0 for both — an explicitST_Transformis 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
ST_Buffer(centreline, width/2, 'endcap=flat')→ polygonsais.pansa.pl, Fintrafficais.fi)aeroway=runway/taxiwaypolygonsTwo OurAirports caveats:
width_ftcarries field width on grass strips (Poznań 02/20 = 984 ft ≈ 300 m), so it needs clamping againstlength_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
airportsfrompl_ptkm ∩ pl_kuko_a, and put the KUKO area intocoverasairport. Fills the contract for the civil airports today without waiting on this issue.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.
Marking the issue as blocked because we simply don't need it anymore.