new runtest option and dirty locale fix method

[Bernhard Reiter]

On Monday 25 September 2006 09:02, Didrik Pinte wrote:
> Le dimanche 24 septembre 2006 à 21:11 +0200, Bernhard Reiter a écrit :
> > This is a hack, but I envision that there will be locale agnostic
> > functions around and putting your own into shapelib probably
> > is creating more need for maintenance.
> > There already are some in glib, Python C/API and even on glibc
> > you can easily create one using strtod_l().
> >
> > Would this be a good solution for gdal as well?
> > shapelib is easy as Thuban already ships its own version.

> First, I have to say that it's good to have something working concerning
> the problems of encoding and locales.

So far I have only tried to fix the LC_NUMERIC problems
and I did not deal with encodings.
Gdal is still broken for LC_NUMERIC.

> I thinks the following could be interesting :
>
> There is actually a discussion on a RFC for a gdal using utf8
> internally. In this discussion they were talking about the problems of
> file encoding/drivers and how to deal with them. 

> (all) :
> http://lists.maptools.org/pipermail/gdal-dev/2006-September/010131.html

This is the strategy that we also started in Thuban a while ago.
It is good to see GDAL considering this.

> It seems that there is 
> a way to know the exact encoding of the dbf file of a shapefile. This
> would allow pyshapelib to be really consistant against the locale and
> the encoding of the file the user wants to open.
>
> Here is the related thread :
>
> (shapefile info) :
> http://lists.maptools.org/pipermail/gdal-dev/2006-September/010150.html

Thanks for finding it, this is indeed interesting. I was wondering if 
.dbf files would save the encoding. 

Both hints do not solve:
a) the problem to know the locale, e.g. the decimal_point saved in the file.
Someone could guess that .dbf files would only use decimal_point = '.',
but I have not consulted the documentation about this.

b) Get functions that actually do things like atof or printf according to the 
locale that is used in the files while the font-end application uses a 
different one.  GNU libc seems to have a proof-of-concept implementation
of strtod_l, see last sentence of 
http://www.gnu.org/software/libc/manual/html_node/Parsing-of-Floats.html#Parsing-of-Floats

Bernhard


-- 
Managing Director - Owner, www.intevation.net       (Free Software Company)
Germany Coordinator, fsfeurope.org       (Non-Profit Org for Free Software)
www.kolab-konsortium.com   (Email/Groupware Solution, Professional Service)
-------------- 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/20060925/35ec51b2/attachment.bin