[Tagging] Cycling infrastructure routes (was Re: cyclist profiles - was:Feature Proposal - RFC - value 'basic_network' - cycle_network?)

[stevea]

On Dec 1, 2021, at 5:40 PM, Minh Nguyen <minh at nguyen.cincinnati.oh.us> wrote:
>>> The current approach of representing them all as route=bicycle relations gets messy as dedicated infrastructure gradually becomes part of designated routes. For example, the Little Miami Scenic Trail in Ohio [1] has a well-known identity, so we made it into a coherent network=lcn relation. [2] We need a route representation because it unfortunately still has a couple of on-road gaps, as well as a short segment with a different local name. [3] People still follow the named bikeway instead of the concurrent U.S. Bike Route or state routes that are more fragmented. This relation is distinguished from those routes by the lack of cycle_network=*. None of the network=*cn tags fit well, but there's a pro-forma network=lcn on it. Maybe in time it would become informal=yes and eventually be deleted.
>> I underscore once again the importance of infrastructure tagging.  It is de minimus (the bare minimum required), and an OSM bike route that doesn't have bicycle infrastructure tags on its members is "posing," and must be fixed so it does.  Even then, the route SHOULD be signed, but might not be, in the USA we are a bit lax about this.  But not the converse:  if it is a signed bike route (whether national, regional/state or local), OSM has every reason to map it as a route=bicycle (or even a route=mtb, we have signed mountain bike routes pretty close to me, I've hiked them).
> In this spun-off thread, I was floating the idea of distinguishing a new kind of relation for cycleway/bikeway infrastructure, in addition to the infrastructure tags we'd of course keep on ways. The named trail I gave as an example is signposted -- but not as a route per se, rather, in the manner that a street is signposted. Yet people routinely follow the trail as if it were a route, overcoming any discontinuities in the physical trail. I recognize this is orthogonal to mapping the kind of network that started the original thread. It just seems that overloading route=bicycle for this purpose is inconsistent with both road and rail mapping.

Thank you, Minh, for spinning off this additional thread (I think I mistakenly said THIS thread is long, rather than its parent thread).

Keep bicycle infrastructure tags on ways, of course.

"New kind of relation for (bicycles)?" well, I'm listening.

There really are two distinct, mathematically unique "sets of things" that are different from one another:  a "road way" which is a real thing with a name, and signposts along it which denote that.  OSM models the former as a way with a name=* tag and might model (does so in the case of certain bicycle and hiking routes/networks) these as a or some "signposted node route(s)/network(s)" (and there seems to be a method of doing that everybody agrees upon, now denoted with network_type:node_network, perhaps others).

If there is a Main Street with 1st Avenue, 2nd Avenue, et cetera as perpendiculars to it, let's say the city didn't get around to signposting "Main Street" at 6th Avenue and 7th Avenue, but did again at 8th and 9th Avenues.  Main Street didn't cease to be Main Street around 6th and 7th.  Yet, OSM can properly model both of these distinct "sets of things" in the real world:  as a way with a name=* tag, and as a relation of nodes representing signposts, where importantly, there is a "skip in the data" because "there is a skip in reality."  There can be both, OSM can model both.  Yes, the latter are rare, the former are much more common, but so what?

Maybe a node can contain key-value pairs that represent named and/or numbered routes/networks (I'm being slightly and deliberately vague here).  We seem to do something like that, there's room to "grow into" other ways to do that.  I simply ask for that to be clearly described.  While I listen.