LC_NUMERIC != ".\0" can break gdal (probably ogr as well) as e.g. with German and French locales

[bernhard@…]

Best solution would be to have locale agnostic funcations, like Python introduced them. Second best solution: Use funcation so that a caller can provide such funcations, see dbflib solution for Thuban.

The FAQ does not show a real solution as the LC_NUMERIC value is important for some applications. See discussion at ​http://bugzilla.maptools.org/show_bug.cgi?id=1615 (dbflib) ​http://bugzilla.remotesensing.org/show_bug.cgi?id=1360 (proj) and Python PEP331.

[neteler@…]

Added links to related discussion in the list:

LOCALE dependent segfault in OGR 
http://lists.maptools.org/pipermail/gdal-dev/2006-November/010857.html
http://lists.maptools.org/pipermail/gdal-dev/2006-November/010865.html
http://lists.maptools.org/pipermail/gdal-dev/2006-November/010872.html
http://lists.maptools.org/pipermail/gdal-dev/2006-November/010880.html
http://lists.maptools.org/pipermail/gdal-dev/2006-November/010882.html
http://lists.maptools.org/pipermail/gdal-dev/2006-November/010887.html

Markus

[neteler@…]

Followup concerning the v.in.ogr problem reported in the mailing list:

Andrey was so kind to fix a bug in 'v.in.ogr' which somehow solved the
problem with the German locale (Ogr_projection should not be freed 
and a memory leak).

Best,
Markus

[warmerdam]

A variety of improvements have been made to SRS handling in unusual numeric locales in trunk. Could you see if the problem still exists when things are built against trunk? If so, please add detailed info in this bug on bug characteristics, and what I will need to do to reproduce it.

[warmerdam]

Closing under the assumption things are fine.