[Tilesathome] Proposal: New T at H Server structure

[Gert Gremmen]

I understand (more or less) the overall T at H system.

> 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).

Right !

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

Starting at level Z13 will immediately help. 
If , in addition we provide a captionless layer on level
12 AND 13 , the area that needs rendering outside the tile
could also be reduced. (the way  I understand it, is that currently only texts
are needing this extra area, large (extra-tile) surfaces like water and wood are 
processed differently ?)



>thera are ways of doing this in-client

I thought that the whole T at H was in-client,
I do not think it would help modifying
a client on my own. 


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

Of course, my remark was meant just to show the frustration;
while expecting a level Z13 rendering would stop that.

> The issue is a bit more complicated than that.

Well, stating just that won't help the list
find/suggest a solution. 
Or do you really mean: too complex to explain to me ?
Well I am definitely no T at H or perl specialist,
but there are  more like me, who would like
to step in helping, but cannot currently.
Share the problems, we'll share the solution.

We all appreciate the good work, done by
a few of you only, but the lagging between you 
and the rest of the list is growing, in the end
you will be the only maintaining T at H....

Or is it just ME, being stupid ???


Gert



-----Oorspronkelijk bericht-----
Van: Dirk-Lüder Kreie [mailto:osm-list at deelkar.net] 
Verzonden: Monday, June 02, 2008 11:49 AM
Aan: Gert Gremmen
CC: Frederik Ramm; Sebastian Spaeth; tilesathome at openstreetmap.org
Onderwerp: Re: [Tilesathome] Proposal: New T at H Server structure

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