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
