Hello nice people!
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=yes 4 times, but I think it’s mistagged (this edit happened 10 years ago, and now it has double tagging along
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.
Pinging here @mods-spain. Podéis llevar esa discusión a los españoles, por favor?
Also pinging the people who started that discussion in the wiki: @Bxl-forever, @IgorEliezer, @Nighto and @yopaseopor.
As there appears to be no established tag for these motoboxes I could imagine using a similar tagging as for cycleway=asl, using
highway=asl + motorcycle=designated
=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).
At least in my city (800K) there are around hundreds of motoboxes, and almost… none ASL for bicycles.
My suggestion is that a motobox could be mapped both as a standalone feature and a secondary tag.
As a standalone feature, as a node placed at its actual position with highway=motobox.
As a secondary tag along with traffic signal node, for micromapping: highway=traffic_signals + motobox=yes.
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.
@Kovoschiz do you have any tag to be proposed?
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: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.
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: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
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=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.
restriction= (not exactly the same as other proposed
type=traffic_signals_set ) :
note=The intersection. Ignoring any other tags.
note=The box's advanced stop line. Assuming no feature tag required. Ignoring any other tags.
note=Is only an example of how motorcycles may be indicated as excluded on the `highway=traffic_signals`
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)
note=The box as line (optional)
wy -2 from
nd -1 via
wy -3 to
wy -4 to
nd -2 force
nd -5 device
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.
Ah just a stop line in a wide median between the 2 carriageways of a divided road. Like the intersection of a compact urban diamond interchange.
Roadway Design Manual: Median U-Turn Intersection (MUT) Say there is a stop line inside the main intersection of a median u-turn junction. http://onlinemanuals.txdot.gov/TxDOTOnlineManuals/TxDOTManuals/rdw/images/e_mut1SigMnInt.png
Assuming diamond interchanges and other unconventional “intersections” should be treated as 2 intersections.
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.
I came up with a possibly simpler method:
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:part=, however there won’t be a
highway:part=traffic_signals for the root
This avoids the issues of
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
lanes=3 can have
traffic_signals:lanes=signal|separate|separate for the left most lane (RHT).
- The other lanes downstream will have
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
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.