[OSM-dev] PNG type for Mapnik map

[Jon Burgess]

On Wed, 2007-12-19 at 12:49 +0000, Tom Hughes wrote:
> In message <476910A2.6020706 at arjam.net>
>         Robert Munro <rjmunro at arjam.net> wrote:
> 
> > Jochen Topf wrote:
> >
> >> http://svn.openstreetmap.org/applications/rendering/mapnik/generate_tiles.py
> >> uses a call to the external 'convert' program to reduce the number of colors
> >> for tiles rendered by Mapnik to 255. Since version r571 Mapnik supports
> >> writing to 8 bit palette PNGs. Palette PNGs are generally smaller than
> >> normal PNGs.
> >> 
> >> Is there any reason NOT to change the code to use Mapniks function to
> >> write out the image directly as 8bit paletted PNG, make the images
> >> smaller and save the call to 'convert'? (If nobody comes up with a
> >> reason, I'll change the code.)
> >
> > AFAIK, the main reason the feature was added to mapnik was that /we/
> > needed it because the external convert was really slow (about the same
> > amount of time as the whole rest of the render).
> 
> The generate_tiles.py script is only an example - whilst changing it
> is probably a good idea I don't think it will have an affect on
> anything very much.

Artem mentioned that the colour reduction technique is still fairly
experimental. It would be great for people to try it in order to iron
out any kinks before we adopt it on the main site.

> > So no, there is no reason not to change the code. Please do & make
> > mapnik run at twice the speed. Also, if you can make mapnik render
> > on-demand first, and only render the backlog when it's not busy, that
> > would probably be a great improvement.
> 
> I think you're confusing mapnik the rendering library with the set of
> tools used to render mapnik tiles for openstreetmap, most of which are
> not in the repository as far as I know.

Practically everything should be in:
http://trac.openstreetmap.org/browser/sites/tile.openstreetmap.org

There are sometimes some trivial differences between these scripts and
the ones on the live server. I'm slowly adding a few more helper scripts
over time.

> In particular any work along the lines you suggest would be best
> directed at completing mod_tile rather than improving the current
> ruby/python based code.
> 
> Note however that mod_tile already does most of the things you have
> just suggested ;-)

yes, mod_tile will favour rendering live tiles even if there is a
backlog. 

   Jon