What do you mean by “wrong thing”? Isn’t it up to the renderer how to display our OSM data? Is it as well a wrong thing if I decide to render the ocean red and the buildings blueish?
5 Likes
I’m pretty sure our rhetoric all along has been “we recognize that the map won’t look perfect everywhere and that’s OK.” We’re a regional style and we don’t pretend otherwise – after all, it’s in the name as you point out.
The decisions and data interpretations we make are just one tiny data point out of an entire community of software that uses OSM data. Based on the objections posed so vociferously in this thread by current and former OSMF board members, you would think that a regional style supporting a semi-colon delimiter is some kind of existential threat to the project.
I think working software is the best way to demonstrate an approach to solving a problem. People can talk all day about hypotheticals, but there’s really no comparison to putting a working map in the user’s hands. If the mere existence of a piece of working software is indeed a threat to the status quo, that should prompt folks to question what the problems are with the status quo, rather than attacking the piece of software for its very existence.
The fear that our regional style is going to prompt some sort of global mass-retagging of name=*, one of the most common keys in the database, seems beyond silly and alarmist. I’m confident that mappers in Zurich, Brussels, Casablanca, and Hong Kong aren’t rushing to fire up their editors just because someone half a globe away made a map do a thing.
1 Like
Personalization is inherently selfish. Take osm.org’s layer switcher for example: each layer exercises some editorial control over which subset of OSM data to show. Yes, a map in the user’s language ignores the herculean efforts that have gone into coverage of other languages, including my own. Americana is not the first map to commit this sin and it won’t be the last.
Yet a map that adds the local-language names in parentheses is attempting to strike a compromise, reminding the user that not all the world speaks the user’s language. I shudder at the thought of an American tourist landing in a foreign country and expecting everyone to speak English. Labeling a city in the local language can help prevent that situation, but first the user has to be able to find the city with the language skills they have.
For those who prefer to see as many languages as possible on the map, there’s a “multilingual” mode that uses the name tag by itself, without any name:* tag.
(Oh no, Pascal strings…)
Judging from the screenshot, I think you’re suggesting that the renderer iterate over all the name:* tags (ignoring things like name:etymology and name:genitive), looking for substring matches within name. That’s essentially what Tracestrack is doing, but it’s too simplistic. You got lucky that “Cottbus” isn’t part of “Chóśebuz” or vice versa. For better or worse, this method would be much more reliable if the names were separated by something that can’t occur within a name.
1 Like
For those used to locally standardized delimiters in names, consider places where there may not be a standard delimiter. This road in Indiana, USA has two equally important names, both in English. These names are posted on separate signs, so there’s nowhere for a delimiter to go. The US doesn’t really have a precedent for this. Are we supposed to invent a delimiter? If so, why not a semicolon?
these cases are usually tagged with several tags, like name and alt_name
I see three possible outcomes for the change you have just made:
- Mappers largely ignore this change, OSM Americana has a bit of dead code and I have been unnecessarily negative. You have to implement solutions for other separators.
- Some mappers like the styling of names with semicolons so much that they start editing existing names. Other mappers who use other maps don’t like that names now appear with odd semicolons on these maps and revert the changes. There are regular editing wars over name tags. DWG is not amused.
- Many mappers like the semicolon style and a significant number of names get changed. Every data user that uses the ‘name’ tag (that is to say, everybody who uses OSM) suddenly sees odd semicolons on their maps, routers, search results etc. Everybody is forced to implement preprocessing of the name tag before using it. Some of the software will not have been designed for modifications of the name tag before it is used, so developers will have to spend considerable time implementing a completely different solution. They are not amused.
There must be a solution to your problem that does not force the mappers to make a choice between having a pretty OSM Americana map or human-readable output for other data users.
(For any avoidance of doubt and because I’ve been called out at it: I am speaking as a simple community member and OSM software maintainer here. All opinions are my own.)
1 Like
A question for the semicolonphobic.
At z6 of cycle.travel’s raster map style, I want to show a single placename for somewhere like Brussels. This is because cycle.travel has the design goals of (a) fairly high information density (b) not looking like ass.
I am ok with this being a single commonly-used local name, because I trust my users to be smart enough to figure that a capital city called “Bruxelles” in Belgium is probably the same one they know as “Brussels” or “Brussel”. I do not want to default to name:en because not all my users are English; it would seem like cultural imperialism; and English has historically had some really stupid names for towns outside England.
How should I do this?
You are asking how to choose a single local name in a multilingual area, but want to avoid cultural imperialism. Rather try drawing a circle with 4 corners 
1 Like
Realistically speaking, this is the most likely outcome in regions that are accustomed to the ad-hoc delimiters, although personally I’m not so bothered about the output in those regions that I’d feel obligated to figure out a solution for them.
Americana is not nearly the first data consumer to parse the semicolon delimiter in name, not nearly the most popular, and not nearly the best-funded. If it has the kind of global sway that you’re holding up as a possibility, that’s quite a statement of support for the project and its approach so far.
Ironically, Americana has managed to macgyver semicolon parsing in the one programming environment that currently lacks the obvious tools for it. I’m not really convinced that, of all the things data consumers have to do to get OSM data into a usable state, splitting a string on ; would normally be a dealbreaker.
1 Like
Semicolons don’t solve your problem. You still have to choose from many names. If you always choose the first one, we are back to editing wars about which language comes first. It also makes for a fun map in areas where the decision was to switch the order around all the time to avoid the who-comes-first conflict.
Here is how I would do it: create a shape file with the default languages you want to show on your map. You can create this from the default_languages tags and take a few hours to curate them. Once. It’s unlikely to change much over time. Or maybe ID already has something usable already. I wouldn’t be surprised. Then preprocess your names and compute name labels solely from the name:* tags by looking up the coordinate of each feature in your shape file. Add special handling for name:left and name:right. Done.
3 Likes
Obviously running a random number generator to generate labels isn’t “wrong” either if that is what you would like to see on the map. My comment was simply wrt the name of the place vs. something invented.
More than suggestive enough
Semicolons don’t solve your problem. You still have to choose from many names. If you always choose the first one, we are back to editing wars about which language comes first. It also makes for a fun map in areas where the decision was to switch the order around all the time to avoid the who-comes-first conflict.
They solve my problem for me. They might not solve the problem for maps which are less worried about looking like ass, and they might not solve the problem for DWG, but that’s not my problem.
It is, as it happens, exactly what I do. Aberteifi/Cardigan shows on cycle.travel as Aberteifi. Bruxelles - Brussel shows as Bruxelles. I’m happy with that.
Currently the separator I use basically is “either a slash or a dash”. The slash might not have spaces, the dash must (because Woluwe-Saint-Lambert - Sint-Lambrechts-Woluwe). It works.
So there are two possible things I can take from this:
- The separator for the name tag is
/\s+-\s+|\s*\/\s*/. That seems… unusual? a bit less intuitive than the;used everywhere else? But hey, OSM is like that. If we document this then I can live with it. - There is no separator for the name tag. OSM is not interested in providing a machine-readable list of the common names of a city in its local languages.
¯\_(ツ)_/¯
There’s a third option of course - create a new name tag that is defined to be a machine-readable list, with a (defined somewhere) separator. It really doesn’t matter what that separator is because in a new tag it won’t break any existing code.
Maybe then the “language enthusiasts**” can be persuaded not to wage edit wars in the name tag, but “Bruxelles-Brussel”, “Londonderry/Derry” et al can be kept there by locals if that really is a local linguistic compromise.
Surprised you’ve not had an international incident over this rendering by the way 
** by that I mean people who typically aren’t local to a place but are keen to see names in (some rarer or non-local language) proliferate. Some “name” tags in OSM have been subject to this over the years.
1 Like
Or indeed @lonvia’s suggestion upthread of introducing display_name. I’d be fully supportive of that.
Surprised you’ve not had an international incident over this rendering by the way
Given my experience of cycling round there a few years ago I might just not render the city at all and suggest that people cycle on the Irish side of the border instead… the lanes are much nicer and have fewer boy racers!
2 Likes
your current rules are not leading to a consistent look, take this screenshot, Bozen is shown with the Italian name only while St. Ulrich looks just as bad as on carto (with the name split over two lines) and shows three local names all together:
1 Like
In that case we should move to something consistently machine-readable like, oooh, I dunno… semicolons?
1 Like
I agree, it’s a fine suggestion, although I would offer a slightly different take. Instead, I would make name the “formatted for display” name (basically what it tends to be today), and introduce a new key called simply names which would be “a semicolon-delimited list of names used locally”.
2 Likes
In this case, they are also tagged with name:left and name:right. But which of these equally prominent names would you propose go in name? Or would you leave it empty and have name:left and name:right only?
1 Like
But how does that solve the situation where a certain community has one name for a place and another community has another name? Which should be the display_name? Both but formatted nicely? If so, what does that actually solve over the current name tag?
Maybe I’ve misunderstood…
The current name tag is apparently not intended to be machine-parsable. So if you want your map to display names with a consistent delimiter (say, “always a dash” or “always a newline”), rather than whatever arbitrary delimiter the original mapper chose, you can’t. Or if you want to pick just one of the commonly used names, nope, you can’t do that either.
The suggestion being batted around towards the bottom of this thread is that there’s one machine-parsable tag (consistently semicolon-separated), and another non-machine-parsable tag containing the current freeform tagging for those renderers which aren’t capable of parsing a machine-parsable tag.
2 Likes