[OSM-talk-nl] [Tilesathome] Proposal: New T at H Server structure

[Martijn van Oosterhout]

On Tue, Jun 3, 2008 at 9:02 PM, Gert Gremmen <Administrator at ce-test.info> wrote:
> But someone needs to close the gap
> between us.
> I want to suggest to divert a bit from creating
> T at H code to updating the community by mail
> and wiki.

To be honest, I think you're overestimating the complexity of the
code. But anyway, your questions (which I had to lookup the answer to
since I didn't know myself).

> I recognize 6 stages
>
> Downloading a OSM file  (becomes an encoded tilename.osm file)

Is done in GenerateTileset, looks like it's called data-$PID-$i.osm,
$i is just a counter

You forgot the preprocessing stage which keeps the filename but adds
the name of the filter each time (same function).

> Conversion to SVG, apparently needed for inkscape ? creates a SVG file
> for every zoom level

In GenerateSVG, files are called output-$parent_pid-z$Zoom.svg
Driven from GenerateTileset which calls it multiple times for the strips

> Conversion to png  creates a lot of tiles in a suitable directory
> (tilenumber?)

RenderTile is a recursive function that does each level in turn, the
svg2png function does the actual rendering.
The strips have random filenames generated by tempfile().
The splitting and optimising is done in splitImageX. (search for PngOptimizer)

> Compression stage  (any of the available zip programs results in a zip
> file in the upload dir)

In compress.pl, triggered by compressAndUpload in the tilesGen.

> And an upload stage  (renames the compressed file to uploaded)

In upload.pl, triggerred by the same.

> There must also be a housekeeping task, cleaning it all.

tilesGen is supposeed to cleanup after itself (wipes the working
directory), the others just delete the ZIPs when uploaded.

Hope this helps,
-- 
Martijn van Oosterhout <kleptog at gmail.com> http://svana.org/kleptog/