Proposal talk:Highway link

no real world feature - non consistent with "link" concept for other highway=*

The tagging you propose is not actually a real world feature. The "link" concept is used in OSM for specific links, clearly constructed and physically distinguishable as links from one highway=* to another highway=*, like in highway=motorway_link. I see no added value here for creating an additional tag, no added value. If it is your intention to try to mimic a picture on a map, use the landcover tags on areas instead. Stick to the existing mapping and tagging practices. Some examples:

1. one highway=residential "ending" or "linked" at another highway=tertiary. We don't add a "link" tag to the residential way section from the highway=tertiary edge to the centre where the way is drawn. "Logically" the residential way connects and ends on the tertiary way. In some cases there could be a stop line, in others not, you add a node with the stop position. The "link" is not a distinctive physical feature, so it is not seperately mapped.
2. There is no marked crossing. But we can map crossing which are unmarked. I would in this case also draw the kerb and add a node kerb=yes where the sidewalk crosses the kerb to indicate the barrier.

Some examples solved without "link": Tororo roundabout, Entebbe-Nkumba road crossing
--Bert Araali (talk) 13:11, 10 March 2021 (UTC)

It is a real life feature since the routing link is real on the ground though the geometry is not.--Florimondable (talk) 20:53, 10 March 2021 (UTC)

Yes. If you'd leave out the bit tagged with link, you'd get broken routing (i.e., the two ways would not be connected). --JeroenHoek (talk) 21:36, 10 March 2021 (UTC)

That is not a good argument to justify this tag. Every highway intersection is and can be mapped like that, regardless of what category it is, they all work fine without tagging a specific "link" bit, and like others have been answering, even waterways follow the same concept, there are millions of those in OSM and they all work fine. Everywhere routing in OSM means connecting the last bit, for routing sakes. The only viable explanation for this tag to be introduced, that I've seen so far, is that it will offer a possibility to distinguish these "last bits" from the actual physical appearance. Which for me sounds good, we introduce a new tag to be able to more accurately represent the physical ground truth, data consumers or renderers alike to do or use it as they like, but it is surely not a routing issue. There is no routing problem at all if you follow the routing principle applied on all highways: you connect the last bit, you extend the way to connect to another way, which by no means needs to be an actual representation of the physical appearance. --Bert Araali (talk) 10:34, 11 March 2021 (UTC)

Mapping for the router

We don't map for the router. Actually I don't see any added value in this tag how this would improve or simplify a router program.--Bert Araali (talk) 13:11, 10 March 2021 (UTC)

Why a new tag for something we already have and is solved simple and broadly used with existing tags?

I believe the parking space example you have given is a good example. I would add these "links" also because they give an added value to wheelchair users that there is sufficient space foreseen to mount a vehicle sideways conveniently. And there are no kerbs (if you add the kerb nodes) that form a difficult barrier. However i would just tag them as any other footway, I don't see any added value in a specific "link" tag, neither for the mapper, the user or a router. All your links are virtual, not real features.--Bert Araali (talk) 13:11, 10 March 2021 (UTC)

@Bert Araali: That's the point. The feature does not exist. It's to distinguish where a real features end, but still retain routability. --Lectrician1 (talk) 15:55, 10 March 2021 (UTC)

While I understand the motivation for this tag, I don't feel it is truly necessary. It's true that we map sections of path/footway/cycleway/bridleway that don't really exist when viewed at a high enough zoom level. We also map sections of waterway=stream that don't exist in order to join them with the linear waterway=river in the middle of a wide river area. While this can feel a little odd it is not wrong. The wider linear highway=* or waterway=* logically represents the full width of the of the feature even if it is not rendered as such. -- Ezekielf (talk) 15:56, 10 March 2021 (UTC)

Exactly my thoughts. This new proposal messes up conventions for how roads and paths should be tagged by thinking that ways are infinitely thin, which isn't the case. This proposal is suggesting that for example: you should split the driveway off at the limit of the road and then make the rest of the driveway as the main road (or link) because the driveway that's within the limit of the road is somehow an "unreal, but traversable connection". --Mxdanger (talk) 04:29, 22 March 2021 (UTC)

Example of how this proposal would current convention:

            . 
            .             <- highway=service
            . 
============.============ <- (lateral limit of carriageway)
            |             <- highway=residential (link?)
------------------------- <- highway=residential

========================= <- (lateral limit of carriageway)

@Ezekielf:, exactly thank you for the comparison and explaining it in a simple way.
@Lectrician1:. I am also getting your point and understand your motivation. What I still don't understand is why we need a new tag for this. What added value does this tag have ? It advises a mapper to add an additional tag, another step in editing. To a router, not clear to me, the routing is established fully with existing tagging. The only reason I could see is that it is not a "real" feature, some kind of logical connection (I don't want to use the word 'link' here). But not different from any crossings we have with other highways. The only example you given where I could see some added value is the parking. But that doesn't seem significant enough for defining a new tag. If you want to mimic the real situation in the field, which in most cases isn't significant for the route-ability, you use other none routing related mapping techniques, like in the parking you draw an area for the parking, you draw the parking isles as an area, you draw the footway as a seperate way... when you see it on a map as a human you can clearly see how it looks like in real life. It doesn't need any new tag to achieve what you had in mind. The page looks nice though and you did a great job in describing a complex feature, lots of work. But sorry, I don't see any advantage in using this, in none of the examples you given.--Bert Araali (talk) 16:30, 10 March 2021 (UTC)

"This mapping primarily benefits routing"

How adding extra tags to already mapped elements helps router? Mateusz Konieczny (talk) 13:26, 10 March 2021 (UTC)

Well, routers might assume elements that use this tag are less-traversable than a standard highway element. I kind of just said that because sometimes people don't map the connections between the minor and major highway elements because no tagging standard exists for it yet. That's why it "benefits" routing. --Lectrician1 (talk) 15:12, 10 March 2021 (UTC)

Standard exists, just continue footway with such virtual segment Mateusz Konieczny (talk) 15:26, 10 March 2021 (UTC)

Using the word link is a bad idea

I support the concept, but think it would be really confusing if you use the word link, since it's already used for highway exits and other connections. Also, I'd put the examples part of the page front and center, since explaining the tag without examples is extremely hard. --LeifRasmussen (talk) 14:39, 10 March 2021 (UTC)

@LeifRasmussen: Well, it's a value, not a key. Most editors make sure that these two things don't get confused. And if you read the rationale section, you'd understand there aren't any other reasonable options I came up with. Do you have any better suggestions? Also, thank you for the the suggestion about moving the sections! --Lectrician1 (talk) 15:22, 10 March 2021 (UTC)

I think it's a good tag-value, and I like how you reuse the previous proposal. --JeroenHoek (talk) 21:37, 10 March 2021 (UTC)

Good idea to use a value. Either link or connection, as earlier discussed in tagging (with a few discussion images)--AllroadsNL (talk) 09:31, 11 March 2021 (UTC)

Using the word link will create confusion: The other proposal was about footway only, this extends to all kinds of highway. I bet this will be seen on "highway=tertiary" where "highway=secondary_link" was intended. Now matter how much you stress, that this property is only applicable to things that are not there, but instead just mapped to make some graph complete. --Hungerburg (talk) 10:09, 22 March 2021 (UTC)

So, it must be connection? (or else) a crossing is from kerb to kerb. I agree a tag must not only fit footway, bus usable on all highways. A tertiary road ongoing(asphalt) with a T junction unclassified (paving stones) and you ask random people: Where does the unclassified road starts? They point out the transition from asphalt to paving stones, meaning all asphalt belong to the tertiary road, that part unclassified is asphalt. A kind of connection line till the middle of the tertiary road. In the area:highway model, this polygon gets surface=asphalt, so they connection line unclassified must also get surface=asphalt. This is what people see and should we tag it that way. footway=connection? unclassified=connection? We have also a tag placement=transition. Are there placement=transition lines on a sidewalk?--AllroadsNL (talk) 10:54, 22 March 2021 (UTC)

Good idea for renderers and routers

I like the fact that:

• Renderers can choose to not render these little connections made for the purpose of routers
• Routers can still follow point-to-point paths without impacting renders.

--ZeLonewolf (talk) 20:29, 10 March 2021 (UTC)

I had also like this idea for cycleways since there is lot of this little connection link between main carriageway and the cycle tracks. This tag can be used for data filtering in order to remove small useless ways in some usecases.--Florimondable (talk) 20:52, 10 March 2021 (UTC)

@ZeLonewolf: That is added value, thank you for making it clear! Although one might consider it as mapping for the renderer, but we also map for the router... I can support it this way !
@Lectrician1: Did you consider to define a single new key with just yes/no (default=no) instead of a new keys with a value for every highway key ? Could make it simpler and more efficient to process the data. Something like routelink = yes/no ? --Bert Araali (talk) 21:42, 10 March 2021 (UTC)

link is already in use, and fits in well as a further specification of the type of footway=*, similar to how other tag-values for the key are used (e.g. crossing, sidewalk). Formalising it seems sensible. --JeroenHoek (talk) 22:09, 10 March 2021 (UTC)

@Bert Araali: See Proposed_features/highway_link#The_value --Lectrician1 (talk) 00:38, 11 March 2021 (UTC)

@Lectrician1: OK ! Perfect just ask me next time if I did read everything carefully :)... sloppy Bert. --Bert Araali (talk) 01:49, 11 March 2021 (UTC)

JOSM Map Paint Style

For footway=link the Sidewalks and footways (with knobs on) Map Paint Style already highlights it with its own pattern. I have been using footway=link for these kind of connecting bits where extending the other way all the way to the crossing of the paths wouldn't be a good fit. To aid mapping I created that Map Paint Style with highlighting for a couple of footway=* values.

Sample

Here it is the small bit of footway that connects the service-way (grey) and the alley comming from the left and going around the parking spaces.

Feel free to reference the Map Paint Style and reuse the screenshot. --JeroenHoek (talk) 21:50, 10 March 2021 (UTC)

Useful for sidewalks

I have been using footway=link for connecting bits of way like this, where an explicitly mapped sidewalk (e.g., at a major intersection where crossings and things like lowered kerbs are tagged) goes from separately mapped (highway=footway with footway=sidewalk) to implicitly tagged on the street with sidewalk=*. Does this fit into your proposed scope? --JeroenHoek (talk) 22:02, 10 March 2021 (UTC)

Yes! Lectrician1 (talk) 23:33, 10 March 2021 (UTC)

Might be a good idea to mention it in the proposal as one of the use-cases. These are about as virtual as you can get: someone walking along that sidewalk would not actually take three steps to the left from sidewalk to street, but continue along the sidewalk. It just isn't mapped explicitly (and this is very common and OK). You can't even tag things like surface=* on it, because it doesn't exist, but it's absolutely necessary to link the separately mapped sidewalk with the sidewalk=* tagged street. --JeroenHoek (talk) 08:38, 11 March 2021 (UTC)

On the sidewalk, you could even use for the perpendicular part highway=footway footway=sidewalk sidewalk=link,to the kerb but also from middle of the sidewalk to a entrance of a building. The render have the choice to render it or not. --AllroadsNL (talk) 09:41, 11 March 2021 (UTC)

On a side note, in that area with the examples you provided, ways such as 904686164 904686164, should not be tagged as a sidewalk and instead joined as part of the crossing way. You need to remember that ways have real world widths, and they aren't as thin as they are in an editor and because of that you should really be connecting the crossing way directly to the sidewalk. The same way it is done with all the other ways used in OSM. Such as such as how a driveway directly connects to a main road. You wouldn't make the rest of the driveway as the main road or "link" would you?

Disagree. Looking in detail, they aren't part of the footway=crossing. But it shouldn't be footway=sidewalk either. Comparing this to roads is inappropriate, when the minor road does connect to the major road at the intersection directly, ---- Kovposch (talk) 07:08, 22 March 2021 (UTC)

The reason I brough up roads, which is appropriate to this topic, is because how they join together is the same way paths should join together with other paths. You also have to think about how data is represented while editing, which this entire proposal seems to revolve around, because when said data is rendered it makes more sense when they're connected at the intersection of the paths directly just as it is in real life. If iD displayed the real-world widths of the paths and roads and how they join (which the link tag would probably break any seamless joining of the ways) then this whole proposal would fully fall apart. --Mxdanger (talk) 19:38, 22 March 2021 (UTC)

You are completely correct! The updated proposal will have to account for roads as well. --Lectrician1 (talk) 19:52, 22 March 2021 (UTC)

Wrong concept on "link" causing inconsistency, use "virtual" or others instead

*=link should be used to connect between same sorts of highway=*, as in highway=*_link for roadways. You may have seen my mention of "carriage walk", "service walk", "cat walk" for narrow kerbside sidewalks and what connects them to the main sidewalk on Discord. Another example, a highway=footway connecting a footway=sidewalk to a bus stop area separated by a verge or planter may also get a footway=link or equivalent, as they are parallel. A quarter-circle arc quadrant connector between grade-separated highway=cycleway can also get cycleway=link. This should refer to the discussion on Talk:Key:informal#Features_that_do_not_exist. ---- Kovposch (talk) 07:41, 22 March 2021 (UTC)

Proposal changes

@AllroadsNL, Hungerburg, Mxdanger, and Kovposch: The reason I brought up the whole virtual vs. informal discussion is because of this proposal in the first place :). This proposal has to not only determine how to map connections between intersections of different types of roads, but also try to cover "imaginary routing cases" (say using virtual=*).

We need a way to indicate the extent of crossing highway features using ways. Areas aren't always going to be present and ways need to show their actual extent and not just be used as arbitrary routing features in my opinion. I'm thinking of using something like intersect=* to indicate lengths of ways where traffic areas of ways of different highways types intersect (also instead of *=link since it is a better term). You can see my discussion about this here. As User:Kovposch pointed out, this is similar to Proposed features/junction=intersection. I haven't had time revise this proposal to account for these thoughts.

This proposal is also going to have to propose for virtual=* or some other tagging scheme. I haven't decided if virtual=* is the right tag to propose or whether it should be something else. I will ask the tagging mailing list for their opinions.

Please be patient as I work through this. I'm glad this proposal will eventually solve many of the somewhat-related problems the tagging of ways for routing and realistic-extent current mapping techniques do not account for. --Lectrician1 (talk) 17:57, 22 March 2021 (UTC)