That said, StreetComplete will ask for properties of kerbs even if barrier=kerb hasn’t yet been added on the node when it is mapped this way (at the nodes highlighted in blue):
but will not ask when it has been mapped like this on the nodes highlighted in yellow (or if there was a footway=link in-between):
(When barrier=kerb is present at a node, kerb properties will always be asked. So, this post is just to inform that for StreetComplete, there is some automatic “kerb is missing”-detection but it only works if a crossing is mapped like in the first picture.)
The reason not to do this is that the curb node is then in the “middle” of the sidewalk, and will be penalized by routers that consider curbs even if a user is going straight. While the sidewalk does dip a little, it does not really have a “curb”, if that makes sense.
I’m not sure I understand what you mean. My proposal would be exactly like your first image but with the exception that those tiny red stubs would be tagged as footway=link. I don’t think the second one should be acceptable as it doesn’t allow the presence of kerb nodes.
That is a shame about StreetComplete not asking for kerbs at the point where a footway=sidewalk and a footway=link meet, as you would think these’d be present in their original usage (a sidewalk ending abruptly and pedestrian traffic being redirected to the road). I think it would warrant filing an issue in their Github (regrettably, my coding skills aren’t good enough to do a pull request on my own)
My first and second post are disconnected from each other. The first post is a reply to you, the second is just an information how StreetComplete behaves depending on how it is tagged.
Anyway, in regards to
I don’t think the second one should be acceptable as it doesn’t allow the presence of kerb nodes.
Of course it allows the presence of kerb nodes. Just add the barrier=kerb node at one vertex of the footway=crossing way (the physical location of the kerb). The second image just shows that StreetComplete does (correctly) not assume that a barrier=kerb node is missing at the intersection between the crossing-way and sidealk-way.
Doesn’t the wiki strongly disencourage this, as it would apply all penalisations of the kerb to people staying on the sidewalk? If you meant mapping it on the crossing segment, that would leave a tiny stub and return us to the first scenario.
Just to be clear, are you of the idea that these stubs should be mapped footway=sidewalk?
(Just add the barrier=kerb node at one vertex of the footway=crossing way (the physical location of the kerb)
The physical location of the kerb is not at the nodes highlighted in yellow. I agree that if the barrier=kerb node was added there, it would be a problem. But that is not what I was saying.
To your question: No, I think they should be mapped like in the second illustration.
But in many cases, the curb height for going into the crossing will differ from the transition height when one continues straight along the sidewalk. And it arguably is not a curb, anyway. In my opinion, the best practice is to place the curb node where it exists in physical reality, not the middle of the sidewalk.
Ah, my apologies for misinterpreting I understand your point now. I think I prefer this reasoning to the footway=sidewalk one and I agree that the argument based on semantics is sound. It does pose the problem that it makes software like StreetComplete work worse (since it wouldn’t prompt people to fill in data for those kerbs), and I think it’d be harder to make it work than my approach.
Maybe, it’s a bit of a gray area I think. Both curb ramps at this configuration are identical to the curb ramp that would be present at a more typical barrier=kerb. Usually someone going straight across would have to go over the tactile paving. For a wheelchair user, the ramps themselves could pose a challenge, just as they do in a more typical configuration, if the ramps are steep enough. But I’m not opposed to mapping a tiny stub in this case too, as long as it remains possible to distinguish the parallel curb ramp configuration somehow.
This is a bit of an ironic example. There’s still a lingering disagreement about where exactly to place the highway=traffic_signal node: at the intersection node or at the marked stop line. Either approach is an abstraction: we don’t intend to place the node at the literal position of the signal along the roadway. Depending on the region, that could be at the near side, the far side, the middle of the intersection, or all three at once. (I sometimes use man_made=traffic_signals when I have some reason to micromap the intersection.)
At least originally, the choice to place stop and traffic signal nodes at stop lines had as much to do with avoiding relations as anything to do with semantics. The primary intent was to move the node away from the intersection, to disambiguate which street it belongs to. Over time, the stop line became the most likely “real” thing to place it over.
Anyways, to reiterate, when someone is standing at the curb, waiting to cross, we normally say they’re still “on the sidewalk”, not “in the intersection”, whether or not that part of the sidewalk is surrounded by a grassy verge. When a cyclist is waiting in a turn lane behind a stop line, even an advanced stop line, we don’t say they’re “in the intersection” yet.
Tagging the whole thing as a footway=crossing reminds me of the now-discouraged style of extending a bridge all the way to the nearest intersection. I still do it sometimes when I’m in a hurry, just as I sometimes extend the crossing all the way to the intersection of two sidewalks when I’m in a hurry.