Gerd,

Ahhh... Now I understand what you mean. I think you initially mean "redundant" versus "obsolete" - I was confused by "obsolete" thinking that the restriction should use a different method due to an outdated methodology.

For the example, turn restriction 3843893 was the one that made the initial turn restriction 2256354 redundant. If 3843893 had not been there, what would the suggestion be?

I'd suspect that relation 3843894 is still needed regardless as the startpoint is different.

Thanks

On Sat, 5 Oct 2019, Gerd Petermann wrote:

Date: Sat, 5 Oct 2019 13:31:09 +0000
From: Gerd Petermann <[email protected]>
Reply-To: Development list for mkgmap <[email protected]>
To: Development list for mkgmap <[email protected]>
Subject: Re: [mkgmap-dev] Turn Restrictions using three ways - design guide
    for OSM mappers?

Hi blc,

there are already normal restrictions [1]  which look correct to me, so as I 
said before this one is obsolete. I think it should be removed.
Besides that I would not add restrictions without local knowledge or other 
allowed sources.

Gerd
[1] https://www.openstreetmap.org/relation/3843893
https://www.openstreetmap.org/relation/3843894

________________________________________
Von: mkgmap-dev <[email protected]> im Auftrag von blc 
<[email protected]>
Gesendet: Samstag, 5. Oktober 2019 08:53
An: Development list for mkgmap
Betreff: Re: [mkgmap-dev] Turn Restrictions using three ways - design guide for 
OSM mappers?

Gerd,

Thanks for the reply.

So it looks like it's still being handled, but would you say that these
should be changed in OSM?

It seems a bit strange that if you're on way A, you must travel through
way B and get to way C, but indeed it is true that if you weren't allowed
to make any turn at the point between A and B (and B and C), you'd get the
same result -- is this the prefered way of denoting such?

For this particular example in OSM I suspect the mapper did not
want to allow right turns at the intersection (even if it's not
illegal) and hence wrote the restriction as an only left way-way-way
instead of a way-point-way no right turn, perhaps because of either a sign
or the paintings on the road and you can't make an "only left turn" on the
first intersection of the dual carriageway because that's the wrong
direction.

How should this particular intersection be restricted from travel to not
emit warnings?  Adding that no right turn at the first intersection
would probably have the effect, but I've seen a lot of these way-way-ways
around (mostly dealing with complex dual carriageway intersections between
multiple roads) and wonder if it's worth "fixing" them, or should these
warnings be simply ignored for the most part?

Thanks!

On Sat, 5 Oct 2019, Gerd Petermann wrote:

Date: Sat, 5 Oct 2019 05:43:56 +0000
From: Gerd Petermann <[email protected]>
Reply-To: Development list for mkgmap <[email protected]>
To: "[email protected]" <[email protected]>
Subject: Re: [mkgmap-dev] Turn Restrictions using three ways - design guide
    for OSM mappers?

Hi blc,

the code that produces these warnings is this:
               if (valid && !viaWays.isEmpty() && 
restriction.startsWith("only")){
                       log.warn(messagePrefix, "check: 'via' way(s) are used 
in",restriction,"restriction");
               }

So, mkgmap considers them valid, but dubious. I think that's what they are. The 
restriction says something like
"when you want to travel from way A via way B to way C you MUST travel from A via B 
to C"
What kind of restriction is that? In my eyes, the given example is completely 
obsolete.
On the other hand, a "no-" restriction with via way(s) means
It is not allowed to go from A to C via B. This cannot be expressed with a 
single via node.

Hope that helps?

Gerd

________________________________________
Von: mkgmap-dev <[email protected]> im Auftrag von blc 
<[email protected]>
Gesendet: Samstag, 5. Oktober 2019 06:31
An: [email protected]
Betreff: [mkgmap-dev] Turn Restrictions using three ways - design guide for     
OSM mappers?

Hello, I thank all who have been working on this neat program to allow our
otherwise old Garmins sit in the dust heap when we can't afford to
subscribe to new maps.

I've been trying to improve the quality of OSM by fixing the errors
that mkgmap emits, which a lot of times mirrors what's seen in
KeepRight.  However there's one variant of turn restriction I've noticed
that warns in mkgmap but do not show up in KeepRight (and iD seems to
understand this type of turn restriction) - the way-way-way type
restriction where three connected ways are in series for non no-u-turn
restrictions.


example:

Turn restriction (only_left_turn) 2256354 (at
https://www.openstreetmap.org/?mlat=47.777585&mlon=-122.319488&zoom=17)
check: 'via' way(s) are used in only_left_turn restriction

The way-way-way type is the proper method for restricting u-turns
on dual carriageway roads which is understood by mkgmap.  On the
other hand, iD and KeepRight it seems to be valid to do way-way-way
instead of way-POINT-way for no/only left/right turn restrictions, no/only
straight on restrictions, etc.  I've seen a lot of the non no-u-turn
way-way-way restrictions in the USA.

These type of non no-u-turn restrictions seems to cause a warning in
mkgmap and probably not translating them.  My question is that should
these be supported in mkgmap, or should these be fixed in OSM so that they
are simple way-via-way despite iD and KeepRight seem to claim them
valid?  Or perhaps way-way-way is deprecated but still supported by OSM
but should be changed to way-point-way?

way-point-way = relation
from: some-street-way
via: some-intersection-point
to: some-street-way
(this is the most common type of turn restriction)

way-way-way = relation
from: some-street-way
via: some-street-way
to: some-street-way
(this is necessary specifically for dual carriageway u-turn restriction,
but it's used for other types as well which mkgmap complains about.)

Thanks for shedding some light on the discrepancy here!  Note: I'm
currently depending on OpenMapChest data for mkgmap runs as my computer
and internet connection are not large or fast enough for the quantity of
data I'd like to work with.
_______________________________________________
mkgmap-dev mailing list
[email protected]
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
_______________________________________________
mkgmap-dev mailing list
[email protected]
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev


WARNING: All HTML emails get auto deleted.  DO NOT SEND HTML MAIL.
WARNING: Emails with large typo counts/spelling errors will also be deleted.
_______________________________________________
mkgmap-dev mailing list
[email protected]
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
_______________________________________________
mkgmap-dev mailing list
[email protected]
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev


WARNING: All HTML emails get auto deleted.  DO NOT SEND HTML MAIL.
WARNING: Emails with large typo counts/spelling errors will also be deleted.
_______________________________________________
mkgmap-dev mailing list
[email protected]
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Reply via email to