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

[stevea]

I do not have the knowledge nor time to invest in designing a "full-Europe" set of values for cycle_network=* because I'm not familiar with the rich set of the routes, networks and jurisdictions where the do or might overlap.

But I know I did this by throwing all the kinds of routes that existed into one big bucket, then sorting them out into different buckets, without really being concerned about whether they were "national" (and might get tagged network=ncn) or "regional" (and might get tagged network=rcn)...and so on.  I / we (when we did this around 2013 in the USA) noticed that there were three or four or five or maybe six "kinds" of "groupings," some of them "acting national" (and maybe as many of three of them actually were and are national, but that doesn't mean we have to call ALL of them that, especially as we can differentiate them with cycle_network values that differ from one another.  So maybe something that really ACTS national is better expressed (in OSM in the USA, because we also denote it with a specific and unique cycle_network value to differentiate it) as regional (network=rcn) instead of ncn (national).  In fact, we did just that, but not before we discussed it and did the "goods and bads" about that...and tried on a couple of different solutions and we discussed it some more...we DESIGNED it.  We made mistakes along the way.  We came up with something that even today maybe isn't perfect, but it is good enough to work (and grow) and it does both.  I'm thrilled.  I'm also confident you can do this, too.

And so on.  The "tourist" or "more commuter oriented" and even "the basic_network" (I still don't see why lcn=yes or rcn=yes or similar tags can't "collect" these) "routes" (as members of a network or networks) — which ARE, after all, OSM relations tagged type=route, route=bicycle...it's the other tags we're wrangling about...these can get whatever values for cycle_network that make sense to you.  If you don't like cycle_network=DE (for Germany, and then followed by German states and maybe German cities within those states...you know, a hierarchy) because "you have to look for a specific keyword in value," OK I hear you, maybe you prefer to spell out "Deutschland" rather than abbreviate DE:.  Maybe you want to "spell out" "basic_network" (as a cycle_network value) instead of using "bas_net" (or some obscure abbreviation, as that can be OSM-unfriendly), although there are arguments to be made for good abbreviations people already know and there are arguments for "spell out the whole word so we don't have to guess at what an abbreviation stands for."  Your choice!

But start out putting "everything under the sun" (routes, categories of routes, networks, categories of networks, the whole cross product of this with the geography of countries and how "only up to the jurisdiction boundary" is truly going to affect routes, basic_network and whether something is a member of this relation or not a member...) and so on.  LOOK at this big bucket / table of "things."  See if there is structure, especially "country at a time."  (I can almost guarantee you that what Bavaria calls its basic_network is NOT going to be the same as what a Swiss canton might call this, after it has been identified as "yes, this is pretty much the same kind of thing, but the way we do it is Zug-like, rather than München-like."  You'll find overlaps, you'll find exceptions.  You'll find broad categorizations that allow you to say "these are pretty similar but not exactly the same, let's put them in a loose aggregation category that denotes their similarities."  You'll find things that are expressed with a hierarchy in a network tag that STILL needs to include the complexity of being blended into super-relations.  Or not.  Or..."roll your own as you see fit."  That's why cycle_network changes around the world:  because things are different around the world.  Not SO different they can't be expressed with a sensible (maybe even fully-spelled-out words) structure in a smart key like cycle_network, but close enough that with good design, this CAN be designed.

Whew, I'm exhausted.  This CAN be done.  It requires work and more discussion using these ideas and the wheels we've invented (the data structure elements, tagging schemes and renderers / routers we already have), not new wheels that obfuscate away messy tagging and what appears to be laziness of "we shouldn't be forced into imposing what feels like artificial structure upon us and our bicycle routes / networks here."  Well, in OSM, about bike routes, yeah, you should.  The world already does this.  Apparently, you don't (yet).  But you should, I'll be the first to welcome you into the world of doing it a lot like the rest of us. You can get there.  Take the time to design what the heck these routes and networks are trying to "utter" and express to everybody (you really haven't even done THAT yet, it's a good place to start), denote that / those using the building blocks / data structures we already use and everybody will cheer.  But please do not avoid doing the necessary work it will take to "properly" structure this with room to grow for the future.  Because once you do, it will pay dividends of clarity and growth into the future.  I say this from personal experience, and you can check out me and the truth of this yourself.

Encouragement!  (Not rock-throwing).  I wish to offer encouragement!