[Tagging] Feature Proposal - RFC - hiking_trail_relation_roles

[Michael Behrens]

https://wiki.openstreetmap.org/wiki/Proposed_features/hiking_trail_relation_roles



There is no unique way to tag roles in hiking route relations although they
carry a high potential for the rendering of hiking trails. This proposal
was requsted by Sarah Hoffmann on the FOSSGIS conference. A only officially
marked trails should be added to the relations!

Role nameExplaination
*None* or main The main "normal" roletype for the main section of the
hiking trails.
forward Section of the hiking trail that can only be hiked into the
direction of the way.
backward Section of the hiking trail that can only be hiked against the
direction of the way.
alternative or alternate Tags the members of an alternative path to *main*
 path.
excursion Can be used on parts of the trail that leads to a viewpoint, peak
or other. The path has to be hiked back again or else it will be a
*alternative*.
approach A path that is leading from a town, train station / bus station or
parking to main hiking trail or the other way around.
shortcut A trail that shortens the main trail.

Please write comments here:
https://wiki.openstreetmap.org/wiki/Talk:Proposed_features/hiking_trail_relation_roles

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

Re: [Tagging] Feature Proposal - RFC - hiking_trail_relation_roles

[Andy Townsend]

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 expanded it yet, but I'd 
definitely mention node members.


Best Regards,

Andy


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

Re: [Tagging] Feature Proposal - RFC - hiking_trail_relation_roles

[Mateusz Konieczny]

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 tables/images in mails, especially on a mailing lists
often end missing/malformed.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - RFC - hiking_trail_relation_roles

[Peter Elderson]

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 expanded it yet, but I'd definitely
> mention node members.
>
>  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 into the hiking
relation holding the ways of the main route, each with the 'excursion'
role? I think this should be explicit.

It seems to me that use of these roles leads to relations containing
non-contiguous trails. I would call those relations collections rather than
routes. Processing non-contiguous routes presents extra challenges for
processing such as exporting routes and making elevation profiles.

__
> 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 - park_drive

[Philip Barnes]

On Thursday, 5 December 2019, Paul Allen wrote:
> On Thu, 5 Dec 2019 at 10:10, Martin Scholtes 
> wrote:
> 
> >
> > https://wiki.openstreetmap.org/wiki/Proposed_features/park_drive
> > Definition: Information that can be taken on this parking lot to form a
> > carpool.
> >
> 
> I would prefer the key to park_and_drive.  It's longer, and more typing,
> but better English
> and less prone to confusion.  Particularly for those in the UK and New
> Zealand (and maybe
> elsewhere) who know of these:
> https://www.google.com/search?q=park+drive+cigarette

My first thought on seeing this, before reading, was a North American parkway 
where you drive through parkland.

Still not sure how this isn't carpooling.

Phil (trigpoint)

-- 
Sent from my Sailfish device
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - RFC - (changing_table:location)

[Sören Reinecke via Tagging]

I step back from my proposal 
https://wiki.openstreetmap.org/wiki/Proposed_features/Subkey:changing_table:location
which is totally fine because of less work. The webapp "Babykarte" by
the way supports semicolons as seperators so I do not have problems of
having semicolons in values.

Cheers

Sören Reinecke alias Valor Naram

-Original Message-
From: Sören Reinecke via Tagging 
Reply-To: "Tag discussion, strategy and related tools" <
tagging@openstreetmap.org>
To: Tagging@openstreetmap.org
Cc: Sören Reinecke 
Subject: [Tagging] Feature Proposal - RFC - (changing_table:location)
Date: Thu, 05 Dec 2019 14:39:27 +0100

Hey all,

A new but small proposal to change the specification for subkey
`changing_table:location` because of a discussion yesterday about using
seperators in values. I totally agree that we should avoid using
seperators when possible.
Proposal: 
https://wiki.openstreetmap.org/wiki/Proposed_features/Subkey:changing_table:location
Definition: Tagging of the location of the nappy changing facility in a
POI


Reason:
Someone pointed to the wikipage Semi-colon value separator as part of a
discussion of using semicolons as seperator of key values. In my
previous successful proposal the subkey
`changing_table:location'  allows to seperate the values by a
semicolon. While the support of a semicolon as seperator for this
subkey falls under the three exceptions ( 
https://wiki.openstreetmap.org/wiki/Semi-colon_value_separator ), I
want to give here the chance to change that because the subkey
changing_table:location is still not in widespread use.

Cheers

Sören Reinecke alias Valor Naram

___Tagging mailing 
listtagg...@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 - hiking_trail_relation_roles

[s8evq]

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 example https://www.openstreetmap.org/relation/9214075)

2) Or do you make a separate relation for the alternative, and add this 
relation to a super relation containing a main relation and the alternative 
relation. Then assign the member roles on relation level?
(what Peter Elderson kind of does in this example: 
https://www.openstreetmap.org/relation/9514645 collecting all variations, 
approaches and shortcuts in a super relation, but without assigning the roles)

Or would both methods be accepted?

Personally, I find method 2 a bit more practical for mapping.

On Fri, 6 Dec 2019 10:15:31 +, 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 relations although they
> carry a high potential for the rendering of hiking trails. This proposal
> was requsted by Sarah Hoffmann on the FOSSGIS conference. A only officially
> marked trails should be added to the relations!
> 
> Role nameExplaination
> *None* or main The main "normal" roletype for the main section of the
> hiking trails.
> forward Section of the hiking trail that can only be hiked into the
> direction of the way.
> backward Section of the hiking trail that can only be hiked against the
> direction of the way.
> alternative or alternate Tags the members of an alternative path to *main*
>  path.
> excursion Can be used on parts of the trail that leads to a viewpoint, peak
> or other. The path has to be hiked back again or else it will be a
> *alternative*.
> approach A path that is leading from a town, train station / bus station or
> parking to main hiking trail or the other way around.
> shortcut A trail that shortens the main trail.
> 
> Please write comments here:
> https://wiki.openstreetmap.org/wiki/Talk:Proposed_features/hiking_trail_relation_roles
> 
> Greeting
> Michael
> ___
> 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 - hiking_trail_relation_roles

[Michael Behrens]

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 new
routes?

Michael

Am Fr., 6. Dez. 2019 um 11:51 Uhr schrieb s8evq :

> 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 example https://www.openstreetmap.org/relation/9214075
> )
>
> 2) Or do you make a separate relation for the alternative, and add this
> relation to a super relation containing a main relation and the alternative
> relation. Then assign the member roles on relation level?
> (what Peter Elderson kind of does in this example:
> https://www.openstreetmap.org/relation/9514645 collecting all variations,
> approaches and shortcuts in a super relation, but without assigning the
> roles)
>
> Or would both methods be accepted?
>
> Personally, I find method 2 a bit more practical for mapping.
>
> On Fri, 6 Dec 2019 10:15:31 +, 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 relations although
> they
> > carry a high potential for the rendering of hiking trails. This proposal
> > was requsted by Sarah Hoffmann on the FOSSGIS conference. A only
> officially
> > marked trails should be added to the relations!
> >
> > Role nameExplaination
> > *None* or main The main "normal" roletype for the main section of the
> > hiking trails.
> > forward Section of the hiking trail that can only be hiked into the
> > direction of the way.
> > backward Section of the hiking trail that can only be hiked against the
> > direction of the way.
> > alternative or alternate Tags the members of an alternative path to
> *main*
> >  path.
> > excursion Can be used on parts of the trail that leads to a viewpoint,
> peak
> > or other. The path has to be hiked back again or else it will be a
> > *alternative*.
> > approach A path that is leading from a town, train station / bus station
> or
> > parking to main hiking trail or the other way around.
> > shortcut A trail that shortens the main trail.
> >
> > Please write comments here:
> >
> https://wiki.openstreetmap.org/wiki/Talk:Proposed_features/hiking_trail_relation_roles
> >
> > Greeting
> > Michael
> > ___
> > Tagging mailing list
> > Tagging@openstreetmap.org
> > https://lists.openstreetmap.org/listinfo/tagging
>
>
>
> ___
> 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] Foot or foot.cycle crossing

[Nick Bolten]

Sorry for being late to the party!

My understanding is that there isn't a documented tagging strategy for a
marked cycle lane crossing that's mapped as on a street way.

cycleway=crossing covers this scenario if the cycleway has been separately
mapped, so I wonder if a proposal for a tag like cycleway:
right:lane=crossing would be a logical extension. It could be applied to
the street way from the start of the crossing to the end of the crossing.

Specifying the crossing type (if necessary) could lead to an awkwardly long
key, as the nested would always need a side-of-street reference, like
cycleway:right:lane:crossing=uncontrolled. Maybe there should just be one
tag: cycleway:right: crossing=yes/no/uncontrolled (whatever that
means)/unmarked.

Best,

Nick

On Wed, Nov 27, 2019, 7:13 AM Volker Schmidt  wrote:

> I do have a topological problem with the mapping of a junction of two
> roads one of which has parallel cycle lanesa and sidewalks
> Both are correctly mapped: the sidewalk as a separate highwy=footway and
> the cycle lanes as cycleway:left|right=lane.
> How to you tag the foot-cycle crossings.
> See this Mapillary photo
>  to make things
> clearer.
> Two possible options:
>
> (1)
> way with:
> crossing=uncontrolled
> footway=crossing
> highway=footway
> plus node with:
> crossing=uncontrolled
> highway=crossing
>
> (2)
> way with:
> bicycle=designated
> foot=designated
> highway=path
> path=crossing
> segregated=yes
> plus node with:
> bicycle=yes
> crossing=uncontrolled
> highway=crossing
>
> Both are "incorrect" in some aspects.
> Which one is less incorrect?
> Is there a better tagging solution?
> ___
> 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 - hiking_trail_relation_roles

[Janko Mihelić]

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
that means we are doing the work of a router directly in the tags.

We should just mark "oneway" ways as such, and leave the rest to the
routers.

Also, "main" and "alternative" are orthogonal to "forward" and "backward".
We should then have "main:forward", "alternative:backward", and so on. That
doesn't make sense, and is not what "role" is traditionally used for.
Public transport routes used to use them, but not in the new scheme.

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

Re: [Tagging] Feature Proposal - RFC - hiking_trail_relation_roles

[Kevin Kenny]

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 should be checked to see if the whole branch is oneway. But that means 
> we are doing the work of a router directly in the tags.

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? Or if the route places foot traffic on a one way street
against the direction of motor traffic? I have encountered a few of
both scenarios.

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

Re: [Tagging] Feature Proposal - RFC - hiking_trail_relation_roles

[Jmapb via Tagging]

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 to see if the whole
branch is oneway. But that means we are doing the work of a router
directly in the tags.

We should just mark "oneway" ways as such, and leave the rest to the
routers.


If I recall, there were cases of one-way routes whose constituent ways
were *not* one-way. I can't bring one to mind offhand though.



Also, "main" and "alternative" are orthogonal to "forward" and
"backward". We should then have "main:forward",
"alternative:backward", and so on. That doesn't make sense, and is not
what "role" is traditionally used for. Public transport routes used to
use them, but not in the new scheme.


I think you're correct about the orthogonality but I disagree with the
implication. "forward" and "backward" without a prefix can be presumed
to refer to the main trail. If roles like "alternate:forward" and
"shortcut:backward" prove necessary and useful then mappers will  and
data consumers will use them, but I don't feel they need to be part of
the initial proposal.

Jason


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

Re: [Tagging] Feature Proposal - RFC - hiking_trail_relation_roles

[Janko Mihelić]

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, the whole route is oneway. So if you sort ways in the
relation, the same way they are sorted in public transport routes, then you
can use the established tag "signed_direction=yes"[1].

[1] - https://wiki.openstreetmap.org/wiki/Key:signed_direction
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - RFC - park_drive

[Martin Scholtes]

Am 06.12.2019 um 11:58 schrieb Philip Barnes:
> My first thought on seeing this, before reading, was a North American parkway 
> where you drive through parkland.
>
> Still not sure how this isn't carpooling.
>
> Phil (trigpoint)
What exactly don't you understand? Apart from your question, I can't
figure it out.

-- 
Mit freundlichen Grüßen


Martin Scholtes




smime.p7s
Description: S/MIME Cryptographic Signature
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - RFC - hiking_trail_relation_roles

[Sarah Hoffmann]

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 members (start, end, marker, etc.).  This
> > may be deliberate, or you just haven't expanded it yet, but I'd definitely
> > mention node members.
> >
> >  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 into the hiking
> relation holding the ways of the main route, each with the 'excursion'
> role? I think this should be explicit.
> 
> It seems to me that use of these roles leads to relations containing
> non-contiguous trails. I would call those relations collections rather than
> routes. Processing non-contiguous routes presents extra challenges for
> processing such as exporting routes and making elevation profiles.

I have to strongly disagree with all of that.

1. Having alternatives and excursions does not make a route non-contiguous.
   It just makes it non-linear.
2. It is perfectly normal for a route to be non-linear. If the alternative
   route is marked, it's part of the route and should be mapped accordingly.
3. Non-linear routes are not a problem for processing per-se.

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 much as it honors me that you
consider waymarkedtrails the gold standard for what is doable with route
relations, I have to disappoint you here. Non-linear routes are simply not
implemented because of lack of time.

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.

Kind regards

Sarah

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

Re: [Tagging] Feature Proposal - RFC - hiking_trail_relation_roles

[Warin]

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,
then all the ways in a branch should be checked to see if the whole
branch is oneway. But that means we are doing the work of a router
directly in the tags.

We should just mark "oneway" ways as such, and leave the rest to the
routers.


If I recall, there were cases of one-way routes whose constituent ways
were *not* one-way. I can't bring one to mind offhand though.


Australian 'Overland Track' is 'one-way' for people doing the whole 
route in the peak time, however people coming in from the sides are 
allowed to walk the other way for 'short distances'.
As such the ways are not oneway, but the route is oneway for some of the 
time. And during that time a fee is charged...
I have not attempted to tag the one way nature - if you apply for the 
permit you get told that information anyway.

The relation is 1673569






Also, "main" and "alternative" are orthogonal to "forward" and
"backward". We should then have "main:forward",
"alternative:backward", and so on. That doesn't make sense, and is not
what "role" is traditionally used for. Public transport routes used to
use them, but not in the new scheme.


I think you're correct about the orthogonality but I disagree with the
implication. "forward" and "backward" without a prefix can be presumed
to refer to the main trail. If roles like "alternate:forward" and
"shortcut:backward" prove necessary and useful then mappers will and
data consumers will use them, but I don't feel they need to be part of
the initial proposal.

Jason


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




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

[Tagging] Route node roles - was Re: Feature Proposal - RFC - hiking_trail_relation_roles

[Warin]

On 06/12/19 21:23, Andy Townsend wrote:

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 expanded it yet, 
but I'd definitely mention node members.






For nodes .. think the roles of ways should be done first, but some 
thoughts for later proposal/s.


Are they necessary?

Start and finish points will be at the end of the main route ways .. 
should be obvious? No?


Markers .. humm I need some time to think on it.

Well for 'start'/'beginning'/'finish' .. err many routes can be 
'started' at either end. So why not use 'end' as that does not identify 
it as either start of finish?


Then should 'end' be only used for the main route, or can it be used on 
'approaches' and 'excursions' too?
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - RFC - hiking_trail_relation_roles

[Warin]

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 relations although 
they carry a high potential for the rendering of hiking trails. This 
proposal was requsted by Sarah Hoffmann on the FOSSGIS conference. A 
only officially marked trails should be added to the relations!


Role name   Explaination
/None/ or |main| 	The main "normal" roletype for the main section of 
the hiking trails.
|forward| 	Section of the hiking trail that can only be hiked into the 
direction of the way.
|backward| 	Section of the hiking trail that can only be hiked against 
the direction of the way.
|alternative| or |alternate| 	Tags the members of an alternative path 
to /main/ path.
|excursion| 	Can be used on parts of the trail that leads to a 
viewpoint, peak or other. The path has to be hiked back again or else 
it will be a /alternative/.
|approach| 	A path that is leading from a town, train station / bus 
station or parking to main hiking trail or the other way around.

|shortcut|  A trail that shortens the main trail.




A 'shortcut' is an alternative .. I see no need for a separate role, 
just use 'alternate'?


Roles on member ways or on member relations?
The example given has a super relation with a number of member 
relations, these have no role in the super relation.
An alternative is the super relation with each member relation having 
roles. A poor example would be relation 176684 that has one member 
relation with part of the name 'alternative routes'.


What is 'best'? In this case best for the mapper (as is usual OSM 
practice). Any thoughts?



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

Re: [Tagging] Feature Proposal - RFC - hiking_trail_relation_roles

[Martin Koppenhoefer]

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 should be a way to distinguish 
several cases of forward / backward, those where you can walk in both 
directions but only one is signposted, and those where you actually can’t use 
it bidirectionally (e.g. it is too narrow and too much traffic)

Cheers Martin 


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

Re: [Tagging] Feature Proposal - RFC - park_drive

[Martin Koppenhoefer via Tagging]

sent from a phone

> On 6. Dec 2019, at 23:28, Martin Scholtes  wrote:
> 
> What exactly don't you understand? Apart from your question, I can't
> figure it out.


the name is misleading, rather than park_and_drive, the name of the concept and 
borrowing from the well known park and ride concept, you named the tag 
park_drive which means literally a road in a park.
I also find this confusing.

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

Re: [Tagging] Feature Proposal - RFC - hiking_trail_relation_roles

[Peter Elderson]

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 different from cycling 
routes, which tend to have many sections where the route directions use 
different sets of ways. 

I think a simple oneway=yes on a hiking route relation could say it's 
signposted for one direction. 

Mvg Peter Elderson

> Op 7 dec. 2019 om 01:12 heeft Martin Koppenhoefer  
> het volgende geschreven:
> 
> 
> 
> 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 should be a way to distinguish 
> several cases of forward / backward, those where you can walk in both 
> directions but only one is signposted, and those where you actually can’t use 
> it bidirectionally (e.g. it is too narrow and too much traffic)
> 
> Cheers Martin 
> 
> 
> ___
> 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] Route node roles - was Re: Feature Proposal - RFC - hiking_trail_relation_roles

[Andy Townsend]

On 06/12/2019 23:30, Warin wrote:



Start and finish points will be at the end of the main route ways .. 
should be obvious? No?


It depends - as Sarah's already pointed out, routes that are more 
complicated than "one start and one end" are very common.  One of the 
more famous examples is the Camino de Santiago, which has one end but 
many different start points.


Best Regards,

Andy



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

Re: [Tagging] Feature Proposal - RFC - hiking_trail_relation_roles

[Martin Koppenhoefer]

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

pedestrian_oneway=yes
or maybe 

oneway:foot=yes 

would be more in line with what we already have: 
https://taginfo.openstreetmap.org/search?q=oneway


Cheers Martin 


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

Re: [Tagging] Feature Proposal - RFC - hiking_trail_relation_roles

[Andrew Harvey]

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.
> sign_direction=forward/backward/both
>
> pedestrian_oneway=yes
> or maybe
>
> oneway:foot=yes
>

Where it's a restriction on the walking path, then oneway=yes on the way,
when it's a restriction on the route a oneway=yes on the route is the way
to go.

We already have a well documented and accepted way to tag conditional
restrictions via
https://wiki.openstreetmap.org/wiki/Conditional_restrictions. So no need
for a new tag, oneway:foot=yes/no is the way to go. 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.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - RFC - hiking_trail_relation_roles

[Warin]

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 signposted for one direction.



I would prefer being more explicit in the tag name, e.g.
sign_direction=forward/backward/both

pedestrian_oneway=yes
or maybe

oneway:foot=yes


Where it's a restriction on the walking path, then oneway=yes on the 
way, when it's a restriction on the route a oneway=yes on the route is 
the way to go.


If oneway=yes is placed on a route relation then any excursions and 
appropriate approaches will have to be separate relations. Meaning there 
will have to be a super relation to combine them...



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

Re: [Tagging] Feature Proposal - RFC - park_drive

[Paul Johnson]

On Thu, Dec 5, 2019, 04:09 Martin Scholtes  wrote:

> Hello,
>
> I would like to inform you that I have made a suggestion about park and
> drive. This resulted from a discussion in the OSM DE Telegram Chat.
>
> https://wiki.openstreetmap.org/wiki/Proposed_features/park_drive
> Definition: Information that can be taken on this parking lot to form a
> carpool.
>
> I would be pleased about suggestions.
>

I'm thinking this should be a subtag of park and ride ragging already
existing.  There's quite a few Park and Ride lots in places that don't
confer exclusive use of transit, and usually if you see a Park and Ride lot
in the rural midwestern US, there's a good chance it is exclusively for for
carpooling commuters.

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