[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: Jeroen van Rijn
Subject: Re: [Maposmatic-dev] A proposal to solve the translation problem
Date: Thu, 5 Apr 2012 07:31:44 +0200

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

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

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. ;)


reply via email to

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