Now both to list. Op 08-01-10 14:53, jamesmikedup...@googlemail.com schreef: > On Fri, Jan 8, 2010 at 2:50 PM, Stefan de Konink<ste...@konink.de> wrote: >> Op 08-01-10 14:46, jamesmikedup...@googlemail.com schreef: >>> >>> I have been working on c++ code with rtrees and other nice things. >>> depending on what you want to do with it, I think it is fair to make >>> updates very slow if the rendering is very fast... >> >> Do you mean small files as render tiles? > > something like that. I wonder if we were to store all the osm data for > one tile and its index on a file system and just keep them all in > synch. Anyone who edits the data would update all of them as needed.
You would have to take in to account what data is required for rendering. This is basically what the column wise PostgreSQL Schema tries to achieve. I would find it difficult to believe that with for example a memorymapped file, that allocates for example 4k for a node would outperform a database method. I would see a better future in automatic analysing a stylesheet, determing enums, and using databases. >> This is already what we do on tile.openstreetmap.nl; I have modified renderd >> to render 'metatiles', but not to save them as metatiles. So on disk I have >> all seperate tiles. My webserver, based if the file exists, serves the file, >> or otherwise shoots in a render request like mod_tile would do. > > define metatile? Metatile is basically a tile that spawns a (much) greater space than the invidivual tile, for example 8x8. This reduces mapnik-overhead, since you always have to render a bit bigger than the tile anyway. An additional assumption has been made that it would be faster to store and server metatiles by extracting data, than invidivual tiles. Currently there is no benchmark that can confirm or deny that. >> So the main difference is that I never extract tiles, and never compress >> tiles. We still should plan some sort of benchmark to see if this method is >> better or worse then meta tiles. I think its better because the webserver is >> on less load, and the disk speed or filesystem should be tuned anyway. > > It will depend on your architecture, but I think on a distributed > system where you have many processors, > that lots of files , if connected to the processors will work well. > Ideally you would have a set of processors to deal with a set of data > and any requests would come to them and the whole thing would be in > cache all the time... That would assume a big disk cache. For NL, it would be theoretically possible to use multiple renderd instances out of the box. But that would require to run renderd on an TCP/IP socket, instead of a Unixsocket. In my perspective the query time can be reduced anyway significantly if we want it. Mapnik is much harder to optimise, unless you want to go GPU accelerated rendering. Stefan _______________________________________________ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
