[Tagging] Feature Proposal - RFC - value 'basic_network' - cycle_network?

[JochenB]

Am 24.11.2021 um 07:20 schrieb stevea:
> ... Right now begins a sort of crazy time where the calendar slows way down, little work gets done and people travel and gather with family and friends.  ...

It's similar with me. Grandfather is visiting this weekend, he is alone
and we are preparing for Advent with him and the child.

I am positively surprised by the response to the proposal (even if a lot
is viewed critically), but can hardly keep up.


> If say, icn=4, ncn=3, rcn=2, lcn=1 then basic_network would be 0 (zero) in this way of thinking about things (not actually using these numbers, just to illustrate how they relate to one another as layers / levels).  I think we might agree there.

There was also the idea in the German forum to map level "0" via
/'networc=bcn'/, that would fit this point of view. Roughly this fits,
but it is also not ideal.

*Short version: *in certain cases it may be that the specification of
/'network=l*n/r*n'/ makes sense, then it does not fit.

*Long version*: /'network=icn/ncn/rcn/lcn'/ was defined for classic
routes that have a clear beginning and end. It often contains two
statements in one tag:

 1. Statement about spatial extent (length of the route in relation to
    the size of the regions / countries)
 2. Adminstrive classification or jurisdiction

This tag is not entirely clean either, because it expresses two things
at the same time.

In the sense of a), /'bcn'/ would actually be another level, here that
fits very well. The other values /'//icn/ncn/rcn/lcn'/ do not seem
sensible to me in a network with many connections and thus many
beginnings and ends. What is used for categorization? The length of the
longest or shortest connection on the network? Or the expansion of the
whole network? How do you determine the extent of a network if the
networks at the edge are linked to a similar neighboring network. What
is the added value that we derive an /'//icn/ncn/rcn/lcn'/ , it cannot
be read outside? Can't the data evaluators deduce this themselves? So it
also happens that the similar basic networks in Germany are sometimes
tagged as 'lcn', sometimes as 'rcn'. Examples:

  * 'lcn': cycle-network Steinfurt, relation 2003649
    <https://www.openstreetmap.org/relation/2003649>;
  * 'rcn': cycle network Dithmarschen, relation 1771415
    <https://www.openstreetmap.org/relation/1771415#layers=C>

With /'network=bcn'/ these questions would no longer arise, it would be
another layer.

With regard to b), it can sometimes be useful to specify
/'network=icn/ncn/rcn/lcn'/. This is the case when there are different
basic networks with different responsibilities, especially when the
networks outside differ, e.g. B. by different standards. So there can be
a basic network of nationwide connections (/'2-rcn'/) with /'surface =
asphalt'/ as standard, in the municipalities an additional basic network
with different signposts (/'1-lcn'/), where also /'surface = compacted'/
is permissible. Then I would use the /'network=rcn/lcn'/. But that would
result in the following:

    'network=bcn;rcn'

On the one hand, it can be seen that 'bcn' does not completely fit into
the scheme /'icn/ncn/rcn/lcn'/, on the other hand I find tagging two
values on a key unfavorable. Therefore I would prefer to use a different
key or describe the individual properties in individual keys, which
distinguish networks or routes.


> However, I honestly believe that you can denote the "purpose" of a network by adding a modifier to the value of a cycle_network=* value.  Likewise for "THE" basic_network in a given jurisdiction.... cycle_network=DE:Bavaria:basic (or something like that)  ...  cycle_network=DE:Bavaria:tourist ... cycle_network:DE:Bavaria:commuter.

Yeah, kind of like that. I would give the network a title. How we call
this and in which hierarchy we would have to discuss for ourselves in
Germany. The purpose of the network can be the namesake (basic, tourist,
rehabilitation ...), but it doesn't have to be. In my german state
Saxony, the basic network has an official name "Rad.SN", so maybe that's
what it will be and not the purpose of the network.

    'cycle_network=DE:Saxony:Rad.SN'

Certainly you can also specify properties of the routes or networks in
/'cycle_network'/, such as the purpose of a route. The question is, is
it the best place for it? I mean it's not the best place.

*Example: *In Bavaria the basic bicycle network has a green bicycle as
its symbol. We could agree in Germany to designate the network as follows:

    'cycle_network=DE:Bavaria:network green cycle'

or similar. Let's imagine a data consumer wants to display color and
symbol. He should know to look for the network name in
/'cycle_network'/. We would have to document in the wiki at
'cycle_network' that in Germany these properties are mapped in the
network name, the color comes after "network" and the symbol after the
color. The data evaluator would have to program Germany-specific rules.
In the wiki we would have to document all such country-specific rules
for /'cycle_network'/.

I think it becomes clear that you should use the key /'symbol=*'/, even
if you find the symbol and color in the name of the network.

It is the same with the purpose of a route / network. In Germany we can
use the purpose as the name of the network in /'cycle_network'/. That
would be a country-specific solution. That is OK here, because names are
naturally country-specific.

The aim of the proposal was to enable the renderer to display tourist
routes differently than basic connections. However, it should not have
to derive the purpose from a country-specific name. It is better to
specify this property using a key that represents only this property as
far as possible and that can be used worldwide where similar situations
arise. Ideally, it can already be deduced from the name of the key which
property is being mapped.

*Another example: *The need for a separate key becomes particularly
clear when the basic network has its own name, such as "Rad.SN" in
Saxony. From /'cycle_network=DE:Rad.SN'/ it is not possible to derive
the purpose of the routes in the network "Rad.SN".

So I'd like to suggest a tag that makes this distinction explicit. That
is the intention of the proposal that has now been formulated. I have
learned that it is better not to use /'network: type'/, but to use a
self-speaking key.

I would like to argue about this key name and its values, especially on
this mailing list, because key names and values should be
internationally understandable.

With that I would revise the proposal and open a new thread for discussion.

Best regards,
Jochen
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/tagging/attachments/20211127/380a2da3/attachment.htm>