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

Alan Mackie aamackie at gmail.com
Sat Nov 27 13:50:56 UTC 2021


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/aca59515/attachment.htm>


More information about the Tagging mailing list