# Relations/Proposed/Area

(Redirected from Tag:type=area)
Jump to: navigation, search
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
Drafted on: 2009-12-02
RFC start: *
Vote start: *
Vote end: *

# 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 (consecutive) ways. If they should not be, an element of the 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. At the same time, avoiding explicit connections of the ways results in more transparent and less error prone mapping (because people won't connect highway areas and highway graphs by error).

## Requirements

• 2 ways in an angle < 180° (i.e. directions are "similar") optionally roles lower and upper
• ways must not intersect and if they touch it must be their endpoints
• optionally "lateral" ways

## 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 and slopes. 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

<to be added>

## Roles for the way members

• role=lower for the lower way
• role=upper for the upper way
• optionally consecutive ways with role lateral connecting start points and/or end points.

### 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).

# Slopes

It's the same as for area-steps, but rather than highway=steps you use natural=slope (or maybe something else, as some slopes are "man made").

## Roles for the way members

• role=lower for the lower way
• role=upper for the upper way
• optionally consecutive ways with role lateral connecting start points and/or end points.

# highway / lane / barrier

## Members

### required

• at least 2 ways with either highway or lane

### optionally

Please note that the divider can also be defined with a tag barrier=* on the relation.

## Roles for highway/lane-mapping

• 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

• 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)
• 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 barrier
• 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

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 barrier) have precedence over barrier-tags on the relation. If objects with 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:

### 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 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 barrier.

...

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 barrier or divider to the relation) are displayed as well.

## Consistency with current data model

1. the new lanes are tagged differently than existing highway classes to avoid inconsistencies. Existing highways are kept.
2. 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)
3. common barrier=*-Tags can be used on the relation and common barriers can be added with barrier
4. all common objects can be used as barrier
5. the proposed area-steps are completely compatible with the current data model, especially if you draw an additional center-line.

## Comments

please use Talk:Relations/Proposed/Area