Aerodrome refs other than ICAO, IATA, FAA

[Mazda05]

Hello everyone.

During the aerodrome editing process, a disagreement arose with participant Jan Olieslagers | OpenStreetMap about the markup of unofficial aerodrome identifiers (identifiers not related to IATA, ICAO, FAA and not assigned by aviation authorities): Changeset: 155364333 | OpenStreetMap.

After some discussion, it was proposed to clarify the basic markup scheme also for official identifiers that are not IATA, ICAO, FAA. User:Kovposch - OpenStreetMap Wiki also joined the discussion. However, we were unable to agree on a basic markup scheme for these identifiers.

The topic was created for the purpose of discussing these identifiers and, if necessary (if no consensus is reached), it will be converted to an RFC Proposal type topic according to the Proposal process.

Which object identifiers are being discussed: All aerodromes (airports, airfields, airstrips) and heliports:

• aeroway=aerodrome
• aeroway=airstrip
• aeroway=heliport

My suggestion and basic markup scheme for the moment:

• iata — without changes;
• icao — without changes;
• faa — without changes;

---

• official national refs (appointed by an agency of the national aviation authority) — nat_ref;
• official national civil refs (appointed by an agency of the national aviation authority) — nat_ref:civil (only if there’s also a military ref);
• official national military refs (appointed by an agency of the national aviation authority) — nat_ref:military (only if there’s also a civil ref);
• additional official national refs in another alphabet/script (appointed by an agency of the national aviation authority) — nat_ref:<script>, nat_ref:civil:<script>, nat_ref:military:<script>. Where is used according to ISO 15924.
  For example, in Latin, Cyrillic, Arabic — nat_ref:Latn, nat_ref:Cyrl, nat_ref:Arab, nat_ref:civil:Latn, nat_ref:civil:Cyrl, nat_ref:civil:Arab, nat_ref:military:Latn, nat_ref:military:Cyrl, nat_ref:military:Arab etc (according to the available scheme, but without a language code, since identifiers do not have a specific language, but only an alphabet/script);

---

• refs, appointed by an agency other than the national aviation authority — ref:<agency>, where <agency> — name of agencies or non-official amateur organization or resource (according to the already existing scheme of ref tag extensions);
• additional refs, appointed by an agency other than the national aviation authority, in another alphabet/script — ref:<agency>:<script>.
  For example, in Latin, Cyrillic, Arabic — ref:<agency>:Latn, ref:<agency>:Cyrl, ref:<agency>:Arab.

---

For identifiers of objects in disputed territories it is proposed to use the extension of the state, the same one used for [addr:country](https://wiki.openstreetmap.org/wiki/Key:addr:country) tag values, i.e. ISO 3166-1 alpha-2. For example:

• nat_ref:<CountryCode>;
• nat_ref:<CountryCode>:civil;
• nat_ref:<CountryCode>:military;
• nat_ref:<CountryCode>:Latn;
• nat_ref:<CountryCode>:military:Latn;
• ref:<CountryCode>:<agency>;
• ref:<CountryCode>:<agency>:Latn.

---

It is suggested that the base alphabet/script be the one that is the main official or primary alphabet in an amateur organization or resource.

---

If there are several competing schemes, votes can be organized to see if there is a consensus of the vast majority of active participants

At the end of the discussion, according to the chosen scheme, if there is consensus, it is proposed to make changes on the wiki to the pages:
https://wiki.openstreetmap.org/wiki/Tag:aeroway%3Daerodrome
https://wiki.openstreetmap.org/wiki/Key:aeroway
https://wiki.openstreetmap.org/wiki/Key:nat_ref
https://wiki.openstreetmap.org/wiki/Key:ref

If you have any other suggestions or opinions on how to improve the scheme — please post in this topic.

Best Regards.

[Updated #1]
[Updated #2]

[Jarek]

So would nat_ref be used for codes like Transport Canada Location Identifier, (e.g. List of airports in Canada (L–M) - Wikipedia ), so for example Node: ‪Lake Muskoka/Dudley Bay Seaplane Base‬ (‪1042028581‬) | OpenStreetMap would get nat_ref=CNT5?

[aighes (Henning)]

@Mazda05

but without a language code, since identifiers do not have a specific language, but only an alphabet/script);

I’m not sure that is a good idea.
Neither it’s a good idea to use abbreviations for <script> nor is it a good idea to define specific words for the use case. Since there are plenty of possible scripts. The world is not limited to Arabic, Cyrillic and Latin. There is Hindi, Thai, Chinese, Japanese, Korean,…

@Mazda05

official national refs — nat_ref;

Based on the values, to me it seems that key is used already for road refs, not sure if it’s a good idea to use the same key as well for airports. On top, how would your system deal with the case of multiple national refs or multi-national refs? I would think it makes more sense to have a key like ref:<agency>[:<language>]

[Mazda05]

Yeah, that’s right.

[Mazda05]

@aighes

I’m not sure that is a good idea.
Neither it’s a good idea to use abbreviations for <script> nor is it a good idea to define specific words for the use case. Since there are plenty of possible scripts.

What suggestions do you have? Earlier in the discussion, extensions *:und-<Script> and *:mul-<Script> were suggested. In general, they can be considered, but I didn’t see the need to clutter the tag with additional codes.

@aighes

The world is not limited to Arabic, Cyrillic and Latin. There is Hindi, Thai, Chinese, Japanese, Korean,…

Arabic, Cyrillic and Latin this is just an example, this scheme can be used with any alphabets.

@aighes

Based on the values, to me it seems that key is used already for road refs, not sure if it’s a good idea to use the same key as well for airports.

According to the description on the wiki, nat_ref is proposed to be used for national identifiers. Using this tag on the road or elsewhere to identify a national identifier is not a barrier. Why do you think it is not ok?

@aighes

On top, how would your system deal with the case of multiple national refs

https://wiki.openstreetmap.org/wiki/Multiple_values

@aighes

or multi-national refs?

For official identifiers of multiple countries, in addition to ICAO and IATA, can be used ref:<agency> or a separate tag, as is done for the FAA.

@aighes

I would think it makes more sense to have a key like ref:<agency>[:<language>]

It is to reduce the number of agencies when it is a national aviation agency that it was suggested to use nat_ref to avoid generating two hundred ref:<agency>

[Mazda05]

Although FAA is also essentially the national identifier for the US, due to the tag’s widespread use faa | Keys | OpenStreetMap Taginfo, in this discussion I suggest that it not be changed. Over time, however, we can discuss merging faa=* with the tag for national identifiers.

[aighes (Henning)]

@Mazda05

It is to reduce the number of agencies when it is a national aviation agency that it was suggested to use nat_ref to avoid generating two hundred ref:<agency>

In general, I think it’s important to know what the value is about. nat_ref doesn’t say anything about what to expect in the value. One airport might be claimed by different national agencies. Having just a semicolon separated list might not be useful. Think about an airport in the disputed area of China and India. That airport might end up with nat_ref=CHI;IND and nat_ref:chinese=<some chinese characters> and nat_ref:hindi=<some hindi characters I don’t see how this would be useful and easy to use information, where ref:<cn-agency>=CHI and ref:=IND` would be clear and the information can be understood, queried and verified.

[aighes (Henning)]

@Mazda05

Arabic, Cyrillic and Latin this is just an example, this scheme can be used with any alphabets.

I just don’t see a good reason to use another set of list when there is an existing set. It might cause problems later on.

[muralito]

@Mazda05

It is to reduce the number of agencies when it is a national aviation agency that it was suggested to use nat_ref to avoid generating two hundred ref:<agency>

It should be ok to use already established keys, just because they are already there in the database.

nat_ref is mostly used for road refs, but the wiki definition is generic (“Nationally referenced as…”), so it shouldn’t be a problem to use to national reference of aerodromes.

But for national, and according to how nowadays “ref” namespace, it should be ref:<CountryCode>:<agency>. It has all the pros of using the namespace, but as cons it would make more difficult to support or validate without enumerating each pair country/agency. What about ref:aero:<agency>?

[Mazda05]

@aighes

In general, I think it’s important to know what the value is about. nat_ref doesn’t say anything about what to expect in the value

nat_ref:

National reference

ref

nat_ref=* – national reference numbers or codes

@aighes

One airport might be claimed by different national agencies.

Can you give me an example?

@aighes

Think about an airport in the disputed area of China and India. That airport might end up with nat_ref=CHI;IND and nat_ref:chinese=<some chinese characters> and nat_ref:hindi=<some hindi characters I don’t see how this would be useful and easy to use information

I don’t see any problem with that. Can you please tell me what exactly is the problem here? Such markup shows identifiers correctly and separates them in such a way that it is clear what is being marked up, unlike the current time, when partitioning is done by ref, nat_ref, loc_ref, local_ref and reg_ref. Somewhere the national ref is listed as icao.

@aighes

ref:<cn-agency>=CHI and ref:=IND` would be clear and the information can be understood, queried and verified.

In general, this can be considered for disputed territories if needed. However, generating two hundred agencies (ref:agency) for one and the same concept is not ok in my opinion.

@aighes

I just don’t see a good reason to use another set of list when there is an existing set.

What do you mean exactly?

[muralito]

@Mazda05

In general, this can be considered for disputed territories if needed. However, generating two hundred agencies (ref:agency) for one and the same concept is not ok in my opinion.

I agree. It will pollute the namespace.

[Mazda05]

@muralito

But for national, and according to how nowadays “ref” namespace

What exactly

and according to how nowadays

?

@muralito

it should be ref:<CountryCode>:<agency>.

At least the unofficial amateur identifiers are the ones assigned in many countries. There may be official ones. This rejects such a scheme with :<CountryCode>:

:<agency>: do you mean both official national and unofficial amateur or one thing?

@muralito

What about ref:aero:<agency>?

For which identifiers exactly?

If for national identifiers — I see no reason to generate two hundred tags when you can use one and already existing, nat_ref.

If for unofficial amateur or official multistate — yes, you can add the *:aero:* extension to identify aviation tag. But is it necessary? I think it could be put to a vote

[aighes (Henning)]

@Mazda05

Can you give me an example?

Pick any airport on Crimea peninsula for example. They will be claimed both by Ukrainian and Russian agency. How could I query for a specific ref of the Ukrainian agency? Even the <script> would not work…

Another down-side of a generic ref’s like nat_ref is, that they are not unique. nat_ref=A10 might be a airport, a highway and a forest at the same time. Makes it quite ambiguous.

@Mazda05

I don’t see any problem with that.

What is clear on nat_ref=CHI;IND? How would you derive the Indian ref? If that is clear to you, why bother nat_ref, put everything in ref will clear as well

Are you sure an airport has only one nationwide ref?

@Mazda05

However, generating two hundred agencies (ref:agency) for one and the same concept is not ok in my opinion.

I don’t see how you will end up with 200, since most countries with a “normal” amount of airfields won’t have different ref’s than the existing icao and iata-values.

[Minh_Nguyen (Minh Nguyễn)]

@aighes

@Mazda05

but without a language code, since identifiers do not have a specific language, but only an alphabet/script);

I’m not sure that is a good idea.
Neither it’s a good idea to use abbreviations for <script> nor is it a good idea to define specific words for the use case. Since there are plenty of possible scripts. The world is not limited to Arabic, Cyrillic and Latin. There is Hindi, Thai, Chinese, Japanese, Korean,…

Four-character codes like Latn and Cyrl aren’t ad hoc abbreviations. They come from ISO 15924, one of the component standards of the IETF’s BCP 47 standard, which we use in the name:*=* tagging scheme. Adherence to this standard would promote software interoperability and avoid edit wars over the preferred names of scripts, which isn’t really a topic OSM needs to be an authority on.

[Mazda05]

@aighes

Pick any airport on Crimea peninsula for example. They will be claimed both by Ukrainian and Russian agency. How could I query for a specific ref of the Ukrainian agency? Even the <script> would not work…

@aighes

What is clear on nat_ref=CHI;IND? How would you derive the Indian ref? If that is clear to you, why bother nat_ref, put everything in ref will clear as well

Yes, you are right , to separate the identifiers in those regions (disputed areas) there it is better to use the scheme you suggested.

As I have previously reported:

In general, this can be considered for disputed territories if needed. However, generating two hundred agencies (ref:agency) for one and the same concept is not ok in my opinion.

@aighes

I don’t see how you will end up with 200, since most countries with a “normal” amount of airfields won’t have different ref’s than the existing icao and iata-values.

Every state has or may have an aviation agency. The scheme only with ref:agency is the potential generation of about 200 tags for a single concept, instead of using one

@aighes

Another down-side of a generic ref’s like nat_ref is, that they are not unique. nat_ref=A10 might be a airport, a highway and a forest at the same time. Makes it quite ambiguous.

I don’t see any problem with that. The nat_ref is not exclusively assigned to roads. The purpose of the discussion is not to create a new tag. The purpose of the discussion is to develop an identifier markup scheme to detail the status of an airfield identifier: ICAO, IATA, FAA / national official, additional for it in another alphabet/script, unofficial amateur of some resource or organization, which will organize the current markup of these identifiers through ref, nat_ref, loc_ref, local_ref, reg_ref, icao (where it is not ICAO) and others.

[Mazda05]

To clarify which facilities we are talking about, I will add to the first post the information that the facility identifiers being discussed are: aerodromes (airports, airfields, airstrips) and heliports.

I will also add the information that it is proposed to use ISO 15924 for extensions of additional identifiers to identifiers other than the primary identifier.

[aighes (Henning)]

@Mazda05

The purpose of the discussion is to develop an identifier markup scheme to detail the status of an airfield identifier: ICAO, IATA, FAA / national official

I get that, though I doubt that each airport will only come with ONE national official reference. In a good case you might have only ONE national aerospace agency, though there might be other national agencies with different refs.
For example there is a TRACES-code for border points where food enters the European Union (I know, it’s not actually nationwide, though I would think it’s not only exists in the European Union) and of course each intl. airport has such a code.

[Mazda05]

@aighes

I get that, though I doubt that each airport will only come with ONE national official reference. In a good case you might have only ONE national aerospace agency, though there might be other national agencies with different refs.

Can you give me an example? For aerodromes/heliports

[aighes (Henning)]

As mentioned above the TRACE-code: Those would be the codes for Germany, eg. Frankfurt airport is DEFRA4L

[Minh_Nguyen (Minh Nguyễn)]

@Mazda05

official national refs — nat_ref;

Unifying national location identifier schemes under a single key presumes that a data consumer can straightforwardly determine the scheme geographically based on the containing administrative boundary. Are there any situations where this assumption would fail? For example, does any country maintain military facilities on foreign soil while assigning their own identifiers rather than using identifiers assigned by the host country?

@Mazda05

I will also add the information that it is proposed to use ISO 15924 for extensions of additional identifiers to identifiers other than the primary identifier.

I saw the suggestion for these language and script codes on the talk page, but does any national civil aviation authority actually assign location identifiers to a given facility in multiple writing systems or even multiple languages? Maybe that should just be limited to the unofficial refs, to the extent that any unofficial body assigns refs multilingually.