[Tagging] Feature Proposal - RFC - value 'basic_network' for keys 'network:type', 'lcn' and 'lwn'

[stevea]

On Nov 16, 2021, at 4:09 PM, JochenB <JochenB at wolke7.net> wrote:
> Am 16.11.2021 um 09:07 schrieb Peter Elderson:
>> JochenB:
>> In the case of node networks, 'network: type=*' is already used
>> successfully. There, 'network:type=node_network' describes the type of
>> signposting. 
>> 
>> No, it doesn't! It describes the type of network using labeled Nodes and Node2Node connection routes to guide the walker, cyclist, horse rider etc through the area along a prescribed list of labeled Nodes. Each labeled Node points with labeled arrows to the adjacent Nodes, so the user just needs to follow the arrow to the next Node on the list (or node strip).
> That is exactly what I meant by signposting. Maybe that's because of the translation tool. Basic network (destination signage) and themed routes (route symbols) also have their own way of guiding hikers or cyclists. All of these can and will be combined.

This is wonderful, I believe all of us would agree.  The question is HOW they are combined, how these are discussed and understood amongst ourselves (including those of us who want to ponder and think well about these sorts of tagging schemes, but do not have such "cultural guiding principles," routes, signs, (which is what these principles become) in our culture / region / signage / roadways / bicycle and hiking routes and networks.

When it comes to the Germans (or Belgians, or Dutch...) want to map cycle / hiking routes which are far more rich than what might (or do) exist in my culture / nation, I want to GET OUT OF THE WAY and let these develop, grow and flourish.  At the same time, I want to understand them and possibly offer insights from my / our perspective on how this might, can and actually does fit into the greater world.  If there were some sort of proposal that might "step on" (interfere with) either my / our way of doing this, or it looked like it was short-sighted and could potentially break things (or confuse them) for the rest of the world, I would hope I might be able to say something about that and have it fall not upon deaf ears, but upon a listening community that says "hm, yes, maybe we can tweak this in Western Europe so with some minor changes, this works in the whole world."  We are not quite there yet, but I am glad we dialog and listen to each other so that possibility remains open — this is the usual OSM way and it seems we're doing fine.  The road ahead to do so looks clear and good, and again, I thank the mail-list and community for listening and good dialog.

>> I think destination based planning and guidance is regular routing and navigation, and in itself does not need             any special tagging. 
> It is not a question of whether routes with guideposts are mapped as a special day on the routes or on routes. The question does not really arise, because a large part of the network has already been mapped and is the basis for many cycle maps.

I am glad to hear this.  As a brief aside, I'll mention that "tag" and "day" are often substituted — potentially confusingly — in machine-translated texts between German and English (and back to German again).

> It is only a matter of making a distinction between the different layers of the cycle traffic network with the different target groups, network types and types of signposting. Today renderer have no chance to distinguish this. 'network=*' and 'cycling_network=*' are already aimed at other classification options that can be combined with the basic network.

There are at least a couple of assumptions here, this isn't wrong, but it can be perilous to do so:  in one sense, tagging with a network=* tag and a cycle_network=* tag (not cycling_network=*) is VERY well-established, and I don't think we want to abandon doing so.  In a second sense, "basic network" remains a rather colloquial (to Germany and perhaps other parts of Western Europe) notion which, while I'm happy to concede certainly exists and should / must be accommodated in OSM, is still a new-ish concept to other (bicycling) cultures, such as those of us in the USA who have an idea of well established bicycling networks which fit quite well into the (OSM-) established hierarchies of "national, regional, local."  I want to accommodate "basic network," but I also want to see, participate in the development of, fully understand, and potentially untangle from MIS-understanding within other cultures and other well-established bicycle network mapping schemes (like OpenCycleMap/OCM's three-level hierarchy...realizing it is not perfect and needs extensions such as cycle_network=* to be fully sensical).

Given that those are regional / cultural assumptions, that this IS a global project called OSM, that OCM, cyclosm and other cycling renderers have well-defined national / regional / local "levels" for routing and networks that are well-established:  we want the proposal to remain harmonious, understandable and able to "fit into" a global scheme that can be well understood, even in cultures / regions where the asserted German styles of routes certainly do not exist, but can be understood to exist elsewhere.

>> I am fine with tagging <transport>_network for national, regional and local network plans. Most of those I see as road preference systems, aimed at channeling traffic. I would translate that into some kind of quality indicator, to be used as a weight indicator for routing. If it is a collection of predesigned routes, typically with route labels and indication of an operator, that's where the <transport_network=* can be applied, I think, even though I personally don't really care whose route it is if I'm on the road. 
> We need both, 'cycle_network=<country>:<federal state>:<region>:<commune>' for classification in the network structure of the federal states. In addition, we need a distinguishing feature to represent the differences described.

Yes, I am glad to see the specifics of these "nuts and bolts" being discussed here.  These words above are a "tip of the iceberg," there is much more complexity under the surface.  Let's not keep this submerged, let us discuss the specifics so that no misunderstanding remains.  The proposal (perhaps initially its Discussion / Talk page) seems a good place for this.  German happens to be the language used there, I have already posted there in German (thanks to machine translation), even though I speak / write absolutely no German (besides "Ja," "Nein" und "Guten Tag").

> There are several dimensions in which networks differ and according to which they can be classified. Mapping all dimensions in one tag makes it complex. How would we eq. tag a network conceived by a regional administration with a small spatial extension and a node network signposting?
> 'cycle_network=<country>:<federal state>:<region>;node_network;lcn' ?
> I think that's better::
> 
> 'network=lcn'
> 'network:type=node_network'
> 'cycle_network=<country>:<federal state>:<region>' 

I agree: a SINGLE tag seems as though it might be too much here and it could get overloaded.  Let's agree that it seems OK to expand to TWO tags (slowly growing-up from one) and keep it to network=* (established), cycle_network=* (established) and PERHAPS (maybe it becomes this, maybe something else or something richer) network:type.  We remain in the early stages of this, so MORE or RICHER kinds of syntax (proposal) are quite welcome (at this point — the door to doing this might close soon and must close at some point in the future, lest we get bogged down in the mud).

> Different types of clustering - different tags. In my opinion, this is clearer, easier to understand, easier to evaluate and less prone to failures.

EXACTLY this sort of discussion is extremely welcome.  Please be more specific with how the clustering will be EXPRESSED AS specific tags.  Good...VERY good!

>> But is it worth it to break down the road system into pieces between every guidepost,create route relations for all the pieces, and labeling all these chunks with a *_network=* value? It's a lot of work, it's a lot of never-ending maintenance, and what does it actually achieve? 
> What's the alternative? So far, all the routes in a district have been put into a relation in an unstructured manner. The largest relations have over 4,000 members! This is really difficult to maintain. Many of these relations have therefore remained at their old status and are no longer maintained.

We're going to need to solve this eventually.  4,000 members is too large.  (Ways with >2000 nodes, relations with >2500 members...) data structures in OSM with these approximate numbers or greater are simply unwieldy by mutual consensus.  Let's strive to find ways to simplify things at a "more macro" level where it becomes easier to "chunk" things perhaps at "more layers" (or levels), but with fewer individual members of great-big structures.  I'd much rather deal with "five levels where at the bottom or next-to-bottom level, there are dozens or hundreds of things" much better than "three levels where at the bottom there are many, many thousands of nodes or objects."  Four levels is better than five, three levels is better than four, but hundreds or even dozens is much MUCH better than thousands.

> Only breaking it down into manageable pieces makes this work maintainable. In the end, it is not much different than with node networks, only the node names are missing. I find this very maintainable.

It does seem we're on the right rack here, if node names are all that are missing, and adding those makes things either maintainable or MUCH MORE maintainable, then please:  let's add the node names!

> Refraining from mapping the official cycle network with signposting is by no really an alternative. This is essential for good bike maps.

I'm not quite sure what is meant here, but that's like a "five out of six" (or thereabouts), so I'll take JochenB's post as "a pretty big win" and suggest that we keep discussing.  Great so far!

SteveA