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.