However, this apparently generates JOSM error messages (see discussion on Changeset: 167356853 | OpenStreetMap). Should I be using a different delimiter in these cases? Or is this procedure good?
The changeset should be reverted. Keep both names in name=*, separated by a semicolon. Also keep the name:left=* and name:right=* for renderers, but also consider name:forward=* and name:backward=* for routers (like OSRM) that recognize these suffixes in general for any key.
The JOSM validator warnings are false positives. The validator rule is good at catching historical blunders where mappers accidentally merged ways together in Potlatch (guilty as charged), at the cost of incorrectly flagging situations where a stretch of road actually has multiple names of equal prominence.
It sounds like we should propose a change to the JOSM validator to ignore semi-colon separated names in cases where name:left and name:right are set. In these cases, neither name would take precedence over the other.
Note that there are other reasons a street may have multiple names in a tie, such as a dispute between authorities that share jurisdiction. It’s just a poor assumption in general. It made more sense when Potlatch was more popular.
Unfortunately, we’ll have to continue to be vigilant against mistaken edits by out-of-staters unfamiliar with township line roads. To avoid confusion, consider mapping the street name signs at each intersection as traffic_sign=US:D3-1 or traffic_sign=US:D3-1a with name=*.
Yes, but this discussion is specifically about the case where a road has a different name on each side of the road. If a road is tagged:
name=AAA;BBB name:left=AAA name:right=BBB
Would you agree that the reason for the semi-colon in the name is because there is a different name for each side? And in such a case, it’s a false positive easily caught with a bit of string comparison?
To confirm, is that based on the direction the way is going (i.e. is forward if you’re following the arrow and backward when you’re going away from the arrow)?
We seem to be running into a problem with cultural differences here. A quick check in the database indicates that only the US uses semicolons in this situation. Everybody else uses slashes or dashes. Current statistics gives: 859 usages of ;, 2471 usages of / and 1579 usages of -.
Any chance we can come to a common practice? Note that the wiki page on name:left also recommends the slash. And last time I checked, none of the best practices at multilingual names was using a semicolon anymore either.
This sounds wrong. The documentation you cite is very clear that *:forward and *:backward are not for the side of the way. The names usually refer to the houses on the right and left side. The street is not named differently when you move up or down the street.
At least the way I’m conceptualizing it the forward/backward tags would be for the direction of travel (right side of the road here), so if you’re driving on the one side of the road the router would read “268th Street” and on the other “100th Street” if that makes sense.
So I started out putting the second name in parentheses, then switched to slash, then switched to a semicolon after I was told data consumers handle that better.
I’d very much like to come to a common practice. It is unfortunate that there is such widespread use of / and - given that ; is the standard tag value separator. / and - are more problematic as delimiters since they occur more frequently within real world names than ;. I stated as much previously in a lengthy discussion about name delimiters several years ago which was fairly inconclusive.
This being the United States forum category, I think it’s fair to point out that slashes and dashes would be unworkable compared to semicolons. A vast number of street names contain slashes and/or dashes in the real world, especially in rural parts of the country where section/township/county line roads are commonplace.
In these regions, county and township road numbers are also common, and we often have to add ref=* with a semicolon, ref:left=*, and ref:right=*, so this is also a matter of internal consistency. In some regions, slashes and dashes occur in these road numbers too – as a rule.
Good point. We should add the semicolon as the favored delimiter for the U.S. at the very least. That’s been a clear consensus among the community for years now. It’s disappointing that we haven’t been able to convince other communities on this point, but at the end of the day we have a need that other delimiters don’t solve.
The street’s name does indeed depend on the side of the centerline you’re standing on or, alternatively, which direction you’re traveling. For administrative convenience, some neighboring jurisdictions will agree to an easement so that one side will maintain the whole roadway, but this does not change the fact that half the road belongs in a different jurisdiction with a different name and even different default parking rules and speed limits.
Street names in addresses have anything to do whatsoever with what the adjacent street is named.
Most OSM validators fail on this as well, which comes up frequently wherever emergency services or the post office decides the current streetname is too long and insists on using an older, shorter name or forgoing names entirely and using the route ref instead. Or on unnamed roads a numbered route traverses (in which all address street name values will fail).
Aviation mappers also struggle with this on runway refs, however, the OSM value separator is established as ; and is widely supported by data consumers.
Just because other communities are tagging for the renderer, does not mean that we should as well. Semi-colon is a well-established delimeter with a specified escaping in the case of a legitimate semi-colon in the name, like that coffee shop in New Zealand. There is no good reason why road names should be different from other tags that need a delimeter. That would seem pretty annoying for data consumers to have to keep a list of different tags and which delimiter the community has chosen to apply.
Yes, it is. You only drive on one side of the street. Therefore it has one name in one direction, and another name in the other direction when you are driving or cycling on the opposite side. Since we are in the US and drive on the right side of the road, name:right should correspond to name:forward.
There is no good reason why road names should be different from other tags that need a delimeter. That would seem pretty annoying for data consumers to have to keep a list of different tags and which delimiter the community has chosen to apply.
As always there are two options for a delimiter in OSM:
a semicolon
/\s+-\s+|\s*\/\s*/
They’re almost as intuitive, performant, and edgecase-resistant as each other, don’t you think?
Disclaimer: I’m posting here from the point of view of somebody who has to convert a planet into a geocoding database that works on a global scale. That makes me somewhat sensitive to local deviations in tagging. Please take this as an observation and do with it whatever you want. I shall shut up after this post.
I don’t disagree with using semicolon delimiter in general. That one is fine. This is about the name tag specifically. I just don’t think that it is ever used as a multi-value tag in practice. Mappers and data user use it in a way that it comes out as something that can be used as a display name. That may be a good thing or bad thing but that is the current status according to what I see in my daily dealings with names.
I am aware that this is a somewhat contentious issue and if the US community wants to go the semicolon way, fine. I just wanted to point out that this goes against the global trend elsewhere. Documenting the community consensus would definitely be helpful.
If you want to add the two tags and duplicate information, by all means do that. I don’t think it is necessary because – as you correctly point out – the values are trivial to convert, especially for a router who usually already knows about the driving direction of a certain OSM way. So why force mappers to do that work? Still, if it is just a duplicate, as a data user I can simply add rules to drop the forward/backward notation and be done with it, so I wouldn’t care.
But that is not what is going to happen here. Mappers are lazy and once the two schemas are out, they will tend towards adding one variant or the other instead of both. Sooner or later, you have two competing mapping schemas and every data user will have to understand both tags with all the complications that come with it. (Special bonus in this case: all data users have to know about driving directions when they want to convert.)
name:forward/name:backward is by no means an established tag. We have about 9k appearances of the left-right schema and about 200 of forward/backward (pretty much all of them in the US). In fact, this was the first time I heard of the tag being used in this way. So this is simply a good opportunity to ask if recommending name:forward/name:backward is a good idea or if it is better to point routers towards the left/right schema (which they probably already implement, if they care about these kind of things).
Here’s a business named the “40/40 Club”: https://the4040club.com/
Using the regex delimiter above, name=40/40 Club would be interpreted as two coequal names: 40 and 40 Club. This is obviously wrong. Better require a space around the / as well. Problem solved! Until someone starts the “80 / 80 Club”, anyway .
.