I understand (more or less) the overall [EMAIL PROTECTED] system. > 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).
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 [EMAIL PROTECTED] 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 [EMAIL PROTECTED] 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 [EMAIL PROTECTED] 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 [EMAIL PROTECTED] Or is it just ME, being stupid ??? Gert -----Oorspronkelijk bericht----- Van: Dirk-Lüder Kreie [mailto:[EMAIL PROTECTED] Verzonden: Monday, June 02, 2008 11:49 AM Aan: Gert Gremmen CC: Frederik Ramm; Sebastian Spaeth; [email protected] Onderwerp: Re: [Tilesathome] Proposal: New [EMAIL PROTECTED] Server structure 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 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 [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, 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 [EMAIL > PROTECTED] > 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 [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 _______________________________________________ Tilesathome mailing list [email protected] http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/tilesathome
