[Tagging] cyclist profiles - was:Feature Proposal - RFC - value 'basic_network' - cycle_network?

[JochenB]

Am 01.12.2021 um 21:56 schrieb stevea:
> OK, I get a bit closer to good understanding with this.  You want to distinguish between network=lcn (or any other value) and what we might say is network=generic.
>
> I don't understand WHY.  I don't understand HOW THESE DIFFER.  I don't understand why you or a use-case or a renderer or a router would want to distinguish these, as they are all "infrastructure which is more suitable for bicycles than not," so I would insist upon some very sharply documented reasons for we "other people in other parts of the world who use the existing bicycle tagging schemes OSM now uses, and don't seem to have a problem with any of this."
>
> If you were to do this, and have your (new) ability to distinguish BETWEEN, say, network=lcn and network=generic, it still remains true, valid and worthy that a sub-value in key cycle_network=* could specify whether this one is commuter, that one is touristic, the one over here is basic, etc.  Right?
>
> However, and I've said this before (though I do so carefully as it might appear I am rancorously accusing and calling you / others there "lazy," and I'm not), it seems the root cause of this is a lack of development of structure (of EXACTLY this sort) in the cycle_network=* values namespace (perhaps from "DE: on down").  What remains lacking if you have network=generic and the ability to distinguish with cycle_network=* values?  (It seems like absolutely nothing to me, but I do continue to listen).

There is a risk of repeating myself: the data consumers cannot
distinguish route-based tour recommendations from routes that simply
have a signpost and are therefore part of the cycling network or hiking
network. Everything looks the same in our maps. The need to change this
becomes greater, the denser the networks become.

It needs a feature by which e.g. a renderer can easily recognize whether
the relation / path belongs to type A or type B. This should not be done
based on the network names in e.g. B. in 'cycle_network', because the
name can be different in each region. A simple key 'xyz = A' is required
and not a key that contains long texts that have to be interpreted. This
key should also not be region-specific. Therefore an addition to
'cycle_network' is necessary, because 'cycle_network' does not meet
these criteria. I have presented this in detail elsewhere.

The idea here was to mark the paths marked with signposts with a key
that is different from the key for node networks and route-oriented tour
recommendations. I almost don't care what this key is called.