Proposed features/highway link
|Proposal status:||Proposed (under way)|
|Definition:||Map connections between highway elements|
|Rendered as:||An almost-transparent version of the highway element it's key is|
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.
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.
It proposes these tags as a result of this new scheme:
New proposal examples
Where to use
. . <- highway=footway . ============.============ <- (lateral limit of carriageway) | <- highway=footway + footway=link ------------------------- <- highway=* (e.g. highway=residential) ========================= <- (lateral limit of carriageway)
- There is no lower outlet for the footway=sidewalk on the left, so a footway=link is used instead of a highway=crossing.
- A footway=crossing way is placed appropriately with a highway=crossing node at the top because there is an outlet for the footway=sidewalk on each side of the street.
- The service=driveway and footway=link connection on the right is not a footway=crossing because highway=service is not the same type as highway=footway so 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 since service=driveway can be accounted for as a walkable element.
This can be commonplace in parking lots.
--- --- <- highway=steps --- ===========---=========== <- (lateral limit of carriageway) | <- highway=footway + footway=link ------------------------- <- highway=* (e.g. highway=residential) ========================= <- (lateral limit of carriageway)
========================= <- (lateral limit of carriageway) ------------------------- <- highway=* (e.g. highway=residential) | <- highway=footway + footway=link ==============|========== <- (lateral limit of carriageway) ............... <- highway=footway + footway=sidewalk
Where not to use
Incorrect and overusage
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
|What not to do||What to do|
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.
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.
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.
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).
- I decided to go with a the value of
connectionwas too long and
imaginarywere 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=sidewalk is a physical type and footway=crossing is a usage type. *=link follows 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=yes because 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 using
yesas a value in-general.
- 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.
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.
Please comment on the discussion page.