|Feature : Names|
|To provide details of the name for a feature included in OpenStreetMap.|
To provide details of the name for a feature included in OpenStreetMap.
|name||User defined||The common default name. (Notes:
|name:<lg>||User defined||Name in different language; e.g., name:fr=Londres. Note that all key variants below can use a language suffix. See: Multilingual names.|
|name:left, name:right||User defined||Used when a way has different names for different sides (e.g., a street that's forming the boundary between two municipalities).|
|int_name||User defined||International name (note: consider using language specific names instead; e.g., name:en=... - see above – International does not (necessarily) mean English).|
|loc_name||User defined||Local name.|
|nat_name||User defined||National name.|
|official_name||User defined||It has been created for country names but we need a clarification for other cases between "name", "int_name", "loc_name" and "official_name". Example: official_name=Principat d'Andorra (where "name" is name=Andorra).|
|old_name||User defined||Historical/old name.|
|reg_name||User defined||Regional name.|
|short_name||User defined||should be a recognizable, commonly used short version of the name, not a nick name (use alt_name for that), useful for searching (recognized by Nominatim).|
|sorting_name||User defined||name, used for correct sorting of names — This is only needed when sorting names cannot be based only on their orthography (using the Unicode Collation Algorithm with collation tables tailored by language and script, or when sorted lists of names are including names written in multiple languages and/or scripts) but requires ignoring some parts such as:
all of them being ignored at the primary sort level and not easily inferable by a preprocessing algorithm.
|alt_name||User defined||Alternative name by which the feature is known. If there is a name that does not fit in any of the above keys, alt_name can be used, e.g., name=Field Fare Road and alt_name=Fieldfare Road, or name=University Centre and alt_name=Grad Pad. In rare cases, the key is used for multiple semicolon-separated names, e.g. alt_name=name1;name2;name3, but this usage is not preferred.|
|Do not use this tag, suffixed name tagging for multiple values is deprecated.|
This table is a wiki template with a default description in English. Editable here.
Abbreviation (don't do it)
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). If the signs have abbreviated words and you don't know what the full word is, then use it temporarily until someone else completes it. Using short forms is a decision of software, i.e., the underlying data should have the full street name. This will allow a renderer, a router or a location finder to introduce abbreviations as necessary. See, for instance, the list of abbreviations used by Name Finder and Nominatim.
If the name is incorrect when spelled in full, however, do not falsely expand it. (For example: Wilts & Berks Canal, British placenames beginning with "St", Invalid abbreviation expansion) If modifying a name creates ambiguity (for instance, by local convention St. John's is in Terra Nova, while Saint John is in New Brunswick) it's best to keep the local usage intact.
The name "Cedar St" on a sign, which is abbreviated to save space, should be completed to Cedar Street, but the name John F. Kennedy Boulevard is not expanded to John Fitzgerald Kennedy Boulevard in English speaking countries, since the shorter version is the common spelling and pronunciation. With some (academic) titles in names the abbreviated version is also the most commonly spelled version.
Apart from following the above rules, you should always enter the full name as it appears on the street name signs but be aware that street signs may contain errors.
This guidance about abbreviations applies not only to street names but also street addresses in addr:street=*, which should generally match the names of the corresponding streets. (This example Sophox query shows how to find street addresses that incorrectly contain abbreviations in a specific language and geography.)
General recommendation is to use mixed 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 nonwithstanding 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.
- "no name" : (see #No name, below)
- "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.
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.
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.
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
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 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, 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 does include "Central Park" in the name, because "Central Park Tennis Center" is the tennis center's actual name.in New York City's is tagged with
By now the majority of rendering systems can deal with unicode characters, so you can use the local script for the default name tag. There is no need to use the Latin script.
See also Multilingual names
For adding localized names in different languages, add additional name:code=* tags with a suffix on the name key, where code is a language's ISO 639-1 alpha-2 code (in the second column), or ISO 639-2/T (alpha-3) code (technical/terminologic codes, including possibly codes for macrolanguages, but excepting codes allocated to group of languages, do not use bibliographic codes) if an ISO 639-1 code doesn't exist, or ISO 639-3 (alpha-3) codes otherwise; do not use ISO 639-5 codes allocated for language families. (The placement of a language within the differing ISO standards is sometimes misinterpreted as having something to do with the information about the language itself; however, this is not the case. Many widely spoken languages lack a two letter ISO 639-1 code, and some languages are poorly defined by these standards or not coded for altogether.)
For example, name:fr=* for the name in French and name:en=* for the name in English. The default name (occupying the 'name' tag without suffix) should be the name in whatever language is used locally.
Here is an example of the usage. All these tags might appear on the same element :
name=Irgendwas (the default name, used locally) name:en=Something (the name in English) name:el=Κάτι (the name in Greek) name:de=Irgendwas (the name in German) name:pl=Coś (the name in Polish) name:fr=Quelque chose (the name in French) name:es=Algo (the name in Spanish) name:it=Qualcosa (the name in Italian) name:ja=何か (the name in Japanese) name:ko=뭔가 (the name in Korean) name:ko-Latn=Mweonga (the name in Romanised Korean) (conforming to BCP 47 standard. Deprecated:
This leads to a more precise definition of alternative names.
Example of language codes according to the alpha-2 (= two-letter-)code of ISO 639-1 :
de German pl Polish el Greek en English es Spanish fa Persian fr French it Italian ja Japanese ko Korean ru Russian zh Chinese ko-Latn Romanised Korean (conforming to BCP 47 standard. Deprecated:
A short discussion on this language suffixes can be found on the discussion page.
Renderer support: Some rendering systems display these localised names. See Map Internationalization
Import: using osm2pgsql allows users to define new .style files which can include other language's name columns and bring them into the database. In order to render from these columns it is necessary to set up PostGIS views which present these columns as 'name' instead of 'name:languagecode'. An easier alternative might be to use a lua style file to move "name:XX" if it exists to "name". An example is seen in this diary.
Editor support: JOSM builds 1044 and newer support the display of local names. It detects the current system locale and tries to display names in this language first. You can change the order JOSM looks for names in the JOSM expert settings. Example: To display names written in Thai first, even if the current locale is 'en' set the following property:
Transliteration is the process of taking a name in one language, and simply changing letters from one script to another. In general we should avoid doing this with tags in the OpenStreetMap database. Everything with a name could have auto-generated transliterations, so not just city names, but every road, and every cafe! This kind of automatic augmenting with data is best left for data users. For example, Sven Geggus has demonstrated the principle of rendering with auto-generated transliterations. The German OpenStreetMap (Mapnik style) transliterates many scripts to Latin using OSM map l10n functions. We want to avoid adding in tags into our database for every named object via automated or semi-automated Import.
Instead we only put commonly used names in other languages into the database. While we typically think of these as translations, in most cases names that fit this criteria are not literal translations, example: the lake that the city of "Genève" ("Geneva" in English) lies on is in French, bordering "Lac Léman" in French (name also used in France that also borders the lake) or "Genfersee" in German. The default name has to be one of the local names: "Genève" for the city, "Lac Léman" or "Genfersee" for the lake. These are names which have been used by people on the ground, speaking in different languages (In general we're following Good practice#Map what's on the ground). Transliteration will fail to match the actual translations of names like these, hence this is useful data to add.
But for smaller towns or villages, there's no asserted translation and entering transliterations won't really be helpful. There are several transliteration methods and data users may have different needs. It's best to let users select the appropriate tools to perform these automated conversions. For example, small towns in England probably don't have a special Russian name, unless there is a local Russian community or a local authority publishes official translations of documents in other languages (using transliterations or prefered translations). Their names can all be transliterated into Russian script, but it's not a good idea to add lots and lots of tags to all the towns in England containing these transliterated names.
In addition, many transliterated names frequently have been imported as is from Wikipedia (or Wikidata) for naming their articles, but the names may have been chosen quite arbitrarily on these wikis. Importing these transliterated names into OSM is not necessary. We can just link to a single Wikidata entry or a single Wikipedia article in a single language, preferably the main language used locally, in order to find the other articles. (For example, this Sophox query returns the Chinese name of every regional capital city worldwide, regardless of whether a Chinese name is tagged in OSM. A more frivolous example is this table of place names in emoji, which aren't tagged at all in OSM.)
On the other hand, some countries which use an official local language not written in the Latin script (notably in China, India, and Arabic countries) are also providing their own official romanization that should be used and tagged with the appropriate tag for the target language code. In other words, always prefer local sources to any other international sources for transliterations (there's a separate tag int_name=* for the latter, which should be based on a wellknown international standard, e.g. IATA for airport names, otherwise use a geographic international transliteration standard scheme).
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 Russsian (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!
- display names in Polish
- in case of Polish name being unavailable, show English name (with "Beijing" being preferred over "北京市")
- otherwise display name:en=*
In such case the solution would be to
- display name:pl=* - skipped, as not present
- if it is unavailable display name:en=* - done!
- if both are not present display name=* - not reached
Alternative would be adding guesses about language of name=* (what is tricky, complicated for many languages and areas impossible, fragile and error-prone).
Or explicitly tagging both name=* and
Local names (loc_name)
loc_name=* is for the name of a feature as it is known locally, but only where this is deemed to be too much of a slang name or otherwise unofficial-sounding. Ordinarily though, the name which local people use is the name we set in the name=* tag! Examples where we have used loc_name=*:
- There is a bridge in Glasgow known as the Squinty Bridge, but its official name is the Clyde Arc. I have never heard anyone calling it that, so the bridge is tagged loc_name=Squinty Bridge name=Clyde Arc.
- In Reading there's Union Street, but it's been known for decades as Smelly Alley on account of the fishmongers that lined it. The loc_name=* is ideal.
Alternate names (alt_name)
Apply when an alternative name exists, e.g., a street name has different syntax, sometimes even on street signs, although it is not only for street names.
These alternative names are usually not rendered, but can be used by applications like Nominatim.
Sorting names (sorting_name)
sorting_name=* is a proposed approach to supply an alternate name which systems can use for the purpose of sorting alphabetically. This would be useful for street names in some languages/countries, particularly Russian, where words like "Street" are frequently used as a prefix. This is problematic if you simply sort on the main name=* tag.
- Inventing names for essentially unnamed private airstrips
- Tagging mailing list thread on name tags for internal features of a named area
- Central Park Tennis Center on the official Central Park website
- United States Postal Service Official Abbreviations, e.g., street-type abbreviations.
- Falsehoods programmers believe about geography