Re: [Tagging] Feature Proposal - RFC - (Hierarchies route=bicycle)

[Paul Allen]

On Sun, 20 Jan 2019 at 11:05, Axelos  wrote:

[footpath/bridleway fingerposts]

>
> I have already seen this type of symbols, but never added in OpenStreetMap.
>

There's no defined tag for them (or I can't find it).  Which makes adding
them to OSM
difficult.

Always on destination=*, there is the alternative relation that offers ideas
> (https://wiki.openstreetmap.org/wiki/Relation:destination_sign#Tags and
>
> https://wiki.openstreetmap.org/wiki/Proposed_features/Destination_details#destination:symbol
> ).
>
> Maybe to be inspired?
>

Sadly, neither of them work for footpaths/bridleways.  Nor for the other
problem I posed, that
of fingerposts with multiple arms in different directions.

The destination relation isn't a standalone, but has to be part of a route
(if I understand
the page correctly).  The fingerposts with multiple arms I'm thinking of
indicate that the
library is in one direction, the swimming pool another and the tourist
information centre
another.  They're not (necessarily) on a bus/cycle/hiking/walking route,
they're just
telling tourists the direction to certain POIs.  If you have OSM you don't
need the signs
to find those POIs, but knowing the location of such a sign helps confirm
your position
when GPS isn't getting a lock.

The icons for destination signs are interesting, but not really
applicable.  Because the
walking man icon or horse icon on the fingerpost isn't a destination.  The
hospital icon
shows "This way to the hospital."  The walking man says "this is a
footpath."  Again, with
OSM you already know it's a footpath, but the presence of the sign confirms
your position
or tells you that you should be looking for such a sign.  Quite often there
are two adjacent
gets or two adjacent tracks and the presence of the sign tells you which
one to use.

It seems to me that it's useful to map these fingerposts but that we don't
yet have a way
of doing it.

-- 
Paul
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - RFC - (Hierarchies route=bicycle)

[Axelos]

Hello Paul,


Paul Allen wrote
> On Mon, 14 Jan 2019 at 10:38, Axelos 

> axelos@

>  wrote:
> 
> The direction signs are a real problem. An alternative solution is to
>> exploit the destination key
>> https://taginfo.openstreetmap.org//search?q=destination%3Abicycle
>>
> 
> However, it's an incomplete solution.  Around here, official cycle routes
> have fingerposts
> which show a bicycle icon and the number of the route.  It's not a
> destination, just an
> indication that cycle route 82 is along a particular direction.
> 
> Similarly, the UK has many public footpaths and bridleways.  Where they
> join a highway there
> is usually a fingerpost with an icon of either a walking person (footpath)
> or a horse (bridleway).
> No destination is given.  It's useful to indicate, in some way, that these
> are signs for
> footpaths or bridleways so that people know what they're looking for when
> navigating.

I have already seen this type of symbols, but never added in OpenStreetMap.

Always on destination=*, there is the alternative relation that offers ideas
(https://wiki.openstreetmap.org/wiki/Relation:destination_sign#Tags and
https://wiki.openstreetmap.org/wiki/Proposed_features/Destination_details#destination:symbol).

Maybe to be inspired?

Regards, Axel.



--
Sent from: http://gis.19327.n8.nabble.com/Tagging-f5258744.html

___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - RFC - (Hierarchies route=bicycle)

[Richard Fairhurst]

Axelos wrote:
> ID is not suitable for this type of contribution (relations), he knows 
> how to do it, but in a superficial and irrelevant way.
> It's not up to OSM to adapt to ID, but the opposite. Since it is not 
> up to OSM to adapt to opencyclemap but the opposite (ref = icn). 
> Potlach 2 in 2019 is a joke!  It is an outdated publisher requiring
> dangerous technology (Adobe).

Maybe don't start editor flamewars on the tagging@ list? Use another list
for that please, like, I dunno, dev-null@, or maybe a list which isn't
administrated by me and is ideally written in a language I can't read.
Thanks.

Richard



--
Sent from: http://gis.19327.n8.nabble.com/Tagging-f5258744.html

___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - RFC - (Hierarchies route=bicycle)

[Paul Allen]

On Mon, 14 Jan 2019 at 10:38, Axelos  wrote:

The direction signs are a real problem. An alternative solution is to
> exploit the destination key
> https://taginfo.openstreetmap.org//search?q=destination%3Abicycle
>

However, it's an incomplete solution.  Around here, official cycle routes
have fingerposts
which show a bicycle icon and the number of the route.  It's not a
destination, just an
indication that cycle route 82 is along a particular direction.

Similarly, the UK has many public footpaths and bridleways.  Where they
join a highway there
is usually a fingerpost with an icon of either a walking person (footpath)
or a horse (bridleway).
No destination is given.  It's useful to indicate, in some way, that these
are signs for
footpaths or bridleways so that people know what they're looking for when
navigating.

Also, the town where I live relies heavily on tourism.  Several months ago
it installed four
fingerposts pointing to various destinations within the town.  I've
currently handled those in
the description but it's a very clunky way of doing it.  See, for example.
https://www.openstreetmap.org/node/5995875128 and
https://www.openstreetmap.org/node/6201876775

I would welcome some way of tagging those meanings on
information=guidepost.  Maybe, as
part of figuring out the best way to handle destination signs, we could
also consider those issues.

-- 
Paul
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - RFC - (Hierarchies route=bicycle)

[Axelos]

Hello,


Richard Fairhurst wrote
> Axelos wrote:
>> Hello, I propose a concept for contributing cycling route.
> 
> From the description on the wiki page, I'm not sure how your proposal
> differs from the practice documented at
> https://cycling.waymarkedtrails.org/help/rendering/hierarchies . Could you
> explain the difference?

It's the same concept.  The idea is to document the practice on the OSM Wiki
and not just on a third-party website (no matter how good).


>> Example name = Boucle de la Moselle: Toul - Pompey
> 
> Please don't do this - the name tag is for an object's commonly agreed
> name,
> and "Boucle de la Moselle: Toul - Pompey" is not the official name of any
> part of the route. You could perhaps use the description= or note= tag
> instead.
> 
> There are lots of examples of this in your proposal: "name=PAN Segment 1",
> "name=Véloroute 50 : Étapes", and so on.

Indeed this type of information can be indicated in "description".  However,
the relation of the hierarchies consists in linking the different relations
of the same route in a single relation.  The end user only sees this single
parent relation, the "superroute".  So, to indicate this type of information
in the relations child in the field "name" represents a real problem?


>> To do this effectively, you will need a powerful editor: JOSM.
> 
> This is a "tagging smell" (cf https://en.wikipedia.org/wiki/Code_smell).
> Any
> tagging scheme that requires a particular editor is probably a bad scheme.
> 
> As it happens, you can certainly edit relations like this with Potlatch 2
> no
> problem and I guess you can with iD too; but before any tagging scheme
> like
> this is adopted, you should create a tutorial for iD users. It shouldn't
> be
> necessary to learn a whole new editor just to be able to tag a bike route
> -
> as you yourself say, "Is the hierarchy of cycle routes reserved for
> experts?". Bear in mind too that iD users _will_ edit these routes, so the
> scheme should be intuitive and robust (of course, that should be the case
> anyway!).

In general, contributing to relations on openstreetmap (cycle, bus,
boundaries) requires a minimum of knowledge.  This is not like indicating
the location of a bench.
ID is not suitable for this type of contribution (relations), he knows how
to do it, but in a superficial and irrelevant way.
It's not up to OSM to adapt to ID, but the opposite. Since it is not up to
OSM to adapt to opencyclemap but the opposite (ref = icn). 
Potlach 2 in 2019 is a joke!  It is an outdated publisher requiring
dangerous technology (Adobe).

There is a distinction between being "expert" and being "voluntary". Using
JOSM is not just for "experts" but for people who want to go beyond
representing benches! I caricature.

Regards.



--
Sent from: http://gis.19327.n8.nabble.com/Tagging-f5258744.html

___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - RFC - (Hierarchies route=bicycle)

[Axelos]

Hello,


voschix wrote
> 1) The problem exists in the same way also for other routes like:
> route=road|foot|hiking|bus|trolleybus|tram|mtb|
> So the wording has to be reviewed under this aspect

Exactly, I have already made the same reflection on bus routes that take the
same path over long distances.


> 2) There is an unresolved issue with bicycle routes, i.e. that, variants
> apart, in most cases a cycle route between A and B uses a different chain
> of ways different in the direction A > B form the route B > A (due to
> things, like roundabouts, one-way streets, one-way cycle paths that are
> mapped as separate ways in OSM, and possible others). The only logically
> clean solution is to have two separate relations for the two directions
> under a super-relation. But none of the (many) cycle route relations I
> know
> follow this model. The usual approach is to include all ways in the same
> relation and use the forward|backward roles on the ways that differ. The
> consequences for the hierarchy model need to be looked at.

I think that creating two relations, one for each direction is not necessary
for a mode of travel such as cycling. This is also the case for walking. 
The needs are not the same as for public transport (bus, tram, train);  who
are obliged to follow their itineraries and their senses, and have hourly
constraints.

3) There is a tendency to include signposts in the relations. This has a
number of open issues of its own.
3a) with the one-relation-per-direction scheme the signposts that have
information for both directions, do they belong to the super-relation or do
they have to be included in both child relations?
3b) In case of more routes sharing the same string of ways, many signs
(referring to different routes) share the same physical support, i.e. they
should be tagged on the same node.


The direction signs are a real problem. An alternative solution is to
exploit the destination key 
https://taginfo.openstreetmap.org//search?q=destination%3Abicycle

Regards.



--
Sent from: http://gis.19327.n8.nabble.com/Tagging-f5258744.html

___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - RFC - (Hierarchies route=bicycle)

[Peter Elderson]

Well, I regularly edit and maintain a lot of routes, route hierarchies and node 
networks. Id is fine for a few basic things, adding and editing tags, combining 
two routes in a superroute. Now try checking and sorting routes from hundreds 
up to thousands of members, including forward and backward roles. Try cutting a 
way belonging to 10 different routes and route systems, then repair the damage. 
I have tried very hard to do  this with Id. Try splitting an old unmanageable 
damaged hiking route into manageable and reusable parts, each complete, sorted, 
and fitting together end-to-start. Try checking and repairing a node network. 

I have checked the capabilities of P2. As with Id, basic things are possible: 
add, edit a member, edit tagging, as long as it stays simple and not too big. 
If it’s more complex, involves sorting and error checking/repair of multiple 
routes, networks, hierarchies: If anyone does a lot of work like that in Id or 
P2, I would like to know how, so I could do more work online. 
Let’s start with sorting the members of a route relation containing 300 
members. How would you do that in P2? 


Mvg Peter Elderson

> Op 3 jan. 2019 om 16:25 heeft Andy Townsend  het volgende 
> geschreven:
> 
>> On 03/01/2019 14:37, Peter Elderson wrote:
>> What about the same question without the “easily”?
> 
> I occasionally (especially with a DWG hat on) have to modify relations on a 
> member-by-member basis, and depending on what exactly what you want to do, 
> JOSM, P2 or something else might be the best for the job - but both* can edit 
> relations member-by-member and create and edit the sorts of things that 
> you're talking about here (see e.g. 
> https://api06.dev.openstreetmap.org/relation/4304873944 ).  Whether that to 
> you is "easily" I can't answer though - you'd have to try it yourself.
> 
> Best Regards,
> 
> Andy
> 
> * as can iD I suspect - I can certainly edit the (relation) members and tags 
> of the example above.
> 
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging

___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - RFC - (Hierarchies route=bicycle)

[Andy Townsend]

On 03/01/2019 14:37, Peter Elderson wrote:

What about the same question without the “easily”?


I occasionally (especially with a DWG hat on) have to modify relations 
on a member-by-member basis, and depending on what exactly what you want 
to do, JOSM, P2 or something else might be the best for the job - but 
both* can edit relations member-by-member and create and edit the sorts 
of things that you're talking about here (see e.g. 
https://api06.dev.openstreetmap.org/relation/4304873944 ).  Whether that 
to you is "easily" I can't answer though - you'd have to try it yourself.


Best Regards,

Andy

* as can iD I suspect - I can certainly edit the (relation) members and 
tags of the example above.


___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - RFC - (Hierarchies route=bicycle)

[Peter Elderson]

First point: you are right and again, I am sorry.
Second: What about the same question without the “easily”?

Mvg Peter Elderson

> Op 3 jan. 2019 om 13:10 heeft Richard Fairhurst  het 
> volgende geschreven:
> 
> Peter Elderson wrote:
>> Sorry, I assumed Potlatch would work approximately similar to Id. 
> 
> If you're addressing a mailing list with 551 subscribers, could I suggest
> you take a few minutes to actually research your statements before posting?
> 
>> Can it easily sort/reverse ways within relations, move elements 
>> between relations, create and manipulate superroutes, and keep 
>> all the routes (hiking, cycling, PT) happy when removing/splitting/
>> extending ways?
> 
> Potlatch 2 can create and edit relations of any type and with any members
> permitted by the OSM API.
> 
> You now appear to have changed from "Can't be done" to "Can it easily",
> which is a different, subjective question and frankly not one I can be
> bothered to answer.
> 
> Richard
> 
> 
> 
> --
> Sent from: http://gis.19327.n8.nabble.com/Tagging-f5258744.html
> 
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging

___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - RFC - (Hierarchies route=bicycle)

[Richard Fairhurst]

Peter Elderson wrote:
> Sorry, I assumed Potlatch would work approximately similar to Id. 

If you're addressing a mailing list with 551 subscribers, could I suggest
you take a few minutes to actually research your statements before posting?

> Can it easily sort/reverse ways within relations, move elements 
> between relations, create and manipulate superroutes, and keep 
> all the routes (hiking, cycling, PT) happy when removing/splitting/
> extending ways?

Potlatch 2 can create and edit relations of any type and with any members
permitted by the OSM API.

You now appear to have changed from "Can't be done" to "Can it easily",
which is a different, subjective question and frankly not one I can be
bothered to answer.

Richard



--
Sent from: http://gis.19327.n8.nabble.com/Tagging-f5258744.html

___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - RFC - (Hierarchies route=bicycle)

[Peter Elderson]

Sorry, I assumed Potlatch would work approximately similar to Id. Can it
easily sort/reverse ways within relations, move elements between relations,
create and manipulate superroutes, and keep all the routes (hiking,
cycling, PT) happy when removing/splitting/extending ways?

Op do 3 jan. 2019 om 12:44 schreef Richard Fairhurst :

> Peter Elderson wrote:
> > I just did some work on a hierarchy of hiking routes. Can't be done with
> > Id or Potlatch
>
> What specifically can't be done in P2?
>
> Richard
>
>
>
> --
> Sent from: http://gis.19327.n8.nabble.com/Tagging-f5258744.html
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>


-- 
Vr gr Peter Elderson
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - RFC - (Hierarchies route=bicycle)

[Richard Fairhurst]

Peter Elderson wrote:
> I just did some work on a hierarchy of hiking routes. Can't be done with 
> Id or Potlatch

What specifically can't be done in P2?

Richard



--
Sent from: http://gis.19327.n8.nabble.com/Tagging-f5258744.html

___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - RFC - (Hierarchies route=bicycle)

[Peter Elderson]

I just did some work on a hierarchy of hiking routes. Can't be done with Id
or Potlatch, the only available tool is JOSM and even with JOSM you'll have
to do extra steps not to break things.
Reverse is seldom a problem with hiking. Nevertheless, one iwn uses some
sections of a national trail (which in turn is built of three parts, which
in turn are built of ca 10 sections each covering about one day's walking
distance). The basic direction of the common  sections is reversed for this
iwn. I did not use roles, but simply took reversed copies of the sections
and used those for the iwn.

For biking, roles forward and backward are used on ways in the route
relation, because there's a very limited amount of ways where the forward
and backward route actually differ.

Indication of continuity in higher level routes, could be handy when
sectioning a large single route, but often variants are included,
shortcuts, extra loops, branches...

Op wo 2 jan. 2019 om 19:17 schreef Jo :

> The existing scheme for tagging cycle routes is robust. The problem I see
> when 'reusing' it in a hierarchy of routes, is that we would need a role to
> indicate that the sub route is traversed in reverse for a particular
> "super" route. It would also help to have an indicator in JOSM to indicate
> continuity in the super route IF the sub route is continuous AND the last
> node of the way / relation before it is the first of the sub route's way
> AND the same applies for the last waynode in the sub route and the next way
> / route in the superroute.
>
> iD is not ideal for working with route relations. It could be changed,
> obviously, if a developer can be found who wants to dedicate to such a
> task, but at the moment JOSM is your best bet to have a reasonable
> experience working on such routes. For now we're already glad if iD doesn't
> break the route relations.
>
> Polyglot
>
> On Wed, Jan 2, 2019 at 6:39 PM Richard Fairhurst 
> wrote:
>
>> Axelos wrote:
>> > Hello, I propose a concept for contributing cycling route.
>>
>> Many thanks for looking at this - the current state of bike route
>> hierarchies is a mess, and trying to parse the many different tagging
>> practices so that cycle.travel can display them properly has been a
>> nightmare. It would be good to have a commonly agreed, intuitive standard.
>>
>> From the description on the wiki page, I'm not sure how your proposal
>> differs from the practice documented at
>> https://cycling.waymarkedtrails.org/help/rendering/hierarchies . Could
>> you
>> explain the difference?
>>
>>
>>
>> A few passing comments:
>>
>> > Example name = Boucle de la Moselle: Toul - Pompey
>>
>> Please don't do this - the name tag is for an object's commonly agreed
>> name,
>> and "Boucle de la Moselle: Toul - Pompey" is not the official name of any
>> part of the route. You could perhaps use the description= or note= tag
>> instead.
>>
>> There are lots of examples of this in your proposal: "name=PAN Segment 1",
>> "name=Véloroute 50 : Étapes", and so on.
>>
>> (Similarly, some people have tagged sections of EuroVelo routes in one
>> country with the network=ncn tag. This is wrong: EuroVelo routes aren't
>> National, they're International. I think this is probably a mistaken
>> attempt
>> to get them to render on OpenCycleMap.)
>>
>> > To do this effectively, you will need a powerful editor: JOSM.
>>
>> This is a "tagging smell" (cf https://en.wikipedia.org/wiki/Code_smell).
>> Any
>> tagging scheme that requires a particular editor is probably a bad scheme.
>>
>> As it happens, you can certainly edit relations like this with Potlatch 2
>> no
>> problem and I guess you can with iD too; but before any tagging scheme
>> like
>> this is adopted, you should create a tutorial for iD users. It shouldn't
>> be
>> necessary to learn a whole new editor just to be able to tag a bike route
>> -
>> as you yourself say, "Is the hierarchy of cycle routes reserved for
>> experts?". Bear in mind too that iD users _will_ edit these routes, so the
>> scheme should be intuitive and robust (of course, that should be the case
>> anyway!).
>>
>> cheers
>> Richard
>>
>>
>>
>> --
>> Sent from: http://gis.19327.n8.nabble.com/Tagging-f5258744.html
>>
>> ___
>> Tagging mailing list
>> Tagging@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/tagging
>>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>


-- 
Vr gr Peter Elderson
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - RFC - (Hierarchies route=bicycle)

[Jo]

The existing scheme for tagging cycle routes is robust. The problem I see
when 'reusing' it in a hierarchy of routes, is that we would need a role to
indicate that the sub route is traversed in reverse for a particular
"super" route. It would also help to have an indicator in JOSM to indicate
continuity in the super route IF the sub route is continuous AND the last
node of the way / relation before it is the first of the sub route's way
AND the same applies for the last waynode in the sub route and the next way
/ route in the superroute.

iD is not ideal for working with route relations. It could be changed,
obviously, if a developer can be found who wants to dedicate to such a
task, but at the moment JOSM is your best bet to have a reasonable
experience working on such routes. For now we're already glad if iD doesn't
break the route relations.

Polyglot

On Wed, Jan 2, 2019 at 6:39 PM Richard Fairhurst 
wrote:

> Axelos wrote:
> > Hello, I propose a concept for contributing cycling route.
>
> Many thanks for looking at this - the current state of bike route
> hierarchies is a mess, and trying to parse the many different tagging
> practices so that cycle.travel can display them properly has been a
> nightmare. It would be good to have a commonly agreed, intuitive standard.
>
> From the description on the wiki page, I'm not sure how your proposal
> differs from the practice documented at
> https://cycling.waymarkedtrails.org/help/rendering/hierarchies . Could you
> explain the difference?
>
>
>
> A few passing comments:
>
> > Example name = Boucle de la Moselle: Toul - Pompey
>
> Please don't do this - the name tag is for an object's commonly agreed
> name,
> and "Boucle de la Moselle: Toul - Pompey" is not the official name of any
> part of the route. You could perhaps use the description= or note= tag
> instead.
>
> There are lots of examples of this in your proposal: "name=PAN Segment 1",
> "name=Véloroute 50 : Étapes", and so on.
>
> (Similarly, some people have tagged sections of EuroVelo routes in one
> country with the network=ncn tag. This is wrong: EuroVelo routes aren't
> National, they're International. I think this is probably a mistaken
> attempt
> to get them to render on OpenCycleMap.)
>
> > To do this effectively, you will need a powerful editor: JOSM.
>
> This is a "tagging smell" (cf https://en.wikipedia.org/wiki/Code_smell).
> Any
> tagging scheme that requires a particular editor is probably a bad scheme.
>
> As it happens, you can certainly edit relations like this with Potlatch 2
> no
> problem and I guess you can with iD too; but before any tagging scheme like
> this is adopted, you should create a tutorial for iD users. It shouldn't be
> necessary to learn a whole new editor just to be able to tag a bike route -
> as you yourself say, "Is the hierarchy of cycle routes reserved for
> experts?". Bear in mind too that iD users _will_ edit these routes, so the
> scheme should be intuitive and robust (of course, that should be the case
> anyway!).
>
> cheers
> Richard
>
>
>
> --
> Sent from: http://gis.19327.n8.nabble.com/Tagging-f5258744.html
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - RFC - (Hierarchies route=bicycle)

[Richard Fairhurst]

Axelos wrote:
> Hello, I propose a concept for contributing cycling route.

Many thanks for looking at this - the current state of bike route
hierarchies is a mess, and trying to parse the many different tagging
practices so that cycle.travel can display them properly has been a
nightmare. It would be good to have a commonly agreed, intuitive standard.

From the description on the wiki page, I'm not sure how your proposal
differs from the practice documented at
https://cycling.waymarkedtrails.org/help/rendering/hierarchies . Could you
explain the difference?



A few passing comments:

> Example name = Boucle de la Moselle: Toul - Pompey

Please don't do this - the name tag is for an object's commonly agreed name,
and "Boucle de la Moselle: Toul - Pompey" is not the official name of any
part of the route. You could perhaps use the description= or note= tag
instead.

There are lots of examples of this in your proposal: "name=PAN Segment 1",
"name=Véloroute 50 : Étapes", and so on.

(Similarly, some people have tagged sections of EuroVelo routes in one
country with the network=ncn tag. This is wrong: EuroVelo routes aren't
National, they're International. I think this is probably a mistaken attempt
to get them to render on OpenCycleMap.)

> To do this effectively, you will need a powerful editor: JOSM.

This is a "tagging smell" (cf https://en.wikipedia.org/wiki/Code_smell). Any
tagging scheme that requires a particular editor is probably a bad scheme.

As it happens, you can certainly edit relations like this with Potlatch 2 no
problem and I guess you can with iD too; but before any tagging scheme like
this is adopted, you should create a tutorial for iD users. It shouldn't be
necessary to learn a whole new editor just to be able to tag a bike route -
as you yourself say, "Is the hierarchy of cycle routes reserved for
experts?". Bear in mind too that iD users _will_ edit these routes, so the
scheme should be intuitive and robust (of course, that should be the case
anyway!).

cheers
Richard



--
Sent from: http://gis.19327.n8.nabble.com/Tagging-f5258744.html

___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - RFC - (Hierarchies route=bicycle)

[Volker Schmidt]

This is an interesting proposal, but it needs a lot of thinking before we
can consider it a working proposal.

Here is my lost of *additional points* that need clarification.

1) The problem exists in the same way also for other routes like:
route=road|foot|hiking|bus|trolleybus|tram|mtb|
So the wording has to be reviewed under this aspect

2) There is an unresolved issue with bicycle routes, i.e. that, variants
apart, in most cases a cycle route between A and B uses a different chain
of ways different in the direction A > B form the route B > A (due to
things, like roundabouts, one-way streets, one-way cycle paths that are
mapped as separate ways in OSM, and possible others). The only logically
clean solution is to have two separate relations for the two directions
under a super-relation. But none of the (many) cycle route relations I know
follow this model. The usual approach is to include all ways in the same
relation and use the forward|backward roles on the ways that differ. The
consequences for the hierarchy model need to be looked at.

3) There is a tendency to include signposts in the relations. This has a
number of open issues of its own.
3a) with the one-relation-per-direction scheme the signposts that have
information for both directions, do they belong to the super-relation or do
they have to be included in both child relations?
3b) In case of more routes sharing the same string of ways, many signs
(referring to different routes) share the same physical support, i.e. they
should be tagged on the same node.

Volker
Padova, Italy
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - RFC - (Hierarchies route=bicycle)

[Axelos]

Hello,


Paul Allen wrote
> On Mon, 31 Dec 2018 at 08:41, Axelos 

> axelos@

>  wrote:
> 
>>
>> This is not the same usage, but uses that complement each other.
>>
>> Super-route: Linking international routes
>> Route hierarchy: exploit other routes
>>
> 
> A super-relation is a relation that contains other relations. Relations
> have initially been created to contain nodes, ways or areas and
> combinations thereof.

Ok.

I added references to type = superroute on the page, which was just a small
detail.

Regards.




--
Sent from: http://gis.19327.n8.nabble.com/Tagging-f5258744.html

___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - RFC - (Hierarchies route=bicycle)

[Axelos]

--
Sent from: http://gis.19327.n8.nabble.com/Tagging-f5258744.html

___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - RFC - (Hierarchies route=bicycle)

[Paul Allen]

On Mon, 31 Dec 2018 at 08:41, Axelos  wrote:

>
> This is not the same usage, but uses that complement each other.
>
> Super-route: Linking international routes
> Route hierarchy: exploit other routes
>

I agree that the main reason superroute was invented was to link
international routes.  I agree that
the documentation on the wiki might be read as implying that this is the
only use.  However, take
a close look at what the first paragraph of
https://wiki.openstreetmap.org/wiki/Super-Relation
says and doesn't say:

A *super-relation* is a relation
 that contains other
relations. Relations  have
initially been created to contain nodes
, ways
 or areas
 and combinations thereof.

Nothing there about being only for linking international routes.  It
doesn't even mention international
routes.  It says, quite explicitly that it is a relation that contains
other relations.  Which is what your
proposal wants to do.  Further down that page it does mention international
routes, but as ONE
example of how super-relations may be used.  And then it links to other
pages telling you how
to implement a super-relation of routes using type=superroute.

If you wanted to create a nested relation hierarchy of objects that are not
routes, your proposal
might have merit, because using superroute to nest relations of non-routes
is counterintuitive.
But you want nested routes, and that is exactly what superroute is for.

If you trawl through all the discussion about superroute over the years,
you'll find people arguing that
it is useful and sensible (I agree).  You'll also find people arguing that
it is evil, should be
extirpated, and that people who use it should be blocked from ever using
OSM again, as should
their children and their children's children, even unto the fifth
generation.  So if you use superroute,
which does EXACTLY what you want to do, some people will be unhappy.  If
you invent a new tag
to do EXACTLY the same thing as superroute then everyone will be unhappy,
whether they think
superroute is a good idea or a bad idea.  Your time would be better spent
documenting superroute
with greater clarity.

-- 
Paul
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - RFC - (Hierarchies route=bicycle)

[Axelos]

Hello,


Peter Elderson wrote
> I think you describe a use case for that. This can be added to existing
> "How-to" pages for building routes. These vary somewhat by country,
> according to what rules the national community has agreed upon.

This is the idea.

The problem is to use third-party documentations (waymarkedtrails), there is
no documentation on the OSM wiki.

Do we then have the legitimacy of classifying cycle routes as opposed to
using the traditional way if nothing is officially documented?

Is the hierarchy of cycle routes reserved for experts? Without explicit
documentation beginners can not understand the operation that is complex.

Regards.



--
Sent from: http://gis.19327.n8.nabble.com/Tagging-f5258744.html

___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - RFC - (Hierarchies route=bicycle)

[Peter Elderson]

I still think it's the same mechanism.
You reuse existing collections of ways to build other collections.

I think you describe a use case for that. This can be added to existing
"How-to" pages for building routes. These vary somewhat by country,
according to what rules the national community has agreed upon.

Nederland has many routes built from other routes. Many routes are built
using node network routes. Most national and regional routes have been
split into easily manageable sections, and are in turn part of
international routes.

We do not use type=superroute. Just route. Data users and renderers can use
the type and the membership links to do their thing. Applications such as
OSMand and waymarkedtrails show that it can be done, and I think your use
case is already covered by that.

If not, could you please give an example that would not currently be
covered by these applications?



Op ma 31 dec. 2018 om 09:41 schreef Axelos :

> Hello,
>
>
> Paul Allen wrote
> > On Sun, 30 Dec 2018 at 18:20, Axelos 
>
> > axelos@
>
> >  wrote:
> > [...]
> >
> >>
> >> The concept of hierarchical relations makes it possible to avoid this
> >> edition nightmare, so that one single relation has to be modified, and
> >> this
> >> modification is automatically applied on the other 3 routes.
> >>
> >
> > This sort of idea already exists.  See
> > https://wiki.openstreetmap.org/wiki/Super-Relation
> > https://wiki.openstreetmap.org/wiki/Relation:superroute
> > and https://wiki.openstreetmap.org/wiki/Types_of_relation
> >
> > Some people think it a very sensible, useful idea.  Others think it is
> the
> > work of the devil.  I
> > doubt that your parallel scheme doing essentially the same thing would be
> > looked upon
> > favourably by either side.
>
> This is not the same usage, but uses that complement each other.
>
> Super-route: Linking international routes
> Route hierarchy: exploit other routes
>
> Regards.
>
>
>
>
> --
> Sent from: http://gis.19327.n8.nabble.com/Tagging-f5258744.html
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>


-- 
Vr gr Peter Elderson
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - RFC - (Hierarchies route=bicycle)

[Axelos]

Hello,


Peter Elderson wrote
> Look at Nederland on waymarkedtrails, hiking tab and bicycle tab, to see
> this is already working. In the information text they explain how they
> handle the hierarchy.

I know and I am inspired by it.
But is it wise to rely on basic documentation located on a third party site?
My idea is "formalized" on OpenStreetMap practice and can make improvements
later (example stages)

Regards.




--
Sent from: http://gis.19327.n8.nabble.com/Tagging-f5258744.html

___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - RFC - (Hierarchies route=bicycle)

[Axelos]

Hello,


Paul Allen wrote
> On Sun, 30 Dec 2018 at 18:20, Axelos 

> axelos@

>  wrote:
> [...]
> 
>>
>> The concept of hierarchical relations makes it possible to avoid this
>> edition nightmare, so that one single relation has to be modified, and
>> this
>> modification is automatically applied on the other 3 routes.
>>
> 
> This sort of idea already exists.  See
> https://wiki.openstreetmap.org/wiki/Super-Relation
> https://wiki.openstreetmap.org/wiki/Relation:superroute
> and https://wiki.openstreetmap.org/wiki/Types_of_relation
> 
> Some people think it a very sensible, useful idea.  Others think it is the
> work of the devil.  I
> doubt that your parallel scheme doing essentially the same thing would be
> looked upon
> favourably by either side.

This is not the same usage, but uses that complement each other.

Super-route: Linking international routes
Route hierarchy: exploit other routes

Regards.




--
Sent from: http://gis.19327.n8.nabble.com/Tagging-f5258744.html

___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - RFC - (Hierarchies route=bicycle)

[Peter Elderson]

Look at Nederland on waymarkedtrails, hiking tab and bicycle tab, to see this 
is already working. In the information text they explain how they handle the 
hierarchy.

Mvg Peter Elderson

> Op 30 dec. 2018 om 19:19 heeft Axelos  het volgende 
> geschreven:
> 
> Hello, I propose a concept for contributing cycling route.
> 
> my english is bad, sorry ...
> 
> https://wiki.openstreetmap.org/wiki/Proposed_features/Hierarchies_route%3Dbicycle
> 
> "Definition"
> 
> Bike routes are represented on OpenStreetMap as relations. There are many
> official routes that are already present in the base, and more will come.
> They can represent different types of itineraries: local, regional, national
> and even international.
> 
> That said, international routes are often based partly on national routes,
> which in turn are based on regional / local routes. Sometimes the regional
> ones are based on the locals. Clearly, with the system of flat relations, at
> least up to 4 itineraries can share the same physical path. In case of
> modification of this path (for example, a new 2-km cycleway along the road
> formerly used by the route), all the 4 relations have to be updated!
> 
> The concept of hierarchical relations makes it possible to avoid this
> edition nightmare, so that one single relation has to be modified, and this
> modification is automatically applied on the other 3 routes.
> 
> Tanks.
> 
> 
> 
> --
> Sent from: http://gis.19327.n8.nabble.com/Tagging-f5258744.html
> 
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging

___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - RFC - (Hierarchies route=bicycle)

[Paul Allen]

On Sun, 30 Dec 2018 at 18:20, Axelos  wrote:
[...]

>
> The concept of hierarchical relations makes it possible to avoid this
> edition nightmare, so that one single relation has to be modified, and this
> modification is automatically applied on the other 3 routes.
>

This sort of idea already exists.  See
https://wiki.openstreetmap.org/wiki/Super-Relation
https://wiki.openstreetmap.org/wiki/Relation:superroute
and https://wiki.openstreetmap.org/wiki/Types_of_relation

Some people think it a very sensible, useful idea.  Others think it is the
work of the devil.  I
doubt that your parallel scheme doing essentially the same thing would be
looked upon
favourably by either side.

-- 
Paul
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

[Tagging] Feature Proposal - RFC - (Hierarchies route=bicycle)

[Axelos]

Hello, I propose a concept for contributing cycling route.

my english is bad, sorry ...

https://wiki.openstreetmap.org/wiki/Proposed_features/Hierarchies_route%3Dbicycle

"Definition"

Bike routes are represented on OpenStreetMap as relations. There are many
official routes that are already present in the base, and more will come.
They can represent different types of itineraries: local, regional, national
and even international.

That said, international routes are often based partly on national routes,
which in turn are based on regional / local routes. Sometimes the regional
ones are based on the locals. Clearly, with the system of flat relations, at
least up to 4 itineraries can share the same physical path. In case of
modification of this path (for example, a new 2-km cycleway along the road
formerly used by the route), all the 4 relations have to be updated!

The concept of hierarchical relations makes it possible to avoid this
edition nightmare, so that one single relation has to be modified, and this
modification is automatically applied on the other 3 routes.

Tanks.



--
Sent from: http://gis.19327.n8.nabble.com/Tagging-f5258744.html

___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging