Proposal:Area

Area-relation
Proposal status:	Inactive (inactive)
Proposed by:	dieterdreist
Tagging:	type=area Data item
Applies to:	relation
Definition:	a relation to connect and define barrier ways along linear distribution and on nodes. Defines implicit areas, area steps.
Statistics:
Rendered as:	whateveryoulike
Draft started:	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

How to map

Draw at least the upper and lower borders of the area steps (orthogonal to the walking direction) and add them to the relation. Also add the number of steps with step_count=*. If you want you can add the lateral borders as well. Also keep (or add) the representation of the steps in the highway graph model highway=steps for downward compatibility. While it may not be strictly needed, you are encouraged to put the upper and lower roles in order from down (first) to up (last). This will make it easier for following mappers to comprehend the relation.

Steps with landings

When there are different sections of area steps (horizontal pedestrian areas, stair landings between steps), you can add them all to the same relation using upper and lower roles, but the order should follow the order you experience when climbing up the stairs: lower (lowest), upper (end of first section of steps), lower (start of next section), upper (end of second section), etc. You should add one graph role member for each section, between the upper and lower roles. This graph member should have a tag step_count=* and should start at the lower way and stop at the upper way.

It may be useful for rendering simplicity to have all upper and lower ways running in the same direction and each lower and upper way pair (or pair of upper and lower way strings) having the same amount of nodes (each lower way node relates to a corresponding upper way node).

Scheme

<illustration to be added>

Tags for the relation

• type=area
• highway=steps
• step_count=23 -- total number of raisers of the represented steps object. This can be omitted when there are several steps sections (the step count of each section is contained in the graph member / highway=steps).

Roles for the way members

• role lower for the lower way of the area steps or a section of area steps
• role upper for the upper way of the area steps or a section of area steps
• optionally consecutive ways with role lateral connecting start points and/or end points. (These may also have other tags, e.g. be part of a building=*, barrier=retaining_wall, barrier=wall, etc.)
• role graph for the ways representing the steps in the highway graph model, typically tagged as highway=steps or highway=footway. Add step_count=* if it isn't already present.

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). If you do not add step count information, the renderers will not be able to draw the steps as they are. Still for most common zoom levels, renderers will not be able to show every step (they might show every nth step for example, or draw a symbol, etc.)

Slopes

It is 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"). You can also tag the upper and lower ways with terrain elevation information ele=*, or add ele=* tags to the individual nodes of these ways, if you know it. You do not need to add height or elevation information in order to make use of this relation. For many applications it is sufficient to know that there is an upper and lower border.

Tags for the relation

• type=area
• natural=slope (or maybe area_type=slope?)

If you want you can add the tag height=* to the relation to give information about the greatest height difference between the upper and lower way(s).

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

• one or more way(s) tagged barrier=*
• one or more nodes tagged barrier=* or differently (e.g. natural=tree) with barrier.

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

• type=area

and one of the following

• area=highway (between two lanes or between a lane and a highway=*)

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 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):

• barrier=kerb
• barrier=wall
• barrier=bollard
• barrier=fence
• barrier=ramp_bricks

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

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

See also

• The Future of Areas

Comments

please use Talk:Relations/Proposed/Area