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

[Peter Elderson]

Node_networks do not use destination based signposting. You recognize Node
networks by their labeled Nodes, and the fact that the Nodes refer to the
adjacent Nodes by their Node labels.

The traffic guidance system for which the proposal suggests an extra tag is
destination oriented signposting over an official selection of ways or
routes. You recognize the ways or routes by their standardized official
guideposts with "destination hands". The next guidepost will show the same
destination as the previous one (and others, in case you need to change
direction by choosing a different destination on your journey. On
junctions, if no direction change to another officially signposted
destination is present, a simple waymark with a logo is present.

So, there is a dedicated system, clearly visible on the road, and it can
therefore be tagged as a collection of route relations. The purpose of the
tagging is to enable data users to highlight or emphasize these selected
roads or routes for end user applications (maps, planners, routers,
navigators). For mapping, it doesn't really matter which purpose the system
itself has, although this purpose certainly will motivate the mappers to
map it, and the users to use it.

Nothing out of the ordinary so far, and it's already being mapped. The only
thing needed is to be able to recognize from the tagging which ways and
routes belong to this Chosen selection. A tag which clearly reflects the
fact that the ways or routes are part of this system of officially and
visibly dedicated guidance system.

Several alternatives have been brought forward. I think it would be best
now to focus on these alternatives, the pros and cons. I am looking forward
to JochenB's new simplified proposal.

Peter Elderson


Op ma 6 dec. 2021 om 11:09 schreef stevea <steveaOSM at softworkers.com>:

> On Dec 6, 2021, at 1:42 AM, Peter Elderson <pelderson at gmail.com> wrote:
> > officially signposted as routes for cyclists, using destination oriented
> signing on official standardized guideposts, and standardized simple
> waymarks between the official guideposts.
>
> OK, that’s clear enough to me, so thank you Peter:  these are “signposted
> as routes."  We have route=bicycle relations in OSM.  These aggregate
> together into networks, the icn/ncn/rcn/lcn conventions were a “rough
> version 1” which sort-of-worked for many (most? certainly not all)
> locations.  They may even work “just fine” in many locations (though I
> would say that using cycle_network with wisely chosen values really
> clarifies things here).  The cycle_network=* tag evolved to more
> specifically denote “which network?” for those route=bicycle relations
> which had multiple networks at any particular level (e.g. more than one
> “national bicycle network” or “regional bicycle network”).  The
> cycle_network tag has had what might be described as slow-to-moderate
> uptake in its usage around the world to do this denotation, but that
> doesn’t mean it is wrong or broken or a poorly-developed or documented tag,
> rather that it has been “not rapid in its uptake.”
>
> These signs seem to denote something much, much closer to a
> network:type=node_network (destination-based, signposted at intersections…)
> than a “standard” route=bicycle.  (Indeed, I understand that the latter
> containing thousands and thousands of ways is unwieldy and difficult to
> maintain, to which I would agree is correct, because the choice of
> implementation is incorrect).
>
> Can we put whatever “this” is into data structures (and concomitant
> tagging) which fits into the paradigm of “routes aggregating together into
> a network(s)” of a relational database?  Already?  Yet?  Please?  With wide
> understanding and consensus?  If it is such a tall order, by all means,
> take the time to design it well (starting with a concept and developing
> that).
> _______________________________________________
> 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/20211206/823f8c3d/attachment.htm>