“Name is the name only” section of the Names page

[darkonus]

Hello! I have been updating the translation of the documentation for my local community. I moved local naming practices into the article Uk:Key:name:uk and moved the section about abbreviations into a separate article Uk:Abbreviations. After that, I decided to update the translation of the main Names article in Uk:Names.

While working on it, I had a few ideas on how to improve the Name is the name only section and make it easier to understand.

First, I think this section should come before the sections about Abbreviation (do not) and Proper name spelling. This section actually explains what a name is in general. Only after that should there be additional context about not shortening names, fixing typos, and so on.

I also tried to reorganize the recommendations and examples in this section — from simpler cases to more complex ones, with exceptions at the end.

At the beginning, I also introduced the terms proper name, specific, and generic, which I believe are very useful for mappers. I also added an example about the town of Truth or Consequences in the USA to illustrate that all names were once invented.

Here is what I came up with. I tried to keep the original wording as much as possible:

Name is the name only

Introductory part aimed at smoothly introducing core practices and showing the simplest examples. Here and below, bold text highlights entirely new or significantly modified content.

The name tag should be restricted to the actual name of the item. The first step is to determine whether the object actually has a name. Anything can be described by its type or category—for example: house, alley, park, pitch, lake, etc. However, not every such object has a proper name. If something does not have a name, do not fill the name tag. Any additional information should be included in separate tags to identify its meaning.

Incorrect use of name	Properly selected tags
name=house	building=house
name=Mosque	amenity=place_of_worship, religion=muslim
name=football pitch	leisure=pitch, sport=soccer
name=unnamed street	highway=residential, noname=yes — see #No name, below
name=alternate summit trail	member of a recreational route relation with role alternative

Validators may detect and propose to remove the most obvious and common incorrect names, but undetected ones are also incorrect.

Names with generic terms

Examples explaining that a generic term can be part of many names have been moved here. Some formulations have been refined.

However, the examples above do not mean that a name cannot contain a type or describe an object. The official street name East 110th Street should also be recorded in name, despite the fact that the word east describes a relative location, and the words 110th and street are a number and a type.

Very often, in addition to the specific part, names also include a generic term. For example, Ho Chi Minh City, should remain intact even though the place is tagged place=city. At the same time, New York City may be correct as the common name for The City of New York, but for a city named Manchester, do not add a descriptive City.

Some objects are actually named The Lake, or The Hill. In such cases adding it as a name is fine. For example, The Lake in New York City’s Central Park is tagged with name=The Lake and not a constructed name like Central Park Lake.

Invented and real names

Moved here: advice against inventing names and examples of real names that only look constructed or invented but must be mapped. New content — an example for the paragraph about all names being invented.

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

However, bear in mind that actual names referencing the location of an object are fine, as long as it is an actual name. For example, the way Central Park Tennis Center does include Central Park in the name, because “Central Park Tennis Center” is the tennis center’s actual name.

It is certainly wrong for a mapper to invent a name for an airstrip; however, most names were invented at some point in history, so if someone invents a name and it catches on and a sizeable group of people refer to the thing by that name, then it’s ok to be mapped. In 1950, the town of Hot Springs, New Mexico, officially changed its name to Truth or Consequences in honor of a popular radio show. The show’s host promised to broadcast an episode from the first town that agreed to rename itself after the program. The residents voted “yes,” and the name stuck for good.

Names are not for descriptions

Significantly expanded section explaining which specific types of data are typically redundant in the name tag.

For descriptions, please use description=*, not the name=*. A name should not contain additional information that is not part of it, such as categories, types, addresses, ref links, owner or operator data, technical specifications, etc. The name is also not intended for explanations of the object’s state, role, or time restrictions. OpenStreetMap terminology or any other notes for mappers should not be part of the name.

The table below provides some examples of incorrect usage:

name with redundant info	Note
The Royal Albert Hall, London	Do not include the location, London, as part of the name, even if there are multiple objects of the same name
Lower Hell Hole 1030-002 Dam	Do not embed a reference number in a name just because a source (here USGS GNIS) does so; use a separate ref=* tag, for example, name=Lower Hell Hole Dam and ref:gnis=1030-002
Foobar Mountain, 8000 ft	Tag height in a separate tag (like ele=* or ele:ft=*), not as part of the name
closed pub (due for demolition)	Do not describe the object in lieu of a name. Consider the description tag and also adding an old_name tag. Objects that no longer exist should be deleted. Disused objects, such as shops, can be tagged with lifecycle prefixes. See the Nonexistent Features page for more information.
Wildwood Boardwalk (seasonal)	Do not include time-related access restrictions in the name. Instead, use conditional restrictions tags (or opening_hours=* for non-highways). example: access:conditional=no @ (Nov-Apr)
Multipolygon Baldo Forest	Do not include the object type or other OSM terminology, if it does not apply outside of OSM
Interstate 5 southbound lanes	Do not separately name parts of the same object where they are separate in OSM, but not outside of OSM. When a name would only be duplicating the information in the ref=* tag, the ref and noname=yes can be used. Note: Verify with local tagging standards as they vary per region.

Exceptions and borderline cases

Exceptions section, required to simplify the comprehension of the sections above.

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

Union Pacific Railroad — a name=* which was assigned during the USA’s 2007-8 TIGER import (of roads and rail); the correct value is the name of the Subdivision/Branch/Line and this railroad name is properly the value of operator=* and/or owner=* (there are many other incorrect values besides Union Pacific). It is OK to precede a railroad name with an operator when two or more otherwise-identically named lines in close proximity would create serious confusion. For example, naming CN Joliet Subdivision and UP Joliet Subdivision or BNSF Fort Worth Subdivision and UP Fort Worth Subdivision is sensible. (For now. Even this convention may disappear in the future as operator=* and owner=* become more widespread and avoid such ambiguities).

---

Regardless of the outcome of this discussion — I will publish the Ukrainian version of this section on the Ukrainian page in this more structured form, as Uk:Назви will still carry a note indicating that the content has been adapted to local practices.

However, if the English-speaking community reacts positively, it would be great to be able to improve this section in the main English documentation as well.

Thank you!

[campbelltree]

This style refresh looks good to me, if you get no dissents here then you should WP:BOLD and just put this rewrite in the English version of the page.

[Minh_Nguyen (Minh Nguyễn)]

A bit wordy, but fine overall. A couple of the examples are less clear because of actual naming practices in the U.S. that might be unexpected elsewhere:

@darkonus

Lower Hell Hole 1030-002 Dam Do not embed a reference number in a name just because a source (here USGS GNIS) does so; use a separate ref=* tag, for example, name=Lower Hell Hole Dam and ref:gnis=1030-002

Often the reason for this is that there are multiple dams that go by similar names. Because dams are obscure technical infrastructure, the dam operators don’t see any problem with including the reference number in the name.

Sometimes this is difficult to distinguish from a source that simply includes the reference number in the name field for no good reason. Local knowledge is required. GNIS assigns feature identifiers, but they look nothing like 1030-002, which is probably part of a local naming scheme.

@darkonus

Foobar Mountain, 8000 ft Tag height in a separate tag (like ele=* or ele:ft=*), not as part of the name

You’re probably right about this particular formulation, but there really is a peak at an elevation of 11,272 feet that’s informally named “11,272” for lack of an official name. This is a common occurrence in the western U.S., one of the reasons the local community would really like to also put feet in ele=*.

@darkonus

Interstate 5 southbound lanes Do not separately name parts of the same object where they are separate in OSM, but not outside of OSM. When a name would only be duplicating the information in the ref=* tag, the ref and noname=yes can be used. Note: Verify with local tagging standards as they vary per region.

Systematic road names still a subject of frequent, intense debate in the U.S., so I recommend picking an example from elsewhere.

[Mateusz_Konieczny]

Is there way to see before/after clearly? I do not see any obvious problems but I am not really sure how it compares to the current version and is it better

[darkonus]

@Mateusz_Konieczny, I tried using tools that compare texts, but they struggled to distinguish moved content from actual changes. WhatDiff worked reasonably well, so you might want to try it.

I marked in bold the parts I added or improved. Everything else is the original text. I also included notes for each section to better explain my reasoning.

The text may feel a bit wordy, but that’s because I tried not to remove anything—only to restructure and expand it. That said, simplifying it could be a good idea.

@Minh_Nguyen, what you mentioned about numbers and elevation are still exceptions when looking at the full range of dams and peaks worldwide. One issue with the original text is that, in some places, the exceptions are described in more detail than the main guidelines. In my opinion, that doesn’t improve clarity.

The Interstate 5 example is 14 years old. From your perspective as a US-based contributor, what would be better—moving it to the exceptions section (like the railway example), or removing it for now?

Maybe someone has another apt example for what seems to be a sensible rule:

Do not separately name parts of the same object when they are separate in OSM, but not outside of OSM.

So far I have found this examples:

Maybe Mirissa Beach (eastern part)? It consists of several lagoons and is separated by the Parrot Rock.

[Minh_Nguyen (Minh Nguyễn)]

@darkonus

The Interstate 5 example is 14 years old. From your perspective as a US-based contributor, what would be better—moving it to the exceptions section (like the railway example), or removing it for now?

Yes, I’m aware. I just mean that, if you’re going through the trouble of rewriting this section, you might as well choose examples that are more clearly accepted by the community. The kind of example is fine. The specific example can be removed for now. Once we come to an agreement locally, we can always add another example back in.

@darkonus

The name seems pretty reasonable to me. As long as the middle school isn’t a distinct educational institution, we don’t have any established tagging for which grades are served by the classrooms in a wing of a building, classified according to the local school district’s classification scheme. It is a name, for all intents and purposes.

The real issue you’re highlighting in this screenshot is that each wing is mapped as a separate building, whereas it should be a building:part=school. Maybe you could add something about that to the documentation for building=*.

[darkonus]

Further simplified the text based on feedback in this thread and saved the changes to the wiki page. Please review to make sure I didn’t accidentally miss anything:

Name is the name only - Names - OpenStreetMap Wiki

[Minh_Nguyen (Minh Nguyễn)]

I was still intrigued by this example:

@darkonus

Lower Hell Hole 1030-002 Dam Do not embed a reference number in a name just because a source (here USGS GNIS) does so; use a separate ref=* tag, for example, name=Lower Hell Hole Dam and ref:gnis=1030-002

I’m aware that it predates your edits. Thank you for rewording it to avoid stating that this is a GNIS feature ID. The recommendation to shunt the number into ref=* is a good one in general.

I think @T99 is right that “Lower Hell Hole Dam” is the name of that dam, without numbers, but one can’t assume any number is a GNIS feature ID just because it came from GNIS. GNIS got the number from somewhere else. Here’s the citation:

U.S. Army Corps of Engineers. Dams and Reservoirs List, Washington, DC. 30-Sep-1981. A listing of impounded bodies of water and associated information.

I can’t find that particular list online, but similar inventories from around that time clearly distinguish “Lower Hell Hole” as the name and “1030-002” as the dam number. They confirm that this is a number assigned to the dam by the California Department of Water Resources. It may be that whoever digitized the Corps list for GNIS went on autopilot and didn’t notice that the number was in a separate column.

It’s a funny example, so I’m happy to keep it in the article. I just tweaked it to suggest confirming first that the name really doesn’t include a number, because things like “Blanchester Reservoir Number 3 Dam” and “Blanchester Reservoir Number 4 Dam” are legitimately very common in the U.S. These are two of five reservoirs that have been built on this site so far. The numbers indicate the order of construction but aren’t part of a broader numbering system. No one ever refers to the bare integer by itself, only in full.

This happens on other kinds of features too. On many campuses or apartment complexes, each building has a unique number or letter, such as Building C or Building 81. The numbers are unrelated to addressing, and in practice people use them as ordinary names. Personally, I would tag both name=Building C and ref=C. The former is important because there’s no guarantee that a ref=* can be combined with “Building” to form a name. The latter is potentially useful to a renderer that needs to squeeze a label into a very small space, but not as important.

Large companies continue to apply the same naming method even as they outgrow their original campus and expand into many different places. Apple has scores of buildings scattered around Cupertino and surrounding cities, all named and numbered like Infinite Loop 4 (IL4) and De Anza 12 (DA12) based on the street name. We can tag both name=* and ref=* based on real-world usage. Amazon has warehouses scattered all about the country, often next to other logistics companies’ warehouses. As a practical matter, both “Amazon” and the site identifier could be legitimate parts of the name, depending on context. But I generally would not go as far as to include a number in a name of a chain store, because it isn’t useful to enough of the people who would need to look up that feature.

Ultimately, whether a systematic name belongs in name=* is a practical decision informed by real-world usage. It’s probably very inconsistent across cultures, geographies, and contexts. As long as our inconsistency reflects the real world, we’ve done our part.

[campbelltree]

@darkonus

The Interstate 5 example is 14 years old. From your perspective as a US-based contributor, what would be better—moving it to the exceptions section (like the railway example), or removing it for now?

Make the example something like “Hillsdale Expressway Southbound Lanes” “Hillsdale Expressway” oneway=yes

[darkonus]

Thank you for taking the time to check and correct the examples. Now I’m curious whether all the examples in this section can be verified for “authenticity” It seems that a mountain called Foobar Mountain does not exist.

[darkonus]

Another consideration: the examples should be as well-known as possible, since it’s more likely that exonyms exist for them, which would make it possible to localize them as well.

Need to think about this…

UPD. Worked on the examples; it seems that now all the names in this section are factual.