Re: [Tilesathome] Potential t@h optimization: Re-use the optimized .png image

[Martin Koppenhoefer]

2008/12/18 Ævar Arnfjörð Bjarmason <ava...@gmail.com>

> On Thu, Dec 18, 2008 at 8:10 PM, Matthias Julius <li...@julius-net.net>
> wrote:
> > "Ævar Arnfjörð Bjarmason" <ava...@gmail.com> 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.
>

but this is just applying as long as there are few items already in the
z12-tile, by the time, when the map is filling up, this optimisation would
not work. As I have understood the problem though, the bottleneck is the
server not being able to receive the tiles in time, not the rendering
process.

Apart from this I see the point: the tiles are "empty" in terms of content,
but have a different colour then emptyland/sea.png, so this is a nice
discovery, that would improve rendering performance for this case.

Martin

_______________________________________________
Tilesathome mailing list
Tilesathome@openstreetmap.org
http://lists.openstreetmap.org/listinfo/tilesathome