Re: [Tagging] Feature Proposal - RFC - hiking_trail_relation_roles

On 6/3/20 7:28 pm, Peter Elderson wrote: To circle back to my question, I would not use something like "detached" for a trail like The North Trail, because it still is one trail and you would probably want to have the option to export it as a whole, and to see the height profile (with gaps but

Re: [Tagging] Feature Proposal - RFC - hiking_trail_relation_roles

To circle back to my question, I would not use something like "detached" for a trail like The North Trail, because it still is one trail and you would probably want to have the option to export it as a whole, and to see the height profile (with gaps but still useful) and total length calculation.

Re: [Tagging] Feature Proposal - RFC - hiking_trail_relation_roles

On 3/5/2020 9:27 AM, Peter Elderson wrote: Do you know trails with detached sections? We have some in Nederland, on the islands. Doesn't fit in the proposed role scheme, I think. Vr gr Peter Elderson See this section of the E10 in Czechia ( https://www.openstreetmap.org/relation/5465693 ) --

Re: [Tagging] Feature Proposal - RFC - hiking_trail_relation_roles

On 6/3/20 10:05 am, Volker Schmidt wrote: Ferry or private boat, and maybe a short walk or bus to the starting point. However, the approach is not waymarked nor described as part of the route. I think this one is more like a collection of separate walks under one name,

Re: [Tagging] Feature Proposal - RFC - hiking_trail_relation_roles

Ferry or private boat, and maybe a short walk or bus to the starting point. > However, the approach is not waymarked nor described as part of the route. > I think this one is more like a collection of separate walks under one > name, marketed as one trail with one paper guide. > In the case of

Re: [Tagging] Feature Proposal - RFC - hiking_trail_relation_roles

Op 5 mrt. 2020 om 23:18 heeft Warin <61sundow...@gmail.com> het volgende geschreven: > On 6/3/20 1:27 am, Peter Elderson wrote: >> Do you know trails with detached sections? We have some in Nederland, on the >> islands. Doesn't fit in the proposed role scheme, I think. > How would you get to

Re: [Tagging] Feature Proposal - RFC - hiking_trail_relation_roles

This issue has come up before in the context of packrafting trail relations. Closer to home here, we do have some bike trails that include ferry boat /waterbus) bits. They are included in the relations. On of the latter is relation 1610889 The

Re: [Tagging] Feature Proposal - RFC - hiking_trail_relation_roles

On 6/3/20 1:27 am, Peter Elderson wrote: Do you know trails with detached sections? We have some in Nederland, on the islands. Doesn't fit in the proposed role scheme, I think. How would you get to these 'detached sections"? If by ferry, would not the ferry trip form part of the route?

Re: [Tagging] Feature Proposal - RFC - hiking_trail_relation_roles

Do you know trails with detached sections? We have some in Nederland, on the islands. Doesn't fit in the proposed role scheme, I think. Vr gr Peter Elderson Op wo 4 mrt. 2020 om 23:09 schreef Kevin Kenny : > On Wed, Mar 4, 2020 at 4:02 PM Peter Elderson wrote: > > Maybe someone could try

Re: [Tagging] Feature Proposal - RFC - hiking_trail_relation_roles

On Wed, Mar 4, 2020 at 4:02 PM Peter Elderson wrote: > Maybe someone could try basic roletagging of ways. I will not do that, > because it would take much more time, maintenance and tooling. I don't > foresee mappers in Nederland to do it that way, but in other countries > putting everything

Re: [Tagging] Feature Proposal - RFC - hiking_trail_relation_roles

I agree with most things you say, Kevin. But it's not my proposal! I don't really care about the purpose or exact value of a variant, just that it ibelongs to the route but is not the main route and that values are unambiguous. But I don't want to undercut the proposal. I suggested "branch" for

Re: [Tagging] Feature Proposal - RFC - hiking_trail_relation_roles

I certainly agree in principle that having a notation for loops, spurs and alternatives would be a step forward in mapping hiking routes. I don't see any particular advantage in having the role identify the specific purpose of the secondary trail, except that hikers will care whether or not a side

Re: [Tagging] Feature Proposal - RFC - hiking_trail_relation_roles

After consulting the Dutch OSM community on the OSM forum, I have tagged relation member roles for 3 recreational foot routes in Nederland: 1. The Roman LIMES trail https://hiking.waymarkedtrails.org/#route?id=9214891 This national trail has several alternatives and one approach. The main route

Re: [Tagging] Feature Proposal - RFC - hiking_trail_relation_roles

I think the proposal is not ready for use or for voting, but there does not seem to be much progress. The basics are clear enough I think. Though I myself would have made things even simpler (e.g. not bother with functions like approach or excursion, but simply use alternative and branch as

Re: [Tagging] Feature Proposal - RFC - hiking_trail_relation_roles

+1 for stating more clearly What to map and What NOT to map. The first goal of the proposal, I think, is to separate the main (linear or circular) route from the extras, for display and some data use (e.g. export, length calculation and elevation profile). Then render the extras as dashed route

Re: [Tagging] Feature Proposal - RFC - hiking_trail_relation_roles

I agree with Peter, it'll probably be better to start with the basics, get that approved so at least there is some improvement, then move forward with the more complicated parts of the proposal. In terms of the role names proposed I noticed that it is a very similar to a schema I came up with for

Re: [Tagging] Feature Proposal - RFC - hiking_trail_relation_roles

+1 for the last remark, but -1 for voting in its current state. Too many inconsistencies and unanswered questions, e.g. about directionality: conflicting backward/forward role definition and hierarchy resolution stuff (that is up to the data users; should IMO be kept only on the talk page). I

Re: [Tagging] Feature Proposal - RFC - hiking_trail_relation_roles

Hello everyone, What is the status of this proposal? Should we go forward and start voting? Lots of people have added valuable information and insight. It would be a pity if this proposal yet again stays in "Draft" status for forever. On Fri, 6 Dec 2019 10:15:31 +, Michael Behrens wrote:

Re: [Tagging] Feature Proposal - RFC - hiking_trail_relation_roles - transport

if all the ideas for roles in routes are combined, you will need multiple roles for the relation members. When a member of a cycling route relation is tagged as a waterway or a railway, isn't that all the information you need to know it's a transfer? If the member is a relation, you could tag

Re: [Tagging] Feature Proposal - RFC - hiking_trail_relation_roles - transport

Where a hiking route uses some transport to get from one walking section to another should there be a roll 'transport'??? I know one of the American routes uses a canoe to cross a river, and at least one of the Australian routes uses row boats to cross a river. And, yes, this flows on from

Re: [Tagging] Feature Proposal - RFC - hiking_trail_relation_roles

An approach always links something to the route so yeah, fine with me. Fr gr Peter Elderson Op vr 13 dec. 2019 om 14:29 schreef John Willis via Tagging < tagging@openstreetmap.org>: > > > On Dec 13, 2019, at 2:20 AM, Michael Behrens > wrote: > > > > I would agree that a 'link' should be

Re: [Tagging] Feature Proposal - RFC - hiking_trail_relation_roles

> On Dec 13, 2019, at 2:20 AM, Michael Behrens wrote: > > I would agree that a 'link' should be tagged as a approach Then the word "approach" shouldn’t be used - use “link”. Use the same vocabulary as other route relations. We shouldn't use bespoke words when the standardized synonym word

Re: [Tagging] Feature Proposal - RFC - hiking_trail_relation_roles

I would agree that a 'link' should be tagged as a approach. That way we don't have to cover any complicated special cases like a trail that leads to a station and a new trail. And actually the difference between links is not that big. Michael Am Do., 12. Dez. 2019 um 10:31 Uhr schrieb Peter

Re: [Tagging] Feature Proposal - RFC - hiking_trail_relation_roles

I think in terms of this proposal, a waymarked link is an approach? Vr gr Peter Elderson Op do 12 dec. 2019 om 11:21 schreef John Willis via Tagging < tagging@openstreetmap.org>: > Links - as in a relation role value “link” - as in small pieces of trail > that link some other trail or way to

Re: [Tagging] Feature Proposal - RFC - hiking_trail_relation_roles

Links - as in a relation role value “link” - as in small pieces of trail that link some other trail or way to the main route. Just thinking of routing Terms we use for other types of routes. Javbw > On Dec 12, 2019, at 2:22 PM, Warin <61sundow...@gmail.com> wrote: > > What links? urls? or do

Re: [Tagging] Feature Proposal - RFC - hiking_trail_relation_roles

On 12/12/19 16:00, John Willis via Tagging wrote: On Dec 9, 2019, at 6:36 AM, Warin <61sundow...@gmail.com > wrote: individual ways that have the direction, not the entire relation. some routes (made of many overlapping pieces of trail) are considered

Re: [Tagging] Feature Proposal - RFC - hiking_trail_relation_roles

> On Dec 9, 2019, at 6:36 AM, Warin <61sundow...@gmail.com> wrote: > > individual ways that have the direction, not the entire relation. some routes (made of many overlapping pieces of trail) are considered ascents and decents. the named “trail" is made of the ascent route and descent route.

Re: [Tagging] Feature Proposal - RFC - hiking_trail_relation_roles

I am now convinced it is useful to have a oneway=yes tag for a route indicating it's not allowed or possible to go the other way. As for routers, I would still expect a router to check all the ways and nodes for access. Fr gr Peter Elderson Op ma 9 dec. 2019 om 00:36 schreef Martin Koppenhoefer

Re: [Tagging] Feature Proposal - RFC - hiking_trail_relation_roles

sent from a phone > On 7. Dec 2019, at 16:49, Mateusz Konieczny wrote: > > Only-exit ways in zoos, Orla Perć hiking trail, > some tourism routes in castles, mines etc don’t know for the hiking trail, but the other cases are not what I would see as “legal prescriptions”, it’s what the

Re: [Tagging] Feature Proposal - RFC - hiking_trail_relation_roles

On 09/12/19 07:14, Peter Elderson wrote: Sarah Hoffmann mailto:lon...@denofr.de>>: The point about the processing you have now made repeatedly in different contexts. You seem to have come to this conclusion because waymarkedtrails does not implement non-linear routes. As

Re: [Tagging] Feature Proposal - RFC - hiking_trail_relation_roles

Sarah Hoffmann : > On Fri, Dec 06, 2019 at 11:54:08AM +0100, Peter Elderson wrote: > > Also, i guess backward and forward roles are for ways only, the other > > roles are more suited for relation members. Or not? Could I enter all the > > ways of a 3 Km medieval castle excursion to a viewpoint

Re: [Tagging] Feature Proposal - RFC - hiking_trail_relation_roles

8 Dec 2019, 15:25 by mfbehren...@gmail.com: > This diagram should help to better visualise the structure At least in my case diagram was lost and not displayed___ Tagging mailing list Tagging@openstreetmap.org

Re: [Tagging] Feature Proposal - RFC - hiking_trail_relation_roles

Use of Subrelations and Superrelations[Quelltext bearbeiten ] Some user requested to use subrelations to map parts of hiking trail and then assign a role to the subrelation instead of each

Re: [Tagging] Feature Proposal - RFC - hiking_trail_relation_roles

I fully agree with this argument and I also wrote a comment on the Wiki Talk page. What do you thing about using main:forward, main:backward, alternative:forward and alternative:backward. Another problem is that whenever there the main trail has a forward or backward we automatically have two

Re: [Tagging] Feature Proposal - RFC - hiking_trail_relation_roles

What about routes that have oneway segments, without paths having a legal restrictions on direction of walking? 6 Dec 2019, 19:28 by jan...@gmail.com: > I think the "forward" and "backward" don't belong in a role of a relation. > Oneway=yes on a way should be enough. In the Wiki discussion it

Re: [Tagging] Feature Proposal - RFC - hiking_trail_relation_roles

Ok I forgot. So signed_direction=yes means signed in the direction of the sequence of ways in the relation. signed_direction=no would be the default for hikes, then? And oneway=yes on a hiking route means it's really one way (direction is given by the order way sequence) and you are not allowed

Re: [Tagging] Feature Proposal - RFC - hiking_trail_relation_roles

On 07/12/19 23:59, Peter Elderson wrote: I wiould mark the route oneway=yes to indicate oneway signposting, For some it is not the signposting but a legal requirement that the hiking route foot traffic is in one direction only. And it is enforced. The tag oneway=yes is taken to be a legal

Re: [Tagging] Feature Proposal - RFC - hiking_trail_relation_roles

Well, I don't know really. For me either solutions are OK. But reading the discussion here, I think it seems like the topic of superrelations is controversial and most people would apply the newly proposed roles on ways within a relation? On Fri, 6 Dec 2019 13:16:58 +, Michael Behrens

Re: [Tagging] Feature Proposal - RFC - hiking_trail_relation_roles

On Sat, 7 Dec 2019 01:09:37 +0100, Martin Koppenhoefer wrote: > oneway is generally not considered to apply to pedestrians. > I agree with what Kevin has written, there should be a way to distinguish > several cases of forward / backward, those where you can walk in both > directions but only

Re: [Tagging] Feature Proposal - RFC - hiking_trail_relation_roles

On Fri, 6 Dec 2019 22:29:51 +, Sarah Hoffmann wrote: > If I'd have to state a rule what makes processing easier then it would be: > avoid subrelations unless the relation is so large that it is a pain to > handle in the editor. Sarah, just to be clear: with 'subrelations', do you mean

Re: [Tagging] Feature Proposal - RFC - hiking_trail_relation_roles

7 Dec 2019, 16:03 by ajt1...@gmail.com: >> Cannot be legal for a pedestrian route, I think >> > > Statements like this suffer from an effect a bit like "Betteridge's law of > headlines", in this case "any absolute statement that something that is true > in one place is also true everywhere

Re: [Tagging] Feature Proposal - RFC - hiking_trail_relation_roles

> Cannot be legal for a pedestrian route, I think Statements like this suffer from an effect a bit like "Betteridge's law of headlines", in this case "any absolute statement that something that is true in one place is also true everywhere else in the world is false". I can certainly think of

Re: [Tagging] Feature Proposal - RFC - hiking_trail_relation_roles

I wiould mark the route oneway=yes to indicate oneway signposting, then oneway:foot=yes (or whatever is in use to indicate an access restriction on a way) on the ways where it is actually forbidden. I would not take oneway=yes on a route relation to indicate legal restriction on its members. Vr

Re: [Tagging] Feature Proposal - RFC - hiking_trail_relation_roles

There are some hiking routes signposted with allowing travel in one direction and forbidding in the opposite. 7 Dec 2019, 13:04 by pelder...@gmail.com: > Cannot be legal for a pedestrian route, I think. So practical. > > Mvg Peter Elderson > >> Op 7 dec. 2019 om 10:53 heeft Martin Koppenhoefer

Re: [Tagging] Feature Proposal - RFC - hiking_trail_relation_roles

Cannot be legal for a pedestrian route, I think. So practical. Mvg Peter Elderson > Op 7 dec. 2019 om 10:53 heeft Martin Koppenhoefer > het volgende geschreven: > >  > > sent from a phone > >> On 7. Dec 2019, at 04:36, Warin <61sundow...@gmail.com> wrote: >> >> If oneway=yes is placed on

Re: [Tagging] Feature Proposal - RFC - hiking_trail_relation_roles

you could define oneway=yes to be applicable to the main route. Sounds logical to me, i think most hikers would assume that. I think long excursions, branches and alternate routes are better maintained as separate relations. It's a separate discussion if these all need to be put into a

Re: [Tagging] Feature Proposal - RFC - hiking_trail_relation_roles

And, I would interpret the route direction for pedestrians as a suggestion, not an access restriction or physical restriction. Mvg Peter Elderson > Op 7 dec. 2019 om 04:11 heeft Andrew Harvey het > volgende geschreven: > >  > On Sat, 7 Dec 2019 at 13:07, Martin Koppenhoefer > wrote:

Re: [Tagging] Feature Proposal - RFC - hiking_trail_relation_roles

Martin Koppenhoefer : > On 7. Dec 2019, at 01:51, Peter Elderson wrote: >>> >> I think a simple oneway=yes on a hiking route relation could say it's >> signposted for one direction. > > I would prefer being more explicit in the tag name, e.g. > sign_direction=forward/backward/both Hm... sign

Re: [Tagging] Feature Proposal - RFC - hiking_trail_relation_roles

sent from a phone > On 7. Dec 2019, at 04:11, Andrew Harvey wrote: > > If you want to be explicit that's fine, but I think oneway=yes on a > highway=footway,path already implies it's oneway for pedestrians. you might see oneway=yes like this for footways, although additional tags like

Re: [Tagging] Feature Proposal - RFC - hiking_trail_relation_roles

sent from a phone > On 7. Dec 2019, at 04:36, Warin <61sundow...@gmail.com> wrote: > > If oneway=yes is placed on a route relation then any excursions and > appropriate approaches will have to be separate relations. is it a legal restriction or a practical one if placed on a route relation?

Re: [Tagging] Feature Proposal - RFC - hiking_trail_relation_roles

On 07/12/19 14:09, Andrew Harvey wrote: On Sat, 7 Dec 2019 at 13:07, Martin Koppenhoefer mailto:dieterdre...@gmail.com>> wrote: On 7. Dec 2019, at 01:51, Peter Elderson mailto:pelder...@gmail.com>> wrote: I think a simple oneway=yes on a hiking route relation could say it's

Re: [Tagging] Feature Proposal - RFC - hiking_trail_relation_roles

On Sat, 7 Dec 2019 at 13:07, Martin Koppenhoefer wrote: > On 7. Dec 2019, at 01:51, Peter Elderson wrote: > > I think a simple oneway=yes on a hiking route relation could say it's > signposted for one direction. > > > > I would prefer being more explicit in the tag name, e.g. >

Re: [Tagging] Feature Proposal - RFC - hiking_trail_relation_roles

sent from a phone > On 7. Dec 2019, at 01:51, Peter Elderson wrote: > > I think a simple oneway=yes on a hiking route relation could say it's > signposted for one direction. I would prefer being more explicit in the tag name, e.g. sign_direction=forward/backward/both

Re: [Tagging] Feature Proposal - RFC - hiking_trail_relation_roles

I have actually come across 1 instance where a pedestrian should not go in the opposite direction, and markings were actually different for the directions. Most hikers would simply use the opposite route section for both directions. That is to say it's a very rare exception. Completely

Re: [Tagging] Feature Proposal - RFC - hiking_trail_relation_roles

sent from a phone > On 6. Dec 2019, at 19:29, Janko Mihelić wrote: > > I think the "forward" and "backward" don't belong in a role of a relation. > Oneway=yes on a way should be enough oneway is generally not considered to apply to pedestrians. I agree with what Kevin has written, there

Re: [Tagging] Feature Proposal - RFC - hiking_trail_relation_roles

Thank you Michael! Saves me from doing it.. it is on my list of 'things that should be done' .. quite a long list. On 06/12/19 21:15, Michael Behrens wrote: https://wiki.openstreetmap.org/wiki/Proposed_features/hiking_trail_relation_roles There is no unique way to tag roles in hiking route

Re: [Tagging] Feature Proposal - RFC - hiking_trail_relation_roles

On 07/12/19 05:45, Jmapb via Tagging wrote: On 12/6/2019 1:28 PM, Janko Mihelić wrote: I think the "forward" and "backward" don't belong in a role of a relation. Oneway=yes on a way should be enough. In the Wiki discussion it is said that if there is one little "oneway" way in a big branch,

Re: [Tagging] Feature Proposal - RFC - hiking_trail_relation_roles

On Fri, Dec 06, 2019 at 11:54:08AM +0100, Peter Elderson wrote: > Andy Townsend : > > > Michael Behrens: > > > > > > There is no unique way to tag roles in hiking route relations > > > > I'd suggest making it clear that that table is currently for way members > > only - it doesn't mention node

Re: [Tagging] Feature Proposal - RFC - hiking_trail_relation_roles

pet, 6. pro 2019. u 19:39 Kevin Kenny napisao je: > What about the case where it's perfectly right and proper to walk the > way in either direction, but the route is signed in only one > direction? > Religious pilgrimages come to mind, where you usually go in one direction. But in that case,

Re: [Tagging] Feature Proposal - RFC - hiking_trail_relation_roles

On 12/6/2019 1:28 PM, Janko Mihelić wrote: I think the "forward" and "backward" don't belong in a role of a relation. Oneway=yes on a way should be enough. In the Wiki discussion it is said that if there is one little "oneway" way in a big branch, then all the ways in a branch should be checked

Re: [Tagging] Feature Proposal - RFC - hiking_trail_relation_roles

On Fri, Dec 6, 2019 at 1:29 PM Janko Mihelić wrote: > I think the "forward" and "backward" don't belong in a role of a relation. > Oneway=yes on a way should be enough. In the Wiki discussion it is said that > if there is one little "oneway" way in a big branch, then all the ways in a > branch

Re: [Tagging] Feature Proposal - RFC - hiking_trail_relation_roles

I think the "forward" and "backward" don't belong in a role of a relation. Oneway=yes on a way should be enough. In the Wiki discussion it is said that if there is one little "oneway" way in a big branch, then all the ways in a branch should be checked to see if the whole branch is oneway. But

Re: [Tagging] Feature Proposal - RFC - hiking_trail_relation_roles

Hi, So you would also put a short excursion into a new relation and have this as a seperate relation? Of couse, I see the point you want to make. This really makes sense when we look at long alternative routes or approaches. Would you then put all the relations into a superroute or still into

Re: [Tagging] Feature Proposal - RFC - hiking_trail_relation_roles

Interesting proposal. I think it would be useful to also add to the proposal how we structure these hiking relations. For example: 1) Do you put the individual ways of an alternative into the main relation, with each member way of this alternative route assigned role 'alternative'. (for

Re: [Tagging] Feature Proposal - RFC - hiking_trail_relation_roles

Andy Townsend : > Michael Behrens: > > > There is no unique way to tag roles in hiking route relations > > I'd suggest making it clear that that table is currently for way members > only - it doesn't mention node members (start, end, marker, etc.). This > may be deliberate, or you just haven't

Re: [Tagging] Feature Proposal - RFC - hiking_trail_relation_roles

6 Dec 2019, 11:15 by mfbehren...@gmail.com: > https://wiki.openstreetmap.org/wiki/Proposed_features/hiking_trail_relation_roles> >   > I made some comments at https://wiki.openstreetmap.org/wiki/Talk:Proposed_features/hiking_trail_relation_roles#Alternative_vs_main as it included image and

Re: [Tagging] Feature Proposal - RFC - hiking_trail_relation_roles

On 06/12/2019 10:15, Michael Behrens wrote: There is no unique way to tag roles in hiking route relations I'd suggest making it clear that that table is currently for way members only - it doesn't mention node members (start, end, marker, etc.).  This may be deliberate, or you just haven't