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

[stevea]

On Dec 1, 2021, at 3:17 PM, JochenB <JochenB at wolke7.net> wrote:
> Am 01.12.2021 um 23:05 schrieb stevea:
>>> 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?
> When I tell a freeway per tag that it is a freeway, I do that so that
> the render can show the freeway as a freeway. So we all tag for renderers
> 
> It is reprehensible to tag a dirt road as a motorway because it looks
> better on the map.

You get what I'm certain is wide disagreement here.  You get here because of correlation, but not causation.  Renderers are correlated to the data, but their existence isn't the reason for the data:  a renderer displaying a datum or many data is not causation of those data.  It IS evidence the data are correct, at least through the (possibly narrow) lens of how that renderer chooses to render certain data (possibly ignoring other data, including what is proposed).  So, what doing what you're proposing, especially as other alternatives may well exist, is called "breaking the present" with a proposal for the future.

If that can be done already, especially as "what you are trying to do" fits into the current schema, I and I'm certain others here might have something to say about that.  Indeed, many of us have and do.

Tagging a freeway a freeway (as we do it, with the tags we've agreed "do so" semantically, NOT for any particular renderer) is done in OSM because "that's how we do it here."  You might think of THAT as one of the "Prime Directives" of OSM.  We don't have a lot of rules around here (there are a few, all of the good), but that one is right at the top of the list:  we are a database, a repository of correct data.  (Well, mistakes can and do sneak in, but we do well at catching most, maybe even close to all of them early and often).

I'm not calling your proposal a mistake.  "Incomplete as to a concept clearly stated," yes.  I've read it, we've done a lot of typing and some us here might even believe we're closer to a solution (maybe generic, maybe you wear some swim trunks like the rest of us do, we can squint maybe and perhaps read the cycle_network tag with some regional mumbo-jumbo (to me, as a foreigner, but make sense to them, after all, they invented it for themselves)"somewhere in this country's mess of bicycle networks — I'm sure with some quick study of their sensible hierarchy I can make sense out of it when I go biking there, after all, that's the whole point of whipping up multiple bicycle networks, to make things easy, 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).
> 
> I do not believe that a majority prefer to hide a simple property in a
> key, the content of which is designed differently in each region, in
> which freely defined names are separated from one another and put in
> order with a colon, the key names of which do not infer the property and
> where a data evaluator first has to program regionally specific special
> loops in order to filter out the individual property from many different
> types of information.

Well, we have "differently designed in every region around the globe namespace to describe cycle networks" namespace.  It is in your (regional) cycle_network=* namespace.

> With every line in which you advertise the 'cycle_network' it becomes
> clearer to me that 'color=green' is better than 'xxx_network=yyy:green:zzz'

Green is a single English word to describe a specific concept.  The fact that it is a unique value standing for a unique value of "color" is good, because we agree "color=green" is a useful to describe an attribute of a value for something that has a key people agree on (like color, because color is much more than a concept it is something well-established).

A specific sub-or-basic-network of maybe node-based bicycle signposts which indiscriminately (apparently, I see no structure fully articulated) yet insistently are said to be a certain kind of a route that are members of a not-well-specified network or network of networks?  Whoa, my friend, that's a concept you'll need to better articulate to the rest of us.  That isn't something well-established AT ALL.  So your analogy to a color just doesn't fly.  And maybe, after all, it actually IS cycle_network=DE:yyy:ThisKind:zzz.  I don't find that terrible at all, even if you do.

> 
>>> 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?
> 
> Why do we tag motorways around the world with the same tag, we could do
> it differently in each country?

Because it makes sense for the whole world to agree on how we tag such relatively simple things as road networks.  Whether cars, pedestrians, bicycles or horses use them.  We've done OK at it for going on two decades now.