Proposal process

From OpenStreetMap Wiki
Jump to navigation Jump to search
For lists of proposed features by status, see Category:Proposals by status.
For proposed icons for existing features, see Proposed Icons.

This page describes the proposal process, which is one of multiple ways to introduce and discuss new tags for features and properties. The other ways are often undocumented.

The proposal process was designed to let the OSM community discuss and vote on a standard way to tag map features. OpenStreetMap does not have any content restrictions on tags that can be assigned to Nodes, Ways or Areas. You can use any tags you like. However, there is benefit in agreeing on a recommended set of features and corresponding tags in order to create, interpret and display a common base map. It is also common to discover various issues during discussion - there may already be a way to map a given feature or it may be desirable to format the proposed tag differently to make it more clear.

Please note: The outcome of a proposal voting (including approval or deprecation of tags) does not have any implications for those tools which use and generate OSM data, such as the standard tile layer renderings or editor presets. Do not expect an approved proposal to be automatically rendered or added to presets; this is at the discretion of the stylesheet maintainers and code authors. Also, never use a vote result as a permission for large-scale re-tagging of existing objects. See automated Edits code of conduct for more about this topic.

This page is designed to assist anyone considering putting forward a tag proposal, with the aim of speeding the tag proposing process. It is not meant as a set of absolute rules, but as a guide.

Proposal list

All proposals are categorised by the status set in its Proposal Page template:

Before creating a proposal

Existing tags/proposals

Being a rejected feature does not necessarily mean it should not be proposed again: some proposals fail due to a poor definition, being ambiguous or lacking information to justify their significance, some items become more significant over time and thus more map-worthy.
  • Is there any other work not referenced on these pages? Perform a general search on the wiki, including related words.
  • When designing new tags, you can consult for example International Orienteering Federation's mapping specifications with their standard categories, IDs and descriptions, that might be of use; how are some users classifying their interests.

For example:

  • You want a tag for a racecourse; consider searching for "racing", "horse", etc.
  • You want a tag for a peninsula; consider searching for "headland", "point", etc.
  • You want a tag for a brewery; consider searching for "beer", "manufacturing", "alcohol", "industrial", "plant", "works", etc.

It might also be a good idea to send an email to the tagging mailing list, describe the feature you want to tag and see if there are tags in use but hard to find or not yet documented.


Is the tag you are considering for proposal, worthy of a new tag? Consider possible uses for the map, and specifically the data you want to add.

This is a difficult judgement to make: if you want to tag it, then that is generally reason enough to create a tag.

  • Is it a destination in itself?
    • People may search for some locations, for example: a national park, a bus station, a street address or a rubbish dump, because they want to visit that location.
  • How many of the item do you think there will be in the world?
    • For instance, you want to map an aero-engine factory - there are very few aero-engine factories in the world, so rather than creating a specific tag, this may be better served by using an existing man_made tag and specifying product=aero_engines.
  • How large is the item?
    • Large items can assist with navigation.
  • Is it useful for research/study?
    • A geography student may want to determine the total area of national parks in a given region.
    • A sociology student may want to map correlation between number/location of Porsche dealerships and houses greater than 600 m2 in area.
    • A history student may want to show the locations of all battles in a given war.
  • Does it assist in route-planning?
    • It is useful to know which junctions are traffic lights and which are roundabouts as this can affect journey times.
    • Truck drivers need to know the maximum height allowed under bridges, or the maximum weight allowed through population centres.
    • Traffic calming structures can affect journey times, routing software will generally not use roads with these on.
    • Walkers would want to know surfaces/conditions of walking tracks.

Compatibility with established practices

OpenStreetMap has some established good practices. Your proposal should follow those or at least explain why it does not do it. Please have a look at them.

Specifically relevant for proposals might be

Tags that are approved are usually features or properties that an individual mapper can confirm to be correct or false. A tag is verifiable if independent users would make the same observation.
This means that statistical properties (like peak vehicles per hour on a road) and subjective content (reviews, rankings) are not included in OpenStreetMap. Temporary, historic or speculative future developments are also excluded.
One feature, one OSM element
A single real world object should be represented with one element only.
Syntactic conventions for new tags
There are some conventions about naming keys and values. Following them will help mappers to estimate the meaning of your tags without reading the documentation. Using a semicolon should be considered especially carefully.

Skimming though Editing Standards and Conventions might be helpful as well. Please also consider the On the Ground Principle (about current versus old data), fixme=* (for estimations), and names (names versus descriptions, avoiding abbreviations) if any of them might conflict with your ideas.

Creating a proposal page

You can easily create a pre-formatted proposal here.

Read these instructions before creating the page.

  1. Create the page using the tool below. The tool does not immediatly create the page, but opens the editor for the page that will be created if saved.
  2. Making no edits, immediately save to convert the substituted values to text.
    Save proposal first.png
  3. Click on Edit in the upper-right heading.
  4. Click on the Proposal Page template at the top of the page and click edit. Then input the specific details of the proposal for each of the parameters.
    Edit proposal page template next.png
  5. Follow the instructions in the comments under each of the headings to draft the proposal documentation.

Create here:

If you edit using the Wikicode editor instead of the Visual Editor, what is displayed will be a bit different. Instructions still apply: (1) create page (2) save to generate text, (3) edit page to fill the template and save again.

If you have technical trouble with creating a proposal page, feel free to ask for help by sending a message to the tagging mailing list, you can ask for technical help also elsewhere.

Optionally let people know of your new proposal by subscribing to tagging mailing list and sending a mail.

Proposal page template

You may also create a proposal directly by copying and pasting into a new page

Create a new wiki page such as Proposed_features/your_proposition_name (MediaWiki Help:Starting a new page) and then fill in the proposal page template and page details described below. Set the status to Draft and set the draftStartDate=2021-01-15 value (YYYY-MM-DD):

Place the following wiki text at the top of the page, and fill in the brief summary content fields:

{{Proposal Page
|name           = {{subst:SUBPAGENAME}}
|user           = {{subst:REVISIONUSER}}
|key            = <!-- The key of the proposed new tag, if relevant -->
|value          = <!-- The value of the proposed new tag, if relevant -->
|type           = <!-- node, way, area, relation -->
|definition     = <!-- A short, clear definition of the feature or property which the new tag represents -->
|appearance     = <!-- A possible rendering, if relevant - optional -->
|status         = Draft
|draftStartDate = {{subst:#time: Y-m-d}}
|rfcStartDate   = <!-- Date the RFC email is sent to the Tagging list: YYYY-MM-DD -->
|voteStartDate  = <!-- Date voting will start: at least 2 weeks after RFC, YYY-MM-DD format -->
|voteEndDate    = <!-- Date voting will end: at least 2 weeks after start of voting, YYY-MM-DD format -->

== Proposal ==
<!-- A short statement of what you propose, including a list of what tag(s) are being proposed to be added, changed, or deprecated -->

<!-- Which Database Elements (nodes, ways, areas, relations) each of the tags can be used on could be included here or under the Tagging heading, or both. -->

==Rationale ==
<!-- Explanation of why the proposal is needed, and why you chose the specific key and value of the tag. Compare with similar tags or previous proposals, if relevant. Consider significance and potential uses of the data.-->

<!-- Keep the tag short while still being logical and descriptive enough to need little explanation. Avoid tag names which might cause confusion with a  different tag. British English terms are preferred, when possible -->

==Tagging ==
A table, list, or set of subheadings explaining each tag:
* Definition of the meaning of the tag and how it should be used
* Elements tagged: nodes, ways, areas or relations? [if a feature is smaller than 5m by 5m it would usually be mapped only as a node]
* Comparison with current tagging schemes (if applicable)
* Additional tags used in combination (including existing tags)
* When other tags should be used instead.

==Examples ==
<!-- Examples of what elements should be tagged: real-world images, screenshots, links to OpenStreetMap elements that use the proposed tagging. -->

<!-- Optional rendering suggestion, if relevant -->

==Features/Pages affected==
<!-- List of wiki pages that would be edited if the proposal is approved -->

==External discussions==
<!-- Links to mailing lists, other forums where this proposal has been discussed... -->

== Comments==
<!-- There must be at least 2 weeks set aside for comment on the proposal. Do not go to a vote without addressing the comments and fixing any problems with the proposal. The wiki talk page is used for comments, it is linked from the proposal page for those unfamiliar with wikis. -->

Please comment on the [[{{TALKPAGENAME}}|discussion page]].


  • Once the feature is fully described on its page, move on to Proposed Status.
  • You must subscribe the Tagging mailing list for the next steps. Do this before you write any email to this list.
  • Send out an RFC (Request For Comments) to the Tagging mailing list (tagging, “ат”
  • Subject: "Feature Proposal - RFC - (Feature Name)"
  • In the body: include a link to the proposal page on the wiki. Also copy the "definition" from that page and paste it in the mail.
  • Set the status to Proposed and set the rfcStartDate=2021-01-15 value. (YYYY-MM-DD)
  • Spend time with others discussing and modifying the proposal.
  • Please discuss each proposed feature on its own discussion page.


  • You still have to be subscribed to the Tagging mailing list for these steps.
  • At least two weeks after the RFC, and once problems brought up in discussion have been resolved by modifying the proposal, send out a Request for Voting to the tagging mailing list:
  • <Subject:> "Feature Proposal - Voting - (Feature Name)"
  • Set the status to status=Voting at the top of the page
  • Set the voting start date: like voteStartDate=2021-01-15.
  • Set the projected end date voteEndDate=2021-01-29 (usually 14 days after the start).
  • Add this to the bottom of the page:
== Voting ==
{{Proposed feature voting}}

<!-- Cheat sheet:
{{vote|yes}} OPTIONAL MESSAGE HERE --~~~~
{{vote|no}} YOUR REASONS HERE --~~~~
{{vote|abstain}} YOUR COMMENTS HERE --~~~~

Place your vote below, at the end of the list. -->
  • At this point there must be only one proposal on the page, which should not be changed anymore, so it's clear what is being voted on.
  • If you don't get enough votes/feedback after two weeks, the voting-period should be extended and you should send out a second mail to the list.
  • People should not just vote "oppose", they should give a reason for their proposal, and/or (preferably) suggestions.
  • If it becomes apparent during the voting period that the proposal is unlikely to be approved, it is acceptable to suspend the vote early so that the proposal can be re-worked.
  • A list of active votes can be found at Category:Proposals with "Voting" status.


  • If you have no time to do the cleanup after the voting has ended:
Mark the proposal status as status=Post-Vote.
(See Category:Proposals without post-vote cleanup for features needing clean-up. If you have a minute, pick up a broom and clean up!)
  • After the voting period, make a summary of the voting by filling out the parameters of the {{Proposed feature voting}} template:
{{Proposed feature voting
 | closed  = yes
 | yes     = 
 | no      = 
 | abstain = 
 | result  = approved/rejected
 | comment = 


If the proposal has found enough support, the status can be set to Approved.

A rule of thumb for "enough support" is 8 unanimous approval votes or at least 10 votes with more than 74 % approval, (a simple way of counting is that a minimum of 3 yes votes for every no vote is certainly sufficient[1]), but other factors may also be considered (such as whether a feature is already in use).
The explicit abstentions do not count as a vote (e.g. 10 vote "yes", 1 vote "no", 10 "abstain but have comments" would be approved), but all suggestions should be taken into account before a proposal is approved or rejected in order to resolve any deficiencies in the original proposal (if they exist).
Before you decide to reject a proposal because of lack of support, it may be worthwhile to send out a new vote request to the mailing list.
(Historic note: prior to March 2015, the standard for approval was 8 unanimous votes or a 50% majority if there were more than 15 votes. Older proposals are still considered "approved" if they met the standard in place at the time.)
(Historic note: meaning of abstain votes was clarified in 2020)

Clean up the proposal:

  • Do not move the proposal page!
  • Create the permanent feature description page:
  • A new page for the feature should be created and the relevant map features template (depending on whether it is a key, a value, or a relation) should be applied. Follow the standard set by the Key:highway key and its values.
  • Add a link back to the proposal by using the statuslink parameter of the feature template.
  • Add a link to the permanent feature page in the proposal page using Template:Approved feature link.
  • Archive the proposal using Template:Archived proposal.
  • Add the completed feature to the map feature page:
  • Add entry to Map Features page.
  • Do not remove entries from Map Features even if your new feature that has been voted on is intended to replace them. It is not considered good style to remove things from Map Features while they are still in use. You can remove things from Map Features if they are not in use. See also Deprecated features.


If the vote fails, the status can be set to Rejected.

  • Note any reasons why rejected on the feature proposal page.
  • Rejected features may be resubmitted, modified, and moved back to the RFC process.

Abandoned, Canceled, Obsoleted, Undefined

  • Proposals should be set to Abandoned if they have a long time of inactivity (at least 3 months) on the wiki pages (including all languages and discussion pages) and are also not added to the OSM database. A proposal that's unchanged in the wiki for a while might just be tested in daily mapping practice and thus may be very alive.
  • The person proposing a feature can cancel it by setting the status to Canceled.
  • For proposals that have been obsoleted by another proposal, set the status to Obsoleted.
  • For proposals with unknown status, set the status to Undefined.

Non proposed features

Non-proposed features are mapping features which did not undergo the proposal process.

Even if OSM has a completely free data model (that is, you don't need anyone's permission), we try to moderate the Map features list for several reasons:

  • landing page for newbies: so it has to be clear and self-explanatory in every language
  • avoid feature conflicts: during a vote all eyes can keep duplicates away
  • keep list/categories short: even a design decision, we want to avoid an uncontrolled explosion of features and keys

Generally, new keys should always be discussed before being added to Map features. To increase participation in discussion, especially for new values of major keys like highway=* it is a good idea to formally propose them. Any new tag which replaces an established tag requires also a proper discussion, proposal process is a good way to achieve this.

Reviving old proposals

There are many old proposals that never reached vote stage and where the original authors have abandoned them. What can be done by a new unrelated person interested in making identical or a similar proposal?

  • restart the old proposal - it is a good idea if you completely agree with it. Consider contacting the original author whenever it is OK for you to resurrect it - and wait some time for reply. Send it again to request for comment (RFC) stage and continue to proceed like with any other proposal.
  • make a new proposal reusing content from the old one. Simply create a new page, feel free to copy existing content (you are allowed to do this, just mention source of text in the changeset comment). Mention inspiration/source of the proposal, but feel free to make any changes to it that you want. And proceed like with any new proposal. You can also do this with your own proposals.


Proposal process wiki history

You can find the history for this page there (as usual).


  1. For example 26 yes votes and 9 no votes is 74.3% of support that is sufficient. "3 yes for 1 no" means that proposal achieved 75% support, while 74% is sufficient

Lists of proposals