Я добавляю это для любого в будущем, кто читает эту ветку.
Вот все, что я узнал, изучая эту проблему и получая полное расстояние между точками вызова.
Наша первая проблема проистекала из статической природы RasterCatalog. Изменение растров, на которых это основано, НЕ меняет растр внутри RasterCatalog. Оказалось, что у нас была древняя версия, которой не было рядом с картой береговой линии. Извлеченный урок: перестраивайте RasterCatalog КАЖДЫЙ РАЗ, когда вы меняете растры, на которых он основан.
Растр расстояния с добавленными весами становится довольно громоздкой для работы. Посмотрите на следующий сценарий: Исходное значение растра составляет 1 общее расстояние, на которое я хочу посмотреть, составляет 117 км. Размер ячейки 1 метр. Если растр теперь имеет взвешенное значение 48, то общее расстояние, которое я хочу посмотреть, составит 117 км * 48 !!! Таким образом, расстояние в методе CostDistance - это не расстояние до ячейки, а взвешенное расстояние, по-видимому, добавляя значение в каждой ячейке, пока сумма каждой ячейки не станет равной значению, пройденному для общего расстояния. Даже если сам размер ячейки составляет 1 метр !!!
Растр расстояния все сфокусирован на точке происхождения. Поэтому, когда вы вызываете подпрограмму CostDistance, вы не хотите включать точку отправления в этот список. если вы это сделаете, вы получите одно очко с расстоянием 0 (это даже тупая поддержка ESRI)
В то время как многие методы используют Envelope для ограничения своего процесса, два самых дорогих из них: установка значения для растра и извлечение растра без области внутри многоугольника, игнорирование всех настроек огибающей и автоматическое применение этого всегда ко всему растру. К сожалению для нас, мы можем сократить это только путем создания массивных перекрывающихся сегментов и назначения сегмента определенной области в штучной упаковке. Но при этом мы должны быть осторожны (что сложно), чтобы основная область операций не существовала в неправильной перекрытой области. (другими словами, все наши перекрытия должны быть тщательно выбраны, чтобы не содержать каких-либо основных точек интереса!) Причина этого заключается в том, что мы перемещаемся по RasterCatalog, выбирая правильный растр в зависимости от того, где существует выбранная станция береговой охраны. Чтобы еще больше усложнить наш процесс, Перекрытие должно позволить нам перемещаться на расстояние до 120 км от нашей исходной точки, не сходя с края карты и не перекрывая другие основные достопримечательности. Sheesh.
Единственное, что я узнал, это то, что легко растянуть математику, но когда вы хотите либо «проткнуть дыру» в растре (блокировки), либо установить пончик со значением, а внутри пончика есть Значение 1 (задержка, как в случае блокировки) приводит к сложной комбинации инструментов и вызовов ArcObject. Что приводит к последнему уроку: ArcObjects не может делать все. Поэтому я иногда вынужден делать что-то с помощью медленных, громоздких инструментов, написанных на python. Я также узнал, что разработчики инструментов ESRI ничего не знали о поддержании согласованности. Иногда они брали растровую базу данных, а иногда им требовался растр, а иногда - набор функций. И они не возвращают данные в том же формате, который требуется для ввода!
Смущенный? Не волнуйся, это ESRI.