Nothing short of a reinforced concrete wall will completely eliminate any risk to pedestrians, but then that wouldn’t be a sidewalk anyways. A less imposing curb or row of flexible bollards balances the need to separate cars and pedestrians with the need to access abutters by car. True, it doesn’t protect against the most egregious reckless driving. Neither does a roundabout completely prevent collisions, yet they’re getting shipped over here from Europe in record numbers, because they tend to minimize collisions to an acceptable degree.
Another, more prosaic reason many localities install curbs is that they help with drainage after wet weather. But I don’t think we need to debate the merits of installing curbs here; we can all agree that they exist. For all the focus on curbed sidewalks in dictionaries, equating a pedestrian lane with a sidewalk would be a particular choice on OSM’s part. This choice comes with tradeoffs, but as long as the tradeoffs are acknowledged, we can move on to how to address those tradeoffs.
One of the reasons cycleway=lane on the roadway could not be sidepath=lane on the roadway is that the lane could well run somewhere down the middle of the roadway. It’s very common for a bike lane to be flanked by the through lanes on one side and a turn lane or parking lane on the other side. One hopes we don’t ever discover a pedestrian lane with other lanes on either side, but there have already been close calls. The “side” in “sidewalk” normally means left or right, not inside.
The Forum software reminds me again, that this is solved. I do not think so:
I dearly would like to ask @SelfishSeahorse to just take out all the sidewalk references from the proposal and restart the vote for pedestrian_lane. But I fear, reading the opinions voiced here, that the endeavour will fail. E.g. I added the foot:left|right suggestions by @drolbr to the wiki, it got corrected, without presenting evidence, purely by theory.
PS: Kerbs for the blind are not a barrier, they are a valuable means of way-finding, especially, where the building side of the “Gehsteig” (our name for sidewalk) is clogged with bicycles. Pushing that down to an attribute of an attribute shows bad manners.
Yes, “barrier” is a curious overstatement for a curb of typical height – except for wheelchair users. Regardless, it is a physical separation. For a solid line of thermoplastic paint to serve as a physical separation, the road crew would need to layer it on real thick. A physical separation can be slight; it can even be permeable. But there is a clear difference in degree between carving a curb cut and leaving a gap in a painted line.
I just mapped a pedestrian lane, I had to split a highway, my bad. In all the construction manuals I am aware of, separation by merely a kerb does not make the footway a separate entity (We’d call this “Gehweg” instead of “Gehsteig”.) But this is openstreetmap after all, and we should be able to come up with our own definitions.
PS: I will not though undo my change to the wiki, so as to not mention sidewalk lanes, 1) redditists cannot be wrong, these pedestrian lanes are sidewalks. 2) Looks like most of people that tag such features also go this way - though might be able to change their mind, in case a “proper” way was documented and knowledge spread.
Yes, there is quite a big difference between perceived safety and actual safety. It does not however mean that one of them doesn’t matter (or even that it is less important!) For example, many mothers will highly prefer pushing their prams on a kerb-separated sidewalk instead of on the middle of unprotected residential road, as otherwise they’d constantly be subjected to high levels of fear/stress. Even if, statistically speaking, their newborn child is more likely to die or have serious health issues as a result of inhaling all that car exhaust, then to be actually hit by a car and killed/heavily wounded. But as you said, it is getting offtopic
I would highly recommend that if anyone wishes to use summarized documented practices of mapping pedestrian lanes on the road as a base (for making new proposal, or reactivating old inactive one) to open a new Discourse topic and link it here, instead of adding to this already too huge topic - if they would like to see any chance of it having a success.
One would do it by starting a reply here normally, and then pressing at that “hooked right arrow” at the top left of edit window and choosing Reply as linked topic.
It would be nice if (next time) you’d mention the wiki editor too (either here or on talk page) @Hungerburg , so they could improve it and/or explain if unclear. I’ve guessed it relates to me and went to have a look purely by chance. Anyway, I’ve tried to document lane and designated variants, and added a short comment why foot*=yes variant is inadequate (as it could mean things quite different than designated pedestrian lane). Let me know how it looks now, @Hungerburg and @drolbr.
It would also help if you used Discourse quoting functionality. Just select the text you’re replying to and select Quote. Otherwise, Discourse discussions become very hard (not to say impossible) to follow, especially in such gargantuan threads like this one. In other words, it looks like I’d probably agree with you here, if I had any idea about what you are talking about (i.e. context that you’re replying to) .
Sorry in case I might have upset you. Discourse eats quotes, when the reply immediately is below the quote and it also does not show, that the post is a reply.
On the rewording wiki for the umpteenth contender for mapping pedestrian lanes - as foot:left|right, I saw no use in mentioning your name. Actually, I walked the extra mile and learned from overpass queries and loading entities into the editor with background aerial, that the proposed alternative is used in a wholly different way by the mapping community - I did not bother to inform you - maybe I should have done so, because this alternative seems inexistent in data, so might better get dropped from the comparison?
Hmm? So, Discourse will eat the quote above this line? I have not noticed that before. Let’s see if the quote remains. I know only discourse complains if you try to quote whole article (instead of just part of it relevant for your reply). And no worries, I was not upset, just wanted to give a helpful hint so we all can use the Discourse better
I would guess at least foot:left=lane tagging would clearly designate pedestrian lane on the road? It does not make much sense otherwise. Did your research show otherwise? But I agree that foot:*=yes would be full of false positives (so I documented in wiki to avoid using that). Maybe @drolbr can chime in with their experience, since (if I understand correctly) they have been using such foot:left=* tagging?
I don’t think there’s any need for a revert. The mention of sidewalk lanes now links to a section that goes into such detail about tagging possibilities, for the benefit of this discussion, that anyone attempting to map a pedestrian lane for the first time will probably reconsider. Meanwhile, the table of examples remains as a discussion piece, and a different table aims to help mappers “comparison shop” between tag and way representations of sidewalks, but neither provides any direct guidance. So at this point, the page is as unassailable as it is unfinished. One hopes that eventually we’ll be able to write a more coherent, actionable piece of documentation based on consensus, even if that consensus varies by region.
From my point of view, it should be mentioned that by the numbers all the listed approaches have very low usage. There are about a million sidewalk=both and together 700k sidewalk=left|right, and almost all of them on highway=residential|unclassified|tertiary|secondary.
At least here in my region, over 10% of them record streets where the sidewalk is only separated by paint. So even if we assume an order of magnitude less for the entire world, we should expect that there are 20’000 to 200’000 ways out there where a paint separated pedestrian way has been mapped as sidewalk=both|left|right. In comparison to far less than 1000 for any of the presented mapping approaches.
I cannot help with that, the table is not my work, I just put kerbs first. Maybe it helps, to see it as a guide, when to add footway=sidewalk to a footway?
Just out of curiositiy, for whom does that make a difference, if this tag is there, or not? It got invented, to settle a conflict between mappers, not to help consumers, as far as I understand the history. I even considered footway=lane as just the same, before you said, you’d prefer it as an attribute to other highway types than footway
If you’re asking why footway=sidewalk exists, it was definitely for a real-world need, not just to settle a dispute. For example, Mapbox wanted style designers to be able to declutter the map by deemphasizing sidewalks that are conceptually part of the road right-of-way; this also would allow the style to emphasize footpaths that stand alone. Valhalla similarly wanted applications to be able to prefer roadways over the sidewalks that run parallel to them, without avoiding footpaths through parks and such. Micromobility profiles (scooters etc.) often set this option.
I can’t speak to the histories of the various attempts to coin a new tag for pedestrian lanes. All I know is that I encountered my first pedestrian lanes unaware that they’re widespread elsewhere. Sometimes, even a pro-sidewalk-way mapper like myself needs to tag the roadway because of the physical separation rule. footway:*=lane seemed logical by analogy with cycleway:*=lane.
Because ifsidewalk can have specific meanings like track or lane, keeping a simple yes for “not sure which one” is pretty useless since it doesn’t take much to distinguish a track from a lane. Has been working for cycleways pretty well now. Whether it’s an overall feasible approach remains to be seen though»
None of that makes anu sense. Each concept is has a specific definitions. A lane is a sub-section of the road surface. Sidewalks are ways that are effectively parallel to but physically separated in some manner from the main road surface.
This is exactly what this thread is about: how to tag a footway that is not physically separate. @Matija_Nalis has summarized possible tagging solutions on the Wiki and @Langlaeufer proposed to just adopt the tried and proved cycleway=*-tagging to sidewalk=*. He also suggested to then deprecate sidewalk:<side>=yes, because it would at this point be about as useful as saying cycleway=yes.
Personally, I’d like to separate the ability to tag the presence of a physically separate pedestrian infrastructure from defining where they should be going. I personally always considered sidewalk=yes on the same level with shoulder=yes and verge=yes.
Broadly speaking, “sidewalks” and “lanes” are both subtypes of “footways”, just as “tracks” and “lanes” are subtypes of “cycleways”. If cycleway=* answers the question, “What kind of cycleway, if any, is associated with this street?”, then why shouldn’t footway=* answer the same question but for footways? Or to put it another way, by all means keep tagging sidewalk=yes on highway=residential, as iterative refinement of an implied footway=sidewalk on the same way.
These examples aren’t quite equivalent, or at least they won’t be until we see an uptick in shoulder=separate and verge=separate, paired with the inevitable amenity=parkingparking=shoulder and landuse=verge areas.
Even if we often omit primary tags when querying because we know what we’re looking for, a recently rediscovered OSRM bug illustrates the necessity of considering any secondary tag in the context of the primary feature tag, rather than relying solely on the secondary tag to define the feature:
What I mean is: verge=yes and shoulder=yes define the presence of a certain physical infrastructure. I was always under the assumption that sidewalk=yes would be on that same level, so I was assuming that sidewalk=both means: there is a kerb on both sides of the street with an elevated footway for pedestrians (and maybe cyclists) running along the street. Much as verge=both indicates the presence of road verges on highways.
I do know now that this is controversial and that there are many ways interpret the meaning of sidewalk=both with the only certain one being: pedestrians can walk on both sides of the roads.
So even if we start introducing something like sidewalk:left=track to indicate that it’s actually physically separated, it still doesn’t say how (could be separated by verge, by kerb or other means) and I’d still be craving for a way to tag the presence of what I call a “sidewalk”
In other words, what may have once been an indication of a sidewalk parallel to the roadway (as in highway=footwayfootway=sidewalk) has been muddled to mean only that there’s something sidewalk-like somewhere in relation to the roadway, maybe even in the middle of it. That leaves us in an unfortunate quandary, where the key doesn’t mean what it says on its face, “side” can mean “inside” instead of “beside”, and the most obvious workaround is tantamount to sidewalk:both=yes_really. Imagine if, in a parallel universe, we had wound up with a cycle_track=* key before recognizing that bike lanes are a thing and belatedly stuffing it into cycle_track=lane.
The purist in me, who occasionally visits this forum, would contend that the solution would be to clarify an actual, physically separate sidewalk on the right side as footway:right=sidewalk, adding sidewalk:right=separate if it’s already mapped as a separate way. But the pragmatist in me would counter that footway:right=sidewalk would already be implied by sidewalk:*=yes/separate and would only be necessary in areas where the term sidewalk has been overloaded.
Following this approach, a pedestrian lane would be footway:right=lane, and you could even pair that with sidewalk:right=separate if you’ve mapped the pedestrian lane as a separate way for some reason. This opens up more possibilities than the alternative of overloading sidewalk=*. In the U.S., we have a need for this additional flexibility.
In some localities, pedestrians are legally required to walk on the left, facing traffic. The following sign is typically posted in these cases. I think sidewalk=opposite would be awkward compared to footway=opposite or footway=opposite_lane, which is at least consistent with cycleway=opposite/opposite_lane:
A sidewalk extension could be footway:right=lane;sidewalk, at least until the authorities treat it as a parking lane, rendering it unusable. Better than sidewalk:right=lane;yes in any case. This sidewalk extension was newly installed in New York City, where electric scooters are banned from sidewalks but not roadways:
A less imposing curb or row of flexible bollards balances the need to separate cars and pedestrians with the need to access abutters by car. True, it doesn’t protect against the most egregious reckless driving. Neither does a roundabout completely prevent collisions, yet they’re getting shipped over here from Europe in record numbers, because they tend to minimize collisions to an acceptable degree.
.
Meanwhile, the table of examples remains as a discussion piece, and a different table aims to help mappers “comparison shop” between tag and way representations of sidewalks, but neither provides any direct guidance. So at this point, the page is as unassailable as it is unfinished. One hopes that eventually we’ll be able to write a more coherent, actionable piece of documentation based on consensus, even if that consensus varies by region.
Imagine if, in a parallel universe, we had wound up with a 
