Proposal:Top-level information tag
| Top-level information tag | |
|---|---|
| Proposal status: | Proposals without post-vote cleanup |
| Proposed by: | Quincylvania |
| Tagging: | information=*
|
| Applies to: | |
| Definition: | Any information-related feature. |
| Statistics: |
|
| Draft started: | 2024-10-07 |
| RFC start: | 2024-10-17 |
| Vote start: | 2025-09-30 00:00:00 (UTC) |
| Vote end: | 2025-10-13 23:59:59 (UTC) |
Proposal
information=* shall become a top-level tag defined as infrastructure intended to convey information. tourism=information shall be deprecated. The meaning of existing information=* tags shall remain the same except be broadened to include non-tourism uses. This tagging aligns with the manner the information=* key already tends to be used in practice.
Two tags that do not match other information=* values, information=office and information=visitor_centre, shall be reclassified as tourism=information_office and tourism=visitor_centre, respectively.
Rationale
tourism=information is by far the most-used value of tourism=*, a key which otherwise encompasses tourist attractions and lodging. Nearly all tourism=information features (96.99%) are tagged with the subtype tag information=*, which in practical terms means information=* alone is a fully-defined tag.
The vast majority of information=* values refer to a type of physical sign or marker. Just two common values go against this pattern: information=office and information=visitor_centre. If these two tags were reclassified under tourism=*, then information=* would be well-defined as a category for "physical infrastructure intended to convey information" while tourism=* would be well-defined as a category for "tourist attractions and amenities".
Expanding the scope of "information"
The desired benefit of a categorical key is to convey basic commonalities between all its values. One should be able to assume that all tourism=* features are of interest to tourists, including tourism=information.
But while information features are often useful to tourists, they also exist in areas where a tourism=* tag would be inappropriate. Places like prisons, shopping malls, office parks, college campuses, refugee camps, cemeteries, and factories are all likely to have signage. The information=* tag seems best-suited to these scenarios, but requiring tourism=information for non-tourist signage dilutes the meaning of the tourism=* key.
The diluted tourism=information tag
A mapper may currently ask, "how do I tag a guidepost in a power plant?" and realize there is no standard way to tag this. They can either use tourism=information + information=guidepost (even though it's not a tourism feature), make up some nonstandard tagging, or give up and not map the data.
Given this, it is likely that a large subset of mappers are not considering tourism at all when mapping information infrastructure features. iD (and all editors that use its tagging schema) allows people to use the following presets without indicating that they add a tourism=* tag:
- Information –
tourism=information - Guidepost –
tourism=information+information=guidepost - Trail Marker –
tourism=information+information=route_marker - Map –
tourism=information+information=map - Information Board –
tourism=information+information=board - Welcome Sign –
tourism=information+information=board+board_type=welcome_sign - Information Terminal –
tourism=information+information=terminal
Since so many mappers are relying on these preset names (and their translations) to decide how to map something, data consumers can't be sure that tourism=information actually refers to tourist features at all.
Existing top-level "information" usage
About 18,000 features already have an information=* tag without tourism=information, indicating that many mappers already treat information=* as a top-level tag. Of these, about 1,500 have a different tourism=* value, such as tourism=artwork, tourism=attraction, tourism=viewpoint, or simply tourism=yes. Dropping the tourism=information requirement makes this type of complex tagging possible.
Tagging
information=*is defined simply as a piece of infrastructure intended to convey information. It no longer requirestourism=information. It is not intended for use on shop-like facilities.- Use for things like: signs, maps, boards, route markers, guideposts, interactive displays, loudspeakers
- Do not use for things like: visitor centers, help desks, reception kiosks, tour guide offices, libraries, map stores
tourism=information_officereplacestourism=information+information=office- About 31,000 feature are affected as of September 2025.
tourism=visitor_centrereplacestourism=information+information=visitor_centre- About 900 feature are affected as of September 2025.
- Other
information=*values remain and keep their existing meanings, but are no longer assumed to relate to tourism. - New
information=*values may be invented for new types of features that convey information (when existing values are insufficient). information=yescan be used as a generic top-level tag for a feature that conveys information, but where the exact details are not known.- Using
tourism=informationalongsideinformation=*is discouraged. - The tag
tourism=informationalone is not deprecated nor endorsed by this proposal. Mappers can decide what to do with it.- As of September 2025, about 41,000 features are tagged
tourism=informationwithout aninformation=*value. This is likely due to the tag corresponding to the "Information" preset in iD. These features may need to be manually reviewed over time.
- As of September 2025, about 41,000 features are tagged
Rendering
Rendering remains unchanged, but renderers may need to be updated to expect the new tagging.
Features/Pages affected
- Key:tourism
- Tag:tourism=information
- All
information=*value pages
External discussions
Comments
Please comment on the discussion page.
Voting
- The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
Voting on this proposal has been closed.
It was rejected with 31 votes for, 16 votes against and 1 abstention.
5 extra "yes" votes not counted as they were after the end of voting period; but even with them the proposal didn't reach 75 % approval rate
I approve this proposal. --Quincylvania (talk) 20:12, 30 September 2025 (UTC)
I approve this proposal. Clear and concise. --ManuelB701 (talk) 20:32, 30 September 2025 (UTC)
I oppose this proposal. This fails to recognise the combinations of tags actually present in use in OSM at the moment. See https://community.openstreetmap.org/t/top-level-information-tag-proposal-final-request-for-feedback/127980/6 and https://community.openstreetmap.org/t/top-level-information-tag-proposal-final-request-for-feedback/127980/7 . Right now data consumers can expect a `tourism`, `removed:tourism` or similar tag and can treat the lack of one accordingly. The thinking behind this idea is just muddled. SomeoneElse (talk) 20:41, 30 September 2025 (UTC)
I approve this proposal.--GuardedBear (talk) 20:48, 30 September 2025 (UTC)
I approve this proposal.--Jacobwhall (talk) 21:00, 30 September 2025 (UTC)
I oppose this proposal. See @SomeoneElse: comment --Nospam2005 (talk) 21:04, 30 September 2025 (UTC)
I oppose this proposal. Not backward compatible - breaks existing applications --chris66 (talk) 21:23, 30 September 2025 (UTC)
- Some apps like Nominatim already treat information as a top-level tag. But yes, data consumers should expect that OSM tagging is always developing. Quincylvania (talk) 21:42, 30 September 2025 (UTC)
I approve this proposal. I agree with the reasoning in the Rationale section; promoting information to a top-level tag improves the interpretability of both tourism=*andinformation=*features in OSM, and reflects the way that these tags are already being used. — Jake Low (talk) 22:11, 30 September 2025 (UTC)
I have comments but abstain from voting on this proposal. While I agree that it is odd that a term as generic as information=*is reserved for a domain as specific astourism=*, I have reservations about introducing a tag that captures "infrastructure intended to convey information" because that is broad enough to cause conflicts with existing tags. For example, a well meaning mapper could tag amemorial=plaqueasinformation=plaque, even though we have an existing tagging scheme for plaques, because "plaques convey information." I could see the same argument being made over road signs, pavement markings, and even public art. The term information is also ambiguous enough to include both its medium (the infrastructure we're trying to tag) and the message (the information the infrastructure is trying to convey). I don't oppose the proposal because I think it is a good idea to decoupletourism=*andinformation=*(possibly by retiringtourism=information), and it seems like mappers already view these tags as decoupled. But a generic top-levelinformation=*seems like it can go in a lot of directions. --Malle Yeno (talk) 00:05, 1 October 2025 (UTC)
I approve this proposal. --Fizzie41 (talk) 02:24, 1 October 2025 (UTC)
I approve this proposal. It's important to decouple the two tags. I approve. --Morlark (talk) 03:40, 1 October 2025 (UTC)
I approve this proposal. Although it will require changes for data consumers, I think this is a positive change. In particular, I don't think the current system of tagging both tourism offices and tourist guideposts with the same top-level tourism=information makes much sense (they're very distinct types of object, so deserve different top-level values). Neither does having to tag non-tourist information objects with tourism=information. -- Rjw62 (talk) 07:51, 1 October 2025 (UTC)
I oppose this proposal. Regardless of the merits of the proposal itself, this will break every single map showing the affected objects. The tourist organisations running these are a core OSM user demographic and it is simply insane to propose any thing like this without a clear migration plan that addresses these users and gives them enough time as in (a year or two) to change. SimonPoole (talk) 14:40, 1 October 2025 (UTC)
I oppose this proposal. It breaks existing applications without much benefit to them and without compelling external reasons. Geonick (talk) 15:19, 1 October 2025 (UTC)
I approve this proposal. Yes, it's a breaking change, but it is occasionally necessary in order to fix broken tagging schemes. There shall be a plenty of time for data consumers to adapt, and broken tourism=information is not going to go away overnight. Duja (talk) 17:13, 1 October 2025 (UTC)
I approve this proposal. --Esmenard (talk) 17:47, 1 October 2025 (UTC)
I oppose this proposal. I like the idea behind this proposal, and agree that I've struggled with `tourism`-related tags not really being applicable to what I want to map. However, Malle Yeno and SomeoneElse both bring up points above that I think need to be addressed. See some potentially unaddressed concerns at https://community.openstreetmap.org/t/top-level-information-tag-proposal-final-request-for-feedback/127980/16 Thanks for the proposal though, keep up the good work! --Pwbriggs (talk) 00:26, 2 October 2025 (UTC)
I oppose this proposal. Besides all the unneeded breakage already mentioned (without any concrete plans outlined how to address them), I disagree with basic premise that One should be able to assume that all tourism=* features are of interest to tourists. It is just key name, and like all other keys it can never capture 100% of the cases without enumerating all its values you're interested in (e.g. highway=street_lampis not a type of highway! Nor does it even need to be near any highway!) For example,tourism=motelis at least as likely (or more) to be used by truck delivery drivers then tourists,tourism=museumortourism=zooortourism=picnic_siteetc. are very likely more used by locals etc. And many of the things that are very interesting to tourists are not intourism=*tag, likeshop=mobileoramenity=nightclub, and even those used almost exclusively by tourists are not insidetourism=*key (like e.g.amenity=bureau_de_change). Nor is it possible to fix, as every single thing practically always belongs to multiple categories. --mnalis (talk) 21:16, 2 October 2025 (UTC)
- Honestly, this answer. Tourism is simply a type of travelling leisure but it doesn't involve travel through half of the world (in other words, locals visiting local zoos are still doing touristy things) and conversely, other features use a top-level domain used by similar features because, well, they are similar to features (e.g. it makes no sense for a mobile phone shop to be
tourismbecause by the duck test, it's still clearly ashop). For the other,informationfeatures so much stuff which are non-tourisms related thing like maps and guideposts which help for the orientation even for non-leisure purposes that treatinginformation=*as top-level is more useful at the end (in other words, only fewinformationelements can be truly classified as a touristy thing likeinformation=boardwhich are primarily used for trivia but dragging the otherinformationtags along? Nah...). --ManuelB701 (talk) 19:59, 4 October 2025 (UTC)
- Honestly, this answer. Tourism is simply a type of travelling leisure but it doesn't involve travel through half of the world (in other words, locals visiting local zoos are still doing touristy things) and conversely, other features use a top-level domain used by similar features because, well, they are similar to features (e.g. it makes no sense for a mobile phone shop to be
I oppose this proposal. Agree with @SomeoneElse: comment --Nick Sokornov (talk) 18:57, 4 October 2025 (UTC)
I oppose this proposal. I think SomeoneElse says right things --Smollett (talk) 19:09, 4 October 2025 (UTC)
I approve this proposal. --FreeExec (talk) 07:56, 5 October 2025 (UTC)
I approve this proposal. Sound reasoning. It would make the tagging hierarchy better represent a more objective mapping process. I welcome this in principle with a suitably-communicated and well-design auto-edit procedure. --Mstrbrid (talk) 10:01, 5 October 2025 (UTC)
I approve this proposal.--Kuba743 (talk) 12:26, 5 October 2025 (UTC)
I approve this proposal. --Ravlop (talk) 13:26, 5 October 2025 (UTC)
I oppose this proposal. Mapping in a very touristic region, current tagging very consistently applied, deprecation/discouraging will create a mess. Rather find a top level tag for what now does not have one? --Hungerburg (talk) 13:29, 5 October 2025 (UTC)
I oppose this proposal. --Söm4324 (talk) 14:00, 5 October 2025 (UTC)
I approve this proposal. --Caboulot (talk) 14:09, 5 October 2025 (UTC)
I approve this proposal. --JB (talk) 14:17, 5 October 2025 (UTC)
I approve this proposal. Information is clear enough, no need for tourism=information. --Ilias (talk) 15:57, 5 October 2025 (UTC)
I oppose this proposal. See @SomeoneElse: @SimonPoole: and comment --streckenkundler (talk) 21:04, 30 September 2025 (UTC)
I approve this proposal. this was a very needed option to get out from the only rendering tourism=information --JLZ (talk) 17:24, 5 October 2025 (UTC)
I approve this proposal.</nowiki> --Benoitdd (talk) 18:47, 5 October 2025 (UTC)
I approve this proposal. --Timmy_Tesseract (talk) 19:48, 5 October 2025 (UTC)
I approve this proposal. --Olr (talk) 21:54, 5 October 2025 (UTC)
I oppose this proposal. I agree with @SomeoneElse: comment --Murcik (talk) 22:31, 5 October 2025 (UTC)
I approve this proposal. This proposal simplifies tagging (features require fewer tags) regardless of the semantics of 'tourism'. --JeroenvanderGun (talk) 14:58, 6 October 2025 (UTC)
I approve this proposal. Simpler and more accurate. Current exceptions can be fixed. And consumers can have a grace period. --HellMap (talk) 18:51, 6 October 2025 (UTC)
- The proposal contains no such grace period and we can fully expect busy mappers to immediately starting to mass retag the objects, based on the terms of the proposal you are saying yes to. SimonPoole (talk)
I oppose this proposal. I like the improvements made possible by the proposal, but the unclear description of what's supposed to happen with so many existing tagging: grace period, coordinated effort through a MapRoulette, or other means to update existing tagging to be compliant with the new, this makes me say no (for now) please update the proposal to clarify what should happen with all the tags that aren't compliant to the new tagging scheme. --Hike&Map (talk) 03:57, 7 October 2025 (UTC)
I approve this proposal. --R2d (talk) 12:07, 7 October 2025 (UTC)
I approve this proposal. --Adamfranco (talk) 14:03, 8 October 2025 (UTC)
I oppose this proposal. Quite like Hike&Map, I feel like this lacks a clear migration path. --H@mlet (talk) 16:37, 8 October 2025 (UTC)
I approve this proposal. --AndreaDp271 (talk) 21:05, 8 October 2025 (UTC)
I oppose this proposal. Tag names are just mnemonics. Users of OSM-based products should never deal with such names directly. UI should use more human-readable and localized text for object names. Only OSM-programmers and mappers see its. Moreover, mappers with high-level editor (such Street Complete) could never see tag names. --Wowik (talk) 07:32, 9 October 2025 (UTC)
I approve this proposal. --Britzz (talk) 18:30, 10 October 2025 (UTC)
I approve this proposal. --Lenny (talk) 12:19 11 October 2025 (UTC)
I approve this proposal. The proposal is good; that way I can properly map information buildings for towns that aren’t tourist-oriented or for micromapping. --Kanpaidaisuki (talk) 18:43, 12 October 2025 (UTC)
I approve this proposal. --Emvee (talk) 06:22, 13 October 2025 (UTC)
I approve this proposal. --Hervé TUC (talk) 14:37, 13 October 2025 (UTC)
I approve this proposal. The overwhelming majority of tourism=informationnodes without an information tag are functionally meaningless. --Dschep (talk) 13:19, 14 October 2025 (UTC)
I approve this proposal. --TheBlackMan (talk) 14:56, 16 October 2025 (UTC)
I approve this proposal. --Babouche Verte (talk) 03:08, 1 November 2025 (UTC)
I approve this proposal. This proposal is not perfect but it is one step forward for a better system. — Computae (talk) 10:41, 2 November 2025 (UTC)
I approve this proposal. --Giopera (talk) 16:20, 4 November 2025 (UTC)
- The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.