[Tilesathome] Proposal: New T at H Server structure

Dirk-Lüder Kreie osm-list at deelkar.net
Mon Jun 2 10:48:40 BST 2008


Gert Gremmen schrieb:
> One of the main services of T at H, namely being a means
> of quick response to map modifications is being lost
> just for those tiles that are a little bit more complex then
> the average. 
> As long as tiles are being returned to the server (by low resource
> clients)
> for complexity reasons, after 1-2 hours of fruitless processing and
> a client crash, there is still work to do.
> Currently the NL tileserver running Mapnik, often
> provides a quicker update (max 48h) as T at H for NL tiles.

Mapnik is orders of magnitude better than t at h, provided the pgsql db of 
mapnik can be kept up-to date. t at h is slow because it takes many steps 
to get from osm to png, and because it renders every single tile 
beforehand (as opposed to on demand).

> I have requested several times for modification of the T at H starting
> point to level 13. The render jobs will be smaller, allowing
> more clients to participate successfully. 

 From my tests this is not enough, z14 is the proper level to start, but 
there are ways to do this in-client.

> In my opinion it is very frustrating that in the morning the 
> t at h process was stopped due to too many heap sections or a
> inkscape memory problem. Spill of energy, effort and
> computer time.

Show me a better svg->png processor and I'll make t at h use it immediately.

> Level 13 will allow most t at h clients to run complex tiles much faster,
> creating a fast turnaround time. Stitching four captionless
> tiles 13 will create a level 12 tile.
> The downside is that for a given area 4x more requests are needed,
> but each upload will contain 4 x less tiles.
> 
> Is this a too big change of strategy ?
> Will the level 12 results be too bad of quality ? 
> Does the t at H community think this is not relevant (yet) ? 
> Is there any major reason that I overlooked ?

The issue is a bit more complicated than that.

> Will inkscape be replaced soon, making this unnecessary (like ORP)?

There is batik. It has it's own issues, but it is an alternative to 
clients with less than a couple GB of RAM
Just to clarify: or/p replaced the XSLT implementation of osmarender, it 
has nothing to do with the svg->png step.

-- 

Dirk-Lüder "Deelkar" Kreie
Bremen - 53.0952°N 8.8652°E


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 260 bytes
Desc: OpenPGP digital signature
URL: <http://lists.openstreetmap.org/pipermail/tilesathome/attachments/20080602/d6202428/attachment.pgp>


More information about the Tilesathome mailing list