|Status:||Draft (under way)|
This proposal wants to install a tagging-scheme for implicit traffic-laws (not set explcit by signs). This information is needed, because boundary relations are related to building regulation and not to traffic.
Currently there is no way to find out which ways are in and which are out of town. Because of complex road structures it is impossible to draw a boundary=traffic polygon; i.e., an "out of town" road is in a tunnel under a town.
It should be noticed that there must be a one to one correspondence between the tagged zone names and the zones defined in the official legal documents such as the UK highway code or le code de la route belge
Usage of zone:traffic:
- 1 Tagging
- 2 Implied Keys and Values
- 3 Zones which does not need tagging
- 4 Frequently asked questions (FAQ)
- 4.1 Why don't you use relations for this?
- 4.2 Why don't you use polygons for this?
- 4.3 Why don't you add nodes to ways to mark changes of traffic zone?
- 4.4 Why don't you explicitly add tags such as maxspeed=50?
- 4.5 Why don't you derive defaults from a combination of country borders, city boundaries, lane counts etc.?
- 5 See also
- 6 Rendering
- 7 Discussion
zone:traffic=* is the only tag proposed here.
It should be used on all public roads (ways and areas).
Values have the format "<ISO 3166-1 alpha-2 code>:<rural|urban|...>"
Values can be set as default. Default is a proposal for a default values system. This proposal can set default values such as maxspeed for areas (countries, states...)
Implied Keys and Values
|DE:motorway||Not needed, see below!|
Zones which does not need tagging
The following table lists examples where the tag zone:traffic=* can be omitted because it is already implied by other tags.
|Value||Implied by / Alternate Key||Description|
|DE:motorway / DE:motorwaylike||highway=motorway or highway=trunk + zone:traffic=DE:rural + oneway=yes + lanes=2+||motorways and motorway-like roads - In Germany this are special zones which imply maxspeed=none|
|DE:bicycle||bicycle_road=yes||bicycle road (always a zone in DE) - Rarely used: cyclestreet=yes|
|DE:enviromental:2||zone:traffic_emission=DE:2||enviromental protection zone - Alternate key because this is a access-restriction. See wikipedia:de:Umweltplakette!|
|DE:speed:30|| zone:maxspeed=DE:30 or
source:maxspeed=DE:zone + maxspeed=30 or
|speed XX zone - in DE this implies: zone:traffic=DE:urban, turning restrictions, traffic-signals, right of way and street layout.|
|DE:no_waiting||zone:parking=DE:no_waiting||no waiting zone|
Frequently asked questions (FAQ)
After hundreds of mails on various mailing lists discussing this topic, it seems sensible to provide a list of frequently asked questions (and frequently proposed alternatives) for this proposal. This is supposed to be a summary of arguments for this proposal, not yet another place for discussion. Use the talk page or mailing lists for that.
Why don't you use relations for this?
Why don't you use polygons for this?
- Polygons are two-dimensional. There are situations where bridges or similar three-dimensional structures cause "zones" to vertically overlap, which cannot be represented by polygons.
- Downloading only a part of the map (e.g. a part of a city) can result in polygons missing from the download, despite ways from inside the polygon being part of the downloaded data.
- A mapper will often know that a certain way is part of a zone without knowing where the zone boundaries are.
- Tags on ways are easier to evaluate for applications. Polygons require more advanced programming techniques to reduce performance problems from inclusion tests.
- it's very incorrect, because only the roads themselves are part of any kind of traffic-zone and not the whole area; e.g. roads in parcs or on private property or even tracks.
Why don't you add nodes to ways to mark changes of traffic zone?
- It's error prone: A single missing node will potentially cause the zone to "leak" all over the map, because you enter the zone, but never reach an exit. Every safeguard against this can only be an estimate.
- Arguments against polygons (except 3D problem) apply.
- It is always a good idea to tag traffic_sign=* anyways!
- A traffic zone often bundles a lot of restrictions: not only maxspeeds for various vehicle types, but additional regulations depending on local law. Mapping reality proves that mappers don't add all those tags, they might not even know about all those restrictions. But they are able to identify traffic zones.
- Using zone:traffic allows to distinguish between explicitly signed restrictions and those that are defaults for the zone. This has several advantages:
- It becomes trivial to deal with some changes in traffic laws.
- A mapper re-checking an area knows whether to look for explicit signage.
Why don't you derive defaults from a combination of country borders, city boundaries, lane counts etc.?
- a lot of that information is polygon-based, so the problems mentioned for polygons apply
- in at least some countries, administrative boundaries of cities aren't the same as urban traffic zone boundaries, neither are landuse boundaries; therefore, the existing information often isn't the one relevant for zones
Discuss on the talk page, please.