[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