[OSM-dev] renderd in a multi-user multi-style environment

Ævar Arnfjörð Bjarmason avarab at gmail.com
Fri Dec 18 12:14:21 GMT 2009

On Fri, Dec 18, 2009 at 10:01, Frederik Ramm <frederik at remote.org> wrote:
>    for our German dev server, I want to give everyone who has an Unix
> account the opportunity to install as many Mapnik styles as they want,
> and make the rendered tiles available. I don't want everyone to run
> their own renderd though!
> I'm prepared to code the necessary changes to renderd and mod_tile but
> would like to solicit your opinion before I do.
> I think it could be feasible to have an /etc/renderd.d directory where
> you can put as many config snippets as you want, each representing a
> config section of the renderd.conf file, e.g. if you before had the section
> [default]
> max_zoom=18
> URI=/osm/
> XML=/etc/mapnik/osm.xml
> then you would now have a file named /etc/renderd.d/default containing
> max_zoom=18
> URI=/osm/
> XML=/etc/mapnik/osm.xml
> We would then also need some way to make renderd re-read the config dir
> or a Mapnik config file so that the whole thing does not have to be
> restarted every time someone makes a change. The same is probably true
> for mod_tile which also reads the renderd.conf file.
> Also, we currently have one global planet import timestamp file, but in
> a multi-style environment it is possible that some of them have their
> own little database and thus have their own timestamp. We should
> possibly specify the timestamp file in the renderd config so that this
> is catered for.
> Anything stupid or unworkable in this? Better ideas?

Sounds good. We have the same setup on the Wikimedia Toolserver except
there's a preprocessor that writes out one huge .ini so
renderd/mod_tile isn't parsing different files.

What you need to change is stuff like XMLCONFIGS_MAX. We had around
~270 configs so I changed it to ~300 but things like that shouldn't be
allocated on the stack, there's also a few related areas where it'll
malloc() according to some #define in one go instead of doing
malloc()/realloc() as it goes.

More information about the dev mailing list