Re: [Tagging] tagging of one-way cycle lanes

2018-05-10 Thread Marc Gemis
Let me elaborate a bit. When the "lanes" tag was introduced the community choose to only count the "full width segments for motorised traffic". Perhaps because traffic law in some countries (e.g. Belgium [1]) define them that way. So people started using the tag that way and data consumers

Re: [Tagging] tagging of one-way cycle lanes

2018-05-10 Thread Paul Johnson
On Thu, May 10, 2018 at 10:49 PM, Marc Gemis wrote: > I'll agree with all your tags, as ":lanes" is for all lanes, including > cycle lanes. > It's just historically that "lanes" (the tag alone) is only for motorised > traffic. > Right, but *why*? I can't think of any

Re: [Tagging] tagging of one-way cycle lanes

2018-05-10 Thread Marc Gemis
I'll agree with all your tags, as ":lanes" is for all lanes, including cycle lanes. It's just historically that "lanes" (the tag alone) is only for motorised traffic. On Thu, May 10, 2018 at 6:55 AM, Paul Johnson wrote: > I strongly dispute the suggestion in the wiki in

Re: [Tagging] access=disabled

2018-05-10 Thread Nick Bolten
> I would expect a dedicated parking space for disabled drivers to have room for a ramp. AFAIK it is required by the standard specification (in Germany, likely in the EU). I can guarantee you, that is not universal. On Thu, May 10, 2018 at 3:25 PM Martin Koppenhoefer

Re: [Tagging] tagging of one-way cycle lanes

2018-05-10 Thread Paul Johnson
OK, a little more thought on this. On Wed, May 9, 2018 at 11:45 PM, wrote: > If I may correct your suggestion, that’s not quite right. > > The lanes=* key should be used to specify the total number of *marked* [image: > Wikipedia-16px.png] lanes

Re: [Tagging] complete tagging of all 'right of way'-cases

2018-05-10 Thread Paul Johnson
On Thu, May 10, 2018 at 4:57 PM, Martin Koppenhoefer wrote: > > > 2018-05-10 21:03 GMT+02:00 Ruben Kelevra : > >> > which is intrinsically flawed, as it gets added to a node but nodes >> > don’t have a direction. >> Yep. It's a mess and really bad to

Re: [Tagging] complete tagging of all 'right of way'-cases

2018-05-10 Thread Ruben Kelevra
10 May 2018 23:57:00 Martin Koppenhoefer : > generally, a relation is capable of explicitly modelling the > situation, at the cost of complicated/time consuming actions required > from the mapper (and nowadays, with a lot of mapping on mobile phones > going on, average

Re: [Tagging] access=disabled

2018-05-10 Thread Warin
What I have for now : Disabled Parking - Way: 587061339   Tags:     "access"="disabled"     "surface"="paved"     "amenity"="parking"     "capacity:disabled"="3"     "description"="Disabled Parking"     "source"="survey"     "capacity"="3" Ambulance Parking - Way: 584778386   Tags:    

Re: [Tagging] complete tagging of all 'right of way'-cases FOLLOWUP

2018-05-10 Thread Ruben Kelevra
Hey guys, I've took the proposed give_way relation and did the minor tweaks the original author, AMDmi3, probably had in mind to create a stop relation. Sure the == Rationale == I'm too tired now, will do this soon. https://wiki.openstreetmap.org/wiki/Relations/Proposed/stop As always: Feel

Re: [Tagging] access=disabled

2018-05-10 Thread Warin
On 11/05/18 09:01, Martin Koppenhoefer wrote: 2018-05-11 0:48 GMT+02:00 Warin <61sundow...@gmail.com >: On 10/05/18 23:57, Martin Koppenhoefer wrote: I think capacity tagging would be better (if referring to who can park there), or is really the

Re: [Tagging] access=disabled

2018-05-10 Thread Martin Koppenhoefer
2018-05-11 0:48 GMT+02:00 Warin <61sundow...@gmail.com>: > On 10/05/18 23:57, Martin Koppenhoefer wrote: > > > I think capacity tagging would be better (if referring to who can park > there), or is really the access restricted? > > Legally the spaces I am tagging are only meant for disabled

Re: [Tagging] access=disabled

2018-05-10 Thread Warin
On 10/05/18 23:57, Martin Koppenhoefer wrote: sent from a phone On 10. May 2018, at 05:04, Johnparis > wrote: If it's exclusive the normal tagging would be: access=no disabled=yes I think capacity tagging would be better (if referring

Re: [Tagging] access=disabled

2018-05-10 Thread Warin
Disabled parking spaces here are/should be extra wide - to allow for wheelchair mounting/dismounting. A few wheelchair people have vehicles where the wheelchair is mounted to the roof by some winch system - they need the extra room for the wheelchair to go up/down. The rear of most, if not all

Re: [Tagging] access=disabled

2018-05-10 Thread Martin Koppenhoefer
2018-05-10 21:56 GMT+02:00 Nick Bolten : > As a follow-up, it is valuable to know whether a parking space has > dedicated room for a ramp (i.e. one that extends out of the vehicle). > capacity:disabled only describes whether there's dedicated parking for the > disabled. Would

Re: [Tagging] complete tagging of all 'right of way'-cases

2018-05-10 Thread Martin Koppenhoefer
2018-05-10 21:03 GMT+02:00 Ruben Kelevra : > > which is intrinsically flawed, as it gets added to a node but nodes > > don’t have a direction. > Yep. It's a mess and really bad to parse and check for consistency. Also > pretty hard to understand. I fixed many highway=stop nodes

Re: [Tagging] complete tagging of all 'right of way'-cases FOLLOWUP

2018-05-10 Thread Ruben Kelevra
Hey guys, If the first one was TL;DR ... I start with working on this proposal to implement a give_way as a relation. This might be one of many to this topic and I'll follow up every different one when I start working on them. I thought some hours about this old proposal[1] and decided to

Re: [Tagging] complete tagging of all 'right of way'-cases

2018-05-10 Thread Ruben Kelevra
> 10 May 2018 13:54:09 -0700 Tod Fitch : > There are “four way”/“all way” stops in my area where traffic on the > primary road is required to stop. I map those by putting the > highway=stop on the junction node. For those where not all the ways > are required to stop, I put

Re: [Tagging] address property vs. housenumber as a feature

2018-05-10 Thread Andrew Hain
I was recently on holiday in Turin, where addresses are mapped as POIs inside the buildings; a few have been fleshed out as businesses but many shops remain unmapped. I was once able to identify which node to fill out but the others were going to take more time than I was willing to spend. --

Re: [Tagging] complete tagging of all 'right of way'-cases

2018-05-10 Thread Tod Fitch
> On May 10, 2018, at 12:03 PM, Ruben Kelevra wrote: > >> 10 May 2018 19:37:11 Martin Koppenhoefer : >>> On 10. May 2018, at 19:12, Ruben Kelevra wrote: >>> >>> Well, both tags are combined with a direction tag: >>> >>>

Re: [Tagging] access=disabled

2018-05-10 Thread Paul Allen
On Thu, May 10, 2018 at 9:23 PM, Nick Bolten wrote: > I agree that capacity:*=yes isn't as information-rich, it's just the > convention listed on the wiki: https://wiki.openstreetmap.org/wiki/Key: > capacity. > Not the convention but A convention. More precisely, an option:

Re: [Tagging] access=disabled

2018-05-10 Thread Nick Bolten
I agree that capacity:*=yes isn't as information-rich, it's just the convention listed on the wiki: https://wiki.openstreetmap.org/wiki/Key:capacity. I suppose it could help communicate different certainties in mapping. There is *some* value in knowing whether any spaces are available, versus the

Re: [Tagging] access=disabled

2018-05-10 Thread Paul Allen
On Thu, May 10, 2018 at 8:56 PM, Nick Bolten wrote: > Would it be too deeply nested to have capacity:disabled:ramp=yes/no/#? > I don't know about being too deeply nested, but if you consider it hierarchical I'm not happy with the implied semantics that capacity takes a yes/no

Re: [Tagging] access=disabled

2018-05-10 Thread Nick Bolten
As a follow-up, it is valuable to know whether a parking space has dedicated room for a ramp (i.e. one that extends out of the vehicle). capacity:disabled only describes whether there's dedicated parking for the disabled. Would it be too deeply nested to have capacity:disabled:ramp=yes/no/#? On

Re: [Tagging] complete tagging of all 'right of way'-cases

2018-05-10 Thread Paul Johnson
Thank you! I'm a proponent of the relation method myself, though, stupidly, this is the one that got traction somehow. On Thu, May 10, 2018, 12:38 Martin Koppenhoefer wrote: > > > sent from a phone > > > On 10. May 2018, at 19:12, Ruben Kelevra wrote:

Re: [Tagging] complete tagging of all 'right of way'-cases

2018-05-10 Thread Ruben Kelevra
> 10 May 2018 19:37:11 Martin Koppenhoefer : > > On 10. May 2018, at 19:12, Ruben Kelevra wrote: > > > > Well, both tags are combined with a direction tag: > > > > direction=forward/backward > > > which is intrinsically flawed, as it gets added to a

Re: [Tagging] tagging of one-way cycle lanes

2018-05-10 Thread Paul Johnson
On Thu, May 10, 2018, 00:29 wrote: > The “lanes=count” key gives the number of full lanes for motorized > traffic. This gives a good estimate for total carrying capacity for vehicle > traffic on this road for software that isn’t too concerned about the >

Re: [Tagging] complete tagging of all 'right of way'-cases

2018-05-10 Thread Martin Koppenhoefer
sent from a phone > On 10. May 2018, at 19:12, Ruben Kelevra wrote: > > Well, both tags are combined with a direction tag: > > direction=forward/backward which is intrinsically flawed, as it gets added to a node but nodes don’t have a direction. cheers, Martin

Re: [Tagging] brand=* necessary?

2018-05-10 Thread Martin Koppenhoefer
sent from a phone > On 10. May 2018, at 17:41, Frederik Ramm wrote: > > "brand" is an artificial construct of today's global capitalist economy. > I have nothing against OSM recording it, but I'd be loathe to afford the > concept the same importance as corporate PR

Re: [Tagging] complete tagging of all 'right of way'-cases

2018-05-10 Thread Ruben Kelevra
> 10 May 2018 16:58:23 +0200 Mateusz Konieczny > : >> 10. May 2018 14:57 by ru...@vfn-nrw.de : >> # currently missing: right-before-left/left-before-right >> >> Since there is no tag for this, I guess it's reasonable to define >> one the same way

Re: [Tagging] complete tagging of all 'right of way'-cases

2018-05-10 Thread Ruben Kelevra
> 10 May 2018 16:36:46 by Martin Koppenhoefer : >> 10. May 2018 14:57 by RubenKelevra : >> >> # Currently approved tagging >> >> stop signs: >> >> Stop signs are currently tagged at the position of the stop line, >> as a node on the way with the

Re: [Tagging] brand=* necessary?

2018-05-10 Thread Frederik Ramm
Hi, On 05/10/2018 04:23 PM, Martin Koppenhoefer wrote: > It is also a result of how the tags have been introduced, name was used much > earlier than brand (which was originally only proposed for automotive brands) > so that there is some self-amplifying process of people looking around how >

Re: [Tagging] brand=* necessary?

2018-05-10 Thread Tobias Knerr
On 10.05.2018 16:23, Martin Koppenhoefer wrote: > The reason why it is done differently is not an educated decision but the > result of poor presets and mappers filling them in without further reflection. Sure, but uneducated decisions reveal a lot about people's intuitions and interests – two

Re: [Tagging] brand=* necessary?

2018-05-10 Thread Eugene Alvin Villar
This whole discussion reminds me of the following passage from Lewis Carroll's Through the Looking-Glass: The name of the song is called ‘Haddocks' Eyes.’” > > “Oh, that's the name of the song, is it?" Alice said, trying to feel > interested. > > “No, you don't understand,” the Knight said,

Re: [Tagging] complete tagging of all 'right of way'-cases

2018-05-10 Thread Mateusz Konieczny
10. May 2018 14:57 by ru...@vfn-nrw.de : > # currently missing: right-before-left/left-before-right > > Since there is no tag for this, I guess it's reasonable to define one > the same way as for 4-way-stops. I think highway=give_way and > give_way=all or default

Re: [Tagging] complete tagging of all 'right of way'-cases

2018-05-10 Thread Mateusz Konieczny
10. May 2018 14:57 by ru...@vfn-nrw.de : > Hey guys, > # currently missing: priority road by road design > A lowered curb at a street on an intersection makes this road to yield, > without the need for a sign (in Germany) > I think we should tag this separately since

Re: [Tagging] access=disabled

2018-05-10 Thread Mateusz Konieczny
10. May 2018 02:19 by 61sundow...@gmail.com : > Hi, > > I'm tagging a 'disabled parking area' - these are fairly common in my country. > > There appears to be no documented way to tag these. > > I think the present practice is to use the 'access' tag, things like

Re: [Tagging] brand=* necessary?

2018-05-10 Thread Mateusz Konieczny
10. May 2018 12:59 by pla16...@gmail.com : > On Thu, May 10, 2018 at 11:29 AM, Colin Smale <> colin.sm...@xs4all.nl > > > wrote: > >>  >> A "name" is what something is "called" by "others." Which "others" are >> considered, is the real

Re: [Tagging] complete tagging of all 'right of way'-cases

2018-05-10 Thread Martin Koppenhoefer
sent from a phone > On 10. May 2018, at 14:57, RubenKelevra wrote: > > # Currently approved tagging > > stop signs: > > Stop signs are currently tagged at the position of the stop line, as a > node on the way with the direction of traffic flow - which needs to be >

Re: [Tagging] brand=* necessary?

2018-05-10 Thread Mateusz Konieczny
10. May 2018 09:44 by leonkarcher@gmail.com : > Hello, > While I was filling up > this list > > on the wiki with information, > someone on the talk page asked why I was adding brand=* to every object. His >

Re: [Tagging] brand=* necessary?

2018-05-10 Thread Martin Koppenhoefer
sent from a phone On 10. May 2018, at 15:05, Tobias Knerr wrote: >> Imho it us the opposite : name should be added only if it us not the >> same as brand > > That approach is different from real-world usage of the tags and appears > to offer little practical benefit.

Re: [Tagging] access=disabled

2018-05-10 Thread Martin Koppenhoefer
sent from a phone > On 10. May 2018, at 05:04, Johnparis wrote: > > If it's exclusive the normal tagging would be: > > access=no > disabled=yes I think capacity tagging would be better (if referring to who can park there), or is really the access restricted? > >

Re: [Tagging] access=disabled

2018-05-10 Thread Tobias Knerr
On 10.05.2018 05:04, Johnparis wrote: > access=no > disabled=yes > > ...to be consistent with other such, like  > access=no > bus=yes Unlike "bus", "disabled" is not a mode of transport, so it should not be used in the key of access tags. ___ Tagging

Re: [Tagging] brand=* necessary?

2018-05-10 Thread Tobias Knerr
On 10.05.2018 09:52, marc marc wrote: > Imho it us the opposite : name should be added only if it us not the > same as brand That approach is different from real-world usage of the tags and appears to offer little practical benefit. As far as I can tell, many – probably most – mappers look at

[Tagging] complete tagging of all 'right of way'-cases

2018-05-10 Thread RubenKelevra
Hey guys, # Motivation and Context I'm pretty long active in this project. I came across many times a detail of our street infrastructure, which is currently underrepresented in our data: The right of way. This is somewhat important for routers for estimation of travel time, but really

Re: [Tagging] brand=* necessary?

2018-05-10 Thread Christoph Hormann
On Thursday 10 May 2018, Colin Smale wrote: > Referred to, by whom? Who is the persona here? This in OSM is always the local observer. What you might be after is that not every mappable feature in OSM that is occasionally referred to with a verbal identifier has a verifiable name according to

Re: [Tagging] brand=* necessary?

2018-05-10 Thread Christoph Hormann
On Thursday 10 May 2018, Colin Smale wrote: > > I should probably add that what can be considered the name of a > > feature is ultimately the decision of the local community. > > ...as long as there are global ground rules. The autonomy of local > communities, just like democracy, cannot be

Re: [Tagging] brand=* necessary?

2018-05-10 Thread Paul Allen
On Thu, May 10, 2018 at 11:29 AM, Colin Smale wrote: > > A "name" is what something is "called" by "others." Which "others" are > considered, is the real debate here. Is it the council? Is it the residents > within 100m? Is it a tourist who doesn't speak the local

Re: [Tagging] brand=* necessary?

2018-05-10 Thread Andrew Harvey
On 10 May 2018 at 18:33, Christoph Hormann wrote: > On Thursday 10 May 2018, marc marc wrote: > > Imho it us the opposite : name should be added only if it us not the > > same as brand > > Exactly. Nme tags are for identifiers that identify the individual > object, not a whole

Re: [Tagging] brand=* necessary?

2018-05-10 Thread Colin Smale
On 2018-05-10 12:01, Christoph Hormann wrote: > I should probably add that what can be considered the name of a feature > is ultimately the decision of the local community. ...as long as there are global ground rules. The autonomy of local communities, just like democracy, cannot be unbounded.

Re: [Tagging] brand=* necessary?

2018-05-10 Thread Christoph Hormann
On Thursday 10 May 2018, Simon Poole wrote: > > It can be argued that the name suggestion index it is a bit at odds > with the point raised be Marc and Christoph, but for many of the > stores/facilities in question there is no difference, and in any case > I've been toying with the idea of

Re: [Tagging] brand=* necessary?

2018-05-10 Thread Simon Poole
On top of all what has already been said, what you -should- be doing (after discussion) is adding the tags to https://github.com/osmlab/name-suggestion-index instead of embarking on a lone crusade to show everybody the light. It can be argued that the name suggestion index it is a bit at odds

Re: [Tagging] brand=* necessary?

2018-05-10 Thread Christoph Hormann
On Thursday 10 May 2018, Leon Karcher wrote: > > Also note the edits of DP14_BrandUnification are an undiscussed > > mechanical edit and should be reverted. > > Undiscussed? See > https://lists.openstreetmap.org/pipermail/tagging/2018-May/036034.htm >l See

Re: [Tagging] brand=* necessary?

2018-05-10 Thread Leon Karcher
On Thursday 10 May 2018, Christoph Hormann wrote: > Also note the edits of DP14_BrandUnification are an undiscussed > mechanical edit and should be reverted. Undiscussed? See https://lists.openstreetmap.org/pipermail/tagging/2018-May/036034.html And it is only partly mechanical since I'm

Re: [Tagging] brand=* necessary?

2018-05-10 Thread Christoph Hormann
On Thursday 10 May 2018, marc marc wrote: > Imho it us the opposite : name should be added only if it us not the > same as brand Exactly. Nme tags are for identifiers that identify the individual object, not a whole class of objects. Also note the edits of DP14_BrandUnification are an

Re: [Tagging] brand=* necessary?

2018-05-10 Thread marc marc
Imho it us the opposite : name should be added only if it us not the same as brand But some render doesn't use brand, this need to fix to avoid loosing data on the map Le 10 mai 2018 à 09:45, Leon Karcher > a écrit : Hello, While I

[Tagging] brand=* necessary?

2018-05-10 Thread Leon Karcher
Hello, While I was filling up this list on the wiki with information, someone on the talk page asked why I was adding brand=* to every object. His argument was that the brand tag is a duplicate of the name tag in most cases and I should only add it if