On Tue, 31 Mar 2009 08:55:54 -0400, Greg Troxel <[email protected]> wrote: > As you can see there is a roundabout, but there is also a dual > carriageway through the middle with the flow controlled by traffic > lights. If you are in the lanes which go through as the dual > carriageway you can't turn onto the roundabout, and if you are in > the lanes that lead onto the roundabout you can't turn onto the dual > carriageway lanes. I think for the relations to work I might have to > split the roundabout from a closed way into a number of sections, > but I've always drawn roundabouts as closed ways before. Will > splitting it cause issues with anything else? Although I might not > have to split as the via (node) will indicate where the restriction > actually applies, even when the dual carriageway lane crosses the > roundabout at two nodes. Or perhaps I could just split the dual > carriageway lanes somewhere in the middle of the roundabout to make > things easier for me to work out what restrictions I need to add. > > I haven't thought this through, but I wonder if you could add relations > to describe road groups, putting all the dual carriageway ways in one > relation, and all the roundabout and link ways in another, and then > adding a turns_prohibited restriction between those two relations. This > seems pleasing since there is logically one extra rule to explain to > humans - no turning between the roundabout and the dual carriageways > that cross it. Of course this nested relation/restriction complicates > routing software but perhaps not too badly.
There is no need for any additional relations to describe these turn-restrictions. It's just a bunch of "only_ahead". However a relation to group the left and right lane of a dual-carriageway is a very welcome thing for many algorithms. What about: type=road to collect the ways of a long street and if it's a dual-carriageway some may have a role of "left" or "right" while for single carriageways and sections where the ways are joined temporarily have some other role. Marcus _______________________________________________ talk mailing list [email protected] http://lists.openstreetmap.org/listinfo/talk
