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

Mon Jan 6 20:50:26 GMT 2014

On Mon, Jan 06, 2014 at 08:02:57PM +0100, Gerd Petermann wrote:
>before I retired I worked for a company that develops tools around the 
>(job) scheduling tools in IT centers. One typilcal problem in this area 
>is a loop of dependencies (job a depends on b, b on c, c on d, .. , x 
>on y; y on b) which may result in deadlocks.
>In such a loop it is not possible to say which dependency is wrong, you 
>can only list the elements of the loop and an expert has to say where 
>the loop has to be split.
>Still our customers asked for a tool to show THE wrong depency.
>Your email reminded me a bit on this ;-)

Yeah. :)

By the way, I was wondering how you have so much expertise and energy to 
work on this. (I cannot code anything big on spare time, because my 
brain needs a break after working on complex coding problems at the day 
job.) Now I got the answer. Nice to see that active OSM development is 
not only for students and young people.

Your example is very similar to using a model checker. For a safety 
property violation (say, an assertion on the global state, or a check 
for a system-wide deadlock) the model checker would give you a 
(shortest) path of actions leading from the start to the error.

For a liveness property violation, the counterexample would be a path to 
a non-progressing loop, plus the loop itself.

>In the OSM case, maybe it is a way that is missing and not a wrong 
>oneway tag. I think someone has to visit the place to find out.

Right. The "global" check could at most say "something might be wrong", 
and human intervention would be required. In my experience, even for 
"local" errors it is useful to look at the surroundings, to see if the 
JOSM Validator reports any errors nearby.

>Another question is what we can do with such "wrong" data in the map 
>produced by mkgmap.

One option could be to emit a warning, saying that we are going to strip 
oneway=* from way X in order to avoid a potential problem. This could be 
enabled by --report-dead-ends=3 if we want this to be optional.

Also, what would the Garmin routing algorithms (different versions of 
Mapsource etc.) do with such data?  For example, can the routing get 
stuck if a P-shaped oneway (with no junctions to other roads, besides 
from the foot of the P) is the closest way to the starting point or the 
destination point? Does it matter if the P is split into "foot" and 
"loop" parts in the Garmin map?

	Marko