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

[Volker Schmidt]

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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/tagging/attachments/20211126/3e7a2fc3/attachment.htm>