Problemas de codificación con base de datos ogr2ogr y Postgis/PostgreSQL

En nuestra organización, manejamos el contenido GIS en diferentes formatos de archivo. Necesito poner estos archivos en una base de datos PostGIS, y eso se hace usando ogr2ogr. El problema es que la base de datos está codificada en UTF8 y los archivos pueden tener una codificación diferente.Problemas de codificación con base de datos ogr2ogr y Postgis/PostgreSQL

Encontré descripciones de cómo puedo especificar la codificación agregando un parámetro de opciones a org2ogr, pero aparentemente no tiene un efecto.

ogr2ogr -f PostgreSQL PG:"host=localhost user=username dbname=dbname \ 
password=password options='-c client_encoding=latin1'" sourcefile;

El error que recibo es:

 
ERROR 1: ALTER TABLE "soer_vd" ADD COLUMN "målsætning" CHAR(10) 
ERROR: invalid byte sequence for encoding "UTF8": 0xe56c73 
HINT: This error can also happen if the byte sequence does not match the 
encoding expected by the server, which is controlled by "client_encoding". 

ERROR 1: ALTER TABLE "soer_vd" ADD COLUMN "påvirkning" CHAR(10) 
ERROR: invalid byte sequence for encoding "UTF8": 0xe57669 
HINT: This error can also happen if the byte sequence does not match the 
encoding expected by the server, which is controlled by "client_encoding". 

ERROR 1: INSERT command for new feature failed. 
ERROR: invalid byte sequence for encoding "UTF8": 0xf8 
HINT: This error can also happen if the byte sequence does not match the 
encoding expected by the server, which is controlled by "client_encoding".

Actualmente, mi archivo de origen es un archivo de forma y estoy bastante seguro, que se codifica Latin1.

¿Qué estoy haciendo mal aquí y me pueden ayudar?

Saludos cordiales, Casper

Fuente

2009-09-04 Chau

Eso suena como sería establecer la codificación del cliente para LATIN1. Exactamente, ¿qué error obtienes?

En caso de que ogr2ogr no lo transmita correctamente, también puede intentar configurar la variable de entorno PGCLIENTENCODING en latin1.

Le sugiero que compruebe dos veces que en realidad son LATIN1. Simplemente ejecutar file en él le dará una buena idea, suponiendo que es realmente coherente dentro del archivo. También puede intentar enviarlo a través del iconv para convertirlo a LATIN1 o UTF8.

Fuente

2009-09-05 23:17:02

He intentado tanto el client_encoding como el PGCLIENTENCODING para seleccionar un esquema de codificación. Ninguno de ellos resolvió mi problema. Como no he encontrado una forma de determinar la codificación de caracteres exacta de mis archivos de formas, probé LATIN1, LATIN9, WIN1250 y WIN1252, pero todavía no tuve éxito. Todavía estoy buscando que iconv funcione ... – Chau

Magnus tiene razón y voy a discutir la solución aquí.

He visto la opción de informar a PostgreSQL sobre la codificación de caracteres, options=’-c client_encoding=xxx’, se usa en muchos lugares, pero no parece tener ningún efecto. Si alguien sabe cómo funciona esta parte, siéntete libre de elaborar.

Magnus sugirió establecer la variable de entorno PGCLIENTENCODING en LATIN1. Esto puede, de acuerdo con una lista de correo He preguntado, se realiza modificando la llamada a ogr2ogr:

ogr2ogr -–config PGCLIENTENCODING LATIN1 –f PostgreSQL 
PG:”host=hostname user=username dbname=databasename password=password” inputfile

Esto no hizo nada para mí. Lo que funcionó para mí fue que, antes de la llamada a ogr2ogr, a:

SET PGCLIENTENCODING=LATIN1

Sería bueno escuchar más detalles de los usuarios con experiencia y espero que pueda ayudar a otros :)

Fuente

2009-09-08 09:04:25 Chau

Me parece que el comando SET es específico de Windows. Aquí hay un tema análogo: http://gis.stackexchange.com/questions/15912/how-to-encode-shapefiles-from-latin1-to-utf-8 y sugirieron el comando EXPORTAR bajo Linux. Pero tal vez estoy equivocado. De todos modos, SET funcionó en Windows para mí. –

Actualmente, OGR de GDAL no realiza ninguna recodificación de datos de caracteres durante la traducción entre formatos de vectores. El equipo ha preparado el documento RFC 23.1: Unicode support in OGR que analiza el soporte de la recodificación para controladores OGR. El RFC 23 was adopted y la funcionalidad principal ya se lanzaron en GDAL 1.6.0. Sin embargo, la mayoría de los controladores OGR no se han actualizado, incluido Shapefile driver.

Por el momento, describiría OGR como una codificación agnóstica e ignorante. Significa que OGR toma lo que recibe y lo envía sin ningún procesamiento. OGR usa el tipo de caracteres para manipular datos textuales. Esto está bien para manejar cadenas codificadas de múltiples bytes (como UTF-8), es simplemente una secuencia simple de bytes almacenados como una matriz de elementos char.Se recomienda que los desarrolladores de controladores OGR devuelvan cadenas de valores de atributo codificados en UTF-8. Sin embargo, esta regla no se ha adoptado ampliamente en los controladores OGR, por lo que esta funcionalidad aún no está lista para el usuario final.

Fuente

2010-01-22 16:12:45 mloskot

tiene que escribir su línea de comando como este:

PGCLIENTENCODING=LATIN1 ogr2ogr -f PostgreSQL PG:"dbname=...

Fuente

2012-03-15 10:37:56 Sylvain

No veo cómo su respuesta proporciona información adicional en comparación con las respuestas ya publicadas. – Chau

Para mí 'SET PGCLIENTENCODING = LATIN1' no funcionó. Esta respuesta me ayudó. –

He resuelto este problema mediante este comando:

pg_restore --host localhost --port 5432 --username postgres --dbname {DBNAME} --schema public --verbose "{FILE_PATH to import}"

No sé si esta es la solución correcta, pero trabajó para mi.

Fuente

2012-04-10 07:18:22 Sivaguru

Problemas de codificación con base de datos ogr2ogr y Postgis/PostgreSQL

Respuesta

Cuestiones relacionadas