I would like more detail about how that would work. I suspect that in many of these cases, the mapper genuinely intended to convey that the information point provides information relevant to tourists. The same would apply where there is a sub tag such as information=board without board:type. Often these types of board cover a mix of information for visitors including amenities, history, geography, routes etc and don’t easily fit under more specific tags. Unless I am missing something, current tags for maps and boards don’t provide a way to indicate this kind of generic tourist information. Previously I wouldn’t have seen this as a problem in my own mapping as I felt that tourist information was a kind of implied default under the tourism tag, with specific tagging for exceptions. It seems that would no longer be the case.
In summary: if a resurvey indicates that one of these points provides tourist information, how do we tag that?
I think this is a good proposal. As a data user, it’s a pain to have to query tourism=*, except for tourism=information except for tourism=information+information=office when wanting to fetch tourist attraction type objects. (And I wasn’t aware of information=visitor_centre which I should probably be including an exception for too.)
While there’s quite a lot of work to re-check the tourism=information objects that don’t currently have information=*, this can be done gradually. And arguably these object need checking and having additional tags added to clarify what they are regardless of this proposal.
I like the clarity about tourism=information_office and tourism=visitor_centre but beyond that, I am wary of elevating information to a “top-level” tag. information=yes sounds particularly strange to me, almost as if someone were to write amenity=yes. Clearly tourism=information which you want to deprecate carries a lot more information than information=yes which you want to introduce?
For what it’s worth, Nominatim is treating information as a top-level tag by now and it simply keeps tourism=information as the top-level tag, when information is missing.
Echoing @alan_gr, I do worry about the inherent shift of meaning in the proposal away from touristic information. waymarkedtrails has shown information=guidepost for ages and so far there wasn’t any need to filter because the wiki page so far was clear about the reference to hiking/cycling/etc. route signage. Opening up the tagging for signage in prisons and nuclear power plants would certainly be surprising for me as a data user.
What about the other way around? Here is that query for IE + UK. There are some oddities in it - for example this cycleway, this track and thisremoved:tourism=information (presumably before this scheme can be accepted someone would need to edit that so that it said removed:information=).
There are further problems with this. As well as removed:tourism mentioned above there are a bunch of other lifecycle tags used - have a look through this list. In addition, there are a bunch of other features that have an information tag; here are a couple and here are some more.
With the Lyke Wake Walk Stone, currently it has one “main tag”, and the person who tagged it that way would have had an expectation about what tag was most important (they deliberately tagged it as natural=stone but not tourism=information). If information is “promoted” there won’t be an easy way to fulfill that expectation.
Maybe information:for=tourist could be added to touristical information stuff instead of tourism=information. information:for=refugee is used a few times in Poland together with information=office. These offices also have a tourism=information tag; I am not sure if this makes sense, What shall become of them? tourism=information_office? office=*? (related wiki discussion)
With a key named as generically as information=*, I wonder how the key would evolve organically after this proposal. Without the implied link to tourism=*, presumably the kinds of values that will arise because of “any tags you like” will shift to being even less recreational than before. Maybe what we need is a more inclusive tagging scheme for informational signs and informational offices as such, building on the existing man_made=sign and office=* tags.
Are you still working on it? I know that you dropped it because you wished for more feedback but at some point you should stop waiting for them and start the voting already if feedback is slowing down or ceased to come.
waymarkedtrails has shown information=guidepost for ages and so far there wasn’t any need to filter because the wiki page so far was clear about the reference to hiking/cycling/etc. route signage. Opening up the tagging for signage in prisons and nuclear power plants would certainly be surprising for me as a data user.
Fair point, but I would say this is a general problem in OSM. Things like natural=tree, amenity=toilets, or highway=path aren’t confined to a specific type of map. Though one might not generally map toilets in a prison, but you definitely would when making a map for a refugee camp.
information is actually one of the few tags where this problem is well accounted for, with categorical tags like hiking=yes having over 350,000 uses on information= features to indicate to renderers that they should be included in hiking maps.
Thanks for bringing this up. You’re right that these would need to be updated as well. In my mind a change to a tag implies a change to its namespaced tags, but perhaps I should have been clearer.
Though if apps like Nominatim are already treating information as a top-level tag, this is already a problem, and information needs to be namespaced regardless if the proposal passes. There is plenty of precedent for mappers to add lifecycle prefixes to attributes of a feature, for example, disused:parking.
I’d be happy to perform these updates myself if there is interest.
This an interesting example. I think it’s pretty common in OSM to double-tag a top-level tag on features that match two things simultaneously (though perhaps not everyone agrees?). Most data consumers can handle such situations. I expect the mapper didn’t add tourism=information because they didn’t think this matched a place where people can get tourist information.
Without the implied link to tourism=*, presumably the kinds of values that will arise because of “any tags you like” will shift to being even less recreational than before.
My contention is that most mappers are using iD presets to add information tags and therefore aren’t really aware that there’s supposedly a connection to tourism. The goal of the proposal is to reflect this reality and to free the key from its artificial constraints. I think information could be a good home for a lot of signage types if the proposal passes, but I’m not prescribing specific values here.
I do tend to think that most signs should share a common tag (or at least key), and information=sign has about 4x the usage of man_made=sign.
Ideally, though for signs in general it’s already a bit of a lost cause. highway=traffic_sign is about twice as common as information=sign, and advertising=sign is about three times as common.
man_made=sign was an attempt to unify other kinds of signs that don’t clearly function as traffic signs or commercial advertising. The discussion that led to it focused very heavily on propaganda signs, which have a complicated relationship to information.
