https://ais.ansp.kg/eaip/2026-06-11-AIRAC/html/eAIP/UC-AD-2.UCFB-en-GB.html#AD-2.UCFB

Why did you revert the changes?

UAFB is an outdated code. Previously, Kyrgyzstan's airports used the UA- prefix (a legacy of the Soviet bloc, shared with Kazakhstan and other Central Asian states).

UCFB is the current code. ICAO allocated Kyrgyzstan its own UC- prefix, and all Kyrgyz airports were recoded accordingly.

Other Kyrgyzstan airports changed in the same way.

I’m doing this just for fun. I’m not paid for these edits, and nobody else is involved — it’s a personal hobby project, not a company mapping programme or an organised team.

OSM airport data is often incomplete or inconsistent, so it can’t be treated as authoritative on its own. Even so, I use it in aviation chart rendering where commercial providers don’t have coverage. You can see an example on SimBrief.com — open the IFR or VFR chart layer and zoom in as far as possible on any airport; the detailed airport surface features there come from Jeppesen or OSM.

Where did I add the ref for the taxiways? Show me an example; in this particular case, the ref was not specified. If I did specify a ref somewhere, it was using the local AIP. But I almost never did that.

Ok

The runway designation can be calculated using magnetic deviation. The TWY ref is not indicated here, but most likely "A".

To produce a useful proposal, I first need to work through real edge cases. Australia is a convenient test bed for that. My intent is not to invent a parallel tagging scheme or redefine existing keys that renderers already depend on.

What I have been adding are additional geometries and tags that sit alongside the established model and should not break current rendering — for example area:aeroway=* polygons next to the usual centreline ways. Existing aeroway=runway / aeroway=taxiway ways remain the primary features.

A few practices I keep seeing (and that AMDB-style thinking highlights) are, in my view, misunderstandings rather than the OSM “standard”:

1. Runway — a runway centreline way is essential. Treating a large polygon that merges runway pavement with adjacent taxiways as aeroway=runway is not the same thing and often confuses the layout.
2. Displaced threshold / stopway — these are frequently tagged incorrectly, including by splitting the runway line into segments by surface type instead of modelling those elements properly.
3. Runway threshold nodes — these matter for operations and alignment; they are often missing or under-specified.
4. parking_position vs taxilane — a taxilane is part of the surface routing graph (a way used to move between taxiways and stands). A parking position is the stand itself: typically a node (or small area), a designated position that several taxilanes / lead-ins can connect to. It is not a marked line analogous to a taxiway. Mixing the two — e.g. tagging stand lead-ins as parking_position, or treating parking positions as linear features — confuses the graph with the stand identity. AMDB-style separation keeps graph = lines (taxiway / taxilane) and stands = points/areas (parking_position).
So the experiment is mainly about adding missing structure (polygons, thresholds, clearer separation of stopway / displaced threshold / blast pad), not ripping out the line-based scheme mappers already know.

I understand the concern about “map everything first, propose later.” I am not running an organised import of third-party geometry; this is on-the-ground / imagery-based mapping while I draft something that can be discussed properly. I will put up an Organised Editing / proposal page once the tagging pattern is stable enough to describe — trying to propose before the edge cases are clear would just produce a weak proposal.

OSM’s do-ocracy works best when experiments are visible and reversible. If particular changesets are problematic, I am happy to discuss those case by case and revert or retag where the local community prefers the previous representation.

https://skybrary.aero/articles/airport-mapping-database-amdb

Mapbox

To produce a useful proposal, I first need to work through real edge cases. Australia is a convenient test bed for that. My intent is not to invent a parallel tagging scheme or redefine existing keys that renderers already depend on.

What I have been adding are additional geometries and tags that sit alongside the established model and should not break current rendering — for example area:aeroway=* polygons next to the usual centreline ways. Existing aeroway=runway / aeroway=taxiway ways remain the primary features.

A few practices I keep seeing (and that AMDB-style thinking highlights) are, in my view, misunderstandings rather than the OSM “standard”:

1. Runway — a runway centreline way is essential. Treating a large polygon that merges runway pavement with adjacent taxiways as aeroway=runway is not the same thing and often confuses the layout.
2. Displaced threshold / stopway — these are frequently tagged incorrectly, including by splitting the runway line into segments by surface type instead of modelling those elements properly.
3. Runway threshold nodes — these matter for operations and alignment; they are often missing or under-specified.
4. parking_position vs taxilane — a taxilane is part of the surface routing graph (a way used to move between taxiways and stands). A parking position is the stand itself: typically a node (or small area), a designated position that several taxilanes / lead-ins can connect to. It is not a marked line analogous to a taxiway. Mixing the two — e.g. tagging stand lead-ins as parking_position, or treating parking positions as linear features — confuses the graph with the stand identity. AMDB-style separation keeps graph = lines (taxiway / taxilane) and stands = points/areas (parking_position).
So the experiment is mainly about adding missing structure (polygons, thresholds, clearer separation of stopway / displaced threshold / blast pad), not ripping out the line-based scheme mappers already know.

I understand the concern about “map everything first, propose later.” I am not running an organised import of third-party geometry; this is on-the-ground / imagery-based mapping while I draft something that can be discussed properly. I will put up an Organised Editing / proposal page once the tagging pattern is stable enough to describe — trying to propose before the edge cases are clear would just produce a weak proposal.

OSM’s do-ocracy works best when experiments are visible and reversible. If particular changesets are problematic, I am happy to discuss those case by case and revert or retag where the local community prefers the previous representation.

I'd like to provide some broader context about my edits, as this might help explain why I've been making these changes across multiple Australian airports.

I'm primarily focused on Australia right now because I'm running an experiment to implement a new airport mapping standard that aligns as closely as possible with the Aerodrome Mapping Database (AMDB) specification.

For those unfamiliar: AMDB is an international standard defined by ICAO (Annex 14 and Annex 15) and detailed in industry specifications like EUROCAE ED‑99C / RTCA DO‑272C. In simple terms, an AMDB is a structured digital dataset that describes the spatial layout of an aerodrome – runways, taxiways, parking stands, and other features – with geometry represented as points, lines, or polygons, plus attributes providing additional information. It's used to improve pilot situational awareness, surface navigation, and operational efficiency. https://skybrary.aero/articles/airport-mapping-database-amdb

To develop a solid proposal for updating OSM's airport mapping guidelines, I need to test all possible edge cases. Australia provides a great testing ground because of its diverse range of airports – from major international hubs to small regional airfields. My plan is to map all Australian airports following this AMDB‑inspired scheme, and then submit a formal proposal to the OSM community suggesting updates to the current mapping rules.

99% of my changes involve creating proper polygons for:

Taxiways (TWY), Runways (RWY), Displaced thresholds, Stopways, Blast pads, etc …

I'd like to provide some broader context about my edits, as this might help explain why I've been making these changes across multiple Australian airports.

I'm primarily focused on Australia right now because I'm running an experiment to implement a new airport mapping standard that aligns as closely as possible with the Aerodrome Mapping Database (AMDB) specification.

For those unfamiliar: AMDB is an international standard defined by ICAO (Annex 14 and Annex 15) and detailed in industry specifications like EUROCAE ED‑99C / RTCA DO‑272C. In simple terms, an AMDB is a structured digital dataset that describes the spatial layout of an aerodrome – runways, taxiways, parking stands, and other features – with geometry represented as points, lines, or polygons, plus attributes providing additional information. It's used to improve pilot situational awareness, surface navigation, and operational efficiency.

More info: https://www.eurocontrol.int/articles/aerodrome-mapping-database-amdb[reference:3]

To develop a solid proposal for updating OSM's airport mapping guidelines, I need to test all possible edge cases. Australia provides a great testing ground because of its diverse range of airports – from major international hubs to small regional airfields. My plan is to map all Australian airports following this AMDB‑inspired scheme, and then submit a formal proposal to the OSM community suggesting updates to the current mapping rules.

99% of my changes involve creating proper polygons for:

Taxiways (TWY), Runways (RWY), Displaced thresholds, Stopways, Blast pads, etc …exactly as the AMDB standard requires. This is about getting the geometry right – the spatial layout of these features – which is perfectly valid work when traced from permitted imagery like Mapbox.

I fully acknowledge that the TWY identifiers were a separate issue. Since I don't have clear records of the source for each specific case, I'm happy to remove all TWY ID tags from my edits. That eliminates the licensing concern entirely.

I hope this clarifies the bigger picture behind my edits. I'm genuinely trying to improve OSM's airport data in a thoughtful, standards‑aware way, and I'm more than willing to cooperate to resolve any licensing issues.

I understand the concern about the TWY identifiers. I acknowledge that I took those numbers from the Airservices Australia DAP charts, which are not licensed for OSM. I'm fully prepared to remove all those tags (ref=) from the ways I added.

However, I do not agree with reverting the entire geometry. All the geometry (the outlines of the taxiways, runways, aprons, etc.) was traced exclusively from Mapbox satellite imagery. Mapbox explicitly permits using their imagery for OSM tracing, so that geometry is perfectly legitimate under OSM's license.

Therefore, I propose a clean solution:

I will delete every TWY identifier that came from the charts.

The geometry drawn from Mapbox will remain intact, because it is based on a permitted source and is useful data.

A full revert would remove valid, license-compliant work and is unnecessary. If there are any other tags that you believe are problematic, please point them out and I'll remove those as well.

Please let me know if this compromise works for you. I'm happy to cooperate to keep OSM clean and legal.

What I'd really like to know is why we're lumping the airport itself in with all the surrounding grass and trees. The grass can simply be mowed or burned off, so what possible reason is there for including the car park and other such areas within the airport boundary—sites that have absolutely nothing to do with airport infrastructure? The latest Mapbox imagery clearly shows a physical fence demarcating the actual premises, so why concoct spurious, artificial boundaries—unless the whole point is just to give the grass a nicer highlight on the map?

This is a cargo terminal, which is explicitly marked on the new airport chart taking effect from the 9th. Refer to the Airservices Australia DAP. In the latest Mapbox imagery, all those tree-covered areas have been completely cleared, revealing the construction site for the new terminal. Let's wait for fresh satellite imagery to confirm. For now, what I have mapped aligns as closely as possible with the published airport diagram. As for "parking_position" — it is not a marked line like a taxiway, but rather a designated "position." I adhere to AMDB standards when denoting airport infrastructure elements; accordingly, a parking area is defined as a point or polygon, and never as a line.

Airservices Australia DAP + Mapbox

I do see the remains of the volcano in the relief data – the diameter is about 8 kilometres. However, I would ask you to agree that erosion has eaten away part of the western side, a village has long stood inside the caldera, and the area is now covered by forest. I must admit that in this particular case, the preservation of the feature is much better than for many other ancient volcanoes in the Carpathians.

But there are numerous similar calderas in Romania and Ukraine as well – you can also guess their shape if you look at relief maps, yet nobody tags them as volcanoes. This is simply geological history. Does it really matter whether the terrain was formed by glaciers, volcanoes, or an asteroid impact? Erosion has long since consumed everything. If you were to stand there in person, you would never guess that you are in the centre of a caldera.

I do understand that some people find this interesting, much like old riverbeds or impact sites. But for such cases, I would kindly ask that we use a different tag. My work focuses on aviation mapping, and in that context, tagging this as a volcano looks odd and creates confusion. I need to be able to distinguish actual volcanoes – those with visible vents or craters – from ancient, deeply eroded remnants. My only goal was to validate mountain peaks and volcanic features so that they align better with the elevation grid in the simulator.

So I would respectfully request that we adopt a separate tag for these geological relics, rather than using natural=volcano. That would help keep the data clear for all users.

Remember, OSM is a geographic database that reflects the current, verifiable state of features on the Earth's surface. It is not a repository for geological history or past political borders – we don't map the Tethys Ocean, the Ural or Scandinavian mountains at their Himalayan-like height from millions of years ago, or the historical borders of Czechoslovakia or Austria-Hungary. We map what exists today, on the ground, as it is visible and measurable. ;)

Regarding your new node (node/12769693915): this mountain already exists in OSM as Node: Poľana (node/26864346#map=15/48.62578/19.47687&layers=P) and is located approximately 4 km to the southeast of your point. Its correct elevation is 1,458 m, which is confirmed by terrain/elevation data.

Regarding the tags for this peak. As we've already discussed, according to OSM guidelines, the tag natural=volcano is intended for marking a visible volcanic vent (crater, volcanic plug, etc.). On satellite imagery, no crater or caldera is visible at the summit of Poľana – it's simply forest. Therefore, for this object, I propose the following tagging scheme:

natural=peak – as the main tag for the physical mountain peak.

volcano:status=extinct – to indicate it is a remnant of an extinct volcano.

volcano:type=stratovolcano – to specify the type.

This approach preserves all the scientific information while complying with OSM's verifiability rules, as it is based on a real physical object (the peak), rather than a hypothetical vent that no longer exists.

Regarding your new node – since it is neither a peak nor a visible volcanic vent, it holds no cartographic value in OSM. Therefore, it should be deleted, and all relevant information should be migrated to the existing peak Node: Poľana (26864346) with the updated tags as described above.

Thank you for your understanding and cooperation.

Your comment did make me think more deeply about how we tag ancient volcanoes in OSM, and I'd like to raise a broader question for discussion, if you're open to it.

As you pointed out, there are extinct volcanoes in Slovakia. However, many mountains in the Carpathians are also remnants of ancient volcanic activity. If we were to tag all of them as natural=volcano, we'd quickly run into a problem of definition – where do we draw the line? By that logic, we'd practically have to tag half of the Carpathians, and perhaps even the ancient Tethys Ocean as a geological feature. That seems excessive and goes against the principle of verifiability in OSM.

In this specific case, from satellite imagery, I could not see any clearly identifiable crater, caldera, or volcanic vent. The feature appears to be a heavily eroded remnant of an ancient volcano rather than a recognisable volcanic landform. OSM tagging guidelines are quite clear on this point: the tag natural=volcano should be used for an opening exposed on the earth's surface where volcanic material is emitted — i.e., a volcanic vent. The mapping instructions say to "Place [the node] as close to the centre of the main crater/caldera/vent as you can". If there is no visible crater, caldera, or vent, the tag is not appropriate.

I also checked the elevation using Copernicus DEM data about 9 months ago, as part of a broader effort to verify mountain peaks and volcanic features globally. In this case, the elevation value on the node did not match the DEM data at that location. The actual elevation at the exact point you re-created is 790–800 metres, and according to the terrain/elevation data, it's simply a slope of Mount Mičová. So I was right to delete this fake object. There is no objective reason to tag an ordinary hillside as a volcano.

Thank you for the feedback.

Regarding the changeset description — since I'm consistently mapping a limited set of airport features (runways, taxiways, aprons, hangars, etc.) following a schema close to AMDB, the descriptions naturally end up looking very similar across changesets. I usually dedicate one changeset per airport, or occasionally split it into a few if I spot something I missed later.

That said, I do find this level of administrative detail a bit tedious, for a couple of reasons:

OSMCha visually highlights exactly what was changed, so lengthy commit messages don't really add much clarity for reviewers.

Adding explicit source tags like Mapbox or Bing feels redundant, since these are the default imagery layers in most editors and don't carry any meaningful additional information.

Inventing completely unique headlines for every single commit feels like unnecessary overhead when the actual content is consistently geometry corrections for airport diagrams.

However, I do understand the importance of good documentation. If you have a specific suggestion for a clearer, more descriptive format that works well for mapping airport layouts, I'm genuinely open to it. I'd be happy to adopt your recommended template going forward.

Thanks for your time and understanding.

I don't remember. It was 9 months ago. In any case, I apologize. The elevation was probably given very incorrectly, plus there's a volcano in the middle of Slovakia. If it's some sort of mud geyser, then the question arises of how to distinguish mountain/volcanic peaks from this type of object.