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
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" .
Envoyé: 17 mars 2017 11:26 PM
Répondre à: email@example.com
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  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.
> 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)
Tagging mailing list
Tagging mailing list