[mkgmap-dev] Diagnostic warnings for dead-end oneway highway=service

Fri Jan 3 14:29:22 GMT 2014

Hi Marko,

okay, thinking again about endlessly traveling in a loop I guess it is a special form
of a deadend when there is no other exit ;-)
At the moment I have no idea how we can separate the
two cases, but I agree that this should be handled.

Gerd

From: gpetermann_muenchen at hotmail.com
To: mkgmap-dev at lists.mkgmap.org.uk
Date: Fri, 3 Jan 2014 15:10:27 +0100
Subject: Re: [mkgmap-dev] Diagnostic warnings for dead-end oneway highway=service

Hi Marko,

reg. p-shaped: 
The error was not in the foot, but in the other end. My understanding is that
that you can travel in that loop like in a roundabout, so it is not a dead end.

OK?

Gerd

> 
> >3) The new check did not recognize P-shaped oneways as self-connecting.
> 
> This was not a bug in the new check, but a bug in the old check!
> 
> I agree that by definition, looped ways cannot be dead ends.
> 
> For the purpose of detecting dead ends, we could ignore non-branching 
> loops formed by a sequence of ways. Actually, it does not matter if the 
> non-branching loops are oneway!
> 
> If there is no non-looped way connected to both ends of the "foot" of 
> the P, then the foot of the P forms a dead-end oneway. That is, a 
> P-shaped oneway should be treated just like an I-shaped oneway that is 
> obtained by removing the looped part.
> 
> Maybe you could use this idea to improve dead-end checks? Note that a 
> roundabout does not count as a non-branching loop, unless it is 
> connected to a single oneway flare road only.
> 
> >Attached is a new version of the patch.
> 
> Thanks, I will try it later for today's data. I already ran trunk and 
> the previous patch on the data.
> 
> >I think this is okay as long as you see the warning for way Y.
> 
> Me too, it is OK to be silent about some part of an error scenario, as 
> long as some of the connected ways get flagged. I usually download a 
> region around the problematic spot in order to figure out what the 
> intention is and how it should be fixed.
> 
> 	Marko
> _______________________________________________
> mkgmap-dev mailing list
> mkgmap-dev at lists.mkgmap.org.uk
> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

_______________________________________________
mkgmap-dev mailing list
mkgmap-dev at lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.mkgmap.org.uk/pipermail/mkgmap-dev/attachments/20140103/e84be42f/attachment-0001.html>