[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: David Decotigny
Subject: Re: [Maposmatic-dev] A proposal to solve the translation problem
Date: Thu, 05 Apr 2012 10:13:33 -0700
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv: Gecko/20120313 Thunderbird/3.1.20

Hash: SHA1

Hi all,

(Catching up). Do people deploy ocitysmap/maposmatic with their
private/own stylesheet? Or do they use what we are providing in
ocitysmap? If we assume that stylesheets are nicely integrated with
ocitysmap and that most people will be happy with them, I believe we
should 1/ ship them all with ocitysmap, 2/ go away from using
configuration files to declare them and register them in a more pythonic

For example, if we assume we ship them all in ocitysmap2/stylesheet,
then IMHO it's enough to add a file in the stylesheet
subdirs (eg. maposmatic-printable/) with something like:

   import os
   import ocitysmap2

   class MaposmaticPrintableStyleSheet(ocitysmap2.Stylesheet):
     def __init__(self):
        ocitysmap2.Stylesheet.__init__(self) = _('maposmatic printable stulesheet')
        self.path = os.path.join(os.path.dirname(__file__), 'osm.xml')
        self.description = _('blah')

And then, in ocitysmap2/stylesheet/

   import ocitysmap2
   import ocitysmap2.stylesheet.maposmatic_printable as MP
   import ocitysmap2.stylesheet.pierre_orange as PO

   # default stylesheet comes first

And people who want to have their own stylesheet can easily add the glue
code in ocitysmap2/stylesheet. They also can send us the patch so that
we integrate them.

Of course, it means we should add the default stylesheet there (and
rename the dirs with underscores instead of hyphens).


On 04/04/2012 10:31 PM, Jeroen van Rijn wrote:
> To bring another possibility to the table... we have a few givens:
> - Currently MapOSMatic depends on OcitySMap and it will likely be a
> hard dependency for the time being, in that there's no alternative
> backend for it to use (which may not always be the case in that
> someone might want to extend it to use an additional optional backend,
> not me, btw).
> - OcitySMap doesn't require MapOSMatic as of yet and can be run separately.
> - To run and offer translations, both need to have knowledge of
> stylesheets, layouts and paper sizes.
> So far, so good. Essentially this means that the two pieces of
> software have a shared dependendy: the stylesheets, layouts and paper
> sizes.
> Instead of refactoring things in a way that will possibly make
> OcitySMap depend on MapOSMatic, I'm wondering if it can't be built
> into a module shared between the two. It would live within the
> OcitySMap repository and might even consume its configuration file,
> but it would be its own module, possibly even installed into
> /usr/lib/python2.7/dist-packages as part of OcitySMap's installation
> process.
> Also, rather than have explicit assumptions about locations of
> stylesheets and configurations in that hypothetical module, this might
> be passed to it on instantiating it.
> import replace_with_suitable_name as stylefactory
> styles = stylefactory(/location/to/ocitysmap/config)
> Or something... am just spitballing a bit here. ;)

- --
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla -


reply via email to

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