Proposed features/Traverse link

From OpenStreetMap Wiki
Jump to: navigation, search
Traverse_link
Status: Draft (under way)
Proposed by: ulamm
Tagging: Traverse link=(see description)
Applies to: linear
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

Rationale

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

Description

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:

Tagging

highway=cycleway           (or highway=path + bicycle=yes)
+ cycleway=obligatory/vs/optional
+ oneway=yes/vs/no
+ surface=*
+ traverse link=*
+ particcross=*

Rendering

As written above, the rationale of this tag is to give informations for routing without overloading rendered maps.

Routing

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.

Wider usage

In the same way as on roadside cycletracks, the tag may also be used on separately drawn sidewalks.

Comments