Proposal talk:Airport communication frequencies

Radio Frequency

Have you considered reviving the radio frequency proposal? That seems a lot more fleshed out than this one. --GA Kevin (talk) 02:11, 20 June 2025 (UTC)

I did have a look at that proposal before drafting this one. It is impressive, but it solves what seems to be a completely different problem. That proposal seems to be designed for radio enthusiasts and HAM operators to map RF infrastructure with complex relations, antennas, and satellites. It was extremely complex in my eyes and the proposal does explicitly state that it’s «not expected to be used widely by [the] general public, but more for a specialized use by HAMs or radio monitoring enthusiast[s].» This proposal directly serves aviation-related uses by tagging frequencies used by airports. The use cases are different: a pilot planning a flight needs to know «What’s the Unicom frequency at Wilmington Air Park?» not «What antenna infrastructure exists within X meters of Wilmington Air Park?» FatalFit (talk) 03:27, 20 June 2025 (UTC)

Nice! As long as you've seen it I'm happy with that. You don't need to take everything from an abandoned proposal, but is a good starting place! --GA Kevin (talk) 11:15, 20 June 2025 (UTC)

De Facto Tag Change

TagInfo shows most communication=* is towers / transponders, not the operator of said transponders. Is there an issue in saying "If a mast / tower exists within X distance from an airport with certain frequencies, that the airport can be assumed those frequencies?" Because airports do not radiate a signal, towers or transmitters do. --GA Kevin (talk) 02:11, 20 June 2025 (UTC)

I understand your concern with tagging the signal operator and not the source, but aviation frequencies work differently than typical radio infrastructure. While airports don’t actually radiate signals, airports (not antennas) are assigned (typically by a government entity) and operationally control these frequencies as part of their operations. These frequencies are fundamentally tied to airport operations, not just physical infrastructure. If you were to map individual antenna infrastructure, it would be more complex and difficult to verify which antennae broadcast which frequencies, as some airports, especially towered ones, have more than one antenna. I feel it would be more simple and follow precedent by tagging the operational characteristics on the primary feature, the airport. FatalFit (talk) 03:27, 20 June 2025 (UTC)

I understand frequencies are assigned to an operator but that's more of a clerical reason than practical. A mast does not typically accept mail, visitors, or produce paperwork or anything else really. Likewise, cell carrier spectrum is assigned to the operator (the carriers) but it would be incorrect to assign every shop/office/location with a telecommunication tag as the operators spectrum. Cell service is fundamentally tied to their operator too, but we don't tag them this way. Antennas should be mapped in my opinion, it's the backbone of wireless communication, much the same as power poles are mapped because they are the backbone of electrical grids. --GA Kevin (talk) 11:15, 20 June 2025 (UTC)

I see your point about mapping infrastructure. Aviation frequencies are assignments published in aeronautical charts (FAA Airport/Facility Directory, etc.) tied directly to airports. These frequencies are assigned to airports rather than coverage areas or antennas. These publications are easily verifiable and reference frequencies by airport such as "Wilmington Air Park uses 119.475 for tower," which is how pilots, flight planning software, and other aviation databases access this information.

Verification is the main challenge I see with mapping individual antennas, since many airports don't publish detailed antenna locations or specifications, making it difficult to verify what each one communicates. That said, I think it would make sense for both methods to work in parallel: where antenna layouts are verifiable, individual antennas could be mapped along with their frequencies; where not, airport-level frequency tags remain appropriate given how fundamental these frequencies are to operations. Either way, data users can still see which frequencies the airport uses. FatalFit (talk) 18:52, 20 June 2025 (UTC)

frequency tag is good enough

I'm not sure why frequency=* is not adequate for your needs here. a simple subtag of frequency:*=* could capture this information without changing the meaning of current communication tags. --GA Kevin (talk) 02:11, 20 June 2025 (UTC)

I believe you’re suggesting something like frequency:tower=119.475 or frequency:atis=124.925. That could work, and I can adapt the proposal if the community prefers that approach. I chose communication:*:frequency=* because of the precedent set by communication:amateur_radio=* and its subkeys. However, the main purpose/functionality would be the same under either key, so if there’s a preference for one or the other, I can modify the proposal. FatalFit (talk) 03:27, 20 June 2025 (UTC)

I will let some others chime in first but I believe this to fall better in frequency=* versus communication=*. --GA Kevin (talk) 11:15, 20 June 2025 (UTC)

Prefixing is better than suffixing for attributes of different entities inside, eg *:wikidata=* not wikidata:*=* . As mentioned, communication:*:frequency=* has already been used. As I have asked, *:frequency=* + *:callsign=* would be better organized than frequency:*=* + callsign:*=* .
—— Kovposch (talk) 09:13, 21 June 2025 (UTC)

I don’t agree at all, arguably the most popular version of this is ref=* and that is “suffixing.” I also don’t think having a tagging scheme 3 subkeys deep will do any good for adoption. People may not use it at all but they’ll probably just use it incorrectly. frequency:*=* would be much better and already established. The page even calls out specifically 2-way radio like this. - GA Kevin (talk) 00:01, 24 June 2025 (UTC)

ref:*=* is used for specific coding and databases. These are not. junction:ref=* , level:ref=* , heritage:ref=* , bridge:ref=* . highway_authority_ref=* .
—— Kovposch (talk) 17:19, 24 June 2025 (UTC)