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

[stevea]

On Nov 21, 2021, at 4:48 PM, JochenB <JochenB at wolke7.net> wrote:
You had me at first.  Saying "it is not designed for OSM."  I allowed that as a good starting place.  And I thought, "OK, he's going to say how our relational database SHOULD model that."  Or maybe "here's how I think to model it" or "it can't be modeled, here's why."

But you didn't quite, you started waving your hands again by stating "basic network" like I already know what that is.  I don't.

As others (from Europe) have stated, this isn't a concept unique to Germany or "your way of thinking or proposing a solution about it."

We have no reason to ascribe to reasons of "children's toys" that we are talking about an existing paradigm (which works, and is documented, and has been both for a decade or more) that isn't anything besides a working transportation network, sparsely and somewhat elegantly described by OSM's basic data structure of elements [nodes, ways, relations].  Earth, in OSM, does this.  We have a legacy of three-or-four levels (some renderers display international, some stick to national-regional-local...) which have allowed a rough framework to be draped over humanity and cyclists with some harmony.  We try to be a bit more precise with cycle_network tagging, where we can assign routes to be members of a network or networks.  That's pretty rich and as I have demonstrated, can accommodate anything you can throw at it, however you do things in your part of the world, with existing tagging.  You can.  I don't think you have, as there appears to be a great deal of disarray perhaps caused by poor planning and a lack of management or agreement or harmony or consensus.  That is "what is" right now.

> I think I have to revise my description of basic network in the proposal because it is misleading. Perhaps it is also because it is not common in other countries for the state to set up such a well thought-out bicycle network with three types of signage in one system. In many countries the bicycle is just a piece of sports equipment. It is hardly a transport device or everyday means of transport. The signposting systems are correspondingly simple.

Complex routing schemes that are expressed into networks can have truly and highly complex "levels" of overlap, inter-relations and relations between relations.  It is complicated at first to anybody who doesn't know what it is, but that doesn't mean it can't be taught, explained, diagrammed so others fully understand it.  You haven't done that.  Waving your hands and saying "but I know what this is..." and not getting others to "see it" as you do won't fly.

If it is so simply, then explain it simply, using the relatively simple building blocks of data structure we have in our map today (things like route relations, node-networks of bicycle routes and their networks, bidirectional routes, unidirectional routes, super-relations of routes, the existing hierarchy of networks, what can be done with sane, clever, planned, sensible, agreed-upon cycle_network=* values...).  Please.

> Anyone who is familiar with the local system will quickly understand which of them belong to the basic network, which to the route recommendation and which to the node network. Here is a picture where all 3 signage systems meet at a signpost:

There you go again, saying "this exists" and expecting others to know what it means without clearly saying so.  You have said so, but muddily and not clearly.  For hopefully the last time, you cannot say "basic_network" without others agreeing on what it is.  That has not happened yet.  Explain it in terms of how people already build highly complex bicycle routing systems (including both on-road and off-road with route=mtb:  two very different things, yet we accommodate them with specific tagging that is well documented in our wiki).

You have all the pieces you need, I don't think you need to insist that there is such a thing as a basic_network unless you can demonstrably "build the pieces of what it is" either out of comprehensible language (no hand-waving or circular definitions allowed) or out of data structures and existing tagging schemes in OSM.

I hereby draw this line in the sand lest we all go mad.

> File:Guidepost_basic_network_and_node_network_and_route_recommendation.jpg 
> 
> But there are also many sections where there is only the basic network. The proposal is intended to enable them to be presented differently.

Gee, could "presented differently" be another way to state "tag for a renderer?"

> 
>> If you haven't done these relatively simple, documented, used for many, many years already and widely supported by renderers and routers (and understood by humans using common sense), then go back and fix your tagging so you HAVE done these relatively simply, documented uses.  Please, for the love of $YOUR_PREFERRED_DEITY, do not invent something as horrific as this beast called 'basic_network."  It feels hostile and alienating to the rest of OSM and the relatively good, careful, conscientious, consensus-based bicycle tagging we've done in the rest of the world.
>> 
> There are six reasons that speak against extending the 'cycle_network' tag to include the distinguishing feature mentioned in this proposal.
> Reason 1: After a successful proposal, I would like to recommend 'cycle_network' also for the german administrative hierarchy:
> 
> cycle_network=<country>:<federal state>:<region>:<municipality>
> This is different from the differentiation I have proposed according to the purpose of a route relation. To accommodate this distinction in 'cycle_network' in addition to the hierarchy makes it more complicated, since a key then contains two pieces of information at the same time. If you include the network name in the value, there are even three different pieces of information in one tag.

So?  When they are well-chosen, you're going to get it right every time.  When you leave room (with sensible strategy and good planning), you'll have room to add new ones in the future, simply by coining them and putting them into the hierarchy "right about, no, EXACTLY...HERE" because that is where you imagined they would go in the future.  This is the part you have skipped and why this isn't flying.

> Reason 2: The main problem addressed in this discussion is that many from outside cannot understand what I mean by "basic network" and perceive it as a complex construct, see above. To write this term in 'cycle_network' instead of 'network: type' does not solve the problem.

It lives at least partly IN the STRUCTURE OF "cycle_network" because that is a real thing.  It is a highly useful tag.  It means something and it is blank canvas for you (or someone with the skills to do so) design, invent, engineer, utter, grow, extend into the future...a new way of organizing how "cycling, the pieces of it put together around here" is done in [this state of Germany].  By the way, start out at a small level whatever you propose.  See how it fits.  See how it renders.  See how you can search for routes with something like Overpass Turbo queries (for example).  See how easy it is for others to enter and modify routes and networks because "ah, this makes a lot of sense, I'm glad somebody starting with a WORKING concept and communicated that to others with a clean design that fits into the framework of structuring data (especially about bicycle routes and networks as a lot of work is done already) sketched this out like this."  Wow, how easy and sensible!

When "this" is "there," we can talk.

> Reason 3: 'cycle_network' allows an almost unlimited number of values: on the one hand, combinations of country abbreviations, names of federal states, names of regions and municipalities, on the other hand, proper names of the networks. It is a free text field, even if it is structured. In contrast, we need a key here that has fixed values and not free text. 

Of course it does!  That's how it starts out as "blank canvas" then you draw boxes around it (but leave room to grow around the edges...there's this thing called 'the future,' you know).

Start with the blank canvas of "free text" (because you ARE!) and DESIGN IT!  That is design:  start with a concept.  Take the whole universe of mess you have and say, "hm, this seems like it belongs over here, and that over there, except where they overlap and we can blend those like this, except where we don't, because we're in another country or state or even city...".  That's design!  It can't be skipped!  Don't skip it thinking you can wave your hands and state "basic network!" and expect others to read your mind.  (I don't read minds).

> That would be two fundamentally different approaches in one key. I don't think it's a good thing for data processors to have to look for a specific keyword in value. Usually they look to see whether the value completely matches an expected value. I also don't think that is widely supported by renderers and routers as you put it

We have two fundamentally different approaches in one key in the USA.  One kind of "national routes" (with numbers) are tagged cycle_network=US:US.  One kind of "national routes" (with names or acronyms) are tagged cycle_network=US.  One brand new route that rather curiously and uniquely was "declared unanimously by Congress and signed by our President" (the "9/11" route) might be tagged cycle_network=US:USA (it's early and data are only beginning to enter and discussion is barely rolling).

But that's how we roll.  It works.  We keep our ears open.  We sketch out with some rough chalk lines and figuratively speaking "paint some watercolor" and some dashed lines might appear and the "paint hardens" and over months and years the red lines go from dashed to solid because everybody in the country and aware of the national network nods our heads and says "this seems to be working, understandable and growing nicely."  It CAN be done.  Using the existing pieces of tagging built into our syntax right now (and for as long as my 12+ years in this map project).

> Reason 4: When I suggested adding a value to the existing tag 'network:type', the criticism that 'network:type' is not self-explanatory was rightly so. The name of the key does not indicate which information is used for classification there. This criticism applies to 'cycle_network' as well, so it would not be an improvement over today's state for e.g. 'network:type=node_network'.

Cycle_network is not only an elegantly-named tag, it is also a highly successful one.  (Where people take the time to discuss "here's how we should carve up the namespace around here because 'we bike like this'" and then do so).  There isn't any criticism leveled at cycle_network, unless you are identifying it as "hostile," here and now.  Are you?  The tag works because it is understandable to be somewhat plastic and flexible around the world.  It's bubble gum:  blow some bubbles!

> Reason 5: You have to look in the documentation to see where you write which value, it is not self-explanatory from the structure within 'cycle_network'. To make matters worse: The structure seems to be different in different countrys.

Yes.  So?  You really lost me there.

> Reason 6: The information for the distinguishing features mentioned in the proposal can be derived directly from the signposts used. The information previously contained in 'cycle_network' does not come from the signposts.

Stop right here.  I cannot "derive" the meaning from a sign.  It should not be assumed that people can.  Much of the time, "we" can, especially as we have grown up around any group of particular signage and absorbed these into our local/regional/national culture that we know what they mean.  But traffic signs are notoriously "can't quite parse that in my way of thinking / language..." all around the world there are misunderstandings, like "I get it this is trying to tell me something about bicycle routing, or maybe network(s), but I'm not really clear exactly WHAT."  Welcome to the world where this is true.  It remains unexplained.  You can think of me as ignorant, I'm not, I simply haven't had a clear definition stated.  The MUTCD even attempt to clean it up among states in North America and we're a long way from harmony, but "something is better than nothing."  This is the same real-world problem, though "in a smaller box."

> reason 7:
> 
> Using 'cycle_network' for all these different pieces of information in the same key is a bit like putting all tags in 'note = *'. Then you have to define your own structure within the 'note = *' in order to be able to distinguish the       information again.

YOU get to design and implement the structure!  Do it!  You haven't yet!  It's lazy or broken to NOT!

> But we already have a recommended structure in OSM:
> <self-explanatory key name>=<one value that matches the key name>

This is like saying "invent a new verb blorfub" to describe something we already can express with "cycle_network" and network=rcn and nodes and ways and type=route relations.  I mean you can do that, but then you're going to get pesky people like me saying "why would you dump on our well-developed bicycle syntax with a mess like this?"  (When you haven't taken the time to design a system that matches / mimics your real world of rich routes and networks).  Design and describe the darn thing!

> I would like to approach this structure according to the motto "one key - one distinguishing feature - one piece of information - one data source"
> 
> I will not fight myself if there is no other majority for my proposal. It just doesn't convince me, for the reasons I       mentioned.
> 
> If the established 'network:type' does not fit, among other things because the key name does not explain itself, then I would rather look for a key that explains itself and that only contains one distinguishing feature, maybe
> 
> route:purpose=basic_network/route_recommendation
> 
> or just write a simple
> 
> basic_network=yes/no
> 
> on the relations, what do you think?

I think that is quintessential "lazy syntactic sugar" by somebody who can't or won't "use his words" (and existing OSM database elements) to express himself.  I have no apology to offer about that:  that's what it looks like to me and I'm saying so.