Proposed features

Help

Available languages

• Deutsch • English • français • 日本語 • русский

Other languages — Help us translating this wiki

• Afrikaans • አማርኛ • العربية • অসমীয়া • asturianu • azərbaycanca • български • বাংলা • brezhoneg • bosanski • català • corsu • česky • dansk • Zazaki • ދިވެހިބަސް • Ελληνικά • Esperanto • español • eesti • euskara • فارسی • suomi • Frysk • Gaeilge • Kréyòl gwadloupéyen • Gàidhlig • galego • Alemannisch • ગુજરાતી • هَوُسَ • עברית • हिन्दी • hrvatski • Kreyòl ayisyen • magyar • Հայերեն • interlingua • Bahasa Indonesia • Igbo • íslenska • italiano • Basa Jawa • ქართული • қазақша • ភាសាខ្មែរ • ಕನ್ನಡ • 한국어 • Kurdî • Lëtzebuergesch • ລາວ • lietuvių • latviešu • Malagasy • македонски • മലയാളം • मराठी • Bahasa Melayu • Malti • မြန်မာဘာသာ • नेपाली • Nederlands • ‪norsk (nynorsk)‬ • ‪norsk (bokmål)‬ • occitan • Oromoo • ଓଡ଼ିଆ • ਪੰਜਾਬੀ • polski • پښتو • português • português do Brasil • română • română (Moldova) • سنڌي • සිංහල • slovenčina • slovenščina • Soomaaliga • shqip • српски / srpski • svenska • தமிழ் • తెలుగు • тоҷикӣ • ไทย • Türkçe • українська • اردو • oʻzbekcha • Tiếng Việt • Wolof • isiXhosa • Yorùbá • ‪中文（简体）‬ • ‪中文（繁體）‬ • isiZulu

This page describes the proposal process, which is one of multiple ways to introduce and discuss new features. 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.

Please note: The approval, or otherwise, of a proposal means does not have any implications for those tools which use and generate OSM data, such as the Mapnik 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 justification for large-scale re-tagging of existing objects.

For proposal and status help, refer to proposed features status guidelines.

Proposed icons for existing features are on the Proposed Icons page.

Proposal list

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

• All proposals
  • Proposals under way
    • Status Draft
    • Status Proposed
    • Status Voting
    • Status Post-Vote
  • Active proposals
    • Status Approved
  • Inactive proposals
    • Status Undefined
    • Status Abandoned
    • Status Canceled
    • Status Obsoleted
    • Status Rejected

Creating a proposal

See Creating a proposal

There have been a large number of proposals created, that are seriously lacking in detail. This page details a 'suggested' process to go through when creating a proposal; it is by no means exhaustive, or meant to be blindly followed without consideration.

See also Relations for proposed relations grouping together ways and nodes, with their own tags and values.

Proposal status process

Draft

See List of Drafts

• Use the Template to create your proposal. Set the status to "Draft" and set the draftStartDate=* value. (YYYY-MM-DD).
• Place your proposal in the correct category.
• Create the proposal Page. Creating a proposal
• Once the feature is fully described on its page, move on to "Proposed" Status.

Proposed

See List of Proposed

• Send out an RFC (Request For Comments) to tagging@openstreetmap.org mailing list[1].

• Subject Line: "Feature Proposal - RFC - (Feature Name)"

• Set the status to "Proposed" and set the rfcStartDate=* value. (YYYY-MM-DD)
• Spend time with others discussing and modifying the proposal.

• Please discuss each proposed feature on its own discussion page.

Voting

See List of Voting

• 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 tagging@openstreetmap.org mailing list[2].

• Subject Line: "Feature Proposal - Voting - (Feature Name)"

• Set the status=Voting, voteStartDate=<today> and voteEndDate=<today +14>. (Always use the date-format YYYY-MM-DD)
• 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 perhaps you should send out a second mail to the list
  • Don't just vote "oppose". Give a reason/suggestions why you oppose the proposal. All suggestions should be taken into account before a proposal is approved or rejected.

Approved or rejected

• At the end of the voting period, if the proposal has found enough support, the status can be set to "Approved" and the feature may be promoted to Post-vote clean-up.

A rule of thumb for "enough support" is 8 unanimous approval votes or 15 total votes with a majority approval, but other factors may also be considered (such as whether a feature is already in use).

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[3].

• If the vote fails, the status can be set to "Rejected" and you should do the Post-vote clean-up.

• Any proposals that have a 3 month inactive history should be set to "Abandoned" and the table-entry should be moved to Abandoned_features.
  • No !, an inactive proposal doesn't mean automatically that the tag is bad or completely abandoned, it just means that the proposal didn't go to the end of the process and is not being currently worked on. Many tags with the status 'abandoned' are used daily in OSM.

Post-vote clean-up

• If you have no time to do the cleanup

• Mark the proposal status as "Post-Vote"

(See Category:Post-vote_clean-up for features needing clean-up. If you have a minute, pick up a broom and clean up!)

• For features approved by vote:

• Clean up the proposal:

• Do NOT move the proposal page!
• Add the feature to the listing on the Approved features page using the template.
• Remove the feature from the listing on the Proposed features 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 Proposal in a "See Also" section.
• Add a link to the permanent feature page in the proposal page using the Template:Approved feature link: {{Approved feature link|link=*|name=*}}

• 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.

• For rejected features:

• Note any reasons why rejected on the feature proposal page.
• Add the feature to the listing on the Rejected features page, using the template (see the existing entries for an example).
• Remove the template entry for the feature from the listing on the Proposed features page.
• Rejected features may be resubmitted, modified, and moved back to the RFC process.

Non proposed features

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

If you find bad features, feel free to mark them using Template:Key_stub, Template:Tag_stub or any other Wiki labels