OJ W wrote: > something people have suggested here is keeping track of complexity > for each tile (is alredy done I think? reply with details) and then > only give those complex tiles to renderers who claim to have large > amounts of RAM. As others have mentioned, that would solve the delays > caused by some feeble old PC trying to render London on its own while > better more capable machines wait politely until it's given-up.
Yes, this is currently done. Clients will report back a complexity number of the tile (don't know whether it's based on the size of the .osm file) and the server stores that complexity number for each z12 tile. Clients can then advertize a maximum complexity they are willing (and capable) of rendering. > one interesting thing to try here, is maybe each render can simplify > the tile it downloaded, to produce an outline version of the tile data > (nodes every 1km along a way, all small roads removed etc) which could > be used later by a special lowzoom renderer that joins a load of > simplified tiles together to do the intercontinental railway and > autoroute map This is done to a certain extent, in that there is a "captionless" layer that renders z12 tiles geared to producing low zoom tiles. they don't have any captions on it, so that e.g. informationfreeway.org can overlay the englsih captions (or any language they would like). AFAIK, there is currently no simplification of the data performed (which would be beneficial). The problem however is seldom the z12 tile, they tend to render ok, the problem is the higher zoom levels, which are currently fed the full z12 area. It's really a mixture of unhelpful behavior: - osmarender cannot just produce a bounding box restricted svg, all it can do is insert some <boundary> tag (or something like this). It will still produce the full area SVG though. - inkscape will render the full SVG, even if told that only a certain area is supposed to be exported. As e.g. z17 tiles are rendered in stripes, the tiles are rendered in smaller pieces already. Yet, each time inkscape constructs the full SVG for the whole z12 area, which is not needed and not helpful. The only solution I see (as has been suggested), is to either change server/client to be able to request smaller areas (z13 tilesets) or (preferably) to make the client split the .osm files appropriately. (Not a trivial task, as deelkar has elaborated on. He is currently trying to get that going in the tahNG part in SVN. > one area of research I can suggest here is: when one renderer > discovers a large area feature (forest, lake, etc.) they somehow > notify other renderers (e.g. through a database) that someone > rendering tile y (inside the forest) should also download way x which > surrounds y. Or they might mark tile y as being 'forest' in the > database even though they're not currently rendering y because they > happen to have downloaded information about the forest's extents as > part of their tile data Yep, something like this might be helpful. > we currently download a 'border' of extra data around the tile of > interest (maybe 10-20% not sure) which helps with the forests and > placenames but hinders the memory/download/CPU. > In all of this, the key thing to remember is that we want the maps > fast. One more thing that could help is the prioritizing of requests. Right now we have a simple high/mid/low priority queue. By tweaking it so that "interactive" tiles are rendered faster than low priority requests (e.g. by having them skip the uploaded queue, right now each upload is treated the same), we could have those bits appear quicker on the map. spaetz _______________________________________________ Tilesathome mailing list [email protected] http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/tilesathome
