osm2streets icon indicating copy to clipboard operation
osm2streets copied to clipboard

Support direction = both ways

Open dabreegster opened this issue 2 years ago • 2 comments

There are many cases where bidirectional travel is allowed on one "lane." We should add that to the Direction enum, then make all caller code handle it properly. In osm2streets itself, the impact isn't huge. But many places downstream in A/B Street will be affected: rendering, routing, traffic simulation, and even blockfinding. Just starting this issue to start tracking notes on how to fix things there

dabreegster avatar Sep 15 '22 03:09 dabreegster

An "alternates" case too. I called it TravelDirection in my types.

Most reads of the value will boil down to "is travel supported in this direction", right? Routing could implement "alternating" and use that for "both ways" too.

BudgieInWA avatar Sep 15 '22 06:09 BudgieInWA

An "alternates" case too. I called it TravelDirection in my types.

Ah right. I guess this fits signalized one lane "under construction" cases, or super narrow tunnels. And maybe even reversible / contraflow highways.

Most reads of the value will boil down to "is travel supported in this direction", right?

I think so, but there are a few abuses of direction in A/B Street that I need to sort out. They started before I knew when to reason in terms of left/right or inside/outside. For example, sidewalks have a forwards/backwards direction that has to be set a certain way, or a bunch of things break (people walking on the wrong side, tracing the geometry of curbs, people transferring between a bus or car and the sidewalk).

A funny in-between example is parking lanes. Are they directional or not? In many places, legally you're supposed to park with the direction of traffic, even if it's not enforced much. But I've seen things like center parking lanes separating the two directions of traffic. Or center turn lanes (ref https://github.com/a-b-street/osm2lanes/issues/184).

dabreegster avatar Sep 15 '22 06:09 dabreegster