Gert Gremmen schrieb:
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 level12 AND 13 , the area that needs rendering outside the tile could also be reduced. (the way I understand it, is that currently only textsare 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-clientI thought that the whole [EMAIL PROTECTED] was in-client, I do not think it would help modifyinga 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 [EMAIL PROTECTED] use it immediatelyOf 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 listfind/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.
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 bya few of you only, but the lagging between you and the rest of the list is growing, in the endyou will be the only maintaining [EMAIL PROTECTED]
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 [EMAIL PROTECTED] 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
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Tilesathome mailing list [email protected] http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/tilesathome
