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

[stevea]

> On Dec 1, 2021, at 1:41 PM, JochenB <JochenB at wolke7.net> wrote:
> 
> 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.

That's "fair," and understandable.  There is no risk of repeating yourself (or myself).  I tell people I newly meet at parties that it takes me four times of hearing their name before I remember it (because it does).  We make a joke out of it, they hear me say MY name at least four times, and by the end of the party, at least we know each other's names.  Let's say things are similar here.  We do seem to struggle to understand each other, I deeply appreciate everybody's patience at extending better understanding.

> It needs a feature by which e.g. a renderer can easily recognize whether
> the relation / path belongs to type A or type B.

So, this really IS "tagging for a renderer," right?

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

Of course it can!  But this isn't a problem, because each region has the ability to say "OUR part of the namespace (e.g. of cycle_network values) means that we use THIS name here, while over there in THAT part of the namespace (e.g. another country, region or locality), we use ANOTHER name.  (Because we can, and appropriately DO, since it has been "carved up" so that these values are understood in any given country, region or locality).  This can only happen as the cycle_network=* namespace has had the time to have its values, for any country, region or locality, agreeably "carved up" into these values (including what I'm suggesting are sub-values that denote PURPOSE of the network in that country, region or locality).  Yet, it appears to remain true that this "work" (early suggestions, development, agreement, consensus) has not happened.

> A simple key 'xyz = A' is required
> and not a key that contains long texts that have to be interpreted.

No, I don't believe this is correct.  You might believe it is true because of the ease with which "a renderer or router can grab this as a simple 'one-off' parsable string and know definitively that THIS is one of THOSE."  But that is the very definition of "syntactic sugar," something I think OSM (and especially participants in this tagging list) wish to avoid.  Scrupulously avoid.  (Hence what feels like one of the longest threads I've ever seen).

> This
> key should also not be region-specific.

Why not?!  It IS region-specific!  We (in the USA) don't have these here.  And why a key, when values will do?

> Therefore an addition to
> 'cycle_network' is necessary, because 'cycle_network' does not meet
> these criteria. I have presented this in detail elsewhere.

As I just asked:  if you have network=generic (for example), a key-value pair that "distinguishes something" (I still don't quite know exactly what), AND you add to that well-designed cycle_network=* values (which ARE region-specific, because they ARE, so therefore they MUST BE), you seem like you have all you need.  I still do not have an answer as to why this would not be true.

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

Use the existing key network (without the sub-key :type, as many agree it is problematic / ambiguous), along with the value "generic."  (I use that as Flips suggested it, it may emerge to be something different).  I'll say again I don't understand why (and I'm certain I'm not alone), but add to that well-crafted cycle_network=* values (it appears to be many, many values in the DE: CH: maybe BE: maybe NL: namespaces) and it appears to me you have exactly what you need.  Especially as the regions / localities have sub-values that denote the purpose of the network.

Done.  Absent a counter-argument to the contrary, I'm not sure what we are discussing any longer.  (Except, what might appear to be a lack of willingness to roll up your sleeves and design good cycle_network=* values — and I mean truly well-thought-out ones — in your part of the world).

Am I STILL missing something?