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
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).
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 favorsidewalk 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? (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.
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.)
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?
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/....
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 .
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
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)
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.
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.
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.
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.
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).