Розуміння, чому інструмент аналізу шляху витрат ArcPy швидше, ніж ArcObjects? [зачинено]


15

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

Я розмістив сервіс GP ArcGIS Server - збій RasterIO.dll ArcSOC.exe і сценарій геопроцедури ArcGIS працює на робочому столі добре, але працює як послуга геопроцесори? за останні кілька днів про те, як отримати сценарії геообробки, які використовують засоби просторової аналітики для роботи в якості геопроцесорних служб. Мій термін швидко наближається, тому я вирішив пройти маршрут ДП для досягнення бажаної функціональності.

Аналіз траєкторії витрат у 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?

2
Ви профілювали свій код, щоб точно знайти, який дзвінок триває найдовше? Чи можете ви показати фрагмент коду?
Рагі Ясер Бурхум

Моє розуміння було ArcPy просто обгорткою навколо ArcObjects, тому що цікаво. Я не знаю, чи це актуально, але одна відповідь тут: gis.stackexchange.com/questions/171304/… .. Зазначає, що інструменти GeoProcessing потрібно завантажувати порівняно з інструментами графічного інтерфейсу. Отже, якщо ArcPy заздалегідь створить відповідний код або замість функції GUI замість функції ToolBox, він може пропустити деякий час налаштування. Досить просто перевірити, побачивши, чи зменшується розрив у швидкості при більших наборах даних.
AnserGIS

Згідно туру, на кожне питання повинно бути лише одне питання.
PolyGeo

Відповіді:


0

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


2
У цій публікації недостатньо інформації, щоб зробити ці припущення. Незважаючи на це, Сервер має 64-бітний або якщо у нього встановлений 64-бітний БГ, він може виконати проти нього свій функціональний інструмент. Однак, щоб розважити думку, просто перехід від 32 до 64 біт не забезпечує підвищення продуктивності. Це дуже ситуативно, коли / якщо 64-бітний 'швидше', ніж 32-бітний.
Хібма

ОП може уточнити, чи є ці припущення поза базовими чи ні. Посилання, які я надав, підтримують припущення, як продуктивність краща, оскільки є доступ до більшої кількості системних ресурсів тощо. Існує причина, чому більшість ОС сьогодні 64-бітні, а одним із великих є підвищення продуктивності. Таким чином, при рівних обставинах, особливо при хрускоті великого числа, 64-бітні процеси будуть виконувати 32-бітні процеси.
alexGIS
Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.