"Ævar Arnfjörð Bjarmason" <[email protected]> writes:

> On Thu, Dec 18, 2008 at 8:10 PM, Matthias Julius <[email protected]> wrote:
>> "Ævar Arnfjörð Bjarmason" <[email protected]> writes:
>> I guess you were looking at empty tiles (67 or 69 bytes).  Empty tiles
>> are not optimized.  In fact, they are never written to disc.  When the
>> client finds during tile splitting that a tile is empty it throws the
>> tile away and copies emptyland.png or emptysea.png from the client's
>> root directory.  Those are actually 1 pixel PNGs with 67 respective 69
>> bytes size.
>
> I should have been clear on that. No they were not empty tiles (I read
> the tile optimizing code and noticed the empty tile optimization you
> mention). What I was rendering was a glacial area which 1844,1089 is
> an example of. In cases of such tiles Tileset.pm will optimize each
> and every individual z17 tile even though the greater z12 tile
> consists of only two colors with a thin line running through it, if
> I've understood it correctly.
>
> The map contains many areas where this applies, like lakes, large
> areas of landuse, large buildings etc.

Yes, this is true.  I did not think about those areas.

But, how significant are they?  And how often are they being
re-rendered?  If it is worth doing we could extend the current empty
tile mechanism to include those.  This would also save some disk space
on the server.

I believe lakes use the same color as sea.  If that is correct the
client should produce empty sea tiles for them.  This could actually
create a problem when a whole z12 tileset fits inside a lake.  Because
this would create an empty sea tileset which the server throws away.
If that tile then is requested the server would consult oceantiles and
deliver an empty land tile.  Does this happen anywhere?

Matthias

_______________________________________________
Tilesathome mailing list
[email protected]
http://lists.openstreetmap.org/listinfo/tilesathome

Reply via email to