Many broadcast towers carry a variety of radio, television, and cellular antennas with differing names, heights, operators, frequencies, and other attributes. Unfortunately, the documentation for man_made=mast is silent on how to map these structures, but it only allows this tag on nodes. I would like to relax this restriction and also allow the tag on areas, so that we have the option to micromap more complex cases.
Background
In the U.S., we imported comprehensive coverage of individual broadcast antennas from GNIS back in 2009. Each antenna was tagged as a man_made=tower node. Whenever multiple antennas are on colocated the same mast, the import placed a series of coincident nodes. Later, many were retagged as man_made=mast, once we started distinguishing between “skeletal” structures and more substantial structures. This tagging violates the “One feature, one element” principle, since there’s only one mast in reality.
Some of us began to combine these nodes, but the result is that many keys contained semicolon-delimited value lists. Sometimes we tried to reconcile conflicting values by simply taking the average of ele=* or randomly choosing one of the gnis:feature_id=* values and discarding the rest. Making matters worse, over the past 15 years, radio stations have frequently changed ownership in citywide or nationwide “realignments”. Each time this happens, the owner moves some of the antennas to a different tower in the same city – not physically, but rather in terms of what the antenna is licensed to broadcast. Updating the single consolidated node becomes tedious and error-prone as we have to pick apart the various values.
A micromapping solution
In a sense, this is similar to the problem with multiple appurtenances hanging off a street lamp, but at a larger scale, which may allow for a simple solution. In 2020, I began experimentally micromapping some shared masts in my hometown as man_made=mast areas and each antenna colocated on the mast as a man_made=antenna node within the area. This required researching the history of each node to determine which attributes were still accurate after four or five station realignments.
I believe this more detailed modeling satisfies the “One feature” principle, since we’re only saying each node is an antenna, not a full-fledged mast. Besides helping us keep the various antennas from getting tangled up, we can also express the geometry of the tower itself. This isn’t possible with a single node, and I’m not inclined to duck-tag the structure as a man_made=tower or building=tower just because it’s big.
(Aside: I’m told that an AM station can broadcast from a tower array, such that the entirety of multiple structures effectively serves as the antenna. In that case, a site relation may be appropriate instead.)
Conflict with documentation
Despite these benefits, the man_made=mast documentation currently specifies that the tag only applies to nodes, not areas. I understand why, but it seems short-sighted to preclude the form of micromapping that I engaged in. There was some favorable feedback on OSMUS Slack. I also mentioned my experiment both on the talk page and last year in a help thread on the forum, but there hasn’t been much response, so I didn’t feel comfortable updating the documentation without further discussion.
In the meantime, iD and Rapid warn about these areas based on the prohibition against areas on the wiki:
Along the way, Wikipedia and Wikidata tags were removed because they only represented the structure, not the stations that broadcast from it. However, the surviving node still has FCC IDs representing the structure and multiple GNIS feature IDs corresponding to the individual stations.
Updating the documentation
In conversation, the rationale appears to be a desire for consistency among all the broadcast towers – that no effort should be made to micromap these towers without micromapping all the towers. Frankly, I disagree with the importance that’s being placed on database consistency and upfront standards-making. After all, data consumers cope with some supermarkets being tagged as nodes and others as areas. When a shop is colocated with other shops in the same building, we don’t expect mappers to maintain complex tabular data about the shops on the building itself. That said, I understand that some mappers are motivated to contribute to the map by resolving validator issues, so we should make sure those validators reflect best practices.
Admittedly, I was being bold and mapping a handful of features not completely to spec prior to getting permission from the community. Since I’m apparently not the only one who’s been micromapping man_made=mast, I’d like to get the community’s opinion about updating the documentation to allow either nodes or areas, before any of their meticulous work also experiences dataloss.
man_made=mast is silent on how to map these structures, but it only allows this tag on nodes. I would like to relax this restriction and also allow the tag on areas, so that we have the option to micromap more complex cases
Hi @Minh_Nguyen. While I appreciate you starting this conversation, I also feel your approach here has been somewhat antagonistic. Calling someone out on a public forum (and in the OSM Slack) for facilitating “dataloss” by adhering to the documented guidelines rather than an alterative schema that you admit you implemented without consulting the guidelines or the community is problematic. No one can be expected to know (or follow) what rules you personally deem appropriate – that’s why we have documentation.
I also don’t think the method by which we currently map telecommunications facilities is perfect, and I am certainly open to further discussion on how we could improve it. I think the crux of the issue is finding a good balance between what is intuitive, especially for the beginner/intermediate mapper (in my opinion, the primary priority), and what lends itself to a person who may attempt to micro-map.
While micromapping is useful in some cases, it should always take a backseat to ease-of-mapping and should still fit within the guidelines of the documentation (as ideally all mappers should know to follow guidelines for the sake of consistency). As people around the world rely on data from OSM to be accurate and usable to navigate their surroundings or provide a foundation for their own projects, OSM should not be used for pet projects or experiments that don’t match documentation. Thousands of people edit this resource. If we disregard consistency and standards, how can we consider the map a reliable representation of our world? How can data consumers trust that what is represented in the map is truly reflective of our reality?
The tension between the dual goals of micromapping and ease of use is evident in the mapping of communication masts. A significant number of communication masts (man_made=mast), tens of thousands in the US alone, are currently miscategorized due to user error. Common misclassifications include:
man_made=tower (nodes or areas)
man_made=communications_tower (nodes)
man_made=antenna (nodes)
Regarding your proposal, adding support for mapping sites as areas would necessitate a significant rewrite of the wiki page and general guidance. As such, best practices would need to be established.
A quick summary of my concerns:
How to Map as an Area
Option 1: Mapping the footprint of the structure:
This approach focuses solely on the physical base of the mast, as shown in your examples. However, the vast majority of communication masts (e.g., guyed lattice or monopole structures) have footprints of only a foot or two, relatively comparable to a high-mast street lamp. This raises questions about the practicality of area mapping for such small structures.
Option 2: Mapping the entire site complex:
This includes the mast and any associated base station equipment. A challenge here arises when the base station isn’t directly beneath the mast. How do we define and delineate such sites consistently?
When to Map as an Area
If the presence of collocations on a site justifies area mapping, then it would apply to a majority of sites. Should mapping as an area be THE prioritized method going forward? Alternatively, should we map communication maps as areas only for structures above a certain size? If the guideline is set for “larger” structures, what size threshold would be appropriate? At that point, would it not be preferred to use man_made=communications_tower, which already supports area mapping?
How will the attached tags to Communication Masts be changed to account for mapping as an area?
If the standard for going forward is mapping a Communication Mast with multiple Antenna nodes, what information should be retained on the core Communication Mast area/node? Only intrinsic values (elevation, construction type, height, material, etc)? Only intrinsic values plus a list of communication types (radio, microwave, mobile phone, etc)? Should owner/operator still be incorporated, or left to the antenna node?
I’m sure there is more that could be discussed here, but overall I do lean toward the suggestion posted by @dieterdreist as it achieves many of the same goals without necessitating answers to some of the questions asked above.
This doesn’t match my understanding of the role that the wiki plays in the OSM project. The man_made=mast page is not a technical standard; it is the result of mappers trying their best to describe existing practice that arose organically, hence the status “de facto”. There is a formal process for getting approval on a tagging proposal, but a tagging approach does not need to go through this process in order to gain traction in OSM. In fact, proposals sometimes fail precisely because the community expects the proposer to experiment first. The proposal is primarily for the purpose of “clearing the field” of competing approaches.
My experiment was not radical; it builds on common practices. Almost a thousand masts are mapped as areas, most of them probably intentionally. While this is only 0.02% of total man_made=mast usage, it is far from rare enough that you’d be justified in deleting this detail on sight without at least thinking about how to accommodate this detail in some other manner. More likely, the wiki page’s authors just assumed it wouldn’t be used on areas, and the assumption turned out to be incorrect. This situation is not unheard of when it comes to our documentation of POI types. The only novel aspect of my experiment was to place man_made=antenna nodes inside a man_made=mast area, which currently occurs at only 13 sites in six cities worldwide (not including any you’ve simplified to nodes). As I explain in the original post, this is motivated by a desire to deconflict the various attributes of these antennas.
You’re right that a data consumer interpreting the documentation literally wouldn’t pick up the mast I micromapped. However, it turns out that most software is more flexible in practice. Unlike iD/Rapid, JOSM and Vespucci allow masts to be areas. Most renderers that symbolize man_made=mast can do so with man_made=mast areas, including OSM Carto and Open Infrastructure Map. The only taginfo-listed renderer that expects only nodes would be Straßenraumkarte Neukölln, which is specific to Berlin. The only unlisted renderer I know of would be F4Map (though its pole-like depiction of masts leaves something to be desired).
I could’ve added a note about these facts and changed the infobox to allow areas without much ceremony. It’s not unheard of for mappers to take that step based on statistics like these. Some mappers would even take the next step and restore the area without further discussion. However, I chose to consult others first and reach out to you before taking these steps, since communications infrastructure is not my area of expertise. If anything, I haven’t been as aggressive as I perhaps should’ve been to promote this tagging style, because there’s a lot of unhappiness with the currently documented approach – questions about how to map colocated towers have come up multiple times on this forum and Slack in recent years.
I’m sorry my message comes across as antagonistic. Perhaps you can sense some frustration. There’s an important principle in OSM that we are to be respectful of other mappers’ work to the extent that it reflects reality. It would be one thing if a mast were clearly mistagged by mistake or without much thought, or untouched since an import, or falsely optimized for a particular renderer’s quirks. But when someone takes the time to draw a tower’s footprint and otherwise lavish attention on the feature, it isn’t fair to simply delete that detail. You could’ve retagged the footprint as something else like area:man_made=mast and searched the wiki for alternative proposals for the antennas, like that node relation proposal. At the very least, you could’ve left a more descriptive changeset comment.
Fortunately, I hadn’t taken the time to micromap very many towers, so I may be able to recover the work using a changeset reverting tool, should it come to that. I hope we were just unfortunate enough to have crossed paths but that others haven’t seen more of their work deleted.
This inconsistency has nothing to do with micromapping. man_made=tower is the oldest of these tags. This was the only relevant tag when the GNIS import took place. man_made=mast was later split out, but unfortunately there’s always a long tail of older tagging in OSM, because we generally don’t prioritize database consistency over other matters. I appreciate that this is a priority of yours and especially that you’ve managed to do as much cleanup as you have, but consistency needs to be understood as a tradeoff in a crowdsourced, bottom-up project like ours.
There’s historically been a lot of confusion between these four tags because of their overlapping definitions (from a layperson’s perspective). It hasn’t helped that some of the documentation pages have at times used the same exact image to illustrate multiple tags. Every time I look at the man_made=antenna page, I always have to remind myself that this photo only appears in the infobox because of the antennas on the towers, not to say that the towers themselves should be tagged as man_made=antenna.
I used “footprint” in my earlier post rather loosely. What I was really wanted to express was the horizontal extent of the structure, not to replicate a 3D model. It’s rather like how a man_made=bridge area or man_made=gantry way is shaped.
For example, I’ve micromapped WLW’s Blaw-Knox tower as an area based on the maximum profile midway up. This is an AM tower for only one broadcaster, but the man_made=mast area allowed me to distinguish between the broadcaster and the tower, both of which are nationally renowned and historically significant. It also allows me to map the big WLW sign halfway up. I was already mapping man_made=guy_wire ways and man_made=guy_wire_anchor nodes, since a new neighborhood is coming in below the tower and I wanted to show how it relates to the guy wires.
For structures that have no substantial footprint or profile, I agree that a more slender structure akin to a pole might benefit from a different representation, since the horizontal extent is better represented by a diameter=* tag. Node relations could come in handy if such a structure holds a variety of antennas, though an experimental relation type is just about the least discoverable thing one can map in OSM.
Micromapping is not an all-or-nothing affair. Just because one mapper has taken the time to convert a man_made=water_tower into an area does not mean we have to put everything down and convert all the water towers to areas. Introducing the option to map a mast area does not compel you to map new masts any differently than you currently do, but on the other hand it would give mappers more opportunities to add detail to the map.
I’ve never been clear on the difference between man_made=tower and man_made=communications_tower, but the documentation seems to clearly distinguish man_made=mast as a more “skeletal” structure, of the type that I’ve been mapping. The man_made=communications_tower documentation doesn’t say when to use a node versus an area, and that hasn’t been a major problem as far as I can tell. If we do need a guideline, it’s simply this: don’t downgrade a mast area to a mast node, but you may upgrade a mast node to a mast area as you see fit.
The status quo shows that the presence of these two options isn’t much of a problem for the software ecosystem. If you happen to be mapping these features because you use them in a particular way, please elaborate on your use case so we can make sure we accommodate it.
I’m not sure I follow what you mean by “intrinsic” here – the mast can be owned or operated by a different entity than each of the antennas on the mast. As far as I know, the GNIS feature IDs refer to the transmitters rather than the tower per se. Wikidata can have an item about any of these things; you would tag an item about a tower on the tower. Another detail you eliminated from the WCPO TV Tower was the various antenna heights, which I had tagged as height=* on each antenna node, in favor of the tower’s height. (Presumably height=* on man_made=antenna means how high it is, while height=* on man_made=mast means how tall it is.)
First off, the original mast/antenna data for the US imported from GNIS was of poor quality. At the time of the import, GNIS wasn’t doing a good job of managing records in the Tower feature class, so the source data was already out of date. In addition, GNIS classifies data differently than OSM does, so masts, towers, antennas, and a variety of other “tall” structures all got lumped into the Tower feature class. When this was imported into OSM, Tower records from GNIS were generally tagged as man_made=tower regardless of what they really referred to.
The result of those imports was that we got a lot of man_made=tower nodes stacked on top of each other, where some of the nodes should have referred to mast structures and some of them should have referred to the broadcast antennas.
Over time, those stacked nodes got merged, presumably by well-meaning mappers who heeded the validation warnings from editor software. That’s how we ended up with features like this:
That really should be man_made=mast but I don’t suppose anyone has considered the tag since the original import. And without doing the research into FCC records, I suspect that the list of broadcasters is substantially out of date. Researching the current data from the FCC and associating the broadcast antennas with physical structures is not simple. This is not a task for beginner mappers.
In addition, the feature above maps the mast structure and six different broadcast antennas all as a single node. This makes the feature a headache for data consumers and a beast to maintain.
Let’s say we wanted to tag some of the other common tags for broadcast antennas, like alt_name, callsign, city_served, fcc:facility_id, frequency, operator, wikidata, and wikipedia. With the feature above, that would mean that each of these tags becomes a list of values and correctly editing or interpreting these tags implies treating all the tags as rows in a table with the values as columns that each refer to a separate broadcast antenna.
I don’t know of anywhere that that interpretation of OSM data has been documented. Nor, I think, should it be because there’s some serious ambiguity about how it could be interpreted, particularly when you consider edge cases of missing values, tags with single values, or tags with multiple values that don’t match the table scheme (e.g., colour). That’s one reason we have the One feature, one element principle that @Minh_Nguyen cited above.
What would be better is if we were to map the mast structure and each antenna as a separate feature within OSM. Minh has proposed a way to do this by splitting the structure and antennas into individual features. That’s particularly important for large broadcast structures that host multiple broadcast antennas for separate broadcasters.
Let’s start there, with the premise that a mast with multiple broadcast antennas needs to be mapped as separate features for the sake of both data editors and data consumers.
Agreed. The example you provided is actually in a better state than most of these nodes are currently—it’s in the correct location, it’s clear that it is a communication facility of some sort (that currently or formerly broadcasted TV/radio signals), the potential operators are actually listed as operators (rather than names), and it has some information regarding its construction type. By my numbers, there are somewhere around 10,000 of these nodes remaining in some form.
And without doing the research into FCC records, I suspect that the list of broadcasters is substantially out of date. Researching the current data from the FCC and associating the broadcast antennas with physical structures is not simple. This is not a task for beginner mappers.
Absolutely. Some more things to consider here:
Although radio/TV operators need to be registered with the FCC to broadcast on each site, mobile operators (which operate significantly more communication masts than radio/TV operators, combined) do not need to. Unless you can do a site survey, it’s impossible to know which operator is actually on the site. And even if a site survey is done, unless you’re familiar with the equipment (or all the equipment is labeled, which isn’t necessarily all that likely), it may not be possible to identify the operator.
Even if a broadcaster (mobile/radio/TV) is no longer active, it’s not uncommon for the site to retain the abandoned antennas and base station equipment.
What would be better is if we were to map the mast structure and each antenna as a separate feature within OSM.
Again, agreed.
Minh has proposed a way to do this by splitting the structure and antennas into individual features. That’s particularly important for large broadcast structures that host multiple broadcast antennas for separate broadcasters.
In my opinion, this is already in practice by some importers and can be implied from the documentation (to some extent)—every communication mast should inherently have at least one related broadcast antenna. I fully support that concept, but I don’t believe it is what he is proposing.
What he is proposing is the ability to map communication masts—which in the vast majority of cases (a) correspond more closely with nodes in the real world and (b) are better handled as nodes in OSM—as areas based on some fringe showcased examples (that would probably be better handled by mapping under a different tag) and a number of incorrectly mapped sites.
I’m not at all surprised that there is already a sizable (although somewhat insignificant, in this case) number of incorrectly mapped sites, as we’ve all already laid out, and in my opinion, allowing mapping as an area adds significantly more ambiguity about how to map objects with a tag that is already a mess.
Moreover, crowding a whole bunch of antenna nodes around an object doesn’t resolve the main issue at hand and why the tag is a mess in the first place—editors finding it difficult to relate multiple broadcasters as separate objects on a single communication mast and, without sufficient documentation guiding them on how to handle the situation, combining nodes to simplify, as it (a) more closely resembles what can easily be observed (one communication mast) and (b) matches the documentation.
The documentation needs to be more clear as to the close but separate relationship between the physical structure and the broadcast equipment attached to it, suggest that it is common for there to be multiple broadcasters with separate equipment on a single mast, and then provide guidance on how to properly map that with some sort of relation (namely, the way @dieterdreist has proposed) rather than conflate for the sake of convenience and consistency (myself included).
It sounds like we’re in agreement that the structure and antennas should be mapped as separate features, at least in complex sites. (I’ve mapped mast and antenna as a single node for small, simple structures with a single antenna, and I guess that works OK.)
Let’s tackle the next bit. I’m going to stretch a little bit and say that any permanent physical structure can be mapped in OSM as a node, closed way, or multipolygon regardless of what the wiki says.
First off, the wiki is not a source of absolute truth. It’s just an attempt at documenting consensus on mapping practices. It’s often very good, but there are plenty of examples where it’s out of date, just plain wrong, or just one person’s opinion rather than community consensus. So, even if the wiki says something should be an area, mapping a feature as a node could still be acceptable and vice versa.
If you start with the premise that we’re mapping what’s on the ground, any permanent physical structure can be verifiably located and measured.
Sometimes those measurements aren’t so easy to come by. Some structures have a small footprint, and if you’re mapping from aerial imagery, sometimes the imagery isn’t so good. In those cases, maybe a node is the best you can do. And that’s just fine. Having a node with the information is much better than having nothing.
On the other hand, sometimes things that the wiki suggests should be mapped as nodes are much bigger in the real world and can easily be mapped as closed ways or multipolygons. If that’s the case, mapping them as areas is not just acceptable but better than mapping them as nodes.
So, when @Minh_Nguyen is proposing man_made=mast can be mapped as an area, that’s not much of a stretch. That makes perfect sense when the structure is big enough to be mapped that way. And it makes OSM that much richer to have the additional data to represent the geometry of the structure.
If my examples are on the fringe, then I’d be glad to carve out an exception for them and let that be the end of the story. Blaw-Knox’s diamond cantilever towers are somewhat rare. However, I was under the impression that triangular lattice towers aren’t terribly unusual in general. Are you finding that few are large enough to be able to discern their horizontal extent in aerial imagery? So far, I haven’t had much trouble finding lattice towers with footprints larger than a two-car garage or a water tower. I don’t know about the others here, but I’ve mapped plenty of garages, toolsheds, and water towers as areas without much problem. Maybe I’m just lucky enough to be mapping in areas where the imagery is high enough in resolution or skewed enough that I can clearly see the antennas that the FCC records indicate.
Especially if these types of towers turn out to be rare exceptions, I don’t see any harm in allowing them as areas under the same tag. I don’t think we can simply write off every mast area as inherently “incorrect” solely because a few mappers didn’t foresee them being mapped that way. Most values of man_made=* can be either a node or an area – even man_made=windpump, which rarely compares to even the smallest of masts. On the other hand, area:man_made=* occurs only twice globally, so there wouldn’t be much precedent for mapping a given mast as a node and simultaneously as an area.
Or is your suggestion to instead map a man_made=communications_tower whenever I have the compunction to map an area? I still don’t see a difference between the examples I’ve given and other masts, besides their size, but if others don’t disagree with using communications_tower for large masts, then I can switch to it. Looking around, I see that Sutro Tower is also a mast, but it’s tagged as both man_made=communications_tower and building=tower, apparently in order to detail it with 3D building parts. That’s too much micromapping even for me!
I wouldn’t mind integrating my approach with the node relations somehow, but if the structure is represented by an area, then do we attach all the node relations to a bare, tagless node? I guess my assumption was that a data consumer could already infer that the antenna is attached to the structure by virtue of the node falling within the mast area – just as a shop is presumed to be located within a building if its node lies within a building area. If we were concerned that man_made=mast areas would be too exotic for some data consumers, I can hardly imagine these same data consumers knowing what to do with a type=node relation.
I was just going to make the same point. Enclosure does establish a relationship between the mast area and the antenna nodes.
I’m not particularly set on this method of mapping masts and antennas. One of the downsides is that it uses some arbitrary spatial separation to keep the nodes from stacking on top of one another. In reality, the antennas might be mounted on different sides of the mast but that’s really hard to verify without a survey.
On the other hand, I have used this method to map broadcast sites and it works fine in practice. It really helps to keep all the information about the individual features separate.
That said, there might be other ways to do this. And this is a good place to have a discussion about the relative merits of possible approaches.
If you don’t mind taking a little detour in the discussion, AM broadcast antennas are an entirely different beast. Consider the KGB (AM) and KOGO (AM) facility.
The structures are not masts supporting antennas. The structures are the antennas. Or more properly, each of the structures is an antenna component.
When the site is broadcasting, each of the antenna components is transmitting the same signal, possibly at different amplitudes and with shifted phases. The resulting composite signal is shaped to radiate in a specific directional pattern.
AM signal propagation is different during daytime and nighttime due to atmospheric conditions, so the use of the antenna array differs between daytime and nighttime. You can see this in the relation roles where KGB uses only one of the antenna components during the daytime and uses all three components during nighttime.
Yes, and to be fair, I understand that this is less explicit than putting the tower tags on the same element or in the same relation as the antenna tags. In the past, this might’ve been a major downside, but these days, standard OSM tools such as Overpass, QLever, and GeoDesk should have no problem performing these spatial queries reasonably efficiently.
In my case, the spatial separation wasn’t completely arbitrary. These towers are located in an urban area that has high-resolution aerial imagery, which I could supplement with 360-degree street-level imagery and even some public-domain photos of the tower. I could see in aerial imagery the antennas mounted on the faces or corners of the tower. The FCC records include precise elevations; since these lattice towers have tapered sides, it isn’t a stretch to eyeball the horizontal positions based on the elevations.
In other words, a lot of things had to come together for me to be able to map the tower as I did. I can totally see this being impractical for a smaller, less well-known, untapered tower in a rural area, such as a communication tower behind a small-town fire station. A node-based representation makes plenty of sense for cases like that.
Even so, I think it’s worth considering whether it’s better to map multiple node relations onto a mast node or whether it’s better to map multiple stacked tower and antenna nodes that share a single site relation. In that sense, it ties into the debate about whether to map a fenced-in schoolyard as coincident ways or coincident multipolygon relations.
There are many tradeoffs. What a mapper finds discoverable may not be what a data consumer finds discoverable. Consistency between colocated mast relations and dedicated mast nodes may beget inconsistency between large mast areas and small mast nodes.
In my original post, I mentioned in passing that a site relation could represent an AM tower array. This is an obvious choice when each of the towers is small enough that it can only realistically be modeled as a node, as in WOR or KVVN. I think it could still be appropriate even if the masts are large enough to potentially be modeled as areas, as in WLW and KGB/KOGO. Your example is also nice because it demonstrates that the two stations must be represented as relations of some sort in order to occupy the same three towers simultaneously.
To me, if an AM broadcast site must be represented as a site relation, but an FM broadcast site may sometimes need nothing more than a node, there’s already enough heterogeneity that introducing an additional node relation type in some other cases may consign those cases to obscurity. Stacked nodes in a site relation would at least stick to well-established feature types.
