Right, so for unofficial and agency identifiers I suggested using ref:<agency>. They will not necessarily be national, international, local — so they should not be prefixed with nat_, reg_, int_, loc_, local_ etc.
Without reading all opinions in the whole discussion, just a short remark: I strongly prefer to use country codes wherever possible. There are just too many similar / identical acronyms across the world.
I’m also against using those int_ / loc_ / nat_ prefixes - their definition is too vague. Is a code valid in e.g. Texas ‘regional’? ‘ref:US:TX:*’ is much more precise.
2 Likes
Texas doesn’t have an aviation agency. To avoid generating two hundred state tags, it is suggested to use one tag (if possible) for one concept
Any arguments in favour of that?
https://wiki.openstreetmap.org/wiki/Key:ref:
int_ref=*– international reference numbers or codes
loc_ref=*– local reference numbers or codes
nat_ref=*– national reference numbers or codes
https://wiki.openstreetmap.org/wiki/Key:int_ref:
“int_ref” stands for “international reference” and is used for international reference numbers or codes.
https://wiki.openstreetmap.org/wiki/Key:nat_ref:
National reference (“Nationally referenced as…”).
I see the most concrete concepts possible. Nothing at all points to vagueness. What did you see there that was vague?
That was just an example. Replace by any other area / state / country.
Exactly: One tag for one group of reference numbers. Having “loc_ref=ABC” on a dozen nodes world-wide doesn’t help in searching.
See:
What counts as “local”? State? County? City?
They are unspecific: If two referencing systems match the definition at a given place, both are acceptable. For basic map rendering, this is the easiest to work with¹: just pick the value and render it (betting that nobody put too many ;-separated values there). For more advanced uses (link to reference website, visual reference system identification on map, filtering, QA checks), it requires reference system recognition, if at all possible.
They are lacking geographical area precision: “Local” is obviously imprecise. “National” depends on borders², which are not always precisely defined (even in the absence of conflicts³). “International” can match any multi-states organization, not necessarily worldwide.
¹ In context of this discussion, ref being even easier.
² Assuming nation=sovereign state, which is not clearly documented on the wiki
³ In such case, the situation is probably clear enough for airports though.
(I know part of this message is rehashing previous comments. But the question was asked.)
On this brief tangent: yes, whenever an OSM tag refers to “regional”, we map that to states in the U.S. However, it is murky because some contexts require us to distinguish multiple levels of “local” and multiple levels of “regional” at the same time. Thankfully not in aviation. Even counties and cities that operate multiple aviation facilities will (must) defer to the national authorities for the location identifiers.
nat_ref=* seems OK to me in general as long as we’re sure nations won’t start coming up with coding schemes for other nations’ airfields. Compared to something more explicit like ref:ABC=*, at least a geocoder will know the scope in order to avoid overindexing the code. The downside is that the identity of “national” is less obvious and needs to be determined via a spatial query. (nat_name=* has similar limitations.)
Is there anywhere in disputed territories or otherwise with multiple four letter ICAO codes issued by different countries?
The example is clearly unfortunate and incomprehensible - because of its failure, it is unclear what it would look like. There is no discussion here yet of merging or replacing the FAA anyway, as the faa tag is documented and already in widespread use. Texas can sleep easy
No one has suggested using loc_ref yet
This is not a problem with the description of the loc_ref tag, but a problem with the concept of ‘local’. There is no problem with national and international, although you indicated that they are vague…
In any case, no one here is suggesting using loc_ref yet
What do you mean?
The document ICAO Location Indicators Doc 7910/158 dated December 2015 is publicly available for free — you can analyse it. If you need newer — there is a free online ICAO API Data Service for 100 requests per day.
But what does this have to do with this topic?
@Minh_Nguyen https://www.faa.gov/documentLibrary/media/Order/7350.9AA_LOCID_dtd_3_24_22.pdf
I didn’t see any information here about military bases overseas, perhaps this information is not public or hard to access, but there are three-character identifiers for Canadian airfields here. As far as I have seen these are the last 3 characters of the Transport Canada assigned code (TC LID), however I have not analysed them all.
There’s also tc=*, which is slightly older and even more common at 138 occurrences, versus 113 for tclid=*.
Right, the FAA LIDs for Canadian airfields are clearly related to TC LIDs, with the exception of the C prefix. Maybe the difference doesn’t matter for OSM purposes. For example:
| Location | FAA LID | TC LID |
|---|---|---|
| West Coast General Hosp Secondary Aerodrome, Port Alberni, B.C. | BK5 | CBK5 |
| St Stephen, N.B., Secondary Aerodrome[1] | CS3 | CCS3 |
| Markham Secondary Aerodrome, Toronto, Ont. | NU8 | CNU8 |
Yes, that St. Stephen. ↩︎
I have created stub wiki pages Key:tc - OpenStreetMap Wiki and https://wiki.openstreetmap.org/wiki/Key:tclid
I don’t mean this to preclude retagging to a possible new tag, only to document the tags in use now
1 Like
(If you know where Location Identifiers can be looked up on an official Transport Canada website, please add it!)
https://www.navcanada.ca/en/aeronautical-information/operational-guides.aspx > Canadian Airport Charts > Download current issue & Download next issue
They will be more up to date and will not include old refs as it is on the wikipedia.
Or use a paid official source Canada flight supplement (CFS). The free ones are obsolete: 2008 & 2020
Ah thanks. The Airport Charts don’t seem to include everything, e.g. no CPR5 Node: Woodstock Airport (1042029061) | OpenStreetMap. The 2020 CFS does have it, though only as LID and name.
I still wonder if Transport Canada themselves have a public list somewhere. Nav Canada is a separate organization.
There’s only a reference to Canada Flight Supplement (CFS) or Canada Water Aerodrome Supplement (CWAS)
You are always arguing there would be hundreds of new ref:* required to be added. Can you link some of those. I would imagine that is limited to quite a few only, as I would believe most aviation agencies simply use ICAO/IATA and do not come up with additional identifiers. Those additional identifiers I would think will be limited to developed countries with a high amount of (small) airfields, like US, Canada and maybe Australia.
Since tags for US and Canada already exist, there might be just a hand full additional keys required.
1 Like
To avoid creating one tag that has different meanings in different places, it is suggested to use one tag (if possible) for one type of reference.
What’s “incomprehensible” about one example of a country/state code? It doesn’t matter whether I wrote ref:US:TX or any other country?
To give an other example: ‘ref:faa’. Is this the US Federal Aviation Agency or the reference number of the UK Fleet Air Arm? The geolocation of the airstrip might not be sufficient as many bases are located on other countries territories. Using ref:US:faa and ref:UK:faa completely solves this for no expense.
1 Like