How to tag "sidewalk stubs"?

Micromapping question that I recently asked in the SCEE GitHub.

In case of micromapped sidewalks, how should this part be mapped?

image

I usually use the same tags of the sidewalk. But lately I was wondering if maybe I should use highway=footway + footway=link. Thoughts?

EDIT:
First poll here: LINK
Second poll here: LINK

6 Likes

theoretically you can argue everything
It is on the sidewalk
It is part of the crossing
it is a link
does it really matter?

6 Likes

I just go with the same tags as the rest of the sidewalk.

In OSM we map something 3d (the world) using connected lines, lines have no width. But things in the real world do.

Personally i prefer to follow graph and line correct geometry during mapping. This means that when a crossing is directly adjacent to a road that there should not occur a split, the crossing should continue to the connecting node.

4 Likes

In general, I don’t bother with splitting the crossing at the kerb but if I were to do micromapping, I’d typically go with footway=link because that path is both perpendicular to a sidewalk and the actual crossing hasn’t started yet.

3 Likes

I would not use footway=link for this purpose. That tag is meant for short virtual connections across areas that aren’t recognizable as footways but are needed to connect the routing graph. These stubs are right on the sidewalk and can be thought of as either part of the sidewalk or as part of the crossing. Tag it as one of those.

11 Likes

Sure, OSM ways are an abstraction of reality in some (/most) aspects, but how is this an argument against tagging the piece of way that is on the sidewalk as a sidewalk?
Whether what you are describing is ‘correct geometry’ is highly debatable.
What about the crossing way? The geometry of that would be incorrect and extend beyond the actual extent of the crossing/part of the way that is on the road.
What about the kerb node? The kerb is the interface between the sidewalk and the street/where the crossing starts. That would be in the middle of the crossing if you map it that way.

2 Likes

Because it is not on the sidewalk if you look at it from a data perspective

1 Like

But it is? Just because walking routes on a sidewalk split in multiple directions they are still on the sidewalk (for a short section at least).
The transition from sidewalk to crossing ‘from a data perspective’ is always there, regardless of whether the crossing connects to a short sidewalk way or a long sidewalk way.

3 Likes

The transition from “crossing” to “sidewalk” might be relevant for visually impaired people, wheelchair users, etc. since a kerb is expected there. That’s why it’s defo important to split the way at that point and add a barrier=kerb node. So from that perspective, the small link segment is a sidewalk. Although I will admit, so far, I often forgot about this and just mapped it as a highway=footway without footway=* tag.

10 Likes

Before =sidewalk is debated, the arguments for =crossing here didn’t seem to consider the existence of Tag:footway=traffic_island - OpenStreetMap Wiki which already reached 40k. When it is drawn it is detailed, it can always be split to be something else.

1 Like

I believe footway=link is already used on the short section between the footway=sidewalk and the kerbing, not only on the roadway. Physically, there doesn’t seem to be any difference.

I usually map these as footway=sidewalk because they almost always have the same attributes (surface, etc) as the adjoining sidewalk, not the adjoining crossing. It fits my intuition better too: someone walking here wouldn’t think they’ve left the sidewalk yet before they reach the curb/kerb, so it seems sensible to me to map it as a sidewalk segment.

7 Likes

Time for a poll: How to tag these way segments? (See the image at the beginning of the thread)

  • footway=sidewalk
  • footway=crossing
  • footway=link
  • Other
0 voters
2 Likes

I’ll just add that this is currently first on the list of the “Unanswered Questions” being considered by the OSM US PWG which we’ll be discussing in our next meeting! I’ll definitely make sure that the views expressed in this thread are included in that discussion.


Personally, I lean towards footway=sidewalk as part of a “footway=crossing is from barrier=kerb to barrier=kerb” model, for the reason @queerthoughts mentions: the exact point at which one is no longer on the sidewalk and instead in the crossing is relevant for pedestrians (especially those with disabilities!) in a way that, in my opinion, justifies the departure from the less granular routing-focused logic dictating the convention that we directly connect, for example, service=driveway ways to highway=residential centerlines rather than split them at the driveway apron.

However, I definitely understand the reasoning behind a “footway=crossing is from footway=sidewalk centerline to footway=sidewalk centerline” model, especially because when footway=crossing ways are mapped at a lower level of detail (without separately mapped barrier=kerb nodes) it adds more work to upgrade to a higher level of detail if it’s required to split the way once the barrier=kerb nodes are mapped and then re-tag the stubs as either footway=sidewalk or footway=link.

10 Likes

For your consideration, besides not being =crossing , I would like to think of some reasons against considering them as =sidewalk :

  • Conceptually: A sidewalk is best understood as parallel to the roadway. These are perpendicular. I don’t know whether the is_sidepath= supporters think this should be =yes . Their premise of treating footway=sidewalk as implying is_sidepath=yes would fail mid-block, requiring a =no override.
  • Short ones (narrow sidewalks): They are often sloped to the crosswalk. It’s not as “flat” (excluding the crossfall) as the rest of sidewalk.
  • Long ones (wide sidewalks, landscaping, or bikepath terminated to join the sidewalk): Causes overestimation on length of sidewalks
  • Routing: They might be skipped when generating any navigation guidance, eg matching names. For instructions, the router should probably say go straight or turn left / right “after crossing”, not “on the sidewalk” somehow, or worse an unnecessary “continue on the sidewalk” (unless maybe they already discard any short lengths).
  • Renderer: They require different rendering rules for 2D area generation, eg shouldn’t be rendered distinctively within the assumed or drawn area:highway=footway area. Could be ignored on more zoom than sidewalks.
9 Likes

When I’m micromapping, I map the stubs and generally tag them as footway=sidewalk, figuring that a pedestrian waiting for a signal is standing “on the sidewalk” rather than “in the crosswalk” or “in the street”. When I’m in a hurry, I often extend the crosswalk all the way to meet the sidewalk proper, with the understanding that someone will have to split it into stubs and islands eventually. We’re talking about literal inches and decimeters in some cases, so a data consumer will always have to account for the lack of micromapping where our data sources can’t facilitate it.

Yes, a fairly naïve router would probably mistakenly instruct the pedestrian to turn onto a sidewalk instead of a crossing. But I think this is a more general problem with routers taking micromapping too literally. By the same token, that router would probably make a mess of a standard intersection by micromanaging the user’s footsteps across itty-bitty turns, instead of taking a more holistic view of the intersection.

Major routers such as OSRM and Valhalla already distinguish between slight and sharp turns by factoring in some length of each approach, not just the angle formed at the immediate intersection node. In the same manner, a router could look ahead to determine how quickly the sidewalk transitions to a crossing. It isn’t easy, but it’s probably critical for improving pedestrian voice guidance along a micromapped street.

A renderer that depicts area:highway=footway would most likely allow such a area to obscure any footways running through it. A renderer that doesn’t attempt to depict footway areas could merge connected footways and then trim any short stubs. However, many of these renderers depict crossings anyways.

3 Likes

I genuinely thought this was precisely what footway=link was invented for (though I’ve only used it a few times). If this isn’t the case then maybe it could be better explained on the Wiki page what it’s for?

2 Likes

To me it seems a bit inconsistent to tag this as footway=sidewalk. If you take a similar situation but with different classifications, for example a highway=residential where a footway branches off, I do not see people mapping the branch as highway=residential until the curb, it is expected that classifications and properties are drawn until the centre node of the intersection.

I don’t see why we should make an exception for sidewalks.

3 Likes

To be honest, vibes may be part of it. But you’re focusing on topological correctness, whereas I think most people micromapping sidewalks are thinking about it in more concrete terms, if you’ll excuse the pun. In some sense, any pedestrian infrastructure is a space, not just a thoroughfare. I can imagine use cases for knowing where a pedestrian would leave the safety of a sidewalk space and enter the street, but the analogue for vehicles would be more contrived.

In your example, micromappers who tag the part within the street as a footway will usually clarify it with either footway=link or footway=crossing crossing=unmarked or similar.

Regardless, no matter which side you fall on in this debate, there’s bound to be edge cases requiring you to make an exception. All for mere inches of pavement.

4 Likes