On Apr 13, 2014, at 11:28 PM, Peter Wendorff wrote: > Agree partly. It's not meaningless, but it get's ambiguous very often. > Take traffic signals as one example where the direction might be used: > Besides an intersection someone could add the traffic lights on the four > individual ways (instead on the intersecting node itself). > This matches the installation of the individual lights and the stop > positions, but it produces wrong results without a direction tag. > > The drawback of that is, that someone crossing the intersection straight > meets two traffic lights, which is wrong of course. The mapper therefore > might decide to add direction-tags to them, as each traffic light node > is relevant and applied only for one of the two directions. > > Looks perfect now - all four traffic lights are mapped separately where > they are, routing for cars works great (provided that the direction tag > is known and supported by routers). > > Enter of the next mapper: He want's to add the footways and cycleways > that cross the streets using the pedestrian traffic lights integrated in > the traffic lights mentioned above. > As a result the nodes previously mapped with a direction are shared by > two ways, and it's hard to determine what the direction tag refers to, > as of course crossing for pedestrians is possible and meaningful for > both directions.
Hmmm. The examples I've seen on the map and as I recall the traffic_signals portion of the wiki for "complex intersections" the traffic signal node is not placed where the signal is but rather where a vehicle must stop for the signal. That is prior to the crosswalk. So if a second mapper comes along and adds footways then those footways should not go through the vehicle traffic signal nodes. I haven't seen an example but it seems to me that the pedestrian signal should be on the new footway where a pedestrian should wait. So there should be no confusion as to the meaning of a traffic_signals:direction=forward/backward tag. On Apr 14, 2014, at 4:44 AM, fly wrote: > Ok, we can take a split between unconnected nodes on the > left-/right-hand-side of the road and nodes being part of a way. The > first are less ambigious but you still need to know the driving > directions where as the latter ones just won't work properly with > forward/backward. > > To make it less ambigious and easier I would deprecate forward/backward > completely for nodes and advice to use cardinal coordinates for all nodes. > At least for the case of traffic_signals:direction=forward/backward, the use should be unambiguous as they are currently defined. Cardinal directions could work but I wonder about errors and ambiguity that might crop up in the consumers of this data. I suppose that there might be some very detailed map renderers that wish to show all signals, signs, etc. But I've assumed that this information was primarily intended to make routing more accurate. Forward/backward along the direction of a way is information any routing algorithm has immediately at hand. But what about a road that makes an sharp bend just before the intersection? We sometimes have these here where two roads come in at an angle and the traffic engineers decided to make the intersection as close to a right angle as possible for safety reasons. I can see a human mapper assuming the tangent the road has before and after the intersection as the cardinal direction but routing software might not easily figure that out. Is there anyone following this thread that is doing work that consumes these tags? If so what is easier and less error prone to process? Regarding using relations, given the multitude of human errors introduced into existing relations by people making changes, I'd argue that very good support for traffic signal relations be built into all editors if this is the direction people wish to take. That does not seem to be the case currently for many types of relations, even simple ones like route relations. -Tod
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
