Talk:Tag:aeroway=aerodrome

From OpenStreetMap Wiki
Jump to navigation Jump to search

only for nodes?

Is there any reason why this tag should be used just for nodes instead the complete airport area? --Etric Celine 01:17, 7 January 2008 (UTC)

In my opinion it should be allowed for areas too. Especially because airports are usually large. The text seems to contradict the ValueDescription-Template in this aspect. --MRQ 18:10, 12 July 2008 (UTC)

I think there are reasons as long as it's rendered from a high "zoom out level".
  • In mapnik it's rendered as a symbol at zoom level 10.
  • in tiles@home it's rendered as a symbol at zoom level 13
-- Logictheo 14:36, 6 April 2009 (UTC)
re-opening this very old discussion: I regularly see aerodromes getting mapped as both a way and a node. I find this very dangerous because both entries can carry the same info (icao code, iata, operator, contact, ...) then when the info changes one may get updated, the other not. So we should avoid this double mapping and the best way seems to introduce a rule that aeroway=aerodrome (and heliport, and perhaps more others) should only be assigned to nodes - or only to ways. I don't much care which of the two, but a French mapper recently told me the total surface may be relevant to hikers, cyclists and others; there fore a "way" should be preferred over a node. Opinions? Jan olieslagers (talk) 20:31, 20 November 2017 (UTC)
@Jan olieslagers: answering an old request for comments ;-). There is no need for replication, you could have a relation holding all the common information, having the node as label member and the shape as outer member(s). It would be similar to a boundary relation like here. Note that currently some duplication are needed for a proper usage for the tools (here Nominatim and default renderer). It avoids duplication of the data displayed on the map, you can compute the area and display the text at a not too "crowdy" location. And the tools could check or propagate the modifications. --Nospam2005 (talk) 21:32, 26 January 2022 (UTC)
Talking of an old discussion... but it does remain actual. I see no need at all to have a node describing the aerodrome, least of all your point of "display the text at a not too crowdy location" - that is pure mapping for the renderer. I am considering a proposal to map all aviation terrains as a relation, with as members at least one area of land (or water) and at least one runway or helipad. Tags like icao, iata, operator, and various names could go in the relation entry itself. But I want to have it ripe before publishing it, and I cannot spare the time right now. Jan olieslagers (talk) 10:49, 27 January 2022 (UTC)
least of all your point of "display the text at a not too crowdy location" - that is pure mapping for the renderer as you may guess I said that on purpose ;-). It is NOT tagging for the renderer, it's giving hints for the renderer, which is a completely different issue (we don't misuse a tag to have the "wanted" rendering).
To trigger changes to the renderer, hints will not be sufficient, not by a long way... I have long given up any hope in that corner. The renderer renders aviation terrains with less nuance and accuracy than did the paper maps by Michelin of 50 years ago, it is a sad truth but I see no solution to it. The only reason for keeping aeronautical information complete and accurate in our database is the use thereof by other applications. Jan olieslagers (talk) 21:46, 28 January 2022 (UTC)
But the reason for aerodromes is that aerodromes have a officially published location, the reference point, it's "centre", see AIP portals or OpenAIP, for instance JFK. Of course you may could map the reference point as a separated object, but it's the really position of the airport seen as node. --Nospam2005 (talk) 21:34, 28 January 2022 (UTC)
Only the fewest of aerodromes are in the AIP - in UK, for an extreme example, there are several hundred "farm airstrips" that are not officially listed anywhere. And of course they come and go, keeping a few people well occupied, myself included. France, Germany, Italy, Poland, Spain, Romania, all the bigger countries in Europe have far more fields NOT in the AIP than fields IN it. And if not in the AIP then there is no question of an ARP. One more reason for not including the ARP in our database, by the way. Jan olieslagers (talk) 21:46, 28 January 2022 (UTC)
If that's a good argument, you should suggest the removal of iata and icao codes... --Nospam2005 (talk) 15:18, 30 January 2022 (UTC)--Nospam2005 (talk) 15:18, 30 January 2022 (UTC)

Boundary Ways

I would like to tag an airport with an area, however, there are a number of different ways defining the perimeter in this case - some barrier=fence, some building=hangar, and some are ways of an administrative boundary too. It's therefore not possible to use the existing ways to form a closed node to share the aeroway=aerodrome property. The solution seems to be using a multipolygon relation to gather the boundary sections using role "outer" then apply the aeroway tags to the relation. For buildings that form part of the solid boundary I have created an additional barrier=wall way for their outer edges, as closed ways can't be included as part of multipolygons. --Pink Duck 11:39, 26th March 2010 (UTC)

I have been spending some time looking at how people are modeling airports and haven't been comfortable with how boundaries are defined either. Personally I prefer to use 'aeroway=aerodrome' as a node so that I can position it where I wish it to appear, probably near to, or on the main terminal building. The boundary seems to be a separate entity, indeed I think there are multiple boundaries, including 'airside', 'main airport facilities', 'airport include all related parking, transport interchanges and services etc. Sometimes a boundary can be a simple way, but other times it will indeed be better as a multi-polygon as you suggest. I have also been looking at how one might use a 'site' relation to pull all the elements of an airport into a single container. Possibly the boundary could form part of that over-arching relation. Can I suggest that we discuss this further on the talk:Airports page? PeterIto 22:13, 14 December 2011 (UTC)

The type=* tag

The current documentation of the type=* conflicts with the actual tagging of multipolygons.

So instead of type=public, you should use aerodrome:type=public. Other documented values include aerodrome:type=military, aerodrome:type=private.

But may be we could use access=* ? — Verdy_p (talk) 03:05, 6 April 2013 (UTC)

Currently there is a proposal to use the key aerodrome=*. --Jgpacker (talk) 11:00, 13 November 2014 (UTC)

Type does not describe what is being tagged! Use a word that describes what you want to tag e.g. aerodrome:use=international/domestic/military aerodrome:prominence=large/medium/small Warin61 (talk) 21:43, 16 October 2017 (UTC)

aerodrome=* tag

There is a need for describing how important is the airport. It seems already some people have been following the idea of using the aerodrome=* tag: [1]. It should be documented. Pieleric (talk) 08:50, 10 May 2013 (UTC)

Now there is a proposal for that: Proposed features/Aerodrome --Jgpacker (talk) 10:58, 13 November 2014 (UTC)

Inconsistent documentation

There is an inconsistency between the "How to map" section, allowing relations (edited on 23:24 14 dic 2011‎), and the ValueDescription template, allowing only nodes and areas. Muralito 10:17, 13 November 2014 (UTC)

Not really because a multipolygon relation counts as a complex area, but I can see how it can be confusing. --Jgpacker (talk) 10:56, 13 November 2014 (UTC)

What distinguishes an Aerodrome from other types of aeroways?

This article should clearly define an aerodrome explain what distinguishes an aerodrome from other types of aeroways. My English dictionary says:

aerodrome
a small airport.
airport
a landing and take-off area for civil aircraft, with facilities for aircraft maintenance and passenger arrival and departure.

However, my civil aviation authority considers all airports to be aerodromes and provides a list of aerodrome co-ordinates for around 200 places, including both civilian and military airports, aeroclub/glider airfields and heliports at hospitals and a few other places. All these places have an ICAO 4 letter airport location code. A few of these aerodromes are certificated to Part 139 of the CAA rules. All of these certificated aerodromes are international or domestic airports that airlines fly passenger aircraft to.

The above-mentioned list of aerodromes does not include disused military or civilian airfields, nor does it contain any of about 3500 airstrips dotted around New Zealand that are basically farm paddocks where light agricultural and similar aircraft can land and take off from. Because of this, the aeroway=aerodrome tag should explain what distinguishes an aerodrome from any other airfield or airstrip, and perhaps mention what aeroway=* tag should be used. - Huttite (talk) 22:22, 30 January 2017 (UTC)

That's a confusing one, because "aerodrome" has a formal meaning and at least one informal meaning, perhaps several. Formally, that is to say in the vocabulary of that most venerable institution the ICAO, an aerodrome is (more or less) "any surface of land or water, intended, exclusively or not, for the operation of aeroplanes" - so basically, any aviation terrain, including seaplane bases, glider fields, heliports, and what not. Informally, in certain variants of English, "aerodrome" indicates indeed a smallish airfield, though less small than an "airstrip". On the other hand, even the US-dominated Wikipedia agrees that the term "airport" should only be applied to those aerodromes with extended facilities for commercial operations, mostly passenger flights but cargo airports are also existant. Jan olieslagers (talk) 20:12, 27 January 2022 (UTC)

How to map an Aerodrome licensed as a spaceport ?

For aeroway=spaceport there's a tag.
However, there are Aerodromes licensed as a spaceport, see
Active Launch Site Operator Licenses [2]
which don't have "special" spaceport infrastructure such as an aeroway=launchpad
An example currently in the media is Stratolaunch [3]
In this example, the Mojave Air and Space Port [4] is affected.
As there's (IMHO) no part of the Aerodrome dedicated to space launch, how would you tag this ?
aeroway:spaceport=yes ? rtfm Rtfm (talk) 13:12, 5 June 2017 (UTC)

Other tags, generic

When creating an aerodrome as a node, the tag "local_ref" is suggested by potlatch. I have taken this for an indication that it is meant to be a typical tag for aerodromes, even if Potlatch does not behave so when creating an aerodrome as a way. I have used the "local_ref" tag especially in France, where pseudo-icao codes of the form LFddxy are maintained by the FFPLUM and can be consulted and downloaded from their website; the dd standing for the "département" and the xy being a free counter. To a lesser extent I have used the same tag in Italy, for the codes from www.ulm.it, and in Czechia and Slovakia, for those used by aerbaze.cz Jan olieslagers (talk) 09:36, 8 June 2017 (UTC)

In order to avoid the use of "local_ref" tag where this doesn't correspond to the description https://wiki.openstreetmap.org/wiki/Key:local_ref (local reference / reference at local level) and discussion in the comments https://www.openstreetmap.org/changeset/155364333:
My proposal is to transfer official latinized codes to the another tag, "aftn" (Aeronautical Fixed Telecommunications Network https://en.wikipedia.org/wiki/Aeronautical_Fixed_Telecommunication_Network because this code is used primarily for this network and for the general identification), and add information about this to wiki https://wiki.openstreetmap.org/wiki/Key:ref + https://wiki.openstreetmap.org/wiki/Tag:aeroway%3Daerodrome. At the moment, I'm observing the use of "aftn" tag only in Croatia near Pula. The use of "aftn" tag for latinized version will not be limited to the territories of the former USSR. The use of the AFTN in cyrillic version as "nat_ref" tag also corresponds to the description on wiki https://wiki.openstreetmap.org/wiki/Key:nat_ref, since this option is used at the national level. I remind you that I am talking exclusively about official identifiers that are appointed state structures of the USSR, the Russian Federation and other states of the former USSR. For amateur identifiers, such as from the site aopa.ru, which aren't included in the official lists and aren't indicated on official aerodromes schemes (AIP, Aeronautical Information Publication), I already proposed using the corresponding tags like "ref:aopa:ru" & "ref:aopa:en" (as almost a monopoly source of amateurs identifiers at the former USSR). However, if we come to an agreement to use the "aftn" tag, then latinized identifiers beginning with U*** but not assigned as an ICAO code should be moved from "ref:aopa:en" to "aftn", since they are also used in AFTN. It should be noted that the AFTN code, when it contains more than 4 characters, may be used by aerodrome units/departments or aerodrome services. Best Regards, Mazda05 --Mazda05 (talk) 13:11, 18 August 2024 (UTC)
As for the aerodromes in France, Italy, Czech Republic, Slovakia that you previously mentioned, and others — if these codes are used in AFTN, then, I believe, you can extend the "aftn" tag at these references --Mazda05 (talk) 13:36, 18 August 2024 (UTC)
It is good to think about ways to improve our database. That said, using the AFTN address does not look like a good idea to me: AFTN is a communications system, it has no purpose of identification or cataloguing. If we ever begin adding this info, it should be with a tag contact:aftn=XXXXABCD. But I see little if any added value, since the XXXX correspond to the ICAO code, so we would not really be adding new information. Our servers are too expensive for that! But, as I stated elsewhere, the vast majority of aviation terrains do not have an ICAO code, thus no AFTN either. Jan olieslagers (talk) 15:50, 18 August 2024 (UTC)
From your point of view, the Cyrillic alfabet must be a thorny matter. In no case should we associate the Latin alfabet with English, nor the Cyrillic with Russian! Both are used by several more languages. Jan olieslagers (talk) 15:50, 18 August 2024 (UTC)
Using exactly the “aftn” tag is not necessary. We can use “ref:aftn” or basically move away from defining AFTN and linking to it. In order to avoid duplication of information and database sprawl, for “aftn” or “ref:aftn” or some other tag in the description on the wiki we can make it very clear that it is not worth duplicating the ICAO code in “aftn” if they are identical, because as far as I know they are identical for those aerodromes to which the ICAO code is assigned. Regarding "contact:aftn" and the topic of communication: in the former USSR countries the codification of aerodromes was, and currently is, taking into account AFTN — as far as I understand, these are the same pseudo-ICAO codes (at least part of them) that you described earlier on wiki. That's why I suggest to concentrate on AFTN — if you have another ideas about marking, feel free to express them. I don't see any problems with “contact:aftn”, in the description of the new tag on wiki we can clearly indicate that this tag is 4-character and is the first half of the AFTN code for departments, services, units of the aerodrome. In order to understand whether this does not apply to ICAO codes of airfields in France, Italy, Czech Republic, Slovakia and in other countries — we need detailed information, namely documents related to these airfields. If you provide the sources of these documents, I could study them and suggest other options if the codes under discussion are not conceptually related. However, at the moment, nothing else comes to my mind but to associate these identifiers with the AFTN linkage, since they act as a generic designation and in the main part in the AFTN code. What is unambiguous, however, is that they are not local identifiers.
Yes, quite right, Cyrillic is not necessarily Russian, and Latin is not necessarily English. I did not suggest aftn:ru / aftn:en. --Mazda05 (talk) 17:07, 18 August 2024 (UTC)
If we move away from AFTN, and do not link ref with anything else, it is possible to mark Cyrillic names where Cyrillic is the basic alphabet as "nat_ref" Latinized variant codes as "nat_ref:Latn" or "nat_ref:en", where Latin is the basic alphabet, mark them as "nat_ref", and if there are Cyrillic variants of these aerodrome codes, mark them as "nat_ref:Cyrl" or "nat_ref:<lang>", where <lang> is the local official language or Cyrillic-based script. However, the problem is that "name:Latn" and "name:Cyrl" are not currently in use. Same with "ref:aopa:*" --Mazda05 (talk) 20:03, 18 August 2024 (UTC)
@Mazda05, you have perhaps not suggested aftn:ru or aftn:en but you did introduce, without any discussion or consensus, the tag ref:aopa:en. To say the least, in politeness, you have not always been very consequent with your own words or principles. I am glad to see you now entering the path of discussion. Jan olieslagers (talk) 21:12, 18 August 2024 (UTC)
  1. I feel mixed about contact:*=* . This may be better than ref:*=* when it can specify the communication purpose. But I'm unsure about adding specialized professional/industrial systems in contact:*=* , which is currently for general purpose and consumers.
  2. Does AMHS, and CIDIN use the same AFTN location code? If yes, *:aftn=* shouldn't be used. Eg *:afs=* to be cover them all .
  3. *_ref:*=* should be avoided if you can think of a specific ref:*=* system as in ref:aftn=* . *_ref=* is generic, so *_ref:*=* is best reserved for languages only.
  4. *:*-Cyrl=* language is required by the international standard. But you can use the local one, eg *:mn-Cyrl=* , *:kk-Cyrl=* , and *:uz-Cyrl=* are the ≥1k instances. If you still don't want that, it might be *:mul-Cyrl=* "multiple languages" , or *:und-Cyrl=* "undetermined".

—— Kovposch (talk) 08:35, 19 August 2024 (UTC)
It's called an "AFTN station". It could be considered a station identifier. But besides contact:*=* (see my other reply) and ref:*=* , there is also callsign=* in radio. Using something specific may be justified.
—— Kovposch (talk) 08:37, 19 August 2024 (UTC)
@Jan olieslagers, As for "ref:aopa:*" — there really is no discussion, since these are unofficial references, and from the site of aviation amateurs. In addition, there was no question of the description on wiki "ref:aopa:*" until yesterday, because "ref:aopa:*" was considered a temporary tag for separating official references from amateur references. But as @Kovposch noted, Latn and Cyrl is recommended to use with the language code. Given this, I temporarily indicated :ru and :en. Now it's time to discuss this issue
@Kovposch It is not entirely clear what most of your messages relate to. I ask you to see the changes and comments in the https://www.openstreetmap.org/changeset/155364333 to understand the essence of the issue. Best Regards, Mazda05 --Mazda05 (talk) 11:26, 19 August 2024 (UTC)
@Kovposch As far as I know, AMHS uses the same code (four-symbol) for communication. I have no information about the use of these codes in CIDIN. However, as I understand it, @Jan olieslagers is opposed to the identification of aerodromes by communication systems --Mazda05 (talk) 11:34, 19 August 2024 (UTC)
As for references from the aviation enthusiasts/amateurs site (aopa.ru), as well as lists from aopa.ru and lists generated from data from this site, in order to move away from binding to Russian and English, use "ref:aopa" tag for unofficial amateurs references in Cyrillic ("ref:aopa:ru" → "ref:aopa"), and "ref:aopa:la" (":la" — Latin ISO 639) for identifiers in Latin ("ref:aopa:en" → "ref:aopa:la"). If approved, add information about this on the wiki https://wiki.openstreetmap.org/wiki/Tag:aeroway%3Daerodrome & adding information about this tag — that their values should not duplicate the ICAO code or national official codes and should only be used if the ICAO and national codes are not specified and not assigned to the aerodrome. As for national official references (codes), I don't have any new proposals yet. --Mazda05 (talk) 15:43, 20 August 2024 (UTC)
You are confusing language with the alphabet. *:la=* is the historic Latin language. *:*-Latn=* is the Latin alphabet, which may be used in any language.
—— Kovposch (talk) 07:52, 21 August 2024 (UTC)
It's possible. What kind of tag you are proposing? We need the Latin alphabet without being language specific. The tag with * is invalid... --Mazda05 (talk) 15:54, 24 August 2024 (UTC)
Sounds good, thank you! Only we should not use generic "aopa" because AOPA is a worldwide organisation, but you correctly state that these codes are maintained by the Russian division. So I would suggest ref:aopa_ru or some such. Jan olieslagers (talk) 17:46, 20 August 2024 (UTC)
Yes, you are right, it is a public organization with the name AOPA within one state and it is not quite correct to refer it to other organizations with the name AOPA. Their short name is AOPA-Russia and RAOPA, so yes, "ref:aopa_ru" or "ref:raopa" would look more correct. --Mazda05 (talk) 21:01, 20 August 2024 (UTC)
In this direction, you can use ref:aopa:RU=* country suffix. The order ref:RU:*=* would be used for a system in Russia only. ref:*:RU=* could be used for the Russia part of an international system. Key:ref#Extensions
—— Kovposch (talk) 07:55, 21 August 2024 (UTC)
Yes, that's also a possible option. Thank you --Mazda05 (talk) 15:57, 24 August 2024 (UTC)
About the alfabet used, I am quite unsure. It would seem to me the Latin is the "native" alfabet of OSM, :la would be the default extension and thus optional; whereas Cyrilic must of course be respected and valued, but still remains an exception, if looking globally. Above all, we should keep to the same practices and standards as elsewhere on OSM. But where are they documented? Jan olieslagers (talk) 17:46, 20 August 2024 (UTC)
I don't understand your message. The text itself is clear, the meaning of the message is not clear. Please explain it in detail. You can also write in Portuguese or Dutch. Thank you --Mazda05 (talk) 21:04, 20 August 2024 (UTC)
I took my time to reply, and not without reason.
On an introductionary note: dear @Mazda05, I see not a single reason to distinguish between official and not-official sources. I do agree that official sources are more relevant for most applications, but we should leave it to the users of our data to decide that. IMHO.
Allow me the liberty to propose a scheme of three fields, the third probably optional. The first field would always be "ref". The second would indicate the source, which could be "icao" or "aopa_ru" or "basulm" or many more others. The third would indicate the character set. As I stated before, this field could be optional: if not given, the character set would default to "latin", as is the case for 99,99% of OSM data.
Some examples:
  • London Heathrow Airport

ref:icao=EGLH ref:iata=LHR

  • Moskva Sheremetyevo

ref:iata=SVO ref:icao=UUEE ref:nat_civ:Cyrl=УУЕЕ

  • Тверь / Мигалово

ref:nat_civ:Cyrl=УУЕМ ref:nat_mil:Cyrl=ЬУЕМ ref:icao=UUEM

  • Плавск

name=Плавск name:ru=Плавск name:en=Plavsk ref:aopa_ru=ZAD0 ref:aopa_ru:Cyrl=ЗАД0

The disadvantage of this idea is that the second field needs to be relative to an organised and managed list, so that someone would need to keep an eye on it. Thanks for sharing your thoughts!

Jan olieslagers (talk) 22:23, 24 August 2024 (UTC)

Thank you for finding the time to answer.
1. I am strongly against to use the "ref:icao" & "ref:iata" or similar for ICAO & IATA codes, because on them: firstly, there is proposal in Approved status https://wiki.openstreetmap.org/wiki/Proposal:Iata_and_Icao; secondly, there is a developed scheme and norm of marking; thirdly, in order to change this scheme it is necessary to bring it to new Proposal process, where obviously no one will support it, as it does not make sense to transfer "icao" > "ref:icao" & "iata" > "ref:iata".
2. About the issue of references that are assigned by authorized persons (official references) and amateur references: I don't think we should mix them up and not distinguish between them. For what reason you think they should not be distinguished is unclear. Official references are in any case basic and can be regarded as national & international. Amateur references cannot be considered as such, because there is an authorized organization that assigns references of this rank (national & international). Amateur references are not fixed by any documents and are not stable, i.e. conditionally every minute the administrator of the amateur site can change this or that airfield code. Besides, for example, such an amateur organization as AOPA Russia may cease to exist tomorrow. For this reason, in my opinion, those who want to tag amateur resource references can use the reference tag (in accordance with https://wiki.openstreetmap.org/wiki/Any_tags_you_like), but it should not overlap/mix with the tag used to tag of official references.
3. About «the character set would default to "latin", as is the case for 99,99% of OSM data.»: The main references in Russia are Cyrillic references (see Сборник четырехбуквенных указателей (индексов) местоположения аэродромов, полигонов и посадочных площадок http://www.caiga.ru/DocAni/manual_of_4_letter_indexes/Indexes_of_Airports.pdf). It would be inappropriate to use additional tag fields for main references, and to use tags without additional fields for Latin variants, which are formed on the basis of main references (which is explicitly stated in official documents, for example in Руководство по авиационной электросвязи 01.09.1999 by Federal Air Transport Service of Russia). Good practice has established that https://wiki.openstreetmap.org/wiki/Ground_truth : «The sources cited as official evidence (of a specific Map Feature) are also subject to OSM Community acceptance.».
4. As for the separation of the civil and military official references by different tags — I am not against this, but we can not reduce to "_civ" / "_mil", but to record completely "_civil" / "_military". This can be discussed when there will be a consensus on basic issues.
I would still like to come to a reasonable consensus. Best Regards --Mazda05 (talk) 03:39, 25 August 2024 (UTC)
If the decision is made not to use AFTN, my suggestion is this:
  • official national civil refs: "nat_ref:civil" or "nat_ref:civ" or "nat_ref";
  • official national civil refs in Latin (if official ref in another alphabet/script) refs — "nat_ref:civil:la" or "nat_ref:civ:la" or "nat_ref:la";
  • official national military refs — "nat_ref:military" or "nat_ref:mil" or "nat_ref";
  • official national military refs in Latin (if official ref is in another alphabet/script) refs — "nat_ref:military:la" or "nat_ref:mil:la" or "nat_ref:la";
  • amateur refs — "ref:<name>";
  • amateur refs in Latin (if the amateur ref is in another alphabet/script) — "ref:<name>:la",
in case of AOPA Russia, I suggest <name> = "aopa_ru" or "raopa" or "aopa:RU".
The proposal also includes mandatory information in the description of tags on the wiki: not to duplicate the ICAO code in any official or amateur refs if they are identical to ICAO code.
Regarding Latin: I haven't found any use of ":Latn" or ":Cyrl" without being language-specific, either by "name" tag, "ref", or whatever. Based on the description of "name:la" at wiki — I don't see any problem to use the ":la" code for the Latinized version of the reference.
If you are willing to consider linking to AFTN or other systems, or provide documents for other countries - please let me know.
If you agree with this scheme in general - let me know, then we will discuss details and options for writing tags. --Mazda05 (talk) 05:59, 25 August 2024 (UTC)

—— Kovposch (talk) 06:28, 25 August 2024 (UTC)
«nat_ref:civ*=* : As I said, if you have another suffix, it's best to avoid using *_ref=*» Why?
«nat_ref:military=* / nat_ref:mil=* : How about military:ref=* considering there's already military=* ?» You can do that, but then how do you indicate that it is a national identifier? military:ref — It is not clear from the name of the tag that it is a national-level identifier.
«*:la=* : Key:name:la already mentions it's for "historic Latin names", not any romanized text. name:*-Latn=* is widely used in Multilingual names by different counties.» You are absolutely right that "name:la" is for names in historical Latin. We are not talking about "name:la", but "ref:***:la" & "nat_ref:la". The problem with "ref:*-Latn" is that there is no language-specific to which you can bind the value of the tag. And "ref:Latn" and other ":Latn" are not currently used or described on the wiki. To introduce such notions on wiki as ":Latn" — need to discuss it in other sections and topics. I don't see the need for this, as we are not using names, but identifiers (refs). --Mazda05 (talk) 06:44, 25 August 2024 (UTC)
However, if you are alluding to "ref:ru-Latn" as a romanization, it cannot be used. Let me explain. Spassk-Dalny Airfield identifier it's “УХВД”. The ru-Latn/romanized variant is “UKhVD” or “UHVD”. However, its Latin identifier is “UHWD”. The identifier for Ust-Omchug Airfield it's “УХМЖ”. The ru-Latn variant is “UKhMZh” or “UHMZh”. However, its Latin identifier is “UHMV”. Therefore, using language-specific "ref:*-Latn" is not correct in this case --Mazda05 (talk) 07:05, 25 August 2024 (UTC)

—— Kovposch (talk) 10:33, 23 September 2024 (UTC)
«nat_ref=* can be understood as civilian» Why? Proposed «nat_ref:civil» — it's about national civilian reference... https://wiki.openstreetmap.org/w/index.php?title=Key:nat_ref «National reference ("Nationally referenced as...").». I don't see any problems in using the subtag «nat_ref:civil» of widespread already acting tag «nat_ref», instead of generating the new tag «civ_ref» or similar. What is the reason to do as you described?
«The format is either *_ref=* , or ref:*=*» Why? Where is it defined or approved?
«There's no need to complicate it with civ_nat_ref=* .» I didn't suggest the «civ_nat_ref». I suggest the «nat_ref:civil»
«military:ref=* : Military is already clear as national. If anything, you can still use military:nat_ref=* .» https://taginfo.openstreetmap.org/search?q=military%3Anat_ref#keys No items. What is the reason you suggest doing a reference subtag for the military tag (military:nat_ref) rather than doing a military subtag for the nat_ref tag (nat_ref:military)? It's about the reference first and foremost. And military is a type of reference. ref > military, so «nat_ref:military» is suggested (since we are talking about a national reference)
I don't see a problem with «*:la» in the description on wiki, including historical Latin, because the conversion of the reference is done in it, in historical Latin. However, I am not against using «*:und-Latn» or «*:mul-Latn» (based on their descriptions in ISO 639-3). If through this we reach a consensus on the main issue - then we need to decide which option to use.

—— Mazda05 (talk) 13:00, 23 September 2024 (UTC)
Can you please look at how others are done in Key:ref first? I don't understand why you use 0 instance as the counterarguement when none of your suggestions have any uses either. Ignoring the 2 military:ref=* , and railway:ref=* , heritage:ref=* is standard. There are also some emergency:ref=* .
—— Kovposch (talk) 12:44, 24 September 2024 (UTC)
First, we are not just talking about references (ref), but national level references (nat_ref). Second, I'm not ignoring railway:ref, but we're discussing aerodrome references, not railroad references. Third, it is recommended to use heritage=* + ref=* https://wiki.openstreetmap.org/wiki/Key:heritage#Case:_a_single_object_e.g._a_building_is_under_protection rather than heritage:ref=* for heritage. Fourth, I observe a possible extension (subtag) for ref - https://wiki.openstreetmap.org/wiki/Key:ref#Extensions + https://wiki.openstreetmap.org/wiki/Key:ref#Special_uses. As for military:ref and emergency:ref — I don't see descriptions on wiki for them. Why I am in favor of the subtag for ref and not for military - I wrote above, because it is not an internal identifier of a military object, but an identifier for a military object assigned at the national level. It's not a «use 0 instance as the counterarguement when none of your suggestions have any uses either» --Mazda05 (talk) 14:20, 24 September 2024 (UTC)
Can you please don't cherrypick and mix things up? Where is it said you should use nat_ref:*=* ? They are all ref:*=* , or *_ref=* .
—— Kovposch (talk) 09:16, 25 September 2024 (UTC)
«Where is it said you should use nat_ref:*=* ? They are all ref:*=* , or *_ref=*» I did not say this and didn't mean. Please, specify your question --Mazda05 (talk) 20:20, 25 September 2024 (UTC)
The question is on the format you are using. nat_ref:military=* doesn't fit into other prevailing formats in use. So you should not use it.
military:nat_ref=* would be fine. But I don't see any need over military:ref=* .
railway:ref=* in fact has its own problems. The "internal identifier" meaning is made-up. military:ref=* would simply mean a ref=* in the context of military=* , ie what ref=* the military=* feature has.. Indeed, a military internal identifier would likely be military_ref=* , similar to highway_authority_ref=* .
—— Kovposch (talk) 20:04, 26 September 2024 (UTC)
Is there any argument in favor of that? I already gave you a link to the formation of subtags for ref:* (https://wiki.openstreetmap.org/wiki/Key:ref#Extensions + https://wiki.openstreetmap.org/wiki/Key:ref#Special_uses), what makes you think that's not the case? --Mazda05 (talk) 21:08, 26 September 2024 (UTC)
That's ref:*=* only. Where do you see nat_ref:*=* being recommended?
In Key:ref#Authority_control below, it's already stated as either *_ref=* or ref:*=* . Not *_ref:*=* .
—— Kovposch (talk) 07:11, 27 September 2024 (UTC)
I didn't write that something like this was recommended anywhere. I was proposing a variant, which is consistent with subtag formation schemes, as evidenced by https://taginfo.openstreetmap.org/search?q=nat_ref#keys & https://wiki.openstreetmap.org/wiki/Key:ref#Extensions.
You did essentially the same thing, as there are no recommendations to do exactly as you described on the wiki. However, I explained to you why it is preferable to use "ref" & "nat_ref" as the main tag, because it is not an internal military identifier, but an identifier assigned at the national level for an object, including military. At the same time there is no mention of “military” in the documents, officially it is veiled as an airfield of state and experimental aviation. However, this is applicable exclusively about one state that was discussed, so, in my opinion, it is necessary to identify objects by essence, and not exclusively formally by documents of one or another state.
Given that you and I are unable to come to a consensus, and that the other member (Jan olieslagers) with whom I originally had a discussion about marking up these identifiers has announced his withdrawal from the discussion, meaning that we can't even get to a 2vs1 vote, I will create a thread on the forum to discuss this issue and to try to get more people involved to form a solution by voting on the forum. If this vote is not overwhelming for either side, we will have to resort to the https://wiki.openstreetmap.org/wiki/Proposal_process. Given that you have proposed a really reasonable option of using “*:mul-Latn” / “*:und-Latn” instead of “*:la”, I invite you to participate in further discussion on the forum. I will inform you additionally about the creation of such a discussion. Best Regards --Mazda05 (talk) 23:16, 29 September 2024 (UTC)

«Does AMHS, and CIDIN use the same AFTN location code? If yes, *:aftn=* shouldn't be used. Eg *:afs=* to be cover them all .» I have researched this issue. CIDIN is an extended version of AFTN and yes, this communication system also uses these same codes/refs. However, it is my understanding that it is best to avoid using communication systems such as AFTN, CIDIN, AMHS and others as tag names for consensus.

I suggest that for the time being we publish the markup scheme by editing the wiki articles and adding information about the new subtags without applying the https://wiki.openstreetmap.org/wiki/Proposal_process, and indicate the status of these tags as «in use». If other members of the community feel it is necessary to use a https://wiki.openstreetmap.org/wiki/Proposal_process to approve these subtags, then follow that https://wiki.openstreetmap.org/wiki/Proposal_process.

In terms of options, based on the other tags, I propose that:

  • official national civil refs — "nat_ref". If there is also a military ref, then both values should be specified in nat_ref with «;», and the civilian ref recommend also be duplicated in "nat_ref:civil";
  • official national civil refs in Latin (if official ref in another alphabet/script) refs — "nat_ref:la". If there is also a military ref, then both values should be specified in nat_ref:la with «;», and the civilian ref recommend also be duplicated in "nat_ref:civil:la";
  • official national military refs — "nat_ref". If there is also a civilian ref, then both values should be specified in nat_ref with «;», and the military ref recommend also be duplicated in "nat_ref:military";
  • official national military refs in Latin (if official ref is in another alphabet/script) refs — "nat_ref:la". If there is also a civilian ref, then both values should be specified in nat_ref:la with «;», and the military ref recommend also be duplicated in "nat_ref:military:la";
  • amateur refs — "ref:<name>";
  • amateur refs in Latin (if the amateur ref is in another alphabet/script) — "ref:<name>:la",

in case of AOPA Russia, I suggest <name> = "aopa_ru" (since AOPA Russia amateur refs are assigned not only within the Russian Federation, I ultimately propose not to use the country-binding subtag «:RU» and «raopa» would be an obscure acronym for the general public).

The proposal also includes mandatory information in the description of tags on the wiki: not to duplicate the ICAO code in any official or amateur refs if they are identical to ICAO code.

If you agree with this scheme in general - let me know, then we will discuss details and options for writing tags. --Mazda05 (talk) 15:10, 21 September 2024 (UTC)

I am afraid I disagree at several points, though I am grateful for your open and polite and constructive approach. But you are making things needlessly complicated, in my opinion.
  • as already pointed out, your use of the :la extension to indicate Latin alphabet is incorrect, if anything it should be :Latn. But I keep thinking that the Latin alphabet is the default on OSM, so there should be no need. In my understandng, reference xyz should be either ref:xyz or ref:Cyrl:xyz, Cyrillic being the exception, by and large. But I look forward to other opinions on this matter;
  • I can well understand your suggestion of xxx_civ versus xxx_mil tagging, and would support this, since both codifications appear to be managed by one and the same autority. Any suggestion for how to fill the xxx part? Ministry of aviation, perhaps, abbreviated? This in contradiction to the suggestion of military:ref or such, which suggests the codes are assigned and maintained by the military, which they are not, to my understanding, at least not in the Russian Federation.
  • I keep on resisting the difference you absolutely wish to make between "official" and "amateur" codings. To me, there are just several sources of information. But more generally, there does be a need to differentiate between various sources and systems of aerodrome codification. For example in Italy, there is the commercial but not official Avioportolano, assiging codes like CS08, CS indicating the province while the 08 bit is arbitrarily assigned, or I should be missing something. But there is also ulm.it assigning codes like CSSIP, with the CS again standing for the province but no further connection. There needs to be a way to enter both, in a differentiated way, into our database;
  • Even more striking is the codification by manufacturers of GNSS navigation systems and their databases. One aerodrome might well be code UK55 in one database while being UK71 in another.
  • What we need, in my opinion, is a broadly applicable tag CODE:SOURCE(:alphabet)=reference. For example, CODE:ulm_it=PGCST for the Trasimeno Aviosuperficie, or CODE:garmin=PT55 or CODE:rus_gvt_civ:Cyrl=ЗАД0
  • In general, our purpose should be to avoid, on the one hand, country-specific codification systems; while on the other hand agreeing on a scheme that is supple and broad enough to accomodate all kind of (sometimes weird) existing codification systems. Jan olieslagers (talk) 13:49, 23 September 2024 (UTC)
«as already pointed out, your use of the :la extension to indicate Latin alphabet is incorrect, if anything it should be :Latn.»
Today, as you can see above, @Kovposch suggested the options «*:und-Latn» or «*:mul-Latn». I don't see the need to find a replacement for «*:la» and have described above why, but I don't mind the more cumbersome «*:und-Latn» or «*:mul-Latn» option if it suits you and the community at large.
«But I keep thinking that the Latin alphabet is the default on OSM, so there should be no need. In my understandng, reference xyz should be either ref:xyz or ref:Cyrl:xyz, Cyrillic being the exception, by and large. But I look forward to other opinions on this matter»
This is where you are clearly wrong. Each locality has its own language, alphabet/script as default, including for references.
«I can well understand your suggestion of xxx_civ versus xxx_mil tagging, and would support this, since both codifications appear to be managed by one and the same autority. Any suggestion for how to fill the xxx part? Ministry of aviation, perhaps, abbreviated?»
I didn't understand this message of yours. What the "xxx" is meant?
«This in contradiction to the suggestion of military:ref or such, which suggests the codes are assigned and maintained by the military, which they are not, to my understanding, at least not in the Russian Federation.»
Yes, I've written about it above:
«What is the reason you suggest doing a reference subtag for the military tag (military:nat_ref) rather than doing a military subtag for the nat_ref tag (nat_ref:military)? It's about the reference first and foremost. And military is a type of reference. ref > military, so «nat_ref:military» is suggested (since we are talking about a national reference)»
«I keep on resisting the difference you absolutely wish to make between "official" and "amateur" codings. To me, there are just several sources of information. But more generally, there does be a need to differentiate between various sources and systems of aerodrome codification. For example in Italy, there is the commercial but not official Avioportolano, assiging codes like CS08, CS indicating the province while the 08 bit is arbitrarily assigned, or I should be missing something. But there is also ulm.it assigning codes like CSSIP, with the CS again standing for the province but no further connection. There needs to be a way to enter both, in a differentiated way, into our database; Even more striking is the codification by manufacturers of GNSS navigation systems and their databases. One aerodrome might well be code UK55 in one database while being UK71 in another. What we need, in my opinion, is a broadly applicable tag CODE:SOURCE(:alphabet)=reference. For example, CODE:ulm_it=PGCST for the Trasimeno Aviosuperficie, or CODE:garmin=PT55 or CODE:rus_gvt_civ:Cyrl=ЗАД0 In general, our purpose should be to avoid, on the one hand, country-specific codification systems; while on the other hand agreeing on a scheme that is supple and broad enough to accomodate all kind of (sometimes weird) existing codification systems.»
What's the big deal? For amateur references, I suggested "ref:<name>", so, for example:
  • ref:avioportolano=CS08;
  • ref:ulm=CSSIP;
  • ref:gnss1=UK55;
  • ref:gnss2=UK71;
  • ref:ulm=PGCST;
  • ref:aopa_ru=ЗАД0 + * ref:aopa_ru:mul-Latn=ZAD0
Why not?--Mazda05 (talk) 16:56, 23 September 2024 (UTC)
The reason why country and even state is used, is to avoid collisions causing multiple meanings, and to directly show the scope. One example I helped solved is how ref:thc=* became ref:US:thc=* then finally ref:US-TX:thc=* , because THC can refer to Texas or Tennessee's own Historic Commission.
Does ref:ulm=* refer to the Ulm city in Germany, or a database by University of Louisiana at Monroe? The motivation for using ref:*=* is to be uniquely identifiable. So ref:IT:ulm=* allows you to confidently query in Overpass, QGIS, or whatever database worldwide, and only get Italy's Ulm website codes.
—— Kovposch (talk) 20:27, 26 September 2024 (UTC)
No one prohibits the use of country subtags, including "ref:IT:ulm", as long as it is justified and pertains to a single country. "ref:ulm" is offered as an example. It could be "ref:ulm_it", "ref:IT:ref", or anything else. No problem. However, there may be cases of international amateur identifier, in which case the linkage to the country is incorrect --Mazda05 (talk) 21:46, 26 September 2024 (UTC)
The Italian source is www.ulm.it (and is scarcely kept up to date, in recent years), thus I consider ulm_it to be a better identifier. Similarly, the Russian division of AOPA is a quite separate organisation, the data they publish have nothing to do with AOPA as such, therefore my preference is for ref:aopa_ru(:Cyrl) format. But most and above all, I am getting very tired of this discussion, since one party continues to stick to personal preferences and opinions, and shows little openness to other views. I intend to remember the positive points of this discussion, and apply them in my contributions, but see little hope of finding a consensus. Jan olieslagers (talk) 20:38, 26 September 2024 (UTC)
Everyone who proposes something, lobbies something — it's a natural process. It is important to have arguments for one's position and a willingness to accept the other side's arguments, if any, and to form a final scheme based on the discussion that takes into account all the subtleties of the issue.
You disagreed with my proposed scheme and described several points such as "*:la" and "AFTN". It's ok. I & Kovposch suggested adjusting these points (*:la > *:mul-Latn & not to use AFTN as a binding). As for your mistake in assuming that Latin is the default everywhere - I already gave you a document (http://www.caiga.ru/DocAni/manual_of_4_letter_indexes/Indexes_of_Airports.pdf) where the default is not Latin, but you still lobby for "*:Cyrl" without arguments, and without "mul"/"und" (*:mul-Cyrl/*:und-Cyrl) or something else. When asked what you mean by “xxx”, you didn't answer the question. What is “CODE:” - you did not clarify.
However, you report that you are still not satisfied with something, but you have not written what exactly you disagree with and have not suggested a different scheme. To get a consensus, I suggest you describe and argue for the scheme you propose. Otherwise, we need to debate on the forum https://community.openstreetmap.org/ with https://wiki.openstreetmap.org/wiki/Proposal_process. Please advise if you are prepared to provide and argue a marking scheme or can the issue be transferred to the forum. In any case, I ask you to refrain from tagging as "local_ref", "local_ref:Cyrl" and similar for the period of discussion and getting consensus --Mazda05 (talk) 21:45, 26 September 2024 (UTC)
I do have proposed a scheme, and illustrated it with several examples. See above, after the phrase "Allow me the liberty to propose a scheme of three fields, the third probably optional." You only confirm your unwillingness to read what is written, and only pursue your own ideas. I will not further argue with you, it is obviously useless to offer arguments that are not read or considered. For lack of options, I will go on as I did, unless corrected by higher authority. Bye bye! Jan olieslagers (talk) 22:01, 26 September 2024 (UTC)
You misunderstood me. My idea is to come up with a consensus scheme that would require minimal resources and would not require lengthy discussions on the forum and in the Proposal process. If my idea was to lobby for my option and only - I would impose, for example, "aftn=*", and ":la", and deny all other options and find 1000+ reasons not to use your options... You write about arguments, but you did not give arguments on what I refuted, for example, for iata, icao, Latin as default...

«Allow me the liberty to propose a scheme of three fields, the third probably optional. The first field would always be "ref". The second would indicate the source, which could be "icao" or "aopa_ru" or "basulm" or many more others. The third would indicate the character set. As I stated before, this field could be optional: if not given, the character set would default to "latin", as is the case for 99,99% of OSM data. Some examples: 

   London Heathrow Airport

ref:icao=EGLH ref:iata=LHR 

   Moskva Sheremetyevo

ref:iata=SVO ref:icao=UUEE ref:nat_civ:Cyrl=УУЕЕ 

   Тверь / Мигалово

ref:nat_civ:Cyrl=УУЕМ ref:nat_mil:Cyrl=ЬУЕМ ref:icao=UUEM 

   Плавск

name=Плавск name:ru=Плавск name:en=Plavsk ref:aopa_ru=ZAD0 ref:aopa_ru:Cyrl=ЗАД0 »

What makes you think I didn't read your post? I responded to it earlier... I have informed you that it is not appropriate to affect the ICAO and IATA tags, as they have been previously approved by the community and changing them clearly requires a new https://wiki.openstreetmap.org/wiki/Proposal_process which is unlikely to be supported:

«1. I am strongly against to use the "ref:icao" & "ref:iata" or similar for ICAO & IATA codes, because on them: firstly, there is proposal in Approved status https://wiki.openstreetmap.org/wiki/Proposal:Iata_and_Icao; secondly, there is a developed scheme and norm of marking; thirdly, in order to change this scheme it is necessary to bring it to new Proposal process, where obviously no one will support it, as it does not make sense to transfer "icao" > "ref:icao" & "iata" > "ref:iata".»

You have no counterarguments to that, as far as I can see. Would you be willing to do https://wiki.openstreetmap.org/wiki/Proposal_process at icao=* > ref:icao=* & iata=* > ref:iata=*? As for me — no. I don't see the need for it and I don't see any arguments for the community to support such an idea.

Regarding *:Cyrl I explained to you in a both in the same reply-post and in the previous one post.

As for "ref:nat_civ" vs "nat_ref:civil" and similar, that can be debated. I expressed my variant for a sub-tag for already common "nat_ref" and argued why it is for "nat_ref" and not for "ref". You just proposed a sub-tag for "ref" without argumentation.

I supported the general concept of subtags, including three parts (main tag: "nat_ref" / "ref"; organization or level tag, like "civil", "military", "ulm_it", "avioportolano" etc; alphabet tag like "mul-Latn") in a reply to that post of yours: «4. As for the separation of the civil and military official references by different tags — I am not against this, but we can not reduce to "_civ" / "_mil", but to record completely "_civil" / "_military". This can be discussed when there will be a consensus on basic issues.

I would still like to come to a reasonable consensus. Best Regards» --Mazda05 (talk) 00:20, 27 September 2024 (UTC)

Closed / disappeared aerodromes

Time and again I am annoyed by people who (with the best of motivation, I do not doubt) remove aerodromes because they are no longer active. A recent example is EPLE Legnica. I suppose the aerodrome is no longer active; but someone removed its mention as an aerodrome, while leaving the runway and taxiways mapped. I think this is confusing and inconsequent. But how to do it properly?

leave aeroway=aerodrome but add a closed=yes tag ; this is my preference but has been rudely disregarded
change aeroway=aerodrome into disused:aeroway=aerodrome or some such?
other suggestions? Jan olieslagers (talk) 11:39, 27 July 2018 (UTC)
Can also added disused=yes if the aerodrome is not in service, but could actually be used for take-off and landing in an emergency, and if it still looks like an aerodrome or airport from the ground and air.
If it's been disused so long that it's no longer really recognizably and aerodrome and probably couldn't be used for landing aircraft without some minor repairs, then use disused:aeroway=aerodrome but keep the runways and buildings.
If the runway and buildings are in obviously poor condition, and would require extensive repairs or total reconstruction to be useable again, then use abandoned:aeroway=aerodromes. --Jeisenbe (talk) 12:49, 30 August 2019 (UTC)
Retrieved from "https://wiki.openstreetmap.org/w/index.php?title=Talk:Tag:aeroway%3Daerodrome&oldid=2760036"