Proposal:Relation:bikeped link

Relation:bikeped link
Proposal status:	Draft (under way)
Proposed by:	JPinAR
Draft started:	2025-02-27

Proposal

Address the routing navigation 'gap' for transations between dedicated 'Cycling, Pedestrian, and Disability' infrastructure like Multi-use paths when the 'terminate at or merge with' or 'start along or separate from' road infrastructure such as 'bike lane' or 'on grade but separated' infrastructure for all 'Cycling, Pedestrian, and Disability' users.

This in intended as part of this proposal to be implemented as part of a Relation with the intended type to be type=bikeped_link

Rationale

The best explaination for the need to to list the 'gap' present in Cycling, Pedestrian, and Disability mapping today. When these forms of infrastructure switch between dedicated and independent to merge and become part of road infrastructure some weird things occur. However, this proposal is not intended to solve the first half of this. For this we look to a 'de facto' tag use of cycleway=link or footway=link these serve to fill the gap between the physical center-line of each infrastructure and the necessity to route between them in the form of ways.

This Relationship would suppliment the above tagging and extend it to cover the second half of the routing issue that the 'link' ways don't address namely not the 'where' of the transition but the 'how'.

If you look at a lot of these transitions they could be very simple. For instance a bi-directional 'bike lane' and multi-use separated path transition via a ramp. This is a simple and intuative transition within the physical enviroment OSM seeks to emulate.

The issue is that a simple transition like the one above and a complex one like the one I'm about to explain are virtually indestinguishable using merely ways. A lot of these 'links' merge into roads at 90° angles and into intersections at 45° angles. Even when viewed in OSM it's not clear even what direction if any the dedicated infrastructure becomes or how one would navigate to it from any connecting road.

To give the complex example is actually quite simple. A East-West running bike lane comes to an intersection from the south-west side of an interestion. Then starting on the east side of the road the bike-ped infrastructure becomes a bike-ped lane on each side of the road. Assuming for this example this is a 'right side of the road' direction nation then depending on the direction and layout of the intersection a few options arise.

For the west-to-east bound bike-ped traffic it's likely they will cross with the traffic flow to the other side of the intersetion on continue one just in a one-way lane. However, east-to-west traffic could have a few options:

• They might need to join and cross the E-W crosswalk and then the N-S crosswalk.
• If a 2-lane road a "bike box" (cycleway=asl, advance stop line) allowing cyclist to joing the traffic lane and make the transition as a left-turn
• The intersection could depending on the laws of the location and traffic volume have a one directional diagional crossing lane.

The point of this 'Rationale' statement is not to selection one of these. The entire point is that presently OSM has no way to handle any of these transition types from a navigational perspective. From the perspective either 'physically rendered' or 'logically routed'.

The thought here is to do in a manner of speaking an 'inverse restriction' keeping the 'to/from/via' model but instead of saying where you can't go instead give guidance on how to navigate the transition between two cycle/ped/disability infrastructures.

Tagging

Key	Value	Explanation
type	bikeped_link	Relationship between two linking cycle, pedestian, and/or disability infrastructures.
transition	See steps options.	An ordered list of steps to perform a bike-ped transition. If not specified but a subkey/nomespace this is presumed to apply to all members of active transportation.
transition:foot, transition:bicycle, transition:wheelchair	See step options.	Transition refers only to the given mode of active transportation.
implicit	yes / no	Transition that are implied by local laws, safe driving norms, or the real-world physical layout of roads, but are not accompanied by explicit signs (posts or road paint).

Steps

Step Type	Link or List	Explanation
Turn	Use Turn Values	Make a turning action.
Merge	merge_bikelane / merge_sidewalk / merge_footway / merge_cycleway / merge_multiuse / merge_asl / merge_shared_lane / merge_through_lane / merge_rightturn_lane / merge_leftturn_lane	Merge with differing infrastructure that what you started on. This could be the end state, but also steps along a transition.
Crossing	cross_sidewalk / cross_bikelane / cross_traffic / cross_slip_lane	Road crossings typically for transitions at intersection. Potentially at mid-block crossings if this corresponds with beginning or end of bike-ped infrastructure.

Members

Way or node	Role	Cardinality	Notes
	from	1 1 or more	A way from which a bike-pedestrian-disability transition either starts between a road or dedicated infrastructure. This is the way a user will begin a transition from.
	to	1 1 or more	The ending way between a road or dedicated infrastructure. This is the way that a user should arive upon post transition.
	via	1 node 1 or more way(s)	Member(s) connecting the beginning and end ways representing the point of transition. If a way this should commonly be a cycleway=link or footway=link. As shown below, a turn restriction can either have a single connecting node or one or more connecting ways with a via role. If the via members do not connect the from- and to- members, the relation is invalid.

Roles

If more than one transition is acceptable. If there is more than one equally important main route, do not use roles on the ways but create separate route relations.

Ways and Relations

Role value	Explanation
None or main	The role value for the main section(s) of a signposted or in any way waymarked route.
alternative	A signposted or otherwise waymarked alternative branching off then rejoining the main route at a significantly different point. The alternative is used instead of a section of the main route.

Examples

Caption text

Example	Transition
	transition=slight_left;merge_multiuse 'Alternate' Role transition=through;merge_shared_lane
Example	Example
Example	Example
Example	Example

Comments

Please comment on the discussion page.