On Fri, Dec 18, 2009 at 10:01, Frederik Ramm <[email protected]> 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. _______________________________________________ dev mailing list [email protected] http://lists.openstreetmap.org/listinfo/dev
