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

[Flips]

Hallo Everyone

I have been following this thread for the last week. At the beginning I thought: 

What a great idea of Jochen! This solves some problems with mapping I encountered the last Years. Why the f*** is stevea insisting so hard, that this is no good solution.


Than after reading some of the last posts, I got an inspiration. Maybe this might solve the problem. 

We do not need the key network:type=basic_network
Instead we need a key like network=base, network=basis or network=generic 

So we will still have the standard key route=bicycle/hiking/... 
And we get an extra key to separate the touristic routes or any other routes (l*n/r*n/n*n/i*n) from the noname/nonumber/nospecialsymbol network.

Each of this new routes contains only the way-segments between two signposts.
This routes can than again be collected in a network-relation like the big one which is now called NRW.

Renderers can than put the lowest priority to this routes and give them a different colour or line-width.

Routing-devices might find a code, so you can choose which routes to follow.

Have a nice evening or afternoon
Urs

Am 27. November 2021 14:50:56 MEZ schrieb Alan Mackie <aamackie at gmail.com>:
>On Fri, 26 Nov 2021, 03:53 Peter Elderson, <pelderson at gmail.com> wrote:
>
>> 1. The proposal that started this thread is being reconsidered/rewritten,
>> as I understand from the author, JochenB.
>>
>> 2. I understand that the core proposal is about tagging that chains of
>> ways have been selected by an authority as preferential for cycling to
>> destinations. On the road this is implemented by destination oriented
>> guideposting using standardized guideposts and standardized waymarking
>> between the standardized guideposts.
>>
>> 3. The aspect that the OP wants to tag is this visible and verifiable
>> official preference and the exact chain of ways between the guideposts.
>> This is different than tagging ways as cycleways or ways fit for cycling.
>> Correct?
>>
>> 4. There are two approaches: 1. tag the ways as officially preferred ways
>> for cycling; 2. add the ways to route relations tagged as officially
>> preferred cycling routes. Both approaches have pros and cons, both are
>> already used in OSM, but both lack the "officially preferred" aspect.
>>
>> 5. icn, ncn, rcn and lcn are used for recreational routes. To me, using
>> that to indicate the "officially preferred" aspect does not seem right.
>>
>> 6. network:type is aimed at a precisely defined network planning and
>> navigating system, not a collection of officially preferred ways. It
>> doesn't seem wise to reuse that for a preference indication for the same
>> transport method over exactly the same ways.
>>
>> All in all, I would welcome a separate tag which does nothing more and
>> nothing less than stating that the object (way, relation or node) is
>> officially preferred for destination oriented traffic guidance.
>>
>
>
>In my (limited) experience trying to add bus route info based on what the
>signs at the stops say I think it is helpful to keep the information as
>local as possible. Physically large relations are not always easy for a
>local to even find if others have only worked on the other end of the
>route. Some sort of ref tag extension to accommodate multiple networks is
>probably much easier for a visiting mapper who isn't focused on travelling
>the whole length.
>
>>
>> Peter Elderson
>>
>>
>> Op vr 26 nov. 2021 om 08:57 schreef Volker Schmidt <voschix at gmail.com>:
>>
>>> LCN, RCN, NCN: the terms have their origin in the UK cycle network, which
>>> is organised and numbered in these three tiers.
>>> In Italy we are transposing this into:
>>> A LCN route is limited to a Provincia, a RCN route to a Regione, a NCN
>>> route connects several Regioni, and an ICN route at least two countries.
>>> The network value does not imply any quality statement about a route, with
>>> other words a NCN route is in no way "better" than a RCN route.
>>> In that sense I would not use LCN to describe the general cycling
>>> infrastructure like cycleways or cycle lanes.
>>> Some short LCN routes can look spectacular, large and with huge
>>> signposts, whereas one of the longest NCN routes in Italy, for example, is
>>> signposted with small stickers only (https://www.aidainbici.it/) and
>>> best followed using its GPX track.
>>>
>>> On Fri, 26 Nov 2021, 02:48 stevea, <steveaOSM at softworkers.com> wrote:
>>>
>>>> "Around here" (California, USA...) we see the green-colored "Bike Route"
>>>> sign (those words below a glyph of a bicycle) and we tag lcn=yes.  Either
>>>> on the way or on the route that contain these road / path / way elements.
>>>> We call this "very loose collection of infrastructure" (not always, in fact
>>>> MOST of the time, NOT a route relation, but possibly expressed that way) a
>>>> "Class III" (three, 3) bike route.  (Class II is painted-on-the-road-edge
>>>> cycleway=lane and Class I is highway=cycleway).  And that is INFRASTRUCTURE
>>>> tagging, not necessarily route tagging (though we say it's OK if sometimes
>>>> Class III routes are created  — though, importantly, the collection of
>>>> those isn't known here as "a network," whether that is "basic" or by any
>>>> other name).
>>>>
>>>> We document this in our wiki I footnoted earlier (US Bicycle Networks),
>>>> though that's USA.  But it works, "continent wide" as it were.  I don't
>>>> know if Canada uses a similar (MUTCD D11-1) sign, which OSM documents as
>>>> "generic" (bike route), so I'm heartened that "generic" as we call it is
>>>> similar to what you propose calling "basic."  Rarely, as I might imagine
>>>> here, we COULD call the collection of ways tagged with "simply" lcn=yes "a
>>>> network."  A rarely again, I think, when we collect what might have once
>>>> been a bunch of ways tagged lcn=yes and put that tag on a type=route
>>>> relation (with route=bicycle), then it's OK to remove that tag from the
>>>> individual ways.  But the majority of time (I believe, a continental OT
>>>> query would dim the lights at the server farm) I wouldn't say so; we "more
>>>> simply" put lcn=yes on the ways.  But I don't want to prevent you from
>>>> doing so, and maybe saying "noname=yes" if/as that makes sense (I think it
>>>> might) and sure, add some cycle_network=* tagging here, too, it seems a bit
>>>> overdue to offer some clarity to our community.
>>>>
>>>> So, do so ("utter" into OSM this concept of basic_network, and others
>>>> like it), but please don't do so with network:type (=basic_network, or any
>>>> other value in this sub-key of network).  Because it really, really is
>>>> confusing to say this is a "type of network."  In multiple, different,
>>>> ultimately confusing ways.  We (in the USA) don't think of this
>>>> "collection" as a network, or only quite rarely, as here, like as the
>>>> "academic exercise" I feel like I'm engaging in here and now.  You might
>>>> choose to do so in Europe, that's fine by me, please use a syntax other
>>>> than what is proposed.  There are some possible suggestions that have been
>>>> tossed out there, I listen and consider.  Clearly, many others listen (and
>>>> participate here — good!), also.
>>>>
>>>> We're making sausage here, everybody.  It isn't always pretty.  It seems
>>>> to me there is good progress and remains some distance to go.
>>>> _______________________________________________
>>>> Tagging mailing list
>>>> Tagging at openstreetmap.org
>>>> https://lists.openstreetmap.org/listinfo/tagging
>>>>
>>> _______________________________________________
>>> Tagging mailing list
>>> Tagging at openstreetmap.org
>>> https://lists.openstreetmap.org/listinfo/tagging
>>>
>> _______________________________________________
>> Tagging mailing list
>> Tagging at openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/tagging
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/tagging/attachments/20211127/7c000f83/attachment-0001.htm>