Opened 9 years ago

Closed 9 years ago

#3268 closed defect (wontfix)

pgsql2shp: wrong ldid in dbf

Reported by: Redoute Owned by: pramsey
Priority: medium Milestone: PostGIS 2.1.9
Component: postgis Version: 2.1.x
Keywords: pgsql2shp Cc: Redoute

Description

I have a database with ENCODING = 'UTF8' LC_COLLATE = 'German_Germany.1252' LC_CTYPE = 'German_Germany.1252'. When I export a table with pgsql2shp, the dbf file contains text attributes encoded in UTF-8, which is fine. But the language identifier (ldid byte at position 29 of the dbf) is set to 0x57, meaning codepage 1252 ANSI. I tried pgsql2shp in Windows 8, both as subprocess call in python 3 and at the command line. pgsql2shp RELEASE: 2.1.5 (r13152).

Change History (4)

comment:1 by pramsey, 9 years ago

It looks like the shape driver just writes that ldid in by default, and then the libpq library just hauls the data down in the server encoding. The problem is a little aggravated by GDAL now considering LDID/87 to mean WIN1252. A partial workaround could be to set your PGCLIENTENCODING environment variable to WIN1252, so your data at least match your LDID. Probably we should be setting the LDID to "UTF-8" so that at least GDAL will interpret the data right (and hence hopefully QGIS too)

comment:2 by Redoute, 9 years ago

Cc: Redoute added

comment:3 by pramsey, 9 years ago

This dupes #2220, it turns out. So fixed in trunk, wondering if we want to do a behaviour change (a positive one, but a big one) in 2.1

comment:4 by pramsey, 9 years ago

Resolution: wontfix
Status: newclosed

I'm going with wontfix, on the principle that we've had this problem for multiple years, and the next version does address it.

Note: See TracTickets for help on using tickets.