Re: [Tagging] traffic_signals:direction=* vs. direction=*

[Martin Koppenhoefer]

sent from a phone

> On 26 Mar 2017, at 17:43, Marc Gemis  wrote:
> 
> I've been adding maybe hundreds of stop & give ways signs


if you're mapping signs (traffic_sign=*) I think you should map them where they 
are, if you map the effects of signs, map it to where it applies.

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

Re: [Tagging] traffic_signals:direction=* vs. direction=*

[Martin Koppenhoefer]

sent from a phone

> On 26 Mar 2017, at 09:48, Paul Johnson  wrote:
> 
> Not to sound like a broken record, but what exactly would be so complicated 
> about adapting the existing and adopted enforcement style relations to stop 
> and give way devices?  This completely removes ambiguity and guesswork and 
> can already be done using existing tools. 


+1, for stop signs and give way (maybe also for right of way, because otherwise 
how would you know if it's the default or not tagged?) the relation seems 
appropriate (analogous to what we do in similar cases like turn restrictions 
and enforcement)

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

Re: [Tagging] traffic_signals:direction=* vs. direction=*

[Marc Gemis]

On Thu, Mar 23, 2017 at 12:57 AM, Martin Koppenhoefer
 wrote:
> generally it is unsafe to rely on a "direction" like forward or backward as
> tag on a node. Nodes do not have directions, and there is no relation from a
> node to a single way, the relation is from a way to a node and many ways can
> reference the same node, that's not an error. Will it become forbidden to
> split ways on nodes with stop sign or traffic signal tags, because it breaks
> the information tagged on those nodes?

I've been adding maybe hundreds of stop & give ways signs with a
direction and never had a problem that there was a split of the way at
the node where the stop sign had to come.
Are you talking about theoretical cases, or do you have examples where
the way has to be split at the stop node ?

m.

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

Re: [Tagging] traffic_signals:direction=* vs. direction=*

[Paul Johnson]

On Thu, Mar 23, 2017 at 7:44 AM, Martin Koppenhoefer  wrote:

>
> 2017-03-23 10:30 GMT+01:00 Jean-Marc Liotier :
>
>> As the "complex intersections" section of the highway=traffic_signals
>> page describes a gradation of model complexity
>> (https://wiki.openstreetmap.org/wiki/Tag:highway%3Dtraffic_
>> signals#Complex_intersections),
>> maybe coexistence is also possible between simple tagging of a
>> highway=stop+direction=forward node on the way to an intersection and a
>> complex relation-based model for more complex cases: having a simple
>> model that covers most cases has such significant benefit that I would
>> say it more than offsets the cost of having more than one way to do it.
>>
>
>
> If we choose to trade off  stability / disambiguity / reliability for a
> little less complexity (no relation), the better solution is positioning
> the node for the sign not on the highway but in the driving direction close
> to it to the side (could be sold as "actual sign position" save some
> exceptions). This way you have the direction implicitly stored and don't
> depend on other ways, but there is the risk of someone dragging the node
> with the sign or the highway so far away that another (unrelated) highway
> comes closer.
>

This assumption would generally mean that on tight-radius corners common in
rural American towns, the implied face of the stop would be towards the
major road on the downstream side of the intersection, when in reality it's
facing the upstream side of the minor intersection, thanks to the stop sign
being closer to the side of the major road than the minor road.


> Both variants require postprocessing anyway (either you have to look for a
> closeby highway or for the direction of the way(s) your node is part of).
>
> Yet another option would be to use tiny way stubs for the signs, these
> would have a direction (and could even imply a default sign direction if
> defined like that).
>

Not to sound like a broken record, but what exactly would be so complicated
about adapting the existing and adopted enforcement style relations to stop
and give way devices?  This completely removes ambiguity and guesswork and
can already be done using existing tools.  Plus, like turn relations,
further developments on the editor end would make this even more trivial.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] traffic_signals:direction=* vs. direction=*

[Greg Troxel]

Tod Fitch  writes:

> Quoted sections have been edited down to only show parts I am responding to:
>
>> On Mar 22, 2017, at 5:37 AM, Greg Troxel  wrote:
>> 
>> For highway=traffic_signals, the normal situation is that it's on a
>> node, and affects all ways entering the node.  Or it's on a way and
>> affects both directions -- in my experience, when there are traffic
>> lights not at an intersection, they are always for both directions (even
>> though in theory they could be set up for one direction only).
>
> CalTrans has used semi-permanent traffic signals to control traffic
> flow over damaged road sections. A light at each side of the damaged
> area controls the sequentially one-way traffic through the damaged
> area that has been reduced to one lane operation. I’ve seen these in
> the Santa Cruz mountains, but the longest section of road I’ve seen
> controlled this way was on the main road to Yosemite Valley where the
> side of the mountain came down on the main roadway and the work
> around, in place for several years, was to put some pavement on the
> old single track railway grade on the other side of the river and put
> two bridges in place to get traffic across and back. It maybe still in
> place while but I’ve not been through there in several years. I know
> they took a long time to decide what to do about the still unstable
> mountain above the covered section of highway.
>
> So there are places with traffic signals away any intersections that
> control traffic going into a one lane section. I guess a smart router
> could guess that the transition of a road from two lanes to one lane
> would count as an intersection but that seems an error prone
> algorithm. Having a direction tag of some sort available does make
> tagging this situation possible.

You are totally correct.  I have seen two traffic signal sets near me,
controlling access to a one-lane bridge and a road where one lane is
washed out and the other alternates.  I had forgotten about these.

But, while we need a way to represent these, I think the notion that:

  stop not at a node is towards the node only, unless otherwise tagged
  to be both
  
  signals is both ways, unless tagged to be just one way

is relatively sound, in terms of striking a balance between mapping ease
and data consumers.


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

Re: [Tagging] traffic_signals:direction=* vs. direction=*

[yo paseopor]

On Thu, Mar 23, 2017 at 1:41 AM, Tod Fitch  wrote:

>
> “stop:forward=yes” & “stop:backward=yes” seem like they are putting a
> value in the key as the stuff to the right of the equals may never be
> anything other than “yes”. On the “lanes:forward” and “lanes:backward” keys
> at least the values carry variable values.
>

Sorry, but you are wrong if you are talking of "my idea" . I don't view any
future to a unique key for every traffic sign (would be interesting for
every group as a concatenation of pairs as: traffic_sign=warning
warning=bump), I see varied values. So as you can see with the example of
the proposal [1] , the result will not be stop:x = yes instead of

highway=stop >> kind of traffic sign in a unified scheme
traffic_sign:forward=ES:R2 >> Spanish code of the traffic sign (wil be good
for rendering the exact image)
side=right > side of the road it is.


>
> There is already a “traffic_signals:direction=forward | backward” usage.
> “stop:direction= forward | backward” and “give_way=forward | backward”
> would fit that schema too.
>

I think a scheme with the various values is more complete than create a key
for every traffic sign because then every traffic sign will fit in every
country with the same key, as you can see in Taginfo [2].

>  Will it become forbidden to split ways on nodes with stop sign or traffic
> signal tags, because it breaks the information tagged on those nodes?
>
> To split a way specific in that node would not be the best option but the
only problem will be if you connect other way to that node, if you split a
way but you have the same direction in the two segments of a way I don't
think there will be any problem with that.Also you can split the way next
pixel of the pixel of the traffic sign.

Salut i senyals de trànsit (Health and traffic signs)
yopaseopor

[1] https://wiki.openstreetmap.org/wiki/Proposed_features/
Extended_traffic_signs_tagging#Traffic_signs_presets
[2] https://taginfo.openstreetmap.org/projects/traffic_signs#tags
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] traffic_signals:direction=* vs. direction=*

[Martin Koppenhoefer]

2017-03-23 15:47 GMT+01:00 Jean-Marc Liotier :

> I'm not operating a routing system so maybe someone who is
>   might offer his opinion on that point
>


in another thread a few days ago there was a comment by Daniel Hofmann who
works at mapbox on OSRM:
https://lists.openstreetmap.org/pipermail/tagging/2017-March/031727.html

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

Re: [Tagging] traffic_signals:direction=* vs. direction=*

[Jean-Marc Liotier]

So, summing up the ideas expressed so far, in the example case of a stop
sign on a two-ways way (not an all-ways stop), we have:

1- highway=stop+direction=forward node on the way to an intersection
- Advantages: simple, uses the well-known direction=* tag, easy for
  routers to interpret
- Disadvantages: to be unambiguous, must be tagged on a
  non-intersection node adjacent to the intersection to which it
  applies, only good for covering the simple case, which
  means that it requires another way to coexist for covering the
  complex case
- My opinion: looks good to me for covering the simple case, which
  means that it requires another way to coexist for covering the
  complex case. Is the simple case common enough for this duplication
  to be a net benefit ?

2- highway=stop+stop:direction=forward node on the way to an
  intersection
- Advantages: simple, uses the stop:direction=* tag which is coherent
  with traffic_signals:direction=*
- Disadvantages: new tag, to be unambiguous, must be tagged on a
  non-intersection node adjacent to the intersection to which it applies
- My opinion: just like n°1 but with an exotic tag for no benefit...
  Discard this proposal !

2- highway=stop node on the way to an intersection, with the nearest
  intersection being the one to which the sign applies
- Advantages: simplest method
- Disadvantages: slight processing burden for the router which must find
  the closest intersection to guess which one it applies to
- My opinion: might be too ambiguous for the routing processor, but I'm
  not operating a routing system so maybe someone who is might offer
  his opinion on that point

3- highway=stop on the right of the way when looking towards the
  intersection to which the sign applies
- Advantages: very simple, records actual location of the stop sign
- Disadvantages: heavy processing burden for the router which must find
  the closest way to guess which one it applies to
- My opinion: way too much burden on the routing processor... But
  again, I'm not operating a routing system so maybe someone who is
  might offer his opinion on that point

4- highway=stop near the way, with a two-node way attached as a
  "direction arrow"
- Advantages: well, it sort of would work
- Disadvantages: way too much burden on the routing processor, heretical
  to the Openstreetmap way
- My opinion: heretical !

5- relation (type: to be defined) including highway=stop and
from:forward (the incoming way arriving at the stop - must be connected
to the stop)
- Advantages: only a couple more additional tagging steps compared to
  the other methods (creating the relation+a couple members).
  Compatible with the highway=stop being either on the way or near the
  way at the actual location of the sign
- Disadvantages: a couple more additional tagging steps compared to
  the other methods... And it is a relation (which is not
  beginner-friendly)
- My opinion: must be retained because it is the only one which
  unambiguously covers all cases. The only question is: is it valuable
  to have another simpler relationless method to cover the common
  simple case ?

My opinion summary: n°5 is a keeper... Do we need n°1 too ?

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

Re: [Tagging] traffic_signals:direction=* vs. direction=*

[Martin Koppenhoefer]

2017-03-23 10:30 GMT+01:00 Jean-Marc Liotier :

> As the "complex intersections" section of the highway=traffic_signals
> page describes a gradation of model complexity
> (https://wiki.openstreetmap.org/wiki/Tag:highway%
> 3Dtraffic_signals#Complex_intersections),
> maybe coexistence is also possible between simple tagging of a
> highway=stop+direction=forward node on the way to an intersection and a
> complex relation-based model for more complex cases: having a simple
> model that covers most cases has such significant benefit that I would
> say it more than offsets the cost of having more than one way to do it.
>


If we choose to trade off  stability / disambiguity / reliability for a
little less complexity (no relation), the better solution is positioning
the node for the sign not on the highway but in the driving direction close
to it to the side (could be sold as "actual sign position" save some
exceptions). This way you have the direction implicitly stored and don't
depend on other ways, but there is the risk of someone dragging the node
with the sign or the highway so far away that another (unrelated) highway
comes closer.

Both variants require postprocessing anyway (either you have to look for a
closeby highway or for the direction of the way(s) your node is part of).

Yet another option would be to use tiny way stubs for the signs, these
would have a direction (and could even imply a default sign direction if
defined like that).

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

Re: [Tagging] traffic_signals:direction=* vs. direction=*

[Martin Koppenhoefer]

sent from a phone

> On 23 Mar 2017, at 01:41, Tod Fitch  wrote:
> 
> And if not on an intersection node then it should be placed at the stop line. 
> [2] I don’t think we are likely to have a stop line in the middle of an 
> intersection. :)


think of a cycleway or a driveway for example. Maybe also non-highways.

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

Re: [Tagging] traffic_signals:direction=* vs. direction=*

[Tod Fitch]

> On Mar 22, 2017, at 4:51 PM, yo paseopor  wrote:
> 
> Anyone else with an opinion ? Two of us might be the very beginning of a
> consensus but we need a little more before even putting a proposal
> page up on the wiki...
> 
> I think to include direction inside the tag with a subkey :forward :backward 
> following the scheme for lanes and so one are the best option instead of 
> using a specific key as direction because we save one key, and we follow a 
> well-known scheme.
> Other thing is the side of the road the traffic sign is , as it changes the 
> form and the style of it (motorway panel vs. little traffic sign on the right 
> side of a road)
> 

“stop:forward=yes” & “stop:backward=yes” seem like they are putting a value in 
the key as the stuff to the right of the equals may never be anything other 
than “yes”. On the “lanes:forward” and “lanes:backward” keys at least the 
values carry variable values.

There is already a “traffic_signals:direction=forward | backward” usage. 
“stop:direction= forward | backward” and “give_way=forward | backward” would 
fit that schema too.

> On Mar 22, 2017, at 4:57 PM, Martin Koppenhoefer  
> wrote:
> 
> generally it is unsafe to rely on a "direction" like forward or backward as 
> tag on a node. Nodes do not have directions, and there is no relation from a 
> node to a single way, the relation is from a way to a node and many ways can 
> reference the same node, that's not an error. Will it become forbidden to 
> split ways on nodes with stop sign or traffic signal tags, because it breaks 
> the information tagged on those nodes?

Good point. Although one might suggest that it is a theoretical situation as 
the definition of the stop tag [1] indicates that if on the node connecting 
multiple then it is a all way stop. And if not on an intersection node then it 
should be placed at the stop line. [2] I don’t think we are likely to have a 
stop line in the middle of an intersection. :)

[1] https://wiki.openstreetmap.org/wiki/Tag:highway%3Dstop#All-way_stop
[2] 
https://wiki.openstreetmap.org/wiki/Tag:highway%3Dstop#Tagging_minor_road_stops




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

Re: [Tagging] traffic_signals:direction=* vs. direction=*

[Martin Koppenhoefer]

generally it is unsafe to rely on a "direction" like forward or backward as
tag on a node. Nodes do not have directions, and there is no relation from
a node to a single way, the relation is from a way to a node and many ways
can reference the same node, that's not an error. Will it become forbidden
to split ways on nodes with stop sign or traffic signal tags, because it
breaks the information tagged on those nodes?

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

Re: [Tagging] traffic_signals:direction=* vs. direction=*

[yo paseopor]

>
> Anyone else with an opinion ? Two of us might be the very beginning of a
> consensus but we need a little more before even putting a proposal
> page up on the wiki...
>

I think to include direction inside the tag with a subkey :forward
:backward following the scheme for lanes and so one are the best option
instead of using a specific key as direction because we save one key, and
we follow a well-known scheme.
Other thing is the side of the road the traffic sign is , as it changes the
form and the style of it (motorway panel vs. little traffic sign on the
right side of a road)

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

Re: [Tagging] traffic_signals:direction=* vs. direction=*

[Tod Fitch]

Quoted sections have been edited down to only show parts I am responding to:

> On Mar 22, 2017, at 5:37 AM, Greg Troxel  wrote:
> 
> For highway=traffic_signals, the normal situation is that it's on a
> node, and affects all ways entering the node.  Or it's on a way and
> affects both directions -- in my experience, when there are traffic
> lights not at an intersection, they are always for both directions (even
> though in theory they could be set up for one direction only).

CalTrans has used semi-permanent traffic signals to control traffic flow over 
damaged road sections. A light at each side of the damaged area controls the 
sequentially one-way traffic through the damaged area that has been reduced to 
one lane operation. I’ve seen these in the Santa Cruz mountains, but the 
longest section of road I’ve seen controlled this way was on the main road to 
Yosemite Valley where the side of the mountain came down on the main roadway 
and the work around, in place for several years, was to put some pavement on 
the old single track railway grade on the other side of the river and put two 
bridges in place to get traffic across and back. It maybe still in place while 
but I’ve not been through there in several years. I know they took a long time 
to decide what to do about the still unstable mountain above the covered 
section of highway.

So there are places with traffic signals away any intersections that control 
traffic going into a one lane section. I guess a smart router could guess that 
the transition of a road from two lanes to one lane would count as an 
intersection but that seems an error prone algorithm. Having a direction tag of 
some sort available does make tagging this situation possible.

> As a human, if I see a highway=stop on a way about 3-10m from an
> intersection, it's obvious that it applies to travel on the way towards
> the intersection, but not leaving the intersection.  However, I think
> OsmAnd sometimes falses on these.

OsmAnd always seems to “false on” these. To the point where I ignore the stop 
warning it gives.

> I would suggest a definition that associates the stop sign with the
> nearest intersection if it's less than 25m away, and there are no
> intersections in the other direction within 3x that closest intersection
> distance.  And then to use relations to label which intersection, if the
> above doesn't work.

Sounds like a reasonable thing to add some distances to the wiki where it 
describes that algorithm but without specific distance numbers.

> . . .   I view this whole exercise as designing tagging rules
> that are good for human editors and acceptable (semantically non-kludgy
> and reasonably easily implementable) for data consumers.

+1 on that.




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

Re: [Tagging] traffic_signals:direction=* vs. direction=*

[Greg Troxel]

-- 
Dave Swarthout  writes:

> This is embarrassing but relevant to this conversation. I've been mapping
> intensely for several years but adding stop signs was something I rarely
> did.

I only started adding stop signs within the last year.  Probably I
started because OsmAnd will give a warning, and that's good, as long as
there is no one else in the car :-)

> In hindsight, it's perfectly obvious when one considers routing engines
> that any highway=stop node must affect traffic in both directions unless
> made explicit in some fashion, or else ignored as OSMand seems to do. So
> far, I've only added 45 highway=stop nodes in Alaska and 18 in Thailand.
> I'll be revisiting them to add the appropriate direction tags in the not
> too distant future.

I don't think it's obvious...

For highway=traffic_signals, the normal situation is that it's on a
node, and affects all ways entering the node.  Or it's on a way and
affects both directions -- in my experience, when there are traffic
lights not at an intersection, they are always for both directions (even
though in theory they could be set up for one direction only).

Stop signs, on the other hand, are for the most part sort of properties
of intereections, except that the normal cases are that some ways have
them and some don't, or that all ways have them.  (Around me, some is
much more common than all, but all isn't odd.)

As a human, if I see a highway=stop on a way about 3-10m from an
intersection, it's obvious that it applies to travel on the way towards
the intersection, but not leaving the intersection.  However, I think
OsmAnd sometimes falses on these.

I had the impression that there was supposed to be a relation with the
intersection node, which seems somewhat awkward.

I would suggest a definition that associates the stop sign with the
nearest intersection if it's less than 25m away, and there are no
intersections in the other direction within 3x that closest intersection
distance.  And then to use relations to label which intersection, if the
above doesn't work.

> As to an opinion about how to implement their tagging, I would tend to go
> with the ones that resemble the directionality tags already in use for
> lanes, i.e., lanes:forward=* and lanes:backward=* except that it's awfully
> verbose. I automate much of my tagging with custom presets in JOSM so
> adding complicated, long tags to them isn't difficult but asking casual
> mappers to enter these very long tags like
> "traffic_signals:direction=forward" is going to be problematical IMO.
> Consequently, I would lean towards keeping it simple and
> using direction:forward/backward to indicate directionality, at least for
> nodes.

That sounds ok to me too, but it seems that it should be mostly
unnecessary.   I view this whole exercise as designing tagging rules
that are good for human editors and acceptable (semantically non-kludgy
and reasonably easily implementable) for data consumers.



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

Re: [Tagging] traffic_signals:direction=* vs. direction=*

[Paul Johnson]

On Mon, Mar 20, 2017 at 12:46 PM, LeTopographeFou  wrote:

> In real life a traffic light is more often associated to another device
> such as a camera, a pedestrian light... than stop signs which stands
> generally on their own. So direction=* might be enought for stops and
> give_ways most of the time for most of the mappers and editors.


Stop signs also get used at signalized intersections in the US with
annoying frequency.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] traffic_signals:direction=* vs. direction=*

[Martin Koppenhoefer]

2017-03-21 0:36 GMT+01:00 yo paseopor :

> 2-putting the node at the side visually is more realistic...but it is so
> unuseful as be a independent node, so it is better to put it IN the way and
> mark its position with subkeys or other tags as side relatives to this way
> the node is in.



it is far from unuseful, it just requires preprocessing to find the way it
applies to. Also a node that is part of a way and has a direction tag
referring to the direction of this way, needs preprocessing to make sense
of it.

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

Re: [Tagging] traffic_signals:direction=* vs. direction=*

[Dave Swarthout]

This is embarrassing but relevant to this conversation. I've been mapping
intensely for several years but adding stop signs was something I rarely
did. There's so much else that needs attention that I wasn't even following
this thread. Then today I was using Osmose to correct errors in Alaska and
kept seeing this persistent error about missing direction tags on
highway=stop objects, the ones I added! After thinking about that for a
moment it finally dawned on me that, unless the stop is a 4-way stop,
the directionality and placement of the sign is important. Time to check
this thread, I thought, and immediately.

In hindsight, it's perfectly obvious when one considers routing engines
that any highway=stop node must affect traffic in both directions unless
made explicit in some fashion, or else ignored as OSMand seems to do. So
far, I've only added 45 highway=stop nodes in Alaska and 18 in Thailand.
I'll be revisiting them to add the appropriate direction tags in the not
too distant future.

As to an opinion about how to implement their tagging, I would tend to go
with the ones that resemble the directionality tags already in use for
lanes, i.e., lanes:forward=* and lanes:backward=* except that it's awfully
verbose. I automate much of my tagging with custom presets in JOSM so
adding complicated, long tags to them isn't difficult but asking casual
mappers to enter these very long tags like
"traffic_signals:direction=forward" is going to be problematical IMO.
Consequently, I would lean towards keeping it simple and
using direction:forward/backward to indicate directionality, at least for
nodes.

There is also the other case where one uses the direction tag to indicate
the compass direction an adit or cave opening faces. I don't see a problem
with using direction=* for both situations because the values used in
either case are different, for example, S,N SSE, on the one hand and
forward, backward, on the other.

Cheers,

Dave



On Tue, Mar 21, 2017 at 3:31 PM, Jean-Marc Liotier  wrote:

> On Mon, 20 Mar 2017 18:46:17 +0100
> LeTopographeFou  wrote:
> >
> > I think that both stop, give way and traffic signals shall have a
> > consistent definition of direction and shall be consistent in which
> > key to encourage. As soon as direction=* is valid I would encourage
> > it as the primary method, would not deprecate the second one but
> > explain it is one way of avoiding ambiguities in some cases.
>
> I agree with that line of thinking: traffic_signals:direction=* is not
> harmful so, while consistent universal use of direction=* would be
> nice, there is no need to hurry anything or anyone.
>
> Anyone else with an opinion ? Two of us might be the very beginning of a
> consensus but we need a little more before even putting a proposal
> page up on the wiki...
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>



-- 
Dave Swarthout
Homer, Alaska
Chiang Mai, Thailand
Travel Blog at http://dswarthout.blogspot.com
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] traffic_signals:direction=* vs. direction=*

[Jean-Marc Liotier]

On Mon, 20 Mar 2017 13:47:46 -0400
Kevin Kenny  wrote:
>
> If there is a traffic signal at an intersection, the default is that
> traffic from any direction will be facing a signal.

Yes, but only in the case of tagging the traffic signals at the
intersection node.

If the traffic_signals tag is placed on a way node, then there is
ambiguity. A human observer might guess that it applies to traffic
directed to the nearest intersection - and one might even implement
that as an algorithm... But it is ambiguous at best.

> I don't think with the present state of data consumers, that there is
> necessarily a "right way" to do this. Ultimately, it will be the data
> consumers that will decide what the "right way" is: tag your
> STOP and YIELD signs correctly

Yes, users are ultimately right... And expressing themselves early will
save everyone some of the chaotic period that precedes the settling in
of perennial tags. Implementation rules but discussing it a little
beforehand is valuable.

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

Re: [Tagging] traffic_signals:direction=* vs. direction=*

[yo paseopor]

On Mon, Mar 20, 2017 at 6:47 PM, Kevin Kenny 
wrote:

>
> By contrast, traffic signs are inherently directional. Without a direction
> indication, we really have no way of conveying "traffic on the side
> street has to come to a stop/give way here; traffic on the main street
> can proceed relatively unhindered." There isn't quite a universal
> consensus on how to convey that information.
>
What appears to be most popular, as you have observed, is to place the stop
> or give_way
> near, not upon, the intersection, as a node on the way that it applies to,
> and apply a direction=* tag to indicate the direction of traffic flow
> that will be facing the sign.
>

The difficulties I have found doing as you say are two:

1-with :forward :backward scheme you are aproaching at others that affects
to the way: maxspeed,overtaking. Using good subkeys you are saving one
innecesary key (direction) thus forward and backward are...directions.
2-putting the node at the side visually is more realistic...but it is so
unuseful as be a independent node, so it is better to put it IN the way and
mark its position with subkeys or other tags as side relatives to this way
the node is in.


> I don't think with the present state of data consumers, that there is
> necessarily a "right way" to do this. Ultimately, it will be the data
> consumers that will decide what the "right way" is: tag your
> STOP and YIELD signs correctly, and the applications will warn
> drivers; tag them wrong, and they won't.
>

I know traffic signs were not an important thing in OSM. In 2013 when I
have started to think about it and move me to do something about that there
was only a plug-in for JOSM. And then, when you opened that plug-in you can
saw 4 country presets with about 30 traffic signs-per-country. Putting
inside the plug-in the +300 Spanish traffic signs was a curious thing.
Making a style that show all the traffic signs and not only Maxspeed was
"interesting".
Thinking about all the rest of the European Countries was logical (why
Spanish and not the other European traffic signs...or the world traffic
signs?)

We are not in 2013. Nowadays is 2017.
In this years we saw a project called Mapillary that had a traffic sign
editor and automated recognition for 40 countries. We saw other project
called OpenStreetCam with automated recognition and a editor for
destination signs (internally yet).
We know these projects are around other big names like Toyota, Telenav. We
know the strategy of the big one Google: Street View exists to give data to
their automated cars, Google Captchas now are from traffic signs
recognition.
In this scenario we start to have some governments give us the permission
and the data to put traffic signs into the map.
So, for a important thing in the "future maps" (traffic signs) we have
three different sources (Mapillary, OSC and Governments)
Presets, styles, all this stuff will reach the most populated countries of
the World soon or later. You will have some tools to do this job...for all
main countries. OSMAnd does not understand stops? no problem, there will be
an app that understand and warning you about ALL the traffic signs (this
will happen soon or later).
OSM is capable of have this data inside it. We have to propose a rich
scheme with all the possibilities and make it work. I have proposed one but
I hope there will be others and better or make better the one I have
proposed. Then other apps will join us because people and data are ready.
Are we ready? Is OSM ready? I think so.

Salut i estiguem preparats (Health and Get Ready)
yopaseopor
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] traffic_signals:direction=* vs. direction=*

[Kevin Kenny]

On Mon, Mar 20, 2017 at 12:19 PM, Jean-Marc Liotier  wrote:

> Given how widely used the direction tag is for highway=* signs, why
> isn't it also applied to highway=traffic_signals ? Does
> traffic_signals:direction=* bear additional meaning that direction=*
> does not convey ?
>

If there is a traffic signal at an intersection, the default is that traffic
from any direction will be facing a signal. There's no harm in assuming
that a guidance application might warn that a driver is approaching
a signal.

By contrast, traffic signs are inherently directional. Without a direction
indication, we really have no way of conveying "traffic on the side
street has to come to a stop/give way here; traffic on the main street
can proceed relatively unhindered." There isn't quite a universal
consensus on how to convey that information. What appears to be
most popular, as you have observed, is to place the stop or give_way
near, not upon, the intersection, as a node on the way that it applies to,
and apply a direction=* tag to indicate the direction of traffic flow
that will be facing the sign.

Unfortunately, OSMAnd and whatever it uses for its routing and
navigation engine doesn't recognize this scheme, and alerts about
a STOP sign as you're leaving the intersection, as well as when you're
entering it.

I don't think with the present state of data consumers, that there is
necessarily a "right way" to do this. Ultimately, it will be the data
consumers that will decide what the "right way" is: tag your
STOP and YIELD signs correctly, and the applications will warn
drivers; tag them wrong, and they won't.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] traffic_signals:direction=* vs. direction=*

[LeTopographeFou]

On a node, traffic_signals:direction=* applies only to the traffic 
signals while direction=* applies to all other tags which may be 
associated with a direction (camera...). This is the additional meaning. 
Let say that traffic_signals:direction=* is a more explicit tag than 
direction=* (see https://wiki.openstreetmap.org/wiki/Namespace).


So why is there such a gap in use of the two keys between stop, give 
ways and traffic lights? For me several reasons:


1. Because of the wiki. Some people (including me) look at the wiki as
   guidelines when mapping (not only as a documentation):
1. https://wiki.openstreetmap.org/wiki/Tag:highway%3Dtraffic_signals
   encourages traffic_signals:direction=* (even in the talk page)
2. https://wiki.openstreetmap.org/wiki/Tag:highway%3Dstop
   encourages direction=*
3. https://wiki.openstreetmap.org/wiki/Tag:highway%3Dgive_way
   encourages direction=*
2. Because editors use it that way... probably because they have
   implemented directions following the wiki! But also because they
   have implemented it for traffic lights, stops and give ways at
   different point in time (and iD for instance don't support direction
   for all of those features) and by different developers (and
   different point of view). When you see a field in iD (for instance),
   you often want to fill it when you know the answer. When you don't
   see it, you may not think to create the tag by yourself (or maybe
   not even know a tag exists).
3. Some quality assurance tools (such as Osmose) encourage (or have
   encouraged) one form over another one, sometimes involuntarily.
4. In real life a traffic light is more often associated to another
   device such as a camera, a pedestrian light... than stop signs which
   stands generally on their own. So direction=* might be enought for
   stops and give_ways most of the time for most of the mappers and
   editors.
5. Maybe massive edits or imports have dug the gap.

I think that both stop, give way and traffic signals shall have a 
consistent definition of direction and shall be consistent in which key 
to encourage. As soon as direction=* is valid I would encourage it as 
the primary method, would not deprecate the second one but explain it is 
one way of avoiding ambiguities in some cases.


Yours,

LeTopographeFou

Le 20/03/2017 à 17:19, Jean-Marc Liotier a écrit :

traffic_signals:direction=* is used on 27278 highway=traffic_signals
objects:
https://taginfo.openstreetmap.org/tags/highway=traffic_signals#combinations

highway=stop is combined with a direction tag on about 77000 objects
(direction=backward, direction=forward and the literal direction=*)
https://taginfo.openstreetmap.org/tags/highway=stop#combinations

highway=give_way is combined with a direction tag on about 43000 objects
(direction=backward, direction=forward and the literal direction=*)
https://taginfo.openstreetmap.org/tags/highway=give_way#combinations

Given how widely used the direction tag is for highway=* signs, why
isn't it also applied to highway=traffic_signals ? Does
traffic_signals:direction=* bear additional meaning that direction=*
does not convey ?

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


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

[Tagging] traffic_signals:direction=* vs. direction=*

[Jean-Marc Liotier]

traffic_signals:direction=* is used on 27278 highway=traffic_signals
objects:
https://taginfo.openstreetmap.org/tags/highway=traffic_signals#combinations

highway=stop is combined with a direction tag on about 77000 objects
(direction=backward, direction=forward and the literal direction=*)
https://taginfo.openstreetmap.org/tags/highway=stop#combinations

highway=give_way is combined with a direction tag on about 43000 objects
(direction=backward, direction=forward and the literal direction=*)
https://taginfo.openstreetmap.org/tags/highway=give_way#combinations

Given how widely used the direction tag is for highway=* signs, why
isn't it also applied to highway=traffic_signals ? Does
traffic_signals:direction=* bear additional meaning that direction=*
does not convey ?

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