OGRSpatialReference::exportToProj4 is not locale-safe

[ge@…]

When calling exportToProj4 after calling setlocale, it will return commas     
instead of points in numbers, which will confuse proj4.     
  
Possible fixes:   
  - Make proj4 locale-aware; this would probably break many scripts that don't   
care about locales   
  - Don't use sprintf in exportToProj4; this would be a hell lot of work, as  
all formatting is done using sprintf...  
  - Call setlocale before and after exportToProj4; hacky and since setlocale  
can be expected not to be thread-safe, this would be counterproductive to the  
current multi-threading efforts  
  
Test case:  
from osr import *  
import locale  
  
locale.setlocale(locale.LC_ALL, '')  
  
srs = SpatialReference()  
srs.ImportFromEPSG(31297) 
print srs.ExportToProj4()  
  
# Run with LANG=de or something equivalent and watch the commas...

[ge@…]

Oops.  While testing the test case, I've overlooked some NaN's...  
  
$ python ~/tmp/osr_test2.py  
+proj=lcc +lat_1=nan +lat_2=nan +lat_0=nan +lon_0=nan +x_0=400000 +y_0=400000  
+a=6377397 +b=6356067,913043479 +towgs84=577,90,463,5,1,5,2 +units=m +no_defs  
  
$ LANG=C python ~/tmp/osr_test2.py  
+proj=lcc +lat_1=49 +lat_2=46 +lat_0=47.5 +lon_0=13.33333333333333 +x_0=400000  
+y_0=400000 +ellps=bessel  
+towgs84=577.326,90.129,463.919,5.137,1.474,5.297,2.4232 +units=m +no_defs  
 
Looks as if there are even bigger problems. 

[ge@…]

OK, it seems that atof is locale-dependent too.  Ouch, there has to be a 
sensible way to parse LANG=C numbers in a different locale. 

[warmerdam]

Gabriel, 

I'm sorry, but effectively PROJ.4, GDAL and related libraries
require "C" numeric locale or they just fall apart. 

[ge@…]

Oh, sorry.  Maybe this should be noted somewhere in the docs? 

[warmerdam]

Gabriel, 

Any suggestions for a good place?  Do you think the FAQ makes sense? 

[ge@…]

Yeah, the FAQ and a note in the API tutorial (I think most people, including 
me, start by reading that) would make most sense, I think. 

[warmerdam]

I have added an entry in the PROJ.4 (and GDAL) FAQs. 

[bernhard@…]

The problem still persists, 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.

Thus I am reopening.