Re: [Tagging] Feature Proposal - RFC - park_drive

On 05/12/19 21:08, 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

Re: [Tagging] Feature Proposal - RFC - park_drive

On 12/6/19 18:38, Martin Koppenhoefer via Tagging wrote: 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

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

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 bicy

Re: [Tagging] Feature Proposal - RFC - park_drive

sent from a phone > On 7. Dec 2019, at 09:57, Shawn K. Quinn wrote: > > I have also seen this referred to as "park and > pool" (short for "park and carpool"). Would this be too confusing of a name > as well? seems comprehensive, I agree there should be the „and“ in the tag Cheers Martin _

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

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: O

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 'collect

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 a

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

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 gr

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 pl

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 el

Re: [Tagging] How to correctly name a forest

Thanks for the tip Marc, that sounds actually the most reasonable solution at the moment. Using place=locality works. But would there be any support for the more specific place=forest, like Mateusz Konieczny mentions? On Wed, 27 Nov 2019 21:50:03 +, marc marc wrote: > Le 27.11.19 à 22:35,

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 relati

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] Route node roles - was Re: Feature Proposal - RFC - hiking_trail_relation_roles

On Sat, 7 Dec 2019 10:30:37 +1100, Warin <61sundow...@gmail.com> wrote: > > 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'

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] Route node roles - was Re: Feature Proposal - RFC - hiking_trail_relation_roles

On 12/7/2019 11:52 AM, s8evq wrote: On Sat, 7 Dec 2019 10:30:37 +1100, Warin <61sundow...@gmail.com> wrote: For nodes .. think the roles of ways should be done first, but some thoughts for later proposal/s. Are they necessary? In my limited experience mapping hiking routes, I have not yet co

Re: [Tagging] Feature Proposal - RFC - park_drive

On 12/6/19 7:59 PM, Paul Johnson wrote: 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.

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

On Sat, 2019-12-07 at 12:28 -0500, Jmapb wrote: > On 12/7/2019 11:52 AM, s8evq wrote: > > On Sat, 7 Dec 2019 10:30:37 +1100, Warin <61sundow...@gmail.com> > > wrote: > > > For nodes .. think the roles of ways should be done first, but > > > some > > > thoughts for later proposal/s. > > > > > > Are

Re: [Tagging] Feature Proposal - RFC - park_drive

On Thu, 2019-12-05 at 14:46 +0100, Martin Scholtes wrote: > Am 05.12.2019 um 12:41 schrieb Sören Reinecke via Tagging: > > > Allows the tag the mapping of carpool meeting points? > The proposal aims at marking parking places where one could meet to > carpool or which explicitly provide for parking

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

Re: [Tagging] Feature Proposal - RFC - park_drive

On 07/12/19 20:55, Martin Koppenhoefer wrote: sent from a phone On 7. Dec 2019, at 09:57, Shawn K. Quinn wrote: I have also seen this referred to as "park and pool" (short for "park and carpool"). Would this be too confusing of a name as well? seems comprehensive, I agree there should be

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 to

Re: [Tagging] Feature Proposal - RFC - park_drive

Am 07.12.2019 um 09:33 schrieb Warin: > park_drive=no for parking of customers only or private. > These should already be tagged with an access tag to say this .. so it > is redundant? This form should not be explicitly stated but rather understood as implicit values. Similar to highway=footway, fo

Re: [Tagging] Feature Proposal - RFC - park_drive

Am 07.12.2019 um 09:55 schrieb Shawn K. Quinn: > > I have also seen this referred to as "park and > pool" (short for "park and carpool"). Would this be too confusing of a > name as well? park_pool I find too confusing -- Mit freundlichen Grüßen Martin Scholtes smime.p7s Description: S/MIME

Re: [Tagging] Feature Proposal - RFC - park_drive

Am 07.12.2019 um 18:59 schrieb brad: > We already have park_ride tag.   I don't see the new tag adding anything? > https://wiki.openstreetmap.org/wiki/Key:park%20ride?uselang=en-US > https://www.openstreetmap.org/way/133916328 "park and ride" rather describes the change to public transport and no

Re: [Tagging] Feature Proposal - RFC - park_drive

Am 07.12.2019 um 19:44 schrieb Philip Barnes: > On Thu, 2019-12-05 at 14:46 +0100, Martin Scholtes wrote: >> Am 05.12.2019 um 12:41 schrieb Sören Reinecke via Tagging: >> >>> Allows the tag the mapping of carpool meeting points? >> The proposal aims at marking parking places where one could meet t

Re: [Tagging] Feature Proposal - RFC - park_drive

On 08/12/19 10:43, Martin Scholtes wrote: Am 07.12.2019 um 09:33 schrieb Warin: park_drive=no for parking of customers only or private. These should already be tagged with an access tag to say this .. so it is redundant? This form should not be explicitly stated but rather understood as implici

Re: [Tagging] Feature Proposal - RFC - park_drive

On 08/12/19 10:54, Martin Scholtes wrote: Am 07.12.2019 um 19:44 schrieb Philip Barnes: On Thu, 2019-12-05 at 14:46 +0100, Martin Scholtes wrote: Am 05.12.2019 um 12:41 schrieb Sören Reinecke via Tagging: Allows the tag the mapping of carpool meeting points? The proposal aims at marking park

Re: [Tagging] Feature Proposal - RFC - park_drive

Hi Martin, my doubt on your proposal is that I think the only useful value would be "designated" (anyway, can you share any example/picture of a sign describing a park specificly designated for carpooling?). But in this case I'd support As far as I know, in a general-use parking (without spe