The proper full name may be “Wall Street” or “Long Island Expressway”, but “Street” and “Expressway” can be omitted if necessary when there’s enough surrounding context. This kind of elision is extremely common in print maps, because a slightly ambiguous label is still more informative than no label at all. If you really need to know the full name of the street, you might have to guess whether it’s Chartres Street, Chartres Avenue, or Chartres Boulevard, but at least you know it’s basically called Chartres and it’s a street:
In my opinion, we can generally rely on data consumers to implement these shortenings at the same stage in the code that implements abbreviations, as long as the rules are well-defined. In English, both transformations would involve more or less the same list of words. short_name=* is still needed for unusual or unpredictable shortenings, such as “Doctor Martin Luther King, Junior, Boulevard” as “MLK Blvd.” in English, or 北京天津河北 (Beijing–Tianjin–Hebei) as 京津冀 (Jing-Jin-Ji) in Chinese.
I would think it would be just the opposite. For example, in the US the names of mountains take various forms, e.g. Mount , Mountain, Peak, Spire. It would be fairly easy to strip out Mount, Mountain, Peak, Spire, etc., but if you were to start out with just the “bare” name, how would you know which of the “descriptive” names to add on? In any event, for some types of features, I wouldn’t recommend displaying just the “bare” name as there can be multiple features of the same type with the same bare name, for example, Rowe Peak (Node: Rowe Peak (358945036) | OpenStreetMap), and Rowe Mountain (Node: Rowe Mountain (358911764) | OpenStreetMap).
There is also the case where the full name of one feature forms the “bare name” of some other feature, e.g. Longs Peak Road (Way: Longs Peak Road (6175687) | OpenStreetMap). If you strip out the “descriptor”, then you label the road “Longs Peak”, which doesn’t make sense.
It wouldn’t make sense in plain text, but it might on a map, on which roads have a particular style treatment. For example, on the map of New Orleans I posted earlier, “Elysian Field” is clearly a street, not a field. You don’t even have to refer to the legend to distinguish it as a street label, because it looks just like all the other street labels. (However, you wouldn’t know it’s an “avenue”.)
Things have different names depending on who you ask. OSM simply tries to collect these usages and that’s one of the reasons for the massive amount of *_name variations.
Consumers of maps therefore can’t really rely on any particular usage; Choosing to use name as a label is usually done out of convenience and being “good enough”. I don’t think enforcing any sort of standard is going to be either practical nor particularly useful.
Mammi71
(One feature, Six mappers and still More ways to map it)
86
Due to a very well-known book ‘Christiane F. - Wir Kinder vom Bahnhof Zoo’, this is no longer a loc_name.
Yeah, another ambiguity. I guess one can make the case that it’s a local name that’s known to a wider audience?
Different example: Ku’damm. I even had to think for a second what its real name is. I’d still consider it a local name eventhough I and all my friends who’ve never been to Berlin would understand what is meant.
It’s entirely arbitrary.
That’s actually what happens in some cultures, especially in South Korea!
In Korea, descriptive terms are rarely omitted unless it’s very clear or efficient to omit them.
In South Korea, “Seoul Station” is not far from “Seoul Station Subway Station”, and some people get confused because “Seoul Station” is shown as “Seoul” and “Seoul Station Subway Station” is shown as “Seoul Station” on a map. (Unfortunately, there’s no graphical distinction between the two, and not many people seem to notice).
Of course, in real life, confusion doesn’t cause much inconvenience, because they are close together and in everyday conversation, we add descriptive terms as needed…
Another example is people who write stops in their photos or reviews of a particular place.
And coming back to the point, there is a frequent debate in OSM editing about whether we shouldn’t add descriptive terms according to common Western (?) practice, or whether we should add descriptive terms according to the practice of our own culture. Even since I posted this question, there has been a mass removal of descriptive terms from station names in South Korea.
Coming back to the original question: consider my local zoo, the “Erlebnis-Zoo Hannover” (yes, that’s what it’s called). Everyone would refer to it as “the zoo”, unless they came from a different city, then they would say “Zoo Hannover”. Under normal reasoning, we should end up with loc_name=Zoo + name=Zoo Hannover + official_name=Erlebnis-Zoo Hannover, yet we’re not doing it, we’re only tagging name=Erlebnis-Zoo Hannover. We’re definitely not stripping away the “zoo” in any of the names for zoos. Is it a cultural thing? I don’t know.
For me, this is clearly something that should be settled in a local community, like the Korean one, and cannot be decided on a global scale.
I think you’re right.
My original question was whether it is common in some English-speaking cultures to exclude descriptive terms from “official representative place names”.
The new question that arises is,
Is it common in some languages to omit the descriptive term and still be able to use it as an ‘official representative place name’ if it makes sense?
Should ‘London Bridge’ be considered the official representative name of the station or a contraction of the station name?
(If I get into a taxi with my suitcase and luggage and say, “London Bridge, please”, will the taxi driver take me to London Bridge Station without asking?)
If omitting the descriptive term is the official representative way to write it, why not apply the same principle to other landmarks?
Why is it that the map only shows the city name “Charleville-Mézières” when the signboard outside the station clearly says “Gare de Charleville-Mézières”?
How can this discrepancy be explained?
Addendum: If it’s just a convenience for visibility, as some people claim, wouldn’t it make sense to write the official representative name properly and display an alternative name, such as a common name?
Addendum 2: From your comments, I realized that what I meant to say was not “official” but something closer to “formal” or “representative”. I’m not sure which word is better, but I’ll change it to “representative” for now.
The following bridge is usually referred to as the Merced River Bridge. Officially, the “Bridge” is optional, a minor detail. So can you really “cross the Merced River on the Merced River”? Most would find that unintuitive. Yet this sign relegates “Bridge” to a footnote, and any map that labels this bridge might omit it entirely:
As far as English is concerned, the descriptive word only became part of the name proper fairly recently:
Place naming conventions have also evolved over time. The U.S. Census Bureau still insists on referring to “New York city”, with the lowercase C signaling that the word is optional and only included for maximum precision.
Railroad stations are tricky, because traditionally they were place names in their own right. In much of North America, many stations predate any settlement of appreciable size, historically serving as a projection of the railroads’ economic power. If anything, the disambiguating word would’ve belonged on the settlement rather than the station.
The English Wikipedia’s naming conventions for railroad and other public transit stations requires descriptive words in lowercase, as a nod to this history, but also to avoid naming conflicts with more widely read articles about cities and towns. That’s a constraint we obviously don’t have: our software is perfectly happy to store multiple features with the same name. At the same time, the guidelines also acknowledge that some stations have the descriptive word as part of the name proper.
This mass edit should receive the same scrutiny and discussion that the local community gives any mass edit. If the consensus is that the name=* tags should omit the descriptive suffixes, then the community has significantly more work to do to ensure that data consumers automatically restore the deleted words in contexts that need them.
If it was automated edit was not discussed or not accepted, it definitely can be reverted. You can ask DWG for help. Or someone else in local or global community.
(Note, if it was discussed and accepted by local community then you should not revert, but if it was not then anyone is allowed to revert it without further reason)
Your explanation makes it clear why some languages often omit descriptive terms.
However, I think the name of the bridge, “Merced River”, is an example of a blatant misuse of the name of a place.
Even in our culture, where we don’t usually omit descriptive terms, we often don’t add them when it’s obvious that they’re not necessary.
We don’t use descriptors on the destination board in the station or on the ticket to indicate the destination.
I think it would be wrong to treat the name on a destination signboard in a station or on a ticket as the ‘official representative name’.
And most of all, reversing it is a secondary issue.
If we don’t make the principles intuitive and clear, it’s going to be a recurring problem in the future, and we’re going to have the same questions we have now.
Commercial maps like Google Maps are managed by internal people anyway, so they can share their own principles internally without publicizing them.
However, for maps that anyone can edit, such as OSM, I think the standards for editing should be clearly communicated to the outside world.
And I think the clearer the criteria, the less confusion editors will have.
My guess is that the answer is yes. (Disclaimer: I lived in London for 2 years about a decade ago but I’m not really a Londoner.) If only because there is no other obvious destination named London Bridge. There is the bridge, of course, but it is not a destination of its own and so it’s unlikely the tourist wants to get out of the taxi right at the bridge.
I would bet that it’s also the case for all other central London railway stations like Liverpool Street or Waterloo, because the railway stations are major destinations.
Certainly if you get into a taxi in Gdynia and ask for “Gdynia Główna” you’ll be brought to the railway station. Non-tourists would probably ask for “dworzec główny” or “dworzec PKP”, but “Gdynia Główna” would be understood.
We have official_name=* if you want to do that – if you can find the definitive official name. (Particularly hard in England, where a lot of things are based on unwritten traditions.)
If you want to discuss naming standards for South Korea, it might be more productive to discuss this with other South Korean mappers and develop a local consensus, rather than asking about England and France and “some languages”.
Regions and communities are definitely allowed to have local guidelines that deviate from “worldwide” OSM guidelines (inasmuch as that even exists), and there is absolutely no requirement to have Korea OSM mapping guidelines match OSM guidelines for England or any other regions. If South Korean community wants to have “station” in their names, you can.
I would not go so far, there are limits here that cannot be exceeded.
But as far as details in Korean names go, I would expect Korean mappers to be experts and there are no global guidelines here beyond meaning of name tags.
I would argue that “Gdynia Główna” and “Dworzec Główny” are two different places, as “Dworzec Główny” is the name of building next to train stop “Gdynia Główna”.
I don’t know Gdynia, but eg. in Kraków you may be brought to a slightly different place if you mix Kraków Główny and Dworzec Główny as the building of the station is joined with shopping centre.
*In Polish we use “stacja” for the place where train stops, and “dworzec” for the building. I guess in English it’s not that easy.
Are you referring to official_name=*, or perhaps the common name that goes in name=*? In general, I think this is a matter of convention rather than right or wrong.
In North America, we often split the difference by distinguishing between the name of the station proper versus the name of the overall station complex. This is convenient because the complex often has a more generic name that acknowledges other transit services like buses, and because the station proper can go by different names depending on which line you take to get there.
For example, I often ride a train that serves this station in Santa Clara, California. As the train pulls out of the previous station, the conductor announces, “The next station stop is Santa Clara. Santa Clara, next station stop.” Then, as it approaches this station, they announce, “Now arriving at Santa Clara. Santa Clara, now arriving.” The timetable, passenger information displays, and running-in boards also say “Santa Clara”.
Two other rail lines serve this station, but they call it different names – “Santa Clara–Transit Center” and “Santa Clara University” – because they need to disambiguate it from another station they stop at in the same city. Meanwhile, the pillar and monument signs visible from the street refer to the whole complex as “Santa Clara Transit Center”. Some of these signs are maintained by the same agency that calls it just “Santa Clara” on board.
We’ve applied the name “Santa Clara” to the railway=station node and public_transport=stop_area relation, preferring the name used by the most frequent service to the station over the name used by the more famous national rail system. We’ve shunted the other names to alt_name=* and ad hoc name:*=* subkeys. However, we’ve applied “Santa Clara Transit Center” to everything else, including the bus station and the parking lot.
Pedantically, the top-level stop area group should also be called “Santa Clara Transit Center” based on the on-the-ground rule. However, rail mappers have a particular emphasis on consistency across a whole system, so I think they try to keep idiosyncratic names away from anything that OpenRailwayMap or the Transport style might label. Regardless, as long as both names are present on some feature in the general vicinity of the station, users will be able to find their destination in search results.
From your comments, I realized that what I meant to say was not “official” but something closer to “formal” or “representative”.
I’m not sure which word is better, but I’ll change it to “representative” for now.
building = train_station
railway = station
...
name = Charleville-Mézières
Because of that you can’t have different names for the building and the station. The name of the station (without “Gare de”) currently wins. In the history of this way you find other values including Gare de Charleville-Mézières;Charleville-Mézières.
You will find in France a lot of train station buildings with ever changing values in name or the deletion of the name tag. I would tag the building with the name at the building, “Gare de Charleville-Mézière”, and the different element with the tag railway=station with the name that can be found at the platform. That would be name=Charleville-Mézière for sure.
Buildings with a name but without “Gare de” do exist, mostly older ones, here Tieffenbach-Struth: