2009/3/17 Udo Giacomozzi <udo....@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 _______________________________________________ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
