У меня есть один из моих специалистов по ГИС, оцифровывающий некоторые строки в QGIS в формате шейп-файла. Я не знаю, как он это сделал (как и он), но каким-то образом шейп-файл стал поврежденным. Это создавало случайные линии, или некоторые из созданных им линий просто исчезали. Я вошел в ArcCatalogue, чтобы посмотреть, как он выглядит в ArcGIS, и вот что я увидел:

Обратите внимание на значок вопросительного знака, где я должен увидеть значок «линии» шейп-файла. Очевидно, что ArcCatalogue не может прочитать этот файл. Кроме того, второй файл dbf, похоже, был создан с прикрепленным к концу _packed. Когда я смотрю на шейп-файл с помощью проводника Windows, я вижу, что для шейп-файла 'M3_PRE_SMU_lines_10Apr13_SMC.dbf' уже есть файл .dbf, поэтому я не знаю, откуда появился этот _пакованный шейп-файл, и я не могу найти что-либо в Интернете это говорит с этим.

Я попытался добавить этот файл в ArcMap и получил следующую ошибку:

Ошибка довольно очевидна ... количество фигур не соответствует количеству записей. Я просто не знаю, почему это происходит. Кажется, в Интернете нет ничего, что объясняло бы, как это происходит в QGIS, но я вижу пару инструментов для ремонта. Я сам исправил это, просто открыв QGIS, добавив слой, а затем щелкнув правой кнопкой мыши по слою и сохранив другой шейп-файл. Итак, я решил обойти, но я надеюсь найти решение, которое предотвратит это в первую очередь. Спасибо майк

объяснение

OGR (часть GDAL) - это библиотека, используемая QGIS для доступа к шейп-файлам. Когда OGR удаляет объекты, он не удаляет их сразу, а просто отмечает объекты как удаленные. Время от времени выполняется команда repack , которая создает новый файл с суффиксом _repack и копирует все функции, которые не помечены как удаленные, в этот новый файл. Как только он заканчивается, оригинальный .dbf заменяется на _repack.dbf. Затем он делает то же самое с шейп-файлом: создайте новый (_packed.shp), скопируйте все не удаленные функции и в конечном итоге замените оригинальный .shp.

Кажется, где-то в этом процессе что-то не удалось (может быть, сбой?).

В рамках этого процесса идентификаторы объектов меняются, поэтому я предполагаю, что shp (геометрия), который у вас есть, и dbf (таблица атрибутов) используют разные идентификаторы объектов для одних и тех же объектов, что приводит к странному поведению, которое вы испытываете. Кажется, что один из двух файлов по-прежнему содержит (часть) удаленных функций, а другой - нет.

Как с этим бороться

Обновление, ноябрь 2016: GDAL 2.2 поставляется со встроенной функциональностью для автоматического вызова repack при записи файла на диск. Поэтому, прежде чем делать что-то еще: проверьте версию GDAL в диалоговом окне QGIS about и обновите свой выпуск GDAL (часто поставляется как часть QGIS) до последней версии.

Вероятно, вы не можете ничего с этим поделать, кроме регулярного резервного копирования, чтобы не потерять больше данных, чем вы можете обработать (вы все равно делаете это, верно? 😉). И если вы найдете способ воспроизвести это (лучше всего с примером набора данных), создайте отчет об ошибке .

Если вы столкнулись с этой проблемой снова, вы также можете попытаться создать пространственный индекс в шейп-файле. В этом процессе QGIS снова вызовет repack для шейп-файла и может «починить» shp / dbf. Но это только непроверенное предположение.

Как упомянуто @rhm и в комментариях, это может также помочь переименовать файл {xyz} _packed. {Ext} в {xyz}. { Ext } . Если упакованный файл уже полностью записан, и это было просто переименование, которое не удалось, то этот шаг абсолютно действителен вручную. Однако, если _packed файл не был полностью написан, возможно, вам не хватает информации из частей ваших функций. Поэтому, прежде чем пытаться сделать это, сделайте резервные копии всех задействованных файлов.

Справочная информация о том, когда вызывается repack

Между QGIS 2.0 и 2.8 repack вызывался всякий раз, когда слой выгружался (выход из QGIS, загрузка другого проекта ...). Если объект был удален или геометрия изменена, файлы .shp и .dbf с записями, помеченными как удаленные , присутствовали.

Начиная с QGIS 2.10, repack вызывается всякий раз, когда слой сохраняется после операции, которая потенциально может добавить удаленный флаг в записи. Поэтому файлы должны теперь всегда находиться в нормальном состоянии для обработки другими приложениями.

Это случилось со мной в QGIS. Мне удалось решить проблему, просто удалив «_packed» из имени файла, как кто-то предложил в разделе комментариев выше.

Может быть, это еще одна проблема поврежденного файла индекса .shx. Тип геометрии должен храниться в заголовках .shp и .shx. Если они не совпадают, программа выдаст ошибку.

Похоже, что QGIS не очень строг в отношении поврежденных индексных файлов и может воссоздать его Save As..., в то время как ARCGIS настаивает на правильном индексном файле и создает упакованный dbf (таблица атрибутов) для функций, которые можно найти через правильные части индексный файл, или, возможно, без использования индекса.

Появление удаленных объектов и / или странное поведение шейп-файлов, из которых были удалены объекты в QGIS, является известной ошибкой, см. Этот отчет об ошибке 11007 и связанный с этим вопрос. Удаленные полигоны возвращаются к более старым версиям . Помимо того, что у ArcGIS возникают проблемы с такими шейп-файлами, при сохранении в QGIS как TAB-файлы MapInfo они вызывают сбой плагина MapInfo RouteFinder, если таблицы не были сначала упакованы в MapInfo перед загрузкой RouteFinder. Запустить Universal Translator для преобразования этих поврежденных шейп-файлов в MapInfo не удается.

Как вы обнаружили, проблему можно решить, выполнив команду «Сохранить как» в QGIS.