Proposed features/area:highway
| area:highway | |
|---|---|
| Status: | Proposed (under way) |
| Proposed by: | flaimo |
| Tagging: | area:highway=* |
| Applies to: | 
|
| Definition: | A tag to define the two dimensional area of highways |
| Rendered as: | Different shades of gray, depending on the value |
| Draft start: | 2011-05-09 |
| RFC start: | 2011-05-11 |
| Vote start: | |
| Vote end: | |
Contents |
Status Quo
Currently, ways are only one dimensional. They may contain a width tag, but for maps at very high zoom levels, that is not enough information for an accurate two dimensional representation. The situation basically is the same as for waterway=riverbank, where you have a way representing the river and an additional area around it to represent the physical dimensions for rendering purposes. Based on the suggestion of another user in a thread in the german forum, I propose a new key to fill this gap (which is already used by some users).
Key&Values
Key
Values
Values are the same as for the current highway=* tag, under the lists "roads" or "paths". In addition to that the value "junction" can be used (see below). Other values, like barriers could be evaluated on an individual basis later on, if and how they could be integrated in a 2D style, but those should be handled in separate proposals.
Junctions
- Minor road crossing major road
- The major road is one area. The minor road gets split up into two areas left and right to the major road.
- T-Junctions
- The straight road, or major road stays one area, the minor road gets adjoined with the major or straight road.
- Junctions with multiple street types merging
- For complex junctions, where multiple street types cross and/or merge, the neutral value "junction" can be used.
Additional Keys
Optionally the following tags can be used to further define an area:highway and which could be evaluated when rendering 2D or 3D maps:
- surface=* (if not explicitly tagged, the default value for the tagged highway value can be assumed)
- smoothness=*
- tracktype=* (for tracks)
Tagging this information on the highway or lanes should be enough, since the information can later be applied to the surrounding area:highway element. To override the information on the ways, the tags can still be applied to the area:highway element if desired.
Usage
- Just like waterway=riverbank and mostly landuse=*, area:highway=* would be for visual purposes only. This is also the reason why a separate tag is necessary. Using area=yes paired with existing highway=* tags would lead to unpredictable routing results and is only widely accepted and evaluated for highway=pedestrian.
- area:highway=* is not a kind of landuse=*. The brought up idea of landuse=traffic is not the same. Streets could be part of such a new landuse value (just like rails on landuse:railway=*).
- Another aspect is the still ongoing debate on how detailed landuses should be mapped, due to a imprecise definition of the tag. This proposal doesn't take sides and therefore won't define if area:highway=* should be mapped over landuse areas or if they can be adjoined at shared nodes.
- There is no need to add the information about pavement markings to the areas. This can be determinated later on by evaluating the properties of the highways (or lanes) inside the boundaries of the area.
Advantages
- Tags like width=* mapped on highways are valuable for routing purposes, but wouldn't offer enough information for correct rendering of non uniform streets. area:highway=* would allow a much more accurate mapping of the dimensions of highways.
- Mapping and displaying actual areas of an highway would open up a whole new range of possible usages for OSM based maps. An example would be "You-are-here" maps often found on subway entrances or other public transport stop areas.
- Keeping visual and routing information separate offers the possibility to switch from a highway based routing system to a lane bases routing system later on without having to think about the affects on the visual presentation.
Disadvantages
- Other users raised concerns, that regions tagged with such areas could later be hard to maintain in case the high resolution satellite images aren't available anymore. While this may be true, it isn't a problem specific to area:highway=*. It would rather affect every element that was drawn based on the satellite images, which later can't be corrected efficiently using alternative measure methods like GPS tracks (buildings, parking spaces,…).
Suggestion for renderers
- Displaying area:highway=* would only make sense at very high zoom levels (for mapnik > 19). All other zoom levels should continue to display highway=* ways only.
- If it ever gets rendered by mapnik, in a first phase it could be done "on request", meaning the user couldn't reach the highest zoom level using the slider, but would rather have to manually enter the zoom level in the URL bar. A tile would only be rendered if explicitly requested that way.
- When displaying area:highway=*, the overlying highway (or later lanes) shouldn't be displayed, except for maybe the name which could be displayed as an text overlay (see mockup screen below).
- The areas could be displayed in a gray color. If two areas with different values adjoin, a slightly darker line should be rendered between them.
Mockup screen on how it could be rendered (zoom level 19, zoom level 16, JOSM):
Please note that the graphic is from the thread in the german forums and therefore a bit outdated, since the residential road and the tertiary road should be mapped as separate areas.
Real life examples
-
1583133 (XML, check, manage, JOSM, history, view, gpx ) (Leonding, Austria)
- 54936552 (Eichlinghofen, Germany)
- 112381890 (Huje, Germany)
