From bernhard at intevation.de Sat Dec 1 00:50:55 2007 From: bernhard at intevation.de (Bernhard Reiter) Date: Sat, 1 Dec 2007 00:50:55 +0100 Subject: Installing Thuban-svon on Debian Etch Message-ID: <200712010051.05165.bernhard@intevation.de> Here is an attempt to produce some instructions. Note that Debian Lenny comes with a thuban-1.2.0 package. -- 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 -------------- Howto install Thuban-svn on Debian GNU/Linux Etch (20071130ber) Current with svn Revision 2788 (20071128) Let us assume a target directory like: /opt/thuban-svn a) Checkout Thuban somewhere, e.g. using read access and package "subversion": svn checkout https://scm.wald.intevation.org/svn/thuban/trunk cd trunk b) Check and install the requirements (see README) (for checking I usually use a command like COLUMNS=200 dpkg -l '*wx*' COLUMNS=200 dpkg -l '*sqlite*' ) Here the packages I've checked: Python 2.4.4 -> okay libwxbase2.6-dev 2.6.3.2.1.5 -> okay python-wxgtk2.6 2.6.3.2.1.5 -> okay proj 4.4.9d-2 -> okay. libsqlite3-dev 3.3.8-1.1 python-pysqlite2 2.3.2-2 python interface to SQLite 3 optional libgdal1-1.3.2-dev 1.3.2-4 -> okay python-gdal 1.3.2-4 -> okay. python-psycopg 2.0.5.1-6 -> okay. plugins can have their own dependencies python-mapscript 4.10.0-5+etch1 python-imaging There is no pyogclib package, we deal with it later. For testing: There is no pyRXP package, so we those XML validation is skipped, but this is neglectible. You could install postgresql and postgis to run more tests, but I will not cover this here. So the following command would install quite a bit: aptitude install python-dev python-wxgtk2.6 proj python-xmlbase \ libwxgtk2.6-de wx2.6-headers docbook-utils docbook-xml \ libgdal1-1.3.2-1-dev python-gdal python-psycopg \ python-pysqlite2 libsqlite3-dev python-mapscript python-imaging c) Build the message files for the translations cd po make mo cd .. d) Build, test, install python setup.py build_ext --use-wx-python-swig-hack build To test (optional): cd test python runtests.py cd .. Variation if you know about a working postgis installation, you can set the path to it first before running python runtests.py (2 tests will fail with the Rev 2788 in the ogr, this is known, see the releasenotes.) Install: python setup.py install --prefix /opt/thuban-svn --create-init-module=0 Now you can start thuban with /opt/thuban-svn/bin/thuban e) Install the example data, as you want to play around with Thuban. ;) You can copy the data to the target directory, if you like, e.g. cp -r Data /opt/thuban-svn f) Make sure that users install a .thuban/thubanstart.py file so that it is attempted to load all modules. For this you could copy the packaging/windows/thubanstart.py into the users $HOME/.thuban/ (Better comment out the line for "profiling" as the python-profiler module is non-free software. g) For the experimental wms.py Extension, you need to pyogclib, which we can install manually: Download it from from http://pyogclib.cvs.sourceforge.net/. tar -xvmlzf pyogclib-0.1.0.tar.gz cd PyOGCLib python tests/testWMSClient.py cp -r ogclib /opt/thuban-svn/lib/thuban/Lib -------------- 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/20071201/983ecca4/attachment.bin From thuban-bugs at wald.intevation.org Sat Dec 1 01:09:38 2007 From: thuban-bugs at wald.intevation.org (thuban-bugs@wald.intevation.org) Date: Sat, 1 Dec 2007 01:09:38 +0100 (CET) Subject: =?UTF-8?B?W3RodWJhbi1CdWdzXVs1NTBdIC0tdXNlLXd4LXB5dGhvbi1zd2lnLWhhY2sgcmVsaWVzIG9uIFNXSUcgaW50ZXJuYWxzLCBhbmQgc2hvdWxkIGJlIG1hZGUgb2Jzb2xldGUgYnkgbG9iYmluZyB0byBpbmNsdWRlIHd4UHl0aG9uLmggaW4gdGhlIGRpc3RyaWJ1dGlvbnM=?= Message-ID: <20071201000938.E3EF540485@pyrosoma.intevation.org> Bugs item #550, was opened at 2007-12-01 01:09 Status: Open Priority: 3 Submitted By: Bernhard Reiter (bernhard) Assigned to: Nobody (None) Summary: --use-wx-python-swig-hack relies on SWIG internals, and should be made obsolete by lobbing to include wxPython.h in the distributions Resolution: None Version: None Category: None Initial Comment: setup.py rev 2788 has: --use-wx-python-swig-hack For performance reasons, Thuban access wxPython objects at the C++ level so that it can directly call wxWidgets code from C++. The normal and preferred way to do that is to use the API defined in wxPython.h. Unfortunately, this header file is not distributed with binary packages of wxPython on some platforms. By using the --use-wx-python-swig-hack option you can activate a way to access the C++ objects without wxPython.h. This relies on internals of SWIG, so it might change with future wxPython versions. Therefore, only use this option if the normal way doesn't work for you. Debian today (20071201) still does not ship the packages, there is a discussion at: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=326440 Which also claims that Robin Dunn, the maintainer of wxPython did not want to fix it in the upstream package. ---------------------------------------------------------------------- You can respond by visiting: http://wald.intevation.org/tracker/?func=detail&atid=105&aid=550&group_id=6 From bram.degreve at gmail.com Wed Dec 5 20:50:42 2007 From: bram.degreve at gmail.com (Bram de Greve) Date: Wed, 05 Dec 2007 20:50:42 +0100 Subject: release number? (was: Christmas release? :)) In-Reply-To: <200711300958.05698.bernhard@intevation.de> References: <200711261224.55169.bernhard@intevation.de> <200711291724.15256.bernhard@intevation.de> <474F4641.2010504@gmail.com> <200711300958.05698.bernhard@intevation.de> Message-ID: <47570112.5060806@gmail.com> Bernhard Reiter wrote: > On Friday 30 November 2007 00:07, Bram de Greve wrote: > >> Hold the presses! =) >> > > Hey, we were not that fast anyway, just trying to buy supplies for > the machines and planning the run. 8) > > Things will take a bit longer than antipicated, as I'm now communicating with Frank Warmerdam, and I'll wait until more is know about how the official shapelib is going to evolve. File IO will likely change quite a lot, to support 2GB+ files on Win32, and so the unicode filenames will be revisited (trying to avoid the ugly _wfopen wide character API). Also, about the LDID/CPG code page things, some unified construct will be designed first. More on that later ... > My master plan is to do anything as unicode objects within Thuban > and transfrom things as early as possible when they enter Thuban's realm > and usually late when they are written out. > Agreed > Of course at each border we would need to now what the encoding of the > communication partner is. In some cases this will need to be configurable > as it might not be securly determined by runtime. > > What borders to we have: > a) the filesystem determining the filename encoding > b) the contents of each file > c) all internet connections > d) possible libraries that cannot handle unicode directly. > > So I believe taking and returning unicode would be perfectly fine > for dbflib and preferable even if we need to change Thuban then. > Of course there should be way to request and set the enconding that dbflib > internally uses so that we can inform the user about which dbffile format is > going to be written and let him override this. Apart from this I do not think > that users of dbflib should need to know about encoding issues. > Requesting the encoding should be easy, setting it would most likely only be possible when creating a new DBF file. (in early implementations) this might default to UTF-8 but in the real thing this would be configurable in Thuban. I'm still not sure about returning the string data as unicode or as "raw" encoded strings. You see, my interest in pyshapelib is beyond Thuban. Of course, regardless of the choice, DBFTable in Model/table.py should use Unicode. But if pyshapelib returns raw strings, then DBFTable will do the conversion instead so that it blend seamlessly with the rest of Thuban. The reason why I'm hesitating is two-fold: - backwards compatibililty with tons of existing scripts that don't use unicode and might break - what-if the encoding information (LDID/CPG) or the encoded content is broken. Returning Unicode will only be able to raise an exception, while returning raw content might give opportunities to go further. OTOH, I might do it in a configurable way. For example: dbflib returns raw encoded strings by default, unless you do something like this: import dbflib dbflib.return_unicode = True or even individually on each file: dbf = dbflib.open(u"foobar", return_unicode=True) >> Bonus question 2: Bernhard, shall I make another branch where I commit >> these recent developments? Or do I commit it to my current branch? >> > > Make it in another branch please. > If possible branch from current trunk, this probably will ease merging. > > OK, I did branch from current trunk. But now I need to merge my Bramz branch in my Unicode branch ... *shiver* =) Bram From bh at intevation.de Thu Dec 6 11:56:47 2007 From: bh at intevation.de (Bernhard Herzog) Date: Thu, 6 Dec 2007 11:56:47 +0100 Subject: release number? (was: Christmas release? :)) In-Reply-To: <47570112.5060806@gmail.com> References: <200711261224.55169.bernhard@intevation.de> <200711300958.05698.bernhard@intevation.de> <47570112.5060806@gmail.com> Message-ID: <200712061156.50815.bh@intevation.de> On Wednesday 05 December 2007 20:50, Bram de Greve wrote: > I'm still not sure about returning the string data as unicode or as > "raw" encoded strings. You see, my interest in pyshapelib is beyond > Thuban. pyshapelib should definitely stay usable outside of Thuban. > Of course, regardless of the choice, DBFTable in Model/table.py > should use Unicode. But if pyshapelib returns raw strings, then > DBFTable will do the conversion instead so that it blend seamlessly with > the rest of Thuban. From Thuban's point of view it's sufficient that the abstraction in table.py automatically translates between Thuban's internal encoding and whatever the underlying data sources use. pyshapelib was primarily meant to be a python wrapper for shapelib. As such it should be reasonably close to shapelib itself and reasonably compatible with older pyshapelib releases. Automatic translation between unicode and the dbf file's encoding is not necessarily important in pyshapelib itself. However, unicode will be the preferred data type for text in Python 3 and builtin support for it is probably a good idea in pyshapelib. At the same time, pyshapelib should provide access to all features of shapelib, so a way to get at the raw bytestrings might be important too. > OTOH, I might do it in a configurable way. For example: dbflib returns > raw encoded strings by default, unless you do something like this: > > import dbflib > dbflib.return_unicode = True > > or even individually on each file: > > dbf = dbflib.open(u"foobar", return_unicode=True) The latter version is much better. Such settings should not be globals in a library. Bernhard -- Bernhard Herzog Intevation GmbH, Osnabr?ck Amtsgericht Osnabr?ck, HR B 18998 http://www.intevation.de/ 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/20071206/72a34d9b/attachment.bin From bram.degreve at gmail.com Thu Dec 6 12:16:25 2007 From: bram.degreve at gmail.com (Bram de Greve) Date: Thu, 06 Dec 2007 12:16:25 +0100 Subject: pyshapelib and unicode (was: release number?) In-Reply-To: <200712061156.50815.bh@intevation.de> References: <200711261224.55169.bernhard@intevation.de> <200711300958.05698.bernhard@intevation.de> <47570112.5060806@gmail.com> <200712061156.50815.bh@intevation.de> Message-ID: <4757DA09.50808@gmail.com> Bernhard Herzog wrote: > pyshapelib was primarily meant to be a python wrapper for shapelib. As such > it should be reasonably close to shapelib itself and reasonably compatible > with older pyshapelib releases. Automatic translation between unicode and > the dbf file's encoding is not necessarily important in pyshapelib itself. > However, unicode will be the preferred data type for text in Python 3 and > builtin support for it is probably a good idea in pyshapelib. At the same > time, pyshapelib should provide access to all features of shapelib, so a way > to get at the raw bytestrings might be important too. > I can completely agree with that ... > >> OTOH, I might do it in a configurable way. For example: dbflib returns >> raw encoded strings by default, unless you do something like this: >> >> import dbflib >> dbflib.return_unicode = True >> >> or even individually on each file: >> >> dbf = dbflib.open(u"foobar", return_unicode=True) >> > > The latter version is much better. Such settings should not be globals in a > library. > > I very much favor the latter version as well. It just seems neater that way: maximum control. OTOH, most applications would want to use the same style all over the place. So, if they want to return unicode all over the place, then specifying return_unicode=True might prove a burden and be errorprone. Then, a global setting that can be overridden on individual files might be more useful. But then again, that's just as much error prone when two pieces of code are merged that think otherwise about the default. So yes, I'll agree with you. The all-unicode guys can always write a wrapper if they want. udbflib.py =) Bram From bernhard at intevation.de Thu Dec 6 12:52:48 2007 From: bernhard at intevation.de (Bernhard Reiter) Date: Thu, 6 Dec 2007 12:52:48 +0100 Subject: pyshapelib and unicode (was: release number?) In-Reply-To: <4757DA09.50808@gmail.com> References: <200711261224.55169.bernhard@intevation.de> <200712061156.50815.bh@intevation.de> <4757DA09.50808@gmail.com> Message-ID: <200712061252.52805.bernhard@intevation.de> On Thursday 06 December 2007 12:16, Bram de Greve wrote: > ?So yes, I'll agree with you. Fine with me as well. Striking argument is backwards compatibility, and that raw code might be interesting under some circumstances. > ?The all-unicode guys > can always write a wrapper if they want. ? udbflib.py =) Hey! :o :) -- 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/20071206/6c3beff9/attachment.bin From bernhard at intevation.de Sat Dec 8 15:39:26 2007 From: bernhard at intevation.de (Bernhard Reiter) Date: Sat, 8 Dec 2007 15:39:26 +0100 Subject: Translations (was: Christmas release? :)) In-Reply-To: <200711300949.28207.bernhard@intevation.de> References: <200711261224.55169.bernhard@intevation.de> <1a486f560711291837h7226f9dfya084fee6ca83d2ec@mail.gmail.com> <200711300949.28207.bernhard@intevation.de> Message-ID: <200712081539.32714.bernhard@intevation.de> On Friday 30 November 2007 09:49, Bernhard Reiter wrote: > Thanks for sending the updated .po s! Daniel, your ES and FR updates are commited now, thanks! Status: de.po: 410 translated messages. es.po: 410 translated messages. fr.po: 410 translated messages. hu.po: 384 translated messages, 13 fuzzy translations, 13 untranslated messages. it.po: 355 translated messages, 30 fuzzy translations, 25 untranslated messages. pt_BR.po: 362 translated messages, 23 fuzzy translations, 25 untranslated messages. ru.po: 351 translated messages, 34 fuzzy translations, 25 untranslated messages. -- 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/20071208/90d00e18/attachment.bin From bernhard at intevation.de Sun Dec 9 02:59:31 2007 From: bernhard at intevation.de (Bernhard Reiter) Date: Sun, 9 Dec 2007 02:59:31 +0100 Subject: Patch submitted, who will commit? Message-ID: <200712090259.36289.bernhard@intevation.de> Hi Sean, Hi Jean-Francois, a few minutes ago I have submitted a small patch for pyogclib to add some error handling in case of url or connection problems. (This bugged me playing around with the old thuban/Extension/wms which uses pyogclib.) http://sourceforge.net/tracker/index.php?func=detail&aid=1847088&group_id=89925&atid=591903 Will someone apply it? If you like you can give my CVS write access and I might apply it myself. (my sf id is "ber".) Regards, 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/20071209/d3887e73/attachment.bin From bernhard at intevation.de Tue Dec 11 10:08:48 2007 From: bernhard at intevation.de (Bernhard Reiter) Date: Tue, 11 Dec 2007 10:08:48 +0100 Subject: Extension wms.py should move to owslib Message-ID: <200712111008.52935.bernhard@intevation.de> Deal Thuban-Developers, after poking around in wms.py (because it is somewhat broken), Didrik and I sketched the plan to move it to owslib. http://trac.gispython.org/projects/PCL/wiki/OwsLib The reason is that pyogclib is abandoned (and broken) and owslib is active. Whoever gets first to it, can do the move, but we need to pay attention that owslib currently is changing its interface - so we might need to wait for rel-0.3.0. 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/20071211/40839a65/attachment.bin From bram.degreve at gmail.com Wed Dec 12 21:44:47 2007 From: bram.degreve at gmail.com (Bram de Greve) Date: Wed, 12 Dec 2007 21:44:47 +0100 Subject: =?ISO-8859-1?Q?Re:_release_number=3F_=7F(was:_Christmas_release=3F_:))?= In-Reply-To: <200711291724.15256.bernhard@intevation.de> References: <200711261224.55169.bernhard@intevation.de> <200711291724.15256.bernhard@intevation.de> Message-ID: <1d5b08270712121244m28e6d5f3ue7337612a41d9499@mail.gmail.com> If you're interested, I've merged the current trunk with the WIP-pyshapelib-bramz branch into something that seems to work (at first glance =). You'll find it as r2795 of the WIP-pyhapelib-Unicode branch, to make things complicated (*) =) (*) In reality, I will use this as my starting point for further development. Bramz. It should be possible to back port _that_ particular revision to the trunk fairly easily. On 29/11/2007, Bernhard Reiter wrote: > > On Monday 26 November 2007 12:24, Bernhard Reiter wrote: > > I think we should prepare for a christmas tree release of Thuban. > > I am thinking about how to call this release, what is your opinion. > Candidates I have come up with: > > 1.2.1 > 1.2.1beta1 > 1.3.0 > 1.3.0beta1 > > There are arguments for all candidates: > 1.2.1 would be suitable, because I think we have fixed a couple of > problems > since 1.2.0, so everybody should better try 1.2.1. Also it seems currently > we > do not have that many users so might not need to care for too many > branches > and want to encourage them to test things. > > 1.2.1beta1 would be suitable because we know there are some problems with > the > current state of Thuban. Notably with the encoding issues. Also we do have > a > completely new pyshapelib implementation which has not seen that much > testing > with Thuban, yet and could use some. > > 1.3.0 would be a way out and revive the "experimental" branch being an odd > number. What speaks against it is that there are not that many changes in > Thuban, so we might do inflation here and also there is no point in using > 1.2.0 anymoree with 1.3.0 out there. > > We could consider 1.3.0beta1 if we do the complete overhaul to internal > unicode yet. > > I am mainly undecided between 1.2.1beta1 and 1.2.1. > With Free Software it is a good tradition to indicate the state of the > software and Thuban is "beta" right now, with somethings moving fast and > others not deeply tested. On the other hand, if someone would use 1.2.0 > instead of 1.2.1beta1 because of the believe it would be more stable, it > would be bad as well. > > Opinions? > > 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 > > _______________________________________________ > 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/20071212/a49f71ce/attachment.html From bram.degreve at gmail.com Thu Dec 13 10:15:40 2007 From: bram.degreve at gmail.com (Bram de Greve) Date: Thu, 13 Dec 2007 10:15:40 +0100 Subject: DBFSet_atof_function Message-ID: <1d5b08270712130115p49293ceq14be71954697fc1d@mail.gmail.com> Hi all, I guess this is primarily a question to Bernhard Reiter: what's the story of DBFSet_atof_function() you seem to have added in dbfopen.c? It isn't in the maptools.org version of shapelib I have ported to the WIP-pyshapelib-Unicode branch, and still everything seems to work =). If there's a good reason to have this included again, we can bring up the issue with Frank? Bramz -- 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/20071213/9aa4901e/attachment.html From dpinte at itae.be Thu Dec 13 11:05:17 2007 From: dpinte at itae.be (Didrik Pinte) Date: Thu, 13 Dec 2007 11:05:17 +0100 Subject: DBFSet_atof_function In-Reply-To: <1d5b08270712130115p49293ceq14be71954697fc1d@mail.gmail.com> References: <1d5b08270712130115p49293ceq14be71954697fc1d@mail.gmail.com> Message-ID: <1197540317.28794.1226353841@webmail.messagingengine.com> On Thu, 13 Dec 2007 10:15:40 +0100, "Bram de Greve" said: > Hi all, > > I guess this is primarily a question to Bernhard Reiter: what's the story > of > DBFSet_atof_function() you seem to have added in dbfopen.c? It isn't in > the > maptools.org version of shapelib I have ported to the > WIP-pyshapelib-Unicode > branch, and still everything seems to work =). If there's a good reason > to > have this included again, we can bring up the issue with Frank? > > Bramz > Bernhard, Isn't it related to an issue with LOCALES using "," and "." for decimals ? --> https://wald.intevation.org/tracker/index.php?func=detail&aid=120&group_id=6&atid=105 --> http://bugzilla.maptools.org/show_bug.cgi?id=1615 Didrik From bram.degreve at gmail.com Thu Dec 13 14:03:09 2007 From: bram.degreve at gmail.com (Bram de Greve) Date: Thu, 13 Dec 2007 14:03:09 +0100 Subject: DBFSet_atof_function In-Reply-To: <1197540317.28794.1226353841@webmail.messagingengine.com> References: <1d5b08270712130115p49293ceq14be71954697fc1d@mail.gmail.com> <1197540317.28794.1226353841@webmail.messagingengine.com> Message-ID: <47612D8D.7020207@gmail.com> Didrik Pinte wrote: > > Bernhard, > > Isn't it related to an issue with LOCALES using "," and "." for decimals > ? > This is to make the atof insensitive to the locale? (can't access bugzilla.maptools.org ATM) > --> > https://wald.intevation.org/tracker/index.php?func=detail&aid=120&group_id=6&atid=105 > --> http://bugzilla.maptools.org/show_bug.cgi?id=1615 > > Didrik > > _______________________________________________ > Thuban-devel mailing list > Thuban-devel at intevation.de > https://intevation.de/mailman/listinfo/thuban-devel > > From bernhard at intevation.de Mon Dec 17 12:31:21 2007 From: bernhard at intevation.de (Bernhard Reiter) Date: Mon, 17 Dec 2007 12:31:21 +0100 Subject: DBFSet_atof_function In-Reply-To: <47612D8D.7020207@gmail.com> References: <1d5b08270712130115p49293ceq14be71954697fc1d@mail.gmail.com> <1197540317.28794.1226353841@webmail.messagingengine.com> <47612D8D.7020207@gmail.com> Message-ID: <200712171231.23000.bernhard@intevation.de> On Thursday 13 December 2007 14:03, Bram de Greve wrote: > > Isn't it related to an issue with LOCALES using "," and "." for decimals > > ? > > ? > > This is to make the atof insensitive to the locale? (can't access > bugzilla.maptools.org ATM) Yes. Also see my changelog entries. AFAIR, Frank W. as not shown much interest in the issue. I have also filed an issue with gdal. Of course it would be good to fix this upstream. > > --> > > https://wald.intevation.org/tracker/index.php?func=detail&aid=120&group_i > >d=6&atid=105 --> http://bugzilla.maptools.org/show_bug.cgi?id=1615 -- 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/20071217/2b37ab4d/attachment.bin From bernhard at intevation.de Mon Dec 17 12:32:27 2007 From: bernhard at intevation.de (Bernhard Reiter) Date: Mon, 17 Dec 2007 12:32:27 +0100 Subject: DBFSet_atof_function In-Reply-To: <1d5b08270712130115p49293ceq14be71954697fc1d@mail.gmail.com> References: <1d5b08270712130115p49293ceq14be71954697fc1d@mail.gmail.com> Message-ID: <200712171232.28284.bernhard@intevation.de> On Thursday 13 December 2007 10:15, Bram de Greve wrote: > If there's a good reason to > have this included again, we can bring up the issue with Frank? It is very important, the code has to work with a version of python that has an LC_NUMERIC that will have "," instead of "." in a floating point for instance. Please try with such a locale. -- 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/20071217/d53f43d6/attachment.bin From bram.degreve at gmail.com Mon Dec 17 13:10:38 2007 From: bram.degreve at gmail.com (Bram de Greve) Date: Mon, 17 Dec 2007 13:10:38 +0100 Subject: DBFSet_atof_function In-Reply-To: <200712171231.23000.bernhard@intevation.de> References: <1d5b08270712130115p49293ceq14be71954697fc1d@mail.gmail.com> <1197540317.28794.1226353841@webmail.messagingengine.com> <47612D8D.7020207@gmail.com> <200712171231.23000.bernhard@intevation.de> Message-ID: <4766673E.8080100@gmail.com> Bernhard Reiter wrote: > On Thursday 13 December 2007 14:03, Bram de Greve wrote: > >> This is to make the atof insensitive to the locale? (can't access >> bugzilla.maptools.org ATM) >> > > Yes. > Also see my changelog entries. > > AFAIR, Frank W. as not shown much interest in the issue. > I have also filed an issue with gdal. > Of course it would be good to fix this upstream. > I understand the issue, and I'll make sure it is taken care of. I already agreed with Frank on it. From bernhard at intevation.de Mon Dec 17 15:08:58 2007 From: bernhard at intevation.de (Bernhard Reiter) Date: Mon, 17 Dec 2007 15:08:58 +0100 Subject: DBFSet_atof_function In-Reply-To: <4766673E.8080100@gmail.com> References: <1d5b08270712130115p49293ceq14be71954697fc1d@mail.gmail.com> <200712171231.23000.bernhard@intevation.de> <4766673E.8080100@gmail.com> Message-ID: <200712171509.00016.bernhard@intevation.de> On Monday 17 December 2007 13:10, Bram de Greve wrote: > I understand the issue, and I'll make sure it is taken care of. ?I > already agreed with Frank on it. Very good! -- 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/20071217/8a460fb2/attachment.bin From bram.degreve at gmail.com Tue Dec 18 22:30:34 2007 From: bram.degreve at gmail.com (Bram de Greve) Date: Tue, 18 Dec 2007 22:30:34 +0100 Subject: DBFSet_atof_function resolved (again =) In-Reply-To: <200712171509.00016.bernhard@intevation.de> References: <1d5b08270712130115p49293ceq14be71954697fc1d@mail.gmail.com> <200712171231.23000.bernhard@intevation.de> <4766673E.8080100@gmail.com> <200712171509.00016.bernhard@intevation.de> Message-ID: <47683BFA.2040001@gmail.com> Bernhard Reiter wrote: > On Monday 17 December 2007 13:10, Bram de Greve wrote: > >> I understand the issue, and I'll make sure it is taken care of. I >> already agreed with Frank on it. >> > > Very good! > > This issue has been resolved (again) in commit r2798. This time it has also been fixed upstream. See libaries/pyshapelib/ChangeLog. Cheers, Bram From thuban-bugs at wald.intevation.org Sun Dec 30 19:32:05 2007 From: thuban-bugs at wald.intevation.org (thuban-bugs@wald.intevation.org) Date: Sun, 30 Dec 2007 19:32:05 +0100 (CET) Subject: =?UTF-8?B?W3RodWJhbi1CdWdzXVs1NzFdIEVycm9yIHdoZW4gYWRkaW5nIGEgbGF5ZXI=?= Message-ID: <20071230183205.A6AF640507@pyrosoma.intevation.org> Bugs item #571, was opened at 2007-12-30 19:32 Status: Open Priority: 3 Submitted By: luis garmendia (rowan) Assigned to: Nobody (None) Summary: Error when adding a layer Resolution: None Version: None Category: None Initial Comment: I was using the Add Layer option from the Map Menu when I got an error pop-up: An unhandled exception occurred: argument number 1: (please report to http://thuban.intevation.org/bugtracker.html) Traceback (most recent call last): File "/usr/lib/thuban/Thuban/UI/view.py", line 190, in OnIdle event.RequestMore(self._do_redraw()) File "/usr/lib/python2.4/site-packages/wx-2.6-gtk2-unicode/wx/_core.py", line 6749, in RequestMore return _core_.IdleEvent_RequestMore(*args, **kwargs) MemoryError: argument number 1: I am using Thuban version: Thuban Release Version 1.2.0 on my Debian Sid. The layer that nade it crash was file hs1-1500.shp from http://www.juntadeandalucia.es/obraspublicasytransportes/www/estaticas/cartografia/descargas/archivos/hidrografialineal.zip Reagrds, Luis ---------------------------------------------------------------------- You can respond by visiting: http://wald.intevation.org/tracker/?func=detail&atid=105&aid=571&group_id=6