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

[stevea]

On Nov 30, 2021, at 10:51 AM, Minh Nguyen <minh at nguyen.cincinnati.oh.us> wrote:
> Vào lúc 02:58 2021-11-30, Brian M. Sperlongano đã viết:
>> In the US, I even struggle to come up with a clear definition of what counts as a "route" for cycling.  Certainly our signed and numbered "US Bicycle Routes" are routes, but there are many, many dedicated off-road bicycle paths that extend for considerable distances while carrying a common name (and would be mapped as multiple ways based on length and changes in attributes).
> 
> If we were to strictly apply the standards we use for roads, then we'd nix the route relations for dedicated bikeways that aren't part of designated routes. On the other hand, that's distinctly unhelpful for mapmaking, since from a user perspective, the dedicated bikeways are often more usable routes (in the ad-hoc sense) than the designated routes.

Yes, but I'd argue that "nixing" would be too strict.  DESIGNATED routes, absolutely go in OSM.  There certainly are more (in the USA) that are "less formal."  I don't think we want to remove those, but I recently removed a really messy allegedly-mtb route (which was obviously copied from a copyrighted web site) that went from the San Diego International Airport down through Tecate (taking mostly paved roads there) and then got "sort of on dirt trails" as it went into Mexico.  I deleted it, noting so in the USA's International section of Bicycle Networks wiki, the author did not complain.  (I did try to contact him first; no reply).

> 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).

> Rail mappers take a middle ground by distinguishing between route=railway for the railway infrastructure versus route=train for the services that use it. For example, in the San Francisco area, Caltrain's route relations [4] overlap with a route relation for its dedicated trackage. [5] An analogous solution for bikeways would be a route=cycleway relation for a dedicated bikeway that's known by a particular name. It might be a better way to model bike boulevards too.

I know bike routes well, I know rail routes well (having spoken at national OSM conferences on both).  Please recall the method by which we "simplified" rail mapping in the USA:  we looked at (mostly Germany's) propensity of using THREE relations (route=tracks, route=railway, route=train, the latter for passenger services, the middle for what we call "USA's railroad company's 'subdivisions' or named groupings of rail segments).  Because the "bottom level" of route=tracks really made no sense to me or anybody else in the USA (I'm sure it made / makes sense to Germans), it was only after I suggested we conflate the route=tracks and route=railway relations together into a "single sense" route=railway relation ("what our rail companies and we know as subdivisions") that rail mapping really started to take off in the USA (circa 2014-5 or so).  We've never "looked back" at whether "conflating 3 into 2" was a mistake or OK to have totally ignored what Germany was doing, and to this day it doesn't seem to have negatively affected any use cases that I know of, rail renderers, rail routers, or the ability for anybody to not very positively use OSM's rail data in USA.

Perhaps bicycle routes and networks Germany is similarly (and again) an outlier and so strongly seems to want to insist "the methods by which it signs and maps" must be different from the rest of the world in OSM.  However, what we did in the USA by "conflating 3 in to 2" is going in the opposite direction:  we simplified, and mapping rocketed upwards in popularity.  Germany is creating more diversity (in our tagging, again), hence confusion and even argument (I hope it doesn't feel it's going as far as rancor, let's not do that).  If extra-special tagging really is necessary to describe richness, I keep thinking and hoping and striving for it to be done with methods and tagging that are understandable (relatively simple), fit reasonably into the tagging schemes (which are small, finite and understandable) we already do and which has worked for well over a decade and harmonious (agreeable to most or all, eventually achieving wide consensus).  However, it does seem we remain quite a distance away from that (here).

This is a really, really long thread.  I look forward to resolution.