Documenting the issues and history of the key busway=*

I’m in the process of formally deprecating the key busway=* thanks to the existence of better tags such as bus:lanes but I first need to find all the issues of this tag as well as how this tag came about to be.

I know the following ones:

  • Ambiguous lane count (I have seen roads where the lanes of busway=lane weren’t counted towards lanes, though according to bus lanes, they should count). Actually brought up.
  • Lack of position (is it a bus lane in the middle or at the edge of carriageway?)

I also know that it was used at a time when access restrictions were more primitive e.g. oneway:bus wasn’t in use (see busway=opposite_lane akin to cycleway=opposite) and bus:lanes first had to be properly defined but I also want some text sources and first hand experiences.

2 Likes

To bump it a little, I’ve been drafting a proposal to formally deprecate it and is nearly ready aside from requiring some tagging examples (even better would be some illustrations for the examples like on cycleway=opposite but the focus is on the main core).

Example 5 shows a worse problem in lanes:* from the possibility of using lanes:bus:backward=1 + lanes:taxi:backward=1 for lanes:backward=1 . I feel that simply the question of whether busway=lane is counted in lanes= needs to be decided. It can be preserved as a crude method when someone doesn’t want to do all the motor_vehicle:lanes= + bus:lanes= in different number of lanes= on each section. That would ease bus lanes on wider roads.
It could be applied non-physically separated center-running bus lanes Shouldn't we make rules that suit each country's road system?
Another application is determining the side of bus lanes. bus:lanes= would have to be parsed. With busway:*=lane , it’s straightforward.
In either case, you can instead start with deprecating busway=opposite_lane only. That’s as easy as cycleway=opposite_lane recently.

Thanks. I’ve never used busway=, only the lanes: scheme which I’ve found to be clear and well documented.

In example 5, shouldn’t it just be lanes:psv:backward=1 instead of lanes:bus:backward=1 and lanes:taxi:backward=1? It’s not clear to me how example 5 is different from examples 2-4, which do use lanes:psv.

In all fairness, I had forgotten to update these but I think it’s better to keep the examples lanes:psv and why it’s used in these situations.

Yes I think that makes more sense.

lanes:bus:backward=1 lanes:taxi:backward=1 should mean one lane for buses, another lane for taxis. Otherwise the following would be ambiguous:

lanes:backward=2
lanes:bus:backward=1
lanes:taxi:backward=1

Is this one lane for taxis and one for buses, or is it one lane for taxis and buses and another for general traffic?

It makes more sense to map buses and taxis sharing the same lane with lanes:psv:backward=1.

There is also the scheme

lanes:backward=2
bus:lanes:backward=yes|designated
taxi:lanes:backward=yes|designated
vehicle:lanes:backward=yes|no

It’s even more unambiguous. Bus and taxi could still be combined with psv.

Yes but that’s a well established tagging style which is mentioned both in the proposal and in Bus Lanes (to the point where I say it’s the main way of tagging bus lanes on OSM).

On that aside, any further discussion should better move over to [RFC] Deprecate busway=* for bus lanes