Obsługa kodowania znaków w geobazach i plikach kształtów


11

Mam kilka geobaz, które zawierają wiele cech z greckimi literami w wielu atrybutach. Kiedy próbuję wyeksportować klasę obiektów jako plik kształtowy z ArcCatalog, atrybuty są rozczłonkowane w danych pliku kształtowego, jakiś problem z kodowaniem znaków (wyglądają one tak: „etr ?? e?”). To samo dzieje się, gdy używam ogr2ogr w FWtools do konwertowania warstw z MDB na KML, shp itp.

Czy ktoś ma doświadczenie w radzeniu sobie z formatami kodowania w różnych formatach danych GIS?

Prawdziwym celem jest przeniesienie niektórych danych z tych geobaz danych Esri do bazy danych Postgres / PostGIS, ale zepsute kodowanie nie zadziała. Zamierzałem wyeksportować z geoDB do plików kształtów, a następnie załadować je shp2pgsql. Czy to najłatwiejsza droga, aby się tam dostać?


2
Możesz użyć QGIS do zaimportowania pliku shap z opcją CP1256 i wyeksportowania go za pomocą UTF8, aby uniknąć problemu z kodowaniem innym niż Unicode

Odpowiedzi:


10

Myślę, że jesteś w połowie drogi. Możesz użyć iconvdo konwersji z jednego kodowania na inne i możesz użyć tego jako części shp2pgsqlprocesu. Na przykład:

shp2pgsql *postgrestablename* | iconv -f *sourceencoding* -t *targetencoding* | psql -d *yourdatabase*

Jeśli pracujesz w środowisku Linux, iconvpowinien być już zainstalowany. Dla Windows znalazłem LibIconv dla Windows . Ale nie mam doświadczenia w korzystaniu iconvz systemu Windows, więc nie mogę za to ręczyć.

Mam nadzieję że to pomoże!

Jo


Problem występuje przed zastosowaniem shp2pgsql. Atrybuty w pliku kształtu są już uszkodzone, jeśli dobrze rozumiem.
podmrok


podmrok, masz rację. Dane są złe, zanim przejdę do kroku shp2pgsql.
colemanm

Dzięki, mwalker ... rozwiązanie, które do tej pory działało fantastycznie! Zmieniłem format CodePage na UTF-8, a dane DBF pliku kształtów pokazują teraz prawidłowe znaki. A przy użyciu modułu ładującego pliki kształtów PostGIS w QGIS dane w bazie danych PostGIS również są poprawne.
colemanm,

6

Poniżej szczegóły procesu, którego użyłem do konwersji pliku GeoDataBase z polami arabskimi na pliki kształtów z kodowaniem UTF-8, które otwierają się szczęśliwie zarówno w QGIS, jak i ArcMap, pokazując poprawnie zarówno arabski, jak i angielski (bez użycia rozszerzeń do eksportu lub odczytu):

  • Podstawowa idea: z pliku FGDB wyeksportuj plik kształtu zawierający plik .dbf (w niewłaściwym kodowaniu), a następnie wyeksportuj tabelę atrybutów tej samej warstwy co tekst (w odpowiednim kodowaniu, którym jest UTF-8) i użyj innego programu zastąpić zawartość pliku shapefile .dbf odpowiednimi polami danych UTF-8 i zapisać plik .dbf z kodowaniem UTF-8. Następnie dodaj plik .cpg do każdego pliku kształtu, aby poinformować ArcGIS o nowym kodowaniu pliku .dbf. Kroki:

1) Dodaj warstwy z FGDB do ArcMap (użyłem 10.1, ale nie ma absolutnie żadnego powodu, aby nie działał we wcześniejszych wersjach, ponieważ bit kodujący zdarza się później, poza Arc). Aby wyeksportować, kliknij warstwę prawym przyciskiem myszy i wybierz Dane-> Eksportuj dane, kliknij przycisk folderu w oknie dialogowym eksportu, aby wyświetlić okno dialogowe Zapisz, i wybierz Shapefile jako format wyjściowy.

1b) Metoda alternatywna do powyższej: przejdź do FGDB w ArcCatalog, kliknij go prawym przyciskiem myszy, wybierz Eksport -> Do Shapefile (wiele) i wyeksportuj cały FGCB jako folder pełen plików kształtów w jednej operacji).

2) Teraz masz zestaw plików kształtów z bełkotem, w którym powinien znajdować się skrypt arabski (na mojej maszynie zamiast znaków wyświetlały się znaki zapytania). Części samych plików kształtowych .dbf, otwarte w programie Excel lub czymkolwiek innym, mają bełkot zamiast arabskiego; nie jest to tylko problem z wyświetlaniem w programie GIS, ale to, że same pliki .dbf nie zawierają znaków arabskich. Nie jest jeszcze pomocna.

3) W ArcMap otwórz tabelę atrybutów warstwy z FGDB. Tabela otwiera się z poprawnie wyświetlonym angielskim i arabskim (dlatego właśnie FGDB został użyty). W menu Opcje tabeli w oknie Tabela atrybutów wybierz opcję Eksportuj, aw oknie dialogowym Eksport danych kliknij przycisk folderu wyjściowego, aby przejść do okna dialogowego Zapisywanie danych, w którym jako typ wyniku wybierz Plik tekstowy. Teraz masz plik tekstowy, który otworzy się w Notatniku z ogranicznikami przecinkowymi, zakodowanymi jako UTF-8, z odpowiednio zakodowanym językiem angielskim i arabskim (język arabski powinien w tym momencie poprawnie wyświetlać się w Notatniku).

Teraz, aby uzyskać te informacje w częściach .dbf plików kształtów!

4) Otwórz LibreOffice Calc, darmowy klon programu Excel typu open source, który łatwo otwiera, manipuluje i zapisuje pliki .dbf, aby otworzyć plik .dbf pliku kształtu.

Nawiasem mówiąc, w tym przypadku nie używam LibreOffice zamiast MS Office z powodów ideologicznych, ale po prostu dlatego, że nie mogę wymyślić, jak Excel zapisać plik .dbf, co jest łatwe w Calc, w rzeczywistości jest to domyślna opcja po naciśnięciu przycisku Zapisz po otwarciu i zmodyfikowaniu pliku .dbf w programie Calc, podczas gdy program Excel faktycznie stwierdza, że ​​pliku „nie można zapisać w bieżącym formacie” i niezbyt pomocne oferuje „zapisanie go jako najnowszego formatu” (nie pojawia się opcja dla .dbf). Istnieją rozszerzenia / wtyczki dla programu Excel, które rzekomo wykonują zadanie (

Plik .dbf w programie Calc nadal pokazuje bełkot zamiast języka arabskiego. Oprócz tego otwórz plik .csv, który wyeksportowałeś z tabeli atrybutów tego samego pliku kształtu, upewniając się, że w oknie dialogowym otwierającym podałeś UTF-8 jako kodowanie (i przecinki jako separatory). Pliki tekstowe powinny się otwierać w drugim arkuszu kalkulacyjnym Calc z poprawnie wyświetlonym arabskim i powinny zawierać te same kolumny co .dbf oraz kolumnę OBJECTID na początku. Skopiuj i wklej kolumny z .csv zawierające właściwy język arabski do .dbf (w rzeczywistości po prostu skopiowałem i wkleiłem całą tabelę z wyjątkiem kolumny identyfikatora umieszczonej najdalej z lewej strony, aby zaoszczędzić czas; i tak informacje są identyczne). Naciśnij Zapisz w zmodyfikowanym pliku .dbf w LibreOffice (zapyta, czy naprawdę chcesz użyć tak dziwnego formatu, jak .dbf; tak, robisz).

Powtórz ten proces dla wszystkich składników .dbf plików kształtów z FGDB, zastępując wszystkie bełkotane kolumny ciągami arabskimi.

5) Zaraz po ponownym zapisaniu części .dbf z wklejonymi arabskimi kolumnami, możesz otworzyć pliki kształtów w QGIS i będą one działać poprawnie w obu językach, pod warunkiem, że określisz UTF-8 jako kodowanie w wektorze importu Okno dialogowe pliku. Jednak nadal nie będą działać poprawnie w ArcGIS (a przynajmniej nie we wszystkich wersjach), ponieważ ArcGIS nie rozpoznaje automatycznie kodowania ani nie pozwala wybrać go podczas dodawania pliku kształtu do projektu. Arc potrzebuje osobnego komponentu do pliku shapefile, zwanego plikiem konwersji strony kodowej (.cpg), aby poinstruować go, jakie kodowanie odczytać.

6) Użyj edytora tekstu (notatnik, nano lub cokolwiek innego, ale nie Worda ani żadnego innego edytora tekstu), aby utworzyć plik tekstowy zawierający tylko pięć znaków „UTF-8”. Zapisz go jako .cpg dla każdego pliku kształtów (po prostu klikam kawałek pliku kształtów w oknie dialogowym Zapisz jako, a następnie usuwam rozszerzenie i dodajesz .cpg), w tym samym folderze co plik kształtów (w zasadzie staje się kolejnym kawałkiem Hi wieloczęściowy plik kształtu). Rozszerzenie .cpg mówi Arc, że jest to plik zawierający informacje o kodowaniu pliku .dbf; po dołączeniu do pliku shapefile wraz z rodzeństwem o tej samej nazwie, ale o innym rozszerzeniu, kodowanie pliku shapefile jest teraz automatycznie rozpoznawane przez ArcGIS.

7) Voila. Teraz masz pliki shapefile, które zawierają zarówno ciągi w języku angielskim, jak i arabskim, o ile mogę powiedzieć dokładnie tak, jak w oryginalnym pliku GeoDataBase. Otwierają się one w moich instalacjach ArcMap i QGIS, aw obu przypadkach ciągi w obu językach są wyświetlane poprawnie, w tym na etykietach map.

Ostrzeżenia:

  • Nie wszystkie kopie ArcGIS wydają się eksportować tabelę atrybutów jako poprawnie wypełniony plik tekstowy (na co najmniej jednym komputerze próba wyeksportowania tabeli atrybutów do pliku tekstowego skutkuje plikiem zawierającym tylko nagłówki, a nie wiersze danych. To jest NIE jest to właściwe zachowanie Arc (oczywiście powinno być w stanie wyeksportować Tabele atrybutów jako tekst), ale może pojawić się u niektórych użytkowników. To uniemożliwia dalsze kroki.

  • Nie wydaje się, aby ArcGIS zapisywał nowe pliki kształtów z kodowaniem UTF-8. Wpłynie to tylko na użytkowników, którzy chcą tworzyć nowe pliki kształtów na podstawie danych, a nie na osoby, które chcą tylko wyświetlać, modyfikować i używać ich do tworzenia map. Obejście to wydaje się obejmować bałagan w rejestrze systemu Windows, jak opisano tutaj: ( http://support.esri.com/cn/knowledgebase/techarticles/detail/21106 ). Nie musiałem sobie z tym poradzić, ponieważ moje ArcGIS i QGIS wydają się z radością rozpoznawać pliki kształtów zapisane przeze mnie w powyższym procesie, i mogę modyfikować geometrię i wpisy w tabeli, a nawet dodawać nowe wielokąty z większą ilością tekstu arabskiego bez żadnych oczywistych problemów ( nawet jeśli Arc nie chce zapisywać nowych plików kształtów z kodowaniem UTF-8, wydaje się, że chce je aktualizować / ponownie zapisywać).

  • Zakładam, że funkcjonalność LibreOffice jest taka sama w systemie Windows jak na moim komputerze. Używam GNU / Linuksa przez większość mojej pracy i uruchamiam system Windows tylko wtedy, gdy muszę użyć ArcGIS lub Autocad do jakiegoś zadania, więc zrobiłem modyfikację pliku .dbf w Libreoffice uruchomionym na Fedorze. Zakładam, że działa tak samo w systemie Windows, ale nie mogę tego przetestować bez instalacji LibreOffice na mojej partycji Windows, a moje obecne połączenie internetowe jest nieco wolne w przypadku niepotrzebnych pobrań. Istnieją wtyczki do programu Excel, które pozwalają zapisywać pliki .dbf w wybranym kodowaniu (na przykład exceltodbf.sourceforge.net/), ale nie próbowałem ich. Mogą istnieć inne sposoby manipulowania i zapisywania .dbf, ale nie przyjrzałem się im po znalezieniu dość łatwego sposobu, aby to zrobić za pomocą LibreOffice.

  • Wydaje się, że całego problemu można uniknąć, jeśli zapłacisz za rozszerzenie mapowania produkcji w ArcGIS, które pozwala na bezpośrednią konwersję FGDB do plików kształtów z kodowaniem UTF-8 zgodnie z tą stroną: http://resources.arcgis.com/en/help /main/10.1/index.html#//0103000001m1000000 . Dlaczego ta raczej podstawowa funkcjonalność (Unicode istnieje już od jakiegoś czasu i istnieje wiele języków innych niż angielski) jest dostępna tylko dla tych klientów, którzy płacą dodatkowo, jest pytaniem dla ESRI.


0

Najpierw musisz dowiedzieć się, w jakim kodowaniu są dane wejściowe, abyś mógł powiedzieć swoim narzędziom, jak przekonwertować dane na odpowiednie kodowanie. Jeśli masz Access, spróbuję wyeksportować tabelę do tekstu bezpośrednio z MDB i ustaw kodowanie wyjściowe na UTF8. Jeśli otworzysz wyeksportowany plik kształtu w ArcGIS, czy kodowanie jest ustawione poprawnie? DBF obsługuje strony kodowe i możliwe, że OGR nie wybiera poprawnej strony do konwersji.

Istnieją również sposoby wymuszania narzędzi MDBtool (używanych jako część sterownika OGR) w celu jawnego ustawienia strumienia wejściowego, ale najpierw spróbuję zastosować inne podejście.


0

Raczej pójdę do ArcGIS. Wystarczy ustawić kodowanie na UTF-8 w ArcGIS, postępując zgodnie z instrukcją tutaj . Następnie wystarczy wyeksportować klasy elementów do ShapeFile. Teraz otrzymasz dodatkowy plik CPG (plik strony kodowej) z każdą warstwą. Jest to tylko plik tekstowy z ciągiem „UTF-8”, a wszystkie dane są automatycznie kodowane do UTF-8.

Jeśli chcesz użyć innego kodowania, zapoznaj się z instrukcjami.

Ważną rzeczą jest to, że po zakończeniu tego zadania powinieneś zmienić to ustawienie na wartość domyślną, ponieważ jeśli zachowasz tę wartość, na przykład „UTF-8”, to w przyszłości ArcGIS wyeksportuje wszystkie pliki ShapeFiles przy użyciu kodowania „UTF-8”.

Mam nadzieję, że ci to pomoże.

Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.