I put stops, give ways and traffic light where the car has to stop/yield which 
can be far from the position of the sign (for instance in the US where the 
light is after the junction, thus may not be crossed if you turn). Also on 
narrow junction you may have the lights at the junction but the stop line some 
meters before to let buses make there turn.

To match all use cases a new scheme has to consider the tagging of both 
stop/yield positions on the road and position of the sign/light (like for bus 
stops). One may think of relations as one explicit way of linking all those 
informations (like restricted turns). Any algorithm which try to deduce a 
position on a road from a position sign will be buggy at some points and greedy.

Then we have to consider that at some junctions the direction/orientation of 1. 
The way 2. The stop/yield line (if any) and 3. The sign/light may be three 
different values!

And yes, OSRM is not the only data consumer to look at (even if it is a good 
one :) ). I dream of a routing app which would warn me of stops/lights in front 
of me or say "At the stop, turn right" instead of "Turn right" .


  Message original  
De: t...@fitchdesign.com
Envoyé: 17 mars 2017 11:26 PM
À: tagging@openstreetmap.org
Répondre à: tagging@openstreetmap.org
Objet: Re: [Tagging] The direction=* tag

If micro mapping, then the stop sign is usually not in the center of the 
traveled way (though I have occasionally seen some there). For micro mapping, 
place a node for the sign where it exists on the side of the road and then use 
the compass direction to indicate how it is facing. As it is detached from the 
highway way forward and backward can have no meaning.

The “highway=stop | give_way” tag on a node on way might be used by map 
rendering, which probably doesn’t care if it has forward or backward tagging. 
I’ve been using Mapnik XML for rendering my maps and I don’t recall the ability 
to detect the direction of a way. Or even if something that is being rendered 
by the point symbolizer can tell if the point is on a way. I could be wrong on 
that. And even if wrong, maybe some rendering tool chain will support that in 
the future. But at present I am pretty sure that map rendering can’t use 
“direction=forward | backward”. It can (and my rendering does) use the compass 
points and/or degrees values for rotating icons in the point symbolizer.

I strongly suspect that tagging the stop/give way sign in the middle of the way 
is for the use of routing and route guidance. It might still be of use by 
guidance (though I am not sure the “direction=forward | backward” matters much 
in that case) but what I am hearing is that as implemented/specified now it is 
not useful for routing. Thus my comment about noise.

I have been following the tagging suggested on the wiki [1] and checking the 
direction of the way in order to determine the value to put on the direction 
tag is tedious. If it is not being used, I might well forgo the direction tag. 
Fortunately the same wiki page states direction is only needed if the signs are 
closely spaced and it is not obvious which intersection/direction the sign is 
for, so the direction tag in that case is almost always optional per my 
interpretation of the wiki.



> On Mar 17, 2017, at 2:47 PM, yo paseopor <yopaseo...@gmail.com> wrote:
> I don't agree with this: marking the direction of the traffic sign is not 
> noise, for a driver can be VITAL, also with the meaning of the traffic sign 
> (the main purpose of a traffic sign).
> Why? Because in a way with two directions we need to know to what direction 
> traffic sign it is for. It is not the same a road cross with an STOP forward 
> than backward (with micromapping it is not the same one lamp than two)
> Put a key like direction is not the best option, because this information can 
> be inside the key itself like traffic_sign:forward or traffic_sign:backward.
> Also it is a good thing to say of what side of the way the traffic sign is.
> In some countries traffic sign of a side is not the same as the other side 
> specially in streets in a city.
> e.g.
> traffic_sign:forward=ES:R2
> highway=stop
> side=right
> Ok, OSMR do not use that...but other tools uses this information so it is 
> important to keep it at the data.
> In a short-term, people like Mapillary or OSC will give us the opportunity 
> (and the data) to map all the traffic signs in a way. Routers and navigation 
> apps should be prepared for that. OSM is nowadays capable of show all this 
> information. Don't make it disappear.
> Salut i mapes (Health and maps)
> yopaseopor

Tagging mailing list
Tagging mailing list

Reply via email to