Proposed features/Traverse link
|Status:||Draft (under way)|
|Tagging:||Traverse link=(see description)|
|Definition:||A tag on separately drawn cycletracks to describe linkage to the adjacent carriageway without drawing single connecting ways|
|Rendered as:||not to be rendered|
Recording cycletracks by tags of the roadline limits the possiblity of description. Still, anything exceding cycleway=track is not rendered. Recording cyccletracks by separately drawn waylines allows more description and an exact localization.
But routers have a problem, if the requested route has its start or target next to a road or street with separatly drawn unidirectional cycletracks. The router tends to lead the cyclist on the track in front start adress to the next intersection, and from there to his target. Or it leads the cyclist from his starting point to the last intersection before the target adress. If, in reality, there are several links between the carriageway and that cycletrack and perhaps also to the cycletrack on its opposite side, the router recommends ridiculous detours.
Drawing all connectiony between a carriageway and the adjacent cycletracks is a lot of work, and with large scales, renderers may create unintelligible maps.
Drawing such links selectively, is not really correct.
This problem can be solved, if the renderer is told by a an overall tag traverse_link=* that there are undrawn links. With this information, the router can lead the cyclist from the point next to the start adress on the carriageway or the opposite cycletrack of the same road, to any wayline of the road at the target adress.
As this tag is suggested to make exact mapping (mapping for the renderer in a positive sense) compatible with routing, it is tagging for the renderer in a positive sense. Therefore it should not be rendered.
In many roads, most links between cycletrack and carriageway are crossings of particular entries/exits of at the same time. If cycletracks are lead in sidewalk level, such accessways may cause uncomfortable depths and waves of the cycletrack. If the cycletrack has been built after the houses, the layot of these connections often is almost unique. This could be regarded by adding a second value for this layout. On the other hand, the rendering problems with combined tags suggest to describe the layout by a separate tag on particular crossings
As in a road with cycletracks on both sides, one of those can have many links, the other one none, this information has to be tagged on the cycletracks. In roads with dual carriageway, the tag only describes the links to the adjacent one. For roads with several interconnections between two carriageways, a similar way of tagging the roadlines ought to be found.
The first value of that tag has to describe the density of links:
- traverse_link=continuous, for instance, if the cycletrack is divided from the carriageway by a file of bollards rather than a kerb.
- traverse_link=many, if the distance between neighbouring connections is 50 meters or less.
- traverse_link=some, if this distance is 50 to 100 meters.
- traverse_link=rare, if this distance is 100 meters or more.
- traverse_link=single, if the mapper prefers to draw every single link.
- traverse_link=yes, if the mapper doesn't like to record the density.
- traverse_link=no, if the cycletrack is isolated from the carriageway.
As written above, the rationale of this tag is to give informations for routing without overloading rendered maps.
In roads and streets with separate waylines for the carriageway and one or two cycletracks, the tag shall cause routers not to start or stop schematically on the wayline next to the routed addresses, but as well on other waylines of the same roads or streets.
In the same way as on roadside cycletracks, the tag may also be used on separately drawn sidewalks.