[OSM-dev] Tirex vs Renderd

Jon Burgess jburgess777 at googlemail.com
Sat Apr 17 12:49:00 BST 2010


On Sat, 2010-04-17 at 12:09 +0100, Kai Krueger wrote:
> On 04/17/2010 11:29 AM, Frederik Ramm wrote:
> > Kai,
> >
> > Kai Krueger wrote:
> >> This is less of a question though regarding using renderd vs tirex but
> >> more of a question of where the future lies and thus for which to
> >> develop new features. It would be a shame and rather inefficient to
> >> put in effort to develop features for something that turns out to be a
> >> dead end
> >
> > What particular feature did you want to work on?
> 
> It was somewhat intended as a more general question than a specific 
> feature, but what sparked the question was the potential need to extend 
> the rendering to support a lot of styles (200+) as is currently being 
> discussed on the wikimedia maps list. At 
> http://cassini.toolserver.org/tile-browse/ there are renderings for all 
> the 278 languages wikipedia supports. With renderd each of the rendering 
> threads has a copy of all the mapnik styles. As each style takes up 
> about 5 - 6 Mb, this results in 278*8*5.5 = 12Gb of ram. Not directly 
> desirable. So thoughts exist to implement some form of on demand loading 
> and unloading of styles, as it is unlikely that all those styles will be 
> needed all the time and/or share memory accross rendering 
> threads/processes. So the question somewhat was where to do this 
> potential development. But as it is only thoughts at the moment it will 
> probably depend on who ever gets to actually implementing this. Hence my 
> more general question of which of the two seems more "recomended/future 
> proof" for potential developments like that.

One thing to consider is whether the best place to focus the effort
might be to reduce the memory usage by Mapnik. This then benefits both
projects. I believe you are the first person to measure and highlight
this memory usage. I would recommend you raise a ticket at
trac.mapnik.org (if you have not already). For many uses 5MB per style
is perfectly reasonable but not in your situation. Like many things
there is a trade off between the time to reload the style vs the memory
usage to pre-load everything. 

The most recent Mapnik code has moved to a new parser and is now
supporting more flexible style rules. It might be possible that Mapnik
would one day be able to render all your language variants using just a
single style with some extra run-time parametrisation. It might also be
possible to split the rendering so that language independent features
could be rendered once and then the language specific layers rendered on
top.

	Jon






More information about the dev mailing list