<div dir="ltr">Ok, thanks so far, JochenB. <div>Is this correct: A cycle network of this size (all of Germany) cannot fit into a single relation, so it is a hierarchy of network relations. The lowest level contains the route relations. The junctions where routes happen to cross each other, are the start/end points of the routes. </div><div><br></div><div>The main purpose of the system is to show cyclists the designated cycling ways (win-win for traffic control and for the cyclist) and give them clear destination-based directions. Which does not have to concern mappers, because mappers can just map what they see (given knowledge of the German ways) and it will fit in. Except... how it fits into the network hierarchy, that is not every mapper's cup of tea. </div><div><br></div><div>I think this German integrated guidepost system is great for cyclists, once you get the hang of it!</div><div><br></div><div>The purpose of mapping it all in this way is another thing. </div><div><br></div><div>The purpose of rendering. OpenCycleMap shows routes (route relations containing ways), I think? To my understanding, the membership of the route relation is converted to an attribute of the way, and that is used to determine how it is rendered. If that is how it's done, the network relations are not used for rendering. I know OsmAnd doesn't use the network- and route relations in themselves for rendering (nor for routing).</div><div>My understanding is that for rendering, a tag on the way is easier and quicker than membership of a relation. Correct?</div><div><br></div><div>The purpose of routing then. Again, I am far from an expert, so I will probably (hopefully) be set straight! My understanding is that routing is in the end also based on attributes of the ways. The router chooses ways and assigns weights to ways, according to the routing profile, and calculates which way is the best way to continue the trip. I know that it's a lot more complicated, but the point is, it's way-based, and tags on the ways are easier to process than membership of a relation. Correct?</div><div><br></div><div>The purpose of trip planning then. Yes, this may involve routing, but it is not the same! Node Network planning is: chaining predetermined routes together to form the itinerary of the trip. No way-based routing involved there. The user selects the labeled Nodes corresponding to the Network Nodes found on junctions; the software chains the sections together and the result is a list or strip of Node labels telling the traveler exactly where to go at each Network Node. </div><div>This Node Network system is aimed at guiding the traveler along ways and routes that a router would not choose. It's not a how-to-get-there system, it's a what-would-you-like-to-see system, and that's why it's worth it to do all the mapping work involved. </div><div><br></div><div>Maybe I am missing important purposes here? </div><div><br></div><div>In this basic_network case, I would like to know why it is worth doing all this mapping and building such an elaborate system of relations on top of the ways. </div><div><br></div><div>A different question: am I correct that this system specifically targets cycling? </div><div>I know in places, the integrated guidepost system is also applied to hiking/walking but I think waymarking with e.g. a green or red "walk here" sign between guideposts is not that common. </div><div><br></div><div><div><div><div><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature">Fr gr Peter Elderson</div></div></div></div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Op wo 17 nov. 2021 om 02:38 schreef stevea <<a href="mailto:steveaOSM@softworkers.com">steveaOSM@softworkers.com</a>>:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Nov 16, 2021, at 4:09 PM, JochenB <<a href="mailto:JochenB@wolke7.net" target="_blank">JochenB@wolke7.net</a>> wrote:<br>
> Am 16.11.2021 um 09:07 schrieb Peter Elderson:<br>
>> JochenB:<br>
>> In the case of node networks, 'network: type=*' is already used<br>
>> successfully. There, 'network:type=node_network' describes the type of<br>
>> signposting. <br>
>> <br>
>> 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).<br>
> 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.<br>
<br>
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.<br>
<br>
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.<br>
<br>
>> I think destination based planning and guidance is regular routing and navigation, and in itself does not need             any special tagging. <br>
> 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.<br>
<br>
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).<br>
<br>
> 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.<br>
<br>
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).<br>
<br>
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.<br>
<br>
>> 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. <br>
> 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.<br>
<br>
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").<br>
<br>
> 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?<br>
> 'cycle_network=<country>:<federal state>:<region>;node_network;lcn' ?<br>
> I think that's better::<br>
> <br>
> 'network=lcn'<br>
> 'network:type=node_network'<br>
> 'cycle_network=<country>:<federal state>:<region>' <br>
<br>
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).<br>
<br>
> Different types of clustering - different tags. In my opinion, this is clearer, easier to understand, easier to evaluate and less prone to failures.<br>
<br>
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!<br>
<br>
>> 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? <br>
> 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.<br>
<br>
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.<br>
<br>
> 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.<br>
<br>
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!<br>
<br>
> Refraining from mapping the official cycle network with signposting is by no really an alternative. This is essential for good bike maps.<br>
<br>
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!<br>
<br>
SteveA<br>
_______________________________________________<br>
Tagging mailing list<br>
<a href="mailto:Tagging@openstreetmap.org" target="_blank">Tagging@openstreetmap.org</a><br>
<a href="https://lists.openstreetmap.org/listinfo/tagging" rel="noreferrer" target="_blank">https://lists.openstreetmap.org/listinfo/tagging</a><br>
</blockquote></div>