Doubts with aerodrome tagging

This changeset https://www.openstreetmap.org/changeset/83993927 brings me some doubts with OSM aeroway taggging criteria.

The aerodrome:type seems to be intented to tag the importance of an aerodrome.
But in the example of this changeset, the airport is “international” because it recives aircraft from other countries, but does not recive airline flights.

The wiki page does not describe any options, concepts, or intended use, for classifying the real world terms into the terms in the OSM context.

You are spot-on. This would be an outstanding issue. As you may see in the wiki, this key is “in use” only, and debated in the discussion page. The “:type” suffix should alert you it is a bad key. There was an abandoned attempt to fix it https://wiki.openstreetmap.org/wiki/Proposed_features/Aerodrome listed below, although its (dated) content isn’t the best.

The subject of aerodrome classification is a difficult one, and has been debated more than once. It does not help that the renderer has only a single symbol, which it uses for any aerodrome. Even the Michelin paper maps of 50 years ago had different symbols for big airports, smaller airfields, and glider fields.

I have been mapping aerodromes all over Europe for several years now, and discussed with several other mappers interested in this matter. The wiki pages reflect a kind of consensus to which I have contributed, but I also respect it if I don’t really agree with it.

Two alternatives are generally accepted to aeroway=aerodrome: aeroway=heliport (self-evident usage) and also aeroway=airstrip, for aerodromes with limited facilities and or non-permanent use. This last tag will keep the renderer from showing it - yes I know we should not map for the renderer, but not everybody agrees to that. And, again, the renderer’s current implementation is not encouraging better behaviour.

Using the “aerodrome:type=” tag does not seem like a bad idea to me, it is however a dragon’s den for lack of clear definitions. And even if clear definitions could be given, and were, there will always be border cases.

NB in the above, “aerodrome” is used in the ICAO meaning of “any surface of land or water, used (exclusively or not) for the landing and take-off of aeroplanes”. It is a source of confusion that in colloquial English, “aerodrome” often indicates “a smallish airfield”. A further cause of confusion is the US’an tendency to call every aviation surface an “airport”.

Suggestions for improving/updating the wiki are very welcome.

Thanks for your replies.

Following the category declared by local authority "Categoría: Público - Internacional “3D”, i reached the ICAO (OACI in spanish) aerodrome
reference code which classifies the airports in terms of the size of aircrafts being able to operate there.
See https://es.wikipedia.org/wiki/C%C3%B3digo_de_referencia_aeroportuario (in spanish, english page is unrelated and about to the reference point)
and https://www.skybrary.aero/index.php/ICAO_Aerodrome_Reference_Code

This Airbus document refers to three diferent codes for classification of the aerodrome https://www.airbus.com/content/dam/corporate-topics/publications/backgrounders/techdata/general-information/Airbus-Commercial-Aircraft-ICAO-ARC-FAA-ADG-App-Cat.pdf

Also this ICAO document has information about aerodrome classification https://www.icao.int/MID/Documents/2017/NCLB-Aerodrome%20Certification%20Wksp-Trg/Day%202-PPT10-Continued%20Surveillance-3%20Physical%20Characteristics%20-UAE.pdf

And at least some arbitrary method we can use to render aerodromes in there different classes (like Michelin maps) is an improvement.

[[ sorry, I misread both the message and the document ]]
Both documents seem to discuss classification of runways and airliner aircraft, not the classification of aerodromes.

Most of these issues arise because someone many years ago changed all airport/airfield/airstrip tags to aerodrome and by the time it was known it was too late to restore. Attempts to introduce some sensible tag to allow importance to be worked out has equally failed because ‘international’ does not distinguish between general aviation airfields and one which carry regular international passenger traffic.

Other problems are known landing points on glaciers, lakes etc, which are not aerodromes in any meaningful sense.

I’m afraid these problems stem from failing to control a mass edit (and potentially some undiscussed imports too) and we can see the problems persist for years.

Indeed. One of the biggest outstanding issues is https://taginfo.openstreetmap.org/tags/?key=source&value=ourairports.comhttps://taginfo.openstreetmap.org/tags/?key=source&value=ourairports.com, imported in https://www.openstreetmap.org/changeset/6683367 and some others I think.

I don’t believe the DWG* have ever had an explicit complaint about it (a quick ticket search suggests not) but it’s something that everyone’s aware of that needs looking at at some point, a bit
like cleaning behind the fridge.

It’s pretty unlikely that data such as that from ourairports.com would get imported into OSM nowadays. It’s also true that much of what has that source tag has been changed beyond all recognition since the initial import, so it certainly wouldn’t make sense to “just remove everything”. Some that haven’t been changed in OSM could be dealt with by a maproulette or similar challenge, and those that there’s really no evidence of could be removed.

All of this of course “just needs someone to organise it” :slight_smile:

Regards,

Andy

  • for those unaware, I’m a member of OSM’s Data Working Group

While I too regret the bulk import from ourairports, I wouldn’t point it out as a prime source for the kind of problem we are discussing here. ourairports has a certain degree of classification, but that has not been applied in the import; perhaps it didn’t exist at the time. It is most annoying that the import calls each and every aerodrome an “airport”; only a few days ago I corrected a couple of mountain fields in France (“Altisurface”) that ourairports had injected as “airports”. Those US’ans tend to call every aerodrome an “airport”, more’s the pity.

We should not wish for a mass reversal of the import, even if it were feasible: on the one hand the import added a fair amount of good information, too; we don’t want to remove that only because it was added in an operation “less than perfect”. On the other hand, a large part of the errors have since been manually corrected. At least in Europe, I think we now have a quite acceptable set of aviation terrains mapped, of fairly good quality. Though of course, like all of openstreetmap, the data will never be complete and up to date, since the real world situation is changing all the while.

FWIW: I have made it my quest to harmonise information between various sources of aerodrome information; those sources include both OSM and ourairports, plus a few more. I regularly download OSM aerodrome data through overpass, to this purpose, and run scripts to compare the data with that from elsewhere. Upon finding discrepancies, I will investigate the local situation - not always easy, fom a distance, and never conclusive - and update the various sources accordingly.

Issues that remain, imho, in openstreetmap mapping of aerodromes:

  • lack of a classification system. If once there were defined classes, it shouldn’t be too hard to classify some fields - for example the “campi di volo” in Italy, which by law only accept ultralights. But as said, it has been discussed, it has been tried, but nothing has ever come of it.
  • the indiscriminate use of a single symbol for all kind of aerodromes by the renderer discourages mappers from differentiating. At the very least, the renderer should honour the “aeroway=airstrip” tag, there are some 700 now, in Europe alone.
  • sometimes, “aerodromes” are mapped that shouldn’t; often this is about model flying terrains. The wiki being clear about this matter, correction is easy, and usually accepted.
  • even more rarely, local mappers will refuse to have an aerodrome mapped, and I have occasionally met with some stubbornness here, especially from Scandinavia. It doesn’t help that the DWG seems to prefer supporting local mappers even if they got things blatantly wrong.