On Wed, Mar 22, 2017 at 6:45 PM, yo paseopor <yopaseo...@gmail.com> wrote:
> > On Wed, Mar 22, 2017 at 11:31 AM, Paul Johnson <ba...@ursamundi.org> > wrote: > >> >> Turn restrictions are extremely common and managed using relations, so we >> know relations don't have to be hard. It's possible for the editors to >> adapt to make this easy. There's no real reason enforcement and similar >> from/to/device/force type relations can't be made easy at the editor level. >> > > I ask why we need a relation to put a traffic sign if it is in a way (not > at intersection), and with the information of the correspondence of the > direction of the way it is with a relation . Is duplicate work? > I'm not sure why there's such an aversion for relation primitives since the whole concept of relations was introduced to OSM to cover data like this that doesn't fit the simple point-and-vector scheme employed by nodes and ways. Nodes do not have a direction. Vectors do, and thus the simple node-way combination works great for simple examples. Such examples would be an all-way stop, a yield sign on a one-way freeway on-ramp, and similar scenarios where all movements to the traffic control node (ie, a node tagged highway=traffic_signals, highway=stop or highway=give_way) is going to be subject to that traffic control device for all possible movements. No relation would be necessary. Relations would greatly simplify the burden on data consumers for situations that can't be as readily captured by simple point-and-vector data as it eliminates any need for guesswork. For example, a four way intersection with stop signs facing (for example) north and south only, with east and west facing a priority sign or no sign. Currently, just plopping highway=stop on a node that is a part of the north and south way adjacent to the ground truth location of the stop sign is common practice, but will sound an alarm or get assigned a movement penalty for people turning from east or west to north or south. North to south or vice versa through movements, doubly so, because nodes are not vectors and thus lack direction. A traffic control relation could have the actual intersection node as having the role "to", and the north and south way assigned the role "from". Let's take another common situation: Let's assume traffic coming from the north and west face a stop sign, traffic from the east has no sign/a priority sign, and traffic from the south has a stop sign over an "except right turns" sign. One relation can cover the traffic from the north and west, similar to the two-way example as above. A second relation would handle the traffic from the south: With the south leg as a "from" and the north and west legs as a "to" with the intersecting node as "via". Data consumers could then take the stop sign into account when routing movements from the north or west, and from the south if turning west or north, while assuming all traffic from the east, and from the south turning east, is free flowing. It would also be able to model situations where traffic by different modes has different traffic controls. This is a common situation in North America when it comes to bicycle infrastructure (and I can go on about how stupid it is from a multitude of engineering and layman standpoints), where one direction (usually the cross street) faces traffic signals, while bicyclists or a school entrance face a stop sign. I'll use 21st and Midland Valley <http://www.openstreetmap.org/node/148323708> in Tulsa as an example (I go through this intersection daily, this Google Street View <https://www.google.com/maps/@36.1333451,-95.985062,3a,75y,297.58h,66.55t/data=!3m7!1e1!3m5!1s_nLxHPe87tpeoGfYGzhVBg!2e0!5s20160801T000000!7i13312!8i6656> is accurate). 21st street faces traffic signals, pedestrians crossing 21st on Midland Valley get a traffic light, bicycles get a stop sign. The two directions for Midland Valley could be "from" for a stop sign traffic control relation tagged except=foot. The traffic signal relation for the same direction would be tagged except=bicycle, both with the crossing node as "to". 21st wouldn't need to be part of a relation at all, as far as those two approaches are concerned, it's the same as any other signalized intersection (save for a high potential for jaywalking across the cycleway on a red given the necessarily strange intersection geometry). I'm all ears if anyone has another scheme that doesn't over-rely on context or attempting to invent a direction for a node.
_______________________________________________ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging