Opened 12 years ago

Closed 9 years ago

Last modified 8 years ago

#4713 closed defect (fixed)

GDAL .dbf encoding

Reported by: atx Owned by: warmerdam
Priority: normal Milestone: 2.0.0
Component: OGR_SF Version: 1.8.1
Severity: normal Keywords: encoding
Cc:

Description

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

Attachments (1)

gdal_workaround.jar (54.9 KB ) - added by atx 12 years ago.
Workaround for DBF encoding issue

Download all attachments as: .zip

Change History (5)

comment:1 by Even Rouault, 12 years ago

Component: JavaBindingsOGR_SF
Owner: changed from Even Rouault to warmerdam

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).

by atx, 12 years ago

Attachment: gdal_workaround.jar added

Workaround for DBF encoding issue

comment:2 by atx, 12 years ago

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.

comment:3 by Even Rouault, 9 years ago

Milestone: 2.0
Resolution: fixed
Status: newclosed

Issue with decimal separator has been fixed recently in trunk.

comment:4 by Even Rouault, 8 years ago

Milestone: 2.02.0.0

Milestone renamed

Note: See TracTickets for help on using tickets.