From napo at itc.it Wed Oct 1 10:16:11 2003 From: napo at itc.it (Maurizio Napolitano) Date: Wed, 01 Oct 2003 10:16:11 +0200 Subject: [Thuban-list] Thuban compile problem Message-ID: <1064996171.26924.13.camel@toriamos> I need to compile Thuban myself because i can't be the root of my computer. I have some problem in this point. How i can correct this? creating build/temp.linux-i686-2.3/libraries/pyprojection gcc -pthread -fno-strict-aliasing -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -fPIC -I/usr/local/include -I/sra0/sra/napolita/garnome/include/python2.3 -c libraries/pyprojection/Projection_wrap.c -o build/temp.linux-i686-2.3/libraries/pyprojection/Projection_wrap.o In file included from /sra0/sra/napolita/garnome/include/python2.3/Python.h:8, from libraries/pyprojection/Projection_wrap.c:176: /sra0/sra/napolita/garnome/include/python2.3/pyconfig.h:844:1: warning: "_POSIX_C_SOURCE" redefined From jan at intevation.de Thu Oct 2 15:24:10 2003 From: jan at intevation.de (Jan-Oliver Wagner) Date: Thu, 2 Oct 2003 15:24:10 +0200 Subject: [Thuban-list] Strange exception for user.proj In-Reply-To: <1064847023.16186.30.camel@reisen> References: <20030929122726.GA12742@intevation.de> <1064847023.16186.30.camel@reisen> Message-ID: <20031002132410.GB26739@intevation.de> On Mon, Sep 29, 2003 at 10:50:23AM -0400, Jonathan Coles wrote: > On Mon, 2003-09-29 at 08:27, Jan-Oliver Wagner wrote: > > | Exception exceptions.AttributeError: in ignored > > > > The projection origintates from the epsg file of the proj package. > > I wrote a small converter to produce a Thuban .proj file from the epsg > > file. However, at least for this projection (user.proj is attached) > > I get an exception when opening the Map Projection dialog. > > thuban doesn't have a dialog for proj=omerc. there is only one for > tmerc. when i changed from omerc to tmerc (ignoring what that really > means) i didn't get the exception. I have added a corresponding hint into the bug tracker. Also some further analysis and a proposal how to solve it: https://intevation.de/rt/webrt?serial_num=2138&display=History -- Jan-Oliver Wagner http://intevation.de/~jan/ Intevation GmbH http://intevation.de/ FreeGIS http://freegis.org/ From sholl at gmx.net Sun Oct 5 18:02:05 2003 From: sholl at gmx.net (Stephan Holl) Date: Sun, 5 Oct 2003 18:02:05 +0200 Subject: [Thuban-list] Implementation of GDAL In-Reply-To: <6q1xtybe0v.fsf@salmakis.intevation.de> References: <20030929184502.03df764e.sholl@gmx.net> <6qekxzbfap.fsf@salmakis.intevation.de> <20030930072541.02d601da.sholl@gmx.net> <6qn0cmble8.fsf@salmakis.intevation.de> <20030930131053.784ac429.sholl@gmx.net> <6q1xtybe0v.fsf@salmakis.intevation.de> Message-ID: <20031005180205.13ffa34f.sholl@gmx.net> Hello Bernhard, At Tue, 30 Sep 2003 15:29:36 +0200 Bernhard Herzog wrote: > This looks like some library was missing when linking gdalwarp.so. > According to google this is probably because gdalwarp.cpp is compiled > as c++ but linked by gcc which doesn't automatically include > libstdc++. We don't have problem because we still mostly use gcc 2.95. > > This seems to be a bug in distutils in Python < 2.3. There doesn't > seem to be an easy fix, unfortunately, but there are several options: > > - Use the distutils from Python 2.3 which automatically use the c++ > compiler for linking extensions written in C++ > > I just tried this by creating a symbolic link to the directory > containing distutils in the thuban source directory and then > running the setup.py script normally (after removing the build > subdirectory to make sure everything is rebuilt properly) > > ln -s path/to/python/lib/python2.3/distutils/ . > rm -r build/ > python2.2 setup.py build > > This works for me but all I can easily check is it does indeed call > the c++ compiler. I don't have a system with gcc 3.0 where all the > other stuff Thuban requires is already available. The distutils of > Python 2.3 work fine with Python 2.2 apparently. Thank you for your quick help with compiling thuban from source. The problem I was struggeling with was solved by some apt-getting (python2.3, python2.3.-dev) and setting the correct link as mentioned above. Now it works fine. Gru? Stephan -- Stephan Holl GnuPG Key-ID: 11946A09 18:00:08 up 7:18, 1 user, load average: 0.32, 0.13, 0.04 -------------- 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-list/attachments/20031005/08e18362/attachment.bin From bh at intevation.de Mon Oct 6 19:35:51 2003 From: bh at intevation.de (Bernhard Herzog) Date: Mon, 06 Oct 2003 19:35:51 +0200 Subject: [Thuban-list] Thuban compile problem In-Reply-To: <1064996171.26924.13.camel@toriamos> (Maurizio Napolitano's message of "Wed, 01 Oct 2003 10:16:11 +0200") References: <1064996171.26924.13.camel@toriamos> Message-ID: <6qhe2m1d6w.fsf@salmakis.intevation.de> Maurizio Napolitano writes: > I have some problem in this point. What's the actual problem? > creating build/temp.linux-i686-2.3/libraries/pyprojection > gcc -pthread -fno-strict-aliasing -DNDEBUG -g -O3 -Wall > -Wstrict-prototypes -fPIC -I/usr/local/include > -I/sra0/sra/napolita/garnome/include/python2.3 -c > libraries/pyprojection/Projection_wrap.c -o > build/temp.linux-i686-2.3/libraries/pyprojection/Projection_wrap.o > In file included from > /sra0/sra/napolita/garnome/include/python2.3/Python.h:8, > from libraries/pyprojection/Projection_wrap.c:176: > /sra0/sra/napolita/garnome/include/python2.3/pyconfig.h:844:1: warning: > "_POSIX_C_SOURCE" redefined This is only a warning and not an error. In my brief experience with Python 2.3 so far this warning seems harmless and should still give a working program. Bernhard -- Intevation GmbH http://intevation.de/ Sketch http://sketch.sourceforge.net/ Thuban http://thuban.intevation.org/ From napo at itc.it Tue Oct 7 09:41:34 2003 From: napo at itc.it (Maurizio Napolitano) Date: Tue, 07 Oct 2003 09:41:34 +0200 Subject: [Thuban-list] Thuban compile problem In-Reply-To: <6qhe2m1d6w.fsf@salmakis.intevation.de> References: <1064996171.26924.13.camel@toriamos> <6qhe2m1d6w.fsf@salmakis.intevation.de> Message-ID: <1065512494.20073.19.camel@toriamos> Il lun, 2003-10-06 alle 19:35, Bernhard Herzog ha scritto: > Maurizio Napolitano writes: > > > I have some problem in this point. > > What's the actual problem? I have solved!!! The realy error was 5 lines later: libraries/pyprojection/Projection_wrap.c:508:22: projects.h: No such file or dir ectory My "projects.h" is in a differete directory declarated into the setup.py file located in "libraries/pyprojection" I have changed this and now ... work ;) Thanks! From jan at intevation.de Tue Oct 7 11:16:21 2003 From: jan at intevation.de (Jan-Oliver Wagner) Date: Tue, 7 Oct 2003 11:16:21 +0200 Subject: [Thuban-list] Thuban Logo Message-ID: <20031007091621.GA12976@intevation.de> Hi, approaching release 1.0 it is time to think about a logo for Thuban. Frank Koormann prepared some studies: http://thuban.intevation.org/logos/logos.html What do you think? Any opinions, suggestions and logo ideas are very welcome! My personal favorite of the page above would be No.1 with little lindworm-like wings. Best Jan -- Jan-Oliver Wagner http://intevation.de/~jan/ Intevation GmbH http://intevation.de/ FreeGIS http://freegis.org/ From bh at intevation.de Tue Oct 7 12:15:09 2003 From: bh at intevation.de (Bernhard Herzog) Date: Tue, 07 Oct 2003 12:15:09 +0200 Subject: [Thuban-list] Spanish and French translation updates In-Reply-To: <20030927182841.M55509@minag.gob.pe> (Daniel Calvelo's message of "Sat, 27 Sep 2003 13:30:54 -0500") References: <20030927182841.M55509@minag.gob.pe> Message-ID: <6qn0cdcq1e.fsf@salmakis.intevation.de> "Daniel Calvelo" writes: > Attached are the PO files for french and spanish as of sept.18 CVS. Thanks. I notice that they're in UTF8 and thus they don't work for me because in my enviroment the es locales for instance use ISO-8859-1 or ISO-8859-15 Would the translations work for you if they're in latin1? The older translations are in latin1. While I've found a way to make the utf8 po-files work with my installation (by using wxGetTranslation instead of the python gettext module) I would prefer to keep the old implementation for now because it's simpler. Bernhard -- Intevation GmbH http://intevation.de/ Sketch http://sketch.sourceforge.net/ Thuban http://thuban.intevation.org/ From thomas at intevation.de Tue Oct 7 12:17:59 2003 From: thomas at intevation.de (Thomas Arendsen Hein) Date: Tue, 7 Oct 2003 12:17:59 +0200 Subject: [Thuban-list] Thuban Logo In-Reply-To: <20031007091621.GA12976@intevation.de> References: <20031007091621.GA12976@intevation.de> Message-ID: <20031007101759.GB21334@intevation.de> On Tue, Oct 07, 2003 at 11:16:21AM +0200, Jan-Oliver Wagner wrote: > http://thuban.intevation.org/logos/logos.html > What do you think? Our dragon should be user friendly, therefore it needs those big eyes of logos 1/5/6. But to make the dragon different from a snake, there should be small wings or a "dorsal fin" (what's the correct name here?) like on http://www.reptilien-center.de/goniocephalus%20grandis.jpg Thomas -- Email: thomas at intevation.de http://intevation.de/~thomas/ From bernhard at intevation.de Tue Oct 7 12:58:03 2003 From: bernhard at intevation.de (Bernhard Reiter) Date: Tue, 7 Oct 2003 12:58:03 +0200 Subject: [Thuban-list] Thuban Logo In-Reply-To: <20031007091621.GA12976@intevation.de> References: <20031007091621.GA12976@intevation.de> Message-ID: <20031007105803.GD23504@intevation.de> On Tue, Oct 07, 2003 at 11:16:21AM +0200, Jan-Oliver Wagner wrote: > approaching release 1.0 it is time to think about a logo for > Thuban. Frank Koormann prepared some studies: > http://thuban.intevation.org/logos/logos.html > What do you think? The proposals are more like icons than logos. If we were searching for a logo, I'd say it should contain some letters of "Thuban". -------------- 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-list/attachments/20031007/facf336b/attachment.bin From bh at intevation.de Tue Oct 7 13:04:00 2003 From: bh at intevation.de (Bernhard Herzog) Date: Tue, 07 Oct 2003 13:04:00 +0200 Subject: [Thuban-list] Thuban Logo References: <20031007091621.GA12976@intevation.de> <20031007105803.GD23504@intevation.de> Message-ID: <6qad8dcnrz.fsf@salmakis.intevation.de> Bernhard Reiter writes: > If we were searching for a logo, > I'd say it should contain some letters of "Thuban". Maybe a (stylized) map of a fictitious contry name "Thuban". Bernhard -- Intevation GmbH http://intevation.de/ Sketch http://sketch.sourceforge.net/ Thuban http://thuban.intevation.org/ From bh at intevation.de Tue Oct 7 19:45:24 2003 From: bh at intevation.de (Bernhard Herzog) Date: Tue, 07 Oct 2003 19:45:24 +0200 Subject: [Thuban-list] Apply wxInitAllImageHandlers? References: <20030923075504.GA3057@intevation.de> Message-ID: <6q3ce5aqmj.fsf@salmakis.intevation.de> Jan-Oliver Wagner writes: > I wonder whether Thuban should always call > wxInitAllImageHandlers() at startup to make JPEG and > other formats available for wxBitmap. > > Any particular reason why this should better not be done? The only reason that comes to mind is that it will delay startup a bit and probably increase memory consumption. Bernhard -- Intevation GmbH http://intevation.de/ Sketch http://sketch.sourceforge.net/ Thuban http://thuban.intevation.org/ From jan at intevation.de Wed Oct 8 10:19:01 2003 From: jan at intevation.de (Jan-Oliver Wagner) Date: Wed, 8 Oct 2003 10:19:01 +0200 Subject: [Thuban-list] Apply wxInitAllImageHandlers? In-Reply-To: <6q3ce5aqmj.fsf@salmakis.intevation.de> References: <20030923075504.GA3057@intevation.de> <6q3ce5aqmj.fsf@salmakis.intevation.de> Message-ID: <20031008081901.GB8327@intevation.de> On Tue, Oct 07, 2003 at 07:45:24PM +0200, Bernhard Herzog wrote: > Jan-Oliver Wagner writes: > > I wonder whether Thuban should always call > > wxInitAllImageHandlers() at startup to make JPEG and > > other formats available for wxBitmap. > > > > Any particular reason why this should better not be done? > > The only reason that comes to mind is that it will delay startup a bit > and probably increase memory consumption. any estimates for this available? In general, I think it is a good idea since the various formats needs more and more to be dealt with anyway. So, if the delay and mem consumption is not significant, I propose to apply the initialiazation. Best Jan -- Jan-Oliver Wagner http://intevation.de/~jan/ Intevation GmbH http://intevation.de/ FreeGIS http://freegis.org/ From bh at intevation.de Wed Oct 8 10:40:13 2003 From: bh at intevation.de (Bernhard Herzog) Date: Wed, 08 Oct 2003 10:40:13 +0200 Subject: [Thuban-list] Apply wxInitAllImageHandlers? In-Reply-To: <20031008081901.GB8327@intevation.de> (Jan-Oliver Wagner's message of "Wed, 8 Oct 2003 10:19:01 +0200") References: <20030923075504.GA3057@intevation.de> <6q3ce5aqmj.fsf@salmakis.intevation.de> <20031008081901.GB8327@intevation.de> Message-ID: <6qoewsw2aa.fsf@salmakis.intevation.de> Jan-Oliver Wagner writes: > On Tue, Oct 07, 2003 at 07:45:24PM +0200, Bernhard Herzog wrote: >> Jan-Oliver Wagner writes: >> > I wonder whether Thuban should always call >> > wxInitAllImageHandlers() at startup to make JPEG and >> > other formats available for wxBitmap. >> > >> > Any particular reason why this should better not be done? >> >> The only reason that comes to mind is that it will delay startup a bit >> and probably increase memory consumption. > > any estimates for this available? The change only involves adding the wxInitAllImageHandlers call to the app's OnInit method, I guess, so it shouldn't take more than a few minutes. Bernhard -- Intevation GmbH http://intevation.de/ Sketch http://sketch.sourceforge.net/ Thuban http://thuban.intevation.org/ From laurent_breton_web at yahoo.fr Thu Oct 9 17:19:07 2003 From: laurent_breton_web at yahoo.fr (=?iso-8859-1?q?Breton=20Laurent?=) Date: Thu, 9 Oct 2003 17:19:07 +0200 (CEST) Subject: [Thuban-list] Extensions load problem Message-ID: <20031009151907.24281.qmail@web20701.mail.yahoo.com> Hi, I discovered Thuban a couple of days ago, and I considere as an exciting and promising project. Unfortunately I am not able to use the extensions (e.g. hello_world). I am not a Python expert so may have made a mistake somewhere: - I'm using Windows XP but the same issue occurs on a Win 2K PC. - I installed Python 2.2 and all the mandatory modules, and thuban 0.9.0: it works well. - In the C:\Documents and Settings\\Application Data\thuban I created a thubanstart.py file, containing the line: import hello_world - I added the path to the simple_extensions directory in PYTHONPATH. - Nothing appends when I start thuban. Any idea? Laurent ___________________________________________________________ Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et en fran?ais ! Yahoo! Mail : http://fr.mail.yahoo.com From acuster at nature.berkeley.edu Fri Oct 10 10:15:13 2003 From: acuster at nature.berkeley.edu (Adrian Custer) Date: Fri, 10 Oct 2003 01:15:13 -0700 Subject: [Thuban-list] Compile into oblivion Message-ID: <1065773713.2534.6.camel@tsetse.lab-net> Hey all, I'm tring to give the infamous nordic diety a spin, and got caught in a mess of install requirements. I plowed through a number of them, including changing l.73 of setup.py to: wx_config_script = "/usr/lib/wxPython/bin/wx-config" my last run of: [acuster at tsetse Thuban-0.9.0]$ python setup.py install_local stops after: libraries/pyprojection/Projection_wrap.c: In function `_wrap_new_Projection': libraries/pyprojection/Projection_wrap.c:1283: error: invalid type argument of `unary *' libraries/pyprojection/Projection_wrap.c:1291: error: invalid type argument of `unary *' error: command 'gcc' failed with exit status 1 Any ideas? thanks, adrian From bh at intevation.de Fri Oct 10 11:00:59 2003 From: bh at intevation.de (Bernhard Herzog) Date: Fri, 10 Oct 2003 11:00:59 +0200 Subject: [Thuban-list] Compile into oblivion In-Reply-To: <1065773713.2534.6.camel@tsetse.lab-net> (Adrian Custer's message of "Fri, 10 Oct 2003 01:15:13 -0700") References: <1065773713.2534.6.camel@tsetse.lab-net> Message-ID: <6qk77dii0k.fsf@salmakis.intevation.de> Adrian Custer writes: > libraries/pyprojection/Projection_wrap.c: In function > `_wrap_new_Projection': > libraries/pyprojection/Projection_wrap.c:1283: error: invalid type > argument of `unary *' > libraries/pyprojection/Projection_wrap.c:1291: error: invalid type > argument of `unary *' > error: command 'gcc' failed with exit status 1 Which version of the proj library do you compile it with? The problem seems to be the pj_get_errno_ref function which returns a pointer to int and the code in question dereferences the return value. This can lead to the above errors when e.g. the compiler didn't see the prototype and assumes it returns int. According to proj's ChangeLog this means Thuban needs at least version 4.4.4. Bernhard -- Intevation GmbH http://intevation.de/ Sketch http://sketch.sourceforge.net/ Thuban http://thuban.intevation.org/ From acuster at nature.berkeley.edu Fri Oct 10 21:14:47 2003 From: acuster at nature.berkeley.edu (Adrian Custer) Date: Fri, 10 Oct 2003 12:14:47 -0700 Subject: [Thuban-list] Compile into oblivion In-Reply-To: <6qk77dii0k.fsf@salmakis.intevation.de> References: <1065773713.2534.6.camel@tsetse.lab-net> <6qk77dii0k.fsf@salmakis.intevation.de> Message-ID: <1065813287.2860.7.camel@tsetse.lab-net> Sorry to keep after you, I've fallen into mandrake library hell. After much installing and re-installing, when I now run: python setup.py install_local I get: ... libraries/thuban/wxproj.cpp: In function `wxPoint* project_points(int, int, double*, double*, int*, PJ*, PJ*, double, double, double, double)': libraries/thuban/wxproj.cpp:186: error: invalid application of `sizeof' to an incomplete type libraries/thuban/wxproj.cpp:200: error: invalid use of undefined type `struct wxPoint' ... wxPoint seems to be fundamental to wx* stuff but I can't figure out which library is not being found or how I might go about pointing things to the right location. The wx stuff I have is: [root at tsetse site-packages]# rpm -q -a | grep wx libwxPythonGTK2.4-devel-2.4.1.2-3mdk wxGTK-2.4.2-1mdk libwxPythonGTK2.4-2.4.1.2-3mdk libwx_base2.4_0-2.4.1-1mdk libwxgtkgl2.4-2.4.2-1mdk libwxgtk2.4-2.4.2-1mdk wxPythonGTK-2.4.1.2-3mdk libwx_base2.4_0-devel-2.4.1-1mdk [root at tsetse site-packages]# any more ideas? --adrian On Fri, 2003-10-10 at 02:00, Bernhard Herzog wrote: > Adrian Custer writes: > > > libraries/pyprojection/Projection_wrap.c: In function > > `_wrap_new_Projection': > > libraries/pyprojection/Projection_wrap.c:1283: error: invalid type > > argument of `unary *' > > libraries/pyprojection/Projection_wrap.c:1291: error: invalid type > > argument of `unary *' > > error: command 'gcc' failed with exit status 1 > > Which version of the proj library do you compile it with? > > The problem seems to be the pj_get_errno_ref function which returns a > pointer to int and the code in question dereferences the return value. > This can lead to the above errors when e.g. the compiler didn't see the > prototype and assumes it returns int. > > According to proj's ChangeLog this means Thuban needs at least version > 4.4.4. > > Bernhard From bh at intevation.de Mon Oct 13 15:22:17 2003 From: bh at intevation.de (Bernhard Herzog) Date: Mon, 13 Oct 2003 15:22:17 +0200 Subject: [Thuban-list] Compile into oblivion References: <1065773713.2534.6.camel@tsetse.lab-net> <6qk77dii0k.fsf@salmakis.intevation.de> <1065813287.2860.7.camel@tsetse.lab-net> Message-ID: <6q7k39z306.fsf@salmakis.intevation.de> Adrian Custer writes: > libraries/thuban/wxproj.cpp: In function `wxPoint* project_points(int, > int, double*, double*, int*, PJ*, PJ*, double, double, double, double)': > libraries/thuban/wxproj.cpp:186: error: invalid application of `sizeof' > to an incomplete type > libraries/thuban/wxproj.cpp:200: error: invalid use of undefined type > `struct wxPoint' wxPoint is defined in wx/gdicmn.h which is currently only indirectly included in wxproj.cpp. Your wx version is newer than the one we currently use so I compiled a newer one to check whether something has changed in this regard. Still works for me, though. Nevertheless there must be a problem with the include files somewhere. You can try two things: - add an #include to wxproj.cpp to make sure that headerfile is included - Add a -H to the options of gcc when compiling wxproj.cpp to see which headerfiles are actually used. > ... > > wxPoint seems to be fundamental to wx* stuff but I can't figure out > which library is not being found or how I might go about pointing things > to the right location. > > The wx stuff I have is: > [root at tsetse site-packages]# rpm -q -a | grep wx > libwxPythonGTK2.4-devel-2.4.1.2-3mdk According to http://rpms.mandrakeclub.com/rpms/mandrake/9.1/contrib/i586/libwxPythonGTK2.4-devel-2.4.0.6-1mdk.i586.html this RPM contains all wxGTK headerfiles wx/gdicmn.h so at least gdicmn.h is not missing. Seems a bit strange to put those headerfiles in a libwxPythonGTK2.4-devel RPM isntead of say a libwxGTK-2.4 devel, though. > wxGTK-2.4.2-1mdk > libwxPythonGTK2.4-2.4.1.2-3mdk > libwx_base2.4_0-2.4.1-1mdk > libwxgtkgl2.4-2.4.2-1mdk > libwxgtk2.4-2.4.2-1mdk > wxPythonGTK-2.4.1.2-3mdk > libwx_base2.4_0-devel-2.4.1-1mdk Some of these RPMs have slightly different versions (e.g. 2.4.1.2 vs. 2.4.2) this may cause segfaults when trying to display shapefiles as experience has unfortunately shown as there seem to be some binary incompatibilities in some cases. Bernhard -- Intevation GmbH http://intevation.de/ Sketch http://sketch.sourceforge.net/ Thuban http://thuban.intevation.org/ From barbarito at omplace.com Mon Oct 13 18:05:10 2003 From: barbarito at omplace.com (Fidel Serrano) Date: Mon, 13 Oct 2003 12:05:10 -0400 (EDT) Subject: [Thuban-list] arcview comparition and thuban.mo Message-ID: <200310131605.h9DG5AD3026052@www38.web2010.com> i have been using thuban for six month or so, and im very hapy with the development, yesterday i intalled arcview from ESRI in my computer, and i noticed 2 things: 1 when you maximize the aplication window, the map (all the layers) resizes to cover the new size of the window aplication thuban does not do that, dont you think it would be nice. 2 the time of display for a layer or a raster image is like 1/10 of the time it takes for thuban, is that becouse of python velocity? or becouse of the algoritm of displaing? and i have a cuestion: how do i use the thuban.mo files to get thuban translated? ______________________________________________________________ Sponsored By: The ByRegion Network http://www.HealerPages.info SpiritCard Center http://www.spiritcardcenter.com OmPlace - The Conscious Living Directory - FREE Email http://www.omplace.com From bh at intevation.de Tue Oct 14 20:46:55 2003 From: bh at intevation.de (Bernhard Herzog) Date: Tue, 14 Oct 2003 20:46:55 +0200 Subject: [Thuban-list] arcview comparition and thuban.mo References: <200310131605.h9DG5AD3026052@www38.web2010.com> Message-ID: <6qad834py8.fsf@salmakis.intevation.de> "Fidel Serrano" writes: > 1 when you maximize the aplication window, the map (all the layers) > resizes to cover the new size of the window aplication > thuban does not do that, dont you think it would be nice. I'm not sure whether I would always want it but it's worth considering. I've added a wish-list item in the request tracker fpr it: https://intevation.de/rt/webrt?serial_num=2156 > 2 the time of display for a layer or a raster image is like 1/10 > of the time it takes for thuban, is that becouse of python > velocity? or becouse of the algoritm of displaing? Thuban's rendering speed definitely needs to be improved. The algorithm is probably not to blame. Thuban builds a quad-tree for the shapes in shapefiles and uses it to more or less only draw shapes that overlap the visible region. Beyond that there's not much you can do besides iterating through those shapes and draw them. Some common usage patterns could be speeded up by more intelligent caching, though, and some classifications can be speeded up by using python dictionaries instead of linear searches in some cases, I think. While Python's speed is certainly an issue, I'm not sure how much impact that still has on the rendering especially in the case of rendering from shapefiles and without classifications. We already do the actual drawing of a polygon or arc shape from a shapefile in C++ which means that the code that reads the actual geometry, applies any necessary projection, transforms it to window coordinates and passes the data to the wxDC is written in C++. Anyway, one of the things we want to for 1.0 is to look into ways to increase rendering speed. > and i have a cuestion: how do i use the thuban.mo files to get thuban > translated? Setting the environment variable LANG to a suitable value shuold be enough. e.g. LANG=de_DE to get German translations. This works for me on my GNU/Linux system anyway. Bernhard -- Intevation GmbH http://intevation.de/ Sketch http://sketch.sourceforge.net/ Thuban http://thuban.intevation.org/ From bernhard at intevation.de Tue Oct 14 21:01:23 2003 From: bernhard at intevation.de (Bernhard Reiter) Date: Tue, 14 Oct 2003 21:01:23 +0200 Subject: [Thuban-list] thuban.mo and translations In-Reply-To: <6qad834py8.fsf@salmakis.intevation.de> References: <200310131605.h9DG5AD3026052@www38.web2010.com> <6qad834py8.fsf@salmakis.intevation.de> Message-ID: <20031014190123.GA5694@intevation.de> On Tue, Oct 14, 2003 at 08:46:55PM +0200, Bernhard Herzog wrote: > "Fidel Serrano" writes: > > and i have a cuestion: how do i use the thuban.mo files to get thuban > > translated? > > Setting the environment variable LANG to a suitable value shuold be > enough. e.g. LANG=de_DE to get German translations. This works for me on > my GNU/Linux system anyway. In case the question has been: How to I create a new translation? Look into the "po" subdirectory and the README. You need to end up with a new file for each language, like "pt.po". To get that file you need to start from thuban.pot. Copy that file and then use an po-file editor to do the translations. A normal texteditor might be enough, but a tool like poedit.sourceforge.net might still be interesting. Please contribute a new translation if you make one. (Shouldn't be add something like this a the documentation or the mentioned README somewhere?) 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-list/attachments/20031014/d7b5ac0b/attachment.bin From jan at intevation.de Tue Oct 14 22:15:15 2003 From: jan at intevation.de (Jan-Oliver Wagner) Date: Tue, 14 Oct 2003 22:15:15 +0200 Subject: [Thuban-list] arcview comparition and thuban.mo In-Reply-To: <6qad834py8.fsf@salmakis.intevation.de> References: <200310131605.h9DG5AD3026052@www38.web2010.com> <6qad834py8.fsf@salmakis.intevation.de> Message-ID: <20031014201515.GB13974@intevation.de> On Tue, Oct 14, 2003 at 08:46:55PM +0200, Bernhard Herzog wrote: > "Fidel Serrano" writes: > > 1 when you maximize the aplication window, the map (all the layers) > > resizes to cover the new size of the window aplication > > thuban does not do that, dont you think it would be nice. > > I'm not sure whether I would always want it but it's worth considering. > I've added a wish-list item in the request tracker fpr it: > https://intevation.de/rt/webrt?serial_num=2156 I must confess, that I still expect a behaviur as Fidel describes when changing the window size though I use Thuban now for quite some time. Especially switching between a small window and full-screen is something I want to increase the size of the map quickly. Best Jan -- Jan-Oliver Wagner http://intevation.de/~jan/ Intevation GmbH http://intevation.de/ FreeGIS http://freegis.org/ From a.rottmann at gmx.at Wed Oct 15 00:11:10 2003 From: a.rottmann at gmx.at (Andreas Rottmann) Date: Wed, 15 Oct 2003 00:11:10 +0200 Subject: [Thuban-list] thuban.mo and translations In-Reply-To: <20031014190123.GA5694@intevation.de> (Bernhard Reiter's message of "Tue, 14 Oct 2003 21:01:23 +0200") References: <200310131605.h9DG5AD3026052@www38.web2010.com> <6qad834py8.fsf@salmakis.intevation.de> <20031014190123.GA5694@intevation.de> Message-ID: <87y8vn5v29.fsf@alice.rotty.yi.org> Bernhard Reiter writes: > In case the question has been: How to I create a new translation? > > Look into the "po" subdirectory and the README. > You need to end up with a new file for each language, like "pt.po". > To get that file you need to start from thuban.pot. > Copy that file and then use an po-file editor to do the translations. > > A normal texteditor might be enough, but a tool > like poedit.sourceforge.net might still be interesting. > Or Emacs using po-mode, of course. [SCNR] Andy -- Andreas Rottmann | Rotty at ICQ | 118634484 at ICQ | a.rottmann at gmx.at http://www.8ung.at/rotty | GnuPG Key: http://www.8ung.at/rotty/gpg.asc Fingerprint | DFB4 4EB4 78A4 5EEE 6219 F228 F92F CFC5 01FD 5B62 This reality is really just a fucked-up dream -- Papa Roach From jan at intevation.de Wed Oct 15 14:44:27 2003 From: jan at intevation.de (Jan-Oliver Wagner) Date: Wed, 15 Oct 2003 14:44:27 +0200 Subject: [Thuban-list] Extensions load problem In-Reply-To: <20031009151907.24281.qmail@web20701.mail.yahoo.com> References: <20031009151907.24281.qmail@web20701.mail.yahoo.com> Message-ID: <20031015124427.GB18147@intevation.de> On Thu, Oct 09, 2003 at 05:19:07PM +0200, Breton Laurent wrote: > I discovered Thuban a couple of days ago, and I > considere as an exciting and promising project. > > Unfortunately I am not able to use the extensions > (e.g. hello_world). I am not a Python expert so may > have made a mistake somewhere: > > - I'm using Windows XP but the same issue occurs on a > Win 2K PC. > - I installed Python 2.2 and all the mandatory > modules, and thuban 0.9.0: it works well. > - In the C:\Documents and Settings\ user>\Application Data\thuban I created a > thubanstart.py file, containing the line: import > hello_world > - I added the path to the simple_extensions directory > in PYTHONPATH. > - Nothing appends when I start thuban. this seems indeed a problem. I am not too deep into Windows, and so I do not really understand the logic behind the Windows philosophy of home directories. As I am the one currently taking care of the Users Manual, I would like to add explanations for the Windows world, but I need someone from that world to explain it to me in detail. Best Jan -- Jan-Oliver Wagner http://intevation.de/~jan/ Intevation GmbH http://intevation.de/ FreeGIS http://freegis.org/ From jan at intevation.de Mon Oct 20 13:04:02 2003 From: jan at intevation.de (Jan-Oliver Wagner) Date: Mon, 20 Oct 2003 13:04:02 +0200 Subject: [Thuban-list] Thuban entered Debian Testing(sarge) Message-ID: <20031020110402.GB6244@intevation.de> Hi, this is to let you know that Thuban entered Debian GNU/Linux Testing aka Sarge last week :-) Also, Silke checked in the debian file into the Thuban CVS recently. Unfortunately, it has no rater image support since gdal is not yet available as Debian package. This is being worked on currently. Best Jan -- Jan-Oliver Wagner http://intevation.de/~jan/ Intevation GmbH http://intevation.de/ FreeGIS http://freegis.org/ From bh at intevation.de Mon Oct 20 14:55:47 2003 From: bh at intevation.de (Bernhard Herzog) Date: Mon, 20 Oct 2003 14:55:47 +0200 Subject: [Thuban-list] arcview comparition and thuban.mo References: <200310131605.h9DG5AD3026052@www38.web2010.com> <6qad834py8.fsf@salmakis.intevation.de> Message-ID: <6qn0bwhxv0.fsf@salmakis.intevation.de> Bernhard Herzog writes: > While Python's speed is certainly an issue, I'm not sure how much impact > that still has on the rendering especially in the case of rendering from > shapefiles and without classifications. I did some simple timings last week. The test map was just the roads-line.shp and political.shp from the iceland data, no classifications, just a 1 pixel line for both layers plus a fill for the "political" layer. Normal rendering (with the low-level C++ accelerator) takes about 0.041 seconds on my machine. If I replace the low-level redering function with a no-op so that basically everything but the low-level renderer is executed it only takes 0.0115 seconds. So the low-level renderer takes about 70% of the rendering time. Some things to keep in mind here: - low-level renderer means that it uses shapelib to read the geometry of a shape, applies some coordinate transformations and produces an array of wxPoints to pass to a wxDC. On my system with wxGTK that array is then converted to an array of gdkpoints (which again involves some coordinate transformation) and passed to gdk_draw_polygon which hands the array over to the appropriate xlib function (with only a cast since GdkPoint has the same structure as an XPoint). Xlib then serializes this and sends it to the X server on the same computer. Some more timing tests where the actual calls to the wxDC methods DrawPolygon and DrawLines were commented out in wxproj.cpp indicate that the wxWindows/gtk/xlib part takes about 0.015 seconds. - The timings only take the client side into account. This can be misleading when timing rendering speed on X because it can happen that the client is already finished while the server still processes the requests sent by the client. I don't think this is much of a problem here, though, and in any case it wouldn't change anything regarding the impact of Python (if anything the non-python parts take longer). - The timing results depend a lot on the whether there are layers with classifications, the data source (shapefile vs. postgis) and the type of shapes (currently there's no C++ low-level renderer for points for instance), among others. The percentage of time spent in the low-level renderer is largest for the case I looked at. Bernhard -- Intevation GmbH http://intevation.de/ Sketch http://sketch.sourceforge.net/ Thuban http://thuban.intevation.org/ From jan at intevation.de Mon Oct 20 15:49:52 2003 From: jan at intevation.de (Jan-Oliver Wagner) Date: Mon, 20 Oct 2003 15:49:52 +0200 Subject: [Thuban-list] Status and Roadmap Message-ID: <20031020134952.GA6899@intevation.de> Hi, I've delayed the roadmap towards 1.0 for another month. There are two aspects why additional time is required: First, Bernhard Herzog detected a number of bugs in the projection management while he tried to add EPSG support. Second, performance appears to be an issue as reported from people on this list. The speed for rendering the maps has definitely to be improved for 1.0. I hope this could be done with the additional 4 weeks. If not we should delay again, because better performance is very important. Good news is that it is being worked on a SVG export. The aim is better support for printing maps. However, this work is independent from the roadmap for 1.0. Best Jan -- Jan-Oliver Wagner http://intevation.de/~jan/ Intevation GmbH http://intevation.de/ FreeGIS http://freegis.org/ From frank.koormann at intevation.de Wed Oct 22 13:27:37 2003 From: frank.koormann at intevation.de (Frank Koormann) Date: Wed, 22 Oct 2003 13:27:37 +0200 Subject: [Thuban-list] Thuban Logo In-Reply-To: <20031007105803.GD23504@intevation.de> References: <20031007091621.GA12976@intevation.de> <20031007105803.GD23504@intevation.de> Message-ID: <20031022112737.GA8084@intevation.de> * Bernhard Reiter [031007 12:58]: > On Tue, Oct 07, 2003 at 11:16:21AM +0200, Jan-Oliver Wagner wrote: > > approaching release 1.0 it is time to think about a logo for > > Thuban. Frank Koormann prepared some studies: > > http://thuban.intevation.org/logos/logos.html > > What do you think? > Added a winged version of Logo1 as pproposed by Jan. > The proposals are more like icons than logos. The page title is somewhat misleading. The explanatory texts are more precise. I was thinking of an icon. A logo is already on the first page. > > If we were searching for a logo, > I'd say it should contain some letters of "Thuban". > I fear using a "T" will have the potential for a bunch of new problems ... Frank -- Frank Koormann Professional Service around Free Software (http://intevation.net/) FreeGIS Project (http://freegis.org/) From jan at intevation.de Fri Oct 24 11:03:08 2003 From: jan at intevation.de (Jan-Oliver Wagner) Date: Fri, 24 Oct 2003 11:03:08 +0200 Subject: [Thuban-list] extend context menu of legend? Message-ID: <20031024090308.GC3749@intevation.de> Hi, thanks to Frank Koormann for adding the context menu for the legend. Currently, it contains the same commands as available from the legend's toolbar. However, I propose to add two further items to this menu: - Show Table - Remove Layer What do you think? Jan -- Jan-Oliver Wagner http://intevation.de/~jan/ Intevation GmbH http://intevation.de/ FreeGIS http://freegis.org/ From bh at intevation.de Mon Oct 27 18:55:29 2003 From: bh at intevation.de (Bernhard Herzog) Date: Mon, 27 Oct 2003 18:55:29 +0100 Subject: [Thuban-list] Spanish and French translation updates In-Reply-To: <6qn0cdcq1e.fsf@salmakis.intevation.de> (Bernhard Herzog's message of "Tue, 07 Oct 2003 12:15:09 +0200") References: <20030927182841.M55509@minag.gob.pe> <6qn0cdcq1e.fsf@salmakis.intevation.de> Message-ID: <6qbrs2k1ke.fsf@salmakis.intevation.de> Bernhard Herzog writes: > While I've found a way to make the utf8 po-files work with my > installation (by using wxGetTranslation instead of the python gettext > module) I've implemented this anyway. Not only does this do the automatic encoding conversion, it also means that the standard wx texts are translated. Since the encoding is automatically converted now, I've checked in the po files as they are. Bernhard -- Intevation GmbH http://intevation.de/ Sketch http://sketch.sourceforge.net/ Thuban http://thuban.intevation.org/ From frank.koormann at intevation.de Fri Oct 31 11:17:27 2003 From: frank.koormann at intevation.de (Frank Koormann) Date: Fri, 31 Oct 2003 11:17:27 +0100 Subject: [Thuban-list] extend context menu of legend? In-Reply-To: <20031024090308.GC3749@intevation.de> References: <20031024090308.GC3749@intevation.de> Message-ID: <20031031101727.GB27795@intevation.de> Hi, * Jan-Oliver Wagner [031024 12:03]: > Hi, > > thanks to Frank Koormann for adding the context menu for the legend. > Currently, it contains the same commands as available from the legend's > toolbar. > However, I propose to add two further items to this menu: > - Show Table > - Remove Layer > What do you think? The layer projection was the first item from outside the legend panel bar. However, I've added remove layer/show table as well. Frank -- Frank Koormann Professional Service around Free Software (http://intevation.net/) FreeGIS Project (http://freegis.org/) From jan at intevation.de Fri Oct 31 12:09:29 2003 From: jan at intevation.de (Jan-Oliver Wagner) Date: Fri, 31 Oct 2003 12:09:29 +0100 Subject: [Thuban-list] extend context menu of legend? In-Reply-To: <20031031101727.GB27795@intevation.de> References: <20031024090308.GC3749@intevation.de> <20031031101727.GB27795@intevation.de> Message-ID: <20031031110929.GC5607@intevation.de> On Fri, Oct 31, 2003 at 11:17:27AM +0100, Frank Koormann wrote: > The layer projection was the first item from outside the legend panel > bar. However, I've added remove layer/show table as well. cool. Thanks! Jan -- Jan-Oliver Wagner http://intevation.de/~jan/ Intevation GmbH http://intevation.de/ FreeGIS http://freegis.org/ From jan at intevation.de Fri Oct 31 18:02:51 2003 From: jan at intevation.de (Jan-Oliver Wagner) Date: Fri, 31 Oct 2003 18:02:51 +0100 Subject: [Thuban-list] view render perfomance Message-ID: <20031031170251.GA7017@intevation.de> Hi, Bernhard Herzog today checked in a Thuban extension that measures the time required for rendering the current map. There is also a profile analysis, but thats more for experts who are into the code. You can activate the extension with adding this to ~/.thuban/thubanstart.py: import Extensions.profiling.profiling Now you should have a Profiling submenu under Extensions menu. There are some performance improvement in preparation. However, it might be interesting for you to test one of your typical maps already now and later on, when some tuning is checked into CVS. Have fun :-) Attached is a screenshot for illustration. Best Jan -- Jan-Oliver Wagner http://intevation.de/~jan/ Intevation GmbH http://intevation.de/ FreeGIS http://freegis.org/ -------------- next part -------------- A non-text attachment was scrubbed... Name: screenshot.png Type: image/png Size: 25045 bytes Desc: not available Url : http://www.intevation.de/pipermail/thuban-list/attachments/20031031/84e4ebf0/screenshot.png