From bernhard at intevation.de Tue Mar 13 23:40:21 2007 From: bernhard at intevation.de (Bernhard Reiter) Date: Tue, 13 Mar 2007 23:40:21 +0100 Subject: Thuban 1.2.0 source released. Message-ID: <200703132340.27664.bernhard@intevation.de> Thuban's new stable release is 1.2.0. The source just got released on Wald: Download from "Files" at http://wald.intevation.org/projects/thuban/. With the source being ready for quite a while, it was important to get is out, even when there is no real announcement - yet. If you are a packager or a translator, this release is for you. :) Work on this release was done by Didrik Pinte and Bernhard Reiter. sparkle-sparkle-thuban-ly, Bernhard -- Managing Director - Owner: www.intevation.net (Free Software Company) Germany Coordinator: fsfeurope.org. Coordinator: www.Kolab-Konsortium.com. Intevation GmbH, Osnabr?ck, DE; Amtsgericht Osnabr?ck, HRB 18998 Gesch?ftsf?hrer Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner -------------- 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/20070313/72d568c8/attachment.bin From dpinte at itae.be Tue Mar 13 23:50:55 2007 From: dpinte at itae.be (Didrik Pinte) Date: Tue, 13 Mar 2007 23:50:55 +0100 Subject: [Thuban-list] Thuban 1.2.0 source released. In-Reply-To: <200703132340.27664.bernhard@intevation.de> References: <200703132340.27664.bernhard@intevation.de> Message-ID: <1173826255.19010.1.camel@geru-itae> Le mardi 13 mars 2007 ? 23:40 +0100, Bernhard Reiter a ?crit : > Thuban's new stable release is 1.2.0. > > The source just got released on Wald: > Download from "Files" at http://wald.intevation.org/projects/thuban/. > > With the source being ready for quite a while, it was important to get is out, > even when there is no real announcement - yet. > > If you are a packager or a translator, this release is for you. :) > Work on this release was done by Didrik Pinte and Bernhard Reiter. > > sparkle-sparkle-thuban-ly, > Bernhard Good news ! I'll try to get an official win32 build tomorrow ;-) Didrik -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: Ceci est une partie de message =?ISO-8859-1?Q?num=E9riquement?= =?ISO-8859-1?Q?_sign=E9e?= Url : http://www.intevation.de/pipermail/thuban-devel/attachments/20070313/5b6bb845/attachment.bin From dpinte at itae.be Wed Mar 14 00:05:37 2007 From: dpinte at itae.be (Didrik Pinte) Date: Wed, 14 Mar 2007 00:05:37 +0100 Subject: pyshapelib branch Message-ID: <1173827137.19010.7.camel@geru-itae> Bram, I've just downloaded the pyshapelib branch and tested thuban with it. The tests runs fine. The UI behaves greatly. I've updated the Thuban setup.py script. It's in the branch. It builds fine. Do someone else plan to test this branch ? Bram, do you also plan to update the dbflib part of the library ? Didrik -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: Ceci est une partie de message =?ISO-8859-1?Q?num=E9riquement?= =?ISO-8859-1?Q?_sign=E9e?= Url : http://www.intevation.de/pipermail/thuban-devel/attachments/20070314/bb5f722c/attachment.bin From bram.degreve at gmail.com Wed Mar 14 00:37:47 2007 From: bram.degreve at gmail.com (Bram de Greve) Date: Wed, 14 Mar 2007 00:37:47 +0100 Subject: pyshapelib branch In-Reply-To: <1173827137.19010.7.camel@geru-itae> References: <1173827137.19010.7.camel@geru-itae> Message-ID: <1d5b08270703131637q651f2f1cg8d7633a699c6ad69@mail.gmail.com> Hi Didrik, I'm planning my update in stages. First I'm getting rid of SWIG in favour of hand-crafted bindings. I've done that now for shapelib. I will do it for dbflib as well, and then I'm going to add the support for Z and M values to shapelib Though I am cheating a little bit, I've already added part_types() and __repr__ to SHPObject (__repr__ returns a string that can reconstruct the object when feeded to eval()) Can you specifically test for the Unicode issues. The python documentation says that Unicode should be supported by the methods I've used, but if this is really true, I do not know (yet). I haven't tried =) I'm gonna try to build the branch using your new setup.py Bram On 3/14/07, Didrik Pinte wrote: > > Bram, > > I've just downloaded the pyshapelib branch and tested thuban with it. > > The tests runs fine. The UI behaves greatly. > > I've updated the Thuban setup.py script. It's in the branch. It builds > fine. > > Do someone else plan to test this branch ? > > Bram, do you also plan to update the dbflib part of the library ? > > Didrik > > _______________________________________________ > Thuban-devel mailing list > Thuban-devel at intevation.de > https://intevation.de/mailman/listinfo/thuban-devel > > > -- hi, i'm a signature viruz, plz set me as your signature and help me spread :) -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.intevation.de/pipermail/thuban-devel/attachments/20070314/c5e43c66/attachment.html From dpinte at itae.be Wed Mar 14 00:47:09 2007 From: dpinte at itae.be (Didrik Pinte) Date: Wed, 14 Mar 2007 00:47:09 +0100 Subject: pyshapelib branch In-Reply-To: <1d5b08270703131637q651f2f1cg8d7633a699c6ad69@mail.gmail.com> References: <1173827137.19010.7.camel@geru-itae> <1d5b08270703131637q651f2f1cg8d7633a699c6ad69@mail.gmail.com> Message-ID: <1173829629.19010.10.camel@geru-itae> Le mercredi 14 mars 2007 ? 00:37 +0100, Bram de Greve a ?crit : > Hi Didrik, > > I'm planning my update in stages. First I'm getting rid of SWIG in > favour of hand-crafted bindings. I've done that now for shapelib. I > will do it for dbflib as well, and then I'm going to add the support > for Z and M values to shapelib Great ! > Though I am cheating a little bit, I've already added part_types() and > __repr__ to SHPObject (__repr__ returns a string that can reconstruct > the object when feeded to eval()) > > Can you specifically test for the Unicode issues. The python > documentation says that Unicode should be supported by the methods > I've used, but if this is really true, I do not know (yet). I haven't > tried =) I'll do it and try to create a test case. > > I'm gonna try to build the branch using your new setup.py FYI, on my Debian/sid system, i have to build it the extensions with : python setup.py build_ext --use-wx-python-swig-hack See the doc for more info. Good evening, Didrik -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: Ceci est une partie de message =?ISO-8859-1?Q?num=E9riquement?= =?ISO-8859-1?Q?_sign=E9e?= Url : http://www.intevation.de/pipermail/thuban-devel/attachments/20070314/539d3c5a/attachment.bin From dpinte at itae.be Wed Mar 14 01:00:32 2007 From: dpinte at itae.be (Didrik Pinte) Date: Wed, 14 Mar 2007 01:00:32 +0100 Subject: pyshapelib branch In-Reply-To: <1d5b08270703131637q651f2f1cg8d7633a699c6ad69@mail.gmail.com> References: <1173827137.19010.7.camel@geru-itae> <1d5b08270703131637q651f2f1cg8d7633a699c6ad69@mail.gmail.com> Message-ID: <1173830432.19010.14.camel@geru-itae> Le mercredi 14 mars 2007 ? 00:37 +0100, Bram de Greve a ?crit : > Can you specifically test for the Unicode issues. The python > documentation says that Unicode should be supported by the methods > I've used, but if this is really true, I do not know (yet). I haven't > tried =) Concerning the unicode issue, the problem is more concerned by the dbflib than shapelib. When trying to open a file with a unicode name, I get the following error : An unhandled exception occurred: 'ascii' codec can't encode character u'\xe9' in position 23: ordinal not in range(128) (please report to http://thuban.intevation.org/bugtracker.html) Traceback (most recent call last): File "/home/did/projets/python/thuban/bramz/Thuban/UI/mainwindow.py", line 297, in invoke_command command.Execute(self.Context()) File "/home/did/projets/python/thuban/bramz/test/../Thuban/UI/command.py", line 121, in Execute apply(self.function, (context,) + self.args + args, kw) File "/home/did/projets/python/thuban/bramz/Thuban/UI/mainwindow.py", line 1071, in call_method apply(getattr(context.mainwindow, methodname), args) File "/home/did/projets/python/thuban/bramz/Thuban/UI/mainwindow.py", line 573, in AddLayer store = self.application.Session().OpenShapefile(filename) File "/home/did/projets/python/thuban/bramz/test/../Thuban/Model/session.py", line 296, in OpenShapefile store = ShapefileStore(self, filename) File "/home/did/projets/python/thuban/bramz/test/../Thuban/Model/data.py", line 201, in __init__ self.dbftable = table.DBFTable(filename) File "/home/did/projets/python/thuban/bramz/test/../Thuban/Model/table.py", line 89, in __init__ self.dbf = dbflib.DBFFile(filename) File "/home/did/projets/python/thuban/bramz/Thuban/../Lib/dbflib.py", line 5, in __init__ self.this = apply(dbflibc.new_DBFFile,args) UnicodeEncodeError: 'ascii' codec can't encode character u'\xe9' in position 23: ordinal not in range(128) Didrik -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: Ceci est une partie de message =?ISO-8859-1?Q?num=E9riquement?= =?ISO-8859-1?Q?_sign=E9e?= Url : http://www.intevation.de/pipermail/thuban-devel/attachments/20070314/fd3f5acf/attachment.bin From bram.degreve at gmail.com Wed Mar 14 01:15:02 2007 From: bram.degreve at gmail.com (Bram de Greve) Date: Wed, 14 Mar 2007 01:15:02 +0100 Subject: pyshapelib branch In-Reply-To: <1173830432.19010.14.camel@geru-itae> References: <1173827137.19010.7.camel@geru-itae> <1d5b08270703131637q651f2f1cg8d7633a699c6ad69@mail.gmail.com> <1173830432.19010.14.camel@geru-itae> Message-ID: <45F73E86.3010305@gmail.com> I've looked a bit further into the issue and the Python documentation that the Unicode issue will not be resolved the way I've handled it. It will try the default encoding (which is 'ascii') and thus fail as well. The question of course is, what encoding should be used instead. utf-8? utf-16? Bramz Didrik Pinte wrote: > Le mercredi 14 mars 2007 ? 00:37 +0100, Bram de Greve a ?crit : > >> Can you specifically test for the Unicode issues. The python >> documentation says that Unicode should be supported by the methods >> I've used, but if this is really true, I do not know (yet). I haven't >> tried =) >> > > Concerning the unicode issue, the problem is more concerned by the > dbflib than shapelib. > > When trying to open a file with a unicode name, I get the following > error : > > An unhandled exception occurred: > 'ascii' codec can't encode character u'\xe9' in position 23: ordinal not > in range(128) > (please report to http://thuban.intevation.org/bugtracker.html) > > Traceback (most recent call last): > File "/home/did/projets/python/thuban/bramz/Thuban/UI/mainwindow.py", > line 297, in invoke_command > command.Execute(self.Context()) > File > "/home/did/projets/python/thuban/bramz/test/../Thuban/UI/command.py", > line 121, in Execute > apply(self.function, (context,) + self.args + args, kw) > File "/home/did/projets/python/thuban/bramz/Thuban/UI/mainwindow.py", > line 1071, in call_method > apply(getattr(context.mainwindow, methodname), args) > File "/home/did/projets/python/thuban/bramz/Thuban/UI/mainwindow.py", > line 573, in AddLayer > store = self.application.Session().OpenShapefile(filename) > File > "/home/did/projets/python/thuban/bramz/test/../Thuban/Model/session.py", > line 296, in OpenShapefile > store = ShapefileStore(self, filename) > File > "/home/did/projets/python/thuban/bramz/test/../Thuban/Model/data.py", > line 201, in __init__ > self.dbftable = table.DBFTable(filename) > File > "/home/did/projets/python/thuban/bramz/test/../Thuban/Model/table.py", > line 89, in __init__ > self.dbf = dbflib.DBFFile(filename) > File "/home/did/projets/python/thuban/bramz/Thuban/../Lib/dbflib.py", > line 5, in __init__ > self.this = apply(dbflibc.new_DBFFile,args) > UnicodeEncodeError: 'ascii' codec can't encode character u'\xe9' in > position 23: ordinal not in range(128) > > Didrik > > > ------------------------------------------------------------------------ > > _______________________________________________ > Thuban-devel mailing list > Thuban-devel at intevation.de > https://intevation.de/mailman/listinfo/thuban-devel > From dpinte at itae.be Wed Mar 14 01:30:02 2007 From: dpinte at itae.be (Didrik Pinte) Date: Wed, 14 Mar 2007 01:30:02 +0100 Subject: pyshapelib branch In-Reply-To: <45F73E86.3010305@gmail.com> References: <1173827137.19010.7.camel@geru-itae> <1d5b08270703131637q651f2f1cg8d7633a699c6ad69@mail.gmail.com> <1173830432.19010.14.camel@geru-itae> <45F73E86.3010305@gmail.com> Message-ID: <1173832202.19010.28.camel@geru-itae> Le mercredi 14 mars 2007 ? 01:15 +0100, Bram de Greve a ?crit : > I've looked a bit further into the issue and the Python documentation > that the Unicode issue will not be resolved the way I've handled it. It > will try the default encoding (which is 'ascii') and thus fail as well. > The question of course is, what encoding should be used instead. utf-8? > utf-16? > > Bramz Hi Bram, The good way to handle this is to use the user's locale... For example, i'm using fr_BE at UTF-8 locales but some systems here are still fr_BE at ISO-8859-1 . Considering Thuban, it has an internal encoding that should be full utf-8 (Bernhard, correct me if i'm wrong) Looking at thuban/Doc/technotes/string_representation.txt and thuban/Thuban/__init__.py, it's not already the case. Didrik -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: Ceci est une partie de message =?ISO-8859-1?Q?num=E9riquement?= =?ISO-8859-1?Q?_sign=E9e?= Url : http://www.intevation.de/pipermail/thuban-devel/attachments/20070314/dd363a96/attachment.bin From bernhard at intevation.de Wed Mar 14 10:33:55 2007 From: bernhard at intevation.de (Bernhard Reiter) Date: Wed, 14 Mar 2007 10:33:55 +0100 Subject: pyshapelib branch In-Reply-To: <1173829629.19010.10.camel@geru-itae> References: <1173827137.19010.7.camel@geru-itae> <1d5b08270703131637q651f2f1cg8d7633a699c6ad69@mail.gmail.com> <1173829629.19010.10.camel@geru-itae> Message-ID: <200703141033.56782.bernhard@intevation.de> On Wednesday 14 March 2007 00:47, Didrik Pinte wrote: > > Can you specifically test for the Unicode issues. ?The python > > documentation says that Unicode should be supported by the methods > > I've used, but if this is really true, I do not know (yet). ?I haven't > > tried =) > > I'll do it and try to create a test case. Good, do all the other tests run still with Bram's refactoring of pyshapelib? :) -- Managing Director - Owner: www.intevation.net (Free Software Company) Germany Coordinator: fsfeurope.org. Coordinator: www.Kolab-Konsortium.com. Intevation GmbH, Osnabr?ck, DE; Amtsgericht Osnabr?ck, HRB 18998 Gesch?ftsf?hrer Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner -------------- 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/20070314/1db52a5c/attachment.bin From bernhard at intevation.de Wed Mar 14 10:42:06 2007 From: bernhard at intevation.de (Bernhard Reiter) Date: Wed, 14 Mar 2007 10:42:06 +0100 Subject: pyshapelib branch In-Reply-To: <1173832202.19010.28.camel@geru-itae> References: <1173827137.19010.7.camel@geru-itae> <45F73E86.3010305@gmail.com> <1173832202.19010.28.camel@geru-itae> Message-ID: <200703141042.07197.bernhard@intevation.de> On Wednesday 14 March 2007 01:30, Didrik Pinte wrote: > The good way to handle this is to use the user's locale... For example, > i'm using fr_BE at UTF-8 locales but some systems here are still > fr_BE at ISO-8859-1 . It depends on what input you would want to convert. I do not know for sure, but I have a feeling that most .dbf files will not be unicode (utf-8, utf-16 or similiar), but rather latin1 or similiar. So for a dbf file, if you do not know more, I think trying to convert from "latin1" is reasonable. > Considering Thuban, it has an internal encoding that should be full > utf-8 (Bernhard, correct me if i'm wrong) Well, string_representation.txt describes the plan to fully switch to unicode Python "objects" in all cases. Currently I think Thuban can run with several different internal encodings. > Looking at > thuban/Doc/technotes/string_representation.txt and > thuban/Thuban/__init__.py, it's not already the case. _internal_encoding can be "unicode". Bernhard -- Managing Director - Owner: www.intevation.net (Free Software Company) Germany Coordinator: fsfeurope.org. Coordinator: www.Kolab-Konsortium.com. Intevation GmbH, Osnabr?ck, DE; Amtsgericht Osnabr?ck, HRB 18998 Gesch?ftsf?hrer Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner -------------- 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/20070314/d495748e/attachment.bin From dpinte at itae.be Wed Mar 14 11:10:06 2007 From: dpinte at itae.be (Didrik Pinte) Date: Wed, 14 Mar 2007 11:10:06 +0100 Subject: pyshapelib branch In-Reply-To: <200703141033.56782.bernhard@intevation.de> References: <1173827137.19010.7.camel@geru-itae> <1d5b08270703131637q651f2f1cg8d7633a699c6ad69@mail.gmail.com> <1173829629.19010.10.camel@geru-itae> <200703141033.56782.bernhard@intevation.de> Message-ID: <1173867006.24494.18.camel@geru-itae> Le mercredi 14 mars 2007 ? 10:33 +0100, Bernhard Reiter a ?crit : > On Wednesday 14 March 2007 00:47, Didrik Pinte wrote: > > > Can you specifically test for the Unicode issues. The python > > > documentation says that Unicode should be supported by the methods > > > I've used, but if this is really true, I do not know (yet). I haven't > > > tried =) > > > > I'll do it and try to create a test case. > > Good, do all the other tests run still with Bram's refactoring of > pyshapelib? :) Running thuban/test/runtests.py on the first version Bram has commited worked fine out of the box ;-) Didrik -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: Ceci est une partie de message =?ISO-8859-1?Q?num=E9riquement?= =?ISO-8859-1?Q?_sign=E9e?= Url : http://www.intevation.de/pipermail/thuban-devel/attachments/20070314/833c7000/attachment.bin From dpinte at itae.be Wed Mar 14 12:01:04 2007 From: dpinte at itae.be (Didrik Pinte) Date: Wed, 14 Mar 2007 12:01:04 +0100 Subject: Thuban 1.2.0 installer for win32 released In-Reply-To: <200703132340.27664.bernhard@intevation.de> References: <200703132340.27664.bernhard@intevation.de> Message-ID: <1173870064.24494.25.camel@geru-itae> Hi, The win32 installer for Thuban has been updated to the 1.2.0 version. It has been built for Python 2.4 and wxPython 2.6.3.3 and include proj 4.4.9 and gdal 1.4.0. You can download it here : http://wald.intevation.org/frs/?group_id=6 --> Thuban-1.2.0_1.exe Didrik -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: Ceci est une partie de message =?ISO-8859-1?Q?num=E9riquement?= =?ISO-8859-1?Q?_sign=E9e?= Url : http://www.intevation.de/pipermail/thuban-devel/attachments/20070314/4f5bd102/attachment.bin From bram.degreve at gmail.com Wed Mar 14 13:44:11 2007 From: bram.degreve at gmail.com (Bram de Greve) Date: Wed, 14 Mar 2007 13:44:11 +0100 Subject: Thuban 1.2.0 installer for win32 released In-Reply-To: <1173870064.24494.25.camel@geru-itae> References: <200703132340.27664.bernhard@intevation.de> <1173870064.24494.25.camel@geru-itae> Message-ID: <1d5b08270703140544l126f580bvb2dcbf8529d7bc4e@mail.gmail.com> Hi Didrik, I tried to install it, but it seems to have gdal14.dll missing. Bram On 3/14/07, Didrik Pinte wrote: > > Hi, > > The win32 installer for Thuban has been updated to the 1.2.0 version. > > It has been built for Python 2.4 and wxPython 2.6.3.3 and include proj > 4.4.9 and gdal 1.4.0. > > You can download it here : > > http://wald.intevation.org/frs/?group_id=6 --> Thuban-1.2.0_1.exe > > Didrik > > _______________________________________________ > Thuban-devel mailing list > Thuban-devel at intevation.de > https://intevation.de/mailman/listinfo/thuban-devel > > > -- hi, i'm a signature viruz, plz set me as your signature and help me spread :) -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.intevation.de/pipermail/thuban-devel/attachments/20070314/3e2636f2/attachment.html From dpinte at itae.be Wed Mar 14 14:13:22 2007 From: dpinte at itae.be (Didrik Pinte) Date: Wed, 14 Mar 2007 14:13:22 +0100 Subject: Thuban 1.2.0 installer for win32 released In-Reply-To: <1d5b08270703140544l126f580bvb2dcbf8529d7bc4e@mail.gmail.com> References: <200703132340.27664.bernhard@intevation.de> <1173870064.24494.25.camel@geru-itae> <1d5b08270703140544l126f580bvb2dcbf8529d7bc4e@mail.gmail.com> Message-ID: <1173878002.24494.27.camel@geru-itae> Le mercredi 14 mars 2007 ? 13:44 +0100, Bram de Greve a ?crit : > Hi Didrik, > > I tried to install it, but it seems to have gdal14.dll missing. > > Bram Hi Bram, No it's not missing. It's just that you have to update your PATH environment variables in order to point to the directory containing the DLL. PATH must contain : C:\Program Files\Thuban\gdal\bin if you have installed it in the default location. Didrik -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: Ceci est une partie de message =?ISO-8859-1?Q?num=E9riquement?= =?ISO-8859-1?Q?_sign=E9e?= Url : http://www.intevation.de/pipermail/thuban-devel/attachments/20070314/d4d943aa/attachment.bin From bernhard at intevation.de Wed Mar 14 15:14:42 2007 From: bernhard at intevation.de (Bernhard Reiter) Date: Wed, 14 Mar 2007 15:14:42 +0100 Subject: Thuban 1.2.0 installer for win32 released In-Reply-To: <1173878002.24494.27.camel@geru-itae> References: <200703132340.27664.bernhard@intevation.de> <1d5b08270703140544l126f580bvb2dcbf8529d7bc4e@mail.gmail.com> <1173878002.24494.27.camel@geru-itae> Message-ID: <200703141514.46895.bernhard@intevation.de> On Wednesday 14 March 2007 14:13, Didrik Pinte wrote: > No it's not missing. It's just that you have to update your PATH > environment variables in order to point to the directory containing the > DLL. Maybe you should point people to the release notes in the little announce email. :) (Or have a section in the installer that shows a message about this.) Bernhard -- Managing Director - Owner: www.intevation.net (Free Software Company) Germany Coordinator: fsfeurope.org. Coordinator: www.Kolab-Konsortium.com. Intevation GmbH, Osnabr?ck, DE; Amtsgericht Osnabr?ck, HRB 18998 Gesch?ftsf?hrer Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner -------------- 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/20070314/a750fd58/attachment.bin From bram.degreve at gmail.com Wed Mar 14 15:23:20 2007 From: bram.degreve at gmail.com (Bram de Greve) Date: Wed, 14 Mar 2007 15:23:20 +0100 Subject: Thuban 1.2.0 installer for win32 released In-Reply-To: <1173878002.24494.27.camel@geru-itae> References: <200703132340.27664.bernhard@intevation.de> <1173870064.24494.25.camel@geru-itae> <1d5b08270703140544l126f580bvb2dcbf8529d7bc4e@mail.gmail.com> <1173878002.24494.27.camel@geru-itae> Message-ID: <1d5b08270703140723n7f2547c8gfae9418d3ef3e661@mail.gmail.com> On 3/14/07, Didrik Pinte wrote: > > > No it's not missing. It's just that you have to update your PATH > environment variables in order to point to the directory containing the > DLL. > > PATH must contain : > > C:\Program Files\Thuban\gdal\bin > > if you have installed it in the default location. > > Didrik Well, if I find a nice windows installer (very nice, btw!) I expect it to be "batteries included" ;) If that's not the case, at least displaying a clear message about this matter woudl be nice, as Bernhard also says Bram -- hi, i'm a signature viruz, plz set me as your signature and help me spread :) -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.intevation.de/pipermail/thuban-devel/attachments/20070314/33ba7f01/attachment.html From bram.degreve at gmail.com Wed Mar 14 17:29:12 2007 From: bram.degreve at gmail.com (Bram de Greve) Date: Wed, 14 Mar 2007 17:29:12 +0100 Subject: pyshapelib branch In-Reply-To: <1173827137.19010.7.camel@geru-itae> References: <1173827137.19010.7.camel@geru-itae> Message-ID: <1d5b08270703140929n6b2d90e5h3ac15f57f737ca01@mail.gmail.com> I've just commited my dbflib rewrite to the branch. Unicode strings not, i repeat ;), not supported as for now. First, I'll integrate the Z and M value support, then we'll see about Unicode issues =) Bramz On 3/14/07, Didrik Pinte wrote: > > Bram, > > I've just downloaded the pyshapelib branch and tested thuban with it. > > The tests runs fine. The UI behaves greatly. > > I've updated the Thuban setup.py script. It's in the branch. It builds > fine. > > Do someone else plan to test this branch ? > > Bram, do you also plan to update the dbflib part of the library ? > > Didrik > > _______________________________________________ > Thuban-devel mailing list > Thuban-devel at intevation.de > https://intevation.de/mailman/listinfo/thuban-devel > > > -- hi, i'm a signature viruz, plz set me as your signature and help me spread :) -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.intevation.de/pipermail/thuban-devel/attachments/20070314/6e681546/attachment.html From bram.degreve at gmail.com Wed Mar 14 21:57:26 2007 From: bram.degreve at gmail.com (Bram de Greve) Date: Wed, 14 Mar 2007 21:57:26 +0100 Subject: pyshapelib branch In-Reply-To: <1d5b08270703140929n6b2d90e5h3ac15f57f737ca01@mail.gmail.com> References: <1173827137.19010.7.camel@geru-itae> <1d5b08270703140929n6b2d90e5h3ac15f57f737ca01@mail.gmail.com> Message-ID: <1d5b08270703141357y751f725r5f672b8fd6b712bd@mail.gmail.com> I've integrated the Z and M value support in the branch. It should be working alright. Bram On 3/14/07, Bram de Greve wrote: > > I've just commited my dbflib rewrite to the branch. > Unicode strings not, i repeat ;), not supported as for now. > First, I'll integrate the Z and M value support, then we'll see about > Unicode issues =) > > Bramz > > On 3/14/07, Didrik Pinte wrote: > > > > Bram, > > > > I've just downloaded the pyshapelib branch and tested thuban with it. > > > > The tests runs fine. The UI behaves greatly. > > > > I've updated the Thuban setup.py script. It's in the branch. It builds > > fine. > > > > Do someone else plan to test this branch ? > > > > Bram, do you also plan to update the dbflib part of the library ? > > > > Didrik > > > > _______________________________________________ > > Thuban-devel mailing list > > Thuban-devel at intevation.de > > https://intevation.de/mailman/listinfo/thuban-devel > > > > > > > > > -- > hi, i'm a signature viruz, plz set me as your signature and help me spread > :) > -- hi, i'm a signature viruz, plz set me as your signature and help me spread :) -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.intevation.de/pipermail/thuban-devel/attachments/20070314/7016371b/attachment.html From bernhard at intevation.de Thu Mar 15 10:03:06 2007 From: bernhard at intevation.de (Bernhard Reiter) Date: Thu, 15 Mar 2007 10:03:06 +0100 Subject: pyshapelib branch In-Reply-To: <1d5b08270703141357y751f725r5f672b8fd6b712bd@mail.gmail.com> References: <1173827137.19010.7.camel@geru-itae> <1d5b08270703140929n6b2d90e5h3ac15f57f737ca01@mail.gmail.com> <1d5b08270703141357y751f725r5f672b8fd6b712bd@mail.gmail.com> Message-ID: <200703151003.07889.bernhard@intevation.de> On Wednesday 14 March 2007 21:57, Bram de Greve wrote: > I've integrated the Z and M value support in the branch. ?It should be > working alright. Cool, do you have example code in there as well? -- Managing Director - Owner: www.intevation.net (Free Software Company) Germany Coordinator: fsfeurope.org. Coordinator: www.Kolab-Konsortium.com. Intevation GmbH, Osnabr?ck, DE; Amtsgericht Osnabr?ck, HRB 18998 Gesch?ftsf?hrer Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner -------------- 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/20070315/621f51bc/attachment.bin From bram.degreve at gmail.com Thu Mar 15 11:21:24 2007 From: bram.degreve at gmail.com (Bram de Greve) Date: Thu, 15 Mar 2007 11:21:24 +0100 Subject: pyshapelib branch In-Reply-To: <200703151003.07889.bernhard@intevation.de> References: <1173827137.19010.7.camel@geru-itae> <1d5b08270703140929n6b2d90e5h3ac15f57f737ca01@mail.gmail.com> <1d5b08270703141357y751f725r5f672b8fd6b712bd@mail.gmail.com> <200703151003.07889.bernhard@intevation.de> Message-ID: <1d5b08270703150321q67df2d5dj238d1187785fc036@mail.gmail.com> No, not yet ;) But I've hacked the pytest.py for a second and it seems to work just fine ... On 3/15/07, Bernhard Reiter wrote: > > On Wednesday 14 March 2007 21:57, Bram de Greve wrote: > > I've integrated the Z and M value support in the branch. It should be > > working alright. > > Cool, do you have example code in there as well? > > -- > Managing Director - Owner: www.intevation.net (Free Software > Company) > Germany Coordinator: fsfeurope.org. Coordinator: www.Kolab-Konsortium.com. > Intevation GmbH, Osnabr?ck, DE; Amtsgericht Osnabr?ck, HRB 18998 > Gesch?ftsf?hrer Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner > > _______________________________________________ > Thuban-devel mailing list > Thuban-devel at intevation.de > https://intevation.de/mailman/listinfo/thuban-devel > > > -- hi, i'm a signature viruz, plz set me as your signature and help me spread :) -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.intevation.de/pipermail/thuban-devel/attachments/20070315/eec4f069/attachment.html From bram.degreve at gmail.com Thu Mar 15 15:53:12 2007 From: bram.degreve at gmail.com (Bram de Greve) Date: Thu, 15 Mar 2007 15:53:12 +0100 Subject: pyshapelib unicode saga Message-ID: <1d5b08270703150753y368ef69apeb78a411587e099f@mail.gmail.com> Hi there, For a moment there I thought I've seen my change to support unicode for the filenames. But it was only for a moment =) I've looked in Python's source code how they handled things for their own file object, and I've mimicked it as far as I could. Key aspect seems to be to parse a string argument using "et" instead of "s" and to use Py_FileSystemDefaultEncoding as encoding. Except that it doesn't work ... First of all, FileSystemDefaultEncoding is only defined for windows (mbcs) and apple (utf-8), and not for Linux (NULL, meaning default encoding, meanding ascii). So linux still gets plagued by the same error Didrik had before. And yet, Python's file() seems to be able to copy with unicode filenames in Linux. Secondly, for windows mbcs is used, which is a lossy encoding (not all unicode can be represented using mbcs). This is necessary because the original shapelib library only uses the narrow (char*) API, and on windows that means mbcs encoding. To get full unicode support, the wide character API must be used instead (_wfopen), but shapelib simply doesn't support that. (Python's file() does precisely that on windows, in case of unicode it tries to use the wide character API) Then there's also the issue of the encoding of the field names and the string values. The easiest solution would be to fix everything on UTF-8 but I believe we could do better. It should be able to specify the encoding when opening or creating a DBFFile, defaulting to perhaps something specified by the locale. There's also the issue of backwards compatibility. Getting strings in the DBFFile isn't a problem since we can check whether the caller passes a unicode or a classic string, but getting out is. Should be always return unicode strings and risk some incompatibilities with calling code, or should be try to diversify (perhaps based on the used encoding, ascii encoding could return classic strings, or maybe based on another flag ...) Bram -- hi, i'm a signature viruz, plz set me as your signature and help me spread :) -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.intevation.de/pipermail/thuban-devel/attachments/20070315/b12c3589/attachment.html From aemphil at gmail.com Thu Mar 15 16:25:15 2007 From: aemphil at gmail.com (Philippe Le Grand) Date: Thu, 15 Mar 2007 10:25:15 -0500 Subject: pyshapelib unicode saga In-Reply-To: <1d5b08270703150753y368ef69apeb78a411587e099f@mail.gmail.com> References: <1d5b08270703150753y368ef69apeb78a411587e099f@mail.gmail.com> Message-ID: <3927aa550703150825s4a1fc28am8e4c147fab3a7fcf@mail.gmail.com> Bram, The DBF format specifies that field names and the contents of character fields are ASCII, using the OEM code page (a.k.a. IBM PC code page, a.k.a. code page 437; see wikipedia). I believe FoxPro uses a flag to identify alternate codepages at offset 1Dh in the header of the file, but whether that is actually part of the standard is unclear to me. You can find dbf file specs at: http://www.dbf2002.com/dbf-file-format.html (dbf III+ ,IV) or http://www.dbase.com/KnowledgeBase/int/db7_file_fmt.htm (dbf VII) The dbf associated with shapefiles is version III+, I believe. For portability (which is the only relevant purpose of shapefiles as far as I an concerned), you might want to restrict yourself to the most common features of the standard, i.e. ASCII field names and character field contents. Thanks for your work. I hope to be able to soon start testing, and giving you feedback. Philippe On 3/15/07, Bram de Greve wrote: > > Then there's also the issue of the encoding of the field names and the > string values. The easiest solution would be to fix everything > on UTF-8 but I believe we could do better. It should be able to specify the > encoding when opening or creating a DBFFile, defaulting > to perhaps something specified by the locale. > > There's also the issue of backwards compatibility. Getting strings in the > DBFFile isn't a problem since we can check whether the > caller passes a unicode or a classic string, but getting out is. Should be > always return unicode strings and risk some > incompatibilities with calling code, or should be try to diversify (perhaps > based on the used encoding, > ascii encoding could return classic strings, or maybe based on another flag > ...) > > Bram > > -- > hi, i'm a signature viruz, plz set me as your signature and help me spread > :) > _______________________________________________ > Thuban-devel mailing list > Thuban-devel at intevation.de > https://intevation.de/mailman/listinfo/thuban-devel > > From bram.degreve at gmail.com Thu Mar 15 16:25:44 2007 From: bram.degreve at gmail.com (Bram de Greve) Date: Thu, 15 Mar 2007 16:25:44 +0100 Subject: pyshapelib unicode saga In-Reply-To: <1d5b08270703150753y368ef69apeb78a411587e099f@mail.gmail.com> References: <1d5b08270703150753y368ef69apeb78a411587e099f@mail.gmail.com> Message-ID: <1d5b08270703150825r50d5ae40r4bb6533dfe81cb6f@mail.gmail.com> typo: first sentence: change -> chance =) Update on linux filenames: it seems to work after all, I was merely testing old code ;) Py_FileSystemDefaultEncoding (which resides in bltinmodule.c), is initially set to NULL in linux, but Py_InitializeEx in pythonrun.creinitializes it to nl_langinfo(CODESET). So that still leaves the issue of the wide character support on windows >NT, but that's a matter that first must be resolved by the shapelib library. Bram On 3/15/07, Bram de Greve wrote: > > Hi there, > > For a moment there I thought I've seen my change to support unicode for > the filenames. But it was only for a moment =) > > I've looked in Python's source code how they handled things for their own > file object, and I've mimicked it as far as I could. > Key aspect seems to be to parse a string argument using "et" instead of > "s" and to use Py_FileSystemDefaultEncoding as encoding. > Except that it doesn't work ... > > First of all, FileSystemDefaultEncoding is only defined for windows (mbcs) > and apple (utf-8), > and not for Linux (NULL, meaning default encoding, meanding ascii). So > linux still gets plagued by the same error Didrik had before. > And yet, Python's file() seems to be able to copy with unicode filenames > in Linux. > > Secondly, for windows mbcs is used, which is a lossy encoding (not all > unicode can be represented using mbcs). > This is necessary because the original shapelib library only uses the > narrow (char*) API, and on windows that means mbcs encoding. > To get full unicode support, the wide character API must be used instead > (_wfopen), but shapelib simply doesn't support that. > (Python's file() does precisely that on windows, in case of unicode it > tries to use the wide character API) > > Then there's also the issue of the encoding of the field names and the > string values. The easiest solution would be to fix everything > on UTF-8 but I believe we could do better. It should be able to specify > the encoding when opening or creating a DBFFile, defaulting > to perhaps something specified by the locale. > > There's also the issue of backwards compatibility. Getting strings in the > DBFFile isn't a problem since we can check whether the > caller passes a unicode or a classic string, but getting out is. Should > be always return unicode strings and risk some > incompatibilities with calling code, or should be try to diversify > (perhaps based on the used encoding, > ascii encoding could return classic strings, or maybe based on another > flag ...) > > Bram > > -- > hi, i'm a signature viruz, plz set me as your signature and help me spread > :) -- hi, i'm a signature viruz, plz set me as your signature and help me spread :) -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.intevation.de/pipermail/thuban-devel/attachments/20070315/93c634dd/attachment.html From bram.degreve at gmail.com Thu Mar 15 16:33:56 2007 From: bram.degreve at gmail.com (Bram de Greve) Date: Thu, 15 Mar 2007 16:33:56 +0100 Subject: pyshapelib unicode saga In-Reply-To: <3927aa550703150825s4a1fc28am8e4c147fab3a7fcf@mail.gmail.com> References: <1d5b08270703150753y368ef69apeb78a411587e099f@mail.gmail.com> <3927aa550703150825s4a1fc28am8e4c147fab3a7fcf@mail.gmail.com> Message-ID: <45F96764.4040203@gmail.com> Philippe Le Grand wrote: > Bram, > > The DBF format specifies that field names and the contents of > character fields are ASCII, using the OEM code page (a.k.a. IBM PC > code page, a.k.a. code page 437; see wikipedia). > I believe FoxPro uses a flag to identify alternate codepages at offset > 1Dh in the header of the file, but whether that is actually part of > the standard is unclear to me. > You can find dbf file specs at: > http://www.dbf2002.com/dbf-file-format.html (dbf III+ ,IV) > or http://www.dbase.com/KnowledgeBase/int/db7_file_fmt.htm (dbf VII) > > The dbf associated with shapefiles is version III+, I believe. > Great, I'll take a look at those ... > For portability (which is the only relevant purpose of shapefiles as > far as I an concerned), you might want to restrict yourself to the > most common features of the standard, i.e. ASCII field names and > character field contents. > OK, so, basically, there's no work that needs to be done if we follow the specs strictly, since current implementation only allows ASCII anyway =) But, OTOH, if Thuban aspires to use unicode all the way, we have found a barrier here. Anyway, if there would be some extension to support other encodings, at the very least the default should be ASCII ... > Thanks for your work. I hope to be able to soon start testing, and > giving you feedback. > > That would be great. Bram From bram.degreve at gmail.com Thu Mar 15 23:33:31 2007 From: bram.degreve at gmail.com (Bram de Greve) Date: Thu, 15 Mar 2007 23:33:31 +0100 Subject: pyshapelib branch In-Reply-To: <1d5b08270703150321q67df2d5dj238d1187785fc036@mail.gmail.com> References: <1173827137.19010.7.camel@geru-itae> <1d5b08270703140929n6b2d90e5h3ac15f57f737ca01@mail.gmail.com> <1d5b08270703141357y751f725r5f672b8fd6b712bd@mail.gmail.com> <200703151003.07889.bernhard@intevation.de> <1d5b08270703150321q67df2d5dj238d1187785fc036@mail.gmail.com> Message-ID: <1d5b08270703151533r1131dee6od3711f787cd1db27@mail.gmail.com> On 3/15/07, Bram de Greve wrote: > > No, not yet ;) But I've hacked the pytest.py for a second and it seems to > work just fine ... > > I've just committed a new pytest.py to the branch that includes some of the XYZM magic. As M value None is also accepted as no-data value (the default). ESRI defines any M value smaller than 1e-38 as no-data. This is only on the input side, not on the output because the original shapelib doesn't seem to be no-data aware. None is thus stored as a zero. -- hi, i'm a signature viruz, plz set me as your signature and help me spread :) -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.intevation.de/pipermail/thuban-devel/attachments/20070315/7fbf6105/attachment.html From bram.degreve at gmail.com Thu Mar 15 23:45:37 2007 From: bram.degreve at gmail.com (Bram de Greve) Date: Thu, 15 Mar 2007 23:45:37 +0100 Subject: pyshapelib branch In-Reply-To: <1173827137.19010.7.camel@geru-itae> References: <1173827137.19010.7.camel@geru-itae> Message-ID: <1d5b08270703151545i3b6cf8b7xcae01c1017524125@mail.gmail.com> I've just committed some more changes to my branch. Noteworthy are the folowing changes: - FTLogical is now also supported as a Python Bool. - When using shapes with a measurement M value, None is also accepted as input to represent the no-data. Internally it is stored as zero. ESRI defines any M value smaller than 1e-38 as no-data. On the "output" side, the zero is not converted to None again though. the original shapelib doesn't seem to be no-data aware and messes up the extents, so there's troubles there anyway. - where appropriate, added name and mode keywords to mimic Python's file() behaviour. - reformatted the doc strings a bit so it gets a standard look and feel when the module is parsed through pydoc. I guess where getting close to bumping up the version, merging back with the main branch (after testing of course ;), and doing a seperate release of pyshapelib. Unless we still want to do something about the internal Unicode support (currently it's still ASCII only, dbf specs don't really support Unicode, see other thread). And I also need to restore the "legal" headers =) Bram -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.intevation.de/pipermail/thuban-devel/attachments/20070315/d9c70139/attachment.html From bernhard at intevation.de Fri Mar 16 11:17:08 2007 From: bernhard at intevation.de (Bernhard Reiter) Date: Fri, 16 Mar 2007 11:17:08 +0100 Subject: pyshapelib branch In-Reply-To: <1d5b08270703151545i3b6cf8b7xcae01c1017524125@mail.gmail.com> References: <1173827137.19010.7.camel@geru-itae> <1d5b08270703151545i3b6cf8b7xcae01c1017524125@mail.gmail.com> Message-ID: <200703161117.09316.bernhard@intevation.de> On Thursday 15 March 2007 23:45, Bram de Greve wrote: > I guess where getting close to bumping up the version, merging back with > the main branch (after testing of course ;), and doing a seperate release > of pyshapelib. ?Unless we still want to do something about the internal > Unicode support (currently it's still ASCII only, dbf specs don't really > support Unicode, see other thread). ?And I also need to restore the "legal" > headers Wow, this all sounds good! About the ascii support, I must admitt that I so far have not fully understood all involved issues. We should at least have a document explaining our current knowledge and choices. For input site dbf we should certainly accept more (always latin1) then for writing it (which should be conservative). We could also have a look upon how other shapelib aware products like the ones from ESRI handle internationalisation. Bernhard -- Managing Director - Owner: www.intevation.net (Free Software Company) Germany Coordinator: fsfeurope.org. Coordinator: www.Kolab-Konsortium.com. Intevation GmbH, Osnabr?ck, DE; Amtsgericht Osnabr?ck, HRB 18998 Gesch?ftsf?hrer Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner -------------- 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/20070316/08292b8b/attachment.bin From dpinte at itae.be Fri Mar 16 12:08:19 2007 From: dpinte at itae.be (Didrik Pinte) Date: Fri, 16 Mar 2007 12:08:19 +0100 Subject: pyshapelib branch In-Reply-To: <200703161117.09316.bernhard@intevation.de> References: <1173827137.19010.7.camel@geru-itae> <1d5b08270703151545i3b6cf8b7xcae01c1017524125@mail.gmail.com> <200703161117.09316.bernhard@intevation.de> Message-ID: <1174043299.11591.3.camel@geru-itae> Le vendredi 16 mars 2007 ? 11:17 +0100, Bernhard Reiter a ?crit : > On Thursday 15 March 2007 23:45, Bram de Greve wrote: > > I guess where getting close to bumping up the version, merging back with > > the main branch (after testing of course ;), and doing a seperate release > > of pyshapelib. Unless we still want to do something about the internal > > Unicode support (currently it's still ASCII only, dbf specs don't really > > support Unicode, see other thread). And I also need to restore the "legal" > > headers > > Wow, this all sounds good! > About the ascii support, I must admitt that I so far have not fully understood > all involved issues. We should at least have a document explaining our > current knowledge and choices. > > For input site dbf we should certainly accept more (always latin1) > then for writing it (which should be conservative). > We could also have a look upon how other shapelib aware products like the ones > from ESRI handle internationalisation. To add some information about this, we could just have a look at the report I made some time ago : http://wald.intevation.org/tracker/index.php?func=detail&aid=118&group_id=6&atid=105 - update shapelib to support the DBF encoding (see byte 29 of the dbf header (http://www.clicketyclick.dk/databases/xbase/fo rmat/dbf.html#DBF_NOTE_5_TARGET)) This seems to be more and more used by current gis software (ArcGIS since 8.2). - update pyshapelib so that it convert the output of shapelib to the locale encoding. I guess this could probably be an improvement, no ? Didrik -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: Ceci est une partie de message =?ISO-8859-1?Q?num=E9riquement?= =?ISO-8859-1?Q?_sign=E9e?= Url : http://www.intevation.de/pipermail/thuban-devel/attachments/20070316/8bd84a71/attachment.bin From bram.degreve at gmail.com Fri Mar 16 12:46:40 2007 From: bram.degreve at gmail.com (Bram de Greve) Date: Fri, 16 Mar 2007 12:46:40 +0100 Subject: pyshapelib branch In-Reply-To: <1174043299.11591.3.camel@geru-itae> References: <1173827137.19010.7.camel@geru-itae> <1d5b08270703151545i3b6cf8b7xcae01c1017524125@mail.gmail.com> <200703161117.09316.bernhard@intevation.de> <1174043299.11591.3.camel@geru-itae> Message-ID: <1d5b08270703160446h36b2f878le47b5bd104f8520@mail.gmail.com> I've also found some other information on unicode handling in arcgis: http://support.esri.com/index.cfm?fa=knowledgebase.techarticles.articleShow&d=21106 I'm very confused about all these encodings =) Bramz -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.intevation.de/pipermail/thuban-devel/attachments/20070316/01984255/attachment.html From bernhard at intevation.de Fri Mar 16 12:59:00 2007 From: bernhard at intevation.de (Bernhard Reiter) Date: Fri, 16 Mar 2007 12:59:00 +0100 Subject: pyshapelib branch In-Reply-To: <1174043299.11591.3.camel@geru-itae> References: <1173827137.19010.7.camel@geru-itae> <200703161117.09316.bernhard@intevation.de> <1174043299.11591.3.camel@geru-itae> Message-ID: <200703161259.01700.bernhard@intevation.de> On Friday 16 March 2007 12:08, Didrik Pinte wrote: > I guess this could probably be an improvement, no ? Yes, I believe so (without having deeply gone into the information yet). If you both think it is good, do not let yourself stop my myself. :) -- Managing Director - Owner: www.intevation.net (Free Software Company) Germany Coordinator: fsfeurope.org. Coordinator: www.Kolab-Konsortium.com. Intevation GmbH, Osnabr?ck, DE; Amtsgericht Osnabr?ck, HRB 18998 Gesch?ftsf?hrer Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner -------------- 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/20070316/227e3ce8/attachment.bin From dpinte at itae.be Fri Mar 16 13:21:42 2007 From: dpinte at itae.be (Didrik Pinte) Date: Fri, 16 Mar 2007 13:21:42 +0100 Subject: pyshapelib branch In-Reply-To: <1d5b08270703160446h36b2f878le47b5bd104f8520@mail.gmail.com> References: <1173827137.19010.7.camel@geru-itae> <1d5b08270703151545i3b6cf8b7xcae01c1017524125@mail.gmail.com> <200703161117.09316.bernhard@intevation.de> <1174043299.11591.3.camel@geru-itae> <1d5b08270703160446h36b2f878le47b5bd104f8520@mail.gmail.com> Message-ID: <1174047702.16362.3.camel@geru-itae> Le vendredi 16 mars 2007 ? 12:46 +0100, Bram de Greve a ?crit : > I've also found some other information on unicode handling in arcgis: > http://support.esri.com/index.cfm?fa=knowledgebase.techarticles.articleShow&d=21106 > > I'm very confused about all these encodings =) > > Bramz Bram, I guess that supporting ANSI, 88591 (ISO-8859-1) and UTF-8 could be the right start. If we have this, we can support I guess 80% of the needs. Didrik -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: Ceci est une partie de message =?ISO-8859-1?Q?num=E9riquement?= =?ISO-8859-1?Q?_sign=E9e?= Url : http://www.intevation.de/pipermail/thuban-devel/attachments/20070316/cfc15d90/attachment.bin From dpinte at itae.be Sat Mar 17 15:09:22 2007 From: dpinte at itae.be (Didrik Pinte) Date: Sat, 17 Mar 2007 15:09:22 +0100 Subject: pyshapelib tests Message-ID: <1174140562.26447.10.camel@geru-itae> Bram, I've just tested a bit the new version. Running the test suite gives a segmentation fault : did at geru-itae:bramz/test$ python test_dbf_table.py Segmentation fault BUT : using the UI, everything seems to work fine. I have successfully loaded a shapefile with a name containing UTF8 characters ! Considering the problems with tests/test_dbf_table.py : [1] it seems that calling the close() method on a dbf object causes a segmentation fault [2] it segfaults too in TestDBFTableWriting when calling DBFTable.__init__ when initialisating the new file (line 90 of Thuban/Models/table.py : 'self.dbf = dbflib.DBFFile(filename)'). Could you have a look at this ? I'm going on testing the new version by using the UI. Didrik -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: Ceci est une partie de message =?ISO-8859-1?Q?num=E9riquement?= =?ISO-8859-1?Q?_sign=E9e?= Url : http://www.intevation.de/pipermail/thuban-devel/attachments/20070317/275eb376/attachment.bin From bernhard at intevation.de Sat Mar 17 18:59:29 2007 From: bernhard at intevation.de (Bernhard Reiter) Date: Sat, 17 Mar 2007 18:59:29 +0100 Subject: pyshapelib branch In-Reply-To: <200703161259.01700.bernhard@intevation.de> References: <1173827137.19010.7.camel@geru-itae> <1174043299.11591.3.camel@geru-itae> <200703161259.01700.bernhard@intevation.de> Message-ID: <200703171859.35213.bernhard@intevation.de> On Friday 16 March 2007 12:59, Bernhard Reiter wrote: > On Friday 16 March 2007 12:08, Didrik Pinte wrote: > > I guess this could probably be an improvement, no ? > > Yes, I believe so (without having deeply gone into the information yet). > If you both think it is good, do not let yourself stop my myself. :) Another thing we should do is: Start a collection of example shp and dbf files that we want to support with the different encoding situations. This would be useful for everyone beyond Thuban and pyshapelib as well. -- Managing Director - Owner: www.intevation.net (Free Software Company) Germany Coordinator: fsfeurope.org. Coordinator: www.Kolab-Konsortium.com. Intevation GmbH, Osnabr?ck, DE; Amtsgericht Osnabr?ck, HRB 18998 Gesch?ftsf?hrer Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner -------------- 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/20070317/609b2095/attachment.bin From dpinte at itae.be Mon Mar 19 11:31:11 2007 From: dpinte at itae.be (Didrik Pinte) Date: Mon, 19 Mar 2007 11:31:11 +0100 Subject: pyshapelib branch In-Reply-To: <200703171859.35213.bernhard@intevation.de> References: <1173827137.19010.7.camel@geru-itae> <1174043299.11591.3.camel@geru-itae> <200703161259.01700.bernhard@intevation.de> <200703171859.35213.bernhard@intevation.de> Message-ID: <1174300272.32390.3.camel@geru-itae> Le samedi 17 mars 2007 ? 18:59 +0100, Bernhard Reiter a ?crit : > On Friday 16 March 2007 12:59, Bernhard Reiter wrote: > > On Friday 16 March 2007 12:08, Didrik Pinte wrote: > > > I guess this could probably be an improvement, no ? > > > > Yes, I believe so (without having deeply gone into the information yet). > > If you both think it is good, do not let yourself stop my myself. :) > > Another thing we should do is: > Start a collection of example shp and dbf files that we want to support > with the different encoding situations. This would be useful for everyone > beyond Thuban and pyshapelib as well. There is already one here : http://wald.intevation.org/tracker/index.php?func=detail&aid=118&group_id=6&atid=105 : polygones.tar.gz - shapefile with iso-8859-1 encoded attributes. At the moment, it works fine in Thuban because of the workaround enabled in the Thuban code (see details in the ticket). Didrik -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: Ceci est une partie de message =?ISO-8859-1?Q?num=E9riquement?= =?ISO-8859-1?Q?_sign=E9e?= Url : http://www.intevation.de/pipermail/thuban-devel/attachments/20070319/1ff75608/attachment.bin From bram.degreve at gmail.com Wed Mar 21 14:25:58 2007 From: bram.degreve at gmail.com (Bram de Greve) Date: Wed, 21 Mar 2007 14:25:58 +0100 Subject: pyshapelib tests In-Reply-To: <1174140562.26447.10.camel@geru-itae> References: <1174140562.26447.10.camel@geru-itae> Message-ID: <46013266.2070307@gmail.com> Hi, Weekends are mostly spent on other stuff, so sorry for the late reply =) I've tried to build Thuban on my windows box, but I almost gave up after finding too much hurdles to take. After adding tons of include and library dirs, and setting PATHs, I've bumped into this nice traceback after which I felt kind of tired =) D:\bram\thuban_work\WIP-pyshapelib-bramz>thuban.py Please update your PATH environment variable to include D:\bram\thuban_work\WIP- pyshapelib-bramz\Thuban\..\gdal\bin Traceback (most recent call last): File "D:\bram\thuban_work\WIP-pyshapelib-bramz\thuban.py", line 32, in ? import Thuban.UI.main File "D:\bram\thuban_work\WIP-pyshapelib-bramz\Thuban\UI\main.py", line 18, in ? import application File "D:\bram\thuban_work\WIP-pyshapelib-bramz\Thuban\UI\application.py", line 27, in ? from Thuban.Model.save import save_session File "D:\bram\thuban_work\WIP-pyshapelib-bramz\Thuban\Model\save.py", line 23, in ? from Thuban.Model.layer import Layer, RasterLayer File "D:\bram\thuban_work\WIP-pyshapelib-bramz\Thuban\Model\layer.py", line 15 , in ? from wxproj import point_in_polygon_shape, shape_centroid ImportError: DLL load failed: A dynamic link library (DLL) initialization routin e failed. BUT, the test script you told of did seem to work (or rather not to work =) though. Fortunately I've put the tons of include and library dirs in a batch file so that I could build a debug version rather quickly. And so I was able to trace the first problem back to DBFClose(DBFHandle) which fails to check for a NULL handle. Well, at least in my opinion this is a failure, because I'm of the believe that freeing, destructing and closing NULL pointers should be harmless. I've fixed this in dbfopen.c and will send a patch for future versions ... However, the test still crashes a bit later ... dbflib_read_record is called with args = NULL. I've haven't been able to track down the cause of this problem yet. Bram Didrik Pinte wrote: > Bram, > > I've just tested a bit the new version. > > Running the test suite gives a segmentation fault : > > did at geru-itae:bramz/test$ python test_dbf_table.py > Segmentation fault > > BUT : > > using the UI, everything seems to work fine. I have successfully loaded > a shapefile with a name containing UTF8 characters ! > > Considering the problems with tests/test_dbf_table.py : > > [1] it seems that calling the close() method on a dbf object causes a > segmentation fault > > [2] it segfaults too in TestDBFTableWriting when calling > DBFTable.__init__ when initialisating the new file (line 90 of > Thuban/Models/table.py : 'self.dbf = dbflib.DBFFile(filename)'). > > Could you have a look at this ? > > I'm going on testing the new version by using the UI. > > Didrik > > > ------------------------------------------------------------------------ > > _______________________________________________ > Thuban-devel mailing list > Thuban-devel at intevation.de > https://intevation.de/mailman/listinfo/thuban-devel > From bram.degreve at gmail.com Thu Mar 22 21:37:49 2007 From: bram.degreve at gmail.com (Bram de Greve) Date: Thu, 22 Mar 2007 21:37:49 +0100 Subject: pyshapelib tests In-Reply-To: <46013266.2070307@gmail.com> References: <1174140562.26447.10.camel@geru-itae> <46013266.2070307@gmail.com> Message-ID: <4602E91D.7020703@gmail.com> Bram de Greve wrote: > However, the test still crashes a bit later ... dbflib_read_record is > called with args = NULL. I've haven't been able to track down the cause > of this problem yet. > I've solved this as well. As it turned out, the commit() function was pointing to dbflib_read_record. d'oh! =) test_dbf_table.py runs without errors now. Bram From bram.degreve at gmail.com Fri Mar 23 02:22:09 2007 From: bram.degreve at gmail.com (Bram de Greve) Date: Fri, 23 Mar 2007 02:22:09 +0100 Subject: pyshapelib tests In-Reply-To: <46013266.2070307@gmail.com> References: <1174140562.26447.10.camel@geru-itae> <46013266.2070307@gmail.com> Message-ID: <46032BC1.4020006@gmail.com> Bram de Greve wrote: > I've tried to build Thuban on my windows box, but I almost gave up after > finding too much hurdles to take. After adding tons of include and > library dirs, and setting PATHs, I've bumped into this nice traceback > after which I felt kind of tired =) > > D:\bram\thuban_work\WIP-pyshapelib-bramz>thuban.py > Please update your PATH environment variable to include > D:\bram\thuban_work\WIP- > pyshapelib-bramz\Thuban\..\gdal\bin > Traceback (most recent call last): > File "D:\bram\thuban_work\WIP-pyshapelib-bramz\thuban.py", line 32, in ? > import Thuban.UI.main > File "D:\bram\thuban_work\WIP-pyshapelib-bramz\Thuban\UI\main.py", > line 18, in > ? > import application > File > "D:\bram\thuban_work\WIP-pyshapelib-bramz\Thuban\UI\application.py", line > 27, in ? > from Thuban.Model.save import save_session > File "D:\bram\thuban_work\WIP-pyshapelib-bramz\Thuban\Model\save.py", > line 23, > in ? > from Thuban.Model.layer import Layer, RasterLayer > File "D:\bram\thuban_work\WIP-pyshapelib-bramz\Thuban\Model\layer.py", > line 15 > , in ? > from wxproj import point_in_polygon_shape, shape_centroid > ImportError: DLL load failed: A dynamic link library (DLL) > initialization routin > e failed. I've also been able to track down this problem ... it appears having a proj.dll dependent on msvcr80.dll doesn't mix well with rest of Thuban stuff. I've written a bit about it here: http://www.bramz.org/2007/03/22/things-learnt-while-coding-on-pyshapelib/ Bram From dpinte at itae.be Fri Mar 23 08:06:56 2007 From: dpinte at itae.be (Didrik Pinte) Date: Fri, 23 Mar 2007 08:06:56 +0100 Subject: pyshapelib tests In-Reply-To: <46032BC1.4020006@gmail.com> References: <1174140562.26447.10.camel@geru-itae> <46013266.2070307@gmail.com> <46032BC1.4020006@gmail.com> Message-ID: <1174633616.25824.1180967383@webmail.messagingengine.com> On Fri, 23 Mar 2007 02:22:09 +0100, "Bram de Greve" said: > I've also been able to track down this problem ... it appears having a > proj.dll dependent on msvcr80.dll doesn't mix well with rest of Thuban > stuff. I've written a bit about it here: > http://www.bramz.org/2007/03/22/things-learnt-while-coding-on-pyshapelib/ > > Bram Hello Bram, Sorry for the late reaction ... I can send you a full "development" build of thuban if you need. With all the libs compiled with msvc7. It's great that all the tests runs fine now. Didrik From bram.degreve at gmail.com Fri Mar 23 13:10:10 2007 From: bram.degreve at gmail.com (Bram de Greve) Date: Fri, 23 Mar 2007 13:10:10 +0100 Subject: pyshapelib tests In-Reply-To: <1174633616.25824.1180967383@webmail.messagingengine.com> References: <1174140562.26447.10.camel@geru-itae> <46013266.2070307@gmail.com> <46032BC1.4020006@gmail.com> <1174633616.25824.1180967383@webmail.messagingengine.com> Message-ID: <4603C3A2.5050705@gmail.com> Didrik Pinte wrote: > Hello Bram, > > Sorry for the late reaction ... I can send you a full "development" > build of thuban if you need. > > With all the libs compiled with msvc7. > > It's great that all the tests runs fine now. > > Didrik It works fine now. I have been able to replace them by libs compiled with msvc71, the same compiler as used for Python 2.4, AFAIK. I was able to open a shapefile from the UI as well, though it was one with floating point data only. Bram From bernhard at intevation.de Thu Mar 29 11:04:30 2007 From: bernhard at intevation.de (Bernhard Reiter) Date: Thu, 29 Mar 2007 11:04:30 +0200 Subject: [Thuban-commits] r2751 - in branches/WIP-pyshapelib-bramz/libraries: pyshapelib shapelib In-Reply-To: <20070328233018.75065193662E@pyrosoma.intevation.org> References: <20070328233018.75065193662E@pyrosoma.intevation.org> Message-ID: <200703291104.31303.bernhard@intevation.de> Hi Bram, On Thursday 29 March 2007 01:30, scm-commit at wald.intevation.org wrote: > this needed unofficial modifications in the C++ shapelib library. can you create a ticket with shapelib then? And document it in Thuban, so wie know what to look for? :) Thanks, Bernhard -- Managing Director - Owner: www.intevation.net (Free Software Company) Germany Coordinator: fsfeurope.org. Coordinator: www.Kolab-Konsortium.com. Intevation GmbH, Osnabr?ck, DE; Amtsgericht Osnabr?ck, HRB 18998 Gesch?ftsf?hrer Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner -------------- 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/20070329/4c899775/attachment.bin From bram.degreve at gmail.com Thu Mar 29 20:42:48 2007 From: bram.degreve at gmail.com (Bram de Greve) Date: Thu, 29 Mar 2007 20:42:48 +0200 Subject: [Thuban-commits] r2751 - in branches/WIP-pyshapelib-bramz/libraries: pyshapelib shapelib In-Reply-To: <200703291104.31303.bernhard@intevation.de> References: <20070328233018.75065193662E@pyrosoma.intevation.org> <200703291104.31303.bernhard@intevation.de> Message-ID: <1d5b08270703291142q24d1f1efqbb61ee0b37a6532c@mail.gmail.com> On 3/29/07, Bernhard Reiter wrote: > > > can you create a ticket with shapelib then? > And document it in Thuban, so wie know what to look for? :) > > I've submitted the patch to shapelib, but I've noticed the shapelib files in Thuban already differ quite a lot from the official 1.2.10 release. Most apparent probably are the CPLError thingies. Bram -- hi, i'm a signature viruz, plz set me as your signature and help me spread :) -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.intevation.de/pipermail/thuban-devel/attachments/20070329/fd79a2f6/attachment.html From bernhard at intevation.de Fri Mar 30 12:11:29 2007 From: bernhard at intevation.de (Bernhard Reiter) Date: Fri, 30 Mar 2007 12:11:29 +0200 Subject: [Thuban-commits] r2751 - in branches/WIP-pyshapelib-bramz/libraries: pyshapelib shapelib In-Reply-To: <1d5b08270703291142q24d1f1efqbb61ee0b37a6532c@mail.gmail.com> References: <20070328233018.75065193662E@pyrosoma.intevation.org> <200703291104.31303.bernhard@intevation.de> <1d5b08270703291142q24d1f1efqbb61ee0b37a6532c@mail.gmail.com> Message-ID: <200703301211.30132.bernhard@intevation.de> On Thursday 29 March 2007 20:42, Bram de Greve wrote: > I've submitted the patch to shapelib, Can you write down the link to the ticket or mailinglist post archive somewhere, so it is documented? > but I've noticed the shapelib files > in Thuban already differ quite a lot from the official 1.2.10 release. > ?Most apparent probably are the CPLError thingies. We should look into updating here as well then. Again, we could open ann issue for it, but this time on wald. :) Bernhard -- Managing Director - Owner: www.intevation.net (Free Software Company) Germany Coordinator: fsfeurope.org. Coordinator: www.Kolab-Konsortium.com. Intevation GmbH, Osnabr?ck, DE; Amtsgericht Osnabr?ck, HRB 18998 Gesch?ftsf?hrer Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner -------------- 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/20070330/f3103ed0/attachment.bin From bernhard at intevation.de Sat Mar 31 16:13:53 2007 From: bernhard at intevation.de (Bernhard Reiter) Date: Sat, 31 Mar 2007 16:13:53 +0200 Subject: Contributing code In-Reply-To: <1159943281.22406.21.camel@geru-itae> References: <200610032253.09029.bernhard@intevation.de> <1159943281.22406.21.camel@geru-itae> Message-ID: <200703311613.56777.bernhard@intevation.de> Bram, how are you feeling about the code contribution rights? The mid term plan is to make FSFE the fiduciary of Thuban's code. Currently Thuban is Gnu GPL, we will probably go GPL v3 when this is out and GNU LGPL would also be an option in the future? If you have no problem assigning the rights to Intevation, please send a signed email if you can. Best, Bernhard On Wednesday 04 October 2006 08:28, Didrik Pinte wrote: > Le mardi 03 octobre 2006 ? 22:53 +0200, Bernhard Reiter a ?crit : > > Didrik, best would be if you could also send such an email. > > Would you be willing to? > > > > Regards, > > Bernhard > > For sure ;-) > > I, Didrik Pinte, transfer the copyright (or exclusive exploitation > rights) of my Thuban contributions to Intevation for the purpose that > Intevation publish it as Free Software. -------------- 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/20070331/390a6031/attachment.bin From nelson at crynwr.com Sat Mar 31 17:20:37 2007 From: nelson at crynwr.com (Russ Nelson) Date: Sat, 31 Mar 2007 11:20:37 -0400 Subject: Contributing code In-Reply-To: <200703311613.56777.bernhard@intevation.de> References: <200610032253.09029.bernhard@intevation.de> <1159943281.22406.21.camel@geru-itae> <200703311613.56777.bernhard@intevation.de> Message-ID: <17934.31813.934766.902076@desk.crynwr.com> Bernhard Reiter writes: > If you have no problem assigning the rights to Intevation, > please send a signed email if you can. As good as a signed email, here is my public statement on the small bits of code I've contributed: http://blog.russnelson.com/opensource/thuban.html -- --my blog is at http://blog.russnelson.com | You can do any damn thing Crynwr sells support for free software | PGPok | you want, as long as you 521 Pleasant Valley Rd. | +1 315-323-1241 | don't expect somebody else Potsdam, NY 13676-3213 | Sheepdog | to pick up the pieces. From bernhard at intevation.de Sat Mar 31 17:39:57 2007 From: bernhard at intevation.de (Bernhard Reiter) Date: Sat, 31 Mar 2007 17:39:57 +0200 Subject: Test of Windows 1.2.0_1.exe Message-ID: <200703311740.06502.bernhard@intevation.de> Hi Didrik, I did a test of your window installer and really find that we need to give better step by step instructions how to do the install. The good news is that I get Thuban up pretty simple. Also we need to stick on a large warning that it only works with the English locale. :( See my report:. Best, Bernhard -------------- next part -------------- 20070331 Bernhard Reiter Testing Thuban-1.2.0_1.exe downloaded from wald.intevation.de. The release notes on wald (click on thuban-1.2.0) say: Thuban 1.2.0_1 for Win32 has been built for Python 2.4 with Proj 4.4.9, wxPython 2.6.3 and gdal 1.4. The installer requires an existing Python 2.4 installation. Suggestion: This is too hard to find. General Setup: Windows XP Sp2 German, Outlook 2003 (running in a virtual machine) Pre001 Login as Administrator. Pre002 Python python-2.4.4.msi Pre003 wxPython (still needed? No hint that it is needed.) Pre004 pysqlite2 (still needed? No hint that it is needed.) Pre005 Thuban-data-1.0.0.zip/Data copied to C:\Programme\Thuban\ ok. GS001 Pre001 Thuban Installer Running the installer .exe. Follow the release notes. All default values. Expected behaviour: Release notes are shown. No errors. There is a Thuban start menu entry. Running Thuban-1.2.0_1.exe Fails: No release notes are shown. Release notes do not mention to set the path to GDAL. Fails: Starting fails because no python installed, error message says "thuban.pyw" cannot be opened. Pre006 Login as unpriviledged User. (Not done, continuing as user with admin rights.) GS002 GS001 Pre002 Starting Thuban, via Menu. Expected behaviour: Thuban starts up Fails: gdal14.dll could not be found. Fix attempt: Going to Systemsteuerung -> System -> Erweitert -> Umgebungsvariablen Edit "Path", adding "C:\Programme\Thuban\gdal\bin". Now: No errormessage, but also Thuban does not start. Trying to debug: Opening a command line, cd c:\Programme\Thuban c:\python24/python.exe thuban.pyw Result: No module named "wx", so we do need wxPython to be installed I guess. Trying to fix doing Pre003 installing wxpython. wxPython2.6-win32-unicode-2.6.3.3-py24.exe is a bit harder to find as you need to go to sourceforge. Suggestion: Make it clear which versions in particular of wx will work in release notes and where to get them. Fails: It still does not start. Debugging suggests that pysqlite is missing. Trying to with with Pre004 pysqlite-2.3.3.win32-py2.4.exe Now: ok. G003-language According to the language of your system, if Thuban has the language, it should be localised. Fails: Thuban is in English. Should be in German. Idea why: Maybe the locales have not been included. At least in Thuban/Resources/ the directory Locale/ is missing and this is the place where it usually would be for GNU/Linux. G004-about-dialog-sane Select Help -> About Expected result: Get a nice about dialog. Almost ok. Minor: Thuban 1.2 svn-20070314 still shows the svn version, this should have been 1.2.0. more: Currently using: wxPython 2.6.3.3 Python 2.4.4 PySQLite 2.3.3 SQLite 3.3.10 GDAL 1.4.0.0 psycopg - not available Internal encoding: cp1252 Compiled for: GTK - not available proj 4.4.9 Extensions: None registered. the internal encoding is interesting. Umlauts in the names look fine. G005-about-showing-gdal ok. Pre120 Load session iceland_sample_raster.thuban Fails: An unhandled exception occurred: unsupported locale setting (please report to http://thuban.intevation.org/bugtracker.html) Traceback (most recent call last): File "\.\Thuban\UI\mainwindow.py", line 297, in invoke_command File "C:\Programme\Thuban\Thuban\UI\command.py", line 121, in Execute apply(self.function, (context,) + self.args + args, kw) File "\.\Thuban\UI\mainwindow.py", line 1071, in call_method File "\.\Thuban\UI\mainwindow.py", line 471, in OpenSession File "\.\Thuban\UI\application.py", line 243, in OpenSession File "\.\Thuban\Model\load.py", line 687, in load_session File "\.\Thuban\Model\xmlreader.py", line 75, in read File "C:\Python24\lib\xml\sax\expatreader.py", line 107, in parse xmlreader.IncrementalParser.parse(self, source) File "C:\Python24\lib\xml\sax\xmlreader.py", line 123, in parse self.feed(buffer) File "C:\Python24\lib\xml\sax\expatreader.py", line 207, in feed self._parser.Parse(data, isFinal) File "C:\Python24\lib\xml\sax\expatreader.py", line 348, in end_element_ns self._cont_handler.endElementNS(pair, None) File "\.\Thuban\Model\xmlreader.py", line 125, in endElementNS File "\.\Thuban\Model\load.py", line 471, in end_projection File "\.\Thuban\Model\proj.py", line 77, in __init__ File "\.\Thuban\Model\proj.py", line 44, in _do_we_have_to_work_around_broken_proj File "C:\Python24\lib\locale.py", line 381, in setlocale return _setlocale(category, locale) Error: unsupported locale setting Something is realy strange her, the following python lines import locale result = locale.setlocale(locale.LC_NUMERIC,"") print result got = locale.getlocale(locale.LC_NUMERIC) print got # works locale.setlocale(locale.LC_NUMERIC, result) # fails locale.setlocale(locale.LC_NUMERIC, got) >>> import locale >>> result = locale.setlocale(locale.LC_NUMERIC,"") >>> print result German_Germany.1252 >>> got = locale.getlocale(locale.LC_NUMERIC) >>> print got ('de_DE', '1252') >>> # works ... locale.setlocale(locale.LC_NUMERIC, result) 'German_Germany.1252' >>> # fails ... locale.setlocale(locale.LC_NUMERIC, got) Traceback (most recent call last): File "", line 2, in ? File "C:\Python24\lib\locale.py", line 381, in setlocale return _setlocale(category, locale) locale.Error: unsupported locale setting >>> Idea how to really fix: save the result of setlocale() in UI/__init__.py because this is the best bet to return to. But this is not really helpful as the locale change does not seem to fix the problem for raster later. Workaround: Changed Model/proj.py to setlocale/locale.LC_NUMERIC."") G020-raster-display, (Pre120) Expected result: iceland with raster background should be shown. Fails: Raster background is not seen. Reason unknown, probably a locale problem. Some debugging: results1 is equal result2 in proj.py's test function, so setting the locale to "C" does not change the projects behaviour the result is: [1.0001886830913063, 1.0001886830913063] gdalinfo works fine. -------------- 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/20070331/d636d82a/attachment.bin