Relations/Proposed/Area
| Area-relation | |
|---|---|
| Status: | Draft (under way) |
| Proposed by: | dieterdreist |
| Tagging: | type=area |
| Applies to: | relation |
| Definition: | a relation to connect and divide ways along linear distribution and on nodes. Defines implicit areas, area steps, might also introduce lanes. |
| Rendered as: | whateveryoulike |
| Draft start: | 2009-12-02 |
| RFC start: | * |
| Vote start: | * |
| Vote end: | * |
Contents
|
Area-relation
A relation type=area is a linear connection between two ways which defines an area between them. This area can also be considered as crossover possibility. It can be used for the description of:
- highway areas,
- steps,
- to define where there is a possibility to cross (in the case of kerbs, fences, walls, etc),
- or even to demonstrate that there is no possibility to cross.
- you can (optionally) define the dividing object (physical barrier or legal limit like road markings) either
- implicitly with tags
- or with other geometry (barrier objects)
Generally areas are considered routable, i.e. an area-relation defines a linear connection between two and more (contiguous) ways. If they should not be, an element of the role : barrier or a Tag barrier=* must be added. The barriers (dividers) can be areas, ways or nodes):
The relation attaches areas like streets to the centre-line-highway=*-graph. It allows for lazy mapping because only the lateral limits are needed to define an area.
Example uses
- The area-relation allows to draw lanes, road-markings and kerbs and define the relation / area between them (possibly allowing routing from one way to another without interconnecting nodes):
- A special case for the use of an area relation are wide stairs. See below for more details.
Reasoning
- to define linear connections between ways (required for links, pedestrian areas, parallel ways which are divided in a way that pedestrians, or bicycles could still change (grass, bollards, etc.), required for highway=lane to express a linear possibility of changeover)
- to define lowered kerbs or entrances for crossing (e.g. you could put the relation on two ways, define divider=kerb and add a lowered_kerb - node to it so it is clear where there is a changeover-possibility for wheelchairs. You can either define linear dividers or nodal dividers, nodes can also have a length=* added (e.g. lowered_kerb), so that the node is considered the centre point of the barrier, and length defines a projected centre-line between the two adjacents ways that are in the relation. If the adjacent ways have given a width-tag the position of the node is considered to be interpolated between half the width of each of these ways. If just one way has a given width, the position would be in a projected distance of half the width of this way.
- to define an area between two ways without having to draw another area over it
- to define area-steps
Area-steps, steps which are wide and/or irregular
scheme
<to be added>
Tags for the relation
- type=area
- highway=steps
- step_count=23
Roles for the way members
- role=lower for the lower way
- role=upper for the upper way
- optionally one or two ways with role=lateral
requirements for the ways
The upper and lower way should have the same amount of nodes and point more or less in the same direction (do not have an inversed direction).
highway / lane / barrier
Members
required
optionally
- one or more way(s) tagged barrier=*
- one or more nodes tagged barrier=* or differently (e.g. natural=tree) with role : barrier.
Please note that the divider can also be defined with a tag barrier=* on the relation.
Roles for highway/lane-mapping
- role : highway for ways where highway=is not set to lane. This role is used for ways that are considered to be mapped in the centre of the physical way.
optionally
- role : lane for ways tagged highway=lane (and optionally turn=right/no/u/left, lane and turn as subtag of lane are new proposed values as well)
- role : barrier for areas, ways and nodes tagged barrier=*, natural=tree (to make a forest with single mapped trees routable, you would create an area and add all trees with role : barrier
- role : area for areas that should be considered routable. E.g. you could add an object tagged leisure=park or landuse=forest as area into the relation implying that pedestrians can cross everywhere. This is not necessary in case of highway=* with area=yes.
Tags on the relation
required
and one of the following
or
- area=pedestrian to make objects routable that are not tagged with highway=*, e.g. landuse, natural, ... Do not use this for pedestrian areas tagged with highway=pedestrian and area=yes but use area=highway for those.
or
- any other defined value still to come or not foreseen by now.
optionally
- width=* to define the width of the area (can be used if the width of the streets are not given or to check the street-width-values, in case of variable width it should not be set)
- barrier:width=* to define the width of the (virtual) barrier.
- barrier:height=* to define the height of a barrier (if there is no barrier/divider given, or the barrier is no, or the barrier/divider is a white uninterupted or different marking, height=0 could be given). Example: barrier=kerb, height=0.2; Example2: barrier=wall, height=2. Values for height and width should be given in metres or with explicit unit.
note
Explicit Barrier-objects (objects with role : barrier) have precedence over barrier-tags on the relation. If objects with role : barrier are part of the relation, no barrier-tags should be added to the relation itself.
barrier mapping
example tags
- barrier=yes generic way for physical dividers, usually not crossable by pedestrians, preferably should be more specific (and can therefore become crossable by different vehicle-types):
to cross the barrier:
- barrier=no (if you want to be sure)
- barrier=continuous_line (to define road-marking)
- barrier=broken_line (to define road-marking)(NOTE: not sure about exact English term)
- barrier=diagonal_line (to define road-marking for areas)(NOTE: not sure about exact English term)
- barrier=road_marking (should be )
- barrier=lowered_kerb (can be a way or a node with optionally length and width in metres)
- barrier=entrance (is used for openings in barriers like walls and fences)
- barrier=gate
Position of the Barrier
The barrier/divider is asumed to be in the position of half the width=* of the ways in case that 2 ways with role : highway are involved. If width is not set or if lanes are involved the position could be calculated by the software regarding number of lanes and given widths (to get good results under conditions where not all data is set).
In complex situations there is always the possibility to add explicit divider-objects to the relation with role : barrier.
Additional information for barriers (optional)
- foot=yes
- bicycle=yes
- wheelchair=yes
...
Useful combinations
surface=*
Usecases
- dual carriageway to define the divider object and or to show possible linear changeover (e.g. for pedestrians, wheelchairs, bicycles, cars, climbers)(e.g. these two ways are separated by a grass-divider (what does actually permit pedestrians to cross at any place)
- to connect highway=motorway_link or highway=lane to highway=*
- to define things like: there is a kerb between the footway and the street, but on given nodes there is a lowered kerb to crossover.
- lanes in general - I propose highway=lane and turn=no for lanes with straight arrows or no arrow marking) and turn=something-else for turning lanes (see below)
- lanes that will turn on next crossing (highway=lane and turn=right/left/u), to define changing possibility to this lane and continuous markings where changing is not legally possible but physically possible. This would require somehow double mapping and tagging (as there has to be a artificial way that connects the original (main) way to the way where physical division exists and therefore the way is to model explicitly as normal normal highway, (which is the last changeover possibility for the lane) as a normal way (so that applications can do routing considering the lanes but will work also not knowing about them).
- steps that cover a bigger area than necessary for simple transition
Rendering / Display in Editors
The relation type=area is rendered as an area above landuse and below linear ways. It is (should preferably) displayed in editors like an area. Eventually the virtual dividers/barriers (i.e. that are not mapped explicitly and therefore not added as role : barrier or role : divider to the relation) are displayed as well.
Consistency with current data model
- the new lanes are tagged differently than existing highway classes to avoid inconsistencies. Existing highways are kept.
- this proposal permits to map lanes explicitly maintaining routing capabilities for existing applications (if an old applications doesn't know of highway=lane and the area-relation it will still keep working)
- common barrier=*-Tags can be used on the relation and common barriers can be added with role : barrier
- all common objects can be used as role : barrier
- the proposed area-steps are completely compatible with the current data model, especially if you draw an additional center-line.
See also
Comments
please use Talk:Relations/Proposed/Area
