<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
  </head>
  <body>
    <div class="moz-cite-prefix">Am 16.11.2021 um 09:07 schrieb Peter
      Elderson:<br>
    </div>
    <blockquote type="cite"
cite="mid:CAKf=P+v8ZPTM75S+ioebfk+GuCy92PiW52VPQZNdpzx-mtabHA@mail.gmail.com">
      <meta http-equiv="content-type" content="text/html; charset=UTF-8">
      <div dir="ltr">JochenB:<br>
        <div class="gmail_quote">
          <blockquote class="gmail_quote" style="margin:0px 0px 0px
            0.8ex;border-left:1px solid
            rgb(204,204,204);padding-left:1ex">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>
          </blockquote>
          <div><br>
          </div>
          <div>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). </div>
        </div>
      </div>
    </blockquote>
    <p>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>
    </p>
    <br>
    <blockquote type="cite"
cite="mid:CAKf=P+v8ZPTM75S+ioebfk+GuCy92PiW52VPQZNdpzx-mtabHA@mail.gmail.com">
      <div dir="ltr">
        <div class="gmail_quote">
          <div>I think destination based planning and guidance is
            regular routing and navigation, and in itself does not need
            any special tagging. <br>
          </div>
        </div>
      </div>
    </blockquote>
    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>
    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>
    <p><br>
    </p>
    <blockquote type="cite"
cite="mid:CAKf=P+v8ZPTM75S+ioebfk+GuCy92PiW52VPQZNdpzx-mtabHA@mail.gmail.com">
      <div dir="ltr">
        <div class="gmail_quote">
          <div>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>
          </div>
        </div>
      </div>
    </blockquote>
    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>
    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?
    <pre>'cycle_network=<country>:<federal state>:<region>;node_network;lcn' ?</pre>
    <p>I think that's better::<br>
    </p>
    <pre>'network=lcn'
'network:type=node_network'
'cycle_network=<country>:<federal state>:<region>' 

</pre>
    <p>Different types of clustering - different tags. In my opinion,
      this is clearer, easier to understand, easier to evaluate and less
      prone to failures.</p>
    <p><br>
    </p>
    <blockquote type="cite"
cite="mid:CAKf=P+v8ZPTM75S+ioebfk+GuCy92PiW52VPQZNdpzx-mtabHA@mail.gmail.com">
      <div dir="ltr">
        <div class="gmail_quote">
          <div>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>
          </div>
        </div>
      </div>
    </blockquote>
    <p>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>
    </p>
    <p>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.</p>
    <p>Refraining from mapping the official cycle network with
      signposting is by no really an alternative. This is essential for
      good bike maps.</p>
    <p>b.r.<br>
      Jochen<br>
    </p>
  </body>
</html>