I just saw some news here in my beautiful city (Fortaleza, Brazil) that the municipality implemented over a thousand bike boxes (for motorcycles only, not bicycles). Since we have a great interaction with the municipality, I could ask them this data. But how to tag them?
I know we have right now cycleway=asl for bicycles only, but what about motorbikes?
There’s a very little discussion in that wiki page, and so far it seems bike boxes (for motorbikes) are very common in Brazil and in Spain, but I didn’t do further research.
Someone in Barcelona used the tag asl:motorcycle=yes, but I guess it’s the only case in the world according to Overpass. Around Paris, someone used bike_box=yes4 times, but I think it’s mistagged (this edit happened 10 years ago, and now it has double tagging along cycleway=asl).
So, is there any way we could tag them? Here in Brazil they are called motobox, but I don’t know any English equivalent name.
=asl is not useful. =traffic_signals should be expanded. For compatibility, any competent application should know how to collapse multiple =traffic_signals close by to treat it as one junction.
Hook turn for bikes, and motorcycles, has already been asked before. They are not ASL. It’s not scalable to have a new feature for different stopping line for each mode, eg presignal for bus queue jump (sorta set back stop line).
Thank you for all your input. I am not an expert on tag semantics, so as a regular mapper I liked both ideas (proposed by @Map_HeRo and @IgorEliezer). The idea of Mikke seems interesting because both cycle ASLs and motorcycles could be combined in the same tag (highway=asl), but then a formal proposal should be done in order to deprecate the current asl and so on).
Fidelis’ second idea is also nice and seems on the same page as @Kovoschiz message (combine on the traffic_signals), but I am worried about having two ways of mapping.
Routers do collapse multiple highway=traffic_signals nodes when two dual carriageways intersect and the intersection nodes are tagged as highway=traffic_signals. But I assume you mean that both highway=traffic_signals nodes would be located at stop lines, which means the router would need to recognize that both nodes are associated with the same intersection, even if they point in the same direction. It seems reasonable but will probably be surprising to developers who are unfamiliar with these “motoboxes”.
At one point, I had hoped to popularize highway=stop_position or somesuch to distinguish between the stop line and the intersection controlled by the signal. But road_marking=solid_stop_line came into use in less than ideal circumstances, and there wasn’t much desire to connect them to the roadways where routers could make use of them.
How do routers usually treat a “diamond” intersection (not limited to actual diamond interchanges) with =traffic_signals stop line between the 2 intersecting nodes now? Some far-side crosswalks will also have their own stopping lines at larger intersections. Granted, they are on different sections (different edges on a graph? Don’t know how it is generated and simplified), but can I say they are more difficult to be identified as same intersection? Adjacent =traffic_signals close-by on the same section are more apparently the same intersection. road_marking= will often not be connectable to the highway= road line when they are drawn as separate lines on the physical position for stepped back stopplng lines on each lane. Then there’s the point vs line usability thing.
The difficulty for mode-specific junction control (including signals, stop, and give-way) is similar to lane-specific ones:
It is unexpected to modify the feature by suffixing highway:lanes= / highway:motorcycle= . At least that’s only done for attributes now. It will worsen if you try to add semicolon multival into the mix when there are both signalization and stop control info, not to mention movement-based control for turn-specific rules.
highway=traffic_signals + traffic_signals:lanes= / traffic_signals:motorcycle= requires applications to combine =traffic_signals on the same side to treat as one junction. However as I asked above, I don’t know if this is much more difficult and unreasonable than combining =traffic_signals on different sections (far side across an intersection, and diamond intersection middle).
traffic_signals:lanes= / traffic_signals:motorcycle= alone lacks a feature tag.
Considering the need for turn-specific and signal-specific (for turn on red) control (where using =restriction or similar has been suggested), it may be better to use relations similar to =enforcement to show special rules on different points. This may minimize the number of =traffic_signals , and limit it for all general traffic. But then there are the usual complaints about using rel .
Can you give an example? I’m not picturing it based on the description. For what it’s worth, the collapsing behavior isn’t airtight. It’s about coalescing the most common cases.
Routers mostly use highway=traffic_signals, highway=stop, etc. to add tiny penalties that add up over the length of the route, affecting the ETA and potentially giving the advantage to a different route. If it fails to coalesce one or two stoplights, it normally isn’t a big deal, but if every intersection in a city has a motobox, then it might start to matter if mapped as two successive stoplights. It sounds like this might be the case in some cities.
Another issue would be if the additional light throws off guidance instructions, such as, “At the next traffic light, turn left.” Hopefully an implementation of that feature would rely on associating each highway=traffic_signals node with the nearest intersection that the traffic_signals:direction points to. If so, then it probably doesn’t matter if two of them get mapped to the same intersection.
Mock-up abusing restriction= (not exactly the same as other proposed rel eg type=traffic_signals_set ) :
node -1
note=The intersection. Ignoring any other tags.
node -2
note=The box's advanced stop line. Assuming no feature tag required. Ignoring any other tags.
node -3
highway=traffic_signals
traffic_signals:direction=forward
traffic_signals=signal
traffic_signals:motorcycle=separate
note=Is only an example of how motorcycles may be indicated as excluded on the `highway=traffic_signals`
node -4
node -5
note=The light (eg `man_made=traffic_signals` ?), or sign (eg `traffic_sign=`) for give-way and stop control. Ignoring any other tags. (Optional micro detail)
way -1
highway=*
note=The approach
nd -3
nd -2
way -2
highway=*
note=The box as line (optional)
nd -2
nd -1
way -3
highway=*
way -4
highway=*
rel -1
type=restriction
restriction:motorcycle=traffic_signals
note=For motorcycles
wy -2 from
nd -1 via
wy -3 to
wy -4 to
nd -2 force
nd -5 device
rel -2
type=restriction
restriction=traffic_signals
restriction:motorcycle=none
note=Optional for general traffic, for completeness.
wy -1 from
nd -2 via
wy -3 to
wy -4 to
nd -3 force
nd -5 device
restriction= here is interpreted as what traffic control the vehicles must follow to proceed.
For OSRM, it depends on the distance, name, and geometry. These test cases might shed some light. There’s also support for collapsing staggered intersections, but it probably isn’t aggressive enough. I don’t think a highway=traffic_signals node in a very short interior edge of an intersection is enough to prevent collapsing, since the signals don’t split the edge in two. This is an argument for a more explicit modeling of the extent of an intersection (and for routers to make use of it), which probably deserves a separate discussion.
Yeah, it’s going off-topic. What I thought is the detection of stopping positions at one intersection may interface with the detection of different but related intersections.
highway:part=traffic_signals + eg traffic_signals:motorcycle=signal for the box may be created,
after a highway=traffic_signals + eg traffic_signals:motorcycle=separate for other traffic.
This is similar to building= and building:part=, however there won’t be a highway:part=traffic_signals for the root highway=traffic_signals .
This avoids the issues of highway:motorcycle=traffic_signals, highway=traffic_signals + traffic_signals:motorcycle=signal , and a lone traffic_signals:motorcycle= . The relationship between them will be established by detection of highway:part=traffic_signals between a highway=traffic_signals and the intersection node (may have junction=intersection added), or more explicitly a rel similar to type=building . Turn-specific control can be considered separately later.
Off-topic-wise, for set back stopping lines on each lane:
The most upstream stopping line of a highway= + lanes=3 can have highway=traffic_signals + traffic_signals:lanes=signal|separate|separate for the left most lane (RHT).
The other lanes downstream will have highway:part=traffic_signals + traffic_signals:lanes=no|signal|separate ,
then highway:part=traffic_signals + traffic_signals:lanes=no|no|signal finally for the right most lane closest to the intersection.
However, this doesn’t fully solve the case of continuous green lanes without raised separation at the stopping line (they exists). It will still have highway=traffic_signals + traffic_signals:lanes=signal|no|no causing compatibility risk of penalizing the straight ahead lanes with a raw highway=traffic_signals when not supported by applications. Nevertheless, I hope this is simpler and less things to solve.
