Proposal process

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

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

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:

• 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

Before creating a proposal

Existing tags/proposals

• Does your proposed tag already exist? check the Map features page.
• Is it already a proposal in progress? check the Proposed features page and the Abandoned feature list.
• Has it been proposed before and rejected? check the Rejected features page.

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.

Significance

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 type=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 m² 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.

Creating a proposal page

Create a new wiki page named like 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=* value (YYYY-MM-DD).

Proposal Page Template

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

{{Proposal_Page
|name           = 
|user           = 
|key            = 
|value          = 
|type           = 
|definition     = 
|appearance     = 
|status         = 
|draftStartDate = 
|rfcStartDate   = 
|voteStartDate  = 
|voteEndDate    = 
}}

This will bring in the wiki template Template:Proposal_Page which displays a green box with summary details on the top right of the page. Use 'Show preview' to check how it looks. After the closing '}}' characters you should begin the main content with proposal details as follows.

Page details

In general: be verbose. The more information you can include, the better. Photos, descriptions, situations, examples. Anything to create a well-defined image in people's mind.

More specifically: this list is a starting point for items you may want to consider putting in your proposal:

Proposal

A short description of what you want to map, including links to relevant material with photos if possible.

Rationale

Why the tag is needed, considering significance and potential uses of the data.

Examples

Names, locations, rough idea of numbers (e.g., one on every street corner, several in each suburb in Germany, half a dozen in each South American country).

Tagging

The category the tag falls under (man_made, waterway, tourism, etc,), with a justification of why other similar categories are not suitable (for instance, there may be too many to map individually - such as residential properties in which case a landuse tag would be of more use if they are grouped closely enough?).

The name of the tag itself - keep it as short as possible (15 characters is generally as long as they get), whilst still being logical, descriptive enough to need little explanation and not overlapping with another tag in a different category.

Other significant tags to describe specific instances of the item (e.g., author for a work of art, contents for a pipeline, etc.).

Generic tags that are re-used extensively (e.g., name, operator, access, etc.).

Applies to

nodes, ways or areas; when considering nodes vs areas: generally, if an item is smaller than 5 m by 5 m, it would not be mapped as an area, but as a node.

Rendering

not a part of the proposals process as such, but hints for the renderer maintainer will help them out. maybe a description of an icon (refer Map Icons), or an example mock-up.

Features/Pages affected

What keys/tags and Wiki pages might this proposal affect if approved?

Comments

there must be a time set aside for other people to comment on the proposal, do not go straight to a vote. Usually the wiki talk page is used for comments, but you might want to explicitly link it from the proposal page for those unfamiliar with wikis.

Let people know of your new proposal by sending a mail to the tagging mailing list, not the talk list.

Proposed

• Once the feature is fully described on its page, move on to "Proposed" Status.
• Subscribe to tagging@openstreetmap.org mailing list[1] and send out an RFC (Request For Comments) on this list:

• 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

• 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.
• A list of active votes can be found at Category:Proposed features "Voting".

Post-vote

• If you have no time to do the cleanup after the voting has ended:

• 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!)

Approved or rejected

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

• Note 2015-03-18: it is currently being discussed that this rule of thumb be changed to 8 unanimous approval votes or at least 10 votes with more than 74 % approval.

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.

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

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

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

Proposal process wiki history

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