[mkgmap-dev] Filters for overview map

Tue Jun 16 19:37:16 BST 2009

Hi Johann,

first some introduction to the overview map:

It's only used in mapsource.
If you have multiple tiles (for different areas) there is
exactly one polygon (rectangle) for each tile. The name for
the polygon is the name of the tile plus its map name (the
eight digit name).

It has a resolution of about 13 (shiftlevel 11). One unit
length is on the order of km. The map in that tile usually
has a much better resolution, even at its worst level. So
the rectangles of the overview map have to be unaligned
to the borders of the tile.

On Tue, Jun 16, 2009 at 12:03:52AM +0200, Johann Gail wrote:
[...]
> In general i find it an good idea to split up a problem into small 
> parts, but at the moment I cant see the whole thing. Why is it 
> neccessary break things down to smaller rectangles to get an improvement 
> in alignment?
> Yes, I have seen this error and up to now i thought, there was some 
> rounding error in it.

It's rounding errors, yes. And rounding trickery.

The problem exists mainly with very small tiles. One can
either try to massively enlarge it before the SizeFilter
kicks in, or get it with an acceptable size, which could be
(1 x 1) units^2 in the relevant resolution. It's on the
order of km, so a 1x1 rect is still large.

> >In my testing it turned out, that the SizeFilter and the
> >DouglasPeuckerFilter either dropped my small rectangles or
> >converted them to a triangle.
> >
> >Removing the filters fixed this for me.
> >
> >
> >If you think, that the generated rectangles should be large
> >enough, so that they're not "cleaned":
> >- If this is so, then there really is no reason for
> >  calling the filters anyway, they should be NOPs in that
> >  case. So we can optimize them away.
> >  
> My opinioin:
> I dont know the special case for the overview map. On a normal map layer 
> I dont assume that all elements are large enough. If an element is to 
> small to be displayed then we can drop it completely.

If you drop one polygon, the reference to one tile is
dropped, which finally means, that this tile is not
displayed at all by mapsource. We may not drop a single
polygon, because we want to show all tiles in mapsource.

> >- I hope to show in later patches (don't hold your breath!
> >  I will go slowly step by step. There is no need to hurry
> >  anyway) that smaller rects might make some sense.
> >
> >  
> As said before, I dont know the complete background. Maybe with the 
> overview map it is reasonable to not drop the indisplayable things.

It's not indisplayable. The resolution is just very bad,
even for zooming in to meters. It's just containing the
"borders" of the map tiles. So it doesn't really need
better resolution.

[...]
> With this patch you introduce the possibility to disable filtering. I 
> see nothing destructed, but (at the moment) no use in it.
> 
> But if I understand it correctly, then the filtering is switched of for 
> the complete overview map layer. Wouldn't that increase file size a lot? 
> I would expect at this resolution a lot of filtered small streets.

As said above, there are no streets or anything else in the
overview map.

> More 
> important: Does it increase redrawing speed at low zoom levels, which is 
> possibly the main use of a overview map? Or is the overview map not used 
> at the gps unit?

It's only used by mapsource. It's only generated if you
call with --tdbfile.

> The main intention for the douglas peucker filter was the low drawing 
> speed on my etrex handheld at low zoom levels.
> 
> Don't be discouraged by my critics. It are only my thoughts at the moment.
> 
> Regards,
> Johann
> 
> 
> 
> 
> 
> _______________________________________________
> mkgmap-dev mailing list
> mkgmap-dev at lists.mkgmap.org.uk
> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev