[OSM-dev] Improvement of tile rendering

[Dave Stubbs]

2009/3/17 Udo Giacomozzi <udo.osm at nova-sys.net>:
> I just set up my own Mapnik server that renders map tiles on demand
> and saves them on disk so that they are efficiently cached. Currently
> this is done using a PHP script (FastCGI handler with 5 instances)
> that handles 404 errors and invokes a python script to render the
> tile which then gets stored at the location that caused the 404 error.
> Invoking python from PHP is suboptimal, I know, but I'm no Python
> programmer, PHP lacks Mapnik support and so far this was only a proof
> of concept.
>
> Anyway..
>
> I noticed that to generate a tile, a 512x512 pixel map is generated,
> which gets then cropped to 256x256 pixels and reduced to 255 colors by
> using  'convert'.
>
> I don't know if the mod_tile daemon does it the same way, but I guess
> it does.
>

It doesn't.

It renders meta tiles -- that's 8x8 normal tiles. This reduces the
border overlap overhead.


> I guess the cropping is done to fix some text labelling issues (to
> keep text readable across tiles), but in practice this does not work
> well since I see lots of text cropped in Slippy Map.
>
> Also, invoking the "convert" tool without doubt takes massive
> resources compared to in-place color reduction.
>
> Have any efforts been taken to use libmagick directly or avoid
> external tools at least?
>

And it uses mapnik's png256 output which does the colour reduction itself.
The cycle map doesn't use any colour reduction.

> And, is it really impossible to avoid cropping at all? Can't Mapnik be
> instructed (or extended) to render labels always at the same place, no
> matter the viewport?

The problem is label collisions. Labels cause other labels to move or
not be displayed. When you add/remove data you change the flow. Tile
overlaps help quite a lot but there are issues still.
It could easily render everything in the same place, but that wouldn't
lead to a very nice map.

Dave