From OpenStreetMap Wiki
Jump to navigation Jump to search
This is the talk page for discussing improvements to the Names article and its related topics.

Country/Language specific extension of name tag

(See also Multilingual names for a discussion on the same issue.)

On Iran/Tagging rules#Naming, I see the proposal to use the key name:fa for street names in Persian (fa is the ISO 639 alpha-2 code for Persian).

In countries like Belgium and Switzerland, they have similar issues, that you would want to note down a street name in several languages.

Maybe it is time to work on a proposal to extend the use of the name tag, for example like this:

name=Irgendwas        (the default name, used locally)
name:en=Something     (the name in English)
name:de=Irgendwas     (the name in German)
name:fr=Quelque chose (the name in French)
name:es=Algo          (the name in Spanish)

My hope is that this extension would lead to a more precise definition of alternative names.

Example of language codes according to the alpha-2 code of ISO 639-1:

de  German
en  English
es  Spanish
fa  Persian
fr  French
it  Italian
zh  Chinese
be  Belarusian
The main problem I see here is that it's hard to decide which is the default name. This is very controversial. Also, renderers tend not to be able to handle non-Latin scripts well enough, which will result in undreadable maps for many parts of the world (most of Asia, for example). The reason we use name for the English name and name:fa for the local name is exactly that: we can't assume a rendered can handle the text in the form preferred by the native speakers. Even if they could, we would make the maps unusable to the whole world if we use the Persian names for Tehran! Worst than that, think about Indians using their native names on streets in their state, which will simply result in the map being unusable to Indians from other part of the country, as they can't even read the script probably! Roozbeh 14:28, 1 March 2007 (UTC)
Personally, I would use name=* for the name of a feature in the local language, and name:en=* for the English name. Where I live (Scotland), the default language is English even though a lot of place names in the highlands have a Gaelic Name. I have started adding name:gd=* for Gaelic names of places, where the name=* holds the English name. Bruce89 14:49, 1 March 2007 (UTC)

alpha-2 or alpha-3 ?

Is it a good idea to use the alpha-2 code or should we use the alpha-3 code, which supports more languages?

As the codes are easily distinguishable, we could actually use both in parallel, without any collision.
I don't think so. Using both in parallel makes choosing hard. Also, the alpha-3 codes are not unique (there are sometimes two alpha-3 codes for one language). The standard used almost everywhere is use alpha-2 when it exists, but alpha-3 when not. It happens that there is only one alpha-3 tag for each language that doesn't have an alpha-2 tag, so the uniqueness problem goes away. Roozbeh 14:28, 1 March 2007 (UTC)

Use this extension for other keys as well?

Are there any other keys that could use this extension as well?

The "wikipedia" key perhaps. But again, it would create the problem of having to maintain the interwiki data in OSM also... Roozbeh 14:28, 1 March 2007 (UTC)


Capital of Laos

name:ipa=wiəŋ-ʤan   (?)
name:latinfont:pronounciation=Viengchan (?)
int_name=not used, makes no sense (?)

If you are in Laos and ask for Vientiane the people will not know it. The City is called "Viengchan" which is not the same as "Vientiane".

Wouldn't it make sense to also have name:lo=ວຽງຈັນ name:lo=ວຽງຈັນ - for example in case somebody wanted to render a map of all of Southeast Asia with all the labels in Lao?
Also, as much as I like the IPA idea, would it make sense to indicate the language and script, such as name:lo-Latn=Viengchan instead of the pronounciation extension? Øukasz (talk) 08:20, 18 September 2016 (UTC)

Capital of Thailand

name:ipa=kruŋtʰêːp mahǎː-nákʰon (?)
name:latinfont:pronounciation:short=Krung Thep (?)
name:latinfont:pronounciation=Krung Thep Mahanakhon (?)
int_name=not used, makes no sense (?)

--Robotnik 21:36, 24 November 2007 (UTC)

I think name="" is misleading. It doesn't give any information about what language is actually used. There are also some places that have more than on official language. It would be nice to be able to specify a default or a set of default languages use for the name.
For example, the following would be rendered with a combination of names from the list in name_lang. It would be formatted as "Bruxelles - Brussels" or with a newline or other splitting symbols in between :
As far as name:ipa, I don't think that's relevant to OSM. The transliteration sounds interesting. -Moyogo 09:41, 28 November 2007 (UTC)
Is the above example as used? The correct spelling of pronunciation is without that extra "o". --EdLoach 21:09, 2 March 2009 (UTC)
Assuming that OSM data is actually used and assuming that IPA data is entered for a wide array of objects, the IPA data could be used to guide a GPS with IPA data to pronounce information properly. I don't think that adding the IPA info hurts but perhaps it's not useful for most people to read directly. Also, if someone is able to read IPA information (like me) having the IPA version of the name printed in small letters below the name would allow me to pronounce the place more like a native speaker. Transliteration often requires it's own knowledge base (speaking Japanese from Romanji transliteration provides no clue that "Ritsuko" is actually spoken with a silent "u"). Furthermore, I might be able to recognize the characters for Irish Gaelic street/place names but I wouldn't have the first clue as to how to pronounce it. I personally find IPA data quite informative. --Dygituljunky 05:12, 8 June 2010 (UTC)

Alternative Name


I have come across a number of residential streets that are signed with two different names and do not appear to indicate that each side of the street has a different name (both signs appear on both sides), or that one street leads to the other. I have been using alt_name=* for this.

-- Sward 00:21, 22 September 2008‎

I have been using alt_name=* for this reason too. —Tedp 06:12, 21 April 2009 (UTC)
Yes. Seems like the case for it. In fact I'll add that photo as the example on the alt_name=* page. -- Harry Wood (talk) 22:03, 31 August 2016 (UTC)

In Quito, Ecuador, the streets have a "positional" name in addition to their , like "N18 Asunción", meaning it's the 18th street north of some central street. However, most people know of just "Asunción". I'll use "N18" as alt_name. Arnotixe 01:02, 7 May 2010 (UTC)

Hi Arnotixe! Maybe you could use the ref=* for the positional name. Or maybe loc_ref=*? Zeptomoon 08:01, 7 May 2010 (UTC)

How can I name a tunnel?

I have a road which is inside a tunnel. The road has a name and the tunnel also has a name. The two names are different. Which name should I use for the name tag on the way?

there is a proposal using relations to expand tunnel / bridge descriptions, including a name for the tunnel / bridge. But I would propose using another approach: namespacing. e.g. tunnel:name=xy. this could be expanded to virtually every entity/feature of OSM, not only bridges / tunnels. see my comment: --Marc 12:16, 29 December 2009 (UTC)
Another possible option is to tag the tunnel name in name=* on the tunnel segment, and link it to the road with a road relation (where the name of the road is tagged). --Skippern 12:32, 29 December 2009 (UTC)

Language on name on countries

Should the name=* for countries be in English or the local language? If local, how should we deal with several official languages? I think that for countries the name should be in English, and use name:xx for other languages. --Cohan 17:53, 13 December 2008 (UTC)

The OSM consensus is to use local name in name=* and for those places this is different than English name:en=* for the English name. If there are a naming conflict about the official name of your country, than maybe you should thread carefully here. Anyway use the local name. In my case, the right way is name=Brasil and name:en=Brazil as well as name=Norge and name:en=Norway, name:no=Norge, name:nn=Noreg (Norge and Noreg is both Norwegian names of Norway, and both are official, belonging to two different written forms of the language) --Skippern 19:24, 13 December 2008 (UTC)
For Norway, I think name=Norge - Noreg would be the correct way beacause, as you said, Norway have two offical languages. josi 19:07, 22 January 2010 (UTC)
The form Bokmål is written by more than 75% of the population (I do not have accurate figures though), while the form Nynorsk is thought at more than 75% of the schools. On the norwegian money NOK only the 50NOK bill have the Nynorsk variation of the country name printed, all other bills and coins are printed with the Bokmål name of the country. It is generally accepted that the official name printed on maps are the Bokmål name, even though some maps are printed in Nynorsk. Nynorsk maps are generally local maps for municipalities where the majority of the population write in Nynorsk. I am on purpose avoiding the word spoken, as hardly any speak any of the written forms of Norwegian. --Skippern 00:51, 24 January 2010 (UTC)
If statistics are, as, quote Wikipedia "Bokmål is used by 85-90%[1] of the population in Norway", then it ("Norge") seems to be the common default (written) name. The case of Belgium seems like an exception (there are probably others, too, though), but that's because they have such equal proportions of people speaking each language that using only one language would be an invitation for edit wars, or worse. Generally the name tag should hold only one name in one language. Alv 22:31, 22 January 2010 (UTC)
You are quite right, bokmål is the dominant form of written norwegian. But if we are using the local names because we try to respect the locals choice of names -- then it can be argued that following the people of Norway who has chosen these two forms would be right. So even if the majority of norwegians use bokmål, nynorsk is no second class legally speaking. The nynorsk form Noreg is just as official as Norge, and in Norway they are both used. It's not my intention to just be grumbeling. I actually think it's an interesting principle question. Norway isn't unique by having this issue. I see (or assume) you're from Finland. There you have the same dilemma, Suomi, Finland or both. As those names are so different, it might be more important to include them both? The principle question, as I see it, is when you choose to use local names and not change names by the users languages -- why? Haven taken this choice to use local names, it seems naturally to follow the policies made by the locals themselves. If not, one might instead use the names in the language of the user. French names for francophone users, norwegian names for norwegian users etc. Using some of the local names, but choosing to hide others seems a bit inconsistent to me. Said in another way: It's easy to accept that the germans read Norwegen, english Norway or the francophones Norvège. Choosing to use one of the norwegian names, when there in fact are two equally official names chosen by the locals is way harder to swallow. Do keep in mind the these questions for many people are of great importance, and that the consensus made by the local inhabitants have been obtained by a quite long and emotionally fight. Just ignoring it might be seen as quite arrogant. josi 01:35, 23 January 2010 (UTC)
Yes, in the end it's up to the local mappers to agree on what name to use. The "language issue" in Finland is so old that there hasn't even been any discussion amongst the Finnish mappers that it shouldn't be in Finnish only (wiki/irc/mailing list/forum). Each municipality has a majority language and the tag name=* is in that language in that municipality, and other names are in the language specific name tags; the country has a significant majority of Finnish speaking population (Swedish is about 5.5%) so the name=* of the country is in Finnish. I just looked at it and it seems it's likewise in Estonia: they have a 15% Russian language minority, yet the name=* of the country is in Estonian only. There was a technology demonstration for showing all the names in the language of the user (maybe it was only selectable by the user, and not automatic based on the browser settings), but it hasn't yet been deemed as offering enough value for the users vs. the disk space required for storing all the tiles in possibly hundreds of languages. Alv 13:28, 23 January 2010 (UTC)

In Belgium we have name=België - Belgique - Belgien (that's Dutch - French - German), following the same rule we have in our bilingual capital Brussels where we tag streets and places with name=French name - Dutch name (or the other way around). --Eimai 20:55, 13 December 2008 (UTC)

You should choose only one of the names for name=* and populate the rest with name:xx=* where xx is the ISO code for the language, as my Portugese or Norwegian map will fall back on name=* where name:pt=* and name:no=* does not exist. That will also give me the ability to prioritize what language I prefer. If all place names in Belgium comes up with three forms than the map becomes confusing. I suggest prioritize the name that is most commonly used. --Skippern 09:56, 14 December 2008 (UTC)
No, name will always hold all the official languages in Belgium. Trust me, languages are a really sensitive issue here and doing it differently will result in edit wars. By the way, it's not like every place in Belgium needs two or three languages in the name tag. It's just the Brussels-capital region which is bilingual. Every other place has only one official language. Just the Belgian country name needs more than one language as well. And for Belgium it's something like 60% of the population Dutch speaking and 40% French (and a small number of German speakers, less than 1%), so you'd propose to discard those 40%? --Eimai 13:28, 14 December 2008 (UTC)
Yes and no, name=* should still hold only one value, and all the names should also be put in name:xx=*, so for example Belgium will be like this: name=België, name:nl=België, name:fr=Belgique, name:de=Belgien. I oppose the usage of name=language one - language two - language three, how will that look for places with 5 or 6 official languages? --Skippern 13:43, 14 December 2008 (UTC)
See Multilingual names for more about multilingual names. --Skippern 19:25, 14 December 2008 (UTC)
As the Belgium section in Multilingual names says "The currently used convention for name is name=french - dutch, such as name=Grand Place - Grote Markt." So, I think it's quite clear it should be done like proposed by Eimai. After all, this isn't a place for language politics - I think openstreetmap should try follow the official language policies made by the local authorities where they exist. josi 19:07, 22 January 2010 (UTC)

Unnamed streets

Espeacially in developing countrys there are many streets which simple do not have an official name. To record this fact, I propose the following: unnamed=yes. This tag should indicate, that the street (or other feature) was surveyed, but that there is no existing official name of it

For unofficial names (like those given by the local community) we ca use alt_name=xxx


unnamed=yes is a better approach. --Skippern 17:11, 29 January 2009 (UTC)
Changed the proposal accordingly. --Peter.doerrie 17:35, 29 January 2009 (UTC)
Please see Proposed features/Noname and related discussion. unnamed=yes is already one of the suggestions. -- Harry Wood 18:54, 14 March 2009 (UTC)

Two languages in name= tag?

Sometimes I see cities with e.g. arabic and english names both in the name tag - is this useful/normal/accepted/bad? Ojw 11:51, 14 March 2009 (UTC)

Yes. I saw this too. example.
I guess people are deciding that it's better for the map to show names in arabic and english, so they're setting the name tag accordingly. Certainly these places should have name:en set in addition (in case you do not want to render the arabic name). But setting name with both arabic and english seems wrong to me. "The default name is the local one", in this case arabic. This means the english name wouldn't show up on , which is maybe a rendering problem.
-- Harry Wood 19:22, 14 March 2009 (UTC)
This probably doesn't apply in the shown case but in some countries or regions that are bilingual, there is more than one official name, i.e. there is more than one local name. This could happen in some regions listed at Wikipedia's List of multilingual countries and regions --Moyogo 17:05, 16 June 2009 (UTC)
For some such regions there's no uncertainty. Take Finland for example: every municipality is either dominantly Finnish and only some have a >50% Swedish speaking population. The former might have names in both languages, but these tag name=name in Finnish and name:sv=name in Swedish if it exists. The latter municipalities use name=name in Swedish and name:fi=name in Finnish. The distinction is even easy to make on the ground, as the more common name is written above the other. This then doesn't work, say, in Brussels, where the languages are spoken (roughly) 50/50 and apparently roads have names in both languages and likely both parties would get upset if only the other one is presented as being "the name". Nevertheless the users of the data would appreciate if there's both name:fr and name:nl in addition to whatever is in the plain name-tag. Alv 17:48, 16 June 2009 (UTC)

Abbreviation (don't do it) . Abbreviations on street signs!

Hi, In my area in Greece I spot many times(the reason could be too long names) street signs with abbreviated names. Sometimes it's abbreviated differently, so looking at many signs you might start figuring out the name if you are Greek. (for example one street sign could say "G. Alex" and another "Great Al." . This is for urban areas where I live in Thessaloniki, Greece. I think this is caused by too long names being a common thing. Logictheo 17:02, 11 June 2009 (UTC)

The page says, "Enter the full name as it appears on the street name signs." Then it says, "Do not abbreviate words." In most of the US, the "suffix" part of a streets name, as well as any directional prefix or suffix, is abbreviated on the signs. For example, we have in Columbus "W Dublin Granville Rd" which is a bit long as it is, even without expanding the abbreviations. Someone not from around here recently "fixed" it by expanding it to "West Dublin Granville Road". Not only does that take up more space on the map, but it's not what the sign says, and it looks fruity to an American who's used to seeing the common parts of street names abbreviated. Furthermore, if all abbreviations are expanded, then there can possibly be some ambiguity. For example, we also have a "North Star Rd". "North Star" is the name, and "Rd" is the suffix. If it were completely expanded, it would be "North Star Road" which could be misunderstood as "N Star Rd", which would be the north half of a road called "Star Road". At least, if "North" is spelled out, but other roads nearby with a directional prefix are abbreviated, then it's obvious that the North is part of the road name. (If, hypothetically, the road were long enough to cross into the southern half of the address grid, there would be "S North Star Rd" and "N North Star Rd". It's not uncommon to have things like "N West St", which is entirely different from "Northwest St", though two streets with such similar names are not likely to be located near each other.) Anyway, it seems to me that when parts of a road names are commonly and consistently abbreviated on the signs, as in most of the US, so should the value of the name tag in OSM. I'm going to go ahead and adjust the page text accordingly. If someone disagrees, then put it back to its current (contradictory) wording, and discuss here.

Vid the Kid 20:39, 11 August 2009 (UTC)

Yeah OK so for the sticklers, there was a slight contradiction, I have re-ordered sentence to remove the contradiction (We don't put abbreviations in the data... but apart from that we write exactly what the sign says)
I haven't solved the problem you describe about "N Star Road". Hmmm interesting one. I guess the TIGER data is full of these prefix abbreviations. I think this needs some wider discussion. Also I wonder if it was a bot which "fixed" W -> West. Where did this happen? Can you provide a link?
-- Harry Wood 17:55, 13 August 2009 (UTC)
North Star wasn't wrong in the TIGER data. The other example of W Dublin Granville Rd becoming West Dublin Granville Road was done by a (presumably) human user, who edits primarily in Australia using changeset summaries that say only "Fixing Stuff", and has apparently changed his name (I didn't know that was possible...) since making that particular edit. This user also likes to edit roadway topology, representing a multi-lane road with two one-way ways, even if road is not a divided highway; sometimes both ways run in the same direction, sometimes any route tags and relations involved get messed up, and sometimes the ways simply aren't connected properly to other roads. He also likes to change bridges with layer=0 to layer=1, even when they're only going over things that are layer=-1. In other words, he fixes stuff that's not broken. Vid the Kid 23:26, 27 August 2009 (UTC)

I've further elaborated on my opinion about this in an essay, Why Most American Street Names Should Be Abbreviated in OpenStreetMap. I would like to hear specific arguments for the other side of this issue. Is there an archive of any previous discussion over street name abbreviations? Vid the Kid 23:26, 27 August 2009 (UTC)

So, I'm still a little unclear about whether, under the current guidelines, a street sign which says "N Ave NW" should be expanded to "North Avenue Northwest" or "North Avenue NW" or should be left as signed, "N Ave NW". Perhaps we need a clearer rule that all names shall be expanded to their fullest extent and then have a tag for "name:as_signed" and "name:postal_abbreviation"; with this method, we could list the full name (North Avenue Northeast), the name as it appears on the sign ("North Ave NE"), and the official postal abbreviation as preferred by the national post office ("N Ave NE"). Of course, I fall into the camp of there's no such thing as too much data as long as it's properly categorized. --Dygituljunky 05:43, 8 June 2010 (UTC)
I think I have a few counterpoints to Vid the Kid's essay on using the road name as signed in the US. Firstly, road names are not consistently abbreviated on signs in the Metro Atlanta area; the quality of the street sign itself and the consistency of the abbreviation depend on which county or city placed the sign. As an example, "Boulevard Avenue" in Atlanta might be abbreviated "Blvd Ave" at one intersection, "Boulevard Ave" at another, and just "Blvd" or "Boulevard" at a third. Secondly, text-to-speech functions seem to have a hard time with abbreviations; MARTA buses with "St. Mountain" in the text abbreviation say, "Street Mountain" and the Mapquest Open reads out something like "en decatur erd" for "N Decatur Rd" or "eee ponce de leon ahvay" for "E Ponce de Leon Ave." Thirdly, people abbreviate roadnames in ways other than what highway planners and the USPS do. I think that it would be harder to teach a text-to-speech engine all of the various official and non-official abbreviations and their spoken variants (St-Street vs St-Saint vs St-Stone) than it would be interpret abbreviations in a search query. Given these considerations, I vote that all US roadways be unabbreviated with the exception of national and state numbered routes (ex.I-285, US 29, GA 410). --Dygituljunky 06:35, 15 July 2011 (BST)

Locales in addition to just country codes

I think it would be a good idea to use locales in addition to just language codes for tags that need internationalization. For example, I'm sure that there are terms, that are written differently in the french speaking part of Switzerland than in France. So in this case it would make sense to use "name:fr_CH" and "name:fr_FR". For strings that are the same "name:fr" can still be used. same goes for other tags like "wikipedia", "website" and such. Flaimo 22:32, 13 October 2009 (UTC)

A more standard language code would use a hyphen: name:fr-CH=* or name:fr-FR=*Michael Z. 2013-11-06 07:59 z

Naming links?

Should links (ramps/slip roads) be named? If so, how? --NE2 02:03, 14 December 2009 (UTC)

If there is a link with name it should be tagged e.g. name=Crusty public highway ramp But if there is no name we don't come up with one. Most links should remain nameless. Gnonthgol 02:38, 14 December 2009 (UTC)
OK, so stuff like 'exit 1', 'ramp to Holland Tunnel', and TIGER's default of the highway it leads from or to shouldn't be used? --NE2 06:03, 14 December 2009 (UTC)
Where "exit 1" is somehow indicated to the drivers/visible on the ground, you can tag the start node of the offramp with highway=motorway_junction + ref=1. The fact that a ramp leads to Holland Tunnel should be evident from the fact that it leads to the Holland Tunnel. For recording destination signs, there is a relation proposal. There was at some point in history a recommendation to give the ramps leading to numbered roads (anything that has a ref=*) the same ref as the road that they're leading to, but at the moment it seems to be written as if to be used only in Germany, for whatever reason. But that doesn't mean it should be country dependent. Alv 09:11, 14 December 2009 (UTC)
Yeah, I figured out the "motorway_junction" tag after seeing it in use. (If by destination signs you mean the stuff under the "exit 1", like "exit 1 / NY 9A / West Street", shouldn't that be in name=* for that offramp?) --NE2 04:45, 15 December 2009 (UTC)


I think it is important to find a good definition of the tag name=official_name. The tag has been introduced for country names but now some contributors would like to use it for other things like fully qualified names of libraries, schools. etc. Imho, the tag name=* should be the official school name. Shorter versions used by locals should be tagged with loc_name=*. So one definition of "official_name" could be "for names that are used in documentation exclusively". But still, we need a clear definition and scope between all these different name keys ("name", "loc_name", "int_name" are usually enough). -- Pieren 13:38, 20 January 2010 (UTC)

I see a problem in the fact that we have multiple attributes a name can have: its language (solved in OSM via localization), its utilization (somewhat solved in OSM: loc, int, old etc.) and the length/form (is it an abbreviation, is it the short version of a name or the long version of the same name). the last thing (length of name) has not necessarily a coherence with utilization (e.g. used in official documents); we can have a long version of a local name and a short one. we can have a long version of an official name and a short official name, both used in documents, public affairs and manifested in common sense etc). So i strongly oppose the tag official_name in any form since it mixes up two different attributes of name: utilization and length. And I don't see a need for an official name since we have already the normal name tag for exactly this case. Any unofficial type of name can be tagged with int, nat, reg, loc and alt_name, like currently being done (more or less). if a name has a long and a short form I would like to see a generic appendix like :short / :long / :abbr (naming of appendix open to discussion, maybe there are even more types) that can be used for ANY name-tag: name:short=foo, name:long=foobar, name:abbr:fb wheres all three versions of the name are equal in terms of domain. This appendix shall be used on any name tag, e.g. int_name:short=... and so on. I clearly see the need for a distinction between long and short names, not only for countries but for virtually every object in OSM. But mixing it up with name utilization (official vs. unofficial name) just does not solve the problem. Far from it! we can potentially have this issue with any name tag, not only with "official" names. So we need a generic solution to the problem long vs. short forms of a name. (this comment and proposed solution is just an example of how I think we should approach the problem!) --Marc 14:04, 20 January 2010 (UTC)
Using appendixes :short / :long / :abbr is bad idea, becouse it mixes namespaces with name:<lang> --Ilis 04:26, 21 January 2010 (UTC)
if sorting of appendices is defined and lang is always the last one there is no problem, especially when all appendices and values are defined. works on other OSM tags without problems. --Marc 10:02, 21 January 2010 (UTC)
Shouldn't name=* be what's on signs (with abbreviations generally expanded)? --NE2 05:45, 21 January 2010 (UTC)

I think we could define official_name=* like "fully qualified official name" as used in the official documentation or when multuple official names exist in one language. Sample usage:

I'm not sure if there's a worldwide problem of extensively long official names. But in Russia we do meet this problem. E.g. we use name=*="School #1" when official abbreviated name in Russian is МОУ СОШ №1 which stands for "Municipal Educational Institution Secondary General School #1". I believe nobody needs it this long within name=*. --neutron 06:07, 21 January 2010 (UTC)

I see your problem, and the need for a solution. but the tag official_name messes up with the usage of normal name, because in most parts of the "OSM-world" name is actually used for the official name. so we have two tags for essentially the same thing: an official name. only that some people use it differently than others, because they make a distinction based on its length. if you have a long and short version of the name and both are equally used in official documentation and e.g. political common sense, then you have an addition problem: the definition of official_name does not work anymore. before we find a bullet proof solution to this problem I'd like to ask you if you could explain the usage of your long and short names in more detail, especially how much the population of an area uses the long names, how often the short names are found in official, quasi-official and non-official documents and so on. As i said in my long post above: I see the problem of long and short names, but I don't like the distinction official vs. non-official if it is used only to separate long and short names (take country names for example: some short versions are used more often in official documents and political common sense than long names. does this make the short version "more official" or not?). I'd just like to see another way to solve the problem which is more generic. --Marc 10:08, 21 January 2010 (UTC)
name=* is defined as "The common default name". I believe it does not contradict with official_name=* being more official than name=* where applicable. If there are two equally used official names then one can use semicolon to separate them within name=*. Official names in Russia are always used in official documentation (bank statements, invoices, court letters, laws and so on). While in common life, quasi-official and non-official documents, political common sense, mass-media The common default name or abbreviated official name is used. Because abbreviations are not allowed in the name tag we can end up with multistorey unreadable names on the map. "School #1" transforms into 6 long words which are the same for all the schools in the country. More examples: Belinski Library -> V.G. Belinski memorial Sverdlovsk Regional Universal Scientific Library; JSC Uralmash -> Joint-stock Company Urals Heavy Machinery Plant; TNK-BP Ltd -> Tumen Oil Company - British Petroleum Ltd; Opera House -> Yekaterinburg State Academic Opera and Balet Theatre. One Russian ministry has two official names and three English official names: Emergency Control Ministry (EMERCOM) or The Ministry of Emergency Situations or Ministry of the Russian Federation for Affairs of Civil Defence, Emergencies and Disaster Relief. Tha latter is used only in very very very official documents, in most cases the first one is used or a 3 letter abbreviation of the first one. --neutron 11:18, 21 January 2010 (UTC)
There's few mapnik links for illustration: And we do use abbreviations in name=* at this point to keep the map readable. --neutron 11:28, 21 January 2010 (UTC)
Using abbreviations in name=* is a bad practice, even for readability. If it is a rendering issue to see long names in your map, then fix the renderer and do not shorten the names. A software can easily replace long words by their abbreviations but the other way is much more complicated. We have a special wiki page about abbreviations in multi-languages -- Pieren 12:23, 21 January 2010 (UTC)
thank your for taking time to clarify the current status and conceptual problems in your country. Helps a lot. However may I ask you a question: why not use e.g. nat_name or int_name for commonly used names (as intended) and use name=* for the official name? When I interpret your statement - based on use cases I was confronted with several times on OSM - it's clear for me that you have a long, official name and a name based on local or national or even international common sense / knowledge. and name=* is defined as "default name" on the name-wiki-page whereas on the maping features page it is defined slightly different. we should discuss this since I think name=* is used and understood different depending on OSM-community/region. Generally I don't like mixing several different concepts into one tag (e.g. usage frequency of a name vs. name type/class), that's why I don't find the official_name solution suitable. But I see your problem with rendering the long names and I agree that we need a solution to this. In addition - you already denoted it - to locals actually using the map a "common sense" name is more useful than the full qualified name, even if the later one is the "real" name of an object. but in my understanding that is clearly an issue that should not be solved by changing the OSM meta model but instead by e.g. specifying appropriate rendering rules/options or by adding additional information to an entity (e.g. information that orders name by importance/usage etc.). I hope you correctly understand what I'm trying to tell: I agree with most points and problems you describe and I am in favor of a solution, and I see that official_name solve will solve some of the problems currently encountered in Russia, at least in short-term. But I don't think official_name will solve the remaining problems in long-term and thus am afraid we will discuss similar issues in the near future. That's why I am hoping for a better solution to this. --Marc 12:28, 21 January 2010 (UTC)
why not use e.g. nat_name or int_name for commonly used names (as intended) and use name=* for the official name? It is easy. How do you distinguish between two (or three) official names which one to put where? See the Ministry example above, all names are official and fully qualified. Same sort as with country names (Russia and Russian Federation are both defined in the Constitution as equaly usable names). We could use alt_name=* even but it's more suitable for names given by people, like Beavis and Butt-head monument. Another thing is, when you register a company you have to choose not one name, but a long name and a short name (smth like trademark), e.g. Coca-Cola Subdivision in Yekaterinburg long name is Coca-Cola HBC Eurasia division Yekaterinburg Ltd. I don't think it is practical to put all of this into name=*. Imagine smth like this pops up on your PDA screen when you navigate through unfamiliar suburbs. Or how do you suggest a programm should shrink this? Anyway, as official_name=* was introduced a while ago and had been used roughly 196 times I don't see any reason to abandon it. I would rather focus on finding a suitable definition for it to expand it's usage on objects other than country names. --neutron 18:31, 21 January 2010 (UTC)
what you are proposing (including your example) does not solve the problem of distinguishing between multiple official names: you just put the longer official name in the official_name tag and the shorter official name (which as in your example is equal to the other one, just shorter) in the normal name tag for one reason: so that it renders properly. Who tells you if you have to use Russia or Russian federation if both are defined in the Constitution (!) as equaly usable names (same applies to company names: you are right, they are equal, and that is exactly the problem: two different tags for an equal thing? no way!)? Probably arbitrariness and the wish that one of the two names is displayed on the map, and the other not. If your only problem is a rendering issue then this is the wrong place to find a solution, at least we won't find one in creating a new tag. we don't tag for renderers and we don't cripple and abuse the meta model to suite renderers - as I understand this was some sort of common sense from the beginning of the project, or at least from the point people started to think about what they were doing ;) ). we adapt renderers to interpret the meta model and transform it into a visual representation. But for that we need a bullet proof concept and meta model and as you stated correctly a clear definition. that's highest priority. and that's what I was saying from the beginning: the problem is not the distinction between official and not so official names, because that is solved with the current tags we have, even without using the offical_name tag. the two problems I currently see are: how do we decide WHAT (which tag and which value if there are multiple) shall be rendered and how do we tag multiple equal names (e.g. using a semicolon and rank order for priority and so on --> as I said: using different tags is not a good solution if the cut-off value is "what do I want on the map" / if it is "what do people use" than lets put that name in int_name or nat_name or loc_name) and how do we communicate WHICH tag shall be used to display - depending on application. But please feel free to propose a definition of official_name with a distinction criterion not based on "map display" or "short/long": we need a distinction that shows the conceptual difference between name and official_name. and this one is in my opinion clearly missing since you currently propose to put - as described above - equal names in different tags. and that clearly is not a clean model. As I already said before: I understand your use case and see your problem, but I definitely don't agree with the current approach of "solving" it, because it does not solve anything: the "name-thing" in OSM remains grubby. --Marc 19:00, 21 January 2010 (UTC)
Such long names are result of soviet tradition to mention in name all regalia and call places in a memory of somebody. Several examples: ХАРЬКОВСКОЕ ВЫСШЕЕ ВОЕННОЕ АВИАЦИОННОЕ ИНЖЕНЕРНОЕ КРАСНОЗНАМЕННОЕ УЧИЛИЩЕ or Краснодарское высшее военное училище имени генерала армии Штеменко С.М. This names are used only in oficial papers, when it is "important" to show that this is not usual, but famous organization. May be in your country situation is different, but here nearly all universities and old organizations have such official names which are hardly ever used in everyday life. In usual life first what we do drop additional information, which describes the organization instead of naming it. We drop regalia (first criteria). We drop the name of a person (Second criteria), who this organization was called for. Then we use abbreviations. And abbreviations are the most used ones, but I agree, that they shouldn't be used in name tag. So I suggest using official_name for names with all regalia and name for the name itself.--User:KiberGus 20:00, 21 January 2010 (UTC)
The definition "The common default name" in Map Features is as old as it can be, from 17 March 2006 and "default name" in Key:name was written only hours later. For streets it's simple, it's what's on the sign. For other features it can be different from a sign on the entrance, when all everyday uses are a simpler version - no one would speak of the "Ambassade van het Koninkrijk der Nederlanden te Helsinki", but rather say "embassy of Netherlands" (in their language or the local language, naturally). Even if that phrase could be constructed from the fact that it's amenity=embassy + country=NL, it's still a name, and more descriptively, the "common name". "Tagging for the renderer" is about using false tags to get a desired appearance (landuse=industrial to get a pink area on the map), not about clinging to values that disregard the common sense mentioned somewhere above, when other values are as valid as the one in official papers. Another example: three universities were joined this new year, and, for example, the Kauppakorkeakoulu (Helsinki School of Economics) is now officially "Aalto-yliopiston kauppakorkeakoulu"), but I'm quite certain that they still have only the older name on the wall and everyone uses that version. These cases are the ones that benefit from using the "common default name" in the name tag and additionally specifying that "btw, it's officially a bit different". Loc_name or alt_name are different, as they can be more informal kind. (The street "Bulevardi" has a loc_name=Bule.) Alv 11:28, 22 January 2010 (UTC)
Where did you read that alt_name is more informal ? And yes, using abbreviations or short names in the value of the key "name" just for a nice looking map is "tagging for the renderers". --Pieren 11:37, 22 January 2010 (UTC)
and the definition "common used" raises one major question: commonly used by whom? when different sub populations exist there can be different "commonly used names". so which one to choose from? the name written on the sign? why? because people use OSM-data only for navigation and thus need to see the name written on signs on their map? the most frequently used? do you always have the correct information to determine this? or use the one YOU think is right or that is used in YOUR sub population? or the official, correct name, even if it is long, and put common names in corresponding tags like nat_name, loc_name etc... as I said a hundred times: the current model has many drawbacks and ambiguities. official_name may solve some of them (even if with the wrong approach: tagging for renderers), but by far not all of them... it even generates new problems. and it's definitely time to rethink the current naming-implementation and construct a bullet proof solution or at least provide clear definitions. so lets abandon official_name for now in order to put our resources in reworking the naming concept to sort out all the problems we currently have. in long term that's the only right thing to do. and this is a thing that needs more than 4 opinions in a wiki discussion... --Marc 11:47, 22 January 2010 (UTC)
They (loc_name & alt_name) can be informal - just look at the examples. For most of the features in most countries the official name will be used as is, as taken from the sign on the wall as that's what the entity calls itself. Only when everyone uses a simplified version of the official name (say, of what is found in national company registry), it really is the "common default name". If in doubt about what is "everyone", ask ten (or more) people "Do you know what that is? By what name would a tourist find it? What would an article in the most highly valued local newspaper call it?" (they have language specialists for proofreading). And note, that it's not aiming to tag for tourists, but that kind of question gets people to give a "formal" name as opposed to some possibly derogatory local slang word for it. People can, and do identify the sub populations, and can dismiss the informal names - or enter as alt_name. Alv 14:02, 22 January 2010 (UTC)

name:abbr for abbreviations?

Is there anyway to to fill in name abbreviations? new tag type "name:abbr"? For example there is real estate rental association for students named "Turun Ylioppilaskyläsäätiö" abbreviated "TYS". "TYS" is much more know then its long Finnish name, especially for foreigners. --Kslotte 16:29, 5 March 2010 (UTC)

Isn't that just one more alt_name=*? --Skippern 00:07, 6 March 2010 (UTC)
That was my first thought, too. But it is said here, not to use alt_name=* vor abbreviations. Altough there is need for it. Another example: In Germany there is a "Landesamt für Vermessung und Geobasisinformation". The official and widely used abbreviation is "LVermGeo". [1] If I type "lvermgeo" into a search box, I would expect Name Finder to find it. --Bundesrainer 14:02, 11 November 2010 (UTC)
Rather than "name:abbr", I would suggest "name:short" which could be further extended by "name:en:short" or "name:ko:short", for instance. This would cover both abbreviations and shortened names which serve a similar purpose, to provide a shorthand reference for colloquial use. Also, it would avoid the standard arguments around 'that's not an abbreviation, it's an initialism' etc. --Ceyockey 20:25, 11 November 2010 (UTC)

short_name=* is currently recognized by Nominatim and in use in the data, I've tentatively added it to the list OleLaursen 12:09, 10 July 2011 (BST)

I think this is a quite OK addition. --Ceyockey 05:21, 11 July 2011 (BST)

Transliteration or Translation for name:xx=* ??

There are many names in Greek language, that can be easily translated:

  • Street: Οδός Κνωσσου => Knossos' Road => Knossos Straße
  • Church: Μονή Αγίας Ελένης => Saint Helens' Abbey => Sankt Helen Abtei
  • Place: Άγιος Νικόλαος => Saint Nicholas Town => Nikolas Stadt

The question is, if these translations should go into the name:en= tags, or if it would be better to use a transliteration, that is readable to English speakers, but keeps the Greek names sound:

  • Street: Οδός Κνωσσου => Odos Knossou
  • Church: Μονή Αγίας Ελένης => Moni Aghias Elenes or Aghias Elene's Abbey
  • Place: Άγιος Νικόλαος => Aghios Nikolaos
Arguments pro transliteration:
  • You are able to read the (almost) real name and ask for the way.
  • The place's name is not Nicholas Town. Locals may not know, what is meant.
  • Different names in different languages may cause confusion.
  • more?
  • The wiki says: "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.", but for some languages that is a myth, unless some super clever algorithms are involved. -- SwiftFast (talk)
Arguments pro translation:
  • The renderer can produce transliterations from a substitution table (here). So we can have both: Manual translation in the tag and automatic transliteration.
    • ου=ou, Αυ=Af, οι=i ...
  • Knossos' Road is easier to remember.
  • more?

Please leave your comments!

I personally don't like translations of names. I live in Kallithea not in Bellevue. But I would like to have a nice automatic transliteration, so I can save a lot of work!!! :) I agree, to tag well known places like name:en=Athens, and for those who would like to know, what the name actually means we might give the translation in a tag like translation:en=Pleasant View. Zeptomoon 00:42, 22 April 2010 (UTC)
Did anyone comment on this? logictheo 14:37, 7 June 2010 (UTC)
I guess the best solution is to put the 'translation' to "name:en=Florence" and a transliteration to "name:it_en=Fierentse". This is also now mentioned on the wiki-page. So I would tag "name:el_en=Kallithea" and skip "name:en=*". But I see, that most people use the name:xx tag for transliteration (e.g. Agios Nikolaos) unless a translation is more common (e.g. Athens). Personally I would like, if I we could even use '_' instead of ':' directly for transliterations of local names:
- "name:ru" in Russian name for Russian readers (_ru implied same)
- "name" in local name for local readers (:xy_xy assumed)
- "name_ru" in local name for Russian readers (:xy assumed)
- "name:fr_en" in French name for English readers (useful in multilingual areas)
Finally I think, transliteration is not necessary at all! Thus only name:xx tags need to be filled if a translation makes sense. The transliteration could be automatic. Zeptomoon 16:32, 2 March 2011 (UTC)

My Proposal:

  • The main name=* tag should contain only the original local name, e.g. the Greek name in Greek letters. This could be different in multilingual countries.
  • The name:en=* tags should be used only, if there is a commonly used English name, that is different (sounds different) from the Greek name,e.g. name:en=Athens because it is not Atheena. If there is an addition to the name (such as 'Οδός Μαριας') it may also go into the english name:en=Maria Street tag.
  • No transliteration should get into the name:en=* tags, e.g. not name:en=Ioannina.

The same counts for alt_name=*, alt_name:en=*, loc_name=*, old_name:zh=*, and such.


There are some important arguments, that brought me to this conclusion:

  • Transliteration of Greek names into other languages can be achieved much more easily by an automated script/bot or the map rendering program, i.e. Mapnik etc. It can simply substitute the Greek characters with the transliteration: (Λ = L, οι = i, αυ = af, etc.)
  • The tag data should be understood as a database of information, rather than a mark-up language for the map. Only this way, the map data can be used in more flexible and unexpected ways.
  • The user can decide, what will be shown on the map, only if we leave the name=* tag original and sort other info into other tags. Then users can choose, if English names or other language names (translation or transliteration) shall appear instead - or in parentheses after the Greek name.

I picked English and German translation, as that's what I know.

Examples in Greece
The capital of Greece:
Tag Standard Key:en Key:de Key:el
name=* Αθήνα
(official name)

Tag Standard Key:en Key:de Key:el
name=* Θεσσαλονίκη
(official name)
(Thessaloniki is only transliteration, but maybe we can put it, to stick to the standard spelling)
(Thessaloniki is no translation)
alt_name=* Σαλονίκη
(Alternative in English is different from Greek.)
(Geman is the same: Saloniki)

A square in Heraklion with a fountain in the shape of lions: Node on OSM
Tag Standard Key:en Key:de Key:el
name=* Πλατεία Ελευθερίου Βενιζέλου
(official name)
Eleftherios Venizelos Square
Eleftherios Venizelos Platz
Πλατεία Ελευθερίου Βενιζέλου
alt_name=* Πλατεία Λιονταριών
(What most people call it)
Lions' Square
(What English tourists call it.)
(What German tourists call it.)
Πλατεία Λιονταριών

Some church somewhere in Greece:
Tag Standard Key:en Key:de Key:el
name=* Ναός Αγίων Πάντων
(official name)
All Saints' Church
Ναός Αγίων Πάντων
Examples in other countries

I don't know, if the transliteration from/to other writing systems is as easy as from/to Greek, but there has been some effort already! See here:[2]

The capital of China: Node on OSM
Tag Standard Key:en Key:de Key:el
name=* 北京市
(official name on
(What I found on Wikipedia)
(More usual in Germany)
alt_name=* 北京 or 燕京
(??? Not sure!)
(Also known as...)
(Sometimes used in Germany.)
Open questions
Mass automatic transliteration

Maybe, maybe (probably not) it might good to also have transliterations in the tags in order for the search to find them. This could easily be done automatically. Much better though, if the search engine would transliterate the internal database or at best just look for similar spellings!

Genitive street names

What about the genitive case of the Greek street names? Should we incorporate that into the tranlsations:

  • Οδός Σοφοκλέους > Sophokles' Street  ?
  • Οδός Τίτου Γεωργιάδου > Titos Georgiadi's Street  ?

Does anyone want translations of street names? Are automatic transliterations not enough? Maybe only if the street name is written differently on the street sign: "Aristotle" not "Odos Aristotelus" Zeptomoon 16:32, 2 March 2011 (UTC)

Some good points. Some languages might be hard to automatically romanize, and there are probably names that depend on the spoken language (say, transcribed pronunciations).
There are standard language codes for romanizations, like name:el-Latn=* for romanized Greek. See Talk:Multilingual names#Standard language codes for more details. Michael Z. 2013-11-06 08:04 z
Old Names

I have a question specific to german territories that became polish after WW2. Many places had a german name, which you can find on pre-war maps. After the war poland renames every place.

  • Sometimes it was something completly new, e.g. Kalkofen -> Wapnica.
  • Sometimes it just was made to look polish: Lebbin -> Lubin.
  • Sometimes names got just translated: Alte Swine -> Stara Swina.

how to tag those different cases? in the first i guess old_name:de is to be used for the german name? or is old_name:XX only to be used if there is a name:XX? someone suggested to use nat_name:de. Also im not sure if Alte Swine -> Stara Swina is a changed name? It basically just a translation, so the name was not actually changed. should the german name than be used in name:de or in old_name:de? --JSmith (talk) 18:42, 8 March 2020 (UTC)

What name is used by speakers of German language? For example - is Breslau, Lebbin, Alte Swine, Kalkofen is used as name for this places by speakers of a German language? Or is it overcome by a new name (Wrocław, Lubin, Stara Świna, Wapnica)? Mateusz Konieczny (talk) 23:16, 8 March 2020 (UTC)
Used name:de and name:cs (and empty name-tag) for objects in former Sudeten German region in Czech Republic, e. g. to map hills and mountains. Result is icon for peak and elevation but no name. I was in hope OSM will display the name relative to the language of the webbrowser or operating system of the client.--Jkowar (talk) 15:28, 27 October 2020 (UTC)
"International" transliteration?

Transliteration is a scientific method to convert letters from one language to another. It makes heavily use of diacritic signs (accents etc.) and you will never meet this in OSM. We are talking about Transcription which mean converting words into the target language, as if they were written in this language. And this is of course highly language dependend. Examples (en/de) are Wolgograd/Volgograd or Zimbabwe/Simbabwe. Most languages simply use the English transcription. After all I feel the term "int_name" is completly misleading because there is nothing like an "international language" and should be dropped.

As transcription follows defined rules it is not necessary to write down millions and millions of results of these rules, but it would be useful to set tags, where there are differences to these rules (as "Samaria Gorge" / "Samaria-Schlucht", see below). Standard transcription could be left as a task to the renderers, as well as the decision which language to use as default (as noted before, most European languages actually use English as default, but Bulgarians might prefer Russian, if there is no explicit Bulgarian variant to write a name in cyrillic letters).

There is only one point against dropping int_name: For people editing abroad it might be helpful to have the transcription in the dataset, as does not yet provide auto-transcription. --GerdHH (talk) 11:30, 15 April 2017 (UTC)

Name needed for unnamed paths


when using OSM for a pedestrian navigation for blind persons, the following problem appears:

  • There are unnamed foodways (in the woods).
  • When navigating, crossings can only be named like "unnamed footway crossing with unnamed footway".
  • Using the OSM id of the way is not usable and when the way is split the ID changes.

I would like to add loc_name-Tags for this and name ways like "footway from village A to B, west of footway crossing in the wood"

Any suggestions?

--Lulu-Ann 10:55, 10 September 2010 (BST)

There are also unnamed roads. The same method should be used for both. --NE2 21:05, 10 September 2010 (BST)
I think we will use in this order:
  1. name
  2. loc_name
  3. description


I aggreed with the reply on the ML saying that the name shouldn't be fulfilled just to compensate the lack of unnamed paths support in navigation software. --Pieren 15:50, 13 September 2010 (BST)
I agree with Pieren's notion that the 'name' field should really be used for actual names, data from the field or sources. However, you've ID'd a real problem related to the usability of the OSM data. The ways and nodes in question do have OSM identifiers, albeit numeric and impossible to remember. These identifiers are universal in that they don't need context, but that also makes them all but unusable for human navigation. Thinking on this a few minutes, I can see at least two general solutions to this. One would be to compose a overlay-generator which would request inputs for all unnamed paths in a particular area and create a file outside of the OSM database, like as a .osm or .gpx file. The other general solution would be to add to the OSM data model a 'OSMhumid' or 'OSM human identifier' which would a) only be used when 'name' was not provided , b) not be unique universally but could be rendered unique within the bounds of some administrative level or in the context of a particular relation and c) would be flagged for deletion with a fixme tag automatically if 'name' were provided in the OSM database. --Ceyockey 20:16, 11 November 2010 (UTC)

multiple alt_names or loc_names?

how should i tag objects that have multiple alternative or local names? alt_name_1, alt_name_2, … or should a put all values in the value field, separated by semicolons?

Renderers wouldn’t recognize a made-up key name like alt_name_1=*. Use semicolons. Michael Z. 2013-10-30 21:40 z
Better use name tags supported by Nominatim, e.g. alt_name:1=*, alt_name:2=* and so on. --Scai (talk) 11:21, 9 May 2015 (UTC)

loc_name Squinty Bridge example

In reference to Key:name#loc_name

If, in truth, it is never commonly called by its official name, then you should surely use name=Squinty Bridge official_name=Clyde Arc

-- User:Lorp 13:37, 19 April 2011

Well I agree it's not clear. Normally examples makes things very clear, but this case it's lacking some surrounding explanation about what the loc_name tag means. I guess the answer is that "Squinty Bridge" is a nick name that all the locals use, but despite this, the mapper doesn't judge it to be a sensible name to put in the 'name' tag. That's a bit of subjective judgement, so I'm not entirely comfortable with defining loc_name in this way, but the rule should be written up there somehow.
It might be OK because the tricky thing with names is settling disputes where two groups believe strongly that the name should be one thing or another. If there was a religious following people who found it offensive that we weren't setting "Squinty Bridge" in the name tag, then in that case the loc_name idea would collapse pretty quickly, but as it is we can maybe get away with individual mapper making an airy fairy judgement of the "sensible name to put in the 'name' tag"
How to phrase that in a sentence to add to the docs there though?
-- Harry Wood 16:46, 19 April 2011 (BST)
OK I've added sentence to explain more: Names#loc_name -- Harry Wood 10:03, 11 July 2011 (BST)

Misspelled name

A city in Slovakia is named "Kolárovo" but many people misspell it as "Kollárovo" (double L, because there was a famous person Kollár but this city is not named after him; so many people think it is spelled with doulbe L). Nominatim and other search engines will not find this city when spelled with double L. Therefore I propose new tag "wrong_name" which should allow search engines to search for wrong/misspelled names/user inputs.

  • name=* – Default name
  • wrong_name=* – Regularly misspelled as
You can simply use note=* for this information. Nobody will want to render wrong names anyways. Lulu-Ann
Yes, but "note" has no (clear) interpretation and a lot of bloats in it (note=this city is sometimes misspelled as Kollárovo). wrong_name would have clear interpretation and nobody would dare to render it... --MichalP 10:47, 6 December 2011 (UTC)
I would be more inclined to think of this as a loc_name type. The spelling might be wrong according to official sources, but colloquial use can sometimes trump official use when you are communicating with a local or trying to interpret local documents or news. Also, if many people do misspell it, then your local newspaper or some other local publication might have a representation of this spelling. --Ceyockey 01:26, 7 December 2011 (UTC)


What about nicknames? many places/buildings in berlin have common nicknames. is there a nickname key? --Shmias 21:01, 21 January 2012 (UTC)

  • This would most likely qualify as a loc_name or reg_name, unless those are already taken by "official local" or "official regional" ... if there are such things. --Ceyockey 14:14, 22 January 2012 (UTC)

Mixed case in names

>Use mixed case with the first letter of each word capitalised (for example, Church Street, not Church street).

I disagree. In some languages (f.x norwegian), the right thing to do is _not_ to capitalize the 'street' part ( The wording in this paragraph should revised. --Gorm 15:08, 23 March 2012 (UTC)

I think so too. In Russian language me should write capitalized letters only for part of name, which is proper name (not status part). For example, we can have "New village" (the village with name "Novaya" and "New Village" (the historical district, where "New" and "Village" are important part of name. It is better to write, that rules about capitalized letter depends on language. Dinamik 10:39, 18 April 2012 (BST)
I have added a sentence "We can apply this rule quite strictly for latin-based languages but less so for some other languages." Hopefully that covers it without going into too much detail, but where should people go for more details? You mentioned No:Map Features#Spelling of street names. I suppose one might expect this language-specific information at No:Names too (and likewise for other languages)
-- Harry Wood 01:01, 19 April 2012 (BST)
I would think it would be quite obvious what to do. Name is in the local language, so you use the spelling rules of the local language. I wouldn't expect the OSM wiki to be the place where to find the local language rules. E.g. for Dutch I would look this up on If you plug "How to capitalise names" in your language into your favorite search engine you can probable find similar websites for other languages. --Cartinus (talk) 17:45, 25 May 2014 (UTC)
Yes, and nothing about “Latin-based languages.” Capitalization rules are for languages, not writing systems. Michael Z. 2014-06-16 18:29 z
French appears to lowercase minor words, in France and in Quebec (based on my three minutes of research): Saint-Marc-des-Carrières, Rue du Sanctuaire, Avenue des Érables, Boulevard de l'Assomption, Buttes aux Cailles, &c. Michael Z. 2014-09-01 21:43 z

Name for sorting

I was surprised, when didn't find tag for sorting at name=* page.

Situation: there are several street in the town. Street 1: "street Alexander", street 2: "Elena street", street 3: "Ivan street", street 4: "street Vladimir", street 5: "Xenia street". The proper names are "Alexander", "Elena", "Ivan", "Vladimir", "Xenia", "street" is status part. So, when we making the list of street, the order should be "A: street Alexander", "E: Elena street", "I: Ivan street", "V: street Vladimir", "X: Xenia street". When I tried to make the list with MapOSMtic, I see the next: "E: Elena street", "I: Ivan street", "X: Xenia street", "S: street Alexander", "S: street Vladimir". We should have some tag showing the proper name (perhaps, English word "proper" is not the best; I am talking about part of name, which is really name, not status part"; if you know better word, please, tell me).

I know tag sorting_name=*, which is relatively widely used, but there is no any words about this tag at name=* page. Are there any other analogous tags, which are used more widely? I think, we should choose though one such tag and add information about it to name=* page. The tagging of streets looks like "name=street Alexander+sorting_name=Alexander street", "name=Elena street+sorting_name=Elena street" (or only "name=Elena street"), "name=Ivan street+sorting_name=Ivan street" (or only "name=Ivan street"), "name=street Vladimir+sorting_name=Vladimir street", "name=Xenia street+sorting_name=Xenia street" (or only "name=Xenia street").

-- Dinamik 10:31, 18 April 2012 (BST)

I see you created the Key:sorting_name a few weeks back, which makes me wonder if you were just making this up, but I see there's nearly 15,000 streets with this tag. Seems like it is indeed quite widely adopted. I hadn't heard of it before. People should discuss this some more though. Not much peer review discussion/refinement just yet. Is it maybe a bit premature to add the idea to this Names page? Anyway I'll add some more thoughts over at Talk:Key:sorting_name
-- Harry Wood 18:45, 28 April 2012 (BST)
This tag is widely used and there is real need in it. One day I tried to use some service, which creates maps with list of name. This list looked strange, so I decided to wrote to the authors of service to notice them, that their service worked wrong, because didn't understand tag for sorting. I went to Key:name to check the description of this tag and was very surprised, when din't find it. At Talk:Key:name there is sign, that Most discussion can now be found here. I started the discussion here, there was no any reaction. So I added information about this tag.
I think, there is no question, use some tag for sorting or not to use. It can be question, what tag should we use. Nobody said about other tag, so I added information about the widely used tag sorting_name. Dinamik 19:05, 28 April 2012 (BST)
I've made some fixes to the english and tried to clarify things in places on the Key:sorting_name page. On this page I've thinned it down to just a few sentences, linking that page. I've also labelled it here as a "proposed approach". If you feel it's more than just a proposed approach I guess we'll remove that, but I'd suggest leaving this for a few months.
In general though ...I think it's fine. Thanks for documenting this tag!
-- Harry Wood 19:18, 28 April 2012 (BST)

Redundant localized names?

If you look at cities like Berlin you have 191 translations and 85 of them are exactly like the name-tag "Berlin". For multilingual rendering it makes no different if the translation exist because it fall back to name-tag if it not exist. This redundant translations fill up the database, makes editing more complex and it costs a lot in rendering process because the (stupid) rendering process think that it's necessary to render in this language instead of using default tile. The only benefit I see is the 1-bit information that a translation already exist.

The question is now, if we want to define in the wiki that we want or don't want such translations. --Kolossos 21:55, 25 October 2012 (BST)

The 1-bit niformation is still an information (however useful only if their language is used locally, because otherwise they don't have any official status and could be wrong elsewhere where this name is not even known or used).
And I don't think this costs a lot in the database, very few names are effectiveley translated, most of them just indicate their official names or a few local names or old or alternate names (also local in use). Yes some very wellknown cities and country names will be frequently transalted, but their cost in the database is very small compared to the huge number of names that have no translations at all but just a single "name=*". — Verdy_p (talk) 05:50, 27 October 2012 (UTC)
It can be handy for localised maps. Not everyone is willing to fall back on the original name. I guess, if you make a map for The Netherlands, you would first use the name:nl tags, and if those don't exist, the name:en tags (as we can read English, but f.e. no Chinese), and only as a last possibility, the plain name tag. When I add features to the map, their main language is normally Dutch. But when adding a translation, I also always add the tag name:nl, just to make sure this fall-back mechanism using multiple languages works. --Sanderd17 09:05, 19 November 2012 (UTC)
Well I don't think you need to worry too much about making sure the fallback mechanism works. Could argue that this would be tagging for the renderer, but no... the reason for adding a "translation" which is identical to the name tag, is to capture the fact that in this language there is no different translation. That's a perfectly legitimate reason, and in my opinion is enough of a reason to mean this is not a redundant tagging information.
However it's important to be clear about this reason because mappers (and renderer developers) could easily get the wrong idea, particularly if they look at examples like Berlin. I guess someone filled in these based on translations of the "Berlin" wikipedia article. This probably yields reasonably correct tagging. But note that it's not useful or necessary to "fill in" translations in all languages just to allow renderers to work. It would be a very stupid rendering system that didn't take the default 'name' in the absence of a translation.
-- Harry Wood 12:22, 19 November 2012 (UTC)

Greece: Full names or not? ('name:Οδός Κνοσσού' or 'name:Κνοσσού')

Hi all! I would like to clarify an important issue with the naming of Greek roads. It seems to be common practice on Greek maps (and OSM) to completely omit the "Οδός" ("Street") part of street names on most maps (and occasionally even on street signs). The full name of the street is still "Οδός Κνοσσού" ("Odos Knossou"/"Knossos Street"), but it is just not always displayed.


An important argument to keep the "Οδός" in the name: tag is that we do not make a map, but a database (for making maps and other amazing stuff). So each map renderer can choose to display "Οδός Κνοσσού" or "Ο. Κνοσσού" or just "Κνοσσού". If the database is incomplete (and missing the "Οδός") then the renderer can not choose anymore, because that information is lost (and it could be "Λεωφόρος Κνωσού" if fact!) We should be careful not to tag only for the renderer, but to make a complete and coherent set of data.

I would like to clear this up based on a broad consensus, if possible. What should the be name: tag? With or without the "Οδός" part? Should it be "name:Οδός Κνοσσού" or "name:Κνοσσού"?

Thanks for your feedback!! Zeptomoon (talk) 14:11, 27 May 2013 (UTC)

PS: I found some relevant discussion here also: Talk:WikiProject_Greece But there the discussion was going mostly around the question of translation and what looks best on the map, what is most user friendly.
This is an important issue. What about separating the "general" part which does not belong to the name=* to another tag like name:prefix=*. This is what is used in Czech republic with administtrative regions of level 8 (of LAU2), where it sais whether the entity is "obec", "město", "městys", "vojenské újezd", ... etc. Jakubt
BUMP. I see people in Greece un-tagging the street names and reducing it from eg. "Λεωφόρος Δημοκρατίας" to "Δημοκρατίας". Is that wanted? Can we find a solution here? Is there another place where we can discuss this? (The name:prefix=* is "Abandoned (inactive)", so not sure if it's a good idea.) Zeptomoon (talk) 19:55, 9 September 2015 (UTC)
After much searching, I found that there is some info here and there has been some discussion here: [3] Although It's not clear to me (since in Greek) if a consensus has been reached, it seems to me that the main argument is that there is no information in the fact if a road is Λεωφόρος or Οδός. Personally I don't agree with this, I think there is some information, the full name, even if it's a minor part of it. But I (as non-Greek) want to leave this up to the Greek community. Shall we have a vote on this to decide finally and have a consistent system? Zeptomoon (talk) 19:55, 9 September 2015 (UTC)
The Documentation is quite clear and practice in Germany, Italy and US also. If the street sign is "Λεωφόρος Δημοκρατίας" or "Οδός Κνοσσού" then name= should be identical. If people still don't believe ask for more votes in osm-talk or tagging mailing list. RicoZ (talk) 10:54, 10 September 2015 (UTC)

The common default name

Hi! Key:name: "name - The common default name". Do these words mean, that this name should be known by (almost) everyone? I try to explain my question. For example, we have an object, which has (official) name, but this name is not known for everyone. Does it mean, that we can't add name tag to such object? For example, there is a church, which is called "Church of St. Maria", but (many) inhabitants don't know this fact, because they are atheists and are not interested in names of churches - so people can say, that this is church, but can't say, what church. Another example, there is a building, which is called "House of burgomaster Smith", but (many) inhabitants don't know this fact, because they are not interested in history and don't look at memorial plates. Should we use "Church of St. Maria" and "House of burgomaster Smith" or "Church" and "Building" in name tag? Or perhaps should we don't add name tag overall and use, for example, only tag official_name? Can someone explain word "The common default name"? Dinamik (talk) 11:47, 2 September 2013 (UTC)

"mean, that this name should be known by (almost) everyone?". No, it means: this name is the one that everybody should commonly know it. If you don't know the name of a church, then either write "Church" or nothing. Someone else will come later and add its name. This is the principle of collaborative mapping. Like wikipedia, we share our knowledge. The tag "official_name" has been created much later compared to "name" and was initially created for country names, e.g. "name=Luxembourg" and "official_name="Grand Duchy of Luxembourg". (btw, don't use abbreviations in "name" like "St."). --Pieren (talk) 12:02, 2 September 2013 (UTC)

language specific extension also for alt_name, old_name etc.

Seems to be pretty obvious to use eg old_name:de=* ? RicoZ (talk) 22:58, 16 January 2014 (UTC)

Avoid transliteration, why?

This has been added to the page:

Saying something was discussed on IRC without the discussion offers no real proof that, for example, it isn’t imposing tricky coding for the sake of someone’s aesthetic sensitivities.

User:Wynndale 21:42, 11 February 2014‎

Yeah you're right. This should be discussed more widely really.
It was something RichardF, JonathanB & Someoneelse started chatting about in relation to edits observed recently, in which somebody transliterated loads and loads of English place names to add Ukrainian uk:name tags. They were using a this tool: ([4]?) which seems to guide people to add transliterated place names.
So those guys felt strongly that this was not good mapping practice. I was a little surprised about this, so discussed a bit on IRC. It seemed like something which should definitely be documented, so I captured the points of the conversation, and showed it to them afterwards. They're of the opinion this is documenting accepted tagging practice.
But yeah I did have the feeling that this was unlikely to go unquestioned. The reasoning is all there though (in brief) I wonder if we should give a more stark example. There's a slippery slope with transliteration. Clearly we don't want every road name transliterated in an automated process. What about every village name. Probably still a bit waste of database space, but... personally I'm less sure about that.
-- Harry Wood (talk) 02:16, 13 February 2014 (UTC)
I can’t tell exactly what this tool is doing or how it’s used, but it is not just automated transliteration. I see, for example, that it says International_Stadium_Yokohama / 日産スタジアム / Міжнародний стадіон (which is Ukrainian for “International stadium”).
Some languages have deterministic official transliteration systems, so purely automated transliteration might make sense. The Ukrainian orthography does have an official system for transliterating from English. Conversely, Ukrainian law also has an official system to create Latin-alphabet place names. Of course, editors should be able to override transliteration, so that, for example, Crimea’s traditional English name doesn’t get changed to name:en=Krym.
There are also other exceptions, for example w:Winnipeg, which is officially transliterated name:uk=Вінніпег according to the modern rules, but many Canadian Ukrainian publications and Ukrainian Canadians use alt_name:uk=Вінніпеґ, according to the pre-Soviet rules.
As long as names are valid, it is not a waste to enter them in the database. Any map user should be able to generate or view the map in any language, without having to create their own custom transliteration system. Michael Z. 2014-03-06 21:41 z

Split Key:name peg tag? We have page for names already - Names

Is there any reason against it or just everyone lazy to do this? Xxzme (talk) 11:27, 22 July 2014 (UTC)

Translate a name? is that the right term?

Currently the article says don't add transliterations of names (I'd disagree with this), and it says in effect, add the 'translation' only, if available. I'm not sure that 'translate' is the right term to use here. It makes sense only when the name has no inherent meaning, at least as far as the user knows. E.g. the translation from the original of the name of the city known in English as St. Petersburg is actually town of Saint Peter or something like that. Whereas St. Petersburg is the form of the name in English. Bit nit picky but as others are referring to the detail of this article, it should be clear and unambiguous. Indigomc (talk) 19:42, 3 February 2015 (UTC)

You are right. We should enter the foreign "name form" or something like that (localized form?), not the translation. OSM is not an encyclopedia and should not care about the meaning of Санкт-Петербург. It should only know that this town is called Saint Petersburg in English, Saint-Pétersbourg in French, etc.
As for the transliteration, I am reluctant do to it myself. Here in Korea, I add English names when I see them in the street (which is the case for all streets, but not always for shops or buildings), but I never try to transliterate them myself. But your situation may be different in other countries where Latin names are not as generalized as in Korea. Thbz (talk) 05:24, 12 March 2015 (UTC)

Ways without signs: name vs. official_name

I often see trails and small roads which do not have a name sign anywhere; however, the owner (e.g. Parks & Rec Dept) may have designated a name for the feature on some public documentation such as a guide map or a website. I guess one should use only official_name=* for these names (though JOSM warns about the missing name=* tag). In the same vein, if there is a sign but it differs from the documentation, name=* should match the sign and official_name=* the documentation. Is this the right interpretation? --T99 (talk) 22:40, 28 June 2015 (UTC)

De-duplicating name information to tags

Is there any guidelines in de-duplicating the name such that the common/default name does not even contain the most common details that forms a name? Recently I was in a conversation about naming route relations Tag:route=train and Tag:route=railway where I cannot agree with this person about naming. The main issue is that the route names are truncated to be void of any useful information.

An example is the JR Joetsu Shinkansen and JR Shinkansen (Toki Train) being shortened such that only the identifier name (i.e. Joetsu and Toki) is used as the common/default Key:name. The remaining information is to be tagged using Tags such as Tag:highspeed=yes and the route relations Tag:route=train and Tag:route=railway respectively. Using other examples include such as the Channel Tunnel (as on this page) and Takeshi-dori (as in Japanese road), the names should be shorten and de-duplicated into Channel and Takeshi as the common/default name by their naming convention with the Tag:tunnel=yes and Tag:highway=road.

I feel that the naming convention is ambiguous, because the common/default name does not convey what the object is meant to be. The only way the name can be useful is in combination with the Tags. The identifier also lacks context if used in normal speech or writing without the remaining parts. This is especially a problem for parts of a name that locals take for granted and deemed redundant, such as the railway operator and the object/relation type which significantly alters what the name can quickly convey without having to resort to additional tags.

This is where it was suggested that the common/default Key:name must be the Key:official_name, which in the case of Takeshi-dori is officially named on a government website and makes the inconsistency in application of naming rules acceptable. In another case where the website mentions the identifier (such as Toki) but have the object/relation type (such as train) somewhere else in the page, the common/default name which follows the official name then becomes only the identifier (in this case Toki). I also disagree with this point since I believe that the common/default name should be representation of what can be used to identify the subject and may or may not be the official name. I believe that the naming convention should be consistent and be applicable to all relations of a similar nature, which can facilitate searching for similar objects/relations.

The areas where I was told to reference includes the following pages. However, looking through the following references I cannot come into agreement with that point of view where it states that de-duplication is a good practice or a good idea, and where would I violate/dissent from the referenced pages. Thus, I would like to ask for any opinions on this matter taking into account these references that were quoted.

--JaLooNz (talk) 16:49, 4 August 2015 (UTC)

Map what is on the ground - if there is a real world name table somewhere that is what should be mapped. Official and common street name comes second. If people are referring to it mainly as "Joetsu Shinkansen" than that is what should be the name.
Just because that fact that it is a railway can be deduced from other tags does not mean that the name should not contain that "railway" - a name is a name and if a road is officially named "Long Avenue" we don't strip the Avenue from the name just because it is a synonym to road and it is obviously a road.RicoZ (talk) 16:16, 5 August 2015 (UTC)


According to taginfo, there are over 3K usages of the tag "full_name". Shouldn't we add it to the section "key variations"?

-- Species 17:09, 12 October 2015 (UTC)

"name" should not be an abbreviation, there is already official_name so what should be full_name good for? RicoZ (talk) 21:20, 13 October 2015 (UTC)

name:left=* and name:right=*

I added a section about left and right names (name:left=* and name:right=*).

This is in wide usage already (see and ), so it deserved some info on it.

Other ways of tagging don't cover the all use-cases:

  • Using wind directions isn't possible, as the double-named way may be u-shaped or very bended.
  • Using country codes (like name:be=* and name:nl=*) isn't practical either, as boundaries may also be municipalities that have no code (or something that's highly dependant on the country it's in, so not practical to use).

--Sanderd17 (talk) 07:57, 7 December 2015 (UTC)

If you read the values associated, they are used for City names (and not street names). It is "widely" used because it was an old tag for boundaries and discarded for the better relation use. It's not clearly explained, because it would only work in a way used by the boundary relation (instead we usually have two overlapping ways). In the overlapping case, left and right cannot be easily recognized.

Arlas (talk) 14:51, 7 August 2016 (UTC)

Removing Tags name_1 and alt_name_1 from wiki

I propose, to remove the tagging of name_1 and alt_name_1 from the wiki. Most mappers reject tagging with _x suffixes and it makes no sense to have them in the wiki as a scheme for good mapping.

better use diverse name-tags

Mappers should be motivated to use semantic more rich name-tags like loc_name, old_name, short_name and so on. If theere is a name that does not fit in this scheme, alt_name can be used. If there are multiple names that does not fit, alt_name can be used with semicolons.

semicolons instead of _1 suffixes

Semicolons for multiple values have already been established even though some mappers don't like them. Precise tags should always be preferred (like the mentioned diverse name-tags), but we should not use _1 suffixed tags instead of semicolons. Their only advantage is the better legibility for human eyes, thats a reason why some people may favour them over the semicolon. But for mechanical computation, it is easier to regex the semicolon than crawling through all possible existing suffixed tags. Furthermore the semicolon is already established and has been accepted for such special cases with multiple values.

iD-Editor problem

unfortunately, the iD-editor is creating such prefixed tags and is training newbies to use them as a good tagging practice. When you use the raw-tag-editor and tries to add an already existing tag, iD does not throw any error or information but adds the tag with a suffixed number like _1 or higher. It suggests to the unexperienced mapper, that this is a usable method to add multiple values, although this suffixing is only made to prevent the user of deleting data. We still couldn't convince the developer, that this suffixing method leads new mappers to bad practice (

how the name_1 and alt_name_1 came to the wiki-heaven

But actually, my intention was to propose the removing or marking of name_1 and alt_name_1 tags in the wiki (the iD problem should be discussed in a new topic). Inititally, the alt_name_1 tag has been added by a Nominatim developer in Nov'14. The origin for this decision can be found in this discussion on talk ( that took place in Sept'14.

There, a member of the HOT team described a problem, that their manual massedit caused the tags alt_name:2 and alt_name_2. Now he wants to have a mechanical edit to change all alt_name:2 to alt_name_2, preferably worldwide. That also caused a readable discussion about the sense of suffixed tags. But already before starting that discussion, the author asked the nominatim team for adding the alt_name_x tags to the nominatim search. And the Nominatim developer did so and consequently added it two month later to the wiki. Today there are over 5500 alt_name_1 tags. But only a few of them outside of the mentioned HOT-area in western africa. Nearly half of them, are NOT combinated with alt_name!

The tag name_1 was not proposed in any way, this one has only been added in Aug'15 because it exists in the database. By comment "Document de-facto name_N variant". That is true, currently there are about 800.000 tags with name_1. But when you look on the taginfo map, or the combinations, you can see that almost each of them results from the Tiger-Import (, That tagging-scheme should not be proposed in the wiki for using.

It even makes less sense to have alt_name_1 AND name_1 because they do not differ in any way.


I propose removing the name_1 and alt_name_1 from the Map Features or rather marking them and to explain that and why they should not be used. And after that we can convince iD Editor to stop creating them automatically :)

german readers can also take a look into this discussion in forum:

Hakuch (talk) 18:57, 9 January 2016 (UTC)

I support Hakuch in this case. *_[1..n]-keys are not semantic and unclear. Does _2 mean it overwrite _1, is it a kind of sorting in terms of "weighting" a value, ... Use specific values and in case of multiple same weighted values use semicolon-style. --Dooley (talk) 20:15, 9 January 2016 (UTC)
I agree 100%, thanks for your commitment, Hakuch! iD developers hopefully might consider changing this.--geow (talk) 23:06, 9 January 2016 (UTC)
I also agree, the only limit I would see while using semicolumns would be very long names, but I don't think it should be the default when tagging multiple names. --Gileri (talk) 00:12, 10 January 2016 (UTC)
It might not be neccessary because there weren't any negative comments about that all the time, but I started a formal proposal in the wiki. I shortened the RFC duration to one week, so voting will start on 16th. please comment there, thx Hakuch (talk) 10:59, 10 January 2016 (UTC)
I agree that tags like that should not be in use. But I think, while all these tags are not changed to reflect new scheme and while these tags still exist in presets of editors (here, I'm not competent enough to tell, where exactly they could be found), these tags should not be removed from Wiki - they should be labeled as "obsolete" and "not recommended". Also, JOSM validation presets should have them listed (just like addr:postcode which is now just postal_code, and JOSM warns you every time you trying to save an object with obsolete tag). Everything that exists in the main database should be documented and described. --BushmanK (talk) 18:15, 14 January 2016 (UTC)
Yes, I agree with you. I wouldn't like to just remove them but to show where this tags come from and why they should not be used Hakuch (talk) 20:52, 14 January 2016 (UTC)
I disagree with this proposal, those tags exist for a very good reason. --Vincent De Phily (talk) 14:31, 15 January 2016 (UTC)
Thankfully the _1 behaviour of iD has been changed. I say "thankfully" because I agree with Hakuch on balance, and I think mappers were mostly doing _1's by mistake in iD anyway. -- Harry Wood (talk) 00:11, 31 July 2019 (UTC)

Very long names. bad practice/bug?

The maximum size for a value of a tag is 255 characters, and some people take it right up to the limit with their names. I've made a listing tool which shows the the Long Names of OpenStreetMap, and blogged a bit more detail about it here. This raises some mapping best practice type questions related to names.

Tricky question: How long can a name be before it's really more of a "description" (and so maybe belongs in key:description)? Or is there some other more concrete reason why we can say this mapping of university buildings with a stupidly long names is bad practice?

Easier things: I think we can all agree that it's a clear bug to be fixed when people try influence label placement by writing names such as "Kadamwadi road[space][space][space][lots more spaces]Kadamwadi road" [5]

-- Harry Wood (talk) 22:29, 31 August 2016 (UTC)

In response to diary comments... OK. Let's think about the harder question. This example of university buildings which have a crazy long name tag listing a load of different departments.
What is the "name" of this building? What do people call it? That's the question we need to ask ourselves.
Seems like key 'department' might be a better fit for this value (See Tag:amenity=university#Faculties and departments and taginfo)
Here's a good illustrative example: "department=Computing and Informatics, name=Mary Ann Evans" . Now a university building might not have different name like "Mary Ann Evans". In fact to me it does seem valid for the name to be the same as the department if that's the name people call the building.
Here's another example where the name is a building number. If that's what people call the building, then that's the name.
If it doesn't have a name name tag I guess. Maybe that is the case for this building. Maybe people don't particularly refer to the building by name, just to the more specific department within it. In this case I guess there's no name tag for the building.
Having such a long semi-colon separated value within the 'department' key seems less problematic, so I think my main suggestion would just to swap out the key 'name'->'department'. Although we might also rewrite to be more compact. I mean rather than department=Department of Biology;Department of Radiology it could just be department=Biology;Radiology
-- Harry Wood (talk) 01:08, 24 November 2016 (UTC)

Discourage redundant "name:xx" tags

It should be strongly discouraged in this Wiki to spoil the database with redundant "name" tags. It's not only Berlin with 191 entries (see above), but some bored users have also started to "enrich" the database with copies of int_name in their favourite languages (but what about the other several hundreds languages?) for a lot of little Greek villages.

In the famous Samaria gorge on Crete you can find a GOOD and a BAD example close to each other.

Useful translation (way 27524450): name:de=Samaria-Schlucht name:en=Samaria gorge name=Φαράγγι της Σαμαριάς

Stupid redundant copies (node 1432544825) int_name=Samaria name:de=Samaria name:el=Σαμαριά name:en=Samaria name:fr=Samaria name=Σαμαριά --GerdHH (talk) 11:31, 15 April 2017 (UTC)

UK rights of way: "prow_ref" as name

Hi all. I'm new to OSM and I've been working on public rights of way in my local parishes in Derbyshire, UK. Where a path or track doesn't have a local name (e.g. "name=Primrose Lane"), I've been adding the rights-of-way reference as the name (e.g. "name=New Mills FP 3") as well as putting the same information in the prow_ref=* tag. It's been suggested that I shouldn't do this, but I would contend that the right-of-way reference is the name of the trail when there is no other name. In rights of way, planning and walking circles, you often hear people talking about "New Mills footpath 3" or whatever. I acknowledge the guidance that "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", but personally I think this is a slightly different case to those where the reference is an obscure, context-free numeric identifier that is never used in a human context. I personally find it useful to have the rights-of-way labelled on the map in my local area, and I'm not convinced that adding this information detracts from the map in any way. Dave.Dunford (talk) 11:35, 23 October 2018 (UTC)

Sorry, but no. It is not the name so it does not go in the name. 'The map' you use may chose to display the prow_ref value, possibly in addition to the name and/or where the name value is missing. But that choice needs to be available to the map maker, you should not force it on them by using the name tag. Warin61 (talk) 23:14, 23 October 2018 (UTC)
"It is not the name". This is where we differ: I maintain that it is the name, when there is no other. Dave.Dunford (talk) 08:45, 24 October 2018 (UTC)
No. Seems wrong to me. I guess the reason you're tempted to say it is name, is just because it renders it, but... well it's not a name is it? It might be more reasonable to argue that prow_ref values could also be put in the ref=* tag... might be. -- Harry Wood (talk) 23:51, 30 July 2019 (UTC)

Edit to "Union Pacific Railroad" section

It would be good if the whole "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" was removed now that the operator and owner tags are widely used and are actually tagged on the railroads now. Because someone used it as impetuous to add UP to all the Union Pacific lines when they all have both operator and owner tagged on them. Not only is it massively redundant, it's also wrong usage of the name tag to include the operator in it when the lines aren't officially named that way. So it would be good if there wasn't a suggestion to do it that way. Otherwise, people who don't know any better might wrongly re-tag more railroad names then just the ones that happened with Union Pacific.

I'm wondering if I should contact someone from the DWG to see if the edits can be reverted also. As fixing them all manually would be pretty tedious at this point. --Adamant1 (talk) 08:24, 24 April 2019 (UTC)

name capitalization

I'm wondering if there is somewhere in the wiki any information (rule of thumb or policy) how to deal with capitalization of names? After little research of other sources i found these information related to the topic. Osmose validation check[1]/[2]/[3] and some hints of users in the german forum [3]/[4]. Is there any consensus to this, which potentially could be added to the name=* wiki page? What was the source/base for the Osmose validation rule? Or where could be found out this?
[1] List: Osmose validation check results (item=orthograph & class="Name with uppercase")
[2] Map: Osmose validation check results (item=orthograph & class="Name with uppercase") (e.g. bbox Paris)
[3] Wiki: Osmose issues orthograph (5010)
[4] Upper case lower case of names (en) (automatic google translation)
[5] Gross Kleinschreibung von Namen (de) (original)
--MalgiK (talk) 15:11, 12 January 2020 (UTC)

See also recent (I will not attempt to summarize it as I have some strong opinion on this topic). See also that had some discussion on this topic but I am unable to find them Mateusz Konieczny (talk) 11:23, 13 January 2020 (UTC)

Is an inscription the right name?

The article (nor this discussion page) says nothing about whether incriptions (see Key:inscription) are good names. For example, many boards with a map (Tag:information=map) have headings that could be used as names. What do you think, is it a good practice to tag them as names? --Paavobave (talk) 19:06, 3 May 2020 (UTC)

Depends on a case. Many shops have sign with text (that strictly speaking is inscription) that typically, but not always is their name. For information boards I think that both "they have no real name and it would be wrong tagging for the renderer" and "this can be argued to be a name" are defensible. I would avoid adding such names, but I would also not remove them if added by others. Mateusz Konieczny (talk) 22:15, 3 May 2020 (UTC)

First or 1st?

Is there a preference between numeric (with digits) and and spelled-out (with letters only) cardinal numbers (other than that the address "1 1ST ST" would be quite funny) in street names? One approach is "do whatever the city does in their street name signs". Some cities prefer one form, some the other. I can see examples of both all over the country.

But what if the city can't decide? Take the City of Lincoln, County of Placer, State of California for example. All the old small worn-out dull difficult-to-read-at-night signs use digits. But in the last 30 years, the old signs have given way to new shiny signs with only letters while the city has grown 7-fold in population. But since a couple of years ago when state route 65 was rerouted around the city center, the newly named main thoroughfare, Lincoln Boulevard, has received new sparkling fine street name signs at all intersections and they are using digits again for all the numbered cross streets. Go figure.

I checked the online address checker of the US Postal Service and they seem to prefer digits, correcting "first street" to "1ST ST". But OSM is not USPS.

Any recommendations? -- T99 (talk) 03:55, 16 October 2020 (UTC)

I would ask local community, probably on level of entire USA (see regional talk mailing list or OSM US slack channel) or ask how others mapped in other regions. Such formatting preferences issues are often handled not on global level but on country level Mateusz Konieczny (talk) 19:32, 17 October 2020 (UTC)

Tagging nameless objects as being nameless

Anyone know of a tag that can be used to tag things as being nameless that isn't either a fixme or leaving a note? I ask because there's a lot of things like parks that don't have names in OSM and it would be good if there was a way to know if they don't have names in the first place or if the name just hasn't been added yet. Name=no seems wrong. Maybe something like no:name=yes would work. That doesn't sound right either though. --Adamant1 (talk) 23:02, 27 December 2020 (UTC)

Thanks. It is in the article. I guess I just missed it. --Adamant1 (talk) 19:17, 28 December 2020 (UTC)

Country dependant names

How to tag a feature on or near a national border that has a different name in both countries, but both names are in the same language? For example, this pass is called "Col de Conche" in Switzerland and "Col de Braitaz" in France. --Dafadllyn (talk) 20:35, 2 May 2021 (UTC)

One may use alt_name=* and/or alt_name:fr=* for less dominant form. The tricky part is when both are basically with the same popularity. Mateusz Konieczny (talk) 09:47, 4 May 2021 (UTC)
In theory, one should be able to use name:fr-CH=Col de Conche and name:fr-FR=Col de Braitaz. ---- Kovposch (talk) 11:37, 4 May 2021 (UTC)

Historical Names

Excuse my ignorance, but the Historical Names section seems to contradictory. On top of the page is listed the tag old_name=* for "Historical/old name". The old_name page says you can use the date namespace suffix so... this section seems incorrect to me. It seems "more proper" that name:1953-1990=Ernst-Thälmann-Straße should be old_name:1953-1990=Ernst-Thälmann-Straße. Am I thinking this correctly? BubbleGuppies (talk) 08:18, 8 January 2022 (UTC)

There are multiple people with different preferences for tagging schemes. I would also add old_name=Ernst-Thälmann-Straße that has benefit of avoiding verifiability issues and I would prefer this form Mateusz Konieczny (talk) 11:43, 8 January 2022 (UTC)

Multi-line names

The sign in front of City Hall says:

City Hall (big letters, and then a second line:)
Highland Park (small letters)

If I use

name=City Hall Highland Park

it sounds like bad grammar.

name=Highland Park City Hall

is great, except it is not the Ground truth.

 name=City Hall \n Highland Park

is the Ground truth, but isn't a portable way to express the second line. What to do? Jidanni (talk) 17:41, 17 November 2022 (UTC)

I generally use a slash to represent separate lines, like:
name = City Hall / Highland Park

Hope that helps! JesseFW (talk) 18:28, 17 November 2022 (UTC)

I don't think non-existent punctuations should be added except in extreme circumstances. Names are not titles or inscription=*. What do the address inside use? --- Kovposch (talk) 05:27, 18 November 2022 (UTC)
I think if there isn't a better way to handle it, this is an "extreme circumstance" -- but looking for how it's spelled internally (i.e. on signs inside the building, or return addresses, etc.) does seem like a better choice. JesseFW (talk) 15:27, 18 November 2022 (UTC)
@Jidanni: What would it be called in prose (in general, not just in addresses)? When I've encountered this situation in the past, typically for the name of a division of a bureau of a government department, I've tagged something akin to name=Highland Park City Hall or name=City Hall, Highland Park. I don't think rearranging the two lines is necessarily a violation of ground truth. That's extremely common for signage in languages that put adjectives after nouns. Besides, if something has an overridingly common name that isn't signposted verbatim, the common name is typically tagged as name=*. – Minh Nguyễn 💬 23:25, 20 November 2022 (UTC)

"name=City Hall, Highland Park" I like it! Thanks. Jidanni (talk) 04:12, 21 November 2022 (UTC)

More explicitly discourage place names in names?

In the list of "don't"s we already have: "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 - I wonder if this would warrant its own section, "Don't use place names in names". Many things actually contain a place name in their name, especially when they are branches of something larger, like "The XYZ Hotel New York" (see eg where a SEO mapper named a hotel "DoubleTree by Hilton Hotel New York City - Chelsea"). These names are undoubtedly "correct" as in "that's the name the brand department wishes the place to go by", but they're also undoubtedly not the names used in practice (you will say "I walked past the DoubleTree hotel" and not "I walked by the DoubkeTree by Hilton Hotel New York City - Chelsea"). It's not only hotels though, it could be outposts of a museum or a university or anything else that has branches (for example the original "Madame Tussaud's" in Marylebone is just that, while world-wide branches carry a place name that we actually include in OSM e.g. I wonder if we should suggest that the place name may only be part of the name in extraordinary cases; otherwise the full name including place name could go into official_name and the place name should be purged from the name tag. --Woodpeck (talk) 10:01, 15 February 2023 (UTC)

Coincidentally we're having a somewhat related discussion on the talk-gb mailing list at the moment, relating to infrastructure such a sewage treatment plants and substations. I don't think there's an easy rule here, unfortunately. One possible rule of thumb which might be handy is "does this name tag make sense as the first line of a street address?" -- Russss (talk) 10:28, 15 February 2023 (UTC)

Add section on correct spelling of names

Hi, after some discussions in the German community (here and here), I'd like to propose to add the following section to the page:

Proper name spelling

Conflicting signs "Karlstraße"/"Karlstrasse" for the same street. In this case, Karlstraße would be the correct spelling in Germany.

OSM follows the on the ground principle, which means that street names and other proper names are generally entered as they appear on signs, even if those names deviate from the general spelling rules. Exceptions are made in the following cases:

  • If the name isn't present on any signs, follow the local spelling rules. Make sure that the name is really locally known and you're not inventing or constructing a name. However signs are not required for a name to exist. Most natural features like woods and lakes do not have signs. In many countries with weaker governments or lower literacy levels, the names of hamlets and streets will not be written down, but can be verified by asking the local people.[1]
  • Names are adapted to the local capitalisation rules; for example, in English, title case is generally preferred; in German, the first word of names is capitalised and nouns, adjectives, and proper names in the following words are capitalised, however capitalizing adjectives is sometimes optional[2]. Note that multiple capitalisation styles could be right, so be careful and don't over correct. For example in German both "An der alten Brücke" and "An der Alten Brücke" (meaning "at the old bridge") could be considered correct names.[3] 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.
  • Abbreviations that are used to save space and that can be written out without causing confusion should be written out, for details see Abbreviations.
  • If multiple different spellings are used locally, the most common or most correct is preferred. The other spelling can be entered as alt_name=*.
  • Deviating spellings that only occur because some characters were not transcribed or printed correctly should be replaced with the proper spelling, but within reason. If there is a "Jolin Tsai Street" in an English-speaking country, do not restore the original spelling of the name as something like "蔡依林 Street", but a sign with "GROSSER WEG" in Germany should be turned into name=Großer Weg (which would be the correct local spelling), because here the sign maker probably could not write a capital "ß", which was only officially adopted in the German language in 2017.
  • When old/outdated and new spelling variants are both present, the newer spelling should be used as name=*. Exceptions are possible, for example, if a city or region explicitly prefers the old spelling of a name for historic reasons and any signs with the new spelling are obviously an oversight. Proper names included in street names usually shouldn't be adjusted to new spelling variants.
  • Avoid including special characters that are not pronounced, are decorative, or substitute normal letters (e.g., "♥" used for "heart" or "love", "!" used for "i"). Stylized spellings of trademarks and company names should be adapted to the regular capitalisation and spelling rules, e.g. a sign that says "TACO 🔔 BELL" would be written as name=Taco Bell. However do not change spellings if doing so would cause confusion or if the original spelling is much more common.
  • If local signs do not match the data in official publications/databases/directories, the official name can be tagged as official_name=*, but make sure you're allowed to use that data. Note that databases can contain mistakes or might have limitations in maximum entry length or allowable characters.

In principle, not all special cases and exceptions can be mapped into rules. When still in doubt, use common sense. You may also find the following questions helpful:

  • How would you write the name in a mailing address, e.g. when sending a letter?
  • How would a navigation system pronounce the name and what name would a user enter to search for the feature?
  • How does the name appear in official directories? Are any discrepancies to signs or to proper spelling rules intended or likely mistakes?

(Editable here: User:Jonathan_Haas/Spelling_of_names).

I hope the proposed rules already follow usual practice and could clarify some things. Feel free to change things or to improve wording directly in the proposal (I'm native German, so my English might not be perfect). Controversial changes should maybe be discussed first. -- Jonathan Haas (talk) 12:07, 16 May 2023 (UTC)

  3. Depending on the exact rules you follow and if "Alte Brücke" ("old bridge") is the proper name of a locality, or just a description. "An der Alten Brücke" would never be wrong, but don't correct "An der alten Brücke" if it could also be right.