How many amenity=fire_station should be used for every fire station?

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.

  1. I stumbled across situations like these:


    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.

  2. Then there are situations like these:


    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.

  3. A different situation would be this:


    Here we have two amenity=fire_station next to each other representing (at least as far as I know) two independent real world fire stations.

For my understanding the first two cases violate the “One feature, one OSM element”-principle:

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)
0 voters

(@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?”

1 Like

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

4 Likes

no, there are exceptions - but none applies here (so I have not voted as neither answer applies), but for cases like shown “yes” is closest

if area is mapped as fire station then repeating it on this building is a clear duplicate

multipolygon (with buildings lines as outers, of with two outers larger than buildings) or area if road between them is also part of fire station

then these are two different features, so “One feature, one OSM element” is irrelevant

I agree

yes

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)

4 Likes

TBMK, they are usually mapped as an amenity=fire_station for the area of the grounds, together with a building=fire_station/s.

The name should only be on one or the other though, not both.

2 Likes