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
