I did some quality checks for emergency=disaster_response and amenity=fire_station using this overpass-turbo query. It shows amenity=fire_station with a distance of less than 100 meters to each other.
In this case there is an amenity=fire_station mapped as an area and the building=* located on this area is also mapped as amenity=fire_station. So there is 2x amenity=fire_station for 1x a real world fire station.
In this cases there are two buildings on different sides of the road belonging to a single real world fire station. Both building=* have an amenity=fire_station. So again we have 2x amenity=fire_station for 1x a real world fire station.
one on-the-ground real world feature should be mapped with only one OSM element.
Somewhere I read that there is a local tagging practice that promotes using multiple amenity=fire_station for one real world fire station. I think it was a changeset discussion in Australia but I can’t find it anymore.
Is there something like this? Or should every real world fire station be represented by exactly one amenity=fire_station in OSM? What about emergency=disaster_response? (Or basically any other feature)
Is there any (local) consensus for violating the “One feature, one OSM element” in any situation? Or should I remove such dublicated tags if I have enough knowlege to do so without causing damage?
Does the “One feature, one OSM element”-principle always apply?
yes
no (explanation in comment)
unsure (explanation in comment)
0voters
(@Fizzie-DWG do you know something about such a local Australian consensus?)
It is interesting that the building in example 1 is mapped as building=yes, not building=fire_station, which is well documented and widely used. (It’s also interesting that the building doesn’t seem to match aerial images but I guess that’s a separate issue!)
Assuming the building is something that could be reasonably called a fire station (not just a random building that happens to be on the grounds), I think a more standard approach would be to tag it as building=fire_station and leave the amenity tag only on the grounds. But I am not familiar with Australian tagging practices.
The second example is more understandable, arguably the public road between the two parts could be seen as implying there are really two fire stations here. I guess it could be mapped as a site relation, or perhaps as an amenity=fire_station polygon with a public road running through it? I think it is fair to say that mapping of dispersed amenities in general is not entirely consistent in OSM - see many discussions along the lines of “is a university with multiple campuses a single element?”
Example 2 has the same name= . That can only be 1 amenity=fire_station , requiring a type=multipolygon .
It’s simply a common mistake to add amenity=fire_station to every building= inside, perhaps a technical form of Tagging For Renderer. Personally I would advocate only using building=fire_station for the archetypal “firehouse” structures with both fire trucks and other facilities inside. Other buildings should be what building= they are on their own.
This was partially contributed by iD preset amenity= + building= in the past, and only having building=fire_station from recent years Add Fire Station Building preset by arch0345 · Pull Request #603 · openstreetmap/id-tagging-schema · GitHub
First case is clear enough that I changed it in Changeset: 166119806 | OpenStreetMap (while also mapping it driveway, I assume that you cannot take shortcut through it)
