Re: [Tagging] Traffic sign's relevant direction: direction=* vs. relation [Was: traffic_signals:direction=* vs. direction=*]

[yo paseopor]

I would start a "definitive thread" with all the options, all the
possibilities, all the points of view, all the information and then,
passing all to the wiki with a votting or aproved by list complete
proposal. Some people is watching us and in a near future will try to
collaboret with us so it would be interesting to be ready to this "big
thing"

Salut i senyals de trànsit (Health and traffic signs)
yopaseopor
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Traffic sign's relevant direction: direction=* vs. relation [Was: traffic_signals:direction=* vs. direction=*]

[Jean-Marc Liotier]

On Fri, 24 Mar 2017 07:22:44 -0700
Tod Fitch  wrote:
>
> It is not clear what we have gained by spitting the original topic
> into multiple parts.

Nothing... Had I been aware of the other thread I would probably not
have started this one !

Oh well... 'git merge' for mailing list messages ?

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

Re: [Tagging] Traffic sign's relevant direction: direction=* vs. relation [Was: traffic_signals:direction=* vs. direction=*]

[Tod Fitch]

> On Mar 24, 2017, at 7:04 AM, Jean-Marc Liotier  wrote:
> 
> On Fri, 24 Mar 2017 00:15:41 +0100
> yo paseopor  wrote:
>> On Thu, Mar 23, 2017 at 9:03 PM, Martin Koppenhoefer
>>  wrote:  
 On 23 Mar 2017, at 17:23, Jean-Marc Liotier 
 wrote:
 
 - highway=stop+direction=forward node on the incoming way... Only
 covers the simple case but covers it simply  
>> 
>> I prefer the subkey :forward / :backward because then we save one
>> pair of key=value we can use to put the future unification of the
>> meaning of traffic signs groups.
> 
> I was thinking about unifying using direction=* for all of them
> starting now... But well - yours is an alternate way, which I find
> acceptable too.
> 

It seems to me that having multiple orthogonal semantics for “direction=*” is 
less than ideal. If “direction= forward | backward” is retained and promoted 
for a node that is on a way, then alternatives to “direction = N | NE | E | SE 
| S | SW | W | NW | 0-360” be promoted for nodes that are not on a way.

We now have three related threads on this general topic at present: “The 
direction= tag”, “traffic_signals:direction vs direction=*” and “Traffic sign’s 
relevant direction: direction-* vs. relation”. It is not clear what we have 
gained by spitting the original topic into multiple parts.



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

Re: [Tagging] Traffic sign's relevant direction: direction=* vs. relation [Was: traffic_signals:direction=* vs. direction=*]

[Jean-Marc Liotier]

On Fri, 24 Mar 2017 00:15:41 +0100
yo paseopor  wrote:
> On Thu, Mar 23, 2017 at 9:03 PM, Martin Koppenhoefer
>  wrote:  
> > > On 23 Mar 2017, at 17:23, Jean-Marc Liotier 
> > > wrote:
> > >
> > > - highway=stop+direction=forward node on the incoming way... Only
> > >  covers the simple case but covers it simply  
> 
> I prefer the subkey :forward / :backward because then we save one
> pair of key=value we can use to put the future unification of the
> meaning of traffic signs groups.

I was thinking about unifying using direction=* for all of them
starting now... But well - yours is an alternate way, which I find
acceptable too.

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

Re: [Tagging] Traffic sign's relevant direction: direction=* vs. relation [Was: traffic_signals:direction=* vs. direction=*]

[Jean-Marc Liotier]

On Thu, 23 Mar 2017 21:03:47 +0100
Martin Koppenhoefer  wrote:
> > On 23 Mar 2017, at 17:23, Jean-Marc Liotier  wrote:
> > 
> > - highway=stop+direction=forward node on the incoming way... Only
> >  covers the simple case but covers it simply  
> 
> 
> while this might work often with stop signs it'll hardly work with
> maxspeed signs, because the changing maxspeed requires to split the
> highway, so that there would be 2 highways ending in the same node
> and forward would not be clear of which way.

Maxspeed is a way attribute... Some may tag the sign anyway - I'll let
them have their fun but it doesn't make any sense to me.

stop, give_way and traffic_signals on the other hand, they are nodes.

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

Re: [Tagging] Traffic sign's relevant direction: direction=* vs. relation [Was: traffic_signals:direction=* vs. direction=*]

[Topographe Fou]

It's a different topic: speed, height... Mainly apply to a way whereas stops 
mainly (always ?) apply to a node.

Speeds can still be tagged on the way and the sign put appart from the road, 
mainly for rendering purpose because the way it applies to is already tagged 
with the consequence (the speed).

In this thread I already proposed the same mechanism for stops, i.e. a node for 
the sign at it's exact location (for renderers) + a node on the way at the 
location where the car has to stop/halt/slow down (for routing engine). This 
way we can address both needs (routing engine are not the only data consumer ;) 
). What do you think?

LeTopographeFou 


  Message original  
De: dieterdre...@gmail.com
Envoyé: 23 mars 2017 9:05 PM
À: j...@liotier.org
Répondre à: tagging@openstreetmap.org
Cc: tagging@openstreetmap.org
Objet: Re: [Tagging] Traffic sign's relevant direction: direction=* vs. 
relation [Was: traffic_signals:direction=* vs. direction=*]

sent from a phone

> On 23 Mar 2017, at 17:23, Jean-Marc Liotier <j...@liotier.org> wrote:
> 
> - highway=stop+direction=forward node on the incoming way... Only
>  covers the simple case but covers it simply

while this might work often with stop signs it'll hardly work with maxspeed 
signs, because the changing maxspeed requires to split the highway, so that 
there would be 2 highways ending in the same node and forward would not be 
clear of which way.

When I map traffic signs it's mostly city limit, maxspeed/maxweight/maxheight 
and I do it generally for fellow mappers (including myself) because the effect 
of the sign I will map on the highway (typically linear, not just a point). 
Mapping on the side of the road has worked out perfectly for this scope.

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] Traffic sign's relevant direction: direction=* vs. relation [Was: traffic_signals:direction=* vs. direction=*]

[yo paseopor]

On Thu, Mar 23, 2017 at 9:03 PM, Martin Koppenhoefer  wrote:

>
>
> sent from a phone
>
> > On 23 Mar 2017, at 17:23, Jean-Marc Liotier  wrote:
> >
> > - highway=stop+direction=forward node on the incoming way... Only
> >  covers the simple case but covers it simply
>

I prefer the subkey :forward / :backward because then we save one pair of
key=value we can use to put the future unification of the meaning of
traffic signs groups.

while this might work often with stop signs it'll hardly work with maxspeed
> signs, because the changing maxspeed requires to split the highway, so that
> there would be 2 highways ending in the same node and forward would not be
> clear of which way.
>
For consistence , whit two ways with the same directions, which problem do
you have if the splitted way marks the direction...to the same direction so
is coherent between nodes and the two ways?

>
> When I map traffic signs it's mostly city limit,
> maxspeed/maxweight/maxheight and I do it generally for fellow mappers
> (including myself) because the effect of the sign I will map on the highway
> (typically linear, not just a point). Mapping on the side of the road has
> worked out perfectly for this scope.
>

Using the :forward/backward scheme and with Kendzi3D I get the situation
very similar to reality as you can see in these pics, [1] and [2]. I can
map any traffic sign you have in any traffic law which have a code. People
like Mapillary do some classification we can "copy" or use/propose similar
in a future unification of the keys with meaning for traffic signs , fa
away than only city limit,
maxspeed/maxweight/maxheight/stop,give_way,traffic signal.

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

[1] http://imgur.com/7FCO9ec
[2] http://imgur.com/WDUAWSa
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Traffic sign's relevant direction: direction=* vs. relation [Was: traffic_signals:direction=* vs. direction=*]

[Martin Koppenhoefer]

sent from a phone

> On 23 Mar 2017, at 17:23, Jean-Marc Liotier  wrote:
> 
> - highway=stop+direction=forward node on the incoming way... Only
>  covers the simple case but covers it simply


while this might work often with stop signs it'll hardly work with maxspeed 
signs, because the changing maxspeed requires to split the highway, so that 
there would be 2 highways ending in the same node and forward would not be 
clear of which way.

When I map traffic signs it's mostly city limit, maxspeed/maxweight/maxheight 
and I do it generally for fellow mappers (including myself) because the effect 
of the sign I will map on the highway (typically linear, not just a point). 
Mapping on the side of the road has worked out perfectly for this scope.

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

Re: [Tagging] Traffic sign's relevant direction: direction=* vs. relation [Was: traffic_signals:direction=* vs. direction=*]

[Jean-Marc Liotier]

On Thu, 23 Mar 2017 16:31:47 +0100
Martin Koppenhoefer  wrote:

> 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

Wow, thanks - how did I miss this thread... Well, the good news is
that the question of traffic sign direction modeling is in the air !

So, OSRM doesn't grok relations and doesn't process direction=*
either, nor any of its cousin tags - and the whole thread does not
mention anything else that does, with the exception of Kenzi3D which
does  direction=* ... Very well then: since there is very little
consumption to impact with the choice of a modeling method, I would say
that we are rather free to propose an Openstreetmapically correct way
and data consumers shall follow.

After reading the thread, it seems that our ideas here are not
unlike what has been discussed there.

So I stand by my current position, supporting either or both:

- relation (type: to be defined) including the highway=stop node and
  the incoming way with a from:forward or from:backward role...
  Universal but some consumers such as OSRM balk at processing relations

- highway=stop+direction=forward node on the incoming way... Only
  covers the simple case but covers it simply

I believe that boiling down the issue to just those two (and maybe live
with them both for an indeterminate duration) would significantly
improve over the current state.

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