Почему Intersect выдает ОШИБКУ 999999: Ошибка при выполнении функции Неверная топология [Слишком много конечных точек lineseg]?

Я пытаюсь запустить процесс Intersect в arcgis 10 sp 3 с двумя наборами файлов (аспект и наклон) с высотой до 1 м на площади 65 000 кв. Км. Аспект имеет 9 930 384 записей, а уклон имеет 31 435 462 записей (всего около 12 ГБ в 2 файловых гео-базах данных).

Я выполнил ремонт геометрии примерно 3 раза, и теперь наборы данных не сообщают об ошибках (каждый раз занимал более 30 часов).

Теперь я получаю

Выполнение (Пересечение): Пересечение "D: \ SCRATCH \ Projects \ 106 \ data \ 7_asp_Merge.gdb \ asp_HghstRez_M_rep #" D: \ SCRATCH \ Проекты \ 106 \ data \ working \ working.gdb \ AsSl_Int ALL # INPUT Время запуска: вс 23 октября 02:19:10 2011 Особенности чтения ...

Обработка плитки ...

ОШИБКА 999999: Ошибка при выполнении функции.

Неверная топология [Слишком много конечных точек lineseg.]

Не удалось выполнить (Пересечь).

Сбой в ВС 23 октября 04:09:12 2011 (Истекшее время: 1 час 50 минут 2 секунды)

Это действительно проблема топологии или проблема размера файла?

Я попытался использовать инструмент ArcINFO SPLIT, но он не работает даже при наличии более 1 ТБ свободного места на диске, а при меньшем наборе файлов возникают неровные края. Я не могу использовать DICE, так как области, которые пересекаются между asp и склоном, должны быть точно такими же. Я понимаю, что в больших наборах данных ESRI взламывает (автоматически фрагментирует) наборы данных - это может вызывать проблемы? Есть ли еще информация, которую я могу предоставить, чтобы решить проблему.

Технические характеристики машин больше, чем минимум ESRI - у нас 16 ГБ ОЗУ, Intel Xeon, Windows 7, 64-битные, 2 x 1 ТБ диска и более 1,2 ТБ свободного места на дисках. Все файлы, используемые в процессе, находятся на локальных дисках.

только что нашел это объяснение (2 июля 2012 г.), которое дает много полезных советов по решению проблем.

http://blogs.esri.com/esri/arcgis/2010/07/23/dicing-godzillas-features-with-too-many-vertices/

— GeorgeC
источник

Ограничение размера файла для операционной системы Windows составляет 2 ГБ. (3 ГБ с / 3 ГБ на XP). Попробуйте пролитой инструмент в ArcGIS с большими наборами данных «МОЗАИЧНОЕ» resources.esri.com/help/9.3/arcgisdesktop/com/gp_toolref/...

— Mapperz

Важная информация из ссылки, отправленной Mapperz: «Корпоративная и файловая

— RyanKDalton

У вас есть склоны и растровые изображения? Если так, у вас есть пространственный аналитик?

— Кирк Куйкендалл

@Mapperz, это зависит от файловой системы. FAT ограничен 2 ГБ, FAT32 составляет 4 ГБ, а NTFS не ограничен в соответствии с: microsoft.com/resources/documentation/windows/xp/all/proddocs/…

— blah238

Джордж, для расчета растра, вы можете либо повторно выбрать общий размер ячейки (например, 1 м), либо обработать различные патчи отдельно. Это заслуживает некоторого размышления, поскольку наклон или аспект, рассчитанный с разрешением 30 м, не совсем сопоставимы с тем, который рассчитан с разрешением 1 м. Трудно дать общий совет из-за отсутствия информации о целях этого расчета.

— whuber

Ответы:

Очень немногие смежные ячейки в детализированной ЦМР будут иметь одинаковые значения как наклона, так и аспекта. Следовательно, если входные объекты представляют смежные области общего наклона и общего аспекта, следует ожидать, что в результате этой процедуры пересечения в среднем будет иметься почти один элемент на ячейку.

Первоначально в ЦМР было 65000 * 1000 ^ 2 = 6,5 клеток E10. Для представления каждого из них требуются как минимум четыре упорядоченные пары либо 4-байтовых целых, либо 8-байтовых плавающих координат, либо 32-64 байтов. Это требование 1,3 E12 - 2,6 E12 байт (1,3 - 2,5 ТБ). Мы даже не начали учитывать накладные расходы на файл (функция хранится как нечто большее, чем просто его координаты), индексы или значения атрибутов, которым самим может потребоваться 0,6 ТБ (если они хранятся с двойной точностью) или больше (если они хранятся как текст), плюс хранилище для идентификаторов. Ах да - ArcGIS любит хранить по две копии каждого пересечения, удваивая все. Вам может понадобиться 7-8 ТБ только для хранения выходных данных.

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

Решение состоит в том, чтобы выполнять сеточные операции, используя структуры данных сетки, а не векторные структуры данных. Если выходной вектор абсолютно необходим, выполните векторизацию после завершения всех операций с сеткой.

— Whuber
источник

Принято с большой грустью. Вместо того, чтобы объединять наборы данных 30 м, 10 м и 1 м, я вместо этого запускаю asp + slp + veg, пересекает / забивает по каждому набору данных отдельно, а затем объединяет их.

— GeorgeC

Использование стратегии пространственного разделения позволило нам завершить проект. Набор данных, который обрабатывался 7 часов (а иногда и падал), обрабатывался в течение примерно 100 минут при разделении на 6 частей, а затем объединялся в течение 10 минут. К этому добавьте примерно 40 минут, чтобы изменить модели для эффективной обработки нескольких деталей с минимальными затратами (для каждой итерации), и в целом это экономит половину времени обработки (по крайней мере). Таким образом, процесс, который в противном случае занимал бы около 200 часов, занимал менее 50 часов и занимал всего около 15 часов «реальной» работы (при принятии решения о том, как разбивать данные, вводить переменные в модели и т. Д.

— GeorgeC

Мой опыт использования сплит-инструмента и ремонтной геометрии. Это работает для меня, потому что тот, над которым я работал, использовал векторный слой, который я преобразовал из растра в вектор. Сначала я попытался разделить инструмент и выдал ошибку. Итак, мне пришлось использовать ремонтную геометрию и это зависит от того, как долго она работает. Я делал это дважды, потому что всякий раз, когда вы вносили какие-либо изменения или редактировали, вам все равно придется повторно запускать ремонт geomtry, прежде чем вы сделаете разделение. это сработало для меня.

Кстати, я выполнил ремонт geomtry на обоих слоях: шейп-файл и файловая база геоданных. Я предлагаю вам провести ремонтную геомтрию на ночь.

— Проберт
источник

Еще одна вещь, которую я забыл. Могу ли я предложить, что когда вы делаете что-то подобное, я рекомендую попробовать открыть новый ArcMap и запустить эти инструменты? Чтобы удалить временные файлы, которые вы уже открыли, закройте его и откройте ArcMap. Это очищает темп. Это мой один цент предложить.

— ПРОБЕРТ

Спасибо. Я выполнил ремонт geom 3-4 раза, и теперь наборы данных не сообщают об ошибках. Обычно это работает, но я думаю, что наборы данных слишком велики, как объясняет Уубер ...

— GeorgeC

Джордж, я рад, что это сработало для тебя. Да, я читал, что объяснение whuber, но мой вопрос к вам, вы слились наклон и аспект? Если так, то когда вы используете инструмент разделения, какой слой объектов вы использовали для разделения этих слоев, с которыми вы слились? Например, мне пришлось использовать 24 квадрацикла (около 24 из них, что не так уж и много), чтобы разделить слой с уклоном и подъемом. Может быть, вы могли бы попытаться сузить до меньшего слоя, который может разделиться с вашим объединенным слоем?

— ПРОБЕРТ

Я слил наклон и аспект, и это сработало, но это был неправильный процесс ... нам нужно было пересечь, и это не работает. Чтобы разделить, я получил копию национальной карты топографических карт 100k и использовал ее отдельно на спине и склоне. Зона покрыта 30 листами карты.

— GeorgeC

Вы запустили сетку топографических карт 100k, чтобы очистить геометрию? Поскольку я спросил, у меня были обнаружены некоторые ошибки и мне пришлось сделать чистый ремонт. Так что сработало у меня. Если вы все еще сталкиваетесь с большим количеством проблем, можете ли вы попытаться заставить их разделить национальные 100 тыс. На более мелкие? Как разделить их на три?

— ПРОБЕРТ