Subject: [Thuban-list] Started GD based renderer, suggestions

From: Andreas Rottmann <[email-masked]>
Date: Tue, 29 Apr 2003 21:29:50 +0200

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!

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. 

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

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?

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.

I volunteer to write patches to solve the above (perceived) issues, in
the order presented above, if I get positive input and a go ahead. In
case someone is interested, the preliminary GD renderer is attached.

Cheers, Andy
-- 
Andreas Rottmann         | Rotty@ICQ      | 118634484@ICQ | [email-masked]
http://www.8ung.at/rotty | GnuPG Key: http://www.8ung.at/rotty/gpg.asc
Fingerprint              | DFB4 4EB4 78A4 5EEE 6219  F228 F92F CFC5 01FD 5B62

Make free software, not war!

---

From: Bernhard Herzog <[email-masked]>
Date: 02 May 2003 20:55:47 +0200

> was quite easy after a bit of digging in the code. Really nicely

Thanks :)

>    $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.
 
>    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.

>    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.
 
>    convert .thuban files to PNG or whatsoever without having the wx stuff

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/

---

From: Andreas Rottmann <[email-masked]>
Date: Sun, 04 May 2003 19:09:47 +0200

> I think you mean $libdir/python2.X/site-packages/Thuban.
Yes, that's what I meant.

> with the application. 
Yes, you're quite right here, but there are no applications using
Thuban yet, and I guess it would be reasonably to expect applications
that want to build on it by now (such as my CGI stuff) to follow API
changes across releases.

> Putting thuban into site-packages won't work very
Sure, but I hope that doesn't really happen (see above).

> This is what "setup.py install" does, actually.
Well, that doesn't work for me (I use GNU stow):

andy@alice:~% ls -l /usr/local/bin/thuban
lrwxrwxrwx    1 root     staff          25 Apr 28 13:54 /usr/local/bin/thuban -> ../stow/thuban/bin/thuban
andy@alice:~% ls -l /usr/local/stow/thuban/bin/thuban
lrwxrwxrwx    1 root     staff          43 Apr 28 13:54 /usr/local/stow/thuban/bin/thuban -> /usr/local/stow/thuban/lib/thuban/thuban.py
andy@alice:~% /usr/local/bin/thuban
Traceback (most recent call last):
  File "/usr/local/bin/thuban", line 12, in ?
    import Thuban
ImportError: No module named Thuban

Invoking /usr/local/stow/thuban/bin/thuban directly works, though. It
seems Python is not clever enough to follow more than one symlink.

> they use has been slightly modified.
I already heard that about shapelib... Wouldn't it be good to push
these changes upstream and use an out-of-the-box shapelib?

> Thuban/UI and the shapelib and proj bindings to Thuban/Lib.
So the GDRenderer would also go under Lib/?

> affect setup.py, I think.
Well, I don't know what the proper solution for (2) is, but I'd
suggest to dump that sys.path magic and use Lib explicitly.

> derived from a common base class. 
Indeed, I already tought about that too.

> give any time-frame for that currently, though).
OK.

Regards, Andy

Packages should build-depend on what they should build-depend.

---

From: Andreas Rottmann <[email-masked]>
Date: Wed, 07 May 2003 10:25:31 +0200

> well once you have several applications requiring different Thuban
You already have --create-init-module, so I don't see what the problem
with moving all of Thuban into a standard directory...

Regards, Andy

It's GNU/Linux dammit!