Proposal:Divided road
Divided road | |
---|---|
Proposal status: | Abandoned (inactive) |
Proposed by: | Vovanium |
Tagging: | divider=... |
Applies to: | node/line/relation |
Definition: | Tagging scheme |
Statistics: |
|
Rendered as: | line at the middle of a road |
Draft started: | 2009-09-17 |
RFC start: | 2010-02-20 |
Note to native english speakers: feel free to correct my language.
Proposal
This proposal calls for a way to tag two-way streets that are centrally divided in some fairly minor way (painted traffic island, median strip, barrier).
Note: This proposal was originally created by Vovanium. It has been substantially rewritten, with some parts removed, by Stevage.
Scope
This tagging scheme is applicable to roads, which:
- have a relatively narrow division between the two directions (perhaps 1-2 metres at the most)
- have a central divider of approximately constant width, separating opposite directions;
- treated as one bidirectional road by national or local law (according to road signs, junction layout etc.);
Stevage: It is particularly suited to minor roads with a median strip, for which mapping as two separate roads is inappropriate, and mapping as one road lacks information.
Vovanium: It may be mostly effective on large, long ways having many curves and adjoints (like Moscow MKAD Ring Road) and this was primary motivation for writing such proposal.
This proposal is not applicable to:
- boulevards or streets with great separation between lanes.
- dual-carriage motorways (To be discussed -Vovanium).
- roads with complex arrangements of lanes, where it is best to individually the behaviour of each lane.
- non-vehicular roads
There are some grey areas for discussion:
- Dual carriageways with a very thin physical divider ([1]). Logically and administratively such ways are single objects. They go through single (not separated) bridges and tunnels. There's no separate junctions for each direction when the way crosses another. The only reason to map any road without much space between opposite lanes separately is the lack of a suitable tagging scheme. This proposal gives one.
This proposal does not invalidate any of currently used schemes, so nothing serious that lots of ways are already drawn. They may stay as done. But there's lots of mapping and this proposal may help a much.
Motivation
There are many areas where a street is momentarily separated. This is a useful landmark to render, and may have consequences for routing, but the current options are very limiting: either one way (with no indication of separation), or ways, with no indication that they're really one street.
- One way: Restriction relations must be used to forbid crossing the divider. This renders ok (but currently with no visible indication of the restriction, or its cause). However, the number of separate road segments and restrictions grows to huge values: you need to create a no_u_turn restriction every time the way is split. You need at least two restrictions when a smaller way meets separate way. This is a lot of work and complexity.
- Using two separate ways. This method exempts the need of many restrictions on adjoining ways. However, it requires the double the amount of work. Although tools such as JOSM and Merkaartor have some support for manipulating duplicated ways, Potlatch and other tools don't. Also, junctions become very complex, especially when where are several dual ways. And, while not the major concern, duplicated roads do render messily, which is a very difficult problem.
The main benefits are thus:
- Cleaner, more appropriate modelling of the road. If the road looks like one road with a divider, it should be modelled as one road with a divider.
- Improved usability: it is much simpler and easier to enter the tag, than to create all the separate ways.
- (Improved rendering: this is just an accidental benefit. Renderers struggle to make two separate ways render cleanly, frequently repeating street names needlessly, and failing to draw the divider cleanly.)
Physical properties
Divider property
Incorporate Proposed features/Divider to this proposal, so type of divider appear as:
Tag | Applied to | Meaning |
---|---|---|
divider=no | No division or legally passable divider | |
divider=yes | This should not be normally used, but left for cases where divider type is unknown. | |
divider=legal (or divider=line) | A painted line or box that must not be crossed or another restriction rule (road sign or so). | |
divider:forward=legal or divider:forward=line | A line that can be crossed only in one direction (backward->forward) | |
divider:backward=legal or divider:backward=line | Same as above, but for opposite direction. | |
divider=median | A low median strip, about the height of a normal kerb. It could be physically driven over, but only in exceptional circumstances. Also pedestrians may easily pass it. Please note that median with hedge should be marked as barrier. | |
divider=barrier | A solid barrier that could not be driven through, and which a pedestrian would only cross with difficulty, if at all. | |
divider=physical | Some other sort of physical barrier, for example which may be passed by pedestrians but not vehicles. | |
divider:width=* | Distance between inner edges of the adjacent lanes. Either a number "1.5" or "1.5 m" in metres, or feet: "4 ft". | |
divider:height=* | Height of divider from road level. | |
divider:type=* | More specific divider type specification, for example:
These values might not affect routing. | |
divider:material=* | What the divider is made from (values might be grass, cobblestone, steel, ...) | |
Divider gaps (there is an alternative opinion on how it should be mapped: see below) | ||
divider=u_turn | Gap in divider where vehicles are turned to opposite directions | |
divider:backward=u_turn | Sort of gap where only turn form backward to forward direction (according to way direction) is allowed (was: divider=u_turn_forward). | |
divider:forward=u_turn | Same for turning from forward to backward (was: divider=u_turn_backward). | |
divider=gap | Gap in divider that should not be used for u-turns. Note that if gap is long, more than about 10..20 m / 30..60 ft, then it should be mapped as line with divider=no (or without tag at all). | |
divider:gap=* | Gap / u-turn gap length. |
Also this tag should be applied to junctions where an u turn is allowed.
There was also 'divided=*' form proposed but I decided to refuse it because divider=* is already used in mapping, so it would be better to just 'legalize' its using.
Adjoints and junctions
By default, when a divided way has a junction with a non-divided way, the division is unbroken. That is, when A-X-B (with divider=barrier) crosses C-X-D. Use divider=u_turn to allow this.
When two divided roads meet at a junction:
- If divider=u_turn is not set, this is a weird situation, implying a cross-shaped barrier where all four ways must turn left. This is probably an error, if it occurs.
- If divider=u_turn is set, then it describes an open area where all turns are possible.
Tag | Applied to | Meaning |
---|---|---|
junction=yes | Common type junction at which divider is broken and may be crossed in any direction. | |
junction=adjoint | Adjoint with unbroken divider at which adjoining way is connected to only one direction. |
Routing
This tag has a few, fairly obvious implications for routing. Each side of the divider is treated as a one way street.
Let's take more detailed look at divided road elements:
- Road length
- Common restriction on divided road applied:
- Vehicles may not uturn wherever divider=* (except none) is set, unless at a node with divider=u_turn set.
- Vechicles may not uturn from forward to backward [from backward to forward] direction wherever divider:forward=* [divider:backward] (except none) is set.
- U-turn places
- Such places are marked by divider=u_turn, divider:forward=u_turn or divider:backward=u_turn.
- Vechicles may uturn in both directions when divider=u_turn is set.
- Vechicles may uturn from forward to backward [from backward to forward] direction side when divider:forward=* [divider:backward=u_turn] is set.
- Junction
- There are two types of juntions: adjoint (which have divider unbroken), and common type junction (on which divider breaks).
- Restrictions on junctions may be implied from drive side and side on which other ways adjoin. But because those data acquiring may be difficult, especially in autorouting software, it is encouraged to set driving restrictions explicitly by using adjoint (see below) and/or restriction relations.
- Assuming a left-drive country:
- Vehicles may not turn right from a way where divided=* is set, unless the node has divided=u_turn or junction=yes set.
- Vehicles entering a junction with a way where divided=* is set must turn left, unless divided=u_turn or junction=yes is set.
- To be discussed: there may be uturn and adjoint way at the same node, but because of lanes u_turn cannot be used for driving from/to adjoining way, so such implication may be unacceptable, better use junction=yes.
- In case of adjoint vehicles may not drive from one adjoining way to another, only from main (divided) way to adjoining and from adjoining to main.
Other turn restrictions apply as usual. Restriction relations may be used to fine tune routing. So if you dislike divided:forward/divided:backward tags, you may set restriction on uturn gap to make it unidirectional
Adjoint relation
For adjoint ways a relation is proposed. This gives a way to unambigous routing. Relation defines divded road sides as 'forward' side, and 'backward' side. They correspond to left and right side according to drive side (as stated in country or local laws and rules). So:
- forward ≡ left and backward ≡ right at left-hand drive and
- forward ≡ right and backward ≡ left at right-hand drive.
Relation may be standalone (with type=adjoint) or one may reuse (incorporate into) collection, street, or any other relation representing a road. In case of reusing only adjoin_forward and adjoin_backward are allowed and any other members with highway=* should be treated as main member. Roles forward and backward are only shortcuts for type=adjoint relation. (This paragraph is added after RFC starts and this is only reason why forward and backward are left here).
Also adjoint relation is good for multilevel crossings with links and ramps.
This relation replaces common restriction by more obvious and simpler method, also there's no more need to cut a way to pieces at every adjoint.
In general routing of adjoints should the same as if a way is splitted to two one-ways, in forward and backward directions, and adjoining way is connected to one of them (according to its role).
There's may be misundertanding why relation should be used instead of simple tag. Any tag combination should be ambigous or hard to process.
- If you just connect adjoint way to divided road, router will have to determine to which side it adjon (so it need to do some calculations on geometry instead of just working on topology), and determine side of driving directions (much harder computing task:)).
- Using junction attribute does not erase problem above.
Routing cases explained
All the routing rules are stated above. This section just explains how they are applied.
(1) Divided way splits to two one-directional ways without turning place
- Vehicle from divided road should move to one-way from divided road.
- Vehicle from one-way-to should move only to divided road.
There are two cases (case b shown on the picture):
- (2a) Split point is at the beginning of divided road (first point in a way)
- Divided way is main role of adjoint direction.
- One-way from which vehicles come to divided road is forward role of adjoint relation.
- One-way to which vehicles move away is backward role of adjoint relation.
- Node is tagged as junction=adjoint
- (2b) Split point is at the end of divided road (last point in a way)
- Divided way is main role of adjoint direction.
- One-way from which vehicles come to divided road is backward role of adjoint relation.
- One-way to which vehicles move away is forward role of adjoint relation.
- Node is tagged as junction=adjoint
(2) Single adjoining way
- Vehicle on divided road at side at which way adjoin may move straight on or turn to adjoining way (unless it is one-way-to).
- Vehicle on divided road at opposite side may only move traight on.
- Vehicle from adjoining way may only turn to direction that on side at which the way adjoins (right if right drive, left if left drive).
- (2a) When adjoint is at 'forward' side
- Divided way is main role of adjoint relation.
- Adjoining way is forward role of adjoint relation.
- Node at which ways are joined tagges as junction=adjoint.
- (2b) When adjoint is at 'backward' side
- Divided way is main role of adjoint relation.
- Adjoining way is backward role of adjoint relation.
- Node at which ways are joined tagged as junction=adjoint.
(3) Two adjoining ways from both sides
This case is nearly the same as to (2a) and (2b) combined.
- Vehicle on divided road may only move straight on or turn to adjoining way at its side (unless adjoining way is one-way-to) and may not turn to opposite adjoining way.
- Vehicle from adjoining way may only turn to direction that on side at which the way adjoins.
- Tagging
- Divided way is marked as main role of adjoint relation.
- Adjoining at forward-driving side way is forward role of adjoint relation.
- Adjoining at backward-driving side way is backward role of adjoint relation.
- Node marked with junction=adjoint.
(4) Non-divided and divided way crossed in a junction
- Driving from any direction to any direction is allowed, unless explicitly stated by restriction relation.
- Tagging
- Junction is tagged as junction=yes and divider=u_turn. u_turn is necessary to allow vehicles u-turn on divided road, if it is not set vehicles mat not u-turn on divided road, but may on non-divided.
(5) Two divided ways crossed in a junction
- Driving from any direction to any direction is allowed, unless explicitly stated by restriction relation.
- Tagging
- Junction node is tagged as junction=yes and divider=u_turn. Note that divider=u_turn applies to both divided ways.
(6) Divided way splits in two with u-turn place
- Vehicle from divided road may move to one-way from divided road or u-turn.
- Vehicle from one-way-to may move to divided road or one-way-from.
- Tagging
Properties that affect only one direction
All already known road properties may be applied on individual side of separated road by adding suffixes ":forward" and ":backward" to tag name. At least this whould be applicable to physical, structural characteristics (width, no. of lanes), legal restrictions (maxspeed and others). E. g. maxspeed:forward=100 tells us maximum speed is 100 km/h when travelling toward end of way.
There are also some propositions on lane mapping, which may be useful:
Good tags to use with
These tags are listed in this proposal just for information. No changes in their meaning are proposed here.
Tag | Applied to | Meaning |
---|---|---|
width=* | Total width of a road in metres. | |
lanes=* | Total number of lanes in a road. These two tags are very useful when mapping wide roads, so renderers may show road correctly and navigators will not confuse between the main and satellite ways. |
Alternative opinions and options
There are some alternative opinions on how things should be. This section is for discussion.
U-turn place
Tag | Applied to | Meaning |
---|---|---|
divider:gap=* | A gap where both directions may perform u-turns. If only one direction may perform a u-turn, use this node with turn restrictions. (For discussion, should this be junction:gap=* instead?) |
Properties that affect only one direction
If the two directions have different properties (different speed limits, numbers of lanes, a speed hump), they should be modelled separately. If there is a need to allow this within a single divided road, this can be discussed when that need arises.
Way direction change problem
Many people call attention to that way direction may be unintentionally changed so routing will become wrong. IMHO this is not a problem at all because we already use way direction in many places (one-ways, barriers, etc.) so everyone (and mapping software) should already be aware about way direction and do not do such things without care.
As a 'patch' adjoint relation member 'direction' may be added which contains last node of way.
Also drive_side=right and drive_side=left may also be proposed for 'redundant encoding with error detection' of routing rules.
Goals
- Reduce amount of stored, transmitted and processed raw data without lack of information.
- Just half number of nodes and segments drawn compared to two ways method. One relation per whole instead of 2 per adjoint when using restrictions.
- Get better rendering wihle keeping algorithms simple.
- See the picture.
- Provide more detailed and accurate information on road properties.
- For example there's currently no way to explicitly permit u-turn.
- Simplify management of divided roads.
- Couple of simple attributes instead of dozens of restrictions or duplicate ways, which should be kept parallel.
For discussion see Talk:Proposed features/Divided_road.