In unserer Organisation behandeln wir GIS-Inhalte in verschiedenen Dateiformaten. Ich muss diese Dateien in eine PostGIS-Datenbank schreiben, und das geschieht mit ogr2ogr. Das Problem besteht darin, dass die Datenbank UTF8-codiert ist und die Dateien möglicherweise eine andere Codierung aufweisen.
Ich habe eine Beschreibung gefunden, wie ich die Kodierung spezifizieren kann, indem ich einen org2ogr -Options-Parameter hinzufüge, aber anscheinend hat das keinen Effekt.
%Vor%Der Fehler, den ich erhalte, ist:
%Vor%Momentan ist meine Quelldatei eine Shape-Datei und ich bin mir ziemlich sicher, dass sie Latin1-kodiert ist.
Was mache ich hier falsch und kannst du mir helfen?
Mit freundlichen Grüßen, Casper
Das klingt, als würde es die Client-Codierung auf LATIN1 setzen. Welchen Fehler bekommst du genau?
Falls ogr2ogr es nicht richtig weitergibt, können Sie auch versuchen, die Umgebungsvariable PGCLIENTENCODING auf latin1 zu setzen.
Ich schlage vor, Sie überprüfen, dass sie tatsächlich LATIN1 sind. Wenn Sie file einfach ausführen, erhalten Sie eine gute Idee, wenn Sie davon ausgehen, dass es innerhalb der Datei konsistent ist. Sie können auch versuchen, es über iconv zu senden, um es entweder in LATIN1 oder UTF8 zu konvertieren.
Magnus hat recht und ich werde die Lösung hier diskutieren.
Ich habe die Möglichkeit gesehen, PostgreSQL über Zeichencodierung zu informieren, options=’-c client_encoding=xxx’ , hat viele Orte benutzt, aber es scheint keine Wirkung zu haben. Wenn jemand weiß, wie dieser Teil funktioniert, können Sie das gerne weiter ausführen.
Magnus schlug vor, die Umgebungsvariable PGCLIENTENDODING auf LATIN1 zu setzen. Dies kann, nach einer Mailing-Liste, die ich abgefragt habe, geschehen, indem man den Aufruf von ogr2ogr ändert:
%Vor%Das hat nichts für mich getan. Was für mich funktionierte war, vor dem Aufruf an ogr2ogr zu:
%Vor%Es wäre großartig, mehr Details von erfahrenen Benutzern zu hören und ich hoffe, dass es anderen helfen kann:)
Derzeit OGR von GDAL führt keine Umcodierung von Zeichendaten während der Übersetzung zwischen Vektorformaten durch. Das Team hat RFC 23.1: Unterstützung für Unicode in OGR vorbereitet, in der die Unterstützung der Umcodierung für OGR-Treiber diskutiert wird. Der RFC 23 wurde angenommen und die Kernfunktionalität wurde bereits in GDAL 1.6 veröffentlicht. 0. Die meisten OGR-Treiber wurden jedoch nicht aktualisiert, einschließlich Shapefile-Treiber .
Vorläufig würde ich OGR als Kodierung agnostisch und ignorant beschreiben. Es bedeutet, OGR nimmt, was es bekommt, und sendet es ohne jegliche Verarbeitung aus. OGR verwendet den Zeichentyp zum Bearbeiten von Textdaten. Dies ist in Ordnung, um mit Multi-Byte-codierten Zeichenfolgen (wie UTF-8) umzugehen - es ist nur ein einfacher Stream von Bytes, die als Array von Zeichenelementen gespeichert sind.
Es wird empfohlen, dass Entwickler von OGR-Treibern UTF-8-codierte Zeichenfolgen von Attributwerten zurückgeben sollten. Diese Regel wurde jedoch nicht in allen OGR-Treibern übernommen, sodass diese Funktionalität noch nicht für Endbenutzer bereit ist.
Tags und Links character-encoding postgresql gis gdal postgis