Names

Abbreviation (don't do it)

Main article: Abbreviations

If the name can be spelled without an abbreviation, then don't abbreviate it. Computers can easily shorten words, but not the other way (St. could be Street or Saint).

Uppercase characters

General recommendation is to use title case with the first letter of each word capitalised (e.g., Church Street, not Church street) but regional rules have preference over general rules. For example, in Flemish, capitalisation of last names gives a hint about the nobility status of the person. Street or company names derived from those last names should copy the same capitalisation. In non-Latin based languages, it's often not even possible to capitalise a name.

Watch out for apostrophes

If the street sign has an apostrophe, the OSM data should have an apostrophe. There is no obvious consistency; the London Underground station Barons Court is adjacent to Earl's Court, one with an apostrophe, one without.

Name is the name only

The names should be restricted to the name of the item in question only and should not include additional information not contained in the official name such as categories, types, descriptions, addresses, refs, or notes. However - if something has the official name "East 110th Street" this full name should be in the name notwithstanding the fact that the "street", the "110" and "east" might be deducible from some other information. If something really doesn't have a name, don't add a name to OpenStreetMap. Any additional information should be included in separate tags (see, e.g., aforementioned links) to identify its meaning.

Some examples of incorrect usage:

• "Multipolygon Baldo Forest" : do not include the object type or other OSM terminology, if it does not apply outside of OSM
• "The Royal Albert Hall, London" : do not otherwise include the location London as part of the name, even if there are multiple objects of the same name
• "closed pub (due for demolition)" : do not describe the object in lieu of a name. Consider the description tag and also adding an old_name tag. No longer existing objects should be deleted. Disused objects such as shops can be tagged with lifecycle prefixes. See also nonexistent features page for more info.
• "no name" : (see #No name, below)
• "Football pitch" : this describes the feature, and is likely not the actual name. Instead make sure to use sport=soccer (the same for other sport pitches).
• "Interstate 5 southbound lanes" : do not separately name parts of the same object where they are separate in OSM, but not outside of OSM.
• "Interstate 5" : When a name would only be duplicating the information in the ref=* tag, then the ref and noname=yes is almost always more appropriate.
• "Wildwood Boardwalk (seasonal)" : Do not include time-related access restrictions in the name. Instead, use conditional restrictions tags (or opening_hours=* for non-highways). example: access:conditional=no @ (Nov-Apr)
• "Manchester City" : (for a city named Manchester, do not add a descriptive City; however note that New York City may be correct as the common name for The City of New York)
• "Foobar Mountain, 8000 ft" : tag height in a separate tag (like ele=* or ele:ft=*), not as part of the name
• "Lower Hell Hole 1030-002 Dam" : do not embed a reference number in a name just because a source (here USGS GNIS) does so; use a separate ref=* tag, for example, name=Lower Hell Hole Dam and ref:gnis=1030-002
• "Union Pacific Railroad" : a name=* which was assigned during the USA's 2007-8 TIGER import (of roads and rail); the correct value is the name of the Subdivision/Branch/Line and this railroad name is properly the value of operator=* and/or owner=* (there are many other incorrect values besides Union Pacific). It is OK to precede a railroad name with an operator when two or more otherwise-identically named lines in close proximity would create serious confusion. For example, naming "CN Joliet Subdivision" and "UP Joliet Subdivision" or "BNSF Fort Worth Subdivision" and "UP Fort Worth Subdivision" is sensible. (For now. Even this convention may disappear in the future as operator=* and owner=* become more widespread and avoid such ambiguities).
• "alternate summit trail" describing role of part of hiking route. For signed routes, you can use roles for recreational route relations

It is certainly wrong for a mapper to invent a name for an airstrip; however most names were invented at some point in history, so if someone invents a name and it catches on and a sizeable group of people refer to the thing by that name, then it's ok to be mapped^[1].

No name

Streets which have no name are tagged noname=yes by most mappers. The idea is to clearly indicate that the street genuinely doesn't have a name. Absence of a name tag is increasingly used to indicate areas which need to be surveyed still.

Left and right names

For way objects, names can differ by side of the object.

For example, a street may be on the boundary between Belgium and the Netherlands, Belgium gives it the name "Amsterdamsestraat" and the Netherlands gives it the name "Brusselsestraat".

This is solved by using the name:left=* and name:right=* tags to name both sides separately (using the direction of the way to determine left and right) . The name=* tag can still include both names in order to support different tools.

Example:

• name:left=Amsterdamsestraat
• name:right=Brusselsestraat
• name=Amsterdamsestraat - Brusselsestraat

note: different left-and-right names doesn't exclude the existence of multilingual names (which also happens more often on country borders). So tags like name:left:fr=* are possible.

Multiple names

If you have multiple names for a feature, first try to choose a rich semantic tag like any of the ones in the table (like short_name=*, old_name=* etc.). If none of them works, choose the alt_name=* tag. If there are multiple names that do not fit, alt_name=* can be used with semicolons.

Names are not for descriptions

For descriptions please use description=* not the name=*.

While it is welcome to tag building=house, it is wrong to add also name=house. Or name=Mosque to amenity=place_of_worship + religion=muslim. Validators may detect and propose to remove the most obvious and common incorrect descriptive names, but undetected ones also are incorrect. This is a form of tagging for the renderer.

Though note that some lakes are actually named "The Lake", in such case adding it as a name is fine.

Do not construct names for features^[2] by combining the name of an enclosing feature with a description. For example, an unnamed fountain in XYZ Park should not be tagged with name=XYZ Park Fountain. Internal features to a named area should only be tagged with a name when they have a commonly-used local name, or some other indication (such as signage) of the feature's name. If the internal feature is named, it should still not be combined with the enclosing area's name. A feature named 'Smith Fountain' within 'XYZ Park' should be tagged name=Smith Fountain but not name=XYZ Park Smith Fountain.

For example, The Lake The Lake in New York City's Central Park Central Park is tagged with name=The Lake and not a constructed name like "Central Park Lake". However, actual names referencing location of object are fine, as long it is actual name. For example the Central Park Tennis Center Central Park Tennis Center does include "Central Park" in the name, because "Central Park Tennis Center" is the tennis center's actual name^[3].

Despite this principle, historically, public transit route relations were expected to have name=* set to a description of the route in a rigid format.

Transliteration

Transliteration is the process of taking a name in one language, and changing letters from one script to another. For some languages, this is necessary, particularly those which have multiple orthographies, such as Punjabi or Serbian. Some languages which are typically tagged separately necessarily have a transliterative relationship with one another in most cases; for example, Hindi and Urdu do not differ grammatically or phonetically and tend to contain the same strings in the Devanagari and Perso-Arabic scripts respectively. In most cases, it is not possible to transliterate automatically, so it is advisable to add and review these manually.

Some countries which use an official local language not written in the Latin script (notably in India, Arabic countries, and CJK character using region) have official Romanization or other transliteration schemes which may be tagged with the appropriate tag for the target language code.

Language-specific names

name=* contains the common, default name in the local language. name:<lang_code> is used to tag the name in a specified language in cases where the name differs by language, for example name:ru=Москва gives the city's name in Russian (language code ru) while name:en=Moscow gives the English language name (language code en).

In cases where multiple languages are tagged for a name, the local-language name tag should be duplicated with the language-specific sub-key. For example, Moscow is tagged with name=Москва, with the same value as name:ru=Москва. This tagging is important because it ensures that data consumers don't need to infer the local language. Guessing name language based on location is unlikely to always succeed - there are places in Russia where name=* is not in Russian, there are places in USA where correctly mapped name=* is not in English.

On the other hand, do not tag names that do not exist. An unremarkable village somewhere in Poland might have only one name (recorded in name=*). In all other languages, this village would be called by its Polish name, because it has no other name. Just because all other languages use the Polish name, you should not add name:<lang_code> tags for all other languages containing the Polish name!