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

[Peter Elderson]

Hm.... I used to feel the same way about this difference between routes and destination guideposting. But I have shifted a bit. Not that I'm advocating this proposal, and I am certainly not in favour of using another network:type value, but I understand the reasoning. 

By the way, with "it's up to the mapper" I meant: the mapping community in the area should decide and document how to choose clear start and end points. I think we agree here, that it should not be left to the random individual mapper to indicate start and end points willy nilly. 

It is a fact that between the guideposts, that is, between the guideposts where a direction can be chosen, the traveler does just follow the breadcrumbs, i.e the intermediate waymarkers and guideposts. In this German case, the red and green cyclist logos, and possibly guideposts with only the indication of where you come from and where all cyclists are supposed to go. I think this meets the criteria for being a prescribed route you can put in a route relation, and has clear start and end points. This route is not a network. If people organise collections of these routes in a parent relation, then that parent is a network, not a route.

If defined in this way, a tag to indicate that the guidepost2guidepost route is reflecting the destination-indication on the guideposts, and the way to get to the next one, does not change the route relation to a network relation. It just gives an indication what the route is used for.

Then again, if the same can be achieved and managed by tagging on all the ways in the route what they are used for, also fine with me. I don't think any basic principle of OSM is being breached in both solutions. Unless... the tag on the way does not reflect a visible and verifiable attribute of the way itself, but it's mapped anyway. Then it is on the edge of tagging for the renderer/router.

Peter Elderson

> Op 25 nov. 2021 om 19:53 heeft Sarah Hoffmann <lonvia at denofr.de> het volgende geschreven:
> 
> On Thu, Nov 25, 2021 at 10:46:23AM +0100, Peter Elderson wrote:
>> Journey-Oriented Recreational Traffic guidance is the regular mapping of
>> (mostly) recreational routes in OSM, provided it's
>> visible/verifiable (signposted, waymarked).
>> 
>> 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.
>> 
>> 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.
> 
> Very well said.
> 
> I get the feeling that we are turning circles here because the word
> 'route' is being use ambiguously here:
> 
> The guidepost do not lay out a route, they just give you directions.
> They tell you what potential destinations can be reached in a certain
> direction. They do just help you with doing your own  'routing'. That
> is a very different from the concept of the touristic routes we map
> with type=route: their concept is to follow a certain trail of
> breadcrumbs (aka waymarked symbols) along the way. They really do
> the 'routing' for you.
> 
> Or to put it in different words: for a route, the journey is the
> reason for existence. The basic network is there to help you reach
> a destination.
> 
> I don't think this discussion will go anywhere until we stop trying to
> mix these two very different concepts in the same mapping style.
> 
>> It's up to the mapper how to define begin and end of such routes. 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!
> 
> The arbitrariness you describe here is what bothers me. It is a
> sign that the tagging schema is not well suited for the real world
> concept.
> 
>> 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?
>> 
>> For me, two things are important:
>> 
>> * The tag should not interfere with existing tags (should not require
>> retagging existing route relations)
>> * 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.
> 
> For me, the proposal breaks a very important rule of tagging in OSM:
> do not change the meaning of the main tag by adding a subtag.
> As the proposal stands, adding network:type=basic_network makes
> a network out of what was meant to be a route. It is essentially
> a 'I am not a route' subtag to type=route.
> 
> JochenB, if you cannot be convinced to consider dropping relations altogether
> and concentrating on the lcn=yes tagging style instead, then I'm
> firmly with RichardF: find a different relation type to put the networks
> into.
> 
> Sarah
> 
> _______________________________________________
> Tagging mailing list
> Tagging at openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging