Proposal:Highway link
| highway link | |
|---|---|
| Proposal status: | Proposed (under way) |
| Proposed by: | Lectrician1 |
| Tagging: | *=link
|
| Applies to: |  ways
|
| Definition: | Map connections between highway elements |
| Statistics: |
|
| Rendered as: | An almost-transparent version of the highway element it's key is |
| Draft started: | 2021-03-07 |
| RFC start: | 2021-03-09 |
This proposal will have some upcoming changes that will help address contradicting use cases that this proposal uses as examples as well as clear up any other issues that have been cited on the talk page.
The discussion about these changes can be found here in the OpenStreetMap World Discord server.
Proposal
This was inspired from the original proposal for footway=link
Currently there exists no way to map an unreal, but traversable connection between a highway element that ends and another highway element.
This proposal proposes the the *=link value scheme that are placed on highway=* tagged Ways to connect a minor highway element with a major one.
It proposes these tags as a result of this new scheme:
Because this is a new tagging scheme, future highway elements may use the *=link value for tags where necessary.
New proposal examples
Examples
Most of the examples use footway=link tag, but the usage can apply to any other *=link tag as well.
Where to use
Ways
.
. <- highway=footway
.
============.============ <- (lateral limit of carriageway)
| <- highway=footway + footway=link
------------------------- <- highway=* (e.g. highway=residential)
========================= <- (lateral limit of carriageway)
Real-world example:
footway=sidewalk ways connected to a highway=residential way using footway=link ways on the left and right.Notice:
- There is no lower outlet for the
footway=sidewalkon the left, so afootway=linkis used instead of ahighway=crossing. - A
footway=crossingway is placed appropriately with ahighway=crossingnode at the top because there is an outlet for thefootway=sidewalkon each side of the street. - The
service=drivewayandfootway=linkconnection on the right is not afootway=crossingbecausehighway=serviceis not the same type ashighway=footwayso there is no direct outlet of the same type for the footway. The presence of the driveway continuing to the street also of greater importance than a crossing in this situation. In-all, the connection can still serve as a crossing for pedestrians sinceservice=drivewaycan be accounted for as a walkable element.
Tactile-pavement/sloped curb
Where there is tactile pavement and/org a sloped curb and no outlet (similar to the Ways example), a footway=link way can be added.
This can be commonplace in parking lots.
footway=link way drawn between a footway=sidewalk and service=parking_aisle where there is tactile pavement.Access aisles
The physically-marked areas of footway=access_aisle typically do not extend all the way out to the service=parking_aisle way.
Therefore, a footway=link way can be mapped between the two to accurately connect them.
footway=link ways are used to connect the end of a footway=access_aisle and a service=parking_aisle way.Steps
---
--- <- highway=steps
---
===========---=========== <- (lateral limit of carriageway)
| <- highway=footway + footway=link
------------------------- <- highway=* (e.g. highway=residential)
========================= <- (lateral limit of carriageway)
Real-world example:
Ending sidewalk
========================= <- (lateral limit of carriageway)
------------------------- <- highway=* (e.g. highway=residential)
| <- highway=footway + footway=link
==============|========== <- (lateral limit of carriageway)
............... <- highway=footway + footway=sidewalk
Real-world example:
footway=sidewalk way connected to a highway=secondary way using a footway=link way.Where not to use
Incorrect and overusage
Although there is no connection between the sidewalks and street, footway=link is incorrectly and overused here.
Pedestrians will not and should not use the routes created here. They should instead be directed along the appropriate usage path type and cross at crossings and appropriately-placed footway=link ways.
Other nearby routable features
When other routable features of similar usage are nearby, footway=link is not needed. This also applies to a possible connection at the green circle in the Broken sidewalk example.
| What not to do | What to do |
|---|---|
 footway=link randomly |
 service=driveway is used instead and mapped accurately. They can function as a routable connection between the footway=sidewalk and highway=residential. |
Tagging
Meaning
Implies:
General usage
The tag should be placed on a connecting way between a minor-highway way of the same tag and a major-highway way where there is no outlet.
Exact usage
How and where the way is mapped is ultimately up to the mapper.
They can do whatever they think will yield the most-effective possible routes, however the usage of this on ways for over-routing is highly discouraged.
Exceptions
If there is a way of the same minor-highway tag across the major-highway, then a *=crossing way and node should be used instead.
noexit=yes should never be used on the ends of the connecting because Key:noexit#When not to use states, "This tag should not be used when the way is only a dead-end for one transport mode, but where other modes can continue." Other modes can continue when this tag is used on a way.
Rationale
Physical vs. pseudo indication
Ways that are tagged with the current highway tags indicate that there is real form of that indicated element present there. When a sidewalk ends and outputs to a street accessible and has no outlet on the other side (not a crossing), it would not make sense continue or place another sidewalk way between the end of the physical sidewalk and the street way. No sidewalk actually exists there.
Therefore, a tagged way is needed to indicate that the sidewalk is not physically there, but is possible to be traversed using the purpose of the original way (walking in the case of a sidewalk).
The value
- I decided to go with a the value of
linkbecauseconnectionwas too long andfake,pseudo,unreal, andimaginarywere too weird and not descriptive enough. The original proposal also used this as well. - The values of
highway=*elements usually indicate the physical type or usage of a element of that type. For example,footway=sidewalkis a physical type andfootway=crossingis a usage type.*=linkfollows this trend well because it acts as a pseudo-physical type but also indicates usage. - I decided to not create a new key like
link=yesbecause people might get it confused with a website link. This indicator is also only specific to highway elements, so it makes sense to keep it as a value limited to that namespace instead of making a new tag that could be used on any element. I also dislike usingyesas a value in-general.
Tagging implications
- Routers that currently do not know about the existence of this tag do not need to worry because the way that has this tag also has the
highway=*tag that indicates the same access and intended purpose. - Renderers might decide to hide highway elements with this value so that the realistic starting and ending points of a highway feature can remain consistent on the rendered map.
Current usage
Rendering
osm-carto: An almost-transparent version of the highway element it's key is.
Consumer-oriented maps: Do not render.
Editors (iD, JOSM): They should be a different style to distinguish them.
Features/Pages affected
- Key:footway
- Key:cycleway
- Tag:highway=bridleway/Key:bridleway
- Tag:highway=path/Key:path
- Tag:footway=access_aisle
- Tag:footway=sidewalk
External discussions
Comments
Please comment on the discussion page.