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

Sun Nov 28 00:28:22 UTC 2021

Am 25.11.2021 um 18:38 schrieb Volker Schmidt:
>
>     Journey-Oriented Recreational Traffic guidance is the regular
>     mapping of (mostly) recreational routes in OSM, provided it's
>     visible/verifiable (signposted, waymarked).
>
>
> agreed, if "journey-oriented"  means "touristic"

I would not commit myself to "touristy". It can also be a sport route
for mountain bikers or racing biking or a short hiking route at a
rehabilitation clinic, then it would be for a medical purpose.

In some large cities there are numbered routes for everyday traffic,
e.g. in Frankfurt am Main. Everyday cyclist should make particularly
good progress there.

That's why I would rather stick to route-oriented or route
recommendation, because the routes can be recognized directly from the
associated symbols.

>
>     Destination-Oriented Everyday Traffic guidance for most forms of
>     transport is not usually mapped in OSM. Fact is that it's
>     present/visible/verifiable in most countries. So yes, it can be
>     mapped.
>
>
> agreed if "destination-oriented" means "efficient"

Efficient can mean many things and is not very tangible. The shortest
route, the fastest route, the best road surface, the fewest inclines,
the least risk of congestion, the least headwind ... . The person who
planned the signs is guaranteed to understand something different than
you. You guarantee something different from me.

>
>     It really does not matter whether the physical signs are on
>     integrated guideposts or separate posts or a mix. It's about what
>     they provide for the traveller: where to go, where to ride, what
>     way to use, how to get to the next clue.
>
> (what are "integrated signposts"?)

https://wiki.openstreetmap.org/w/images/5/54/Guidepost_basic_network_and_node_network_and_route_recommendation.jpg

>
>     In my view, the guideposts mark the route to take, not the
>     physical ways. The physical ways can be / often are completely
>     unmarked for this purpose.
>
> Hmmm.
> So far I have always tagged ways as defining the journey-oriented
> hiking or cycling routes by making them part of the route relations.
> Sometimes I included signposts, but as a technical convenience, not
> for routing purposes. And as far as I know routers/navigation devices
> can "digest" that kind of routes.

The signposts and intermediate signposts contain the information which
ways are part of a route (direction of the signpost, name of the
destinations, direction and shape of the arrow symbols). This cannot be
read from the ways themselves outside. Machines, however, are not able
to map the information from the signposts to the ways. That's why we do
it ourselves using relations or tags on the paths.

It's not 100% "on the ground", but that's the only way it works. It is
the same with almost all other route relations.

>
>     It's up to the mapper how to define begin and end of such routes.
>
> Depends on the type of route: bi-directional A <> B routes are the
> most frequent topology (where typically A>B and B>A do not use exactly
> the same ways - there may be oneway stretches that are tagged by
> forward/backward role tags. Most of these linear routes can be used
> both ways and the mapper is free to decide whether A or B is the start.
> In case of circular routes the mapper is normally free to pick a
> beginning for the list ways in the relation.

I think it means how to cut the individual connections from a net
(mesh). In a node network, this is hard-defined: The connections always
end at the next numbered node.

There are no numbered nodes in the basic network, so you could also map
several connections in a relation, as long as it results in a continuous
line without branches. This is particularly useful when two network
nodes are close together so that there would be relations with only one
member.

>
>     Mapping all destinations to all other destinations is not very
>     practical. In this case, mapping Guidepost2Guidepost seems
>     feasible, and could cover the whole system of destination oriented
>     traffic guidance wherever it occurs and whatever form it takes.
>     It's a hell of a job, but if people want to do it, be my guest!
>
> Is that not called Cycle_Node_Network_Tagging
> <https://wiki.openstreetmap.org/wiki/Cycle_Node_Network_Tagging> ?

Yes, but it is only a node network if it is combined with a certain type
of signposting. It is defined that nodes outside have clearly visible
numbers/refs and only the number of the neighboring node is shown at
each node.

This is often combined with the basic network, where named destinations
are shown. However, these do not name the next node in the network, but
rather the nearest and more distant locations.

>
>     Nothing new so far, all of this is being done already. Nothing is
>     invented here. So what's new?
>
>     If you want to enable data users to provide special handling of
>     destination oriented routes, different than how recreational
>     routes are handled, the relations need a tag to make that possible.
>
> That is the point I have in mind.
>
>     So, why not limit the discussion (and the proposal from which it
>     sprouted) to which tag would be appropriate to distinguish
>     destination oriented routes from recreational routes?
>
> YES

Yes, but please do not use the tourist use as a distinguishing feature,
but rather the route recommendation characteristic, see above.

>
>     For me, two things are important:
>
>     * The tag should not interfere with existing tags (should not
>     require retagging existing route relations)
>
> obviously, but this requires a re-definition of the existing cycling
> or hiking routes.
> Unfortunately we cannot be sure that all existing routes are
> "journey-oriented"

We can decide that route-oriented is the standard, which in large parts
of the world is the only form of cycling and walking routes.

>
>     * The tag should be generic, i.e. applicable to all modes of
>     transport, in all countries, and all geographic scopes. It
>     indicates a purpose. The other aspects are already present in
>     other tags.
>
> OK also for this. This would also solve the distinction of tagging for
> "Route Nationale xyz" and "Route du vin en Roussillon".
>
> Now let's define the tags and make the whole thing a proposal
>
>   * journey-oriented, touristic, recreational. ...
>   * destination-oriented, efficient, commuting, ...
>
I also first thought of

    'signposting=destination'

but the example from California shows that these connections do not
necessarily have to have destination-oriented signposts. Sometimes it's
just a sign with a bike on it, without a destination sign. That’s a lot
cheaper. Only a few administrations have a big cycling budget.

So my next thought was

    'route:purpose=basic_network'
    'route:purpose=route_recommendation'

or simply:

    'basic_network=yes'
    'route_recommendation=yes'
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/tagging/attachments/20211128/22a33228/attachment-0001.htm>