[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Maposmatic-dev] A proposal to solve the translation problem

From: Thomas Petazzoni
Subject: Re: [Maposmatic-dev] A proposal to solve the translation problem
Date: Wed, 4 Apr 2012 00:19:29 +0200

Le Wed, 4 Apr 2012 00:05:52 +0200,
Jeroen van Rijn <address@hidden> 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.


Thomas Petazzoni      
Logiciels Libres à Toulouse
Embedded Linux        

reply via email to

[Prev in Thread] Current Thread [Next in Thread]