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

Sat Jul 25 12:05:55 BST 2009

Yeah, merging roads if possible would be great. Even more important
would however be smoothing of curves. i.e. make serpentine corners on
mountain streets more smooth, because otherwise if there is a say 160°
corner, it will add a big time penalty, which in a car is more or less
correct, but on a bicycle overrated.

However, how do you want to do the merging without loosing attributes
(i.e. roadname changes, bridge, etc..), I think this could only work
by running after the main processing, and merging everything identical
if possible.

Otherwise before merging there needs to be a check whether there is
not a rule in the style-file that would change either the name of the
road OR the type (0x??) of a road. If both not changed then merge it.

Nice to see some work on it.

On 25/07/2009, Thilo Hannemann <thannema at gmx.de> wrote:
> 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
>
> _______________________________________________
> mkgmap-dev mailing list
> mkgmap-dev at lists.mkgmap.org.uk
> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
>