[OSM-dev] .bpg tiles

[Paul Norman]

On 3/17/2015 4:21 AM, andrzej zaborowski wrote:
> Its lossy compression mode
> seems to work well for OSM tiles because the artifacts are of a
> different type than in JPEG.
It's interesting to note the differences in compression artifacts, and 
somewhat
surprising to someone who spends a lot of a day seeing JPEG artifacts.

> Here are some results for a small test
> area for different compression ratios (percentages of size saved
> against PNG).
A good comparison might be WebP, both as lossy and lossless. Lossless WebP
is reported to be about 45% smaller than unoptimized PNG and 20% smaller
than optimized PNG with some datasets, but I'm not aware of any tests with
map tiles.

> Unfortunately the stock encoder is slow when compared to PNG.  I'm not
> sure if it makes sense to use for tiles rendered on-demand because the
> compression time adds to the rendering time.
This is probably a big issue. Yes, CPU is cheaper than IOPS, but PNG is 
already
considered slow to encode.

> It would work well for static or low-zoom tiles though.
The traditional logic has been to use uncompressed for map tiles, and 
compressed
for tiles with imagery or hillshading. This has been based on JPEG and 
PNG and may
not apply to BPG or WebP. Particularly with WebP where you can have 
compressed
on some zooms and uncompressed on others.
> I imagine compression would also be
> improved with bigger tiles but I'm not sure if 8x8 metatiles at
> 512x512 pixels is not too heavy for a tileserver -- is anyone
> generating such tiles with mod_tile?
If you were using larger tiles of the same resolution you'd probably 
keep the metatile
size at the same number of pixels, so the database queries would be the 
same and the
metatile storage would be the same, but the only difference would be 
slicing up the metas
into individual tiles.

There has been some work done with large tiles, for disk storage reasons 
(http://blog.geofabrik.de/en/?p=268).

Overall tile formats have been under-researched, and it's good to see 
more explorations with different formats.