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?
- Option 1: Mapping the footprint of the structure:
- 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.