[mkgmap-dev] [PATCH v1] make DP filter avoid removing points located at nodes

Mon Nov 23 21:07:06 GMT 2009

>  
>   
>> So in my opinion the error is in the copy function of the line. If a 
>> line contains CoordNodes, than also the copy should contain CoordNodes. 
>> Can you point me to the code, where the lines gets duplicated?
>>     
>
> Whenever a routable way gets split to limit the number of points or
> nodes it makes a new list of points so any changes to the points in the
> new list will not be visible in the original list.
>   
Yes, its true that changes in the copy will not be visible in the 
original. But this is not my point. My point is: If the original line 
contains CoordNodes (instead of Nodes) then the copy should also contain 
CoordNodes.
I think, this will complicate the split/copy functions in some ways, so 
maybe your solution is the easier way.
>  
>   
>> This all was some unfinished work of the dp filter. I would need some 
>> time to understand the classes structure in full and prepare a solution.
>>     
>
> Well, I think the outstanding issue at the moment is whether the DP
> filter can be made more aggressive at the lower resolutions.
>   
The DP filter could be surely made more aggresive at lower resolutions. 
The simplest way to do this would be to remove the condition at lower 
resolutions or even complete.

            // If a node in the line or coord lies on a boundary
            // then use the douglas peucker algorithm for upper segment
            // TODO: Should consider only nodes connected to roads 
visible at current resolution.
-            if ((p instanceof CoordNode) || (p.getOnBoundary())) {
+            if ((p instanceof CoordNode && resolution == 24) || 
(p.getOnBoundary())) {
                douglasPeucker(coords, i, endIndex, maxErrorDistance);
                endIndex = i;
            }

But the side effect will be that T-crossings will not always meet 
exactly. With the current distance of 5.4 the errors should be small 
enough to be invisible on a gps unit. We should test it.

> The idea of combining ways to reduce the number of segments is
> interesting but at odds with our current strategy of limiting the
> length of ways due to routing problems. More thought required there.
>   
Yes, I have played with this idea and made a patch public some time ago. 
It made the dp filter working really much more better at low 
resolutions. But there was two or more problems with it.
First it disturbs routing. This seems to be caused by merging the lines 
AFTER the routing tables are created. (Thinking about it, i came to the 
solution to limit the merge filter to nonroutable lines will solve this 
problems)
Second it combines the lines after your splitting for the MAX_LENGTH. So 
it is possible to get lines longer than MAX_LENGTH.

Maybe the size limit should be checked after all other filters. This 
would have as a side effect the advantage that it works also for polish 
input files and not only osm files.

Regards,
Johann