GDAL .dbf encoding

[atx]

I'm using GDAL through the SWIG Java bindings from a RCP application. On some of my linux (SuSe&Ubuntu) machines the .dbf was created "differently". depending on the locales($LANG) of the shell in which my Java app is started GDAL uses '.' or ',' for interpunctuation of floating point numbers, hence some of my machines have german locales (de_DE.UTF-8) and the meaning of ',' and '.' is the opposite in german this causes trouble if the Mapserver interpretes the .dbf since it expects the english (en_US.UTF-8) punctuation.

it would be preferable if GDAL wouldn't evaluate the locales for this task.

diff of two dbf files: ​http://pastebin.com/KB11Hqm4

[Even Rouault]

Actually, AFAIK, the decimal separator in DBF files should always been '.'. But it is likely that with some locales, GDAL would write a comma instead, and/or doesn't understand the point when reading. That should be fixed in GDAL obviously.

Thinking out loud: we have a CPLLocaleC enforcer object that temorarily installs the C locale and restores the previous locale afterwards, but calling it at each GetNextFeature() or CreateFeature() might have a cost (how big is that one ...?) Another possibility would be to make sure we don't use the C library functions when reading/writing floating point values. For reading, we have CPLAtofM(). But for writing, nothing at the moment (except at some places in the code, with some hand replacing of comma by point as a post-processing step). As this is in shapelib code, some care should be taken to avoid adding too much CPL dependency (or using the SAHooks table for that).

[atx]

Workaround for DBF encoding issue

[atx]

Sadly i'm not into GDALs source, so i won't be able to do much. But for anyone else encountering this problem i've got a workaround. The attached jar (gdal_workaround.jar), contains a patched javadbf (​http://javadbf.sarovar.org/). I had to patch it, since they have the same issue with reading and writing doubles with ',' decimal seperator...

The workaround is provided as static method: GDAL_WorkAround.FixDbfEncoding("Path/to/file"); and replaces the file. So far it seems to work.

[Even Rouault]

Issue with decimal separator has been fixed recently in trunk.

[Even Rouault]

Milestone renamed