This has always puzzled me. I see a guidepost out there, I want to map it. I find information=guidepost. All would be simple. Yet I am told to also add tourism=information. However, it is 100 % implied by the guidepost tag already. What is the use of it? The only thing I canthink of is to allow renderers that are not interested in details to show a general icon like this: for all nodes tagged with tourism=information. Given how different they are (from a painted sign to a visitor center), I would consider that extremely unhelpful. What do we get from having tourism=information?
Note that this is different from for example board_type=* where already information=board is specific enough for renderers to display something meaningful, yet the additional detail is useful. One can also see that only about 60 % of boards have board_type=*, so it is clearly useful to have just information=board on its own even if it is implied by board_type=*. But again, what does tourism=information bring?.
I think that’s exactly what it is (or maybe rather than not interested, more not yet supporting).
Quite often the top level tag is introduced first and gains support from mappers and then, perhaps a some time later, renderers.
Then someone says, “oh we should be more specific about this feature” so they introduce the secondary level tagging. This may take even more time to gain mapper support and even longer (if ever) to get support from renderers.
So, by keeping the primary tag, we allow renderers to fail gracefully. Even if they don’t support the secondary level tag, they can show something.
It may not be particularly useful for your example, but as a general tagging scheme, it makes sense.
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.
Yes, IMHO we would not have to add tourism=information because it does not add information (rather it will typically lead to misinformation when someone does not look at the “information” key but just on the first level tag). But then you will notice that the features will be disappearing from many maps, because of how the pipelines work: almost all maps filter the stuff they are interested in (whitelist) and as they are interested in optimizing the effort to do it, they usually filter by a few keys rather than by a list of hundreds of key-values, so even if they are interested in guideposts (aka they have a specific rule for information=guidepost), they might miss them if you omit tourism=information, which according to the current documentation should be guaranteed to be present.
Yeah, I get it that it is technical and it is sensible, it is just not obvious to somebody who does not really see into the technical internals of OSM at all:-).
I recently started a tagging proposal to make information a top-level tag. The idea is that many information features have nothing to do with tourism, and requiring tourism=information limits and dilutes the meaning of the tag.
for all nodes tagged with