The problem is in the rendering. I want to see the preference-type ways in a different style or on different maps than the routes. What matters is that the information is in the database to differentiate (the collection of) preference-type ways from the routes. I think lcn=yes (without lcn_ref) on the individual ways does that, so the renderer can make the difference, also the router can use different weights for the both.
Using type=network relations is another method, I agree it is more difficult for mappers as well as data users.
One could try to get some kind of emphasis rendering back for ways with lcn=yes tags. Especially if these ways are signed as preferred ways. A few cities in Nederland have ânetworksâ like this but only in project plans, aimed at construction guidelines, not dependable actual signage. Those ânetworksâ I would exclude from tagging.
We have something similar here. Each of the 101 departments of France is required to manage a registry of ways dedicated to hiking. Some use it for their blazed hiking routes, others just register more or less connected paths. We have sometimes wondered what to do with the latter type, and the idea of creating a dedicated tag on the ways has been aired.
Yes, I was referring to something that the authorities communicate to the traveling public, especially through signs, not something stashed away in planning documents.
It can be difficult to distinguish these situations from each other. Over the years, Iâve encountered many mappers who saw the planning documents and got a little ahead of themselves, mapping the plans as if they were reality, even though they were essentially just funding proposals.
In the project I was thinking about, some project members also got a little ahead of the others, and contracted a route planner company to create a special planner and special maps for publicity and end users. The project members, the company and the mappers together created all this, including the OSM mapping - and then the city decided not to fund the actual signage and road upgrade operation, but keep the route planner as is. If it were up to me I would correct the mapping (in this case, simply make the relation type=network rather than type=route).
One can argue that this network doesnât really exist on the ground; on the other hand, OSM registers many unvisible details as secundary attributes, and one can argue that membership of a (online verifiable) particular virtual network is a secondary attribute of these ways.
Iâve been trying to keep sane about this (bicycle routing around me and on this planet) for about 15 years since I began mapping bike routes in OSM. Hello to many familiar names (Minh, Sarah, Richard, more recently StCâŠ). Thank you for your many and amazing contributions that foster much better bicycle mapping than there used to be 15 years ago (in OSM).
Sticking to bikes, itâs clear (and Minh and I together largely hammered this out in our United States/Bicycle Networks - OpenStreetMap Wiki) that OSM and its renderers (not the be-all of everything, I know, and renderers certainly can and do change the rules for what they render) pay attention to:
infrastructure tagging (like highway=cycleway, cycleway=lane and bicycle=yes)
and route relations and network aggregation tagging, the latter via tagging relations with *cn.
What renderers do with these are partial ingredients of my continuing sanity.
Back on-topic (hiking), the devil seems to be in the details of how *wn is both used now and may be superseded / deprecated in the future. I appreciate that these discussion continue, and while they might seem repetitive and sometimes even circular, I do sense forward momentum; there are a lot of clever, sensible people here.
Iâm watchingâŠIâm listeningâŠIâm tuning out for now. Thanks for reading.