Поддержка кодировки символов в базах геоданных и шейп-файлах


11

У меня есть несколько баз геоданных, которые включают классы объектов с греческими буквами во многих атрибутах. Когда я пытаюсь экспортировать класс объектов в виде шейп-файла из ArcCatalog, атрибуты разделяются в данных шейп-файла, что-то вроде проблемы кодировки символов (они выглядят так в форме: ?? etr ?? e?). То же самое происходит, когда я использую ogr2ogr в FWtools для преобразования слоев из MDB в KML, shp и т. Д.

У кого-нибудь есть опыт работы с форматами кодирования в форматах данных ГИС?

Настоящая цель здесь - получить некоторые данные из этих баз геоданных Esri в базу данных Postgres / PostGIS, но неработающее кодирование работать не будет. Я собирался экспортировать из geoDBs в шейпфайлы, а затем загрузить их с shp2pgsql. Это самый легкий путь туда добраться?


2
Вы можете использовать QGIS, чтобы импортировать шейп-файл с опцией CP1256 и экспортировать его с UTF8, чтобы избежать проблем, не связанных с Unicode

Ответы:


10

Я думаю, что вы частично там. Вы можете использовать iconvдля преобразования из одной кодировки в другую, и вы можете использовать это как часть shp2pgsqlпроцесса. Например:

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

Если вы работаете в среде Linux, то iconvдолжны быть уже установлены. Для Windows я нашел LibIconv для Windows . Но у меня нет опыта использования iconvпод Windows, поэтому я не могу ручаться за это.

Надеюсь это поможет!

Джо


Проблема возникает до применения shp2pgsql. Атрибуты в шейп-файле уже разбиты, если я правильно понимаю.
Подземье


Подземье, ты прав. Данные плохие, прежде чем я могу перейти к шагу shp2pgsql.
Коулманм

Спасибо, mwalker ... решение по этому вопросу до сих пор работало фантастически! Я изменил формат CodePage на UTF-8, и данные DBF шейп-файла теперь показывают правильные символы. А с помощью загрузчика шейп-файлов PostGIS в QGIS данные в базе данных PostGIS также верны.
Коулманм

6

Ниже подробно описан процесс, который я использовал для преобразования Файла GeoDataBase с арабскими полями в шейп-файлы с кодировкой UTF-8, которые с радостью открываются в QGIS и ArcMap, показывая правильно и арабский, и английский (без использования расширений для экспорта или чтения):

  • Основная идея: из FGDB экспортировать шейп-файл, включающий .dbf (в неправильной кодировке), затем экспортировать таблицу атрибутов того же слоя, что и текст (в правильной кодировке, которая является UTF-8), и использовать другую программу заменить содержимое шейп-файла .dbf соответствующими полями данных UTF-8 и сохранить .dbf с кодировкой UTF-8. Затем добавьте файл .cpg в каждый шейп-файл, чтобы сообщить ArcGIS о новой кодировке .dbf. шаги:

1) Добавьте слои из FGDB в ArcMap (я использовал 10.1, но нет абсолютно никаких причин не работать в более ранних версиях, потому что бит кодирования происходит позже, вне Arc). Для экспорта щелкните правой кнопкой мыши слой и выберите «Данные» -> «Экспорт данных», нажмите кнопку папки в диалоговом окне экспорта, чтобы открыть диалоговое окно «Сохранить», и выберите Shapefile в качестве выходного формата.

1b) Альтернативный метод описанному выше: перейдите к FGDB в ArcCatalog, щелкните его правой кнопкой мыши, выберите «Экспорт» -> «В шейп-файл (несколько) и экспортируйте весь FGCB как папку, заполненную шейп-файлами за одну операцию).

2) Теперь у вас есть набор шейп-файлов с бредом, где должен быть арабский алфавит (на моем компьютере вместо символов отображаются вопросительные знаки). Части .dbf самих шейп-файлов, открытые в Excel или чем-то еще, имеют арабский язык вместо арабского; это не просто проблема отображения в программе ГИС, это то, что сами файлы .dbf не содержат арабских символов. Пока не полезно.

3) В ArcMap откройте таблицу атрибутов слоя из FGDB. Таблица открывается как на английском, так и на арабском, и показывает правильное отображение (именно поэтому FGDB использовался в первую очередь). В меню «Параметры таблицы» окна «Таблица атрибутов» выберите «Экспорт», а в диалоговом окне «Экспорт данных» нажмите кнопку папки вывода, чтобы перейти в диалоговое окно «Сохранение данных», где вы выбираете «Текстовый файл» в качестве типа вывода. Теперь у вас есть текстовый файл, который откроется в Блокноте с разделителями-запятыми, закодированными как UTF-8, с правильным кодированием как на английском, так и на арабском (арабский язык должен в этот момент правильно отображаться в Блокноте).

Теперь, чтобы получить эту информацию в .dbf части шейп-файлов!

4) Откройте LibreOffice Calc, бесплатный клон Excel с открытым исходным кодом, который легко открывает, манипулирует и сохраняет файлы .dbf, чтобы открыть файл .dbf шейп-файла.

Кстати, в этом случае я не использую LibreOffice вместо MS Office по идеологическим причинам, а просто потому, что не могу понять, как заставить Excel сохранить файл .dbf, что легко в Calc, на самом деле это опция по умолчанию при нажатии Сохранить после открытия и изменения файла .dbf в Calc, в то время как Excel фактически заявляет, что файл «не может быть сохранен в текущем формате» и не так услужливо предлагает «сохранить его как последний формат» (опция .dbf не подходит). Существуют расширения / плагины для Excel, которые предназначены для выполнения работы (

Файл .dbf в Calc по-прежнему показывает тарабарщину вместо арабского. Помимо этого, откройте файл .csv, который вы экспортировали из таблицы атрибутов того же шейп-файла, и убедитесь, что вы указали UTF-8 в качестве кодировки (и запятых в качестве разделителей) в диалоге открытия. Текстовые файлы должны открываться во второй электронной таблице Calc с правильно отображенным арабским языком, и они должны содержать те же столбцы, что и .dbf, а также столбец OBJECTID в начале. Скопируйте и вставьте столбцы из .csv, содержащие соответствующий арабский язык, в .dbf (я фактически просто скопировал всю таблицу, за исключением крайнего левого столбца ID, чтобы сэкономить время; в любом случае, информация идентична). Нажмите Сохранить в измененном .dbf в LibreOffice (он спросит, действительно ли вы хотите использовать такой странный формат, как .dbf; да, вы делаете).

Повторите этот процесс для всех компонентов .dbf шейп-файлов из FGDB, заменив все колонки с гиббишем арабскими строками.

5) Как только вы восстановили части .dbf с вставленными арабскими столбцами, вы можете открыть шейп-файлы в QGIS, и они будут работать правильно на обоих языках, при условии, что вы зададите UTF-8 в качестве кодировки в векторе импорта Файл диалога. Однако они все равно не будут работать должным образом в ArcGIS (или, по крайней мере, не во всех версиях), поскольку ArcGIS не распознает кодировку автоматически или не позволяет выбрать ее при добавлении шейп-файла в проект. Arc нужен отдельный компонент для шейп-файла, называемый файлом преобразования кодовой страницы (.cpg), чтобы указать, какую кодировку читать.

6) Используйте текстовый редактор (блокнот, нано или любой другой, но не Word или любой другой текстовый процессор), чтобы создать текстовый файл, который содержит только пять символов «UTF-8». Сохраните его как .cpg для каждого из шейп-файлов (я просто нажимаю на кусочек шейп-файла в диалоговом окне «Сохранить как», затем стираю расширение и добавляю .cpg), в той же папке, что и шейп-файл (по сути, он становится еще одной частью HI шейп-файл из нескольких частей). Расширение .cpg сообщает Arc, что это файл, содержащий информацию о кодировке файла .dbf; как только он объединен в шейп-файл вместе со своими братьями и сестрами с тем же именем, но другим расширением, кодировка шейп-файла теперь автоматически распознается ArcGIS.

7) Вуаля. Теперь у вас есть шейп-файлы, содержащие как английские, так и арабские строки, насколько я могу судить, точно так же, как они были в исходном файле GeoDataBase. Они открываются в моих установках ArcMap и QGIS, и в обоих случаях строки на обоих языках отображаются правильно, в том числе в метках карты.

Предостережения:

  • Похоже, что не все копии ArcGIS экспортируют таблицу атрибутов в виде правильно заполненного текстового файла (хотя бы на одном компьютере при попытке экспортировать таблицу атрибутов в текстовый файл получается файл только с заголовками, а не со строками данных). НЕ правильное поведение Arc (конечно, он должен иметь возможность экспортировать таблицы атрибутов в виде текста), но для некоторых пользователей это может возникнуть, что делает остальные шаги невозможными.

  • Не похоже, что ArcGIS будет сохранять новые шейп-файлы с кодировкой UTF-8. Это повлияет только на пользователей, которые хотят создавать новые шейп-файлы из данных, а не на людей, которые просто хотят отображать, изменять и использовать их для создания карт. Обходной путь, по-видимому, заключается в том, чтобы возиться с реестром Windows, как описано здесь: ( http://support.esri.com/cn/knowledgebase/techarticles/detail/21106 ). Мне не приходилось сталкиваться с этим, потому что мои ArcGIS и QGIS, похоже, с радостью распознают шейп-файлы, которые я сохранил с помощью описанного выше процесса, и я могу изменять геометрию и записи таблицы или даже добавлять новые многоугольники с большим количеством арабского текста без каких-либо явных проблем ( хотя Arc, похоже, не хочет сохранять новые шейп-файлы с кодировкой UTF-8, он, похоже, готов их обновить / сохранить).

  • Я предполагаю, что функциональность LibreOffice в Windows такая же, как и на моем компьютере. Я использую GNU / Linux для большей части своей работы и загружаюсь только для Windows, если мне нужно использовать ArcGIS или Autocad для той или иной задачи, поэтому я сделал изменение файла .dbf в Libreoffice, работающем на Fedora. Я предполагаю, что это работает так же в Windows, но я не могу проверить это без установки LibreOffice на мой раздел Windows, и мое текущее подключение к Интернету немного медленное для ненужных загрузок. Существуют плагины для Excel, которые позволяют сохранять файлы .dbf в выбранной кодировке (например, exceltodbf.sourceforge.net/), но я их не пробовал. Могут быть и другие способы манипулирования и сохранения .dbf, но я не стал их рассматривать после того, как нашел достаточно простой способ сделать это с помощью LibreOffice.

  • Похоже, что этой проблемы можно избежать, если вы заплатите за расширение «Производственное сопоставление» в ArcGIS, которое позволяет напрямую преобразовывать FGDB в шейп-файлы с кодировкой UTF-8 в соответствии с этой страницей: http://resources.arcgis.com/en/help /main/10.1/index.html#//0103000001m1000000 . Почему эта довольно базовая функциональность (Unicode существует уже некоторое время, и существует множество языков, отличных от английского), доступна только для тех клиентов, которые платят дополнительно - это вопрос для ESRI.


0

Сначала вам нужно выяснить, в какой кодировке находятся входные данные, чтобы вы могли рассказать своим инструментам, как преобразовать данные в соответствующую кодировку. Если у вас есть Access, я бы попытался экспортировать таблицу в текст непосредственно из MDB и установить выходную кодировку в UTF8. Если вы открываете экспортированный шейп-файл в ArcGIS, правильно ли установлена ​​кодировка? DBF поддерживает кодовые страницы , и возможно, что OGR не подберет правильную для преобразования.

Есть также способы заставить MDBtools (используемый как часть драйвера OGR) явно установить поток ввода, но сначала я попробую другие подходы.


0

Я лучше пойду в ArcGIS. Просто установите кодировку UTF-8 в ArcGIS, следуя инструкциям здесь . После этого просто экспортируйте классы объектов в ShapeFile. Теперь вы получите дополнительный файл CPG (файл кодовой страницы) с каждым слоем. Это всего лишь текстовый файл со строкой «UTF-8», и все ваши данные автоматически кодируются в UTF-8.

Если вы заинтересованы в использовании другой кодировки, просто посмотрите инструкции.

Важно, чтобы после завершения этого назначения вы изменили этот параметр на значение по умолчанию, так как если вы сохраните это значение, например, «UTF-8», то в будущем ArcGIS будет экспортировать все ShapeFiles с использованием кодировки «UTF-8».

Надеюсь, что это поможет вам.

Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.