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

[JochenB]

Am 16.11.2021 um 08:09 schrieb Sebastian Gürtler:
>
> I think instead of the basic_network tag it may be possible to use
> cycle_network=DE:xyz (unique tag like "official" or just the code for
> the state signalling that it is the governmental network) and
> noname=yes. This also implies the possibility to create basic routes
> just by tagging cycle_network=DE:xyz without using a name=* tag which
> I would prefer because the network system is changed quite frequently
> and new named routes are added (it is very simple, they just add route
> logos to the direction signs). So one doesn't need to remove possible
> noname=yes tags on the way if a new named route is made up.
>
The aim is to distinguish the (mostly) tourist routes from the other
hiking and cycling networks provided with signposts. I see two main use
cases:

A) One user wants to know where cycling / hiking is officially
recommended (basic network). In the German cycling network, these can be
recognized by the destination signposts with place names and
intermediate signposts with arrows. The user wants to recognize these
paths in order to prefer them when navigating

B) The other user wants to follow a certain signposted route
recommendation (in Germany: symbols)

The basic network and signposted route recommendations are usually
mapped in OSM with route relations. Both often occur simultaneously.
Therefore, both must be distinguishable from each other in order to be
able to represent them differently.

'noname = yes' describes a characteristic that applies to all
connections in the basic network. That sounds good at first.
Unfortunately, it can also apply to route-based signposting. Sometimes
these routes only have a symbol and no name. This is not uncommon,
especially on hiking routes. Therefore, I find 'noname = yes' unsuitable
to differentiate between the various network layers with their guidpost
types. The lack of a symbol is also not enough. Often the basic network
also has a uniform symbol for the entire network. In the German cycling
network, for example, it is the green or red bicycle. It is the red line
on the Swiss hiking network.

In principle, 'noname=yes' only describes a symphtom and not the heart
of the matter. It's a bit like tagging 'sign_color=blue' instead of
'highway=motorway'. I find that unsatisfactory. Why not call the child
by name?

The question now is, how do you classify the route relations in order to
best reach the goal?

I see several possibilities for classifying the networks:

*The spatial extent (established):* local / regional / national /
international

    For this, the 'network=l*n/r*n/n*n/i*n' has prevailed.

    This becomes difficult with close-knit networks. The individual
    links in the network are often short. Since the networks are linked
    to neighboring networks, the spatial extent of the entire network
    can often not be clearly determined, sometimes it is very large, up
    to national.

    In Germany, this is different in every district (lcn: Relation
    Radverkehrsnetz NRW, Kreis Paderborn (222581)
    <https://www.openstreetmap.org/relation/222581> ; rcn: Relation
    Radverkehrsnetz NRW, Kreis Siegen-Wittgenstein (124706)
    <https://www.openstreetmap.org/relation/124706>). Here, too, a
    uniform approach would be desirable.

    The goal is not reached.

*The administrative assignment (partially established):*
<country>:<state>:<destrict>:<municipality>.

    In Germany, this is usually mapped using parent and child network
    relationships, starting with the federal state. In addition, there
    is an "invented" 'ref' value on the routes, e.g. 'ref=NRW'.

    I would like to establish 'hiking_network / cycle_network =
    <country>: <state>: <destrict>: <municipality>'

    The goal is not achieved with this.

*External characteristics (partly established):* e.g. 'symbol=no',
'name=no', 'no_ref=yes'.

    The goal is not achieved with this, because the desired distinction
    is not always clearly possible with these values, see above.

*Structural properties (partially established)* such as the layer / form
of the network: e.g. 'basic_network', 'node_network', 'line_network';
'circular_route', 'honeycombs'.

    There is already an established key with 'network:type=*', but so
    far only the one value 'node_network'. New values need to be introduced.

    For me, 'basic_network' is a simple network of connections with
    associated marking / signposting and connected nodes.

    The goal can be achieved very well.

*The way users are guided (not established):* 'destination_guided',
'symbol_guided', 'number_guided', 'colour_guided'.

    A new key would have to be found for this.

    The goal can thereby be achieved for the German application cases.

    In other countries, however, the basic network can only be marked
    with symbols without any destination signs. Then it doesn't work
    anymore.

*The target group for signposting (not established):* 'touristic',
'workaday_traffic', 'rehabilitation'.

    I don't know a key for that either.

    The challenge here is that the signposting actually helps everyone
    and it is often not clear who it is aimed at.

    The goal cannot therefore be achieved.

I don't have any more ideas at first.

In my opinion, the assignment based on structural properties is best.

You could use the keys 'network=*', 'cycle_network=*' or
'network:type=*' and introduce new values.

However, these first two keys already have their own definitions with
which the goal is not achieved. I would also like to use them in
parallel, especially the 'cycle_network = *'. Then you would have to
enter several keys in one tags.

'network:type=*' fits best because the already established key
'node_network' is also of a more structural nature.

Viele Grüße,
Jochen
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/tagging/attachments/20211119/6ffaaa21/attachment-0001.htm>