[Tagging] Feature Proposal - RFC - value 'basic_network' - cycle_network?

[stevea]

On Nov 22, 2021, at 11:31 AM, Mark Wagner via Tagging <tagging at openstreetmap.org> wrote:
> I'm guessing that the "basic_network" being discussed here is that
> formed by the orange arrows.  If so, I don't think it should be mapped
> using route relations.  Since the routes don't have any sort of unique
> identifier, there's no way to say where one ends and another begins.
> Instead, it should be mapped as an attribute of the ways making up the
> network, similar to how things like "truck route" are mapped in the US.

Underscoring that there is no need for the 'basic_network' proposal as stated.  Repeating:  what "is" (in the real world and represented on these signs) can be mapped using existing OSM data structures and bicycle-route/network-oriented tags.

If an entire country's 'basic_network' is far too large to be put into one relation (and at what I understand would be or is >4000 relation elements, it sounds like it already is), then do what we do in USA:  we break apart huge, long routes that are or tend towards "national scope, therefore quite huge" into one-state-at-a-time relations and combine these relations together into a super-relation.  It's sensible, we have documented the conventions for how we tag these (with description=* and/or name=* tags), we accommodate unidirectionally- and bidirectionally-entered routes, et cetera.  Yes, it took a while to "craft" these and how we enter them, including trying out a few things that were later discarded as mistakes / poor choices (not TOO many), we asked for agreement along the way to achieve consensus (and eventually did) and we documented in our wiki both that we were doing this and how we were doing this.

Coining a new tagging scheme (as the proposal does) that newly and differently denotes what OSM already denotes is NOT the best way forward.  Rolling up your sleeves and doing the admittedly hard work of "putting the whole mess into a big bucket and sorting them (routes, networks...) out into smaller buckets" which are smartly named, geographically organized, hierarchically organized, assigned wise and future-proofed cycle_network=* values, while documenting the conventions on how Europe is doing this — that WILL work.  I'm certain about this, because we did so a decade ago, and it's working fine.  Join us!

Again, a good starting point is clearly articulating exactly what "this sort of route" and "that sort of route" actually are, perhaps as defined by the government or organization that asserts them.  You can't wave your hands and say 'basic_network' without formally defining it and say "we're denoting that thing in OSM like this."  It must start with "here is what there is in the real world."  (Times three, five, twelve or fifty if you count all the cross-products of "tourist routes in Bavaria" and "basic_network in the canton of Zug in Switzerland" and all the rest of them).  If, after you've enumerated the whole giant bucket and all of the different critters in it, and they start to aggregate into "these cleave into a group because they are all in Germany" or "these are all at the regional level of 'Bavarian bike routes' but there are maybe four or five sub-networks in THAT grouping" and "this is a basic network, but it stops in its current incarnation at the German-Swiss border..." you are on the right track.  But doing this "categorization work" cannot be avoided.

Whether you tag on ways as infrastructure (possible, likely and it will happen), or as routes and/or super-relations of routes (possible, likely and it probably will happen), those sorts of issues will sort themselves out as "well, OSM already does this with these tags" (and/or relations as routes).  But what truly shouldn't happen is "we have to invent a completely new paradigm" (as the proposal does).  I get it that there are a rich set of routes and even networks.  But for the last time, we have the ingredients to bake this cake without inventing new tagging schemes and new keys.  Feel free to invent your own values for cycle_network, that's the point of it:  to make it work in your "region" (which could be all of Europe, for all I know).  But please don't invent entire new tagging schemes when the rest of the world already does this (rich, complex different kinds of bicycle routes at various levels of hierarchy which sometimes need the complexity of super-relations...) with existing tagging schemes.