footway=sidewalk was adopted years before is_sidepath=yes and has 200x more uses. is_sidepath=* has no bearing on the interpretation of footway=sidewalk.
If the footway is directly on the sidewalk, then there’s also no problem with tagging it as footway=sidewalk. Other parts that aren’t on the sidewalk shouldn’t be tagged as such of course.
I’m not entirely sure what the concern is about ‘overestimating’ sidewalks or how relevant that would be to OSM? (And why only for sidewalks specifically but there’s supposedly no issue with tagging crossings over the kerb for longer than the actual length on the carriageway.)
A majority of people would disagree according to the polls here in this thread. footway=crossing also does not include the sections that are on refugee islands, those are tagged with footway=traffic_island.
But that could/should be done with a different tag that extends the tagging, not replaces it. It’s still a sidewalk, even if some parts of it could theoretically be considered to have different functions (although so far I’m not really convinced that there’s a meaningful difference).
So, a different key should be used instead? Why should that be a hurdle but creating a new footway=* value isn’t.
I’m a bit confused by this. My argument and that of the majority of other people is that it is just footway=sidewalk - barrier=kerb - footway=crossing and I’d like to hear counterarguments. A question is not an argument.
As for tagging sections of the sidewalk with more detailed information, see the previous paragraph.
Okay but what is a sufficient criteria to split if there’s no tactile paving? (Also again, see two paragraphs up for how additional info should be handled)
Umm, that’s being discussed here?
The situation now is they are being covered by =crossing , and =sidewalk is for the main parallel part only. I don’t see how changing the section in question to =sidewalk is a great solution for all 3 topics.
Okay fair, you weren’t arguing for footway=crossing but others were. Your concerns would similarly apply to that. (And be more applicable there IMO, the short sections before the kerb aren’t really on the crossing.)
Is it? Most I’ve seen (including the one in the example that started this thread) are tagged as footway=sidewalk. Tagging it as footway=crossing is also the least popular option in the poll above.
You are describing the case when it is split, which is still uncommon now I suppose? Not a large sample size? I’m referring to how the whole length would be =crossing when not split.
Looking in detail, a distinction could be made between intersections, and mid-block. Considering possible evolution of edits at intersections, someone might have stopped drawing a =sidewalk along a main road by connect it to a highway=crossing , or even drew it across without splitting out a =crossing . Then there may be another user drawing the =sidewalk down the minor road. Finally, the next user could decide to split the =crossing out exactly between =kerb . There are many possibilities. Is it all intentional? We don’t know yet.
The footway=sidewalk votes may similarly be based on what they saw. Or they may not even care.
Looking at a random example from Charing Cross, there is already all 3 options present, =sidewalk , =link , and no footway=OpenStreetMap
Between Spring Garden and Cockspur St, there was originally an L-shape =footway connecting a partial =crossing via the sidewalk. It had footway=sidewalk added. Then it was split into =link . Lastly, it was changed to =sidewalkOSM Deep History
The =sidewalk on the west side of Trafalgar Square is alone when the =footway it connects to doesn’t have footway=sidewalkWay: 267214811 | OpenStreetMap
Of course I will be fair, and note those footway= are complicated by how they continue into other =footway or =pedestrain , and the =pedestrian + area=yes
So there’s not even any consistency at one of the most famous junction in UK (I assume)
Ok, but it seems a notable anecdote, if it’s being tried there. Then merely to illustrate another case I described, you can see all the =sidewalk on Whitechapel Rd are connected to the =kerb directly, without drawing the minor road’s =sidewalk around corners OpenStreetMap
At another random intersection in Berlin (B2, B5), it’s again all different. So I’m thinking the status quo is more affected by how the =sidewalk were drawn in the first place, as I suspected. OpenStreetMap
Please don’t, that’s a hideous and unrepresentative mess, with a lot of obviously wrong tagging mixed in. There were also crossing ways tagged with tactile_paving=yes, because someone didn’t bother to read the wiki and just copied all the tags from the crossing node. I’ve fixed that and a few other obvious howlers, but there’s a lot of work to do there when I’m feeling sufficiently bored/masochistic.
I added those. The ones which connect directly do so because the crossings are not offset far up the side road and because pedestrian navigation on most of the side roads wouldn’t benefit from the addition of separate sidewalks.
Where there is a connecting stub, there’s no footway=* value. If this discussion reaches any consensus, they’ll acquire one very quickly.
In Brussels (where I live), when sidewalks are drawn as separate ways, the convention appears to be to split the way on kerbs, then tag the “sidewalk stub” with footway=sidewalk and consider the rest to be the crossing.
While this does not answer the question about the case where the way isn’t split at kerbs, it did made me realise another important point: in a lot of cases, the surface=*, smoothness=* etc. will differ between the main carriageway and the sidewalk. This might have implications when the way isn’t split at the kerb and the whole thing is considered to be a crossing. For example, a wheelchair user might be fine using a crossing with surface=asphalt + smoothness=good, but have trouble with a sidewalk with surface=paving_stones + smoothness=intermediate. And this is not even considering kerbs!
Often, these little stubs represent curb ramps. How you map the stubs depends on how you map the adjoining ways, so the following examples are an attempt to demonstrate how the stubs fit into an intersection layout.
The term “curb ramp” depends on an accessible ramp for wheelchairs and strollers (prams). As with footway=access_aisle, it’s pretty common to extend the stub a foot or two longer to meet the sidewalk way at the landing and tag it all as a sidewalk. Moreover, there are still many raised “curbs” without curb cuts or curb ramps, and sometimes they don’t connect to a path going all the way across the street. There’s no set term for the same geometry over one of these street corners. If I had to come up with one, I’d go with something generic like “crossing approach” or “curb approach”.
Diagonal curb ramp
I would make the two crossings meet at the tactile paving, then draw a footway from that meeting point to the landing above the diagonal curb ramp, connecting to one or more sidewalk ways. That footway would be a sidewalk too, because the curb cut marks the point at which both crossings end.
I would map no extra stub to represent a parallel curb ramp, because someone who stays on the sidewalk and continues straight past the crosswalk would still have to traverse both sides of the ramp.
Sometimes the crosswalks are offset from the intersection but still parallel the street. Someone going straight through the intersection would need to curve around on the sidewalk, turn onto the curb ramp, cross the street, and turn back onto a sidewalk to go back around to the intended street. I still tag the approaches as footway=sidewalk.
Sure, if the way is not split and just drawn across the road as one piece without kerbs being considered, then footway=crossing is a whole lot more correct than footway=sidewalk would be. However I thought the whole point of this thread is how to tag it if there’s a kerb node present.
Beyond a doubt, you have demonstrated the folly of this thread. Clearly a pedestrian crossing should not be tagged footway=crossing. The portion of a pedestrian crossing that lies within an area:highway=primary should of course be footway=primary, and the parts inside an area:highway=residential should be footway=residential, and the parts inside an area:highway=footway should be…
footway=footway! Our tagging system’s singularity has finally arrived!
My two cents on this as a non-seasoned mapper: tagging these stubs as either footway=crossing or footway=sidewalk feels a bit like working for the renderer.
Short of mapping both things as areas (which would remove this problem), I think there’s a consensus that these ways coincide with the middle point of their feature. If we also take into account the micromapping rationale that kerbs are to be added on the actual physical coordinates of the kerb, that leaves us with crossings that are kerb to kerb and semantically disconnected from the sidewalk.
And that’s my key point here: the disconnection is purely semantic, as the sidewalks are arguably fully mapped, just to a level of abstraction that makes them ways instead of areas. Therefore the way to semantically connect these would be footway=link, as a purely semantic artifact. The current usage of footway=link is already pretty similar to this.
Mapping these as links also makes it easier to micromap them, as they don’t need any attributes (because they would logically inherit those of the adjacent ways). Routing through them would necessarily route through both the crossing and the sidewalk, applying any limitations inherent to those to the route (think smoothness, surface or presence of kerbs). It would free effort from micromappers and not prompt them to add attributes (especially those using tools like StreetComplete, who can only add and not edit or remove) to these stubs that really don’t need them.
I agree with @peanuthole and want to add that choosing footway=sidewalk for these stubs essentially maps the same feature (the overlapping area) twice.
Choosing footway=crossing seems odd, because I would associate that tag with a warning.
A complication are recessed sidewalks which are connected to the road. The gap in the buffer zone isn’t part of the main sidewalk, yet it isn’t part of the crossing. In that case, I’d maybe consider footway=sidewalk up to the crossing, though the overlapping area should be tagged footway=link to avoid the first issue. Might look a bit weird, but best reflects what’s OTG.
This is an interesting solution to the problem. Would you suggest using footway=link at any street corner, or only where the geometry is especially contrived? Earlier, I posted some other examples where there are stubs coming out of sidewalks, but they aren’t “purely semantic artifacts”:
In this neighborhood in Wyoming, Ohio, there are pretty clear progressions of the sidewalk along each street. I split out separate ways in order to highlight them in the following screenshot, but normally I would keep them as part of the longer sidewalk ways. When folks were only complaining about “sidewalks” not being parallel to the street, these still seemed like uncontroversial candidates for footway=sidewalk, because they definitely are parallel to the street they serve. Would they need to be split out and tagged as footway=link?
By the way, this way going across Burns Avenue, connecting the sidewalk along the north side of Stearns Avenue with a driveway, is currently tagged as an unmarked crossing but probably would’ve been a good candidate for footway=link even before this discussion. Given that this discussion is ostensibly about “sidewalk stubs”, should sidewalk stubs be tagged identically to non–sidewalk stubs?
I think mapping them as footway=sidewalk is a fair assessment. Firstly, looking at it the way @Jofban suggests and being strictly rigorous, they should be mapped like so:
Where the highlighted bit is footway=link. However, for the sake of simplicity I would prefer to keep this tag’s spirit of connecting two different types of way, and any iteration of it connecting two ways that have the same tag can be simplified to an uninterrupted single iteration of this way at the discretion of the mapper, in this case resulting in this:
That first part of the sentence does not make me reach this conclusion. For example, crossing nodes/traffic signal nodes are also mapped at their physical location, but that doesn’t make the way section beyond the crossing, i.e. the way section that is physically already on the other road area part of that other road. At least we don’t map it that way (thank goodness!).
Or in other words, the last way segment (beyond the crossing) is physically already on the other road, but we map the semantics.
For illustration how we don’t map, see my previous post.
