[mkgmap-dev] Putting the DP code under the microscope

Sat Jul 25 11:39:48 BST 2009

Hi Johann,

Am 25.07.2009 um 10:54 schrieb Johann Gail:

> A further development would be, to consider only nodes which are  
> visible
> crossings at the current zoom level. I.e. if a residential connects  
> to a
> big road and the residential is not visible at the current zoom level,
> then it is allowed to zap this node. This would straighten out lines  
> at
> low zooms much more. But at the DP filter code I don't have this
> information available.

Yes, that would be the best way. But one would need to change a lot of  
the underlying code to make it happen, as currently only the number of  
highways that use a node is stored, but no reference to which highways  
that are. Changing this would be a major act unfortunately.

About the error distance: What I still experience is that the lower  
resolutions look bad in the maps. It seems that the ways get too much  
simplified for lower resolutions. It seems almost like a scaling  
problem with respect to the resolution. I reduced the error distance  
to 1/8th of the resolution and that brought some improvement in the  
higher resolutions (20, 22). But if I look at the lower resolutions  
(down to 12) it gets worse and worse. Looking at the DP code I can't  
find any hint why that should happen, so it might happen somewhere  
else? I have no clue.

> Btw.: there is another patch around, which merges lines before DP
> filtering them. This is reasonable for the highways at very low zoom
> levels, which could be simplified often to a sinlge line in the  
> overview
> maps. (But only if they are not cut in segments from exit to exit).
> If I find some time I will release an updated patch for it.

this is very interesting. I was planning to implement something likes  
this for some time, but didn't get around to do it. But not so much  
for display, but for routing. I think the routing could be much  
improved if we would merge ways, especially for bicycle routing, where  
the cycleways consist of tiny bits here and there. The routing  
algorithm in the Garmin units then won't find a nice route, because it  
gives up trying to wiggle its way through the short bits. Instead it  
takes a long way that goes into the general direction of the  
destination. Which often happens to be a major road that you don't  
really want to use while cycling. The cycleway going alongside it  
isn't used, because the routing algorithm doesn't find it.

So if you have that patch available please post it. Even if it doesn't  
work against the current trunk I'll happily try to make it work.

Regards
Thilo