[Tilesathome] Proposal: New T at H Server structure

[Dirk-Lüder Kreie]

Gert Gremmen schrieb:
> 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 ?)

No, we do use some of the extra area as well for areas, but we're not as 
dependent on it. We do need, however, z12 for coastline. The index 
doesn't scale from z12 to z13 automatically. (for example)

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

A client can take the osm file, split it into smaller parts, suitable 
for z13 rendering (or even higher zoom) and stitch everything back 
together. Only it would have to keep area features and labels intact. 
(ie. copy to each part-file)

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

I believe this just moves the problem, you are, however, free to invest 
*your* time to code something that shows us otherwise.

Yes I agree the cities of the Netherlands would make a good testbed, 
because they are amongst the most densely mapped areas we have in OSM.

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

The thing is, while I have seen a whole lot of reports about things 
going wrong I have yet to see code (IIRC). So I will not go about 
thinking about where we might have hardcoded dependencies on a z12 base.

A short, definitively incomplete list includes:

Informationfreeway tile requests
The Land/sea/coast index (oceantiles_12.dat) and related tools
the empty land/sea tiles server database.
the server tile metadata.
Documentation on the wiki and elsewhere

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

There are only a few maintaining the client, but it's a pure meritocracy.

Secondly: don't assume the developers are dumb for doing things like 
they are done. There is almost always a real good reason behind it.

If there isn't there's probably work being done to fix it (albeit slowly).

Yes, some of the code in t at h is not *that* readable, but we've had perl 
beginners send good patches against it, so it can't be that bad.

-- 

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/4867fa30/attachment.pgp>