Понимание того, почему ArcPy Cost Path Analysis быстрее, чем ArcObjects? [закрыто]

15

Хотя я использую python для создания сценариев / сервисов геообработки, у меня сложилось впечатление, что использование ArcObjects для выполнения эквивалентных операций будет иметь более высокую производительность.

Я разместил сервис ArcGIS Server GP - RasterIO.dll приводит к сбою ArcSOC.exe и скрипта геообработки ArcGIS в рабочем столе, но работает как сервис геообработки? за последние пару дней о получении скриптов геообработки, которые используют инструменты Spatial Analyst для работы в качестве сервисов геообработки. Мой крайний срок быстро приближается, поэтому я решил пойти по пути SOE для достижения желаемой функциональности.

Получение анализа пути затрат в ArcObjects было относительно простым с использованием .NET ESRI.ArcGIS.SpatialAnalyst.RasterDistanceOpClass , в частности методов CostDistanceFull () и CostPath ().

Некоторые фрагменты кода того, как я делаю вещи:

питон

# Get Cost Path Origin and Destination Points
inputPointsShp = 'D:/RasterStuff/test_points.shp'
arcpy.MakeFeatureLayer_management(inputPointsShp,"origin",' "TYPE" = \'ORIGIN\' ')
arcpy.MakeFeatureLayer_management(inputPointsShp,"destination",' "TYPE" = \'DESTINATION\' ')

# Check out the ArcGIS Spatial Analyst extension license
arcpy.CheckOutExtension("Spatial")

# Execute CostDistance
outCostDistance = CostDistance("origin",SOURCE_RASTER,"#","backlink")

# Execute CostPath
outCostPath = CostPath("destination", outCostDistance,"backlink")

# Convert Result to Polyline
arcpy.RasterToPolyline_conversion(outCostPath, "leastCostPath")
featSet = arcpy.FeatureSet("leastCostPath")

C #

IDistanceOp distanceOp = new RasterDistanceOpClass();
IRasterBandCollection costDistanceRaster = (IRasterBandCollection)distanceOp.CostDistanceFull((IGeoDataset)sourceFc, (IGeoDataset)raster, true, true, false);
IRasterBand distanceRaster = costDistanceRaster.Item(0);
IRasterBand backLinkRaster = costDistanceRaster.Item(1);

IGeoDataset costPath = distanceOp.CostPath((IGeoDataset)destFc, (IGeoDataset)distanceRaster, (IGeoDataset)backLinkRaster, ESRI.ArcGIS.SpatialAnalyst.esriGeoAnalysisPathEnum.esriGeoAnalysisPathForEachCell);

Анализ пути затрат в ArcPy (с использованием sa.CostDistance и sa.CostPath) занимает около 15-20 секунд. Используя точно такие же входные данные, процедура на основе ArcObjects занимает 55-60 секунд. Даже использование .NET Geoprocessor значительно медленнее, чем arcpy.

Я думаю, мои вопросы здесь:

  1. Указывают ли реализации ArcPy и ArcObjects на одну и ту же базу кода (через свои обертки Python и .NET)?
  2. Любые советы по оптимизации анализа пути затрат на основе ArcObject?
arcpy arcobjects c# performance cost-path user890
источник
2
Вы профилировали свой код, чтобы выяснить, какой именно вызов занимает больше всего времени? Можете ли вы показать фрагмент кода?
Раги Язер Бурхум
Насколько я понимаю, ArcPy был просто оберткой вокруг ArcObjects, так что это любопытно. Я не знаю, уместно ли это, но один ответ здесь: gis.stackexchange.com/questions/171304/… .. Заметим, что инструменты геообработки нужно загружать по сравнению с инструментами с графическим интерфейсом. Таким образом, если ArcPy заранее создает соответствующий код или переносит функцию GUI вместо функции ToolBox, он может пропустить некоторое время установки. Достаточно легко проверить, видя, уменьшается ли разрыв скорости с большими наборами данных.
AnserGIS
В соответствии с Туром на каждый вопрос должен быть задан только один вопрос.
PolyGeo

Ответы:

0

Я считаю, что это потому, что ваш Python использует ArcPy для вызова задач геообработки, которые выполняются в 64-битных процессах . ArcObjects происходит в 32-битных процессах .

alexGIS
источник
2
В этом посте недостаточно информации, чтобы делать такие предположения. Несмотря на это, Сервер является 64-битным, или, если у него установлена ​​64-битная BG, он может запустить свой инструмент для работы с ним. Однако, чтобы развлечь эту мысль, простой переход с 32-разрядной на 64-разрядную версию не обеспечивает увеличения производительности. Это очень ситуативно, когда / если 64 бит «быстрее», чем 32 бит.
Хибма
ОП может уточнить, являются ли эти предположения неосновными или нет. Ссылки, которые я привел, подтверждают предположения, например, о том, что производительность лучше, потому что есть доступ к большему количеству системных ресурсов и т. Д. Есть причина, по которой большинство ОС сегодня 64-битные, и одна из самых больших - повышение производительности. Таким образом, при прочих равных условиях, особенно при значительном сокращении чисел, 64-разрядные процессы будут выполнять 32-разрядные процессы.
alexGIS