WIP-pyshapelib-Unicode issues
Bernhard Reiter
bernhard at intevation.de
Wed Jan 9 18:37:18 CET 2008
Hi Bram,
On Wednesday 09 January 2008 11:47, Bram de Greve wrote:
> I've committed some changes to the unicode branch. I've fixed copyright
> infos and headers, the README, added an entry in NEWS for 0.4, and did some
> other work on the source code as well. The compiler warnings should be
> gone.
cool, I saw some of the commits happening, but hunted the empty shape file
problem. (Does somebody know, btw, if such a shape file is legitimate at
all?)
> *
> test_transientdb.TestTransientTable.{test_auto_transient_table|test_transie
>nt_table}:
>
> the shapelib C library returns integer numerical fields with more than 10
> digits as double (in order to avoid an overflow with the C int). This is
> causing the test to fail as an 'int' is expected for column 3, and an
> 'double' is found. Bernard Herzog suggests to let pyshapelib convert them
> back to Python long integers. On the Python API level this can easily be
> done using PyLong_FromDouble. Is it OK to mix long integers and "short"
> integers, or should all integers coming from pyshapelib be converted to
> long ints?
Probably one class of objects should always have the same representation,
so if "long" is sufficient for ids, so why not use it for all ids?
This seems consistent. If there are values where (int *) is sufficient,
we could use this.
> * when creating new DBF files, Thuban will use the LDID_ESRI_ANSI code
> page. That's LDID 0x57 and uses the cp1252 codec.
Is this the default encoding old shapefiles uses to have?
> This should be
> configurable by the user, but I don't really know where to start. Can
> anyone who's familier with the Thuban UI give a headstart?
First we have to decide where to save this property.
It looks like the property of a .dbf table which can be a table on its own
or a part of a shapefile layer.
If Thuban displays a table it will already have a concept about it's encoding.
Otherwise it would need to recode it.
So for files where Thuban cannot determine the encoding, we probably have to
add something like in the "import" statements.
Maybe the table view should also display this property.
> * pyshapelib should get a proper unittest that can run on its own, but is
> also tested from test/runtests.py. I've never made a unittest in Python
> before, so I'm a bit puzzled here.
Check the files in there, they are pretty good examples. It is more
straightforward then you might think. :)
--
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/20080109/4414a8a6/attachment.bin
More information about the Thuban-devel
mailing list
This site is hosted by Intevation GmbH (Datenschutzerklärung und Impressum | Privacy Policy and Imprint)