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

[JochenB]

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.


> 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.

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.


> 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.

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>'

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


> 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.

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.

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

b.r.
Jochen
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/tagging/attachments/20211117/07e2cf58/attachment-0001.htm>