[mkgmap-dev] Etrex sea floods tile unless well zoomed out

Mon Mar 1 18:11:43 GMT 2010

On 01.03.2010 18:51, Mark Burton wrote:
> OK - I think I found what was wrong. I recently removed the 0x4b poly
> from the TYP file and that was the only poly on level 1. What I didn't
> realise is that all the polys on higher levels then got shifted down
> one level so that the sea poly was now on level 1 (I guess the etrex
> does something funky with polys at level 1).
>
> Fortunately, I could revert the commit that removed the 0x4b poly
> from the TYP file and so I didn't have to tediously change the levels of
> all the polys again. Hurrah for version control software!
>
>    
Doesn't sound right to me. There is no need for 0x4b at all (my maps do 
not contain 0x4b). The only thing that I could imagine that happenend 
based on your above description is that both sea and land were at the 
same level, or that the polygon for land was not correctly set. Try 
using maptk for Typfiles, ati.land makes too many errors.
There is definitely neither a need to have 0x4b inside typfile, or map.

So here is my take on transparency.
transparency switch tells the GPS to use a color for the background 
polygon (usually 0x4b). The assumption is that all maps do contain 0x4b.
So transparency switch only works corrctly if map contains 0x4b polygon. 
If a map were created without any polygons at all, it would always be 
transparent. Setting it opaque would not work and it would look and work 
exactly like a map with only 0x4b polygon set to transparent.

Therefore when using mkgmap with --generate-sea=polygons we can drop 
0x4b polygon alltogether. We even could draw sea only where it really 
is, and draw land for the rest. There is no need for sea polygon to span 
the whole background. 1 Polygon is enough.
> Mark
> _______________________________________________
> mkgmap-dev mailing list
> mkgmap-dev at lists.mkgmap.org.uk
> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
>    