merging back the new pyshapelib

[Bram de Greve]

Bernhard Reiter wrote:
>>> Running the tests I got more trouble then usual:
>>>  python setup.py  build_ext --use-wx-python-swig-hack  install_local
>>>  
>>>       
>> Well, I tried this as well on my windoze.  I'm supposed to run
>> test/runtests.py ?  I've got like a zillion of permission denieds though :(
>> Scary.  I can't believe this is all due to pyshapelib though.
>>     
>
> We got this followed up already, so of it was caused by the new pyshapelib.
> Also when compiling on Debian sid I got quite a few compiler warning,
> did you check them as well?
>
>   

I've looked a bit further into it, and it boils down to two distinct
errors (apart from the permission denieds):

!!! This is about the WIP-pyshapelib-Unicode branch!

======================================================================
FAIL: test_load.TestNonAsciiColumnName.test
----------------------------------------------------------------------
Traceback (most recent call last):
  File "D:\bram\thuban_work\WIP-pyshapelib-Unicode\thuban\test\test_load.py", li
ne 339, in test
    self.fail("Cannot load file with non-ascii column names")
AssertionError: Cannot load file with non-ascii column names

======================================================================
FAIL: test_load_1_0.TestNonAsciiColumnName.test
----------------------------------------------------------------------
Traceback (most recent call last):
  File "D:\bram\thuban_work\WIP-pyshapelib-Unicode\thuban\test\test_load_1_0.py"
, line 297, in test
    self.fail("Cannot load file with non-ascii column names")
AssertionError: Cannot load file with non-ascii column names



This is about the column name Fläche. It gets into dbflib correctly,
dbflib returns it correctly, but then when it is written to the XML for
testing, it is not UTF-8 encoded to
'Fl\xc3\xa4che'. Instead it is written as Fläche, failing the test. 
Might it be caused by the fact that dbflib is now set to return unicode
strings?



======================================================================
FAIL: test_transientdb.TestTransientTable.test_auto_transient_table
----------------------------------------------------------------------
Traceback (most recent call last):
File
"D:\bram\thuban_work\WIP-pyshapelib-Unicode\thuban\test\test_transientdb.
py", line 138, in test_auto_transient_table
self.run_iceland_political_tests(table)
File
"D:\bram\thuban_work\WIP-pyshapelib-Unicode\thuban\test\test_transientdb.
py", line 59, in run_iceland_political_tests
self.assertEquals(columns[3].type, FIELDTYPE_INT)
AssertionError: 'double' != 'int'

======================================================================
FAIL: test_transientdb.TestTransientTable.test_transient_table
----------------------------------------------------------------------
Traceback (most recent call last):
File
"D:\bram\thuban_work\WIP-pyshapelib-Unicode\thuban\test\test_transientdb.
py", line 111, in test_transient_table
self.run_iceland_political_tests(table)
File
"D:\bram\thuban_work\WIP-pyshapelib-Unicode\thuban\test\test_transientdb.
py", line 59, in run_iceland_political_tests
self.assertEquals(columns[3].type, FIELDTYPE_INT)
AssertionError: 'double' != 'int'


This is caused by a change in the handling of numerical fields in the
shapelib C library.  Integer fields of more than 10 characters (as the
third column in that file is), are returned as doubles to avoid an overflow.
So, we shall either have to change the test, or change policital.dbf.



I don't have access to a linux box ATM, so I can't look into these
warnings.  But there are a few on windows as well.  I'll see to fix them.

Bramz