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

[stevea]

On Dec 1, 2021, at 3:15 PM, Sebastian Gürtler <sebastian.guertler at gmx.de> wrote:
> 
> 
>> 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?
> Hm, I thought that "tagging for the renderer" (in the negative sense)
> meant to use a tagging for an existing rendering scheme and not the
> introduction of a tag for the future possible use for rendering - that's
> nothing that osm should avoid as rendering geodata into graphics is a
> really useful thing to do imho.
>> 

It's useful, of course.  It can be (somewhat, very...) elegant, or (that's a slippery or) it can be opaque, even obtuse.  I opt for what seems to me to be somewhat elegant, the present scheme with extensions as they seem to fit into existing schema.  We may not even really be that far apart, it's more like the misunderstandings are vast.  (Yes, I might be being obtuse, although I actively avoid being obtuse and seem to be rarely so in the grand scheme of me).

I know it wasn't you but I like the swim trunks analogy.  But, what is "making everybody so cold?"  What are you trying to "solve" so you are warm and snug in your SCUBA suit?  That you built it yourself?  Well, I think I get that, I also get that "the rest of us" seem to swim just fine without it and the water does not seem cold to us.  But we don't bike there, you do.  Why wear such machinery that you build yourself, unless it is a well-structured syntax of data that explain this IN THE DATA (we are a database, after all).  Syntactic sugar makes it only easier to do this.  It can also obscure what are actually structure in the data, but these aren't structured in the data as most or the rest of the world seem to do this, they are tagged with "an easy grab" for a parser or a renderer.  Yes, that is how some things are built, I grant you.  Yet one which seemingly quite vividly (here, among many of us who read and write) seems to remain quite opaque, not fully uttered, not-yet-fully-articulated.  What is so cold?

By somewhere between convention and agreement, all we have are words in the English language.  I am articulate in written English and still cannot grok your concept.  Grok is a word popularized by 20th-century author Kurt Vonnegut, Jr. and means very roughly "understand."  Wherever anything in this mail-list must start, it must start with a concept.  Many, many of us here are quite simply unclear on this concept.

>>> 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?
> 
> basic_network was suggested as value not as a key. The key
> "network:type" is now widely used in Europe, I think initially in the
> Netherlands. Used on 107219 relations so far (compared to 13330 with
> cycle_network), it's beginning to be used also in the USA... (for a
> hiking network in Santa Fe).

I have explained that I do not have a problem with network:type as it describes the unique geographic-geometric mathematical-like-difference between vertex data and line data.  Routes started out as lines (ways) being members of routes, so long as they were contiguous and then we started categorizing these in to four levels of network.  That's fine until vertex networks arrive and that was many years ago.  Apparently, "these" (what is being proposed) are not "those" (what exists in Benelux and New Mexico as node networks, those are fine).

What hasn't yet been fully explained (though we might get closer with hand-waving analogies about SCUBA gear and swim trunks, without actually using words that make sense and aren't an analogy) is the concept.  I hear loud and clear that "a concept" or "something like a concept but hasn't yet been fully developed into a concept" is brewing, bubbling, has a need to burst forth and "be" in OSM.

Start with a concept that can be communicated clearly to the rest of us.  You have to want to "do" something with data, that's why we're here.  Whatever it is you wish to do that "prevents you from such cold water" hasn't been explained.  Oh, and the water seems fine to me, I'm swimming and not cold, and have been for at least a decade here.  There, I said it.

All we have are our words.