This is the key, I think.

By having a manageable number of feature tags, as expressed on the Map Features page, data users can make a reasonable initial selection of objects that may be relevant to their purpose. That can be useful even if they will later differentiate based on secondary tags. And for many data uses beyond rendering a map, that differentiation might not even be necessary.

Following from what I wrote above: it provides a way for data users to navigate through the map features, ignoring those that are irrelevant and focusing on a relatively narrow subset. If I’m analysing buildings or waterways or railway infrastructure, I can ignore any “tourism=” object right from the start. If I’m interested in tourist infrastructure in general, I need this object in my query. I can then look at secondary tags for detailed analysis. I might even decide that I don’t really want guideposts for my purposes, but it’s relatively easy to identify and discard exceptions within the “tourism=” category rather than starting with the entire OSM dataset.

To give an example from my own very small-scale use of OSM data: I run a few little queries to visualise changes in points of interest mapped in my local area. In that context, a newly added guidepost would be of interest to me. I start by downloading objects tagged as shop, craft, tourism, office, and amenity. I clearly can’t consider every possible OSM tag individually, so I just assume that anything outside those 5 features is irrelevant. Without the tourism tag, I wouldn’t even know if there are guideposts mapped in the area. This is a trivial example, but hopefully it gives an idea how main feature tags can be useful even if they appear redundant in some specific cases.

Also note that for many mappers this really doesn’t add any friction due to the use of presets. Search for “guidepost” in ID, for example, and it immediately populates both tags - it takes no more time than a single tag.

6 Likes