How to tag "sidewalk stubs"?


(yellow is highway=residential)
footway=link is from kerb to middle road.
The part on the sidewalk is not.

These are two different elements and must be tagged differenly.
Because on the area:highway=sidewalk ( not drawn in) it is a sidewalk part. You could name this differently but not footway=link

There must be two different values.

crossing
When it goes over the whole carriageway then it isfootway=crossing


path

horizontal a path (green dash) with path=link on carriageway.


1 Like

I think big question is to ask oneself is “What it the actual purpose of footway=* tag, how is it being used, and how certain tagging of those stubs adds or substracts from that purpose?”

  • I personally wouldn’t add a footway=* tag at all unless it was unambiguous (and, as this thread shows, it is ambiguous).
  • if something is to be tagged, footway=link would fit, but is (too) generic.
  • footway=traffic_island might technically fit, but people usually won’t call it traffic island if it is not in the middle of the road, but at its side.
  • Ideal would be separate value that reduces ambiguity (Taginfo shows few undocumented values which might be that e.g. footway=crossing_access).
4 Likes

Unsurprisingly, this question has come up a few times in OSMUS Slack, where there’s already a strong consensus for micromapping sidewalks as ways, including these stubs. I think it’s fair to say most mappers there favor sidewalk over crossing, but it isn’t unanimous and no one is willing to disown anyone over using a different tag. Consistent tagging of these stubs is pretty far down on the list of priorities, considering the dearth of sidewalk and crosswalk ways in most cities.

This is the approach OpenSidewalks has taken in their OSM-aligned tagging schema. Your reasoning seems sound in terms of semantics, but there are some practical downsides.

Since the beginning, one of the envisioned use cases for footway=sidewalk was that renderers could hide or deemphasize them (along with footway=crossing) at zoom levels where they’d otherwise clutter up the map. Leaving the stubs unclassified could result in little disconnected artifacts at street corners. Similarly, routers might not be able to distinguish between these stubs and more substantial footways that aren’t considered part of the streetscape. These problems can be solved with the same length and connectivity heuristics I alluded to earlier.

Apart from that, I think folks might be thinking of an unclassified highway=footway as more important by default, since we don’t have an explicit tag for the kind of footpath that needs no elucidation. (It’s similar to how we tag the most important highway=service as just that, but that could be confused with a service road that hasn’t been classified yet.)

How has no one thought to call these traffic peninsulas yet? :sunglasses: (Totally joking, please don’t run with that.)

As with traffic_island, if someone comes up with a reasonably intuitive value that isn’t a pain to use, it could potentially catch on pretty quickly, even without the help of software developers. We haven’t gotten there yet with parking lot access and perimeter roads, but maybe people care enough about these much shorter ways to do something about them.

1 Like

Let’s continue to ask for more quick opinions on that: Do we need a new footway value for these “sidewalk stubs”? (Feel free to make suggestions in the thread.)

  • yes
  • no
0 voters

I continue to be puzzled why and how these supposedly substantially different ‘non-sidewalks’ should be distinguished from normal sidewalks. What defines a ‘real’ sidewalk and what’s different for these sections?

Could a proponent of somehow treating these short sections differently please explain how you would tag these example crossings with respect to the footway=* tag and explain your reasoning?

T crossing

footway=sidewalk for the section on the sidewalk and footway=link for the section on the road.
Where does the ‘expectation’/‘rule’ that properties aren’t allowed to change along the way come from? We’re not talking about different highway classifications, we’re talking about properties of a footway. Nobody is suggesting to map the section of footway that lies on the road on a crossing as highway=primary/....

1 Like

And hi, a disclaimer: I’m the one using =crossing_access (inspired by service= =emergency_access , and historically proposed =parking_access as @Minh_Nguyen hinted at), and =crossing_island (I considered the connection between the refuge island and a transit platform may also be seen as =traffic_island ). I thought they would be logical as refinement of =crossing .

3 Likes

Topologically and on the layout, a crosswalk is often set-back from the intersection, away from the pedestrian deisre line. So it’s not straight with the sidewalk.
It seems unclear what you are asking from the examples. Are there specific sections you are pointing out?
1,2. Build-out or parking bay ends: That would be something special to highlight. Cf crossing:kerb_extension on =crossing (doesn’t cover parking bay ends yet), but the footway= of a crossing:buffer_marking= (the format needs some standardization with cycleway:*:buffer= , cycleway:*:marking= , and crossing:markings= ) be would be a good question. Verkehrswende-Meetup/Gehwege - OpenStreetMap Wiki
3. The protruding triangular section would still be a =sidewalk
4. This appears to be an excellent example of showing how it can be split into a new footway= to show what the tactile_paving= is for

footway=link is already used throughout both the section on sidewalk and roadway now. So I don’t see why it should change.
And another disclaimer: I actually don’t like footway=link either

Real sidewalk is for walking on the side of the road, IOW is a footpath parallel to the road.
Those stubs are however perpendicular to the road.

Thus the confusion and a need for disambiguation.

4 Likes

That sounds good name to me.

Since you are using it; would you be so kind to document that usage at wiki as suggested by ATYL policy? (Status should be “in use”, as it was not approved in proposal process)

1 Like

You are attempting to create an arbitrary distinction that absolutely nobody would make if you were to ask them in real life. If I’m on a sidewalk and then rotate by 90°, am I somehow no longer on a sidewalk?

You are also interpreting an extremely specific meaning and criteria into the word that does not exist in that way, while completely ignoring all other features that make up a sidewalk. A sidewalk is a footway that runs alongside a road. It also usually has distinguishing features such as being separated from the carriageway by a kerb, being slightly raised, having a different surface, etc

Alongside does not mean it needs to be 1000% parallel to the road, that’s absurd.

Describing a tag with ~240 instances by one person as ‘in use’ is pretty questionable, although I guess it’s technically correct and the ‘in use’ status as used on the wiki often doesn’t really mean much due to lack of alternatives.

The set-backs are still part of the sidewalk though. They are not always present and the example in the original question didn’t have any set-back either, so clearly they do not appear to be a criteria why this should or should not be considered a footway=sidewalk.

I’m still trying to get somebody to explain their criteria for why something should or should not be a footway=sidewalk. @Matija_Nalis has offered one metric now, is that the whole reasoning?

The example images were chosen to depict certain scenarios or ‘corner cases’ where I was curious whether you would consider pieces as ‘not sidewalk’ and your reasons for doing so compared to other situations.

They probably should be mapped somehow, but see the first section of this post.

But would you insert a ‘not sidewalk’ gap as the footway goes over the crossing on that triangular section?
(why/why not?)

The tactile paving is already covered by other tags and not all crossings have them. So this cannot really be considered a criteria for this either, can it? Would your answer change if it didn’t have the tactile paving?

That image was picked because it shows an example where the sidewalk does not run around the corner but more or less only goes straight over the intersection from north to south, with the same situation on the right side. The sidewalk to the north of the left crossing has a little extension to the right, but that doesn’t really lead anywhere and just stops.

Would you split the footway=sidewalk way before the kerb because you wouldn’t consider it a sidewalk? How long should that section be?

So the question may be, as I have asked before elsewhere, whether footway=sidewalk is physical (anything on the sidewalk), or functional. Unless is_sidepath= is adjusted to differentiate this, footway=sidewalk is best considered as functional.

  • Other use cases: It’s possible to draw a =footway to connect an entrance= (eg there is a =footway on 12% of entrance= around London, and ~30% around Berlin). If you use footway=sidewalk for those applicable, footway=sidewalk will be diluted, and quickly overestimated.
  • Other footway= : Considering the footway=crossing starting the topic, it’s most common to consider it as including the section discussed here, and refuge islands. This suggests it’s a more functional view.

Even if footway=sidewalk is used, there’s still a need to differentiate different parts of it. There’s no immediate option, aside from sidewalk= not usable properly.

Your examples:
3. How about I asked the opposite question: If it can be split for not being a footway=crossing , why not use something that’s more specific than footway=sidewalk ?
4. tactile_paving= could be a sufficient not necessary criteria to split. But it’s still sufficient. This can be one use. tactile_paving= + footway=sidewalk doesn’t accurately convey its function.

4 Likes

In fact, I already made a draft for documenting myself. It’s more suitable for a proposal format, than article. I’m still not sure whether =crossing_access is best, while I believe something other than =sidewalk and =crossing is useful.

1 Like

I think it’d be better to settle on standardizing the application of existing tagging for these sections (choosing, as a community, footway=crossing vs footway=link vs footway=sidewalk) rather than inventing new tags for these small connectors.

With the new-tag approach, how would the tiny way between a footway=sidewalk centerline and an entrance=main of a building be tagged? Would we really want footway=entrance_access? Would we want footway=platform_access for connecting public transport platforms? footway=viewpoint_access? etc.

A new tag for each type of feature to be connected by a routable network of ways is untenable; these would all be falling back to unrefined highway=footway from the perspective of a data consumer.


Edit to add: tactile_paving=yes|no usually goes on the barrier=kerb node, not the small connector way.

8 Likes

I did think about this question, as I’m usually concerned about scalability of having such =*_access . Here, I’m considering how it’s differentiating from =crossing , which is already covering these sections now. It’s focusing on the highway= , not other PoI. Functionally, it’s a continuation of the =crossing , not the motivating case of a =sidewalk or =steps ending.
Technically, the existence of excursion in a route= =foot / =hiking already implies it’s used to access something?

footway=link has problem with build-outs, on whether it’s part of the sidewalk, and whether it’s unrecognizable on its own only for routing. Mentioned above, when there’s a wide landscaping strip, the length can be significant. Another special case is when there are =subway_entrance , or pedestrian overpasses / underpasses landing at the intersection between the sidewalk and roadway.
To clarify, we are referring to the example 4, where the short section concerned has tactile. The reason of having tactile_paving=yes on =kerb would be because the short section hasn’t been split in the first place. Adding tactile_paving=yes to the whole footway=crossing is unclear, and risks other meanings. There are other proposals that could distinguish them. Proposal:Detailed tactile paving - OpenStreetMap Wiki

There’s already an attempt at this with footway=residential, but it seems like it’s just begging for a future semantical debate over form versus function.

2 Likes

I like footway=residential, it’s like the footway equivalent of service=driveway.

These connectors, however, are on an importance level for the pedestrian equal to the sidewalks and crossings, not lower.

Really? I see a worse version of footway=entrance_access
There’s already enough trouble with =alley from service= that can be forseen in footway=
If footway=link is considered less important than =sidewalk and =crossing , it won’t be appropriate by this criteria?

In my opinion, we should remind ourselves once again that we are a cartographic project and what an essential role topology and generalization plays in cartography. The reference to the segments of roads that branch off from roads of other categories has already been mentioned.

Our linear footways and crossings are abstracted networks and not an exact representation of space. I therefore consider footway=sidewalk to be wrong for these segments (and personally footway=crossing to be the most sensible variant). The exact representation of the space is only possible via area-based mapping (area:highway).

From sidewalk areas, but also from the position of the kerb nodes, it is possible to determine which (crossing) segments are above and below the curb (or on the constructed sidewalk).

8 Likes