[Thuban-list] Started GD based renderer, suggestions

[Bernhard Herzog]

Andreas Rottmann <a.rottmann at gmx.at> writes:

> Hi!
> 
> As part of a (small scale) university term project, I have started
> writing a GD-based renderer for thuban, wich could be quite easily
> used to provide PNG and JPEG export from thuban.
> 
> First of all, I'd like to thank you all for the great work invested so
> far, writing an GD renderer (working already for the iceland example)
> was quite easy after a bit of digging in the code. Really nicely
> written!

Thanks :)

> However, I will use the renderer (and non-UI parts of thuban) from a
> CGI application, so I have some suggestions for making re-use of the
> thuban code easier for other applications.
> 
> 1) Install the Thuban as a regular Python package (i.e. move
>    $libdir/thuban/Thuban to $libdir/python2.X/Thuban. 

I think you mean $libdir/python2.X/site-packages/Thuban.

I'm not sure I actually want to put Thuban in site-packages. Thuban
currently evolves quite rapidly and I expect the interfaces to change a
lot, so applications that use thuban are better off to include a copy
with the application. Putting thuban into site-packages won't work very
well once you have several applications requiring different Thuban
versions.
 
>    This will fix the 'feature' of the current CVS-based installation
>    of the thuban executable only being startable from $libdir/thuban
>    (so that the Thuban package is in the python path, which includes
>    the current dir by default).

Actually, python puts the directory containing the "script", that is the
optional filename argument to the interpreter, into sys.path or the
empty string if no filename was given. E.g. when starting Python as

python /usr/local/lib/thuban/thuban.py

sys.path[0] will be "/usr/local/lib/thuban/"

Furthermore, if the script name is a symlink, the directory will be the
directory containing the file the symlink points to, so you can simply
put a symlink to thuban.py into, say, /usr/local/bin and python will put
the right directory at the front of sys.path if you call that symlink.
This is what "setup.py install" does, actually.


> 2) I quite don't like the fiddling of sys.path to have the Lib
>    directory included. Why not simply explicitly reference Lib, or
>    move its contents to the Thuban package?

The modules in Lib used to be very independend of Thuban, especially at
the beginning. The situatuion has changed a bit since then, and
especially the wxproj obviously is very Thuban specific. The shapelib
bindings are also a bit Thuban specific in that the shapelib version
they use has been slightly modified.

So it might be indeed better to organize them a bit differently. I'm a
bit undecided about this, but wxproj should probably be moved to
Thuban/UI and the shapelib and proj bindings to Thuban/Lib.
 
> 3) Split the Thuban build into the non-UI part, which is quite generic
>    (i.e. doesn't need wxWin/wxPython) and the UI part. This will make
>    it possible, for instance, to build/install a bunch of utilities that
>    convert .thuban files to PNG or whatsoever without having the wx stuff
>    installed for building.

This seems indeed useful.

> I volunteer to write patches to solve the above (perceived) issues

Great!

Patches for 2) and 3) (preferably separate patches for each) should only
affect setup.py, I think.

> case someone is interested, the preliminary GD renderer is attached.

Your GDRenderer class shares a lot of code with MapRenderer which
obviously suggests that it would be good to separate the common
rendering logic from the GD/wxDC specific bits so that they can be
derived from a common base class. 

Patches for that would also be welcome. However, the render is likely to
be changed in some respects when the PostGIS support will be added, so
perhaps this kind of refactoring should wait until after that (I can't
give any time-frame for that currently, though).

   Bernhard

-- 
Intevation GmbH                                 http://intevation.de/
Sketch                                 http://sketch.sourceforge.net/
MapIt!                                           http://www.mapit.de/