Following on from the recent thread on naming “sidewalks", I wonder if I can focus the discussion on one issue such that I (and others) can better understand it (and possibly even find some sort of resolution?).
As part of the thread on separated pavements near Ealing I made a series of changes to some poorly mapped pavements in Manchester as a test. One of the changes was to name any separated pavements that I kept with.. well, their name. So, now Portland Street is mapped (partially) with name=Portland Street on both the “highway” and the “sidewalk”, what problems arise?
For the purposes of this discussion let’s assume that pavements in the UK unambiguously have names, and those names are always the same as the adjoining carriageway. Let’s also avoid diversions into cycle tracks and other things - I just want to understand the problem with name=* on footway=sidewalk ways specifically
Renderers are quite used to having to prioritize when not everything can be rendered within the given space.
Routers will use the name of whatever segment you’re on, regardless of there being a nearby segment with the same name – and if it did use the other name…. it’s the same name.
Curious to see if someone has a problem to contribute.
One problem I can think of is for visually impaired navigation. When a sidewalk is named it is called by that name when the router reads it aloud rather than telling users to turn onto a sidewalk which is more useful in that context.
I’m personally not a fan of the amount of data duplication it creates but I’m aware data duplication is just a fact of life for OSM. I’d love to see some more elegant system allowing sidewalks to be associated with the roads they’re on but again in the meantime it seems like naming sidewalks the same as the road they’re on is just kinda a thing that happens.
I don’t personally do it, mainly because it seems like a lot of effort and makes the map harder to edit in future if a road name is misspelled or updated for not much in the way of benefits I’m aware of.
OSMand. It treats the name of a sidewalk like it’s a footpath with it’s own name. We have some specific footpaths that have their own names and have their own associated addresses without an associated road. For example Way: Seabreeze Terrace (1432429228) | OpenStreetMap which make this behaviour desirable in those cases but undesirable when trying to tell visually impaired users to turn onto a sidewalk or footpath if it’s named the same thing as the road it’s associated with.
It might be more helpful to name sidewalks based on their position relative to the road itself. For instance “Sidewalk on the north side of x road” but that seems like even more work. I’d love some system for tagging relationships to the road for this reason. Would mean routers and apps could give much more specific verbal instructions about the location of sidewalks relative to the road along with the name of the road.
Thanks for the detail. Maybe it could be partially addressed by changing OsmAnd’s instruction for footways depending on whether a footway=sidewalk tag is present?
Well when you put this up as a pre-condition to the discussion it’s not really possible to point out the problem. If the pavements/sidewalks are specifically named the same thing as their adjoining carriageway then of course putting that name in the name tag on the pavement/sidewalk is the right thing to do. I’m not sure I really believe that this is the case though. If I stop a random stranger in the UK and ask them “What is the name of this pavement, specifically? No, not the name of the overall street, specifically the name of the pavement”, are they really going to respond that the pavement is named the same thing as the carriageway? I suspect they will say something like “Well the street is named X. Why are you asking about the name of the pavement? It’s just part of the street”. My view is that the overall street corridor has a name, the pavement/sidewalk is part of the overall street corridor, and neither the carriageway or the pavement/sidewalk specifically have their own names in the real world.
The obvious problem (issue? it’s not the end of the world) is excessive redundant street labels. Princess Street around the corner from Portland Street shows a better example of this. The standard layer places six Princess Street labels in a space where it would have placed just two if the sidewalks didn’t have name tags.
Renderers can of course adapt to hiding name when footway=sidewalk is present so they don’t show an excessive number of redundant labels. This will take a long time though. Who is going to inform all the different renderers of the new status quo? If we can avoid that whole annoying process by just using an alternate name tag like street:name that seems to me like an all around better path forward.
Sure. A simple street with sidewalks is far more commonly occurring than a multi-carriageway street like this though. Imagine how many labels there would be in this example if the sidewalks also had name tags!
This isn’t new if you’re not approaching the map with carbrain. For everyone else, protected bike lanes (aka cycletracks) and sidewalks along the road are just another carriageway, access limited to specific modes.
It isn’t new at all because it hasn’t happened yet, Nothing to do with carbrain. Just a matter of data. The current status quo is that there are ~6.8 million ways tagged footway=sidewalk and ~3.5% of them are tagged with name=* (taginfo link). The new status quo I was referring to would be if in the future this percentage drastically increases so that the majority of footway=sidewalk are tagged with name=*.
Aren’t we supposed not to tailor our tagging practices just to please the renderer?
Although I guess there is a semantic difference between a “name of a footway” vs. a “name of the road this footway is a sidewalk to”? And concluding that name=* should concern only the former, which is almost never the case, save for rare counterexamples like the Walk of Fame.
Why couldn’t the router say “turn onto sidewalk”? Why is it better to say “turn onto sidewalk” without providing any context to which sidewalk this is?
And here I was thinking it was the entire street that had a name….
Not tagging it because (you think) it looks bad sounds like the renderer needs updating or you need to render your own maps to avoid dealing with a rendering style you don’t like?
Even the original proposal has already mentioned footway=sidewalk can be rendered differently, so applications have 15 years to think about accepting it and reduce its prominence, including text labels Proposal:Sidewalk as separate way - OpenStreetMap Wiki
I have changed to street:name= before, but was convinced in the last post it’s fine to also add name=
Sure, but that ~3.5% is already well supported. What’s not particularly well supported is the opposite situation, where there is no name=* tagged. The supported case is likely supported because it’s the easiest, most obvious way to implement a solution and it’s a reasonable expectation to expect the data to include all applicable data on the object. The toolchain made it a solved issue.
I’m seeing carbrain here because this situation parallels the lanes=* situation, where the documented case of excluding lanes for singletrack vehicles is excluded is not widely supported and isn’t orthagonal to how toolchains use it, which is “the total number of lanes included in access, destination and turn lane tagging, inclusively” and absent other forms of lane tagging, “the total number of all travel lanes, inclusive”. The documented case is 100% carbrained because it’s reflexively assuming other modes don’t need this information and motorists don’t need to worry about singletracked lanes (even though doing so makes lane guidance off by at least one lane). Again, the supported case is the easiest, most obvious implementation, it’s reasonable to expect lanes=* to be a total sum of lanes included in subordinate lane tagging, and the toolchain made it a solved issue, wiki be damned.
The motorist-forward assumptions are a recurring theme in tagging discussions and needs to stop, carbrained assumptions make creating and consuming the data needlessly harder.
It’s supported if what one cares about is seeing and/or hearing the street name in pedestrian routing directions. It’s not supported if what one cares about is not seeing extra labels on a map. If one cares about both, then pick your poison I guess .
And concluding that 
.