I have added a check on whether the 'via' is the first/last node in the from and to ways
On Sun, Sep 14, 2008 at 8:12 AM, Nic Roets <[EMAIL PROTECTED]> wrote: > > Would be great if it could also check this: > > > > * a way may not be in any "from" or "to" role if it goes *through* the > > junction (because in that case the information would be incomplete - you > > would need to know which part of the way is meant!). > > Just to clarify : For example A ends in a T junction where it meets B. > 'to' is B and goes through so it may be unclear if the restriction > applies to a left turn or a right turn into B. (Traveling forward / > backwards in B). Hmm, I've been slow - I hadn't full appreciated the scope of the problem ;-( Splitting every way that is part of a turn restriction is going to lead quite a few more ways. Although I'm not sure this is a restriction problem, similar things happen with classification changes or bike routes etc > > > Gosmore currently requires the 'restriction' tag because it uses it to > distinguish between the two. (And it ignores anything with "half", > "left_right" and "right_left") Specifically it measures the angles > between the segments and considers turns less than 45 degrees to be > straight ons and turns more than 135 degrees to be u turns. So there > have been at least one case in Australia were it was mapped as > no_right_turn while gosmore considered it a u turn. Of the 3 solutions > ("no_u_turn", "only_straight_on" and adding a node to give the > junction a T shape), the mapper chose the latter. Ahh, I wonder if this is what is causing some of the weirdness I am seeing with route debugging. Can you send me a permalink to the case in Australia > > > I can't see that I will have time to implement anything else before > 2009. So I recommend mappers to take the 30 seconds and add the > restriction tag and perhaps an extra node. (Just like I recommend > always add bicycle=yes/no to trunk roads). > > If both roads goes through, Relation:restriction simply does not have > enough info. (Relation:xrestriction will have enough info, but is not > supported or used). So then you have to split at least one of the > ways. I should just point out that the newbies here in Pretoria have > blindly recombined ways. In the first case the one way had layer=1 and > the other didn't have layer set, so the recombine did not result in a > conflict resolution dialog. This may well happen in cases where ways > were split to make relation:restriction unambiguous. > > O.T. : In the other case(s) the newbie set the layer and name of the > combined way to "1; 2" and "Old Pretoria Road; Old Pretoria Road" > respectively. > > > Nic has said that he uses the "restriction=..." tag to clarify these. I > > don't like that idea but if it is used widely then my above rule would > > have to be lifted for relations with a "restriction..." defined. > > There are only 500 odd restrictions. So editing them all should not > take more than a few hours. > > P.S. : I have a very simple proposal for encoding restrictions that > never requires splitting ways, and unlike xrestriction it will keep on > working if the someone adds an extra node in the final segment.The > only drawback is that users will find it difficult. So the best time > to adopt it will be when one of the editors gets a restriction editor > function. > > Regards, > Nic > > > > > Bye > > Frederik > > > > -- > > Frederik Ramm ## eMail [EMAIL PROTECTED] ## N49°00'09" E008°23'33" > > > > _______________________________________________ > > talk mailing list > > talk@openstreetmap.org > > http://lists.openstreetmap.org/listinfo/talk > > > cheers -- Franc
_______________________________________________ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk