User:Cmuelle8/Lanes and complex intersections visual approach
If you know about the current state of affairs, please help keep everyone informed by updating this information. (Discussion)
The visual approach to map lanes and complex intersections
The method described here is most simple as it evolves out of established mapping practice. It does not propose new tags or a new tagging scheme. It rather combines existing features of OSM in a specific way. It delivers a general approach to map most complex intersections and their associated turn restrictions.
The list of issues it tries to deal with includes avoiding the upcoming tag bloat previewable at Lane tagging comparison preserving the simplicity of Turn restrictions
Description
Many turn lanes mainly exist on complex intersections, so the question is: How do I map a complex intersection in a simple way? Logically, an intersection consists just of a star topology with:
- ONE node in the middle (the center of the intersection),
- a lot of input lanes (running to the center),
- some output lanes (leading away from the center),
- rules that define which combinations work, which do not (i.e. turn_restrictions for all input lanes).
Mapping/drawing a star topology is simple:
- Draw a way for each lane up to the line of sight OR the stop line.
- hint: a node on the stop line might hold highway=traffic_signals.
- hint: abstracting lanes into a single way IF they have identical turn restrictions works using established lanes=* key, note that it customizes the generality of this approach somewhat.
- Draw a single node in the center of the complex intersection.
- Connect all IN and OUT nodes to this center node.
- i.e. draw a way between the stop line (or similar) node and the center node
- do this for each node on a stop line (or similar, for lanes leading out)
- Define turn restrictions.
- hint: to have the editor display them nicely, I use ways in the via-role, compared to using just the center node in the via-role (a routing engine should not care, either way is fine);
- if you want to use ways in via-roles of the turn restrictions, make sure the way is split at the node you placed on the lane's stop line (or where it would be, if the segment is leading outward);
- now the editor should do an exceptionally nice job for you, it displays the turn restriction symbol aside the lane's stop line/traffic signal.
Examples
|
|
| The screenshot highlights e.g. those turn_restrictions having input lanes you may legally use to leave the intersection to the east.
The right turn lanes in the corners could be routed over the star, but since it looks natural and stays correct, connect them directly. Note: The unconnected ways are a mapnik beautification measure, drop them if you do not like them. It's an interim. See variants below for alternatives to this. This is current data. |
The ways marked red are via members of the three turn_restriction_relations shown (colored magenta).
Some osm-ways are two-laned (lanes=2) for convenience - their properties do not differ. This example is without mapnik guides. |
 |
|
| This is Mapnik's output. Note that it's rendering rules have not been modified to optimize the output of individually mapped lanes. In particular the viz of oneway-arrows clutters the view. |
|
| This one is less complex than above, so a star topology was avoided.
However, the IN/OUT view of the problem stayed relevant for setting correct turn restrictions and using multiple via-segments is now a must. The turn restriction colored magenta in this example is maintained by three via-ways. Still, this could also be mapped using a single center node as above, e.g. you could merge the three nodes to one center node and map it like above. |
How does it compare?
If you try to avoid a star topology on an intersection with 6x6 lanes, you'd create 36 intersecting points in a grid - maintaining turn restrictions would be a mess.
Not mapping individual lanes may decrease the visual complexity, base geometry of the intersection, but then you're stuck getting turn restrictions right. They would have to be re-invented or modified to express:
- from the leftmost lane of way F
- via X via Y (via ..)
only_left_turn - to way T
This has already been proposed as a consequence of some lane tagging proposals.
Mapping lanes individually preserves the simplicity of Turn restrictions. Having a single way in the from-role is slack. As a side effet it also allows for really complex cases, where it is preferable or necessary to thread in on a specific lane to make a correct turn at the intersection following the current, e.g.:
^
|
|_<______
//=<====== leftmost lane preferable..
===>=====//=====>=
||
||
||
||
__<____/ \____>___ ..if you want to leave here
Some caveats
This probably only works well, if you have highres imagery available.
With mapnik rendering just the star data, output looks ugly:
- consider unconnected ways with layer=-5 to feed the renderer
- leave a note=* for other mappers, so they are not buffled
A routing engine should know where arbitrary lane switching is allowed: avoid useless artificial ways that interconnect lanes. So either:
- create a relation in the flavor of type=lane_group and
add all lane segments that allow arbitrary switching at full length
(usually this is signalled by dashed markings on the road), or - draw the lane switching area using landuse=* or similar
(with the lanes you may switch between lying inside this area. This touches the fragile subject of micro-mapping landuse areas. You'll find archived posts on osms mailing list, if you are interested.)
Some day, routing engines and other tools in the osm universe might support sensible routing over area=yess, however this will not eliminate the need to map lanes individually. essentially, drawing 1 area instead of 1 way to represent all lanes will not give you more objects to tag different properties to.
Advantages
- Drawing this is easy (if you have highres images)
- It is easy to understand and use , even for newbies
- There is less information hiding in tags, you get a direct visual feedback
- Defining turn_restrictions is easy
- Checking turn_restrictions is easy: just click on the lane you want to check
- Alignment tools are a great help, re-constructing an intersection
Turn_Restriction shortcomings
The current wide-spread use of TR has one important shortcoming - it limits the count of TO-members to one. In the following two cases, both the only_*_* and the no_*_* variants would benefit if this restriction is changed to 1+ (as is accepted for multiple via-role ways). This would aid a lot of real world situations.
The two examples of turn restrictions shown to the left and to the right are meaningful but invalid wrt the current Turn restriction proposal, since it asks for exactly one TO-role member.
Currently an intermediate way, between the center node and the opening of the second lane leaving south, is used to deal with this shortcoming.
Variants and alternatives
Some variants that show differing approaches, additional things that could be mapped.
You are welcome to add to this table if you have a clever variant.
Please start out with the same intersection, so these approaches can be easily compared.
A negative example - while on the one hand, it's more likely that this will not break current mapnik or a simple geometry-oriented routing engine that does not understand turn restrictions, it is far less manageable by a mapper. This layout degrades the visual simplicity of a bare star topology, in favor of software compatibility. It is, wrt the current state of osms toolchain, more machine-friendly, than human-friendly. Also note, that it is harder to maintain and check turn restriction relations (TR) - there are more via-ways and more possible turns a mapper would have to take care of, especially in the case of type=no_*_* variants of TR. To sum it up, this approach burns mapper's time. |
Another negative example - while it looks nice and has true (wrt to reality) angles for all lanes in the intersection area, it is:
Most nodes are placed at will, their position is hard to reconstruct using alignment tools of an editor. In this example 21 individual intersecting nodes are created that are endangered when maintained. |
A currently incompatible example - this maps the area of the whole intersection and uses it as a VIA-role in TR. Neither the rendering software of OSM, nor routing software is prepared for this. E.g. most routing software still does not know how to handle routing over pedestrian areas correctly. |
An example that includes mapping the area of the intersection as an unroutable feature. It is inspired by Proposed_features/area:highway and maps the area with area:highway=junction and area=yes to give landcover oriented data uses a chance. A renderer could make use of this and simply draw the junction area, instead of the lanes mapped. However, drawing the area explicitly in the detail shown is time consuming as well and a clever rendering algorithm may be able to calculate an approximate shape from the bare star. |