[Tagging] Clarification on the role link in route relations

[Dave F]

I'm still struggling to see what this has to do with route relations.

Maybe you're confused between 'routing software' & 'route relations'.
They are independent of each other. Routing software can, of course, use 
route relations, but they are not reliant on each other.

The tags you describe are all on ways, not route relations. It seems 
they're best described as 'niceties', but not essential to routing 
software. A router can still find its destination without them, the 
instructions would just be 'take the next exit' instead of take the exit 
to Memphis'.


I'm intrigued by your Point 3.
Please provide a link to it in OSM & details of your rendering (Github, 
website?).

DaveF

On 12/01/2022 11:16, Minh Nguyen wrote:
> Vào lúc 08:38 2022-01-11, Dave F via Tagging đã viết:
>>
>>
>> On 08/01/2022 23:02, Minh Nguyen wrote:
>>> Can you provide an example of what this looks like? How does it 
>>> differ from what destination:ref or destination:ref:to would be 
>>> tagged on? (destination:ref:to is for where a trailblazer sign says 
>>> "To ABC 123" with an arrow, as opposed to just "ABC 123" with an 
>>> arrow.)
>>>
>>> The current documentation for "link" explicitly states that it's for 
>>> link road connections between different road routes, making no 
>>> mention of recreational routes. I think it's unlikely that U.S. 
>>> mappers, at least, would support comprehensively using the "link" 
>>> role for anything that so much as mentions a road route, considering 
>>> that there are more maintainable representations of that 
>>> information. There are countless "To ABC 123" signs that are many 
>>> miles away from the route itself, with nothing in between mentioning 
>>> the route. Here are some examples tagged with destination:ref:to:
>>>
>>> https://www.openstreetmap.org/way/19051231
>>> https://www.openstreetmap.org/way/48889597
>>> https://www.openstreetmap.org/way/60108744
>>
>>
>> These are tags on ways, not route relations.
>> Again, I think you are misunderstanding the purpose of route 
>> relations, which are journeys, taken over multiple different types of 
>> highway.
>>
>> Your examples above appear irrelevant to route relations.
>> https://www.openstreetmap.org/way/19051231
>>
>> destination:ref: The 'I 275 North' is the *only* road that highway 
>> goes to. Competent routing software doesn't need to be informed of that.
>>
>> destination:ref:to: The 'I 75' is miles away. If these refer to road 
>> signs, then it has nothing to do with route relations. There are many 
>> turn-offs. A driver's destination could literally be anywhere.
>
> It isn't just my personal preference. You're unintentionally 
> suggesting that everyone has mistagged most destinations throughout 
> the entire U.S. for over a decade, and that most OSM-based navigation 
> software (including what I work on at Mapbox) are in error for 
> handling these destinations without issue.
>
> The U.S. designates and signposts road and cycling routes entirely 
> differently than you're used to in the UK. In the U.S., highway 
> departments primarily number routes, although many routes are 
> coincident to a single road, especially on short freeways and on 
> county and township roads. By contrast, road inventory numbers are 
> very obscure, reserved for internal bookkeeping and emergency response.
>
> Maybe it'll help if I explain how to read the MUTCD guide signs that 
> are tagged as destination:ref and destination:ref:to in these 
> examples. For reference, here are street-level photos of the guide signs:
>
> <https://www.bing.com/maps?osid=eb31e35e-9573-42e9-a71d-a47a296549f2&cp=39.211236~-84.676298&lvl=19&dir=354.557&pi=0&style=x&mo=z.0&v=2&sV=2&form=S00027> 
>
> <https://www.mapillary.com/app/?pKey=527983128577877>
> <https://www.mapillary.com/app/?pKey=2886949251528646>
>
> A shield that appears on a guide sign indicates a route carried by the 
> adjoining roadway (destination:ref=*). A roadway may carry multiple 
> concurrent routes, resulting in multiple shields side by side. 
> Sometimes the highway department posts "To" routes 
> (destination:ref:to=*) because most traffic is predicted to follow a 
> particular succession of routes to reach the control city on the sign 
> (primary destination in UK lingo).
>
> The first photo above shows a fork in the road where a pair of ramps 
> leads to opposite carriageways of an unnamed ring road, which is 
> coincident to Interstate Route 275 (I-275). From this point, the 
> counterclockwise carriageway is designated as simultaneously carrying 
> the westbound lanes of I-75 and U.S. Route 52 and the southbound lanes 
> of I-275. The clockwise carriageway carries the northbound lanes of 
> I-275. [1]
>
> A motorist who keeps left would end up on I-75 West/US 52 West/I-275 
> South en route to Indianapolis. A motorist who keeps right onto I-275 
> North is likely to be headed toward Dayton. To get there, they would 
> need to follow I-75 North after several miles on I-275. The next time 
> they'll see an I-75 shield is miles away at the exit for I-75. 
> However, no one is forcing them to travel to Dayton; they could 
> instead go in circles on a joyride around one of the largest ring 
> roads in the country. [2]
>
> Route relations carry essential, structured information about the 
> route that cannot be reliably derived from parsing ref=* on the way. 
> The U.S. has an incredibly complex system of route networks with often 
> conflicting alphabetic prefixes and route shields with distinctive 
> shapes and colors, which we distinguish using the network=* key. Route 
> relations are important enough to Americans that members of the U.S. 
> community are developing a new renderer that uses route relations to 
> showcase correct-looking route shields, similar to OsmAnd's behavior 
> but more thorough. During testing, we found visual anomalies that were 
> caused by "link" members, hence my original question. [3]
>
> In OSMUS Slack, someone pointed out that routers would find it useful 
> to access the same structured tags that are found on route relations 
> when processing destinations on link ways, versus trying to parse the 
> pretty-printed destination:ref=* tag. [4] That would enable navigation 
> software to consistently use the correct route shield whether the 
> route is mentioned in a maneuver instruction or on the map. But rather 
> than overload a route geometry with tangentially related members, I 
> think it would be more sensible to put the link way and route relation 
> into a superrelation akin to a destinationsign relation (not to be 
> confused with a destination_sign relation). [5] Aside from the 
> incredibly unfortunate name, this approach is incapable of indicating 
> the signposted order of destination cities and destination routes, so 
> destination:ref=* is still essential.
>
> I think this thread has already clarified that UK National Cycle 
> Routes are signposted in a way that's apparently more conducive to 
> some sort of relation role and less conducive to destination tagging, 
> which I'm not in a position to dispute. But hopefully my explanation 
> shows why the wiki's motorway-specific definition of the "link" role 
> sounded particularly baffling to an American like me. At this point, 
> it seems like there's a consensus to describe the "link" role as being 
> specific to piste routes (approved) and maybe cycling routes in some 
> regions (in use), but not for more general use on route relations.
>
> [1] For more about cardinal directions as part of signposted routes: 
> https://wiki.openstreetmap.org/wiki/Route_directions
> [2] The ring road's inventory number is technically HAM-IR-275, but 
> that unsignposted information is too obscure to map.
> [3] https://github.com/ZeLonewolf/openstreetmap-americana/issues/79
> [4] 
> <https://osmus.slack.com/archives/C01TUSZ1Q7J/p1641696330041000?thread_ts=1641614118.015900&cid=C01TUSZ1Q7J>
> [5] https://wiki.openstreetmap.org/wiki/Relation:destinationsign
>