[Tagging] brand=* necessary?

[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 the name differs. (see example
) I kind of see his point,
but what do you think? Should we only add a brand tag if it differs from
the name?

I thought adding brand= to all 'branded' objects would be helpful because
it goes hand in hand with brand:wikidata= which I would add to all of them.

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

Re: [Tagging] brand=* necessary?

[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 
mailto:leonkarcher@gmail.com>> a écrit :

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 the name differs. (see 
example) I kind of see his 
point, but what do you think? Should we only add a brand tag if it differs from 
the name?

I thought adding brand= to all 'branded' objects would be helpful because it 
goes hand in hand with brand:wikidata= which I would add to all of them.

Greetings,
Leon.
___
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] brand=* necessary?

[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 undiscussed 
mechanical edit and should be reverted.

-- 
Christoph Hormann
http://www.imagico.de/

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

Re: [Tagging] brand=* necessary?

[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 reviewing all objects.

2018-05-10 10:33 GMT+02:00 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 undiscussed
> mechanical edit and should be reverted.
>
> --
> Christoph Hormann
> http://www.imagico.de/
>
> ___
> 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] brand=* necessary?

[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

https://wiki.openstreetmap.org/wiki/Automated_Edits_code_of_conduct

for the documentation and discussion requirements of mechanical edits.

> And it is only partly mechanical since I'm reviewing all objects.

Wow - i wish i had that kind of travel budget.

-- 
Christoph Hormann
http://www.imagico.de/

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

Re: [Tagging] brand=* necessary?

[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 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 supporting brands in their own right,
independently of a name .

Simon

Am 10.05.2018 um 10:47 schrieb 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 reviewing all objects.
>
> 2018-05-10 10:33 GMT+02:00 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 undiscussed
> mechanical edit and should be reverted.
>
> -- 
> Christoph Hormann
> http://www.imagico.de/
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org 
> https://lists.openstreetmap.org/listinfo/tagging
> 
>
>
>
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging



signature.asc
Description: OpenPGP digital signature
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] brand=* necessary?

[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 supporting brands in their own
> right, independently of a name .

I should probably add that what can be considered the name of a feature 
is ultimately the decision of the local community.

-- 
Christoph Hormann
http://www.imagico.de/

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

Re: [Tagging] brand=* necessary?

[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. OSM is a global
resource. What's a local community, anyway? We don't want people in one
city doing things differently from another city 10km away in the same
country, do we? 

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
language? Who gets priority? This is something that cartographers (AKA
humans determining the rendering) must decide, depending on who the map
is for. 

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

Re: [Tagging] brand=* necessary?

[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 class of objects.
>

Agreed. Typically I would tag like this:

name=McDonalds Circular Quay
brand=McDonalds
branch=Circular Quay
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] brand=* necessary?

[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 language? Who gets
> priority? This is something that cartographers (AKA humans determining the
> rendering) must decide, depending on who the map is for.
>
> I would suggest that the name is what it says on the sign.  Because if you
have a hardcopy map, or there's no
GPS signal on your phone, the sign is what you're looking for.  If the
locals call it something other than what is
on the sign, that is what loc_name is for (in some circumstances alt_name
or old_name might be more
appropriate).  If a mapper puts something else in the name field than what
it says on the sign, I get an urge
to meet that mapper and shake him/her warmly by the neck because that
information is of no use to me.

Where your questions arise is where there is no sign.  So if you have a
hardcopy map (or no GPS on your
phone) what would you rather see on the map when you ask somebody where X
is?  What the locals call
the place, because most of the people you'll see on the street will be
locals?  What the council calls it,
although the chances of encountering a council employee are small?  What
other tourists who ALSO do not
know what the name is call it?  Hint: those other tourists call it what's
on the map they have or "I don't know
what it's called."

This isn't rocket surgery.  We map reality and approximate to reality if we
must.  So the name comes from
signage, if there is any, or from locals if there is no signage, or from
the council if the locals don't have a
name for it.  Preferably by using loc_name (and maybe official_name for
cases where only the council has
a name for it which locals don't know and there is no signage).

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

Re: [Tagging] brand=* necessary?

[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 unbounded. OSM is a
> global resource. What's a local community, anyway? We don't want
> people in one city doing things differently from another city 10km
> away in the same country, do we?

The definition of a name is pretty universal (as the verbal identifier a 
certain specific object is referred to with).  There is not much local 
variation in that.

> 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
> language? Who gets priority? This is something that cartographers
> (AKA humans determining the rendering) must decide, depending on who
> the map is for.

You are mixing the geographic concept of a name with the cartographic 
concept of a label here - which is of course something a lot of mappers 
do when they choose name tags.

-- 
Christoph Hormann
http://www.imagico.de/

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

Re: [Tagging] brand=* necessary?

[Colin Smale]

On 2018-05-10 13:17, Christoph Hormann wrote:

> 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 unbounded. OSM is a
> global resource. What's a local community, anyway? We don't want
> people in one city doing things differently from another city 10km
> away in the same country, do we?

The definition of a name is pretty universal (as the verbal identifier a

certain specific object is referred to with).  There is not much local 
variation in that. 
Referred to, by whom? Who is the persona here? What's the use case? 

> 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
> language? Who gets priority? This is something that cartographers
> (AKA humans determining the rendering) must decide, depending on who
> the map is for.
> You are mixing the geographic concept of a name with the cartographic 
> concept of a label here - which is of course something a lot of mappers 
> do when they choose name tags.

Interesting - my intention was the exact opposite. The point I was
trying to make (and I think we agree on this) is that a simple "name" is
subjective. Different renderers will make different decisions about what
data to add to the resulting map, according to what they want to
portray. 

A physical sign is analogous to a label - it is a depiction of an
attribute in a certain context. The "facts" are simply that there is a
sign with certain characters on it, in a style that leads us to derive
that this is the name of an object to which it is attached or adjacent.
That is subtly different to the "facts" about the name of the object,
which can be subjective. It depends on who you ask, and in what context.
Multiple different answers may be equally correct, in different
contexts.___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] brand=* necessary?

[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 OSM's verifiability principle.  There you are 
correct.  But human use of names has the tendency to converge to a 
uniform name in many cases so if there are verbal identifiers used 
there is also often a verifiable name.

-- 
Christoph Hormann
http://www.imagico.de/

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

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

[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 important for getting knowledge for live turn-to-turn
navigation, based on our data, since often an audible direction isn't
necessary, if just the main-road does a curve.

I guess it's currently often extrapolated from the highway tag, e.g. a
tertiary is assumed to be the main road while residential roads are
expected to be a "turn" which needs to be mentioned to the driver.


# 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
stopped.

yield signs:

Yield signs are tagged the same way stop signs are tagged.

first come, first serve - 4-way-stops (USA):

Those are tagged with a tag on the intersection-node and a stop=all.

a priority road:

There's a tag called priority_road=designated which is used to tag a
way which is then considered as a priority road. Stop and yield signs
are then tagged additionally in the roads which lead to this way.


# Problems with the current approaches

The yield/stop signs added to the road as nodes are hard to parse,
since the router/parser need to match them to the next intersection.

The priority_road=designated is hardly used at all (just 21 900
worldwide) which makes me wonder if this tag designed very well.

There is no tag for intersections with right-before-left or
left-before-right right of way.

The tagging of one way with priority_road and nodes on the other way,
adding give_way or stop signs lead to redundant data.

Currently, I hardly tag this feature, like most mappers, because it's
pretty cumbersome to take pictures of that information, verify the exact
location on the intersection on an aerial picture and pinpoint it with a
give_way/stop node, while this gives no advantage, 'cause it's not
processed by anyone at the moment.


# Relation approach

There is a proposal in a draft state which add a similar functionality
like the restriction relations to add the exact right of way to
intersections with a priority-road and stop/give_way streets:

https://wiki.openstreetmap.org/wiki/Relations/Proposed/Give_way

While I don't think there's a reason to add those relations to any
roundabout/mini_roundabout. But this proposal makes sense on circular
junctions which have currently no definition of the right of way by the
junction tag alone. 

The circular junction is sometimes used in Germany for junctions which
has no "roundabout" signs but yield signs to apply pretty much the same
rules like on a roundabout. It also might have traffic lights. So a
give_way relation could help to make define the right-of-way in
those cases.


# 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 there are no signs
involved. I have currently no idea how to tag this.


# 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 (analog to maxheight) makes the most sense
(currently give_way=all is used 3 times worldwide).

If right-before-left or left-before-right should be decided by the
national boundary, not on any intersecting node. 


# currently missing: a traffic light with its right-of-way definition
when off

There are 3 types of this in Germany: Stop signs and priority road,
give_way and priority road and no signs (right-before-left). Since
traffic lights are off overnight on many locations, this might not
have a high priority, but it's also nice to have in the database. 


# Rationality for this discussion

I'm using StreetComplete for much mobile mapping and it's actually
awesome to add many small details on the go without taking pictures,
open them in JOSM etc. what I used to do beforehand.

StreetComplete is surly, not able to handle all complex intersections,
but it might be able to filter them, to just get the very easy to
extend ones, where just 2-4 way meet with one single node at the
intersection.

But adding a functionality like this it needs to store the information
for each case, so a tag like priority_road=designated cannot be
implemented, since in the case it's not the priority_road, there's no
tag which can store this information in the database.

Since it's always nice to have a definitive answer stored in the
database, it would be better if we can agree on a solution which has
one for each case. 


# Let's discuss

I would like to hear some other opinions on that topic, since the
current approach: Taking pictures and map that information at hom

Re: [Tagging] brand=* necessary?

[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 the store's
sign and add that appellation to the name tag, no matter whether it's
the name of an individual store or the brand of a chain of stores.

It turns out this usage matches the usual expectations of data consumers
and map users, so I don't see a strong incentive to change it.

I appreciate that there's technically a distinction to be made. And of
course I'm also ok with people who care about these subtleties adding
operator=* and brand=* tags. But personally, I find the intricacies of
corporate organization and branding very uninteresting and would like to
stick with a solution that allows most mappers to not care about it.

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

Re: [Tagging] access=disabled

[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 mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] access=disabled

[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? 


> 
> ...to be consistent with other such, like 
> access=no
> bus=yes
> 
> Though I would argue that they all should use the access: prefix in this case
> 
> access=no
> access:disabled=yes


there are some of these
https://taginfo.openstreetmap.org/keys/access%3Adisabled
but the mostly used value is “no”, probably this is an inconsistency (not about 
legal access but about accessibility)


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

Re: [Tagging] brand=* necessary?

[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.


Although this is different from what is often done, I support Marc’s notion. 
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.

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 
things are done and doing it similarly. And maybe most important, osm carto 
doesn’t render brands, which is sufficient reason for many maybe most mappers 
to prefer name.

The transition would not have to be in a rush, but overall I believe there will 
be benefit from storing information semantically more accurate, e.g. it would 
show that we are actually still missing a lot of names for things where there 
is something else in the name tag.

cheers,
Martin



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

Re: [Tagging] brand=* necessary?

[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 
> argument was that the brand tag is a duplicate of the name tag in most cases 
> and I should only add it if the name differs. (see > example 
> > ) I kind of see his point, 
> but what do you think? Should we only add a brand tag if it differs from the 
> name?
> I thought adding brand= to all 'branded' objects would be helpful because it 
> goes hand in hand with brand:wikidata= which I would add to all of them.
> Greetings,> Leon.




brand tag is typically ignored and everybody tags and uses name tag (even in 
situations where 


it is disputable is it really name)




but if somebody wants adding brand tag is not harmful (only in cases where edit 
is done after

verification, not added in blind remote edit based solely on name 
match/similarity)





PS




https://wiki.openstreetmap.org/wiki/Brands 
 looks like redoing

https://github.com/osmlab/name-suggestion-index 
 in worse format

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

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

[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
> stopped.
> 
> yield signs:
> 
> Yield signs are tagged the same way stop signs are tagged.



this tagging only works in the case of one way streets or separate 
carriageways, otherwise it is not clear to which direction the tags apply (you 
have to look for the closest intersection and guess, which will often work but 
isn’t a real solution)


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

Re: [Tagging] brand=* necessary?

[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 debate here. Is it the council? Is it the residents 
>> within 100m? Is it a tourist who doesn't speak the local language? Who gets 
>> priority? This is something that cartographers (AKA humans determining the 
>> rendering) must decide, depending on who the map is for.
>>
> I would suggest that the name is what it says on the sign.  Because if you 
> have a hardcopy map, or there's no
> GPS signal on your phone, the sign is what you're looking for.  If the locals 
> call it something other than what is
> on the sign, that is what loc_name is for (in some circumstances alt_name or 
> old_name might be more
> appropriate).  If a mapper puts something else in the name field than what it 
> says on the sign, I get an urge
> to meet that mapper and shake him/her warmly by the neck because that 
> information is of no use to me.




Note that name used and tagged is frequently part of what sign displays.




For example: Starbucks vs Starbucks Coffee



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

Re: [Tagging] access=disabled

[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 
> customers, delivery, forestry all specify a restricted access.
>
> There are some 400 uses of access=disabled according to tag info.
>
> Thought on any other methods?
>

 
https://wiki.openstreetmap.org/wiki/Tag:amenity%3Dparking 

documents tagging capacity and capacity:disabled (in this case - both with the 
same value)
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

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

[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 there are no signs
> involved. I have currently no idea how to tag this.
>




https://wiki.openstreetmap.org/wiki/Tag:highway%3Dgive_way 





Wiki already documents that highway=give_way is for  


"Used to mark give way (also known as yield) signs or markings"




I would consider it as a form of marking, close to painted signs like at

https://wiki.openstreetmap.org/wiki/File:Junction_of_Cleveland_Road_and_Ratcliffe_Close_-_geograph.org.uk_-_1518836.jpg
 


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

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

[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 (analog to maxheight) makes the most sense
> (currently give_way=all is used 3 times worldwide).
>
> If right-before-left or left-before-right should be decided by the
> national boundary, not on any intersecting node. 
>




give_way=no_priority? 





PS You may wish to make shorter mails in future and try to tackle one issue at 
once 


(maybe with link to essay describing all related concepts).

It will avoid tl;dr problem.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] brand=* necessary?

[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, looking a little vexed.
> “That's what the name is called. The name really is ‘The Aged Aged Man.’”
>
> “Then I ought to have said ‘That's what the song is called’?” Alice
> corrected herself.
>
> “No, you oughtn't: that's quite another thing! The song is called ‘Ways
> And Means’: but that's only what it's called, you know!”
>
> “Well, what is the song, then?” said Alice, who was by this time
> completely bewildered.
>
> “I was coming to that,” the Knight said. “The song really is ‘A-sitting On
> A Gate’: and the tune's my own invention.”
>


On Thu, May 10, 2018 at 3:44 PM, Leon Karcher 
wrote:

> 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 the name differs. (see
> example ) I kind of see
> his point, but what do you think? Should we only add a brand tag if it
> differs from the name?
>
> I thought adding brand= to all 'branded' objects would be helpful because
> it goes hand in hand with brand:wikidata= which I would add to all of them.
>
> Greetings,
> Leon.
>
> ___
> 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] brand=* necessary?

[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 factors that deserve to be taken into account.

When mappers can fill in data without further reflection and still
produce useful results (which I argue is the case here) then that
strikes me as a huge usability win!

> It is also a result of how the tags have been introduced

It's true that brand was introduced later than name, and that it has
been at a disadvantage due to rendering support and the key's history.

That's probably not a coincidence, though. I assume it was introduced
and adopted more slowly precisely because not that many people were
interested in making the distinction in the first place.

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

Re: [Tagging] brand=* necessary?

[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 
> things are done and doing it similarly. And maybe most important, osm carto 
> doesn’t render brands, which is sufficient reason for many maybe most mappers 
> to prefer name.

"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 departments do.

Knowing what brand a store belongs to is only worth anything if you
combine that with OSM-external "knowledge" that you have gained from
marketing material or past experiences with different branches of the
same brand. It is not a useful fact that helps a visitor who doesn't
know anything about the brand's supposed image.

Bye
Frederik

-- 
Frederik Ramm  ##  eMail frede...@remote.org  ##  N49°00'09" E008°23'33"

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

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

[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 direction of traffic flow - which
>> needs to be stopped.
>> 
>> yield signs:
>> 
>> Yield signs are tagged the same way stop signs are tagged.
> this tagging only works in the case of one way streets or separate
> carriageways, otherwise it is not clear to which direction the tags
> apply (you have to look for the closest intersection and guess, which
> will often work but isn’t a real solution)

Well, both tags are combined with a direction tag:

direction=forward/backward


Best regards,

Ruben

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

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

[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 as for 4-way-stops. I think highway=give_way and
>> give_way=all or default (analog to maxheight) makes the most sense
>> (currently give_way=all is used 3 times worldwide).
>>
>> If right-before-left or left-before-right should be decided by the
>> national boundary, not on any intersecting node.
> give_way=no_priority? 
Yeah, this one sounds better.

> 10 May 2018 16:53:30 by 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 there are no signs
>> involved. I have currently no idea how to tag this.
> Wiki already documents that highway=give_way is for  
> "Used to mark give way (also known as yield) signs or markings"
> 
> I would consider it as a form of marking, close to painted signs like
> at
> 
> https://wiki.openstreetmap.org/wiki/File:Junction_of_Cleveland_Road_and_Ratcliffe_Close_-_geograph.org.uk_-_1518836.jpg
> 

Thanks for the hint, this sounds like we should add a subtag, like
give_way:type=[curb, road_marking, sign, inferred]
or give_way=[curb, road_marking, sign, inferred] (since this tag has
zero usage currently this also works for stop=* or stop:type=*.

The last value can be used when it's obvious, but no special markings
can be found (already discovered two such spots in my surroundings
today).

Since I'm not a native English speaker, correct me when I misuse this
word. :)

> 10 May 2018 16:53:30 by Mateusz Konieczny :
> PS You may wish to make shorter mails in future and try to tackle one
> issue at once 
>
> (maybe with link to essay describing all related concepts).
>
> It will avoid tl;dr problem.

Well, thanks. I thought a not so cluttered way to deliver all
necessary information would be better. It's actually hard to break
down since all approaches currently focus on just one specific topic.
I like to fix this with a step back and a look at the whole picture, to
find an evenly acceptable solution for all cases.


Best regards,


Ruben






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

Re: [Tagging] brand=* necessary?

[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 departments do.
> 
> Knowing what brand a store belongs to is only worth anything if you
> combine that with OSM-external "knowledge" that you have gained from
> marketing material or past experiences with different branches of the
> same brand. It is not a useful fact that helps a visitor who doesn't
> know anything about the brand's supposed image.


this is partly true, more for fields where the offered goods are more or less 
the same (e.g. gasoline brands, apart from what advertising tries to convey, 
your car will run largely the same with differently branded gasoline) and less 
if you have specific needs (e.g. if you are in holiday and need your car 
repaired, you might be interested to go to an official workshop of your car’s 
brand to get original parts, or if you need a mobile phone contract you might 
want to go to a distributor of a specific brand, similarly if you are looking 
for a specific bank or insurance branch, others won’t do).

Besides this, it isn’t improbable that you already have acquired some knowledge 
and expectations based on previous experiences and are looking for a specific 
supermarket brand or chain store, e.g. fashion.


I don’t think it is something that is questioned in general, I’d read this 
discussion that the question is how to store it.


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

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

[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
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

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

[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
> details, or simply older software that doesn’t know about the :lanes suffix.
>
Conflating lane count with lane access is both inaccurate and confusing.

> If there are keys with the :lanes suffix present, then number of lanes
> specified by all of them must be the same, and the total number of lanes
> (including cycle lanes and such) is given by the number of lanes defined in
> the tags, there is no need to repeat the same number again in the
> lanes=count tag. If you simply make the lanes=count tag always represent
> the same number as the lanes specified in the :lanes suffix keys, then you
> could simply omit it completely, as it’s just redundant
>
Every editor that handles lane tagging will (quite correctly) ensure your
lane counts square up to the lanes tagging or loudly complain.

> Changing the meaning of the lanes=count tag after many millions of them
> have already been created makes the key useless as it can’t be relied on
> anymore.
>
I'd argue this has always been the case thanks to this glaring omission.
Just because someone doesn't think all lanes should count just because
bicycle thought that was a smart idea doesn't mean that it actually is, or
that leaving this information out makes lane guidance easier (it doesn't,
it makes it wrong).



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

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

[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 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 which are
actually the intersection nodes, so even the primary_road was
considered to stop there... which makes no sense.

What do you think about the relation-approach designed by AMDmi3:

https://wiki.openstreetmap.org/wiki/Relations/Proposed/Give_way



Best regards,

Ruben

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

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

[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:
> >
> > 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
> ___
> 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] access=disabled

[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 Thu, May 10, 2018 at 7:47 AM Mateusz Konieczny 
wrote:

>
> 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
> customers, delivery, forestry all specify a restricted access.
>
> There are some 400 uses of access=disabled according to tag info.
>
> Thought on any other methods?
>
>
> https://wiki.openstreetmap.org/wiki/Tag:amenity%3Dparking
> documents tagging capacity and capacity:disabled (in this case - both with
> the same value)
> ___
> 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] access=disabled

[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 value.  And
how do you
handle it if some of the capacity:disabled=5 have space for a ramp but
others don't?

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

Re: [Tagging] access=disabled

[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 exact number.

Combining `capacity:disabled=5` with `capacity:disabled:ramp=4` would imply
that 1 disabled parking space doesn't have dedicated room for a van ramp,
if I understand your question right.

On Thu, May 10, 2018 at 1:04 PM Paul Allen  wrote:

> 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 value.  And
> how do you
> handle it if some of the capacity:disabled=5 have space for a ramp but
> others don't?
>
> --
> Paul
>
> ___
> 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] access=disabled

[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:
capacity:disabled=yes/no/number.


> I suppose it could help communicate different certainties in mapping.
> There is *some* value in knowing
>
whether any spaces are available, versus the exact number.
>

There's a benefit to knowing if there are/are not disabled spaces available
rather than not knowing at all.
But if you know the number it's far better to use that rather than "yes."

Combining `capacity:disabled=5` with `capacity:disabled:ramp=4` would imply
> that 1 disabled parking space doesn't have dedicated room for a van ramp,
> if I understand your question right.
>

That was what I had in mind.  Because capacity:disabled=5 and
capacity:disabled:ramp=yes would imply
they all have room for a ramp, which may not be the case (and it's probably
better to give the number for ramps
anyway, so there is no ambiguity).  Leaving room for a ramp means less room
for parking in general, so you
might get 5 disabled spaces and only 2 with room for ramps.

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

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

[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:
>>> 
>>> direction=forward/backward  
>> 
>> 
>> 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 which are
> actually the intersection nodes, so even the primary_road was
> considered to stop there... which makes no sense.
> 
> What do you think about the relation-approach designed by AMDmi3:
> 
> https://wiki.openstreetmap.org/wiki/Relations/Proposed/Give_way
> 

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 the 
highway=stop on the “limit line”. My reading of the wiki a while back implied 
that was all that was needed. More recently, based on mail list discussions, I 
have been adding direction=forward/backward on those too.

Not sure why a relation is needed for these as it is pretty simply to tag and, 
I assume, for a data consumer to use the current tagging.


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

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

[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.


--

Andrew



From: Martin Koppenhoefer 
Sent: 09 May 2018 22:41
To: tagging@openstreetmap.org
Subject: [Tagging] address property vs. housenumber as a feature

Is there a way to indicate a housenumber is a feature, vs. a property?

In many places, housenumbers refer to buildings or sites, and you might omit 
addresses on contained features (because you can hope for inheritance from the 
containing address object). Unfortunately the situation in Italy is a bit 
different in this regard, as housenumbers are assigned to entrances (either 
site or building) and even potential entrances.

This leads to the common situation that the same housenumber appears multiple 
times (on the entrance as a feature and on the contained features like 
businesses as an address property). Businesses being accessible through 
different housenumbers is not a rare exception but rather common. They deal 
with it differently: while some list all or a bunch of the numbers as their 
address, others choose one (often but not always the main entrance).

If you map the POI as an area, you might often be able to represent the numbers 
that are part of the area (unless they are not on the ground floor, or the 
building is not directly on the street hence the number is typically at a gate 
on the site perimeter). Still most people (including myself) don’t map small 
businesses in shared buildings as areas, so duplicated address information is 
common.

Some of my fellow mappers are dealing with this by adding the poi information 
to the entrance, but this is unsatisfactory because of several reasons:

- it can only deal with cases where one number is for one business, it doesn’t 
work for multiple entrances or numbers and it doesn’t work for shared entrances 
(one number for several pois)

- it is topologically wrong (the poi is not on the perimeter, neither inside 
nor outside, it is inside). The poi is also not the same as the entrance, if 
you add entrance=* it is an entrance and should not get other tags for a 
different object (the poi) like name etc.

Thoughts?

Cheers,
Martin

sent from a phone
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging
Tagging Info Page - 
OpenStreetMap
lists.openstreetmap.org
Your email address: Your name (optional): You may enter a privacy password 
below. This provides only mild security, but should prevent others from messing 
with your subscription.


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

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

[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 the highway=stop on the “limit line”. My
> reading of the wiki a while back implied that was all that was
> needed. More recently, based on mail list discussions, I have been
> adding direction=forward/backward on those too.
> 
> Not sure why a relation is needed for these as it is pretty simply to
> tag and, I assume, for a data consumer to use the current tagging.
I think we're fine with more than one solution, for a simple 4-way-stop
a node in the intersecting-node and direction=all should be enough for
data consumer.

Analog to this, a tag on the intersecting node of two streets with a
priority-to-the-right should be enough as well. I guess
'highway=give_way; give_way=right' or similar should be okay. If there's
a left-hand-country using this law in the opposite direction an analog
'highway=give_way; give_way=left' would be added.

But this neither allows many options to add nor to handle special
cases. So we need more.

Best regards,

Ruben

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

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

[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
update[2] it.

It now includes the ability to tag the 
* used sign (directly at the intersection)
* road markings, like a curb or a dotted or solid line
* main operational function of this intersection, like a traffic light.

The last one is necessary because we got intersection with stop and
yield signs here, which are located at the traffic lights. So if the
traffic lights are off (in the night or just non-operational) the signs
located at the traffic lights are applied.

When the traffic lights are shut of every night, we can add that
information to the node at the via tag, to disable the traffic light
tag in those time periods for the routers. Then the give_way- or
stop-relations come into action.

It now also includes lists of cases where it should be used and cases
where it shouldn't. Explicitly changing the recommendation to NOT use
it on roundabout & removing the example for it).

It's also recommending the simple solutions for a priority-to-the-right
(not yet written) and the all-way_stop.

If the mapper wants to map more details, like the curbs, signs,
hour_on/off or the class of vehicles where this applies, we have to go
the relation way and create up to 4 relations to one intersection - I
just don't see a simpler way with the same flexibility.


[1] https://wiki.openstreetmap.org/wiki/Relations/Proposed/Give_way
[2] https://bit.ly/2IrMh3g (just a shorted link to a diff)

As always: Feel free to fix logic and language issues in the proposal -
I'm not a native speaker, there might be many.

I hope for more feedback on this from you, guys.


Best regards

Ruben

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

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

[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 which are
> actually the intersection nodes, so even the primary_road was
> considered to stop there... which makes no sense.
>
> What do you think about the relation-approach designed by AMDmi3:
>
> https://wiki.openstreetmap.org/wiki/Relations/Proposed/Give_way




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
editor relation support is even worse). Personally, I am mapping in a
context with a lot of oneway streets, so it often is not an issue to just
use a node close to the intersection, I believe if you can, you should
avoid relations because it makes the map more complex for others to
understand and modify (maybe with the exception of well supported
multipolygon relations).

The particular proposal seems thought through, but might eventually be
overengineered. In the simplest representation you would only need a via
node (at the stop line) and a from way (ending at the stop line) and be
done.
I am not sure how several via ways should work together with several from
and to ways, and I guess even if it works, it will be complicated to
evaluate (for other mappers) and several very simple relations (only from
way and via node) would probably be much easier to understand (at the cost
of having to split the ways at the stop/via).

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

Re: [Tagging] access=disabled

[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 it be too deeply nested to have
> capacity:disabled:ramp=yes/no/#?
>


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).

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

Re: [Tagging] access=disabled

[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 disabled spaces face the traffic lane .. so 
a ramp could use that, temporally stopping traffic.


On 11/05/18 08:24, Martin Koppenhoefer wrote:



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 it be too deeply nested
to have capacity:disabled:ramp=yes/no/#?



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).


Cheers,
Martin




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

Re: [Tagging] access=disabled

[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 to who can park 
there), or is really the access restricted?

Legally the spaces I am tagging are only meant for disabled parking.





...to be consistent with other such, like
access=no
bus=yes

Though I would argue that they all should use the access: prefix in 
this case


access=no
access:disabled=yes


That is not consistent with access=customer/forestry/delivery/agricultural?






there are some of these
https://taginfo.openstreetmap.org/keys/access%3Adisabled
but the mostly used value is “no”, probably this is an inconsistency 
(not about legal access but about accessibility)


The no value is some 500, combine values yes and designated and you get 
~800.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] access=disabled

[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 parking.
>


i.e. it is forbidden to cross the parking by foot if you are not disabled?




there are some of these
https://taginfo.openstreetmap.org/keys/access%3Adisabled
but the mostly used value is “no”, probably this is an inconsistency (not
about legal access but about accessibility)

The no value is some 500, combine values yes and designated and you get
~800.


according to the wiki, agricultural, forestry, customers etc. are _values_
for access tags:
https://wiki.openstreetmap.org/wiki/Key:access#Access_tag_values
(agricultural is also a vehicle class though).


"disabled" are a class of users (see "by use"):
https://wiki.openstreetmap.org/wiki/Key:access#Access_tag_values

Their documented tag is "disabled=*"
https://taginfo.openstreetmap.org/keys/disabled

Why would we want to push tag fragmentation by promoting a different tag
with not even half the usage and a third of questionable "no" values?

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

Re: [Tagging] access=disabled

[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 access restricted?

Legally the spaces I am tagging are only meant for disabled parking.



i.e. it is forbidden to cross the parking by foot if you are not disabled?
and if an area is tagged amenity=parking, access=customers ... same 
problem.







there are some of these
https://taginfo.openstreetmap.org/keys/access%3Adisabled 

but the mostly used value is “no”, probably this is an inconsistency 
(not about legal access but about accessibility)


The no value is some 500, combine values yes and designated and you 
get ~800.



according to the wiki, agricultural, forestry, customers etc. are 
_values_ for access tags:

https://wiki.openstreetmap.org/wiki/Key:access#Access_tag_values
(agricultural is also a vehicle class though).


And some are using disabled as a value too... which was my suggestion .. 
see the subject of the thread.

Too me this is a logical extension of the present system of use ..



"disabled" are a class of users (see "by use"):
https://wiki.openstreetmap.org/wiki/Key:access#Access_tag_values

Their documented tag is "disabled=*"
https://taginfo.openstreetmap.org/keys/disabled


This is 'documented"? Ha. Look at the page for the 'documentation'. I 
have no idea what it is at all

https://wiki.openstreetmap.org/wiki/Key%3Adisabled

One line saying

"disabled=* is used e.g. if there are exceptions for parking rules. "

Really ? What does that mean ??? just going on this 'documentation' I 
could not use it .. in any place.


So far the only 'suggestions' I have that work for me are ;

use of access=disabled .. some 400 uses
capacity ... needs two entries to specify it and you need to know the 
numbers otherwise it could indicated spaces for others which is not the 
case. Only works for things that have a capacity?



I note the use of access=emergency .. some 2,500 uses ... no 
documentation. I have used this on a parking area.
And I note this is documentation as a 'by use' ... thing too .. very 
inconsistent with other values...
Why the difference between these things .. they all look like they 
should be in the same kind of system - either they should all be values 
or not values?


I'll need to think on it some more. :) Not fixed on anything for the 
moment. But I'd like it to be easy.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

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

[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 free to fix logic and language issues in the proposal -
I'm not a native speaker, there might be many.

I hope for more feedback on this from you, guys.


Best regards

Ruben

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

Re: [Tagging] access=disabled

[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:
    "access"="emergency"
    "capacity:emergency"="3"
    "surface"="paved"
    "amenity"="parking"
    "description"="Ambulance Only"
    "source"="LPI Imagery + knowledge"
    "capacity"="3"

15 min parking Way: 584778387
  Tags:
    "maxstay"=".25"
    "source"="LPI Imagery + knowledge"
    "surface"="paved"
    "amenity"="parking"

Not certain of the 15 minute parking capacity .. would need to look .. 
too much of a hurry when I have been there to note the capacity. Left by 
a different way.


On 10/05/18 13:04, Johnparis wrote:

If it's exclusive the normal tagging would be:

access=no
disabled=yes

...to be consistent with other such, like
access=no
bus=yes

Though I would argue that they all should use the access: prefix in 
this case


access=no
access:disabled=yes





On Thu, May 10, 2018, 02:51 Andrew Davidson > wrote:




On 10/5/18 10:34, Warin wrote:
>
> and then the consumer would need to test it for exclusivity.
>

That does appear to be the logic applied.



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

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

[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 editor relation support is even worse). Personally,
> I am mapping in a context with a lot of oneway streets, so it often
> is not an issue to just use a node close to the intersection, I
> believe if you can, you should avoid relations because it makes the
> map more complex for others to understand and modify (maybe with the
> exception of well supported multipolygon relations).
I understand you're concerned, but we already have very complex
solutions for bus routes, turn restrictions and hiking routes. A
typical street inside a city usually contains easily dozend relations.

In the early days, this was an issue with certain editors, but this time
is long gone. Sure, newbies tend to break stuff, but we have tools to
find those broken relations and fix them.

I don't see an issue with this kind of complexity.

I've added some of those relations to test out different usecases and
it's not harder or take longer than to add a node and move it around. I
might be trained working with relations, but I don't think it's a huge
disadvantage in this case.

> The particular proposal seems thought through, but might eventually be
> overengineered.
Yeah, might look like first, but our data users always envolve and we
had a long time no useable data on this topic. Noone is using those
highway=stop/give_way. The reason is simple, they are often broken, not
easy to parse and this might lead to unexpected results. I think this
might change in the future - like it did with the turn_restrictions.

In the future, we're able to even tag those cases :P

https://en.wikipedia.org/wiki/Traffic#/media/File:Milit%C3%A4rwegweiser_Flugplatz_Mollis.JPG

> In the simplest representation you would only need a
> via node (at the stop line) and a from way (ending at the stop line)
> and be done.
No, you misunderstood the proposal. It's basically exactly the same as a
turn restriction. You don't split the way between the stop line and the
intersection, but just add the intersecting node with a via-role.

If you have two ways crossing: X and Y with intersecting node A.

You select A as via-node and X as from-way and Y as to-way.

If you want to map the exact location of the sign, you can add an
additionally node at the place and add this node as traffic_sign and
map it with traffic_sign=DE:205.

Now a renderer might draw the sign exactly at the location you've
mapped.

If you want just the old behavior the proposal explains it, too:

role location_hint - "a hint to a renderer as to where might be a good
place to position a symbol indicating the give way. [...] Note that
this member has the same meaning as an obsoleted highway=give_way node."


> I am not sure how several via ways should work together with several
> from and to ways, and I guess even if it works, it will be
> complicated to evaluate (for other mappers) and several very simple
> relations (only from way and via node) would probably be much easier
> to understand (at the cost of having to split the ways at the
> stop/via).
One relation is just for one stop or give_way sign. So if there are all
ways exactly the same, a simpler solution without any relation is much
better. I want to create an additional proposal for this.

This would look like this:

https://www.openstreetmap.org/node/102697766#map=19/51.13736/7.20594

A bit more complex case, which was previously not tagable at all can be
found a bit south:

https://www.openstreetmap.org/node/102694679 (intersecting node)

The street has just a curb, no signs to the right and the left. Since
we were just able to tag signs, previously no information about this was
available at all in our database.


PS: I hope my explanations were understandable, I'm a bit tired and
that's the last mail today. If not, just let me know.


Best regards

Ruben 

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

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

[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 parse and check for consistency. Also
>> pretty hard to understand. I fixed many highway=stop nodes which are
>> actually the intersection nodes, so even the primary_road was
>> considered to stop there... which makes no sense.
>>
>> What do you think about the relation-approach designed by AMDmi3:
>>
>> https://wiki.openstreetmap.org/wiki/Relations/Proposed/Give_way
>
>
>
>
> 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
> editor relation support is even worse). Personally, I am mapping in a
> context with a lot of oneway streets, so it often is not an issue to just
> use a node close to the intersection, I believe if you can, you should
> avoid relations because it makes the map more complex for others to
> understand and modify (maybe with the exception of well supported
> multipolygon relations).
>

Any editor that is capable of correctly building a turn restriction
relation would be readily capable of accurately creating give_way and stop
relations by the looks of the proposal (and it largely falls in line with
my previous proposal for tagging stops).


> The particular proposal seems thought through, but might eventually be
> overengineered. In the simplest representation you would only need a via
> node (at the stop line) and a from way (ending at the stop line) and be
> done.
>

I can see that, particularly for stop signs at, say, campground ranger
stations in state parks, security shacks at practically honor-system gates
at industrial sites, and similar mid-block one-direction stop signs.


> I am not sure how several via ways should work together with several from
> and to ways, and I guess even if it works, it will be complicated to
> evaluate (for other mappers) and several very simple relations (only from
> way and via node) would probably be much easier to understand (at the cost
> of having to split the ways at the stop/via).
>

 Well, think of a situation where you have a R1-1 STOP and a R3-11 RIGHT
TURN PERMITTED WITHOUT STOPPING sign.  Your from way would be the way those
signs are facing, and the TO ways would be all the ways you would have to
stop at the sign before proceeding to enter (ie, all of them except the way
for the right turn).
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

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

[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 of a
> road.
>
> The following lanes should be *included*:
>
> · General purpose [image: [W]] traffic lanes
>  suitable for vehicles wider than a
> motorbike.
>
> · [image: [W]] Bus lanes ,
> that are reserved for public service vehicles (PSV), for example buses and
> taxis. Additionally to the total number of lanes, consider to tag the
> number of lanes for PSV with lanes:psv=*, lanes:bus=* and lanes:taxi=*.
>
> · [image: [W]] High-occupancy vehicle lanes
>  (sometimes
> also called carpool lanes, commuter lanes, express lanes, transit lanes).
> The number of such lanes could be tagged using lanes:hov=*.
>
> · Other lanes such as [image: Wikipedia-16px.png] spitsstroken
> (nl) in the Netherlands or 
> [image:
> Wikipedia-16px.png] temporäre Standstreifen
> (de) 
> in
> Austria, Germany and Switzerland which are available to traffic at certain
> restricted times, for example during the rush hour.
>
> · Longer slip-roads, for example on motorways and other fast
> major roads. Turning lanes for minor roads are not normally included. See
> turn =* for further details
> about tagging turning lanes.
>

I agree.  Because bus, HOV and taxi lanes are included because knowing
where they are and whether or not they can be used by a specific mode is
important, bicycle lanes should also be included.


> And the following lanes should be *excluded*:
>
> · Minor slip roads without a deceleration/acceleration lane, i.e.
> the main road is wider only because of the intersecting road.
>
> · Parking lanes. Consider using parking:lane
> =* to provide
> further information.
>
> · Bicycle lanes. Use the tag cycleway
> =lane
>  for those.
>
> · Emergency [image: [W]] shoulder lanes
> . See shoulder
> =* for further details.
>
>
I agree with this mostly, except for the bike lane situation.

And in a related note, it would be nice to have a method to deal with
parking lanes that are *not* curb lanes, as this is the most common method
used in the US to create Dutch-style segregated cycleways (the bike lane is
along the curb, then on the side of the bike lane that's not against the
curb, you have a white flush median (theoretical gores on freeways are a
kind of white flush median, you're supposed to treat it like a curb in the
roadway), and on the other side of the flush median, you have the parking
lane.  But that's another can of worms and the situation isn't so
widespread as to be a serious problem (yet), unlike the weird exclusion of
bike lanes from bike lane tagging.  Tagging as separate roads feels
incorrect in this case (as bollards or other physical barriers tend to be
absent).


> So a “normal” two way road with cycleways (in Australia, with left hand
> traffic) would be tagged as:
>
>
>
> cycleway=lane
>
> lanes=2
>
> vehicles:lanes:forward=no|yes
>
> vehicles:lanes:backward=no|yes
>
> bicycle:lanes:forward=designated|yes
>
> bicycle:lanes:backward=designated|yes
>

This breaks, because you're tagging for four lanes and setting your total
lanes to 2.


> When tagging to this level, I generally try to also add the width:
>
>
>
> width:lanes:forward=1|3
>
> width:lanes:backward=1|3
>

This is a good idea, as older bicycle lanes tend to be significantly more
narrow than general access lanes.


> in JOSM the “lane and road attributes” mapstyle will help visualizing
> these tagged lanes.
>
>
>
> Use vehicle instead of motor_vehicle (to keep carriages out of your cycle
> lanes…).
>

Right, I tend to use access:lanes as the basic rule since no other modes,
only bicycles, are allowed in bicycle lanes in Oklahoma (it's slightly more
lax in Oregon, where almost any nonmotorized mode is allowed, and in
California it's just a hot mess since bicycle lanes double as continuous
turn lanes for other modes).


> Important: Do NOT include the cycleway lanes in the lanes=x count! The
> lanes count (which only counts marked lanes for motorized traffic) and the
> number of entries in the :lanes prefix keys can and will be different!
>

I honestly can't fathom why you would tag more lanes than the lane count,
is there anything that can actually ha

Re: [Tagging] access=disabled

[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 
wrote:

>
>
> 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 it be too deeply nested to have
>> capacity:disabled:ramp=yes/no/#?
>>
>
>
> 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).
>
> 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] tagging of one-way cycle lanes

[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 regards to lane tagging
> as this greatly reduces accuracy for complex lane situations and are NOT
> analogous to the other excluded situations.  The wiki is wrong.
>
> On Wed, May 9, 2018, 23:46  wrote:
>
>> If I may correct your suggestion, that’s not quite right.
>>
>>
>>
>> To quote the wiki for lanes:
>>
>>
>>
>> The lanes=* key should be used to specify the total number of *marked* 
>> [image:
>> Wikipedia-16px.png] lanes of a
>> road.
>>
>> The following lanes should be *included*:
>>
>> · General purpose [image: [W]] traffic lanes
>>  suitable for vehicles wider than a
>> motorbike.
>>
>> · [image: [W]] Bus lanes ,
>> that are reserved for public service vehicles (PSV), for example buses and
>> taxis. Additionally to the total number of lanes, consider to tag the
>> number of lanes for PSV with lanes:psv=*, lanes:bus=* and lanes:taxi=*.
>>
>> · [image: [W]] High-occupancy vehicle lanes
>>  (sometimes
>> also called carpool lanes, commuter lanes, express lanes, transit lanes).
>> The number of such lanes could be tagged using lanes:hov=*.
>>
>> · Other lanes such as [image: Wikipedia-16px.png] spitsstroken
>> (nl) in the Netherlands or 
>> [image:
>> Wikipedia-16px.png] temporäre Standstreifen
>> (de) 
>> in
>> Austria, Germany and Switzerland which are available to traffic at certain
>> restricted times, for example during the rush hour.
>>
>> · Longer slip-roads, for example on motorways and other fast
>> major roads. Turning lanes for minor roads are not normally included. See
>> turn =* for further
>> details about tagging turning lanes.
>>
>> And the following lanes should be *excluded*:
>>
>> · Minor slip roads without a deceleration/acceleration lane,
>> i.e. the main road is wider only because of the intersecting road.
>>
>> · Parking lanes. Consider using parking:lane
>> =* to provide
>> further information.
>>
>> · Bicycle lanes. Use the tag cycleway
>> =lane
>>  for those.
>>
>> · Emergency [image: [W]] shoulder lanes
>> . See shoulder
>> =* for further details.
>>
>>
>>
>> So a “normal” two way road with cycleways (in Australia, with left hand
>> traffic) would be tagged as:
>>
>>
>>
>> cycleway=lane
>>
>> lanes=2
>>
>> vehicles:lanes:forward=no|yes
>>
>> vehicles:lanes:backward=no|yes
>>
>> bicycle:lanes:forward=designated|yes
>>
>> bicycle:lanes:backward=designated|yes
>>
>>
>>
>> When tagging to this level, I generally try to also add the width:
>>
>>
>>
>> width:lanes:forward=1|3
>>
>> width:lanes:backward=1|3
>>
>>
>>
>> in JOSM the “lane and road attributes” mapstyle will help visualizing
>> these tagged lanes.
>>
>>
>>
>> Use vehicle instead of motor_vehicle (to keep carriages out of your cycle
>> lanes…).
>>
>>
>>
>> Important: Do NOT include the cycleway lanes in the lanes=x count! The
>> lanes count (which only counts marked lanes for motorized traffic) and the
>> number of entries in the :lanes prefix keys can and will be different!
>> (Which is maybe somewhat unfortunate, but the lanes=count tag predates the
>> :lanes prefix tags by many years, and has been used that way all over the
>> place. Mixing different definitions of the lanes key in different places,
>> or even just different segments of the same road, is going to result in
>> useless, unreliable data as a data consumer will have no way to
>> differentiate what definition of lanes=count would apply.)
>>
>>
>>
>> See https://wiki.openstreetmap.org/wiki/Lanes#Crossing_with_
>> a_designated_lane_for_bicycles for an example of that.
>>
>>
>>
>>
>>
>> *From:* Paul Johnson 
>> *Sent:* Thursday, 10 May 2018 11:30
>> *To:* Tag discussion, strategy and related tools <
>> tagging@openstreetmap.org>
>> *Subject:* Re: [Tagging] tagging of one-way cycle lanes
>>
>>
>>
>> My suggestion:
>>
>>
>>
>> cycleway=lane
>>
>> lanes=4
>>
>> lanes:forward=2
>>
>> lanes:backward=2
>>
>> motor_vehicle:lanes:forward=yes|no
>>
>> motor_vehicle:lanes:backward=yes|no
>>
>> bicycle:lanes:forward=yes|designated (maybe no|designated if you're not
>> allowed out of the bike lane on a bike)
>>
>> bicycle:lanes:backward=yes|designate

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

[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 reason for this, but I've already
named a lot of reasons why it greatly complicates tagging.  And fixing it
would be easy MapRoulette fodder.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

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

[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 started writing
software depending on that definition.

Perhaps it would have been better to count cycle lanes as well, but we did
not. For me, this means that with a tag as popular as lanes, we cannot
alter the definition later on. It would mean that we have to retag a lot of
objects and that tagging habits have to change.
Furthermore, the tag would be useless for data consumers until we declare
all lanes-tags to be updated to the new definition.

The lanes tag is pretty useless in general. It just works for simple
layouts with the same number of car-lanes in both directions (or on one-way
streets). For anything more complex the total number of lanes is useless,
and we have to rely on the :lanes-suffix anyhow.
In case of more complex layouts (e.g. odd total number of car-lanes), you
can leave out the lanes tag and only use the :lanes-suffix in combination
with the :forward and :backward suffixes.

The cycleway=lane tag is useful for the (at least in Belgium) common layout
where cycle lanes are on the outside. So lanes=2, cycleway=lane is a common
layout that do not need any additional information. As soon as a cycle lane
is between two car lanes, one could start using the :lanes-suffix
Apparently, we also need to do that when we specify turn:lanes (as the
:lanes-suffix always have to take into account the cycle lanes).

If specify everything with the :lanes-suffix, I do not understand why you
would add the lanes-tag. It does not match what you want and is only some
kind of checksum (control number).

regards

m.

[1] https://wegcode.be/wetteksten/secties/kb/wegcode/258-art72 (in Dutch).

On Fri, May 11, 2018 at 5:49 AM, 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.
>
> On Thu, May 10, 2018 at 6:55 AM, Paul Johnson  wrote:
>
>> I strongly dispute the suggestion in the wiki in regards to lane tagging
>> as this greatly reduces accuracy for complex lane situations and are NOT
>> analogous to the other excluded situations.  The wiki is wrong.
>>
>> On Wed, May 9, 2018, 23:46  wrote:
>>
>>> If I may correct your suggestion, that’s not quite right.
>>>
>>>
>>>
>>> To quote the wiki for lanes:
>>>
>>>
>>>
>>> The lanes=* key should be used to specify the total number of *marked* 
>>> [image:
>>> Wikipedia-16px.png] lanes of a
>>> road.
>>>
>>> The following lanes should be *included*:
>>>
>>> · General purpose [image: [W]] traffic lanes
>>>  suitable for vehicles wider than a
>>> motorbike.
>>>
>>> · [image: [W]] Bus lanes ,
>>> that are reserved for public service vehicles (PSV), for example buses and
>>> taxis. Additionally to the total number of lanes, consider to tag the
>>> number of lanes for PSV with lanes:psv=*, lanes:bus=* and lanes:taxi=*.
>>>
>>> · [image: [W]] High-occupancy vehicle lanes
>>>  (sometimes
>>> also called carpool lanes, commuter lanes, express lanes, transit lanes).
>>> The number of such lanes could be tagged using lanes:hov=*.
>>>
>>> · Other lanes such as [image: Wikipedia-16px.png] spitsstroken
>>> (nl) in the Netherlands or 
>>> [image:
>>> Wikipedia-16px.png] temporäre Standstreifen
>>> (de)
>>>  in
>>> Austria, Germany and Switzerland which are available to traffic at certain
>>> restricted times, for example during the rush hour.
>>>
>>> · Longer slip-roads, for example on motorways and other fast
>>> major roads. Turning lanes for minor roads are not normally included. See
>>> turn =* for further
>>> details about tagging turning lanes.
>>>
>>> And the following lanes should be *excluded*:
>>>
>>> · Minor slip roads without a deceleration/acceleration lane,
>>> i.e. the main road is wider only because of the intersecting road.
>>>
>>> · Parking lanes. Consider using parking:lane
>>> =* to provide
>>> further information.
>>>
>>> · Bicycle lanes. Use the tag cycleway
>>> =lane
>>>  for those.
>>>
>>> · Emergency [image: [W]] shoulder lanes
>>> . See shoulder
>>> =* for further
>>> details.
>>>
>

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

[osm.tagging]

A few comments:

* I don't think this should "obsolete" the highway=give_way nodes completely. 
For simple cases with oneway=yes roads the highway=give_way node on the way is 
the easiest way to map them. Also for any "four-way give way" situation, 
tagging the intersection node is clear and unambigious.

* I'm not sure if putting the different traffic types into the relation type 
key is the right place. It might be better to put that into an applies_to key? 

That way you can list multiple, either as applies_to=caravan;hgv;bus or 
applies_to:bus=yes applies_to:hgv=yes

The separate key version has the advantage that it would also allow conditions:

applies_to:hgv=no
applies_to:hgv:conditional=yes@(Mo-Fr)

* instead of day_on, day-off, hour_on, and hour_off, it might be better to use 
an operating_hours key with the same format as opening_hours for shops

* overwritten_by might be better as a member instead (or in addition) of a key. 
Especially for dual carriage way intersections (mapped as # ) the 
traffic_signal nodes are usually at the stop line on the approach instead of at 
the intersecting nodes (if you tag the 4 intersecting nodes, then a route 
through the intersection would pass 2 or 3 highway=traffig_signal nodes, while 
if it is tagged only on the approaches [which are all oneways] the route 
correctly only goes through a single one). 

* the value curb value for the road_markings key should probably be kerb to 
match the barrier=kerb tag and to match UK English usage.

* in addition to the road_sign members, it would be good to also allow 
road_marking members (which would be a node on a from way, or a way with an 
intersecting node with the from way, tagged with road_marking=x, or 
barrier=kerb)

* the road_sign and road_marking members and keys should have the same name

Cheers,
Thorsten


> -Original Message-
> From: Ruben Kelevra 
> Sent: Friday, 11 May 2018 07:52
> To: tagging@openstreetmap.org
> Subject: Re: [Tagging] complete tagging of all 'right of way'-cases
> FOLLOWUP
> 
> 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
> update[2] it.
> 
> It now includes the ability to tag the
> * used sign (directly at the intersection)
> * road markings, like a curb or a dotted or solid line
> * main operational function of this intersection, like a traffic
> light.
> 
> The last one is necessary because we got intersection with stop and
> yield signs here, which are located at the traffic lights. So if
> the traffic lights are off (in the night or just non-operational)
> the signs located at the traffic lights are applied.
> 
> When the traffic lights are shut of every night, we can add that
> information to the node at the via tag, to disable the traffic
> light tag in those time periods for the routers. Then the give_way-
> or stop-relations come into action.
> 
> It now also includes lists of cases where it should be used and
> cases where it shouldn't. Explicitly changing the recommendation to
> NOT use it on roundabout & removing the example for it).
> 
> It's also recommending the simple solutions for a priority-to-the-
> right (not yet written) and the all-way_stop.
> 
> If the mapper wants to map more details, like the curbs, signs,
> hour_on/off or the class of vehicles where this applies, we have to
> go the relation way and create up to 4 relations to one
> intersection - I just don't see a simpler way with the same
> flexibility.
> 
> 
> [1] https://wiki.openstreetmap.org/wiki/Relations/Proposed/Give_way
> [2] https://bit.ly/2IrMh3g (just a shorted link to a diff)
> 
> As always: Feel free to fix logic and language issues in the
> proposal - I'm not a native speaker, there might be many.
> 
> I hope for more feedback on this from you, guys.
> 
> 
> Best regards
> 
> Ruben
> 
> ___
> 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] tagging of one-way cycle lanes

[osm.tagging]

> From: Marc Gemis  
> Sent: Friday, 11 May 2018 14:44
> 
> 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 started writing software depending on that definition.
>
> Perhaps it would have been better to count cycle lanes as well, 
> but we did not. For me, this means that with a tag as popular 
> as lanes, we cannot alter the definition later on. It would mean 
> that we have to retag a lot of objects and that tagging habits 
> have to change. Furthermore, the tag would be useless for data 
> consumers until we declare all lanes-tags to be updated to the 
> new definition. 

THAT is exactly the point I've been trying to make. The definition of the lanes 
tag predates the introduction of the :lanes suffix by many years. It has always 
been defined as "number of full width lanes for motorized traffic. Given then 
widespread use of this tag it's basically impossible to simply change it's 
definition. 

This has also been specifically brought up _and a resolution decided upon_ 
during the proposal process for :lanes suffix:

https://wiki.openstreetmap.org/wiki/Proposed_features/lanes_General_Extension#The_issues_with_the_lanes_tag

Furthermore, I do not know anyone that, when shown this picture:

https://www.google.com.au/maps/@-27.218495,153.0061827,3a,66.8y,204.86h,78.18t/data=!3m4!1e1!3m2!1s2DBegIPPNP78TmCjslUavA!2e0

and asked, "is that a 2 lane or a 4 lane street" would say that it's a 4 lane 
street.

Similar here:

https://www.google.com.au/maps/@-27.2305921,153.0252325,3a,66.8y,285.94h,79.82t/data=!3m4!1e1!3m2!1sWt2KhVfIcF3-YzMzGE1xFQ!2e0

Nobody I know would tell me that is a 3 lane road.

Cheers,
Thorsten



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