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

[Sebastian Gürtler]

Am 28.11.21 um 12:03 schrieb Peter Elderson:
> Sebastian Gürtler:
>
>     Maybe I would change the description to "stating that the object
>     is officially marked for destination oriented traffic guidance" to
>     emphasize that only "tagging what is on the ground" is meant.
>
> If there is no ground truth, we shouldn't map, I hope we all agree on
> that!
>
>     And one should have in mind that in Germany this will result in a
>     100% overlap with the numbered node network, so it would be easy
>     just to put the tag in the superrelations of the "node networks"
>
> The Node networks do not use superrelations. I think you mean the
> network relations? The network relations are not mandatory, the Node
> network system works fine without them. So it would not be wise to
> count on them for a different purpose. I would prefer sticking to
> tagging either the ways or the route relations as "officially
> preferred and marked on the ground with destination oriented
> signposting".
I meant the network relations, I didn't know that they aren't mandatory,
and it would get quite complicated to maintain it with the help of
knooppuntnet.nl without the network relations (despite the fact that in
Germany in fact these are collections - in NL the regional network name
is printed on the posts I think, in Germany it is not...). Maybe the
wiki Cycle node network tagging
<https://wiki.openstreetmap.org/wiki/Cycle_Node_Network_Tagging> needs
an update?
>
> If the Node2Node routes are exactly the same as the "officially
> preferred cycling" routes, you could reuse. But I don't think so, even
> in Germany. Not every guidepost is a Node network Node.

> Also, maybe the cycling Nodes in Germany are always on the official
> guideposts, but for other forms of transport this is not the case.

Yes, that is only for the cycling network.

> In addittion, recreational routes including Node2Node routes tend to
> use different paths than destination-oriented routes.

- my point is that they use the same interim guideposting and are not
distinguishable without the guideposts on the nodes/branches.

> I think even in Germany you would run into many, many exceptions there!
Getting less - in the last decades many municipalites created their own
systems which are now reduced step by step. Here in the region you only
have small traces of it.
> But, you could say as a rule, that if and when a destination oriented
> route is exactly the same as a Node2Node route, you can use one
> relation tagged for both purposes; network:type=node_network for the
> Node nodwork and a different tag saying the relation also counts as a
> destination based route.
Yes, this I would suggest.
>
> Personally, I would prefer not to map this destination based routing
> in areas where a full Node network system exists. But that preference
> probably biased by the Dutch situation, where one basically can count
> on roads being cyclable or having cycleways at the side, with
> destination based signposting everywhere. Mapping and rendering the
> "basic network" would simply show every cyclable way you can think of.
>
The situation is really different in Germany... I can imagine that it
wouldn't make sense in the Netherlands. I can characterize just the
situation in my area, where the additional ways to the named routes and
the node network are not too many.

Just for the city of Bielefeld which I checked completely, the green
routes are the numbered node network, the red routes are "basic
network". The thinner lines are named recreational routes.

As you see the recreational routes sometimes leave the numbered node
network and run over the other ways (e.g. in the north east, north of
node 81). These parts of the route have to be distinguished from
recreational routes from private operators that don't follow the
official guidance system. So I also mapped these sections as
basic_network. (I could prepare a map of the district of Herford where
you need to make these distinctions).

You can see that these red routes have different functions: In the
northwest to get from 29 to 6 or from 31 to 33 you can leave the
numbered node network and take short cuts. I think the wanted just to
reduce the number of nodes to reduce the complexity of the network. Then
you have other routes that just follow big streets as quite fast ways
(in the south from about 70, crossing the 19-17 connection) or from a
point near the 78.

Some other routes are connections to the neighbouring districts without
numbered node network (in the south west from 43 and 33), mainly not
intended for the everyday traffic but more intermediate distance
recreational bicycle trips (still destination orientated, often
touristic destinations).

Sebastian

PS: while struggling with the image ;-) new mails...


Am 28.11.21 um 15:57 schrieb Martin Koppenhoefer:
> Am So., 28. Nov. 2021 um 01:52 Uhr schrieb Brian M. Sperlongano
> <zelonewolf at gmail.com <mailto:zelonewolf at gmail.com>>:
>
>     It seems that the challenge here is that you have all of these
>     cycling ways which are certainly part of an interconnected
>     network, though they are not part of any named and numbered route.
>
>     I see this as very simple - we have a tag for this,
>     network=lcn[1].  These ways are all part of a local cycling
>     network, so tag them that way.
>
>
>
> According to the wiki, the tag lcn=yes is intended for "Designates
> that a road or path is part of a local Cycling Network route", i.e. it
> must be part of a _route_.
>
> Still we could have a tag bcn with a slightly different definition
> ("is part of the basic cycling network" without the "route")
>
> https://wiki.openstreetmap.org/wiki/Cycle_routes
> <https://wiki.openstreetmap.org/wiki/Cycle_routes>
>
> Cheers,
> Martin
@ Brian: with the tag lcn you can't differentiate the official network
with the special rules for guideposting from many other local routes
that follow no official rules, sometimes only very sparsely blazed with
paint on trees and so on (e.g. the Terra-Trails
<https://cycling.waymarkedtrails.org/#route?id=2168153>).

@Florian:
All suggestions introduce new tags or keys, which is in my opinion too
much change to the tagging. Even the initial proposal
network:type=basic_network doesn't add a new key, network:type has to be
considered as well established, at least in Europe, even with only one
value so far. The taggings need not sound logical and nice if spoken
aloud, the main thing is that they fit logically and consistently into
the existing database.


guidance=destination_oriented; conflicting with rare but existent
guidance=magnet (which is not quite good in the used place...)
orientation=destination... Wiki: "Indicates the orientation of the
feature with respect to the flow of vehicles or passerby"
purpose=destination: too general, just look into the taginfo what
happens to such a key... you have the following values: 1. adoption, 2.
study_spot, 3. picnic" would be funny to add "destination"...
destination_oriented=yes - comes closest to what I think...

I'd prefer less invasive tags using some preexisting structure of the
osm "syntax".

@Martin:bcn would be probably also a possibility, I admit that I dislike
these xcn tags as here in the area it is very randomly how they are
used. And the distinction betwen local, regional, national,
international is a spatial categorization, bcn gives information in
another category.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/tagging/attachments/20211128/73052ebe/attachment-0001.htm>