<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<div class="moz-cite-prefix">Am 21.11.2021 um 18:30 schrieb stevea:<br>
</div>
<blockquote type="cite"
cite="mid:9EDA8238-E15D-4B50-8A07-9B8C569A4B2A@softworkers.com">
<pre class="moz-quote-pre" wrap="">3) Use cycle_network=* tagging with sane, planned, sensible values that have achieved consensus across a country (or countries, or a region, however "region" is defined and used "there").
Again: this 'basic_network' seems like a whacky branch of mathematics being invented when "we already know math." </pre>
</blockquote>
<p> The basic network is not a design I designed for OSM. It is a
construction outside, in reality. There is a network there that is
officially recommended for hiking or everyday cycling. In
addition, there are special route recommendations in this network
(themed routes) and / or the node-based signposting (cycling by
numbers).</p>
<p>I cannot explain why this is understood here as a complex model.
If it is complex, it is because in reality it is complex. But it's
not for me. It's just three things that we should put separately.
There is already a tag for one of the three things that the spade
calls a spade. I suggest extending this tag to include the others
by their names.<br>
</p>
<p>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.<br>
</p>
<p>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:</p>
<blockquote>
<p><a moz-do-not-send="true"
href="https://wiki.openstreetmap.org/wiki/File:Guidepost_basic_network_and_node_network_and_route_recommendation.jpg">File:Guidepost_basic_network_and_node_network_and_route_recommendation.jpg</a>
<br>
</p>
</blockquote>
<p>
But there are also many sections where there is only the basic
network. The proposal is intended to enable them to be presented
differently.<br>
<br>
</p>
<blockquote type="cite"
cite="mid:9EDA8238-E15D-4B50-8A07-9B8C569A4B2A@softworkers.com">
<pre class="moz-quote-pre" wrap="">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.
</pre>
</blockquote>
There are six reasons that speak against extending the <i>'cycle_network'</i>
tag to include the distinguishing feature mentioned in this
proposal.
<blockquote>
<p>Reason 1: After a successful proposal, I would like to
recommend <i>'cycle_network'</i> also for the german
administrative hierarchy:</p>
<blockquote><font face="monospace">cycle_network=<country>:<federal
state>:<region>:<municipality></font></blockquote>
<p>This is different from the differentiation I have proposed
according to the purpose of a route relation. To accommodate
this distinction in <i>'cycle_network'</i> 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.</p>
<p>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 <i>'cycle_network'</i> instead of <i>'network:
type'</i> does not solve the problem.<br>
</p>
<p>Reason 3: <i>'cycle_network'</i> 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. <br>
</p>
<p>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<span class="VIiyi" lang="en"><span
class="JLqJ4b ChMk0b" data-language-for-alternatives="en"
data-language-to-translate-into="de" data-phrase-index="2"
data-number-of-phrases="3"><span></span></span></span> </p>
<p>Reason 4: When I suggested adding a value to the existing tag <i>'network:type'</i>,
the criticism that <i>'network:type'</i> 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 <i>'cycle_network'</i> as well, so it
would not be an improvement over today's state for e.g. <i>'network:type=node_network'</i>.</p>
<p>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 <i>'cycle_network'</i>. To make matters worse:
The structure seems to be different in different countrys.<br>
</p>
<p>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 <i>'cycle_network'</i>
does not come from the signposts.</p>
<p>reason 7:<br>
</p>
</blockquote>
<p>Using <i>'cycle_network'</i> for all these different pieces of
information in the same key is a bit like putting all tags in <i>'note
= *'</i>. Then you have to define your own structure within the
<i>'note = *'</i> in order to be able to distinguish the
information again. But we already have a recommended structure in
OSM:</p>
<blockquote>
<p><font face="monospace"><self-explanatory key name>=<<u>one</u>
value that matches the key name></font><br>
</p>
</blockquote>
<p>I would like to approach this structure according to the motto
"one key - one distinguishing feature - one piece of information -
one data source"</p>
<p>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.</p>
<p>If the established <i>'network:type' </i>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<font face="monospace"><br>
</font></p>
<blockquote>
<p><font face="monospace">route:purpose=basic_network/route_recommendation</font><br>
</p>
</blockquote>
<p>or just write a simple<br>
</p>
<blockquote>
<p><font face="monospace">basic_network=yes/no<br>
</font></p>
</blockquote>
<p><span class="VIiyi" lang="en"><span class="JLqJ4b ChMk0b"
data-language-for-alternatives="en"
data-language-to-translate-into="de" data-phrase-index="0"
data-number-of-phrases="1"><span>on the relations, what do you
think?</span></span></span> </p>
<p>Viele Grüße,<br>
Jochen<br>
</p>
<br>
<p style="margin:0in;font-family:Calibri;font-size:11.0pt"><br>
<br>
</p>
<br>
</body>
</html>