Dirk-Lüder Kreie wrote: >> Another saving could be achieved by implementing change detection and >> rendering requests at the z13 level rather than z12. A [EMAIL PROTECTED] >> client would >> then render one z13-z17 tileset and one z12-only tileset. Unchanged z13 >> tilesets would not get needlessly re-rendered. > > I'm in favor of keeping the current infrastructure, but modifying the > client so that it extracts areas from the osm file to be rendered, i.e. > split the OSM data instead of the svg
Agreed, I would like to keep the z12-z17 tileset construct and rather modify our clients to cope better. Taking an render area at z12, render that, split the area in 4 (partially overlapping) subareas and recursively render those at the next zoom level could help us there. Right now Inkscape has to load and parse the full SVG file, even if it only renders a narrow stripe of it. By actually subdividing our osm files, the SVG files would be significantly smaller at each zoom level and save some time. spaetz _______________________________________________ Tilesathome mailing list [email protected] http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/tilesathome
