Le Wed, 4 Apr 2012 00:05:52 +0200, Jeroen van Rijn <[email protected]> a écrit :
> Maybe I'm missing something, but why would ocitysmap need a translated > paper size, or translated layout name for that matter? > > If that particular machinery were moved to maposmatic, along with the > needed translations, then ocitysmap could be supplied - at run-time - > with the relevant information: > > - relation id / bounding box > - title > - language for index > - paper size in some unit it understands (no need to translate units, I > assume) > - layout name (the hardcoded one from the ocitysmap code that takes > care of the layout) > - pointer to location of stylesheet > - translated name of stylesheet for the footer > > In turn MapOSmatic would have a dictionary of the canonical name of > the layout (given to ocitysmap on the command line) which is > translated for the websites's purpose. > > All of that information might even be passed as a pickle and ocitysmap > invoked with --runjob /var/tmp/maposmatic/job-[id]-pickle > > But I'll admit I might be missing something obvious which requires > these particular translations to be part of ocitysmap :) The layouts are implemented in OcitySMap, the stylesheets are managed by OcitySMap, and the paper sizes are defiend in OcitySMap. MapOSMatic is merely a web client for OcitySMap, all the logic (rendering layouts, Mapnik stylesheets, paper sizes that are suitable for a given rendering) is implemented in OcitySMap. Regards, Thomas -- Thomas Petazzoni http://thomas.enix.org MapOSMatic http://www.maposmatic.org Logiciels Libres à Toulouse http://www.toulibre.org Embedded Linux http://www.free-electrons.com
