From nelson at crynwr.com Fri Apr 1 06:38:04 2005 From: nelson at crynwr.com (Russell Nelson) Date: Thu, 31 Mar 2005 23:38:04 -0500 Subject: Thuban more modular? In-Reply-To: <1112277804.14081.120.camel@localhost.localdomain> References: <1112277804.14081.120.camel@localhost.localdomain> Message-ID: <16972.53292.402901.912850@desk.crynwr.com> Jonathan Coles writes: > what are people's thoughts on moving some of what is now > core-functionality into Extensions? I think this is a good idea. Here's how I would implement it: Separable Thuban functions get split out into their own Extension module. This module would export a set of standard functions that let Thuban know what menu entries to add, and it would also make functionality available to other Extensions. The module is executable, and if run stand-alone (outside of Thuban), takes parameters on its command line, or (perhaps) prompts for them. So, people can use Thuban Extensions three ways: o From inside Thuban. o From the command line. o Inside a Python program of their own authoring. So, for example, there would be a "postscript" module. It would allow a Thuban UI user to save the current map as postscript. It would also allow you to run it from the command line as "postscript.py foobar.session foobar.ps". Or a Python coder could: #!/usr/bin/python from Thuban.Model.session import Session from Thuban.Lib.postscript import Postscript # this isn't correct, but it's just an example. session = Session.read_session("foobar.session") Postscript.write(session, "foobar.ps") -- --My blog is at blog.russnelson.com | The laws of physics cannot Crynwr sells support for free software | PGPok | be legislated. Neither can 521 Pleasant Valley Rd. | +1 315-323-1241 cell | the laws of countries. Potsdam, NY 13676-3213 | +1 212-202-2318 VOIP | From Chris.Barker at noaa.gov Fri Apr 1 08:15:27 2005 From: Chris.Barker at noaa.gov (Chris Barker) Date: Thu, 31 Mar 2005 22:15:27 -0800 Subject: Thuban more modular? In-Reply-To: <1112277804.14081.120.camel@localhost.localdomain> References: <1112277804.14081.120.camel@localhost.localdomain> Message-ID: <424CE6FF.9080508@noaa.gov> Jonathan Coles wrote: >why not make even our standard options behave as extensions for >consistency? > > >in general, thuban should provide a very basic framework onto which all >the real functionality is added. the concept of a layer is part of that >framework, but specific implementations of that concept are extensions, >no? > > Yes! I love this idea. From my first look at Thuban, I was hoping to find a toolbox with which to build a mapping application, rather than a particular mapping application. What it is now is that latter, I'd love to see it become more like the former. -Chris From bernhard at intevation.de Sat Apr 2 16:22:55 2005 From: bernhard at intevation.de (Bernhard Reiter) Date: Sat, 2 Apr 2005 16:22:55 +0200 Subject: Thuban more modular? In-Reply-To: <1112277804.14081.120.camel@localhost.localdomain> References: <1112277804.14081.120.camel@localhost.localdomain> Message-ID: <20050402142255.GH8823@intevation.de> Am 31. Mar 2005 um 09:03:24 schrieb Jonathan Coles: > what are people's thoughts on moving some of what is now > core-functionality into Extensions? > in general, thuban should provide a very basic framework onto which all > the real functionality is added. the concept of a layer is part of that > framework, but specific implementations of that concept are extensions, > no? I have seen this approach to modularisation raised as idea quite a few times, but often the implementation did not really lived up to the expectations. One reason is that it add more bureaucracy to the developers, like the checks which components are here yet. In this way it also prevent to make one interface great for the users, because optimising a huge number of possible component combinations puts more burden on the interface design side. Our progress with Thuban currently is slow and we do have competition. So my tendency is to not put more into Extensions, because it is more work. Instead we should extent functionality and speed to get it to enlarge the number of users. Just my 0.02 Euro Cent. Bernhard -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://www.intevation.de/pipermail/thuban-devel/attachments/20050402/3b9d076c/attachment.bin From bh at intevation.de Mon Apr 4 12:45:33 2005 From: bh at intevation.de (Bernhard Herzog) Date: Mon, 04 Apr 2005 12:45:33 +0200 Subject: Thuban and wxPython 2.5 Message-ID: Hi all, Last week, I've tried to build Thuban with wxPython 2.5. Most ofthe time I spent on that went into building wxPython from CVS (the build process has changed quite a but sice 2.4). However, there is also a problem with Thuban's current approach to wxPython 2.5. The file wxPython_int.h has changed in incompatible ways in the CVS version of wxPython leading to exceptions. The wxPyCoreAPI struct has some new members which were added at the top of the structure so that the code compiled with Thuban's copy of wxPython_int.h will call the wrong functions. That this only lead to exceptions is pure chance, it could easily have been a segfault. The only real solution IMO is to use wxPython.h as intended by wxPython and ditch our own copy. Of course, since at least on some platforms the wxPython specific header files are not packaged we need to lobby them to add them. IMO failing to package the files is simply a bug, and shouldn's be hard to do, so ideally filing bug reports and might suffice. Bernhard -- Intevation GmbH http://intevation.de/ Skencil http://skencil.org/ Thuban http://thuban.intevation.org/ From bh at intevation.de Mon Apr 4 17:37:36 2005 From: bh at intevation.de (Bernhard Herzog) Date: Mon, 04 Apr 2005 17:37:36 +0200 Subject: Vector opacity (Re: Raster layer opacity) In-Reply-To: <20050329101524.GI22363@intevation.de> (Bernhard Reiter's message of "Tue, 29 Mar 2005 12:15:24 +0200") References: <1111592504.14081.14.camel@localhost.localdomain> <20050329101524.GI22363@intevation.de> Message-ID: Bernhard Reiter writes: > I also think that vectors can have opacity, the question is if this > will be per vector layer or per drawing style per class. Both would be useful. > And it we have that drawing style option, do we want another layer > wide option? Yes. > Both seems to be nice features with the per style opacity being more > general, but the per layer one might be consistant and easier to add. You can use them simultaneously. See for instance how opacity of groups is handled in SVG. http://www.w3.org/TR/SVG11/masking.html#ObjectAndGroupOpacityProperties Bernhard -- Intevation GmbH http://intevation.de/ Skencil http://skencil.org/ Thuban http://thuban.intevation.org/ From bh at intevation.de Mon Apr 4 18:10:55 2005 From: bh at intevation.de (Bernhard Herzog) Date: Mon, 04 Apr 2005 18:10:55 +0200 Subject: Thuban more modular? In-Reply-To: <20050402142255.GH8823@intevation.de> (Bernhard Reiter's message of "Sat, 2 Apr 2005 16:22:55 +0200") References: <1112277804.14081.120.camel@localhost.localdomain> <20050402142255.GH8823@intevation.de> Message-ID: Bernhard Reiter writes: > Am 31. Mar 2005 um 09:03:24 schrieb Jonathan Coles: >> what are people's thoughts on moving some of what is now >> core-functionality into Extensions? > >> in general, thuban should provide a very basic framework onto which all >> the real functionality is added. the concept of a layer is part of that >> framework, but specific implementations of that concept are extensions, >> no? Have you been reading "On Plug-ins and Extensible Architectures" :-) ? http://www.acmqueue.org/modules.php?name=Content&pa=showpage&pid=286 > I have seen this approach to modularisation raised as idea quite a few times, > but often the implementation did not really lived up to the expectations. > One reason is that it add more bureaucracy to the developers, > like the checks which components are here yet. > In this way it also prevent to make one interface great for the users, > because optimising a huge number of possible component combinations > puts more burden on the interface design side. Some of this is addressed in the article cited above: Extensible application architectures such as Eclipse offer many advantages, but one must be careful to avoid "plug-in hell." > Our progress with Thuban currently is slow and we do have competition. > So my tendency is to not put more into Extensions, because it is more work. > Instead we should extent functionality and speed to get it to > enlarge the number of users. OTOH, we do have Extensions and a stated goal of Thuban. Extensibility is mentioned on the Thuban home page and on the concept page it says: We think that extending Thuban via Add-ons is a good alternative to directly adding features to Thuban. It allows you to add some specific elements you need for your work. It even is possible to create your own custom applications with all the features of Thuban without the need of forking the development and maintaining your own branch of Thuban. While this is true in principle -- GREAT-ER is a good example for this -- the extensibility is relatively limited. Some things that you might want to do are not yet easily possible, like adding a new source of shapes as the ogr extension has shown. Increasing the modularity and extensibility of Thuban doesn't mean that we have to go and implement a generic plugin infrastructure like Eclipse (see thr article mentioned above) instead improving Thuban in a more direct fashion. We can and should continue the process we started with GREAT-ER, that is, add extensibility when and where it is needed. That won't take many resources. In most cases it should more or less come about as a side-effect of the refactoring needed anyway when adding a new feature. However, and this is an area where Thuban could improve IMO, the infrastructure we are building with this process should also be used by the standard components of Thuban. That will help to ensure that the way plugins interact with Thuban is generic enough and not geared too much toward one particular implementation. It will also improve the architecture of Thuban by reducing the coupling between the components and increasing the modularity. Bernhard -- Intevation GmbH http://intevation.de/ Skencil http://skencil.org/ Thuban http://thuban.intevation.org/ From jan at intevation.de Tue Apr 5 07:30:57 2005 From: jan at intevation.de (Jan-Oliver Wagner) Date: Tue, 5 Apr 2005 07:30:57 +0200 Subject: Thuban more modular? In-Reply-To: References: <1112277804.14081.120.camel@localhost.localdomain> <20050402142255.GH8823@intevation.de> Message-ID: <20050405053057.GA18451@intevation.de> On Mon, Apr 04, 2005 at 06:10:55PM +0200, Bernhard Herzog wrote: > While this is true in principle -- GREAT-ER is a good example for this > -- the extensibility is relatively limited. Some things that you might > want to do are not yet easily possible, like adding a new source of > shapes as the ogr extension has shown. ah well, I am working this one - though at a slow pace. > However, and this is an area where Thuban could improve IMO, the > infrastructure we are building with this process should also be used by > the standard components of Thuban. That will help to ensure that the > way plugins interact with Thuban is generic enough and not geared too > much toward one particular implementation. It will also improve the > architecture of Thuban by reducing the coupling between the components > and increasing the modularity. So, are you proposing to go for a raster plugin (provided Jonathan likes to do the work)? Jan -- Jan-Oliver Wagner http://intevation.de/~jan/ Intevation GmbH http://intevation.de/ FreeGIS http://freegis.org/ From jan at intevation.de Tue Apr 5 07:37:08 2005 From: jan at intevation.de (Jan-Oliver Wagner) Date: Tue, 5 Apr 2005 07:37:08 +0200 Subject: Thuban and wxPython 2.5 In-Reply-To: References: Message-ID: <20050405053708.GB18451@intevation.de> On Mon, Apr 04, 2005 at 12:45:33PM +0200, Bernhard Herzog wrote: > The file wxPython_int.h has changed in incompatible ways in the CVS > version of wxPython leading to exceptions. The wxPyCoreAPI struct has > some new members which were added at the top of the structure so that > the code compiled with Thuban's copy of wxPython_int.h will call the > wrong functions. That this only lead to exceptions is pure chance, it > could easily have been a segfault. The only real solution IMO is to use > wxPython.h as intended by wxPython and ditch our own copy. > > Of course, since at least on some platforms the wxPython specific header > files are not packaged we need to lobby them to add them. IMO failing > to package the files is simply a bug, and shouldn's be hard to do, so > ideally filing bug reports and might suffice. sounds like the correct idea. So, lets ditch it. Jan -- Jan-Oliver Wagner http://intevation.de/~jan/ Intevation GmbH http://intevation.de/ FreeGIS http://freegis.org/ From cvs at intevation.de Tue Apr 5 19:27:00 2005 From: cvs at intevation.de (cvs@intevation.de) Date: Tue, 5 Apr 2005 19:27:00 +0200 (CEST) Subject: bh: thuban/libraries/thuban wxproj.cpp, 1.5, 1.6 swigPtrConvertHack.h, 1.1, 1.2 Message-ID: <20050405172700.7C52F1005B4@lists.intevation.de> Author: bh Update of /thubanrepository/thuban/libraries/thuban In directory doto:/tmp/cvs-serv24411/libraries/thuban Modified Files: wxproj.cpp swigPtrConvertHack.h Log Message: Use wxPython.h by default but provide a workaround when it isn't available. * setup.py (wxproj_extension): New variable. Assign the Extension instance for Lib.wxproj to this variable instead of putting it directly into the listso that it can be accessed by other code later. (thuban_build_ext.user_options): Added boolean option --use-wx-python-swig-hack. (thuban_build_ext.initialize_options): Initialize the new option to False. (thuban_build_ext.finalize_options): If the new option was given, define the preprocesser macro USE_WX_PYTHON_SWIG_HACK. (thuban_build_ext): Update the doc-string * libraries/thuban/wxproj.cpp: Normally we use wx/wxPython/wxPython.h now. Only if USE_WX_PYTHON_SWIG_HACK is defined, use swigPtrConvertHack.h instead. * libraries/thuban/swigPtrConvertHack.h: Remove the code that was copied over from wxPython.h. (decode_pointer_new): New. Equivalent of decode_pointer for wxPython 2.5. (wxPyConvertSwigPtr): Modified to cope with wxPython 2.5 as well. Index: wxproj.cpp =================================================================== RCS file: /thubanrepository/thuban/libraries/thuban/wxproj.cpp,v retrieving revision 1.5 retrieving revision 1.6 diff -u -d -r1.5 -r1.6 --- wxproj.cpp 16 Feb 2005 21:14:47 -0000 1.5 +++ wxproj.cpp 5 Apr 2005 17:26:58 -0000 1.6 @@ -1,4 +1,4 @@ -/* Copyright (c) 2001, 2002, 2003, 2004 by Intevation GmbH +/* Copyright (c) 2001, 2002, 2003, 2004, 2005 by Intevation GmbH * Authors: * Bernhard Herzog * @@ -31,11 +31,17 @@ #include -/* For wx2.5, we cannot just extract the address of the object from the - * Python string repr; we need to go through the Swig mechanisms +/* By default we use the wxPython.h API to access wxPython's objects at + * the C++ level. On some systems that's not available, so we offer a + * work-around with swigPtrConvertHack.h, but we only do so if the + * compiler explicitly defines USE_WX_PYTHON_SWIG_HACK. */ +#ifndef USE_WX_PYTHON_SWIG_HACK +#include +#else #include "swigPtrConvertHack.h" -//#include +#endif + /* We only need this prototype from the above (big) include: * * bool wxPyConvertSwigPtr( PyObject* obj, void **ptr, const wxChar* className); Index: swigPtrConvertHack.h =================================================================== RCS file: /thubanrepository/thuban/libraries/thuban/swigPtrConvertHack.h,v retrieving revision 1.1 retrieving revision 1.2 diff -u -d -r1.1 -r1.2 --- swigPtrConvertHack.h 16 Feb 2005 21:14:47 -0000 1.1 +++ swigPtrConvertHack.h 5 Apr 2005 17:26:58 -0000 1.2 @@ -3,34 +3,8 @@ #include - -#if wxCHECK_VERSION(2,5,3) - -#define wxPyUSE_EXPORTED_API -#include "wxPython_int.h" -static bool wxPyCoreAPI_IMPORT() -{ - wxPyCoreAPIPtr=(wxPyCoreAPI*)PyCObject_Import("wx._core_", "_wxPyCoreAPI"); - - if (! wxPyCoreAPIPtr) - wxPyCoreAPIPtr=(wxPyCoreAPI*)PyCObject_Import("_core_", "_wxPyCoreAPI"); - return wxPyCoreAPIPtr != NULL; -} - -// Used by the macros below to fetch the API pointer, importing it first if -// needed. This should never need to be called directly. -inline wxPyCoreAPI* wxPyGetCoreAPIPtr() -{ - if (wxPyCoreAPIPtr == NULL) wxPyCoreAPI_IMPORT(); - // wxASSERT_MSW(wxPyCoreAPIPtr != NULL, wxT("wxPyCoreAPIPtr is NULL!!!")); // uncomment when needed for debugging - return wxPyCoreAPIPtr; -} - -#define wxPyConvertSwigPtr(a,b,c) (wxPyGetCoreAPIPtr()->p_wxPyConvertSwigPtr(a,b,c)) - -#else - /* helper function to extract the pointer value from a swig ptr string + * as used in wxPython 2.4 */ static void * decode_pointer(char *string) @@ -56,22 +30,94 @@ return (void*)p; } -/* Return the object wrapped by the SWIG shadow object shadow */ -bool wxPyConvertSwigPtr( PyObject* obj, void **ptr, const wxChar* className) +/* helper function to extract the pointer value from a swig ptr string + * as used in wxPython 2.5 + * + * The hexvalues describe the bytes making up the pointer in memory, + * i.e. when the pointer is considered as an array of bytes (we assume + * char==byte in the implementation). In the older version it was + * always a bigendian representation. + */ +static void* +decode_pointer_new(char *string, unsigned int length) { - PyObject * string; + void * p = 0; + unsigned char *pp = (unsigned char*)&p; + unsigned int count = 0; + + /* sanity check: the string must be at least as long as twice the + * size of the pointer (two hex digits per byte) plus one for the + * initial underscore */ + if (length < 2 * sizeof(p) + 1) + return NULL; + + /* Pointer values must start with leading underscore */ + if (*string == '_') + { + string++; + length--; + + /* the remaining length must be at least twice as long as the + * size of the pointer. */ + + /* now decode the hex values. We decode exactly two bytes for + * each of the bytes in the pointer */ + while (count < 2 * sizeof(p)) + { + if ((*string >= '0') && (*string <= '9')) + *pp = (*pp << 4) + (*string - '0'); + else if ((*string >= 'a') && (*string <= 'f')) + *pp = (*pp << 4) + ((*string - 'a') + 10); + else + break; + string++; + count++; + if (count % 2 == 0) + pp++; + } + } + return p; +} + +/* Return the object wrapped by the SWIG shadow object shadow + * + * The pointer to the real object can be decoded from the "this" + * attribute of the python object. In wxPython 2.4 it's a string + * containing a hex representation of the pointer value. In wxPython + * 2.5 it's a special python object which can nevertheless be converted + * to a string with a hex representation of the pointer value which is a + * bit different than the one for 2.4. + */ +bool +wxPyConvertSwigPtr(PyObject* obj, void **ptr, const wxChar* className) +{ + PyObject * string = NULL; + PyObject * thisobject = NULL; + *ptr = 0; - string = PyObject_GetAttrString(obj, "this"); - if (string && PyString_Check(string)) + thisobject = PyObject_GetAttrString(obj, "this"); + if (thisobject) { - *ptr = decode_pointer(PyString_AsString(string)); + if (!PyString_Check(thisobject)) + { + string = PyObject_Str(thisobject); + if (string) + { + *ptr = decode_pointer_new(PyString_AsString(string), + PyString_Size(string)); + Py_DECREF(string); + } + } + else + { + *ptr = decode_pointer(PyString_AsString(thisobject)); + } } - Py_XDECREF(string); + + Py_XDECREF(thisobject); return *ptr != 0; } - -#endif #endif From cvs at intevation.de Tue Apr 5 19:27:00 2005 From: cvs at intevation.de (cvs@intevation.de) Date: Tue, 5 Apr 2005 19:27:00 +0200 (CEST) Subject: bh: thuban setup.py,1.49,1.50 ChangeLog,1.798,1.799 Message-ID: <20050405172700.8F6CD1005B7@lists.intevation.de> Author: bh Update of /thubanrepository/thuban In directory doto:/tmp/cvs-serv24411 Modified Files: setup.py ChangeLog Log Message: Use wxPython.h by default but provide a workaround when it isn't available. * setup.py (wxproj_extension): New variable. Assign the Extension instance for Lib.wxproj to this variable instead of putting it directly into the listso that it can be accessed by other code later. (thuban_build_ext.user_options): Added boolean option --use-wx-python-swig-hack. (thuban_build_ext.initialize_options): Initialize the new option to False. (thuban_build_ext.finalize_options): If the new option was given, define the preprocesser macro USE_WX_PYTHON_SWIG_HACK. (thuban_build_ext): Update the doc-string * libraries/thuban/wxproj.cpp: Normally we use wx/wxPython/wxPython.h now. Only if USE_WX_PYTHON_SWIG_HACK is defined, use swigPtrConvertHack.h instead. * libraries/thuban/swigPtrConvertHack.h: Remove the code that was copied over from wxPython.h. (decode_pointer_new): New. Equivalent of decode_pointer for wxPython 2.5. (wxPyConvertSwigPtr): Modified to cope with wxPython 2.5 as well. Index: setup.py =================================================================== RCS file: /thubanrepository/thuban/setup.py,v retrieving revision 1.49 retrieving revision 1.50 diff -u -d -r1.49 -r1.50 --- setup.py 18 Feb 2005 14:56:42 -0000 1.49 +++ setup.py 5 Apr 2005 17:26:58 -0000 1.50 @@ -1,4 +1,4 @@ -# Copyright (c) 2001, 2002, 2003, 2004 by Intevation GmbH +# Copyright (c) 2001, 2002, 2003, 2004, 2005 by Intevation GmbH # Authors: # Bernhard Herzog # @@ -252,15 +252,16 @@ # Thuban specific modules # -extensions.append(Extension("Lib.wxproj", - [ext_dir + "/thuban/wxproj.cpp"], - include_dirs = ([shp_dir, proj4_incdir, - ext_dir + "/pyshapelib/"] - + wx_cs_params[CS_INCDIRS]), - define_macros = wx_cs_params[CS_DEFS], - library_dirs = [proj4_libdir] + - wx_cs_params[CS_LIBDIRS], - libraries = [proj4_lib] + wx_cs_params[CS_LIBS])) +wxproj_extension = Extension("Lib.wxproj", + [ext_dir + "/thuban/wxproj.cpp"], + include_dirs = ([shp_dir, proj4_incdir, + ext_dir + "/pyshapelib/"] + + wx_cs_params[CS_INCDIRS]), + define_macros = wx_cs_params[CS_DEFS], + library_dirs = [proj4_libdir] + + wx_cs_params[CS_LIBDIRS], + libraries = [proj4_lib] + wx_cs_params[CS_LIBS]) +extensions.append(wxproj_extension) # @@ -1072,22 +1073,42 @@ class thuban_build_ext(build_ext): - """Extend the build_ext command to optionally include the - GDAL extension. + """Extend the build_ext command with some Thuban specific options + + --with-gdal, --without-gdal + + Switch the optional GDAL support on/off. Default is On. + + --use-wx-python-swig-hack + + For performance reasons, Thuban access wxPython objects at the + C++ level so that it can directly call wxWidgets code from C++. + The normal and preferred way to do that is to use the API + defined in wxPython.h. Unfortunately, this header file is not + distributed with binary packages of wxPython on some platforms. + By using the --use-wx-python-swig-hack option you can activate a + way to access the C++ objects without wxPython.h. This relies + on internals of SWIG, so it might change with future wxPython + versions. Therefore, only use this option if the normal way + doesn't work for you. """ user_options = build_ext.user_options[:] user_options.extend([("with-gdal", None, "Include GDAL support."), - ("without-gdal", None, "Don't include GDAL support.")]) + ("without-gdal", None, "Don't include GDAL support."), + ("use-wx-python-swig-hack", None, + "Use a hack to access wxPython objects at the C++ level" + "(use only when you absolutely can't use wxPython.h)")]) - boolean_options = ["with-gdal"] + boolean_options = ["with-gdal", "use-wx-python-swig-hack"] negative_opt = {'without-gdal' : 'with-gdal'} def initialize_options(self): self.with_gdal = True + self.use_wx_python_swig_hack = False build_ext.initialize_options(self) - def finalize_options(self): + def finalize_options(self): build_ext.finalize_options(self) if self.with_gdal and include_gdal: self.extensions.append(Extension("Lib.gdalwarp", @@ -1097,6 +1118,9 @@ define_macros = gdal_cs_params[CS_DEFS], library_dirs = gdal_cs_params[CS_LIBDIRS], libraries = gdal_cs_params[CS_LIBS])) + if self.use_wx_python_swig_hack: + wxproj_extension.define_macros.append(("USE_WX_PYTHON_SWIG_HACK", + None)) def run(self, install_options = None): build_ext.run(self) Index: ChangeLog =================================================================== RCS file: /thubanrepository/thuban/ChangeLog,v retrieving revision 1.798 retrieving revision 1.799 diff -u -d -r1.798 -r1.799 --- ChangeLog 29 Mar 2005 18:36:53 -0000 1.798 +++ ChangeLog 5 Apr 2005 17:26:58 -0000 1.799 @@ -1,3 +1,33 @@ +2005-04-05 Bernhard Herzog + + Use wxPython.h by default but provide a workaround when it isn't + available. + + * setup.py (wxproj_extension): New variable. Assign the Extension + instance for Lib.wxproj to this variable instead of putting it + directly into the listso that it can be accessed by other code + later. + (thuban_build_ext.user_options): Added boolean option + --use-wx-python-swig-hack. + (thuban_build_ext.initialize_options): Initialize the new option + to False. + (thuban_build_ext.finalize_options): If the new option was given, + define the preprocesser macro USE_WX_PYTHON_SWIG_HACK. + (thuban_build_ext): Update the doc-string + + * libraries/thuban/wxproj.cpp: Normally we use + wx/wxPython/wxPython.h now. Only if USE_WX_PYTHON_SWIG_HACK is + defined, use swigPtrConvertHack.h instead. + + * libraries/thuban/swigPtrConvertHack.h: Remove the code that was + copied over from wxPython.h. + (decode_pointer_new): New. Equivalent of decode_pointer for + wxPython 2.5. + (wxPyConvertSwigPtr): Modified to cope with wxPython 2.5 as well. + + * README: Add section on potential build problems which explains + how the work-around for a missing wxPython.h is activated. + 2005-03-29 Bernhard Herzog * test/postgissupport.py (find_postgis_sql): Added yet another From jonathan at jpcoles.com Tue Apr 5 22:48:27 2005 From: jonathan at jpcoles.com (Jonathan Coles) Date: Tue, 05 Apr 2005 16:48:27 -0400 Subject: Thuban more modular? In-Reply-To: <20050405184124.GA10911@intevation.de> References: <1112277804.14081.120.camel@localhost.localdomain> <20050402142255.GH8823@intevation.de> <20050405053057.GA18451@intevation.de> <1112720709.2694.1.camel@localhost.localdomain> <20050405181050.GJ10643@intevation.de> <1112725258.2694.6.camel@localhost.localdomain> <20050405184124.GA10911@intevation.de> Message-ID: <1112734107.2694.21.camel@localhost.localdomain> Am Dienstag, den 05.04.2005, 20:41 +0200 schrieb Jan-Oliver Wagner: > It would be really best to send the patch try this. uncompressing the attachment will create a new directory Extensions/gdal and add thuban.py.patch to the current directory. apply the path and then run thuban. there will be a new menu option under map to add a gdal image layer. the behavior should be the same as for a raster layer. one additional enhancement i have added is incremental rendering. the layer is rendered in four quandrants. while this is slightly slower than generating the whole image at once, the visual feedback is more pleasing as one sees the image appear in stages, rather than a white screen with no sense of anything happening until the image appears. the number of rows and columns that make up the incremental rendering is adjustable. they are currently set at 2, but can be changed using the xblocks and yblocks variables in gdallayer.py. if they are both set to 1 the whole image is generated in one step, as per the current behavior for raster layers. --jonathan -- ===================================================================== Jonathan Coles http://www.jpcoles.com jonathan at jpcoles.com GnuPG Key: /gpg_pub_key.asc ===================================================================== -------------- next part -------------- A non-text attachment was scrubbed... Name: gdal-extension.tar.gz Type: application/x-compressed-tar Size: 5646 bytes Desc: not available Url : http://www.intevation.de/pipermail/thuban-devel/attachments/20050405/953c4010/gdal-extension.tar.gz From cvs at intevation.de Tue Apr 5 23:12:26 2005 From: cvs at intevation.de (cvs@intevation.de) Date: Tue, 5 Apr 2005 23:12:26 +0200 (CEST) Subject: bh: thuban/libraries/thuban wxproj.cpp,1.6,1.7 Message-ID: <20050405211226.F1B141006B6@lists.intevation.de> Author: bh Update of /thubanrepository/thuban/libraries/thuban In directory doto:/tmp/cvs-serv30130/libraries/thuban Modified Files: wxproj.cpp Log Message: Make it work with a wxPython.h from wxPython 2.4 as well. Also, remove a now obsolete comment. Index: wxproj.cpp =================================================================== RCS file: /thubanrepository/thuban/libraries/thuban/wxproj.cpp,v retrieving revision 1.6 retrieving revision 1.7 diff -u -d -r1.6 -r1.7 --- wxproj.cpp 5 Apr 2005 17:26:58 -0000 1.6 +++ wxproj.cpp 5 Apr 2005 21:12:24 -0000 1.7 @@ -42,15 +42,37 @@ #include "swigPtrConvertHack.h" #endif -/* We only need this prototype from the above (big) include: - * - * bool wxPyConvertSwigPtr( PyObject* obj, void **ptr, const wxChar* className); - * - * but it is a macro involving a large struct and static variables, so we - * can't just get along with a prototype. - * Trouble is this file is not installed by default on Debian. +/* Compatibility code to cope with wxPython.h from wxPython 2.4. + * + * Instead of wxPyConvertSwigPtr there's SWIG_GetPtrObj which has almost + * the same interface but is a little different. So we define our own + * wxPyConvertSwigPtr if we're being compiled with wxPython 2.4. We + * determine that by checking whether a macro wxPyConvertSwigPtr is + * defined. + * + * In wxPython 2.5 the last parameter, type, is of type wxChar* which + * may be a wchar_t* and thus incompatible with char* and it's value is + * slightly different (the one in 2.4 needs a few more characters + * appended and prefixed). Fortunately, it's is always passed via wxT, + * a macro that we only use for the type parameter. So redefine it to + * do nothing but add the pre- and suffixes necessary for 2.4. */ +#ifndef wxPyConvertSwigPtr +bool +wxPyConvertSwigPtr(PyObject *obj, void **ptr, char *type) +{ + /* import the API ptr if it hasn't been imported yet */ + if (wxPyCoreAPIPtr == NULL) + wxPyCoreAPI_IMPORT(); + return SWIG_GetPtrObj(obj, ptr, type) == 0; +} +#undef wxT +#define wxT(a) ("_" a "_p") +#endif + + +/* pyshapelib api pointer */ static PyShapeLibAPI * pyshapelib_api; From cvs at intevation.de Tue Apr 5 23:12:27 2005 From: cvs at intevation.de (cvs@intevation.de) Date: Tue, 5 Apr 2005 23:12:27 +0200 (CEST) Subject: bh: thuban ChangeLog,1.799,1.800 Message-ID: <20050405211227.0AF411006B7@lists.intevation.de> Author: bh Update of /thubanrepository/thuban In directory doto:/tmp/cvs-serv30130 Modified Files: ChangeLog Log Message: Make it work with a wxPython.h from wxPython 2.4 as well. Also, remove a now obsolete comment. Index: ChangeLog =================================================================== RCS file: /thubanrepository/thuban/ChangeLog,v retrieving revision 1.799 retrieving revision 1.800 diff -u -d -r1.799 -r1.800 --- ChangeLog 5 Apr 2005 17:26:58 -0000 1.799 +++ ChangeLog 5 Apr 2005 21:12:24 -0000 1.800 @@ -1,5 +1,10 @@ 2005-04-05 Bernhard Herzog + * libraries/thuban/wxproj.cpp: Make it work with a wxPython.h from + wxPython 2.4 as well. Also, remove a now obsolete comment. + +2005-04-05 Bernhard Herzog + Use wxPython.h by default but provide a workaround when it isn't available. From cvs at intevation.de Tue Apr 5 23:13:05 2005 From: cvs at intevation.de (cvs@intevation.de) Date: Tue, 5 Apr 2005 23:13:05 +0200 (CEST) Subject: bh: thuban README,1.8,1.9 Message-ID: <20050405211305.C103E1006B7@lists.intevation.de> Author: bh Update of /thubanrepository/thuban In directory doto:/tmp/cvs-serv30182 Modified Files: README Log Message: Add section on potential build problems which explains how the work-around for a missing wxPython.h is activated. Index: README =================================================================== RCS file: /thubanrepository/thuban/README,v retrieving revision 1.8 retrieving revision 1.9 diff -u -d -r1.8 -r1.9 --- README 26 Mar 2004 18:04:23 -0000 1.8 +++ README 5 Apr 2005 21:13:03 -0000 1.9 @@ -76,6 +76,28 @@ See po/README for more information. +Build Troubleshooting +--------------------- + +When building Thuban, you might have problems because of a missing file +wx/wxPython/wxPython.h. This file is part of wxPython and may be +packaged in a separate package. Unfortunately, on some systems this +file is not packaged at all. On those systems you can try a work-around +built into Thuban, by passing the --use-wx-python-swig-hack to the +build_ext command. This can be done on the command line for the build +command like this: + + python setup.py build_ext --use-wx-python-swig-hack build + +You can also use it with the install_local command: + + python setup.py build_ext --use-wx-python-swig-hack install_local + +Note, that this work-around relies on some wxPython internals and may +cease to work at some point. We tested it with wxPython 2.4 and +wxPython 2.5. + + License ------- From cvs at intevation.de Tue Apr 5 23:24:52 2005 From: cvs at intevation.de (cvs@intevation.de) Date: Tue, 5 Apr 2005 23:24:52 +0200 (CEST) Subject: jan: thuban/test postgissupport.py,1.7.2.4,1.7.2.5 Message-ID: <20050405212452.8D1C01006B6@lists.intevation.de> Author: jan Update of /thubanrepository/thuban/test In directory doto:/tmp/cvs-serv30276 Modified Files: Tag: thuban-1-0-branch postgissupport.py Log Message: Backport from HEAD: (find_postgis_sql): Added yet another potential location for (lw)postgis.sql because the file has moved again in postgis 1.0.0 rc4. Index: postgissupport.py =================================================================== RCS file: /thubanrepository/thuban/test/postgissupport.py,v retrieving revision 1.7.2.4 retrieving revision 1.7.2.5 diff -u -d -r1.7.2.4 -r1.7.2.5 --- postgissupport.py 25 Jan 2005 09:31:18 -0000 1.7.2.4 +++ postgissupport.py 5 Apr 2005 21:24:50 -0000 1.7.2.5 @@ -484,6 +484,7 @@ postgis 0.7.5 $datadir/contrib/postgis.sql postgis 0.8.1 $datadir/postgis.sql postgis 1.0.0-rc1 $datadir/lwpostgis.sql + postgis 1.0.0-rc4 $datadir/contrib/lwpostgis.sql To support both versions, we look in both places and return the first one found (looking under contrib first). If the file is not @@ -493,7 +494,8 @@ datadir = os.path.join(bindir, "..", "share", "postgresql") for filename in [os.path.join(datadir, "contrib", "postgis.sql"), os.path.join(datadir, "postgis.sql"), - os.path.join(datadir, "lwpostgis.sql")]: + os.path.join(datadir, "lwpostgis.sql"), + os.path.join(datadir, "contrib", "lwpostgis.sql")]: if os.path.exists(filename): return filename From cvs at intevation.de Tue Apr 5 23:25:28 2005 From: cvs at intevation.de (cvs@intevation.de) Date: Tue, 5 Apr 2005 23:25:28 +0200 (CEST) Subject: jan: thuban ChangeLog,1.624.2.39,1.624.2.40 Message-ID: <20050405212528.AEFD01006B7@lists.intevation.de> Author: jan Update of /thubanrepository/thuban In directory doto:/tmp/cvs-serv30309 Modified Files: Tag: thuban-1-0-branch ChangeLog Log Message: Backport from HEAD for PostGIS. Index: ChangeLog =================================================================== RCS file: /thubanrepository/thuban/ChangeLog,v retrieving revision 1.624.2.39 retrieving revision 1.624.2.40 diff -u -d -r1.624.2.39 -r1.624.2.40 --- ChangeLog 10 Mar 2005 07:52:15 -0000 1.624.2.39 +++ ChangeLog 5 Apr 2005 21:25:26 -0000 1.624.2.40 @@ -1,3 +1,11 @@ +2005-04-05 Jan-Oliver Wagner + + Backport from HEAD. + + * test/postgissupport.py (find_postgis_sql): Added yet another + potential location for (lw)postgis.sql because the file has moved + again in postgis 1.0.0 rc4. + 2005-03-10 Jan-Oliver Wagner * libraries/thuban/gdalwarp.cpp (MFILENAME): Fixed macro From jan at intevation.de Tue Apr 5 23:41:32 2005 From: jan at intevation.de (Jan-Oliver Wagner) Date: Tue, 5 Apr 2005 23:41:32 +0200 Subject: Wishes for the next Thuban Windows installer Message-ID: <20050405214132.GB11275@intevation.de> Hi, I tried the Windows installer today and I found a number of crucial quick-tryout stoppers I send here for archiving purpose: - it would be good to include the iceland sample data and to add a "Thuban Iceland Demo" to the Menu which directly runs one of the iceland .thuban files. - GDAL should be updated (1.1.8 is rather old). - GDAL should either be included in the Thuban installer or have its own. - PostGIS package: Either include or name a installer. - Add Thuban Manual as pdf to Thuban Menu. Best Jan -- Jan-Oliver Wagner http://intevation.de/~jan/ Intevation GmbH http://intevation.de/ FreeGIS http://freegis.org/ From cvs at intevation.de Tue Apr 5 23:55:17 2005 From: cvs at intevation.de (cvs@intevation.de) Date: Tue, 5 Apr 2005 23:55:17 +0200 (CEST) Subject: jan: thuban/Doc/manual thuban-manual-de.xml,1.9,1.10 Message-ID: <20050405215517.CBB601005D2@lists.intevation.de> Author: jan Update of /thubanrepository/thuban/Doc/manual In directory doto:/tmp/cvs-serv30579 Modified Files: thuban-manual-de.xml Log Message: More translations. Index: thuban-manual-de.xml =================================================================== RCS file: /thubanrepository/thuban/Doc/manual/thuban-manual-de.xml,v retrieving revision 1.9 retrieving revision 1.10 diff -u -d -r1.9 -r1.10 --- thuban-manual-de.xml 14 Mar 2005 08:16:25 -0000 1.9 +++ thuban-manual-de.xml 5 Apr 2005 21:55:15 -0000 1.10 @@ -1164,32 +1164,39 @@
Klassifizierung bearbeiten - A layer's classification can be modified under the properties dialog + Die Klassifizierung für eine Ebene wird über den Eigenschaftendialog + bearbeitet ( - Layer - Properties - ). The layer's classification field can be set to None, - which simply assigns a DEFAULT group to the classification. No new - groups can be added to the classification if the field is None. - The user must first select a field to classify on. New groups can - be added to the classification with the Add - button. + Ebene + Eigenschaften + ). Das Feld für die Klassifizierung der Ebene kann ugesetzt sein. + In diesem Fall wird die Gruppe DEFAULT als Klassifizierung eingesetzt. + Solange kein Feld gesetzt wird kann keine weiter Gruppe zur + Klassifizierung hinzugefügt werden. + Es muss also zunächst ein Feld ausgewählt werden. Dann können + weitere Gruppen mit dem Knopf + Hinzufügen in die Klassifizierung aufgenommen + werden. - To apply the changes to the map the user can click - either Try or OK. - Try will not close the dialog box, allowing - the user to see how the classification changes the map. - Revert will undo the last classification applied - to the map. OK will commit the changes and - close the dialog. The user will be unable to undo the changes. - Close simply closes the dialog box. If any - changes have not been applied with Try the - changes will not be applied to the map. + Um die Änderungen auf die Karte anzuwenden kann der Benutzer + entweder Anwenden oder + OK verwenden. + Anwenden schliesst dabei den Dialog + nicht, sondern gestattet es, die gemachten Änderungen auf der + Karte als Voransicht zu sehen. + Zurücksetzen setzt die zuletzt angewendete + Klassifikation zurück. + OK wendet die Änderungen an + und schliesst den Dialog. Dann können die Änderungen + nicht mehr zurückgenommen werden. + Schliessen beendet den Dialog. + Alle Änderungen, die nicht mit Anwenden auf + die Karte gebracht wurden, werden verworfen.
- Properties Window + Eigenschaften Fenster @@ -1197,71 +1204,81 @@
- The order of the groups in the classification is significant - except for the DEFAULT group, which remains at the top. When shapes - are matched against groups the matching begins at the first group - after the DEFAULT group so that groups higher in the list will - be checked first. Matching for a - given shape will stop at the first group that matches. The user can - use Move Up and Move Down - to change the order of the groups. The DEFAULT group will always - match a shape that hasn't matched another group. + Die Reihenfolge der Gruppen in der klassifizierung ist + von Bedeutung. Eine Ausnahme bildet die Gruppe DEFAULT, + welche immer ganz oben verbleibt. + Werden die Shapes den Gruppen zugeordnet, so beginnt + der Vergleich mit der ersten Gruppe nach DEFAULT und dann + absteigend. + Der Vergleich endet sobald eine Gruppe für das Shape passt. + Mit Eine Ebene nach oben bewegen und + Eine Ebene nach unten bewegen + wird die Reihenfolge der Gruppen geändert. + Die Gruppe DEFAULT wird uaf alle Shapes angewandt die + auf keine der anderen Gruppen passssen. -
Visible +
Sichtbar - The Visible column has check-boxes that determine whether a - classification group will be displayed in the legend. This is - useful if the user knows that the groups completely cover - the data set and don't want the DEFAULT group to be displayed - in the legend and on a printout. + Die Spalte Sichtbar beinhaltet Ankreuzfelder mit denen + bestimmt werden kann ob die Gruppen auch in der + Legende dargestellt werden sollen. + Das ist zum Beispiel hilfreich wenn die Gruppen alle + Shapes abdecken und daher die Gruppe DEFAULT nicht + in der Legende bzw. im Ausdruck auftauchen soll.
-
Symbols +
Symbole - Each type of shape has its own type of symbol. Thuban supports three - types of shapes: polygons, lines, and points. Polygons and points - have outline and fill color, while lines have only line color. Each - group has associated symbol properties. To edit the symbol - properties for a group the user can double click on the Symbol - column or select a group and click the - Edit Symbol button. + Jeder Shape-Typ hat seinen eigenen Symbol-Typ. + Thuban unterstützt 3 Shape-Typen: Polygone, Linien und Punkte. + Polygone und Punkte haben eine Rand- und Füllfarbe, Linien + haben nur eine Linienfarbe. + zu jeder Gruppe gehören Symbol-Eigenschaften. + Um diese zu bearbeiten, kann man entweder einen Doppelclick + auf das Symbol machen oder die entsprechende Gruppe + selektieren und dann den Knopf + Symbol bearbeiten verwenden.
-
Value +
Wert - The Value column of the classification table is the value that will - be matched when the map is being drawn. The type of data that can - entered into this field depends on the type of data of the - classification field. + Die Spalte Wert enthält die Werte auf die die Shapes + verglichen werden wenn die Karte gezeichnet wird. + Die Art der Angaben in diesen Feldern hängt vom + Typ der Daten des Klassifizierungs-Feldes. - If the field is of type Text, anything entered - into the field is valid. The text will be compared literally to the - value of the shape attribute, including case sensitivity. - If the type is Integer, then any valid integer may be entered. In - addition, with special syntax, a range of values can be entered. - A range from start to end - inclusive is specified like this: [start;end]. - The exclusive range is specified like this: - ]start;end[. Ranges can include infinity like - this: [-oo;oo]. Field types can also be of type - Decimal. They represent any rational number and can be used in - ranges as well. + Ist das Feld vom Typ Text, sind beliebige Eingaben erlaubt. + Der Text wird buchstabenweise mit dem Wert des Shape-Attributes + verglichen. Gross-Kleinschreibung wird dabei berücksichtigt. + Ist das Feld vom Typ Integer, sind alle ganzen Zahlen + erlaubt. Darüber hinaus können auch mit spezieller Syntax + Bereiche angegeben werden. + Ein Bereich von start bis + ende inklusive der Grenzen wird so + eingegeben: [start;ende]. + Der Bereich ohne die Grnezen wird so angegeben: + ]start;ende[. Bereich können auch + Unendlich als Wert benutzen: [-oo;oo]. + Der Feld-Typ kann auch Dezimal sein. Dann können beliebeige + rationale Zahlen verwendet werden.
Label - By default, the text that is displayed for a group in the legend - is the value for that group. The label can substitute a more - descriptive term in the legend. + + + als Voreinstellung wird als Label für die Gruppe in der + Legende der Wert verwendet. Es kann aber auch ein spezieller + Label angegeben werden.
-
Generating Classes +
Erzeuge Klassifikation
- Generate Class + Erzeuge Klasse @@ -1269,34 +1286,43 @@
- Creating a classification by hand can be tedious. - Thuban, therefore, provides a means of generating an entire - classification at once while still giving the user control over - how it appears. Clicking Generate Class - opens the Generate Classification dialog. - Under the Generate pull down there are at most - three different ways to generate classifications: - Unique Values, Uniform Distribution, and Quantiles. Some options - may not be available if the data type for the field does not - support them. For instance, Uniform Distribution - doesn't make sense for a Text field. + Das manuelle erstellen eine Klassifikation + kann anstrengend werden. + Thuban bietet hier die Möglichkeit, Klassikationen + automatisch, aber unter Kontrolle des Benutzers, zu + erstellen. + Clicked man auf Erzeuge Klasse + so wird der Dialog Erzeuge Klassifikationn + geöffnet. + Unter dem Aufklappmenü Erzeuge finden sich + in der Regel drei unterschiedliche Arten für die + Erzeugung von Klassifikationen: + Eindeutige Werte, Gleichförmige Verteilung und Quantile. + Einige Optionen sind nicht verfügbar wenn der Datentyp + des Feldes es nicht unterstützt. + So macht beispielsweise Gleichförmige Verteilung + keinen Sinn bei Text-Feldern. - For every way of generating a classification, a color scheme must - be selected. Thuban provides several different color schemes that - affect how the group properties change over the classification. - It may be desirable that only certain properties change over the - classification. If the shape type is a polygon or a point then - the Fix Border Color option will be available. - This allows the user to select a border color for all classification - groups. - It is also possible to create a custom color scheme. Selecting - this option will display two symbols: the one of the left has the - properties of the first group and the one on the right has the - properties of the last group. Thuban will interpolate between these - two properties to generate the other groups. + In jedem Fall muss bei der Erzeugung einer Klassifizierung + ein Farbschema ausgewählt werden. + Thuban bietet einige verschiedene Farb-Schemata die dann bestimmen + wie sich Gruppeneigenschaften über die Klassifizierung ändern. + Es mag gewünscht sein, dass nur bestimmte Eigenschaften + sich über die Klassifizierung ändern. + Ist der Shape-Typ Polygon oder Punkt, so die Option + Rahmenfarbe festlegen verfügbar. + Diese erlaubt es, eine feste Rahmenfarbe für alle + Gruppen der Klassifizierung festzulegen. + Es ist ebenfalls möglich ein benutzerdefiniertes Farbschema + zu erstellen. + Wählt man diese Option aus, werden zwei Symbole + dargestellt: das linke Symbol hat die Eigenschaften für + die erste Gruppe, das rechte für die letzte Gruppe. + Thuban interpoliert dann zwischen diesen beiden um die + Eigenschaften für die enderen Gruppen zu erstellen.
- Custom Color Scheme + Benutzerdefiniertes Farbschema @@ -1304,15 +1330,17 @@
- The Unique Values option lets the user select specific values that - appear in the table. Clicking Retrieve From Table - searches the table for all unique values and displays them in the - list on the left. Items can be selected and moved to the list on the - right. Each list can be sorted or reversed for easier searching. - The classification that is generated will be in the same order as - the list on the right. + Die Option Eindeutige Werte erlaubt es, spezielle Werte + auszuwählen die in der Tabelle vorkommen. + Clickt man Aus Tabelle holen + so wird die Tabelle nach allen vorkommenden Werten + durchsucht und diese in der Liste auf der linken Seite dargestellt. + Beide Listen für eine schnellere Suche sortiert + oder umgedreht werden. + Die Klassifizierung die dann erzeugt wird + wird dieselbe Sortierung wie die rechte Liste haben.
- Unique Values + Eindeutuige Werte @@ -1320,14 +1348,17 @@
- The Uniform Distribution option creates a user specified number of - groups of ranges such that each range covers equal intervals. The - minimum and maximum values can automatically be retrieved from the - table by clicking Retrieve From Table. The - stepping is how large each interval is. Adjusting this value will - automatically recalculate how many groups is appropriate. + Die Option Gleichförmige Verteilung erzeugt die angegebene + Anzahl von Gruppen mit Bereichen wobei alle Bereiche + das gleiche Intervall haben. + Minimum und Maximum hierfür können automatisch aus der Tabelle + ermittelt werden indem die Option + Aus Tabelle holen verwendet wird. + Die Stufen bestimmen die Grösse des Intervalls. + Ändert man diesen Wert, wird automatisch neu berechnet + wie viele Gruppen nun passend sind.
- Uniform Distribution + Gleichförmige Verteilung @@ -1335,13 +1366,15 @@
- The Quantiles option generates ranges based on the number of items - in the table. For example, by specifying five groups Thuban will - generate five groups with appropriate ranges such that 20% of the table - data is in each group. If it is impossible to generate exact - groupings, Thuban will issue a warning but allow the user to continue. + Die Option Quantile erzeugt Bereiche anhand der Anzahl Elemente in + der Tabelle. + Beispielsweise werden durch die Wahl von fünf Gruppen + entsprechend fünf Gruppen mit passenden Bereichen erstellt, + so dass 20% der Tabellendaten in jeder Gruppe enthalten sind. + Ist es nicht möglich exakte Gruppierungen zu erzeugen, + sow wird Thuban Warnung mitteilen aber die Aktion fortführen.
- Quantiles + Quantile @@ -1351,13 +1384,16 @@
- Projection Management + Projektions-Management - Projections control how the geographic data is displayed on the screen. - If multiple layers are loaded into Thuban where the geographic data - is in a different projection system, then the user must specify a - projection for each layer. The user must also tell Thuban which - projection the map is in. This can be the same as the layers or a different + Projektionen bestimmen wie geographische Daten auf dem + Bildschirm dargestellt werden. + Werden mehrere Ebenen in Thuban geladen bei denen die + geographischen Daten in verschiedenen Projektionssystemen + vorliegen, so muss jeder Ebene die entsprechende Projektion + zugeordnet sein. Ebenso muss eine Projektion für die Karte + angegeben werden. + This can be the same as the layers or a different projection in which case the layers are reprojected into that space. The map projection can be set using From cvs at intevation.de Tue Apr 5 23:56:09 2005 From: cvs at intevation.de (cvs@intevation.de) Date: Tue, 5 Apr 2005 23:56:09 +0200 (CEST) Subject: jan: thuban ChangeLog,1.800,1.801 Message-ID: <20050405215609.8DF0D1005D2@lists.intevation.de> Author: jan Update of /thubanrepository/thuban In directory doto:/tmp/cvs-serv30636 Modified Files: ChangeLog Log Message: More manual translations. Index: ChangeLog =================================================================== RCS file: /thubanrepository/thuban/ChangeLog,v retrieving revision 1.800 retrieving revision 1.801 diff -u -d -r1.800 -r1.801 --- ChangeLog 5 Apr 2005 21:12:24 -0000 1.800 +++ ChangeLog 5 Apr 2005 21:56:07 -0000 1.801 @@ -1,3 +1,7 @@ +2005-04-05 Jan-Oliver Wagner + + * Doc/manual/thuban-manual-de.xml: More translations. + 2005-04-05 Bernhard Herzog * libraries/thuban/wxproj.cpp: Make it work with a wxPython.h from From jonathan at jpcoles.com Wed Apr 6 16:13:28 2005 From: jonathan at jpcoles.com (Jonathan Coles) Date: Wed, 06 Apr 2005 10:13:28 -0400 Subject: Extension Architecture Message-ID: <1112796808.2694.62.camel@localhost.localdomain> concerning the extension architecture that we've been discussing: i believe the ExtensionRegistry is the right way to go. i was about to write one myself when i noticed that there is already one in UI/. however, this class should not be in UI but in Model because extensions are a concept which is not specific to the UI but a generic feature of thuban. All extensions should be required to register before they can be used and the add() method should also take an Extension instance. to add hooks that extensions can use there should be a generic class perhaps called ExtensionHook that is extended by parts of thuban that wish to provide a clean interface to extensions. this class would have one or more "add" methods which take as arguments the Extension instance created by the extension and whatever other arguments are appropriate for the hook (e.g. one or more callback functions). these add functions would first check that the extension has been registered by calling a function in the parent ExtensionHook class. they might even allow an extension to register multiple times (?). if we provide a nice ExtensionHook class we provide a consistant interface for adding extensions rather than what we have now with the renderer and layer properties, which is somewhat inconsistant. i prefer this method of allowing each part of thuban to control its own extension handling for two reasons: 1) the alternative may to be create one large class that has methods for all the different hooks available. the biggest drawback i can see is that this would mean including UI hooks in the same class as Model hooks. to avoid this, one could create two hook classes, one for UI and one for Model, but this is not really any better than having each part create its own hook mechanism, and could make it harder to add other hook classes in the future. 2) more importantly than reason (1) is that extensions could themselves provide extension points. yes, this could cause extension dependency issues, but could also make thuban much more flexible and powerful. since all extensions are registered before they are initialized, it should be possible for extensions to determine whether all the necessary dependancies are present. the ExtensionRegistry should be made smarter. perhaps the extensions should be allowed some freedom in determining whether multiple versions are allowed. for instance, what if the init_callback function took a list of other extensions that have been registered with the same name? if the list is non-empty then init_callback could determine if is should unregister itself if it has a lower version than what is provided. allowing multiple versions is a good idea if different versions handle input files differently. rather than worrying about backward compatibility an extension could allow different versions to co-exist within thuban. a true conflict can be signalled by the return value from init_callback. in such cases the user can be shown a list of problem extensions and decide whether or not to proceed. that's all for now. :) thoughts? --jonathan -- ===================================================================== Jonathan Coles http://www.jpcoles.com jonathan at jpcoles.com GnuPG Key: /gpg_pub_key.asc ===================================================================== From bernhard at intevation.de Wed Apr 6 17:37:39 2005 From: bernhard at intevation.de (Bernhard Reiter) Date: Wed, 6 Apr 2005 17:37:39 +0200 Subject: Extension Architecture In-Reply-To: <1112796808.2694.62.camel@localhost.localdomain> References: <1112796808.2694.62.camel@localhost.localdomain> Message-ID: <20050406153739.GP7802@intevation.de> Am 6. Apr 2005 um 10:13:28 schrieb Jonathan Coles: > i believe the ExtensionRegistry is the right way to go. i was about to > write one myself when i noticed that there is already one in UI/. > however, this class should not be in UI but in Model because extensions > are a concept which is not specific to the UI but a generic feature of > thuban. All extensions should be required to register before they can be > used and the add() method should also take an Extension instance. Just a wild guess: It might be in UI, because we had the problem to display the registered extensions. And the extensions themselfs should not depend on UI so they can be automatically tested. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://www.intevation.de/pipermail/thuban-devel/attachments/20050406/18ff5e4c/attachment.bin From jonathan at jpcoles.com Wed Apr 6 18:15:36 2005 From: jonathan at jpcoles.com (Jonathan Coles) Date: Wed, 06 Apr 2005 12:15:36 -0400 Subject: Extension Architecture In-Reply-To: <20050406153739.GP7802@intevation.de> References: <1112796808.2694.62.camel@localhost.localdomain> <20050406153739.GP7802@intevation.de> Message-ID: <1112804136.2694.76.camel@localhost.localdomain> Am Mittwoch, den 06.04.2005, 17:37 +0200 schrieb Bernhard Reiter: > Am 6. Apr 2005 um 10:13:28 schrieb Jonathan Coles: > > i believe the ExtensionRegistry is the right way to go. i was about to > > write one myself when i noticed that there is already one in UI/. > > however, this class should not be in UI but in Model because extensions > > are a concept which is not specific to the UI but a generic feature of > > thuban. All extensions should be required to register before they can be > > used and the add() method should also take an Extension instance. > > Just a wild guess: It might be in UI, because we had the problem > to display the registered extensions. And the extensions themselfs > should not depend on UI so they can be automatically tested. the init_callback function may make use of UI components so it should not be called unless there is a gui available. however, this can be tested for (an example is in the ogr extension __init__.py), so the actual callback function can be changed depending on whether we are running the tests or not. under normal operating conditions, init_callback would initialize everything properly (model and gui components). under test conditions, a different init_callback would be specified which would not initialize the gui part and allow the tests to run. this problem is up to the extension to handle properly. the idea of an extension registry should really be part of Model, not UI. please also understand, that i am proposing these changes as part of an overall architecture design change. as the code stands now it is fine for what it does, but if we want to make the extension model more complete then it makes sense to move ExtensionRegistry out of UI and add more generic functionality. --jonathan -- ===================================================================== Jonathan Coles http://www.jpcoles.com jonathan at jpcoles.com GnuPG Key: /gpg_pub_key.asc ===================================================================== From thuban-bugs at intevation.de Thu Apr 7 19:23:24 2005 From: thuban-bugs at intevation.de (Request Tracker) Date: Thu, 7 Apr 2005 19:23:24 +0200 (CEST) Subject: [bug #3148] (thuban) Better transaction handling for postgis Message-ID: <20050407172324.15B931005D6@lists.intevation.de> this bug's URL: http://intevation.de/rt/webrt?serial_num=3148 ------------------------------------------------------------------------- Subject: Better transaction handling for postgis Thuban's postgis support doesn't handle the transactions properly. All queries are made withing the same transaction and as soon as something goes wrong, all subsequent queries result in an error. Typical error message: ProgrammingError: ERROR: current transaction is aborted, commands ignored until end of transaction block A number of bugs have been filed for this problem. I'm going to close all the existing ones in favor of this new one. The bugs are: 2966 3068 2259 -------------------------------------------- Managed by Request Tracker From bh at intevation.de Thu Apr 7 21:02:19 2005 From: bh at intevation.de (Bernhard Herzog) Date: Thu, 07 Apr 2005 21:02:19 +0200 Subject: preparing for Thuban 1.1 Message-ID: Hi all, the HEAD branch of Thuban has seen quite a few improvements since the stable 1.0 branch was created. It's time to make a 1.1 development release. In preparation for that I went through the bug tracker to determine which of the bugs need to be fixes before the release: Issues that need to be fixed for a Thuban 1.1 release: - PostGIS transaction handling - encoding issues in about box and elsewhere. https://intevation.de/rt/webrt?serial_num=2980 https://intevation.de/rt/webrt?serial_num=2258 - "ZeroDivisionError: float division" in set_view_transform https://intevation.de/rt/webrt?serial_num=2309 - the raster layer opacity isn't saved to the .thuban files. This one's not in the bug tracker. I've also not found any time to look at the code so far. Noncritical issues that should be fixed nevertheless: - Panning with middle mouse button while no tool is active I know how to solve this. It's quite simple. https://intevation.de/rt/webrt?serial_num=2921 - Grid and PostGIS not sure what the problem is, so no idea how difficult to solve. https://intevation.de/rt/webrt?serial_num=2293 https://intevation.de/rt/webrt?serial_num=2339 - Session tree with PostGIS-Layer Should be relatively easy to fix https://intevation.de/rt/webrt?serial_num=2338 - Fix Layer.ClipBoundingBox Should also be easy to fix https://intevation.de/rt/webrt?serial_num=2845 Bernhard -- Intevation GmbH http://intevation.de/ Skencil http://skencil.org/ Thuban http://thuban.intevation.org/ From thuban-bugs at intevation.de Thu Apr 7 21:20:54 2005 From: thuban-bugs at intevation.de (Request Tracker) Date: Thu, 7 Apr 2005 21:20:54 +0200 (CEST) Subject: [bug #3149] (thuban) variable points implementation not finished yet Message-ID: <20050407192054.5E1E1100160@lists.intevation.de> this bug's URL: http://intevation.de/rt/webrt?serial_num=3149 ------------------------------------------------------------------------- Subject: variable points implementation not finished yet There are some things still missing in the implementation of variable point sizes: 1. the size is not saved in the .thuban files in some cases. It happens at least for the iceland_sample_raster.thuban file when one modifies the size of the points in the default classification of the cultural_landmark-point layer. 2. the size is not honored when hightlighting selected points. -------------------------------------------- Managed by Request Tracker From bh at intevation.de Thu Apr 7 21:30:08 2005 From: bh at intevation.de (Bernhard Herzog) Date: Thu, 07 Apr 2005 21:30:08 +0200 Subject: preparing for Thuban 1.1 In-Reply-To: (Bernhard Herzog's message of "Thu, 07 Apr 2005 21:02:19 +0200") References: Message-ID: Bernhard Herzog writes: > In preparation for that I went through the bug tracker to determine > which of the bugs need to be fixes before the release: I've changed the priority of the issues listed to match their priority for 1.1: critical issues are now at 70, less critical ones at 50 and all others are < 50. Bernhard -- Intevation GmbH http://intevation.de/ Skencil http://skencil.org/ Thuban http://thuban.intevation.org/ From bernhard at intevation.de Thu Apr 7 21:31:11 2005 From: bernhard at intevation.de (Bernhard Reiter) Date: Thu, 7 Apr 2005 21:31:11 +0200 Subject: preparing for Thuban 1.1 In-Reply-To: References: Message-ID: <20050407193111.GM27403@intevation.de> Am 7. Apr 2005 um 21:30:08 schrieb Bernhard Herzog: > Bernhard Herzog writes: > > > In preparation for that I went through the bug tracker to determine > > which of the bugs need to be fixes before the release: > > I've changed the priority of the issues listed to match their priority > for 1.1: critical issues are now at 70, less critical ones at 50 and all > others are < 50. Very good. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://www.intevation.de/pipermail/thuban-devel/attachments/20050407/b1489978/attachment.bin From bh at intevation.de Thu Apr 7 21:43:03 2005 From: bh at intevation.de (Bernhard Herzog) Date: Thu, 07 Apr 2005 21:43:03 +0200 Subject: preparing for Thuban 1.1 In-Reply-To: (Bernhard Herzog's message of "Thu, 07 Apr 2005 21:02:19 +0200") References: Message-ID: Bernhard Herzog writes: > Issues that need to be fixed for a Thuban 1.1 release: There's one more: - variable points implementation not finished yet https://intevation.de/rt/webrt?serial_num=3149 Bernhard -- Intevation GmbH http://intevation.de/ Skencil http://skencil.org/ Thuban http://thuban.intevation.org/ From cvs at intevation.de Thu Apr 7 21:46:31 2005 From: cvs at intevation.de (cvs@intevation.de) Date: Thu, 7 Apr 2005 21:46:31 +0200 (CEST) Subject: bh: thuban/Thuban/UI classifier.py,1.73,1.74 Message-ID: <20050407194631.2176810015D@lists.intevation.de> Author: bh Update of /thubanrepository/thuban/Thuban/UI In directory doto:/tmp/cvs-serv13219/Thuban/UI Modified Files: classifier.py Log Message: (ClassGrid.__init__): Use -1 as the ID. (ID_CLASS_TABLE): Removed. It wasn't used anywhere except in ClassGrid.__init__ and it's value is outside of the valid range (must be < 32768). wxPython 2.5 complains about it with an exception. Index: classifier.py =================================================================== RCS file: /thubanrepository/thuban/Thuban/UI/classifier.py,v retrieving revision 1.73 retrieving revision 1.74 diff -u -d -r1.73 -r1.74 --- classifier.py 8 Feb 2005 20:34:29 -0000 1.73 +++ classifier.py 7 Apr 2005 19:46:28 -0000 1.74 @@ -1,4 +1,4 @@ -# Copyright (c) 2003-2004 by Intevation GmbH +# Copyright (c) 2003-2005 by Intevation GmbH # Authors: # Jan-Oliver Wagner (2003-2004) # Martin Schulze (2004) @@ -44,8 +44,6 @@ from Thuban.UI.layerproperties import LayerProperties from messages import MAP_REPLACED -ID_CLASS_TABLE = 40011 - # table columns COL_VISIBLE = 0 @@ -75,8 +73,7 @@ clazz -- the working classification that this grid should use for display. """ - - wxGrid.__init__(self, parent, ID_CLASS_TABLE, style = 0) + wxGrid.__init__(self, parent, -1, style = 0) self.classifier = classifier From cvs at intevation.de Thu Apr 7 21:46:31 2005 From: cvs at intevation.de (cvs@intevation.de) Date: Thu, 7 Apr 2005 21:46:31 +0200 (CEST) Subject: bh: thuban ChangeLog,1.801,1.802 Message-ID: <20050407194631.2F73C100160@lists.intevation.de> Author: bh Update of /thubanrepository/thuban In directory doto:/tmp/cvs-serv13219 Modified Files: ChangeLog Log Message: (ClassGrid.__init__): Use -1 as the ID. (ID_CLASS_TABLE): Removed. It wasn't used anywhere except in ClassGrid.__init__ and it's value is outside of the valid range (must be < 32768). wxPython 2.5 complains about it with an exception. Index: ChangeLog =================================================================== RCS file: /thubanrepository/thuban/ChangeLog,v retrieving revision 1.801 retrieving revision 1.802 diff -u -d -r1.801 -r1.802 --- ChangeLog 5 Apr 2005 21:56:07 -0000 1.801 +++ ChangeLog 7 Apr 2005 19:46:29 -0000 1.802 @@ -1,3 +1,11 @@ +2005-04-07 Bernhard Herzog + + * Thuban/UI/classifier.py (ClassGrid.__init__): Use -1 as the ID. + (ID_CLASS_TABLE): Removed. It wasn't used anywhere except in + ClassGrid.__init__ and it's value is outside of the valid + range (must be < 32768). wxPython 2.5 complains about it with an + exception. + 2005-04-05 Jan-Oliver Wagner * Doc/manual/thuban-manual-de.xml: More translations. From jonathan at jpcoles.com Fri Apr 8 00:11:25 2005 From: jonathan at jpcoles.com (Jonathan Coles) Date: Thu, 07 Apr 2005 18:11:25 -0400 Subject: preparing for Thuban 1.1 In-Reply-To: References: Message-ID: <1112911885.2632.2.camel@localhost.localdomain> Am Donnerstag, den 07.04.2005, 21:02 +0200 schrieb Bernhard Herzog: > - the raster layer opacity isn't saved to the .thuban files. This > one's not in the bug tracker. I've also not found any time to look > at the code so far. this was intentionally ommited because i wanted to be sure that everyone agreed it was something worth saving. if i get that agreement i'll add it. --jonathan -- ===================================================================== Jonathan Coles http://www.jpcoles.com jonathan at jpcoles.com GnuPG Key: /gpg_pub_key.asc ===================================================================== From jan at intevation.de Sun Apr 10 23:54:28 2005 From: jan at intevation.de (Jan-Oliver Wagner) Date: Sun, 10 Apr 2005 23:54:28 +0200 Subject: wxproj compilation problems Message-ID: <20050410215428.GA18984@intevation.de> Hi, since the recent changes regarding the wx header file, I can not build Thuban anymore: | $ python setup.py build_ext --use-wx-python-swig-hack install_local | running build_ext | building 'Lib.wxproj' extension | gcc -pthread -fno-strict-aliasing -DNDEBUG -g -O3 -Wall | -Wstrict-prototypes -fPIC -DGTK_NO_CHECK_CASTS -D__WXGTK__ | -D_FILE_OFFSET_BITS=64 -D_LARGE_FILES -DUSE_WX_PYTHON_SWIG_HACK | -Ilibraries/shapelib -I/usr/local/include -Ilibraries/pyshapelib/ | -I/usr/lib/wx/include/gtk-2.4 -I/usr/include/python2.3 -c | libraries/thuban/wxproj.cpp -o | build/temp.linux-ppc-2.3/libraries/thuban/wxproj.o | libraries/thuban/wxproj.cpp: In function `bool | wxPyConvertSwigPtr(PyObject*, void**, char*)': | libraries/thuban/wxproj.cpp:65: error: `wxPyCoreAPIPtr' undeclared | (first use | this function) | libraries/thuban/wxproj.cpp:65: error: (Each undeclared identifier | is reported | only once for each function it appears in.) | libraries/thuban/wxproj.cpp:66: error: `wxPyCoreAPI_IMPORT' | undeclared (first | use this function) | libraries/thuban/wxproj.cpp:68: error: `SWIG_GetPtrObj' | undeclared (first use | this function) | error: command 'gcc' failed with exit status 1 I am on Debian sarge with wx 2.4. Any ideas? Jan -- Jan-Oliver Wagner http://intevation.de/~jan/ Intevation GmbH http://intevation.de/ FreeGIS http://freegis.org/ From bh at intevation.de Mon Apr 11 11:45:36 2005 From: bh at intevation.de (Bernhard Herzog) Date: Mon, 11 Apr 2005 11:45:36 +0200 Subject: wxproj compilation problems In-Reply-To: <20050410215428.GA18984@intevation.de> (Jan-Oliver Wagner's message of "Sun, 10 Apr 2005 23:54:28 +0200") References: <20050410215428.GA18984@intevation.de> Message-ID: Jan-Oliver Wagner writes: > | libraries/thuban/wxproj.cpp:66: error: `wxPyCoreAPI_IMPORT' > | undeclared (first > | use this function) > | libraries/thuban/wxproj.cpp:68: error: `SWIG_GetPtrObj' > | undeclared (first use > | this function) > | error: command 'gcc' failed with exit status 1 > > I am on Debian sarge with wx 2.4. > > Any ideas? Logic error on my part. Is the following patch better? *** wxproj.cpp 07 Apr 2005 17:10:42 +0200 1.7 --- wxproj.cpp 11 Apr 2005 11:42:00 +0200 *************** *** 38,46 **** */ #ifndef USE_WX_PYTHON_SWIG_HACK #include - #else - #include "swigPtrConvertHack.h" - #endif /* Compatibility code to cope with wxPython.h from wxPython 2.4. * --- 38,43 ---- *************** *** 69,76 **** } #undef wxT #define wxT(a) ("_" a "_p") ! #endif /* pyshapelib api pointer */ static PyShapeLibAPI * pyshapelib_api; --- 66,76 ---- } #undef wxT #define wxT(a) ("_" a "_p") ! #endif /* not wxPyConvertSwigPtr */ + #else /* USE_WX_PYTHON_SWIG_HACK */ + #include "swigPtrConvertHack.h" + #endif /* USE_WX_PYTHON_SWIG_HACK */ /* pyshapelib api pointer */ static PyShapeLibAPI * pyshapelib_api; Bernhard -- Intevation GmbH http://intevation.de/ Skencil http://skencil.org/ Thuban http://thuban.intevation.org/ From jan at intevation.de Mon Apr 11 17:51:27 2005 From: jan at intevation.de (Jan-Oliver Wagner) Date: Mon, 11 Apr 2005 17:51:27 +0200 Subject: wxproj compilation problems In-Reply-To: References: <20050410215428.GA18984@intevation.de> Message-ID: <20050411155127.GB20111@intevation.de> On Mon, Apr 11, 2005 at 11:45:36AM +0200, Bernhard Herzog wrote: > Jan-Oliver Wagner writes: > > > | libraries/thuban/wxproj.cpp:66: error: `wxPyCoreAPI_IMPORT' > > | undeclared (first > > | use this function) > > | libraries/thuban/wxproj.cpp:68: error: `SWIG_GetPtrObj' > > | undeclared (first use > > | this function) > > | error: command 'gcc' failed with exit status 1 > > > > I am on Debian sarge with wx 2.4. > > > > Any ideas? > > Logic error on my part. Is the following patch better? yes. Now it works again. Thanks. Jan -- Jan-Oliver Wagner http://intevation.de/~jan/ Intevation GmbH http://intevation.de/ FreeGIS http://freegis.org/ From cvs at intevation.de Mon Apr 11 20:18:10 2005 From: cvs at intevation.de (cvs@intevation.de) Date: Mon, 11 Apr 2005 20:18:10 +0200 (CEST) Subject: bh: thuban/libraries/thuban wxproj.cpp,1.7,1.8 Message-ID: <20050411181810.5E6121005A8@lists.intevation.de> Author: bh Update of /thubanrepository/thuban/libraries/thuban In directory doto:/tmp/cvs-serv18352/libraries/thuban Modified Files: wxproj.cpp Log Message: Move the compatibility code that deals with the wxPython 2.4 version of wxPython.h into the #ifdef branch that includes wxPython.h because it's only needed when wxPython.h is used. Also, it won't compile when USE_WX_PYTHON_SWIG_HACK is set otherwise. Index: wxproj.cpp =================================================================== RCS file: /thubanrepository/thuban/libraries/thuban/wxproj.cpp,v retrieving revision 1.7 retrieving revision 1.8 diff -u -d -r1.7 -r1.8 --- wxproj.cpp 5 Apr 2005 21:12:24 -0000 1.7 +++ wxproj.cpp 11 Apr 2005 18:18:08 -0000 1.8 @@ -38,9 +38,6 @@ */ #ifndef USE_WX_PYTHON_SWIG_HACK #include -#else -#include "swigPtrConvertHack.h" -#endif /* Compatibility code to cope with wxPython.h from wxPython 2.4. * @@ -69,8 +66,11 @@ } #undef wxT #define wxT(a) ("_" a "_p") -#endif +#endif /* not wxPyConvertSwigPtr */ +#else /* USE_WX_PYTHON_SWIG_HACK */ +#include "swigPtrConvertHack.h" +#endif /* USE_WX_PYTHON_SWIG_HACK */ /* pyshapelib api pointer */ static PyShapeLibAPI * pyshapelib_api; From cvs at intevation.de Mon Apr 11 20:18:10 2005 From: cvs at intevation.de (cvs@intevation.de) Date: Mon, 11 Apr 2005 20:18:10 +0200 (CEST) Subject: bh: thuban ChangeLog,1.802,1.803 Message-ID: <20050411181810.6D8D71005AB@lists.intevation.de> Author: bh Update of /thubanrepository/thuban In directory doto:/tmp/cvs-serv18352 Modified Files: ChangeLog Log Message: Move the compatibility code that deals with the wxPython 2.4 version of wxPython.h into the #ifdef branch that includes wxPython.h because it's only needed when wxPython.h is used. Also, it won't compile when USE_WX_PYTHON_SWIG_HACK is set otherwise. Index: ChangeLog =================================================================== RCS file: /thubanrepository/thuban/ChangeLog,v retrieving revision 1.802 retrieving revision 1.803 diff -u -d -r1.802 -r1.803 --- ChangeLog 7 Apr 2005 19:46:29 -0000 1.802 +++ ChangeLog 11 Apr 2005 18:18:08 -0000 1.803 @@ -1,3 +1,11 @@ +2005-04-11 Bernhard Herzog + + * libraries/thuban/wxproj.cpp: Move the compatibility code that + deals with the wxPython 2.4 version of wxPython.h into the #ifdef + branch that includes wxPython.h because it's only needed when + wxPython.h is used. Also, it won't compile when + USE_WX_PYTHON_SWIG_HACK is set otherwise. + 2005-04-07 Bernhard Herzog * Thuban/UI/classifier.py (ClassGrid.__init__): Use -1 as the ID. From nelson at crynwr.com Mon Apr 11 22:09:52 2005 From: nelson at crynwr.com (Russell Nelson) Date: Mon, 11 Apr 2005 16:09:52 -0400 Subject: bh: thuban/libraries/thuban wxproj.cpp,1.7,1.8 In-Reply-To: <20050411181810.5E6121005A8@lists.intevation.de> References: <20050411181810.5E6121005A8@lists.intevation.de> Message-ID: <16986.55696.120653.98808@desk.crynwr.com> cvs at intevation.de writes: > Modified Files: > wxproj.cpp > Log Message: > Move the compatibility code that > deals with the wxPython 2.4 version of wxPython.h into the #ifdef > branch that includes wxPython.h because it's only needed when > wxPython.h is used. Also, it won't compile when > USE_WX_PYTHON_SWIG_HACK is set otherwise. Hmmm.... wxproj.cpp is not compilable under Fedora Core 2 with these packages installed: wxGTK2-2.4.2-0.fdr.2.2 wxGTK2-devel-2.4.2-0.fdr.2.2 libraries/thuban/wxproj.cpp:40:34: wx/wxPython/wxPython.h: No such file or directory I don't know enough about wxWindows to be able to fix it myself. -- --My blog is at blog.russnelson.com | The laws of physics cannot Crynwr sells support for free software | PGPok | be legislated. Neither can 521 Pleasant Valley Rd. | +1 315-323-1241 cell | the laws of countries. Potsdam, NY 13676-3213 | +1 212-202-2318 VOIP | From jonathan at jpcoles.com Tue Apr 12 01:44:40 2005 From: jonathan at jpcoles.com (Jonathan Coles) Date: Mon, 11 Apr 2005 19:44:40 -0400 Subject: bh: thuban/libraries/thuban wxproj.cpp,1.7,1.8 In-Reply-To: <16986.55696.120653.98808@desk.crynwr.com> References: <20050411181810.5E6121005A8@lists.intevation.de> <16986.55696.120653.98808@desk.crynwr.com> Message-ID: <1113263080.2632.12.camel@localhost.localdomain> Am Montag, den 11.04.2005, 16:09 -0400 schrieb Russell Nelson: > Hmmm.... wxproj.cpp is not compilable under Fedora Core 2 with these > packages installed: > > wxGTK2-2.4.2-0.fdr.2.2 > wxGTK2-devel-2.4.2-0.fdr.2.2 > > libraries/thuban/wxproj.cpp:40:34: wx/wxPython/wxPython.h: No such file or directory >From the README file (this was only recently added): Build Troubleshooting --------------------- When building Thuban, you might have problems because of a missing file wx/wxPython/wxPython.h. This file is part of wxPython and may be packaged in a separate package. Unfortunately, on some systems this file is not packaged at all. On those systems you can try a work-around built into Thuban, by passing the --use-wx-python-swig-hack to the build_ext command. This can be done on the command line for the build command like this: python setup.py build_ext --use-wx-python-swig-hack build You can also use it with the install_local command: python setup.py build_ext --use-wx-python-swig-hack install_local Note, that this work-around relies on some wxPython internals and may cease to work at some point. We tested it with wxPython 2.4 and wxPython 2.5. --jonathan -- ===================================================================== Jonathan Coles http://www.jpcoles.com jonathan at jpcoles.com GnuPG Key: /gpg_pub_key.asc ===================================================================== From nelson at crynwr.com Tue Apr 12 03:54:04 2005 From: nelson at crynwr.com (Russell Nelson) Date: Mon, 11 Apr 2005 21:54:04 -0400 Subject: bh: thuban/libraries/thuban wxproj.cpp,1.7,1.8 In-Reply-To: <1113263080.2632.12.camel@localhost.localdomain> References: <20050411181810.5E6121005A8@lists.intevation.de> <16986.55696.120653.98808@desk.crynwr.com> <1113263080.2632.12.camel@localhost.localdomain> Message-ID: <16987.10812.851364.733812@desk.crynwr.com> Jonathan Coles writes: > When building Thuban, you might have problems because of a missing file > wx/wxPython/wxPython.h. This file is part of wxPython and may be > packaged in a separate package. Unfortunately, on some systems this > file is not packaged at all. On those systems you can try a work-around > built into Thuban, by passing the --use-wx-python-swig-hack to the > build_ext command. This can be done on the command line for the build > command like this: > > python setup.py build_ext --use-wx-python-swig-hack build That works great, but why doesn't setup.py do that automagically? Watching setup.py exit with an error certainly gives me the idea that it has a bug. -- --My blog is at blog.russnelson.com | The laws of physics cannot Crynwr sells support for free software | PGPok | be legislated. Neither can 521 Pleasant Valley Rd. | +1 315-323-1241 cell | the laws of countries. Potsdam, NY 13676-3213 | +1 212-202-2318 VOIP | From cvs at intevation.de Wed Apr 13 18:08:36 2005 From: cvs at intevation.de (cvs@intevation.de) Date: Wed, 13 Apr 2005 18:08:36 +0200 (CEST) Subject: russell: thuban/Thuban/UI view.py,1.64,1.65 Message-ID: <20050413160836.17A051005DA@lists.intevation.de> Author: russell Update of /thubanrepository/thuban/Thuban/UI In directory doto:/tmp/cvs-serv13109/Thuban/UI Modified Files: view.py Log Message: Fixing bug #2921, panning with middle button not working without active tool Index: view.py =================================================================== RCS file: /thubanrepository/thuban/Thuban/UI/view.py,v retrieving revision 1.64 retrieving revision 1.65 diff -u -d -r1.64 -r1.65 --- view.py 27 Dec 2004 16:31:32 -0000 1.64 +++ view.py 13 Apr 2005 16:08:33 -0000 1.65 @@ -358,9 +358,9 @@ def OnMiddleDown(self, event): self.remembertool = self.tool - if self.tool: + if self.Map() is not None and self.Map().HasLayers(): self.PanTool() - self.OnLeftDown(event) + self.OnLeftDown(event) def OnMiddleUp(self, event): self.OnLeftUp(event) From bernhard at intevation.de Wed Apr 13 19:18:12 2005 From: bernhard at intevation.de (Bernhard Reiter) Date: Wed, 13 Apr 2005 19:18:12 +0200 Subject: bh: thuban/libraries/thuban wxproj.cpp,1.7,1.8 In-Reply-To: <16987.10812.851364.733812@desk.crynwr.com> References: <20050411181810.5E6121005A8@lists.intevation.de> <16986.55696.120653.98808@desk.crynwr.com> <1113263080.2632.12.camel@localhost.localdomain> <16987.10812.851364.733812@desk.crynwr.com> Message-ID: <20050413171812.GL26301@intevation.de> Am 11. Apr 2005 um 21:54:04 schrieb Russell Nelson: > Jonathan Coles writes: > > python setup.py build_ext --use-wx-python-swig-hack build > > That works great, but why doesn't setup.py do that automagically? > Watching setup.py exit with an error certainly gives me the idea that > it has a bug. Because this indicated a bug in the wxpython packages on your platform and you should file a bug against them. (I guess we can improve the error message in that case. :) ) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://www.intevation.de/pipermail/thuban-devel/attachments/20050413/aaf4ade8/attachment.bin From bh at intevation.de Wed Apr 13 19:34:29 2005 From: bh at intevation.de (Bernhard Herzog) Date: Wed, 13 Apr 2005 19:34:29 +0200 Subject: bh: thuban/libraries/thuban wxproj.cpp,1.7,1.8 In-Reply-To: <20050413171812.GL26301@intevation.de> (Bernhard Reiter's message of "Wed, 13 Apr 2005 19:18:12 +0200") References: <20050411181810.5E6121005A8@lists.intevation.de> <16986.55696.120653.98808@desk.crynwr.com> <1113263080.2632.12.camel@localhost.localdomain> <16987.10812.851364.733812@desk.crynwr.com> <20050413171812.GL26301@intevation.de> Message-ID: Bernhard Reiter writes: > Am 11. Apr 2005 um 21:54:04 schrieb Russell Nelson: >> Jonathan Coles writes: >> > python setup.py build_ext --use-wx-python-swig-hack build >> >> That works great, but why doesn't setup.py do that automagically? >> Watching setup.py exit with an error certainly gives me the idea that >> it has a bug. > > Because this indicated a bug in the wxpython packages on your > platform and you should file a bug against them. In the case of wxPython 2.4 it's not only a packaging bug, though. When you build wxPython 2.4 from sources wxPython.h is not installed automatically. It still is the preferred way to access the objects at the C++ level. When I added the --use-wx-python-swig-hack flag I considered whether setup.py should set it automatically when using wxPython 2.4. It would have taken even more time to implement and I had already spent more time on than I wanted to, and it might make setup.py a bit too smart. OTOH, as it stands Thuban is a bit harder to build with wxPython 2.4. We should perhaps consider making setup.py smarter in this regard for the 1.1 release. Bernhard -- Intevation GmbH http://intevation.de/ Skencil http://skencil.org/ Thuban http://thuban.intevation.org/ From bernhard at intevation.de Wed Apr 13 20:00:12 2005 From: bernhard at intevation.de (Bernhard Reiter) Date: Wed, 13 Apr 2005 20:00:12 +0200 Subject: bh: thuban/libraries/thuban wxproj.cpp,1.7,1.8 In-Reply-To: References: <20050411181810.5E6121005A8@lists.intevation.de> <16986.55696.120653.98808@desk.crynwr.com> <1113263080.2632.12.camel@localhost.localdomain> <16987.10812.851364.733812@desk.crynwr.com> <20050413171812.GL26301@intevation.de> Message-ID: <20050413180012.GS26301@intevation.de> Am 13. Apr 2005 um 19:34:29 schrieb Bernhard Herzog: > Bernhard Reiter writes: > > > Am 11. Apr 2005 um 21:54:04 schrieb Russell Nelson: > >> Jonathan Coles writes: > >> > python setup.py build_ext --use-wx-python-swig-hack build > >> > >> That works great, but why doesn't setup.py do that automagically? > >> Watching setup.py exit with an error certainly gives me the idea that > >> it has a bug. > > > > Because this indicated a bug in the wxpython packages on your > > platform and you should file a bug against them. > > In the case of wxPython 2.4 it's not only a packaging bug, though. When > you build wxPython 2.4 from sources wxPython.h is not installed > automatically. It still is the preferred way to access the objects at > the C++ level. Ah, I was mixing this up then. > OTOH, > as it stands Thuban is a bit harder to build with wxPython 2.4. We > should perhaps consider making setup.py smarter in this regard for the > 1.1 release. Well, it was okay as decision I guess, because getting 1.1 into the hands of more people is more important than to make setup.py smarter in this regard IMO. From nelson at crynwr.com Wed Apr 13 20:10:42 2005 From: nelson at crynwr.com (Russell Nelson) Date: Wed, 13 Apr 2005 14:10:42 -0400 Subject: bh: thuban/libraries/thuban wxproj.cpp,1.7,1.8 In-Reply-To: References: <20050411181810.5E6121005A8@lists.intevation.de> <16986.55696.120653.98808@desk.crynwr.com> <1113263080.2632.12.camel@localhost.localdomain> <16987.10812.851364.733812@desk.crynwr.com> <20050413171812.GL26301@intevation.de> Message-ID: <16989.24738.487638.75400@desk.crynwr.com> Bernhard Herzog writes: > as it stands Thuban is a bit harder to build with wxPython 2.4. We > should perhaps consider making setup.py smarter in this regard for the > 1.1 release. Or at least catching the problem and giving the user a hint: "This often happens when wxPython 2.4 has been mis-packaged. As a workaround ..... " If you don't tell them ... they'll do what I did and report it as a bug. -- --My blog is at blog.russnelson.com | The laws of physics cannot Crynwr sells support for free software | PGPok | be legislated. Neither can 521 Pleasant Valley Rd. | +1 315-323-1241 cell | the laws of countries. Potsdam, NY 13676-3213 | +1 212-202-2318 VOIP | From fclee at highstream.net Fri Apr 15 18:04:20 2005 From: fclee at highstream.net (Frederick C.Lee) Date: Fri, 15 Apr 2005 09:04:20 -0700 Subject: Translating Shape Data to the Screen Message-ID: Greetings: I just installed Thuban code but am currently having trouble building it on my Mac OS X (10.3.8)/Darwin. I'm currently setting up environment variables, etc. so Python (2.4) and PythonWx can see everything. That said, I need to know which Thuban module actually translates the ShapLib coordinates into on-screen coordinates. The following is a piece of a .shp dump: Shapefile Type: Polygon # of Shapes: 661 File Bounds: (-2168511.500, 417031.562,0,0) to ( 1492183.500, 2379070.500,0,0) Shape:0 (Polygon) nVertices=4, nParts=1 Bounds:( -91599.203, 2376631.000, 0, 0) to ( -89468.781, 2379070.500, 0, 0) ( -91599.203, 2376631.000, 0, 0) Ring ( -90551.562, 2379070.500, 0, 0) ( -89468.781, 2378232.500, 0, 0) ( -91599.203, 2376631.000, 0, 0) I want to view the code that translates this data to the screen. Which module actually does this? Also, any coordination code (and significance) between data from the .dbf with .shp would be truly appreciated. Again, Your help would truly be appreciated. Best Regards, Ric. From thuban-bugs at intevation.de Mon Apr 18 12:05:25 2005 From: thuban-bugs at intevation.de (Request Tracker) Date: Mon, 18 Apr 2005 12:05:25 +0200 (CEST) Subject: [bug #3158] (thuban) problems labelling PostGIs layer Message-ID: <20050418100525.9CFBF1006A3@lists.intevation.de> this bug's URL: http://intevation.de/rt/webrt?serial_num=3158 ------------------------------------------------------------------------- Subject: problems labelling PostGIs layer Operating System: MS Windows, XP Thuban version: 1.0.1 wxPython version: 2.4.2.4 Python version: other, 2.3.4 PySQLite version: other, 1.1.6 GDAL version: 1.1.8 Please enter error description here. Did you compile Thuban yourself? no If not, which binary package did you install (eg. where did you get it from)? Thuban-1.0.1-0.exe from FreeGIS website. This occurs when I use the label tool, click on an object, choose a field and click OK. An unhandled exception occurred: PostGISShapeStore instance has no attribute 'Shapefile' (please report to http://thuban.intevation.org/bugtracker.html) Traceback (most recent call last): File "C:\Program Files\Thuban\Thuban\UI\view.py", line 385, in OnLeftUp self.MouseLeftUp(event) File "C:\Program Files\Thuban\Thuban\UI\viewport.py", line 605, in MouseLeftUp self.tool.MouseUp(event) File "C:\Program Files\Thuban\Thuban\UI\viewport.py", line 202, in MouseUp self.view.LabelShapeAt(event.m_x, event.m_y) File "C:\Program Files\Thuban\Thuban\UI\view.py", line 438, in LabelShapeAt ViewPort.LabelShapeAt(self, x, y, text) File "C:\Program Files\Thuban\Thuban\UI\viewport.py", line 930, in LabelShapeAt shapefile = layer.ShapeStore().Shapefile().cobject() AttributeError: PostGISShapeStore instance has no attribute 'Shapefile' -------------------------------------------- Managed by Request Tracker From thuban-bugs at intevation.de Mon Apr 18 15:34:37 2005 From: thuban-bugs at intevation.de (Request Tracker) Date: Mon, 18 Apr 2005 15:34:37 +0200 (CEST) Subject: [bug #3159] (thuban) attempt to open PostGIS layer crashed Thuban and corrupted .thuban file Message-ID: <20050418133437.CCB581006A2@lists.intevation.de> this bug's URL: http://intevation.de/rt/webrt?serial_num=3159 ------------------------------------------------------------------------- Subject: attempt to open PostGIS layer crashed Thuban and corrupted .thuban file Operating System: MS Windows, XP Thuban version: 1.0.1 wxPython version: 2.4.2.4 Python version: other, 2.3.4 PySQLite version: other, 1.6.1 GDAL version: 1.1.8 Please enter error description here. Did you compile Thuban yourself? no If not, which binary package did you install (eg. where did you get it from)? windows executable - from freegis / sourceforge An unhandled exception occurred: 'MULTIPOINT' (please report to http://thuban.intevation.org/bugtracker.html) Traceback (most recent call last): File "C:\Program Files\Thuban\Thuban\UI\mainwindow.py", line 282, in invoke_command command.Execute(self.Context()) File "C:\Program Files\Thuban\Thuban\UI\command.py", line 121, in Execute apply(self.function, (context,) + self.args + args, kw) File "C:\Program Files\Thuban\Thuban\UI\mainwindow.py", line 957, in call_method apply(getattr(context.mainwindow, methodname), args) File "C:\Program Files\Thuban\Thuban\UI\mainwindow.py", line 387, in OpenSession self.run_db_param_dialog) File "C:\Program Files\Thuban\Thuban\UI\application.py", line 235, in OpenSession self.SetSession(session) File "C:\Program Files\Thuban\Thuban\UI\application.py", line 179, in SetSession self.maps_changed() File "C:\Program Files\Thuban\Thuban\UI\application.py", line 279, in maps_changed self.top.SetMap(self.session.Maps()[0]) File "C:\Program Files\Thuban\Thuban\UI\mainwindow.py", line 437, in SetMap dialog.GetPanel().SetMap(self.Map()) File "\.\Thuban\UI\legend.py", line 156, in SetMap File "\.\Thuban\UI\legend.py", line 356, in SetMap File "\.\Thuban\UI\legend.py", line 575, in __FillTree File "\.\Thuban\UI\legend.py", line 649, in __AddLayer File "\.\Thuban\UI\legend.py", line 590, in __FillTreeLayer File "\.\Thuban\Model\layer.py", line 216, in ShapeType File "C:\Program Files\Thuban\Thuban\Model\postgisdb.py", line 472, in ShapeType return shapetype_map[result] KeyError: 'MULTIPOINT' -------------------------------------------- Managed by Request Tracker From bh at intevation.de Thu Apr 21 20:26:53 2005 From: bh at intevation.de (Bernhard Herzog) Date: Thu, 21 Apr 2005 20:26:53 +0200 Subject: Translating Shape Data to the Screen In-Reply-To: (Frederick C. Lee's message of "Fri, 15 Apr 2005 09:04:20 -0700") References: Message-ID: Frederick C.Lee writes: [...] > I need to know which > Thuban module actually translates the ShapLib coordinates into > on-screen coordinates. [...] > Which module actually does this? There are several places in the code, depending on which aspect of this translation you need. Most of the code is in Thuban/UI/renderer.py and Thuban/UI/baserenderer.py. For shapefiles in particular, there's also some C++ code in libraries/thuban/wxproj.cpp that reads the data from the shapefiles, transforms it and passes it to wxWidgets. > Also, any coordination code (and significance) between data from the > .dbf with .shp would be truly appreciated. Not sure what you're after here exactly. The code for the classifications is in the renderers mentioned above and in Thuban/Model/classification.py. Shapefile specific code is in Thuban/Model/data.py which provides some abstraction on top of shapelib. Bernhard -- Intevation GmbH http://intevation.de/ Skencil http://skencil.org/ Thuban http://thuban.intevation.org/ From bh at intevation.de Thu Apr 21 21:10:23 2005 From: bh at intevation.de (Bernhard Herzog) Date: Thu, 21 Apr 2005 21:10:23 +0200 Subject: russell: thuban/Thuban/UI view.py,1.64,1.65 In-Reply-To: <20050413160836.17A051005DA@lists.intevation.de> (cvs@intevation.de's message of "Wed, 13 Apr 2005 18:08:36 +0200 (CEST)") References: <20050413160836.17A051005DA@lists.intevation.de> Message-ID: cvs at intevation.de writes: > Author: russell > > Update of /thubanrepository/thuban/Thuban/UI > In directory doto:/tmp/cvs-serv13109/Thuban/UI > > Modified Files: > view.py > Log Message: > Fixing bug #2921, panning with middle button not working without active tool Thanks. Could you add the ChangeLog entry, too? Bernhard -- Intevation GmbH http://intevation.de/ Skencil http://skencil.org/ Thuban http://thuban.intevation.org/ From bh at intevation.de Fri Apr 22 21:06:21 2005 From: bh at intevation.de (Bernhard Herzog) Date: Fri, 22 Apr 2005 21:06:21 +0200 Subject: Introduce FileShapeStore In-Reply-To: <20050329182326.GB26855@intevation.de> (Jan-Oliver Wagner's message of "Tue, 29 Mar 2005 20:23:26 +0200") References: <20050308144426.GB18094@intevation.de> <20050308144530.GC18094@intevation.de> <20050329182326.GB26855@intevation.de> Message-ID: Jan-Oliver Wagner writes: > +class FileShapeStore: > + > + """The base class to derive any file-based ShapeStore from. > + > + This class contains all information that is needed by a > + loader routine to actually load the shapestore. > + This essentially means that the class contains all required information > + to save the shapestore specification (i.e. in a .thuban file). > + """ > + > + def __init__(self, filename, filetype, layername = None): > + """Initialize the base class with main parameters. > + > + filename -- the source filename. > + This filename will be converted to an absolute filename. > + The filename will be interpreted relative to that anyway, Relative to what? > + but when saving a session we need to compare absolute paths > + and it's usually safer to always work with absolute paths. > + filetype -- The type of the filename. > + Known and used types are: "shapefile" AFAICT the filetype will be the same for all instances of a class, so I guess it should be a class attribute that has to be defined by the derived classes. There's no need to pass it as a parameter to the constructor. > + layername -- a string representing a layer within the file shape store. > + Some file formats support to contain several layers, or > + at least the ogr library says so. > + For those filetypes who don't, the layername can be ignored > + and by default it is None. Would it make sense to call it something other than layername? We already have a layer in thuban and it has a somewhat different meaning. > + def layer_name(self): This should be spelled LayerName to follow the naming scheme of the other public methods. (assuming the method is to be public). > @@ -148,22 +225,10 @@ class ShapefileStore: > self.shapetree = shptree.SHPTree(self.shapefile.cobject(), 2, > maxdepth) > > - def Table(self): > - """Return the table containing the attribute data""" > - return self.table > - [...] > > @@ -186,6 +251,10 @@ class ShapefileStore: > """ > return () > > + def Table(self): > + """Return the table containing the attribute data.""" > + return self._table > + I think we should avoid moving the methods around unnecessarily, if possible. The same applies to BoundingBox. Bernhard -- Intevation GmbH http://intevation.de/ Skencil http://skencil.org/ Thuban http://thuban.intevation.org/ From cvs at intevation.de Sat Apr 23 07:34:55 2005 From: cvs at intevation.de (cvs@intevation.de) Date: Sat, 23 Apr 2005 07:34:55 +0200 (CEST) Subject: russell: thuban ChangeLog,1.803,1.804 Message-ID: <20050423053455.42C861005D7@lists.intevation.de> Author: russell Update of /thubanrepository/thuban In directory doto:/tmp/cvs-serv29140 Modified Files: ChangeLog Log Message: Fixing bug #2921, panning with middle button not working without active tool Index: ChangeLog =================================================================== RCS file: /thubanrepository/thuban/ChangeLog,v retrieving revision 1.803 retrieving revision 1.804 diff -u -d -r1.803 -r1.804 --- ChangeLog 11 Apr 2005 18:18:08 -0000 1.803 +++ ChangeLog 23 Apr 2005 05:34:52 -0000 1.804 @@ -1,3 +1,8 @@ +2005-04-23 Russell Nelson + + * Changed the way the previous tool is remembered, so that + middle-button panning works even if you haven't selected a tool. + 2005-04-11 Bernhard Herzog * libraries/thuban/wxproj.cpp: Move the compatibility code that From cvs at intevation.de Sat Apr 23 18:40:35 2005 From: cvs at intevation.de (cvs@intevation.de) Date: Sat, 23 Apr 2005 18:40:35 +0200 (CEST) Subject: joey: thuban/Thuban/UI renderer.py,1.59,1.60 Message-ID: <20050423164035.C8F86101FB1@lists.intevation.de> Author: joey Update of /thubanrepository/thuban/Thuban/UI In directory doto:/tmp/cvs-serv7486 Modified Files: renderer.py Log Message: Added a missing import Index: renderer.py =================================================================== RCS file: /thubanrepository/thuban/Thuban/UI/renderer.py,v retrieving revision 1.59 retrieving revision 1.60 diff -u -d -r1.59 -r1.60 --- renderer.py 23 Mar 2005 15:30:27 -0000 1.59 +++ renderer.py 23 Apr 2005 16:40:33 -0000 1.60 @@ -18,6 +18,8 @@ import array +import traceback + from Thuban import _ from wxPython.wx import wxPoint, wxRect, wxPen, wxBrush, wxFont, \ From cvs at intevation.de Mon Apr 25 17:01:50 2005 From: cvs at intevation.de (cvs@intevation.de) Date: Mon, 25 Apr 2005 17:01:50 +0200 (CEST) Subject: joey: thuban/Thuban/UI renderer.py,1.60,1.61 Message-ID: <20050425150150.A78471005A0@lists.intevation.de> Author: joey Update of /thubanrepository/thuban/Thuban/UI In directory doto:/tmp/cvs-serv13714 Modified Files: renderer.py Log Message: Added a description according to the CVS log message Index: renderer.py =================================================================== RCS file: /thubanrepository/thuban/Thuban/UI/renderer.py,v retrieving revision 1.60 retrieving revision 1.61 diff -u -d -r1.60 -r1.61 --- renderer.py 23 Apr 2005 16:40:33 -0000 1.60 +++ renderer.py 25 Apr 2005 15:01:48 -0000 1.61 @@ -117,6 +117,11 @@ def projected_raster_layer(self, layer, srcProj, dstProj, extents, resolution, dimensions, options): + """Returns a raster layer image in projected space + + Based on a given filename. This method must be implemented in + classes derived from BaseRenderer. + """ ret = None From jan at intevation.de Mon Apr 25 18:00:05 2005 From: jan at intevation.de (Jan-Oliver Wagner) Date: Mon, 25 Apr 2005 18:00:05 +0200 Subject: Introduce FileShapeStore In-Reply-To: References: <20050308144426.GB18094@intevation.de> <20050308144530.GC18094@intevation.de> <20050329182326.GB26855@intevation.de> Message-ID: <20050425160005.GA16364@intevation.de> On Fri, Apr 22, 2005 at 09:06:21PM +0200, Bernhard Herzog wrote: > Jan-Oliver Wagner writes: > > @@ -186,6 +251,10 @@ class ShapefileStore: > > """ > > return () > > > > + def Table(self): > > + """Return the table containing the attribute data.""" > > + return self._table > > + > > I think we should avoid moving the methods around unnecessarily, if > possible. The same applies to BoundingBox. do you mean my renaming table to _table and bbox to _bbox? I felt this necessary for myself to easier identify only internally used variables. Jan -- Jan-Oliver Wagner http://intevation.de/~jan/ Intevation GmbH http://intevation.de/ FreeGIS http://freegis.org/ From bh at intevation.de Mon Apr 25 18:03:00 2005 From: bh at intevation.de (Bernhard Herzog) Date: Mon, 25 Apr 2005 18:03:00 +0200 Subject: Introduce FileShapeStore In-Reply-To: <20050425160005.GA16364@intevation.de> (Jan-Oliver Wagner's message of "Mon, 25 Apr 2005 18:00:05 +0200") References: <20050308144426.GB18094@intevation.de> <20050308144530.GC18094@intevation.de> <20050329182326.GB26855@intevation.de> <20050425160005.GA16364@intevation.de> Message-ID: Jan-Oliver Wagner writes: > On Fri, Apr 22, 2005 at 09:06:21PM +0200, Bernhard Herzog wrote: >> Jan-Oliver Wagner writes: >> > @@ -186,6 +251,10 @@ class ShapefileStore: >> > """ >> > return () >> > >> > + def Table(self): >> > + """Return the table containing the attribute data.""" >> > + return self._table >> > + >> >> I think we should avoid moving the methods around unnecessarily, if >> possible. The same applies to BoundingBox. > > do you mean my renaming table to _table and bbox to _bbox? The patch removes the Table method in one place and adds it in another. That distracts from the fact that the instance variable is renamed. Bernhard -- Intevation GmbH http://intevation.de/ Skencil http://skencil.org/ Thuban http://thuban.intevation.org/ From jan at intevation.de Tue Apr 26 15:42:16 2005 From: jan at intevation.de (Jan-Oliver Wagner) Date: Tue, 26 Apr 2005 15:42:16 +0200 Subject: Introduce FileShapeStore In-Reply-To: References: <20050308144426.GB18094@intevation.de> <20050308144530.GC18094@intevation.de> <20050329182326.GB26855@intevation.de> <20050425160005.GA16364@intevation.de> Message-ID: <20050426134216.GA2854@intevation.de> On Mon, Apr 25, 2005 at 06:03:00PM +0200, Bernhard Herzog wrote: > Jan-Oliver Wagner writes: > > On Fri, Apr 22, 2005 at 09:06:21PM +0200, Bernhard Herzog wrote: > >> Jan-Oliver Wagner writes: > >> > @@ -186,6 +251,10 @@ class ShapefileStore: > >> > """ > >> > return () > >> > > >> > + def Table(self): > >> > + """Return the table containing the attribute data.""" > >> > + return self._table > >> > + > >> > >> I think we should avoid moving the methods around unnecessarily, if > >> possible. The same applies to BoundingBox. > > > > do you mean my renaming table to _table and bbox to _bbox? > > The patch removes the Table method in one place and adds it in another. > That distracts from the fact that the instance variable is renamed. ah, OK. That was due to itertive adaption of the patch. And here comes trial number 3. This one OK for checkin? Best Jan -- Jan-Oliver Wagner http://intevation.de/~jan/ Intevation GmbH http://intevation.de/ FreeGIS http://freegis.org/ -------------- next part -------------- Index: data.py =================================================================== RCS file: /thubanrepository/thuban/Thuban/Model/data.py,v retrieving revision 1.15 diff -u -3 -p -r1.15 data.py --- data.py 24 Nov 2003 19:23:08 -0000 1.15 +++ data.py 26 Apr 2005 13:38:37 -0000 @@ -1,4 +1,4 @@ -# Copyright (C) 2003 by Intevation GmbH +# Copyright (C) 2003, 2005 by Intevation GmbH # Authors: # Bernhard Herzog # @@ -112,29 +112,104 @@ class ShapeTable(transientdb.AutoTransie """Return a tuple containing the shapestore""" return (self.store(),) +# XXX: (this statement should be kept in mind when re-engeneering) +# +# From a desing POV it was wrong to distinguish between table and +# shapestore. In hindsight the only reason for doing so was that the +# shapelib has different objects for the shapefile(s) and the dbf file, +# which of course matches the way the data is organized into different +# files. So the distinction between shapestore and table is an artifact +# of the shapefile format. When we added the postgis support we should +# have adopted the table interface for the entire shape store, making the +# geometry data an additional column for those shape stores that don't +# store the geometries in columns in the first place. + +class FileShapeStore: + + """The base class to derive any file-based ShapeStore from. + + This class contains all information that is needed by a + loader routine to actually load the shapestore. + This essentially means that the class contains all required information + to save the shapestore specification (i.e. in a .thuban file). + """ + + def __init__(self, filename, sublayer_name = None): + """Initialize the base class with main parameters. + + filename -- the source filename. + This filename will be converted to an absolute filename. + The filename will be interpreted relative to the .thuban file anyway, + but when saving a session we need to compare absolute paths + and it's usually safer to always work with absolute paths. + sublayer_name -- a string representing a layer within the file shape store. + Some file formats support to contain several layers, or + at least the ogr library says so. + For those filetypes who don't, the sublayer_name can be ignored + and by default it is None. + """ + self._filename = os.path.abspath(filename) + self._sublayer_name = sublayer_name + + def FileName(self): + """Return the filename used to open the shapestore. + + The filename can only be set via __init__ method. + """ + return self._filename + + def FileType(self): + """Return the filetype. + + The filetype has to be set in all derived classes. + It must be string. + Known and used types are: "shapefile" + """ + raise NotImplementedError -class ShapefileStore: + def SublayerName(self): + """Return the sublayer_name. + + This could be None if the shapestore type only supports a single + layer. + """ + return self._sublayer_name + + # Design/Implementation note: + # It is not a good idea to have a implementation for a + # "setBoundingBox" or BoundingBox # in this base class. + # In future this data might change during + # a Thuban session and thus can not be kept statically here. + # It is expected that for many derived classes the bbox must + # be retrieved each time anew. + + def BoundingBox(self): + """Return the bounding box of the shapes in the shape store. + + The coordinate system used is whatever was used in the shape store. + If the shape store is empty, return None. + """ + raise NotImplementedError + +class ShapefileStore(FileShapeStore): """Combine a shapefile and the corresponding DBF file into one object""" def __init__(self, session, filename): - # Make the filename absolute. The filename will be - # interpreted relative to that anyway, but when saving a - # session we need to compare absolute paths and it's usually - # safer to always work with absolute paths. - self.filename = os.path.abspath(filename) + FileShapeStore.__init__(self, filename) self.dbftable = table.DBFTable(filename) - self.table = ShapeTable(self, session.TransientDB(), self.dbftable) + self._table = ShapeTable(self, session.TransientDB(), self.dbftable) + self._bbox = None self._open_shapefile() def _open_shapefile(self): - self.shapefile = shapelib.ShapeFile(self.filename) + self.shapefile = shapelib.ShapeFile(self.FileName()) self.numshapes, shapetype, mins, maxs = self.shapefile.info() if self.numshapes: - self.bbox = mins[:2] + maxs[:2] + self._bbox = mins[:2] + maxs[:2] else: - self.bbox = None + self._bbox = None self.shapetype = shapelib_shapetypes[shapetype] # estimate a good depth for the quad tree. Each depth multiplies @@ -149,19 +224,20 @@ class ShapefileStore: maxdepth) def Table(self): - """Return the table containing the attribute data""" - return self.table + """Return the table containing the attribute data.""" + return self._table def Shapefile(self): """Return the shapefile object""" return self.shapefile - def FileName(self): - """Return the filename used to open the shapefile""" - return self.filename - def FileType(self): - """Return the filetype. This is always the string 'shapefile'""" + """Return the filetype. + + The filetype has to be set in all derived classes. + It must be string. + Known and used types are: "shapefile" + """ return "shapefile" def ShapeType(self): @@ -194,12 +270,12 @@ class ShapefileStore: return None def BoundingBox(self): - """Return the bounding box of the shapes in the shapestore. + """Return the bounding box of the shapes in the shape store. - The coordinate system used is whatever was used in the shapefile. - If the shapefile is empty, return None. + The coordinate system used is whatever was used in the shape store. + If the shape store is empty, return None. """ - return self.bbox + return self._bbox def ShapesInRegion(self, bbox): """Return an iterable over the shapes that overlap the bounding box. @@ -224,7 +300,6 @@ class ShapefileStore: def Shape(self, index): """Return the shape with index index""" return ShapefileShape(self.shapefile, index) - class DerivedShapeStore: Index: save.py =================================================================== RCS file: /thubanrepository/thuban/Thuban/Model/save.py,v retrieving revision 1.43 diff -u -3 -p -r1.43 save.py --- save.py 28 Jan 2005 15:54:00 -0000 1.43 +++ save.py 26 Apr 2005 13:38:37 -0000 @@ -26,7 +26,7 @@ from Thuban.Model.classification import ClassGroupDefault, ClassGroupSingleton, ClassGroupRange, ClassGroupMap from Thuban.Model.transientdb import AutoTransientTable, TransientJoinedTable from Thuban.Model.table import DBFTable, FIELDTYPE_STRING -from Thuban.Model.data import DerivedShapeStore, ShapefileStore, \ +from Thuban.Model.data import DerivedShapeStore, FileShapeStore, \ SHAPETYPE_POINT from Thuban.Model.xmlwriter import XMLWriter @@ -201,12 +201,12 @@ class SessionSaver(XMLWriter): continue idvalue = self.define_id(container) - if isinstance(container, ShapefileStore): + if isinstance(container, FileShapeStore): self.define_id(container.Table(), idvalue) filename = self.prepare_filename(container.FileName()) self.write_element("fileshapesource", {"id": idvalue, "filename": filename, - "filetype": "shapefile"}) + "filetype": container.FileType()}) elif isinstance(container, DerivedShapeStore): shapesource, table = container.Dependencies() self.write_element("derivedshapesource", From bh at intevation.de Tue Apr 26 15:49:26 2005 From: bh at intevation.de (Bernhard Herzog) Date: Tue, 26 Apr 2005 15:49:26 +0200 Subject: Introduce FileShapeStore In-Reply-To: <20050426134216.GA2854@intevation.de> (Jan-Oliver Wagner's message of "Tue, 26 Apr 2005 15:42:16 +0200") References: <20050308144426.GB18094@intevation.de> <20050308144530.GC18094@intevation.de> <20050329182326.GB26855@intevation.de> <20050425160005.GA16364@intevation.de> <20050426134216.GA2854@intevation.de> Message-ID: Jan-Oliver Wagner writes: > +class ShapefileStore(FileShapeStore): > [...] > def FileType(self): > - """Return the filetype. This is always the string 'shapefile'""" > + """Return the filetype. > + > + The filetype has to be set in all derived classes. > + It must be string. > + Known and used types are: "shapefile" > + """ Why did you copy the doc-string from the base class where it describes the abstract purpose of the method to a specific implementation? Now the doc-string of the specific implementation doesn't say anything about that particular implementation anymore. The original doc-string would have been just fine, IMO. Bernhard -- Intevation GmbH http://intevation.de/ Skencil http://skencil.org/ Thuban http://thuban.intevation.org/ From jan at intevation.de Tue Apr 26 15:55:38 2005 From: jan at intevation.de (Jan-Oliver Wagner) Date: Tue, 26 Apr 2005 15:55:38 +0200 Subject: Introduce FileShapeStore In-Reply-To: References: <20050308144426.GB18094@intevation.de> <20050308144530.GC18094@intevation.de> <20050329182326.GB26855@intevation.de> <20050425160005.GA16364@intevation.de> <20050426134216.GA2854@intevation.de> Message-ID: <20050426135538.GB2890@intevation.de> On Tue, Apr 26, 2005 at 03:49:26PM +0200, Bernhard Herzog wrote: > Jan-Oliver Wagner writes: > > > +class ShapefileStore(FileShapeStore): > > > [...] > > def FileType(self): > > - """Return the filetype. This is always the string 'shapefile'""" > > + """Return the filetype. > > + > > + The filetype has to be set in all derived classes. > > + It must be string. > > + Known and used types are: "shapefile" > > + """ > > Why did you copy the doc-string from the base class where it describes > the abstract purpose of the method to a specific implementation? Now > the doc-string of the specific implementation doesn't say anything about > that particular implementation anymore. The original doc-string would > have been just fine, IMO. that was not intentionally. Here is round number 4. Jan -- Jan-Oliver Wagner http://intevation.de/~jan/ Intevation GmbH http://intevation.de/ FreeGIS http://freegis.org/ -------------- next part -------------- Index: data.py =================================================================== RCS file: /thubanrepository/thuban/Thuban/Model/data.py,v retrieving revision 1.15 diff -u -3 -p -r1.15 data.py --- data.py 24 Nov 2003 19:23:08 -0000 1.15 +++ data.py 26 Apr 2005 13:54:12 -0000 @@ -1,4 +1,4 @@ -# Copyright (C) 2003 by Intevation GmbH +# Copyright (C) 2003, 2005 by Intevation GmbH # Authors: # Bernhard Herzog # @@ -112,29 +112,104 @@ class ShapeTable(transientdb.AutoTransie """Return a tuple containing the shapestore""" return (self.store(),) +# XXX: (this statement should be kept in mind when re-engeneering) +# +# From a desing POV it was wrong to distinguish between table and +# shapestore. In hindsight the only reason for doing so was that the +# shapelib has different objects for the shapefile(s) and the dbf file, +# which of course matches the way the data is organized into different +# files. So the distinction between shapestore and table is an artifact +# of the shapefile format. When we added the postgis support we should +# have adopted the table interface for the entire shape store, making the +# geometry data an additional column for those shape stores that don't +# store the geometries in columns in the first place. + +class FileShapeStore: + + """The base class to derive any file-based ShapeStore from. + + This class contains all information that is needed by a + loader routine to actually load the shapestore. + This essentially means that the class contains all required information + to save the shapestore specification (i.e. in a .thuban file). + """ + + def __init__(self, filename, sublayer_name = None): + """Initialize the base class with main parameters. + + filename -- the source filename. + This filename will be converted to an absolute filename. + The filename will be interpreted relative to the .thuban file anyway, + but when saving a session we need to compare absolute paths + and it's usually safer to always work with absolute paths. + sublayer_name -- a string representing a layer within the file shape store. + Some file formats support to contain several layers, or + at least the ogr library says so. + For those filetypes who don't, the sublayer_name can be ignored + and by default it is None. + """ + self._filename = os.path.abspath(filename) + self._sublayer_name = sublayer_name + + def FileName(self): + """Return the filename used to open the shapestore. + + The filename can only be set via __init__ method. + """ + return self._filename + + def FileType(self): + """Return the filetype. + + The filetype has to be set in all derived classes. + It must be string. + Known and used types are: "shapefile" + """ + raise NotImplementedError + + def SublayerName(self): + """Return the sublayer_name. + + This could be None if the shapestore type only supports a single + layer. + """ + return self._sublayer_name + + # Design/Implementation note: + # It is not a good idea to have a implementation for a + # "setBoundingBox" or BoundingBox # in this base class. + # In future this data might change during + # a Thuban session and thus can not be kept statically here. + # It is expected that for many derived classes the bbox must + # be retrieved each time anew. + + def BoundingBox(self): + """Return the bounding box of the shapes in the shape store. + + The coordinate system used is whatever was used in the shape store. + If the shape store is empty, return None. + """ + raise NotImplementedError -class ShapefileStore: +class ShapefileStore(FileShapeStore): """Combine a shapefile and the corresponding DBF file into one object""" def __init__(self, session, filename): - # Make the filename absolute. The filename will be - # interpreted relative to that anyway, but when saving a - # session we need to compare absolute paths and it's usually - # safer to always work with absolute paths. - self.filename = os.path.abspath(filename) + FileShapeStore.__init__(self, filename) self.dbftable = table.DBFTable(filename) - self.table = ShapeTable(self, session.TransientDB(), self.dbftable) + self._table = ShapeTable(self, session.TransientDB(), self.dbftable) + self._bbox = None self._open_shapefile() def _open_shapefile(self): - self.shapefile = shapelib.ShapeFile(self.filename) + self.shapefile = shapelib.ShapeFile(self.FileName()) self.numshapes, shapetype, mins, maxs = self.shapefile.info() if self.numshapes: - self.bbox = mins[:2] + maxs[:2] + self._bbox = mins[:2] + maxs[:2] else: - self.bbox = None + self._bbox = None self.shapetype = shapelib_shapetypes[shapetype] # estimate a good depth for the quad tree. Each depth multiplies @@ -149,17 +224,13 @@ class ShapefileStore: maxdepth) def Table(self): - """Return the table containing the attribute data""" - return self.table + """Return the table containing the attribute data.""" + return self._table def Shapefile(self): """Return the shapefile object""" return self.shapefile - def FileName(self): - """Return the filename used to open the shapefile""" - return self.filename - def FileType(self): """Return the filetype. This is always the string 'shapefile'""" return "shapefile" @@ -194,12 +265,12 @@ class ShapefileStore: return None def BoundingBox(self): - """Return the bounding box of the shapes in the shapestore. + """Return the bounding box of the shapes in the shape store. - The coordinate system used is whatever was used in the shapefile. - If the shapefile is empty, return None. + The coordinate system used is whatever was used in the shape store. + If the shape store is empty, return None. """ - return self.bbox + return self._bbox def ShapesInRegion(self, bbox): """Return an iterable over the shapes that overlap the bounding box. @@ -224,7 +295,6 @@ class ShapefileStore: def Shape(self, index): """Return the shape with index index""" return ShapefileShape(self.shapefile, index) - class DerivedShapeStore: Index: save.py =================================================================== RCS file: /thubanrepository/thuban/Thuban/Model/save.py,v retrieving revision 1.43 diff -u -3 -p -r1.43 save.py --- save.py 28 Jan 2005 15:54:00 -0000 1.43 +++ save.py 26 Apr 2005 13:54:12 -0000 @@ -26,7 +26,7 @@ from Thuban.Model.classification import ClassGroupDefault, ClassGroupSingleton, ClassGroupRange, ClassGroupMap from Thuban.Model.transientdb import AutoTransientTable, TransientJoinedTable from Thuban.Model.table import DBFTable, FIELDTYPE_STRING -from Thuban.Model.data import DerivedShapeStore, ShapefileStore, \ +from Thuban.Model.data import DerivedShapeStore, FileShapeStore, \ SHAPETYPE_POINT from Thuban.Model.xmlwriter import XMLWriter @@ -201,12 +201,12 @@ class SessionSaver(XMLWriter): continue idvalue = self.define_id(container) - if isinstance(container, ShapefileStore): + if isinstance(container, FileShapeStore): self.define_id(container.Table(), idvalue) filename = self.prepare_filename(container.FileName()) self.write_element("fileshapesource", {"id": idvalue, "filename": filename, - "filetype": "shapefile"}) + "filetype": container.FileType()}) elif isinstance(container, DerivedShapeStore): shapesource, table = container.Dependencies() self.write_element("derivedshapesource", From bh at intevation.de Tue Apr 26 15:59:36 2005 From: bh at intevation.de (Bernhard Herzog) Date: Tue, 26 Apr 2005 15:59:36 +0200 Subject: Introduce FileShapeStore In-Reply-To: <20050426135538.GB2890@intevation.de> (Jan-Oliver Wagner's message of "Tue, 26 Apr 2005 15:55:38 +0200") References: <20050308144426.GB18094@intevation.de> <20050308144530.GC18094@intevation.de> <20050329182326.GB26855@intevation.de> <20050425160005.GA16364@intevation.de> <20050426134216.GA2854@intevation.de> <20050426135538.GB2890@intevation.de> Message-ID: Jan-Oliver Wagner writes: > def BoundingBox(self): > - """Return the bounding box of the shapes in the shapestore. > + """Return the bounding box of the shapes in the shape store. > > - The coordinate system used is whatever was used in the shapefile. > - If the shapefile is empty, return None. > + The coordinate system used is whatever was used in the shape store. > + If the shape store is empty, return None. Didn't notice this earlier: there is a reason the doc-string said "shapefile". This is in the ShapefileStore so the coordinate system is whatever is used in the underlying shapefile. Other than that, check it in already :) Bernhard -- Intevation GmbH http://intevation.de/ Skencil http://skencil.org/ Thuban http://thuban.intevation.org/ From cvs at intevation.de Tue Apr 26 17:04:24 2005 From: cvs at intevation.de (cvs@intevation.de) Date: Tue, 26 Apr 2005 17:04:24 +0200 (CEST) Subject: joey: thuban/Extensions/wms wms.py,1.12,1.13 Message-ID: <20050426150424.97E581005D0@lists.intevation.de> Author: joey Update of /thubanrepository/thuban/Extensions/wms In directory doto:/tmp/cvs-serv7512 Modified Files: wms.py Log Message: Adjusted the render function to the modified render engine Index: wms.py =================================================================== RCS file: /thubanrepository/thuban/Extensions/wms/wms.py,v retrieving revision 1.12 retrieving revision 1.13 diff -u -d -r1.12 -r1.13 --- wms.py 20 Nov 2004 21:26:35 -0000 1.12 +++ wms.py 26 Apr 2005 15:04:22 -0000 1.13 @@ -54,7 +54,10 @@ ymax = (offy - 0) / scale img, format = layer.GetMapImg(width, height, (xmin, ymin, xmax, ymax)) - renderer.draw_raster_data(img, format) + + data = (width, height, (img, None, None)) + + renderer.draw_raster_data(layer, 0,0, data, format) return () From cvs at intevation.de Tue Apr 26 17:05:22 2005 From: cvs at intevation.de (cvs@intevation.de) Date: Tue, 26 Apr 2005 17:05:22 +0200 (CEST) Subject: joey: thuban ChangeLog,1.804,1.805 Message-ID: <20050426150522.0FDB81005D0@lists.intevation.de> Author: joey Update of /thubanrepository/thuban In directory doto:/tmp/cvs-serv7546 Modified Files: ChangeLog Log Message: Updated the changelog file Index: ChangeLog =================================================================== RCS file: /thubanrepository/thuban/ChangeLog,v retrieving revision 1.804 retrieving revision 1.805 diff -u -d -r1.804 -r1.805 --- ChangeLog 23 Apr 2005 05:34:52 -0000 1.804 +++ ChangeLog 26 Apr 2005 15:05:19 -0000 1.805 @@ -1,3 +1,17 @@ +2005-04-26 Martin Schulze + + * Extensions/wms/wms.py (render_wms_layer): Adjusted the render + function to the modified render engine + +2005-04-25 Martin Schulze + + * Thuban/UI/renderer.py (MapRenderer.projected_raster_layer): + Added a description according to the CVS log message + +2005-04-23 Martin Schulze + + * Thuban/UI/renderer.py: Added a missing import + 2005-04-23 Russell Nelson * Changed the way the previous tool is remembered, so that From cvs at intevation.de Wed Apr 27 13:04:58 2005 From: cvs at intevation.de (cvs@intevation.de) Date: Wed, 27 Apr 2005 13:04:58 +0200 (CEST) Subject: jan: thuban/Thuban/Model data.py,1.15,1.16 Message-ID: <20050427110458.4880B100167@lists.intevation.de> Author: jan Update of /thubanrepository/thuban/Thuban/Model In directory doto:/tmp/cvs-serv29205 Modified Files: data.py Log Message: Various small fixes in doc-strings. (FileShapeStore): New class. (ShapefileStore): Derive from FileShapeStore. (ShapefileStore.__init__): Call __init__ of FileShapeStore, rename self.table to self._table, initialize self._bbox (ShapefileStore._open_shapefile): Use self._bbox instead of self.bbox and self.FileName() instead of self.filename. (ShapefileStore.Table): Use self._table instead of self.table. (ShapefileStore.FileName): Removed (moved to FileShapeStore). (ShapefileStore.BoundingBox): Use self._bbox instead of self.bbox. Index: data.py =================================================================== RCS file: /thubanrepository/thuban/Thuban/Model/data.py,v retrieving revision 1.15 retrieving revision 1.16 diff -u -d -r1.15 -r1.16 --- data.py 24 Nov 2003 19:23:08 -0000 1.15 +++ data.py 27 Apr 2005 11:04:56 -0000 1.16 @@ -1,4 +1,4 @@ -# Copyright (C) 2003 by Intevation GmbH +# Copyright (C) 2003, 2005 by Intevation GmbH # Authors: # Bernhard Herzog # @@ -112,29 +112,104 @@ """Return a tuple containing the shapestore""" return (self.store(),) +# XXX: (this statement should be kept in mind when re-engeneering) +# +# From a desing POV it was wrong to distinguish between table and +# shapestore. In hindsight the only reason for doing so was that the +# shapelib has different objects for the shapefile(s) and the dbf file, +# which of course matches the way the data is organized into different +# files. So the distinction between shapestore and table is an artifact +# of the shapefile format. When we added the postgis support we should +# have adopted the table interface for the entire shape store, making the +# geometry data an additional column for those shape stores that don't +# store the geometries in columns in the first place. -class ShapefileStore: +class FileShapeStore: + + """The base class to derive any file-based ShapeStore from. + + This class contains all information that is needed by a + loader routine to actually load the shapestore. + This essentially means that the class contains all required information + to save the shapestore specification (i.e. in a .thuban file). + """ + + def __init__(self, filename, sublayer_name = None): + """Initialize the base class with main parameters. + + filename -- the source filename. + This filename will be converted to an absolute filename. + The filename will be interpreted relative to the .thuban file anyway, + but when saving a session we need to compare absolute paths + and it's usually safer to always work with absolute paths. + sublayer_name -- a string representing a layer within the file shape store. + Some file formats support to contain several layers, or + at least the ogr library says so. + For those filetypes who don't, the sublayer_name can be ignored + and by default it is None. + """ + self._filename = os.path.abspath(filename) + self._sublayer_name = sublayer_name + + def FileName(self): + """Return the filename used to open the shapestore. + + The filename can only be set via __init__ method. + """ + return self._filename + + def FileType(self): + """Return the filetype. + + The filetype has to be set in all derived classes. + It must be string. + Known and used types are: "shapefile" + """ + raise NotImplementedError + + def SublayerName(self): + """Return the sublayer_name. + + This could be None if the shapestore type only supports a single + layer. + """ + return self._sublayer_name + + # Design/Implementation note: + # It is not a good idea to have a implementation for a + # "setBoundingBox" or BoundingBox in this base class. + # In future this data might change during + # a Thuban session and thus can not be kept statically here. + # It is expected that for many derived classes the bbox must + # be retrieved each time anew. + + def BoundingBox(self): + """Return the bounding box of the shapes in the shape store. + + The coordinate system used is whatever was used in the shape store. + If the shape store is empty, return None. + """ + raise NotImplementedError + +class ShapefileStore(FileShapeStore): """Combine a shapefile and the corresponding DBF file into one object""" def __init__(self, session, filename): - # Make the filename absolute. The filename will be - # interpreted relative to that anyway, but when saving a - # session we need to compare absolute paths and it's usually - # safer to always work with absolute paths. - self.filename = os.path.abspath(filename) + FileShapeStore.__init__(self, filename) self.dbftable = table.DBFTable(filename) - self.table = ShapeTable(self, session.TransientDB(), self.dbftable) + self._table = ShapeTable(self, session.TransientDB(), self.dbftable) + self._bbox = None self._open_shapefile() def _open_shapefile(self): - self.shapefile = shapelib.ShapeFile(self.filename) + self.shapefile = shapelib.ShapeFile(self.FileName()) self.numshapes, shapetype, mins, maxs = self.shapefile.info() if self.numshapes: - self.bbox = mins[:2] + maxs[:2] + self._bbox = mins[:2] + maxs[:2] else: - self.bbox = None + self._bbox = None self.shapetype = shapelib_shapetypes[shapetype] # estimate a good depth for the quad tree. Each depth multiplies @@ -149,17 +224,13 @@ maxdepth) def Table(self): - """Return the table containing the attribute data""" - return self.table + """Return the table containing the attribute data.""" + return self._table def Shapefile(self): """Return the shapefile object""" return self.shapefile - def FileName(self): - """Return the filename used to open the shapefile""" - return self.filename - def FileType(self): """Return the filetype. This is always the string 'shapefile'""" return "shapefile" @@ -176,7 +247,7 @@ return RAW_SHAPEFILE def NumShapes(self): - """Return the number of shapes in the shape store""" + """Return the number of shapes in the shapefile""" return self.numshapes def Dependencies(self): @@ -194,19 +265,19 @@ return None def BoundingBox(self): - """Return the bounding box of the shapes in the shapestore. + """Return the bounding box of the shapes in the shapefile. The coordinate system used is whatever was used in the shapefile. - If the shapefile is empty, return None. + If the shapefileis empty, return None. """ - return self.bbox + return self._bbox def ShapesInRegion(self, bbox): """Return an iterable over the shapes that overlap the bounding box. The bbox parameter should be the bounding box as a tuple in the form (minx, miny, maxx, maxy) in the coordinate system of the - shape store. + shapefile. """ # Bind a few globals to locals to make it a bit faster cls = ShapefileShape @@ -217,7 +288,7 @@ yield cls(shapefile, i) def AllShapes(self): - """Return an iterable over the shapes in the shape store.""" + """Return an iterable over the shapes in the shapefile.""" for i in xrange(self.NumShapes()): yield ShapefileShape(self.shapefile, i) @@ -226,7 +297,6 @@ return ShapefileShape(self.shapefile, index) - class DerivedShapeStore: """A ShapeStore derived from other shapestores or tables""" @@ -279,7 +349,7 @@ return self.shapestore.ShapesInRegion(bbox) def AllShapes(self): - """Return an iterable over the shapes in the shape store. + """Return an iterable over the shapes in the shapefile. This method is simply delegated to the shapestore the DerivedShapeStore was instantiated with. From cvs at intevation.de Wed Apr 27 13:05:21 2005 From: cvs at intevation.de (cvs@intevation.de) Date: Wed, 27 Apr 2005 13:05:21 +0200 (CEST) Subject: jan: thuban/Thuban/Model save.py,1.43,1.44 Message-ID: <20050427110521.733C3100167@lists.intevation.de> Author: jan Update of /thubanrepository/thuban/Thuban/Model In directory doto:/tmp/cvs-serv29387 Modified Files: save.py Log Message: Replace ShapefileStore by FileShapeStore. (SessionSaver.write_data_containers): Only use methods of the base class FileShapeStore. Index: save.py =================================================================== RCS file: /thubanrepository/thuban/Thuban/Model/save.py,v retrieving revision 1.43 retrieving revision 1.44 diff -u -d -r1.43 -r1.44 --- save.py 28 Jan 2005 15:54:00 -0000 1.43 +++ save.py 27 Apr 2005 11:05:19 -0000 1.44 @@ -1,4 +1,4 @@ -# Copyright (c) 2001-2004 by Intevation GmbH +# Copyright (c) 2001-2005 by Intevation GmbH # Authors: # Jan-Oliver Wagner (2004) # Bernhard Herzog (2001-2004) @@ -26,7 +26,7 @@ ClassGroupDefault, ClassGroupSingleton, ClassGroupRange, ClassGroupMap from Thuban.Model.transientdb import AutoTransientTable, TransientJoinedTable from Thuban.Model.table import DBFTable, FIELDTYPE_STRING -from Thuban.Model.data import DerivedShapeStore, ShapefileStore, \ +from Thuban.Model.data import DerivedShapeStore, FileShapeStore, \ SHAPETYPE_POINT from Thuban.Model.xmlwriter import XMLWriter @@ -201,12 +201,12 @@ continue idvalue = self.define_id(container) - if isinstance(container, ShapefileStore): + if isinstance(container, FileShapeStore): self.define_id(container.Table(), idvalue) filename = self.prepare_filename(container.FileName()) self.write_element("fileshapesource", {"id": idvalue, "filename": filename, - "filetype": "shapefile"}) + "filetype": container.FileType()}) elif isinstance(container, DerivedShapeStore): shapesource, table = container.Dependencies() self.write_element("derivedshapesource", From cvs at intevation.de Wed Apr 27 13:07:17 2005 From: cvs at intevation.de (cvs@intevation.de) Date: Wed, 27 Apr 2005 13:07:17 +0200 (CEST) Subject: jan: thuban ChangeLog,1.805,1.806 Message-ID: <20050427110717.2D375100167@lists.intevation.de> Author: jan Update of /thubanrepository/thuban In directory doto:/tmp/cvs-serv29411 Modified Files: ChangeLog Log Message: Introduce FileShapeStore as generalization for file-based shape stores. In a first instance this allows additional modules to handle shapefile format as well, namely the OGR extension. Index: ChangeLog =================================================================== RCS file: /thubanrepository/thuban/ChangeLog,v retrieving revision 1.805 retrieving revision 1.806 diff -u -d -r1.805 -r1.806 --- ChangeLog 26 Apr 2005 15:05:19 -0000 1.805 +++ ChangeLog 27 Apr 2005 11:07:15 -0000 1.806 @@ -1,3 +1,25 @@ +2005-04-27 Jan-Oliver Wagner + + Introduce FileShapeStore as generalization for + file-based shape stores. In a first instance + this allows additional modules to handle shapefile + format as well, namely the OGR extension. + + * Thuban/Model/data.py: Various small fixes in doc-strings. + (FileShapeStore): New class. + (ShapefileStore): Derive from FileShapeStore. + (ShapefileStore.__init__): Call __init__ of FileShapeStore, + rename self.table to self._table, initialize self._bbox + (ShapefileStore._open_shapefile): Use self._bbox instead of self.bbox + and self.FileName() instead of self.filename. + (ShapefileStore.Table): Use self._table instead of self.table. + (ShapefileStore.FileName): Removed (moved to FileShapeStore). + (ShapefileStore.BoundingBox): Use self._bbox instead of self.bbox. + + * Thuban/Model/save.py: Replace ShapefileStore by FileShapeStore. + (SessionSaver.write_data_containers): Only use methods of the + base class FileShapeStore. + 2005-04-26 Martin Schulze * Extensions/wms/wms.py (render_wms_layer): Adjusted the render From cvs at intevation.de Thu Apr 28 11:39:10 2005 From: cvs at intevation.de (cvs@intevation.de) Date: Thu, 28 Apr 2005 11:39:10 +0200 (CEST) Subject: jan: thuban/Extensions/ogr ogrshapes.py,1.6,1.7 Message-ID: <20050428093910.4520D101F0F@lists.intevation.de> Author: jan Update of /thubanrepository/thuban/Extensions/ogr In directory doto:/tmp/cvs-serv31419 Modified Files: ogrshapes.py Log Message: (OGRFileShapeStore): New. This class ist to be used for any file-based shape stores accessed through OGR. Index: ogrshapes.py =================================================================== RCS file: /thubanrepository/thuban/Extensions/ogr/ogrshapes.py,v retrieving revision 1.6 retrieving revision 1.7 diff -u -d -r1.6 -r1.7 --- ogrshapes.py 4 Mar 2005 15:07:59 -0000 1.6 +++ ogrshapes.py 28 Apr 2005 09:39:08 -0000 1.7 @@ -25,6 +25,7 @@ from Thuban.Model.data import SHAPETYPE_POLYGON, SHAPETYPE_ARC, SHAPETYPE_POINT from Thuban.Model.data import RAW_PYTHON, RAW_SHAPEFILE, RAW_WKT +from Thuban.Model.data import FileShapeStore def has_ogr_support(): """Return whether this Thuban instance supports ogr file formats @@ -229,8 +230,16 @@ class OGRShapeStore: """Corresponds to an OGRLayer object, containing features/shapes and providing the same methods like ShapefileStore. + + In fact, for all file based shape stores, the class OGRFileShapeStore + should be used. Only database shape stores should be + used with OGRShapeStore. It is subject to re-factoring + to end up with better class names and sensible base classes. """ + # TODO: re-factor this class to be not responsible for file-based + # stores anymore. + def __init__(self, session, filename, layername, id_column = None): """Initialize the shapestore. @@ -414,6 +423,172 @@ """Return the id_column. """ return self.id_column + +class OGRFileShapeStore(FileShapeStore): + """Corresponds to an OGRLayer object, containing features/shapes and + providing the same methods like ShapefileStore. + """ + + def __init__(self, session, filename, layername, id_column = None): + """Initialize the shapestore. + + All required information is loaded from the datasource. + """ + self._bbox = None + self.ogrdatasource = ogr.Open(filename) + + # filetype is depending on the driver used to open the file. + self._filetype = self.ogrdatasource.GetDriver().GetName() + if self._filetype == 'ESRI Shapefile': + self._filetype = "shapefile" + FileShapeStore.__init__(self, filename, + sublayer_name = layername) + + self.ogrlayer = (self.ogrdatasource).GetLayerByName(layername) + + self._table = OGRTable(session, self.ogrdatasource, self.ogrlayer, + id_column) + + self._open_ogrlayer(layername) + + def _open_ogrlayer(self, layername): + """Get all required information from the datasource. + """ + self.numshapes = self.ogrlayer.GetFeatureCount() + self.shapetype = self.ogrlayer.GetLayerDefn().GetGeomType() + + extent = self.ogrlayer.GetExtent() + if extent: + self._bbox = [extent[0], extent[2], extent[1], extent[3]] + else: + self._bbox = None + + try: + self.shapetype = ogrlib_shapetypes[self.shapetype] + except: + # if shapetype is not contained in ogrlib_shapetypes + # treat it like SHAPETYPE_UNKNOWN + self.shapetype = ogrlib_shapetypes[ogr.wkbUnknown] + + self.shapes = self.shapes() + + def FileType(self): + """Return the filetype.""" + return self._filetype + + def BoundingBox(self): + """Return the bounding box of the shapes in the shape file. + + The coordinate system used is whatever was used in the shape file. + If the shape file is empty, return None. + """ + return self._bbox + + def shapes(self): + """Return a collection of all features as OGRShape objects. + """ + shapes = {} + self.ogrlayer.ResetReading() + + nextFeature = self.ogrlayer.GetNextFeature() + while nextFeature is not None: + fid = nextFeature.GetFID() + shape = OGRShape(self, nextFeature) + shapes[shape.ShapeID()] = shape + nextFeature = self.ogrlayer.GetNextFeature() + + return shapes + + def OGRLayer(self): + """Return the OGRLayer object + """ + return self.ogrlayer + + def ShapeType(self): + """Return the type of the shapes in the shapestore. + + This is either SHAPETYPE_POINT, SHAPETYPE_ARC, SHAPETYPE_POLYGON, + SHAEPTYPE_GEOMCOLL, SHAPETYPE_NONE or SHAPETYPE_UNKNOWN. + """ + return self.shapetype + + def RawShapeFormat(self): + """Return the raw data format of the shape data, i.e. RAW_PYTHON + """ + return RAW_PYTHON + + def NumShapes(self): + """Return the number of shapes in the shape store + """ + return self.numshapes + + def ShapesInRegion(self, bbox): + """Return an iterable over the shapes that overlap the bounding box. + + The bbox parameter should be the bounding box as a tuple in the + form (minx, miny, maxx, maxy) in the coordinate system of the + shape store. + """ + left, bottom, right, top = bbox + + # create a geometry which can be passed to the layer as spatial filter + bboxpolygon = ogr.CreateGeometryFromWkt( + ('Polygon((%s %s, %s %s, %s %s,%s %s, %s %s))' + %(left, bottom, left, top, right, top, + right, bottom, left, bottom))) + + if self.ogrlayer.GetSpatialRef(): + bboxpolygon.AssignSpatialReference(self.ogrlayer.GetSpatialRef()) + + self.ogrlayer.ResetReading() + #ogrlayer.SetSpatialFilterRect(left, bottom, right, top) + self.ogrlayer.SetSpatialFilter(bboxpolygon) + + numFeatures = self.ogrlayer.GetFeatureCount() + # if no features are in bbox, return all features as shapesInRegion + # (PostGIS sometimes returns no features even if they are within + # the bounding box) + if numFeatures == 0: + self.ogrlayer.SetSpatialFilter(None) + numFeatures = self.ogrlayer.GetFeatureCount() + for feature in range(numFeatures): + nextFeature = self.ogrlayer.GetNextFeature() + yield self.shapes[nextFeature.GetFID()] + + self.ogrlayer.SetSpatialFilter(None) + bboxpolygon.Destroy() + + def AllShapes(self): + """Return an iterable over the shapes in the shape store. + """ + for id in range(len(self.shapes)): + yield self.shapes[id] + + def Shape(self, fid): + """Return the shape with fid = fid + """ + if fid in self.Table().ids.keys(): + return self.shapes[fid] + else: + return None + + def Table(self): + """Return the table containing the attribute data.""" + return self._table + + def Dependencies(self): + """Return the empty tuple. + """ + return () + + def OrigShapeStore(self): + """Return None.""" + return None + + def Id_column(self): + """Return the id_column. + """ + return None class OGRTable(transientdb.AutoTransientTable): """A Table for an ogr datasource. From cvs at intevation.de Thu Apr 28 11:40:00 2005 From: cvs at intevation.de (cvs@intevation.de) Date: Thu, 28 Apr 2005 11:40:00 +0200 (CEST) Subject: jan: thuban/Extensions/ogr ogrstart.py,1.5,1.6 Message-ID: <20050428094000.55A6E101F10@lists.intevation.de> Author: jan Update of /thubanrepository/thuban/Extensions/ogr In directory doto:/tmp/cvs-serv31447 Modified Files: ogrstart.py Log Message: (open_with_ogr): Added forgotten _ for i18n. Adapted call OpenFileShapestore regarding new parameter. (OpenFileShapestore): Use OGRFileShapeStore instead of OGRShapeStore. Fix return value (None instead of null). Add new parameter "mainwindow" to avoid accessing global context. Index: ogrstart.py =================================================================== RCS file: /thubanrepository/thuban/Extensions/ogr/ogrstart.py,v retrieving revision 1.5 retrieving revision 1.6 diff -u -d -r1.5 -r1.6 --- ogrstart.py 4 Mar 2005 15:07:59 -0000 1.5 +++ ogrstart.py 28 Apr 2005 09:39:58 -0000 1.6 @@ -54,12 +54,13 @@ layername = layerDlg.GetLayer() try: session = context.application.Session() - store = OpenFileShapestore(session, filename, layername) + store = OpenFileShapestore(context.mainwindow, session, + filename, layername) session.AddShapeStore(store) except: # the layer couldn't be opened - context.mainwindow.RunMessageBox(("Add Layer"), - ("Can't open the file '%s'.")%filename) + context.mainwindow.RunMessageBox(_("Add Layer"), + _("Can't open the file '%s'.") % filename) else: if store is not None: layer = Layer(title, store) @@ -148,19 +149,18 @@ canvas.FitMapToWindow() dlg.Destroy() -def OpenFileShapestore(session, filename, layername): +def OpenFileShapestore(mainwindow, session, filename, layername): """Open a datasource and add the required layer. """ try: - store = ogrshapes.OGRShapeStore(session, filename, layername) + store = ogrshapes.OGRFileShapeStore(session, filename, layername) return store except: # Some error occured while initializing the layer - context.mainwindow.RunMessageBox(_("Open datasource"), + mainwindow.RunMessageBox(_("Open datasource"), _("Can't open the datasource '%s'") % filename) - else: - return null + return None def OpenDBShapestore(session, dbconn, layername, id_column, geo_column): """Open a datasource and add the required layer. From cvs at intevation.de Thu Apr 28 11:40:27 2005 From: cvs at intevation.de (cvs@intevation.de) Date: Thu, 28 Apr 2005 11:40:27 +0200 (CEST) Subject: jan: thuban ChangeLog,1.806,1.807 Message-ID: <20050428094027.DA493101F11@lists.intevation.de> Author: jan Update of /thubanrepository/thuban In directory doto:/tmp/cvs-serv31472 Modified Files: ChangeLog Log Message: Introduce OGRFileShapeStore in ogr extension. This allows at least that loaded shapefile shape stores can be saved correctly in the thuban session file and reloaded again (reload is via core shapefile routine, not OGR). For other types, .thuban files can not be reloaded for the time being. Index: ChangeLog =================================================================== RCS file: /thubanrepository/thuban/ChangeLog,v retrieving revision 1.806 retrieving revision 1.807 diff -u -d -r1.806 -r1.807 --- ChangeLog 27 Apr 2005 11:07:15 -0000 1.806 +++ ChangeLog 28 Apr 2005 09:40:25 -0000 1.807 @@ -1,3 +1,24 @@ +2005-04-28 Jan-Oliver Wagner + + Introduce OGRFileShapeStore in ogr extension. + This allows at least that loaded shapefile shape stores + can be saved correctly in the thuban session file + and reloaded again (reload is via core shapefile + routine, not OGR). For other types, .thuban files + can not be reloaded for the time being. + + * Extensions/ogr/ogrshapes.py (OGRFileShapeStore): New. This + class ist to be used for any file-based shape stores + accessed through OGR. + + * Extensions/ogr/ogrstart.py (open_with_ogr): Added + forgotten _ for i18n. Adapted call OpenFileShapestore + regarding new parameter. + (OpenFileShapestore): Use OGRFileShapeStore instead of + OGRShapeStore. Fix return value (None instead of null). + Add new parameter "mainwindow" to avoid accessing global + context. + 2005-04-27 Jan-Oliver Wagner Introduce FileShapeStore as generalization for From mlennert at club.worldonline.be Thu Apr 28 12:49:42 2005 From: mlennert at club.worldonline.be (Moritz Lennert) Date: Thu, 28 Apr 2005 12:49:42 +0200 (CEST) Subject: still wxproj compilation problems Message-ID: <42469.164.15.134.161.1114685382.squirrel@vivegnulinux.homelinux.org> Hello, Using a freshly checkout cvs tree, I have the same problem that Jan reported in http://www.intevation.de/pipermail/thuban-devel/2005-April/001398.html, and that Bernard had apparently fixed: building 'Lib.wxproj' extension creating build/temp.linux-i686-2.3 creating build/temp.linux-i686-2.3/libraries creating build/temp.linux-i686-2.3/libraries/thuban gcc -pthread -fno-strict-aliasing -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -fPIC -DGTK_NO_CHECK_CASTS -D__WXGTK__ -D_FILE_OFFSET_BITS=64 -D_LARGE_FILES -Ilibraries/shapelib -I/usr/include -Ilibraries/pyshapelib/ -I/usr/lib/wx/include/gtk-2.4 -I/usr/include/python2.3 -c libraries/thuban/wxproj.cpp -o build/temp.linux-i686-2.3/libraries/thuban/wxproj.o libraries/thuban/wxproj.cpp:40:34: wx/wxPython/wxPython.h : Aucun fichier ou r?pertoire de ce type libraries/thuban/wxproj.cpp: Dans function ? bool wxPyConvertSwigPtr(PyObject*, void**, char*) ?: libraries/thuban/wxproj.cpp:62: error: `wxPyCoreAPIPtr' undeclared (first use this function) libraries/thuban/wxproj.cpp:62: error: (Each undeclared identifier is reported only once for each function it appears in.) libraries/thuban/wxproj.cpp:63: error: `wxPyCoreAPI_IMPORT' undeclared (first use this function) libraries/thuban/wxproj.cpp:65: error: `SWIG_GetPtrObj' undeclared (first use this function) error: command 'gcc' failed with exit status 1 make: *** [build-stamp] Erreur 1 Just as Jan I am running Debian sarge, with wx2.4. Moritz From bernhard at intevation.de Thu Apr 28 21:24:50 2005 From: bernhard at intevation.de (Bernhard Reiter) Date: Thu, 28 Apr 2005 21:24:50 +0200 Subject: wxWidgets 2.6.0 released Message-ID: <20050428192450.GD23024@intevation.de> http://wxwidgets.org/front.htm April 21st, 2005: wxWidgets 2.6.0 has been released: please see the download page for details. This is the first official, stable release for a long time but we think the wait has been worth it. From bh at intevation.de Fri Apr 29 12:05:10 2005 From: bh at intevation.de (Bernhard Herzog) Date: Fri, 29 Apr 2005 12:05:10 +0200 Subject: russell: thuban ChangeLog,1.803,1.804 In-Reply-To: <20050423053455.42C861005D7@lists.intevation.de> (cvs@intevation.de's message of "Sat, 23 Apr 2005 07:34:55 +0200 (CEST)") References: <20050423053455.42C861005D7@lists.intevation.de> Message-ID: cvs at intevation.de writes: > --- ChangeLog 11 Apr 2005 18:18:08 -0000 1.803 > +++ ChangeLog 23 Apr 2005 05:34:52 -0000 1.804 > @@ -1,3 +1,8 @@ > +2005-04-23 Russell Nelson > + > + * Changed the way the previous tool is remembered, so that > + middle-button panning works even if you haven't selected a tool. > + Thanks. Could you add filename, class and methodname, too? Bernhard -- Intevation GmbH http://intevation.de/ Skencil http://skencil.org/ Thuban http://thuban.intevation.org/ From bh at intevation.de Fri Apr 29 12:07:04 2005 From: bh at intevation.de (Bernhard Herzog) Date: Fri, 29 Apr 2005 12:07:04 +0200 Subject: still wxproj compilation problems In-Reply-To: <42469.164.15.134.161.1114685382.squirrel@vivegnulinux.homelinux.org> (Moritz Lennert's message of "Thu, 28 Apr 2005 12:49:42 +0200 (CEST)") References: <42469.164.15.134.161.1114685382.squirrel@vivegnulinux.homelinux.org> Message-ID: "Moritz Lennert" writes: > Using a freshly checkout cvs tree, I have the same problem that Jan reported > in http://www.intevation.de/pipermail/thuban-devel/2005-April/001398.html, and > that Bernard had apparently fixed: [...] > Just as Jan I am running Debian sarge, with wx2.4. Have you run setup.py with the --use-wx-python-swig-hack option? Bernhard -- Intevation GmbH http://intevation.de/ Skencil http://skencil.org/ Thuban http://thuban.intevation.org/ From bh at intevation.de Fri Apr 29 12:21:03 2005 From: bh at intevation.de (Bernhard Herzog) Date: Fri, 29 Apr 2005 12:21:03 +0200 Subject: Raster layer opacity In-Reply-To: <1111592504.14081.14.camel@localhost.localdomain> (Jonathan Coles's message of "Wed, 23 Mar 2005 10:41:44 -0500") References: <1111592504.14081.14.camel@localhost.localdomain> Message-ID: Sorry for getting back to this so late, but I don't have as much time for Thuban as I would like. Jonathan Coles writes: > I've just commited changes that allow the opacity of a raster layer to > be changed. Previously, (in anticipation of these changes) a raster > layer had an opacity property but it was not used. I've added a new > control to the layer properties box for raster layers. The level is then > used in MapRenderer.draw_raster_data() to scale the alpha values to the > proper opacity. > > I chose to implement the scaling in MapRenderer.draw_raster_data() as > opposed to BaseRenderer.draw_raster_layer() because doing the scaling > late in the rendering process allows for all types of raster layer > formats to be adjusted, not just those that are handled in > BaseRenderer.draw_raster_layer(). This decision, however, required that > I add the layer to the parameter list of > MapRenderer.draw_raster_data(). I don't see why you need to add the layer itself. The opacity value would have sufficed. So far the draw_raster_data implementations had no need to know about layers. They only needed to know about raster data rendering. I think it should stay that way. Bernhard -- Intevation GmbH http://intevation.de/ Skencil http://skencil.org/ Thuban http://thuban.intevation.org/ From mlennert at club.worldonline.be Fri Apr 29 12:59:06 2005 From: mlennert at club.worldonline.be (Moritz Lennert) Date: Fri, 29 Apr 2005 12:59:06 +0200 (CEST) Subject: still wxproj compilation problems In-Reply-To: References: <42469.164.15.134.161.1114685382.squirrel@vivegnulinux.homelinux.org> Message-ID: <33076.212.87.101.40.1114772346.squirrel@vivegnulinux.homelinux.org> On Fri, April 29, 2005 12:07, Bernhard Herzog said: > "Moritz Lennert" writes: > >> Using a freshly checkout cvs tree, I have the same problem that Jan reported >> in http://www.intevation.de/pipermail/thuban-devel/2005-April/001398.html, >> and >> that Bernard had apparently fixed: > [...] >> Just as Jan I am running Debian sarge, with wx2.4. > > Have you run setup.py with the --use-wx-python-swig-hack option? I used dpkg-buildpackage without changing anything in the debian directory. Moritz