Gert Gremmen schrieb:
One of the main services of [EMAIL PROTECTED], namely being a means of quick response to map modifications is being lost just for those tiles that are a little bit more complex thenthe average. As long as tiles are being returned to the server (by low resourceclients) 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 [EMAIL PROTECTED] for NL tiles.
Mapnik is orders of magnitude better than [EMAIL PROTECTED], provided the pgsql db of mapnik can be kept up-to date. [EMAIL PROTECTED] 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 [EMAIL PROTECTED] starting point to level 13. The render jobs will be smaller, allowingmore 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 [EMAIL PROTECTED] process was stopped due to too many heap sections or ainkscape memory problem. Spill of energy, effort and computer time.
Show me a better svg->png processor and I'll make [EMAIL PROTECTED] use it immediately.
Level 13 will allow most [EMAIL PROTECTED] 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 [EMAIL PROTECTED] 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
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Tilesathome mailing list [email protected] http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/tilesathome
