[Tagging] Feature Proposal - RFC - Pedestrian lane

Nick Bolten nbolten at gmail.com
Sat Nov 23 00:02:00 UTC 2019


> The following pedestrian router already seems to work quite well with
sidewalk=* tags and highway=crossing nodes (examples):

When something "works" 99.9% of the time, it's the edge cases that matter.
But, because this is a network problem, a single edge case can disrupt tons
of paths.

Here's an example (drawing from your very nice diagrams):
https://wiki.openstreetmap.org/wiki/File:Ambiguous_sidewalk_and_crossing_via_street_metadata.svg

Attempting to use this schema requires doing two things:

(1) We infer a set of sidewalk paths from street metadata, usually guessing
about the offset distance. This ends up being an important source of errors
in the routago example in Zollikofen.

(2) We infer street crossings from guesswork that uses street topology,
distances, and any other number of rules we can make up because we don't
actually know for sure which crossings can be used by which sidewalks.

In the case of the marked crossing on top, which sidewalks can use it
(i.e., how should we create our routable graph)? Visually, it is clear that
the marked crossing is to be used by the sidewalk associated with the
rightmost street. However, a heuristic approach could easily identify it as
usable by the other street's sidewalk as well: it is in the correct
topological location (a 'right turn' from an incoming sidewalk) and a short
distance from the intersection (x). Even with more complex heuristics, like
assigning crossings to the nearest intersection, we still get errors
depending on the exact sizes of x and y: perhaps, sometimes, it's usable by
both. This would be no issue were the connections mapped directly.

There's a similarly complex example here:
https://www.openstreetmap.org/#map=19/47.71953/-122.31794. Attempting to
figure out exactly which crossings can be used by which sidewalks is a bit
of a mess due to the proximity of different sidewalk endpoints to nearby
crossings.

This guesswork means the pedestrian paths are uncertain. Imagine if our
street networks were like this, not knowing how they connect to oen another!

>
https://www.routago.de/pedestrian-routing/?map=46.9802955,7.421488,19&start=46.9798388,7.4200845&ziel=46.9800291,7.4229276
>
https://www.routago.de/pedestrian-routing/?map=46.9932946,7.4567288,18&start=46.9936495,7.4545938&ziel=46.9927603,7.4568951

These examples exhibit other issues, though I'll skip the first one because
they're small. The second (Zollikofen) has very clear errors resulting from
this schema: when crossing Zelweg, routago predicts four maneuvers: (1)
turn left to get to the start of the crossing, (2) turn right and get on
the crossing, (3) get off the crossing and turn right (while not called
out, it's visually there), and (4) turn left to get on the sidewalk (or
pedestrian lane, as it is one).

None of those maneuvers are actually required or implied by the on-ground
realities:
https://www.mapillary.com/app/?lat=46.99333843&lng=7.45498349&z=17&focus=photo&pKey=wtKKmazts0SR6pNE8J_8FA&x=0.8600724394834813&y=0.5148842924762222&zoom=0.
You can see the crossing on the left. In reality, the path taken by most
pedestrians will be direct, requiring no particular turns of any kind.

These errors are an artifact of not knowing where the sidewalks and
crossings actually interface and having to guess about them.

Aside from producing errors, this guesswork is highly technical and not
something the vast majority of interested data consumers can do, which
limits the value of the data to a very small set of computer scientists or
extremely enthusiastic programmers + GIS enthusiasts with a background in
graph theory, geospatial analysis, and constructive geometric methods. In
contrast,  pedestrian ways that are directly connected to one another can
be analyzed using any transportation network software and are compatible
with common OSM routers.

> I use highway=footway + footway=link connect steps and sidewalks to a
road, in order to retain the real length and geometry of the steps or
sidewalks and to indicate that these aren't steps or a sidewalk anymore,
but part of the carriageway of the road. Other mappers seem to use this
scheme too (already 743 uses and only every 7th is from me).

Neat! I really like that proposal and would be interested in chatting about
other potential use cases.

Thanks again,

Nick

On Sat, Nov 16, 2019 at 2:25 AM Markus <selfishseahorse at gmail.com> wrote:

> On Tue, 12 Nov 2019 at 23:54, Nick Bolten <nbolten at gmail.com> wrote:
> >
> > > You mean a situation like this?:
> >
> > > https://wiki.openstreetmap.org/wiki/File:Sidewalk_and_crossing.svg
> >
> > One very similar to that, yes! I think I normally wouldn't add
> sidewalk=both to any length of the highway=residential. Is that a typical
> thing to do? I would assume that meant the highway=residential street had
> its own short piece of sidewalk, when it actually doesn't.
>
> You're right, sidewalk=both doesn't make sense in that example. I use
> this tagging only when the junction and the sidewalks are curved. I've
> updated the drawing to better represent the situation.
>
> > The challenge I'm describing is in reliably associating the crosswalk
> with the pedestrian paths. After all, the crosswalk is a node on a
> different street way. I know that I could do it 99.x% of the time, but it
> will require using some graph traversal approaches that most people aren't
> familiar with. Plus, those cases where I couldn't reliably determine it
> could be very important. I suspect this is one of the reasons I haven't
> found anyone using these data in concert (sidewalk=both + highway=crossing)
> to do pedestrian routing.
>
> The following pedestrian router already seems to work quite well with
> sidewalk=* tags and highway=crossing nodes (examples):
>
>
> https://www.routago.de/pedestrian-routing/?map=46.9802955,7.421488,19&start=46.9798388,7.4200845&ziel=46.9800291,7.4229276
>
> https://www.routago.de/pedestrian-routing/?map=46.9932946,7.4567288,18&start=46.9936495,7.4545938&ziel=46.9927603,7.4568951
>
> (However, it seems that it prefers minor roads and paths over distance too
> much:
>
>
> https://www.routago.de/pedestrian-routing/?map=46.9931482,7.4576354,17&start=46.9936495,7.4545938&ziel=46.991809,7.4570239
> )
>
> > > I would simply connect the sidewalk way with the road where the
> > sidewalk ends (and map a barrier=kerb + kerb=* node) and add
> > pedestrian_lane=* to the road starting from where the pedestrian lane
> > begins.
> >
> > So there would be a segment of footway=sidewalk that is not actually on
> a sidewalk? I've been unsure about what to do in similar situations, like
> how to connect footways to roads without implying there's literally a
> footway on top of the road. Probably worth its own, separate discussion (it
> was discussed previously, but without conclusion), so I won't elaborate.
>
> I use highway=footway + footway=link connect steps and sidewalks to a
> road, in order to retain the real length and geometry of the steps or
> sidewalks and to indicate that these aren't steps or a sidewalk
> anymore, but part of the carriageway of the road. Other mappers seem
> to use this scheme too (already 743 uses and only every 7th is from
> me).
>
> https://wiki.openstreetmap.org/wiki/Proposed_features/Tag:footway%3Dlink
>
> Best regards and a nice weekend to all of you
>
> Markus
>
> _______________________________________________
> Tagging mailing list
> Tagging at openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/tagging/attachments/20191122/f2139868/attachment.html>


More information about the Tagging mailing list