¿Comprender por qué la herramienta ArcPy Cost Path Analysis es más rápida que ArcObjects? [cerrado]

Cerrada . Esta pregunta necesita estar más centrada . Actualmente no está aceptando respuestas.

¿Quieres mejorar esta pregunta? Actualice la pregunta para que se centre en un problema solo editando esta publicación .

Cerrado hace 3 años .

Aunque uso Python para crear scripts / servicios de geoprocesamiento, tenía la impresión de que usar ArcObjects para hacer las operaciones equivalentes tendrá un mejor rendimiento.

He publicado ArcGIS Server GP Service: ¿RasterIO.dll se bloquea cuando ArcSOC.exe y ArcGIS Geoprocessing Script funcionan bien en el escritorio, pero se bloquean como servicio de geoprocesamiento? en los últimos días sobre la obtención de scripts de geoprocesamiento que usan herramientas de Spatial Analyst para trabajar como servicios de geoprocesamiento. Mi fecha límite se acerca rápidamente, por lo que he decidido seguir la ruta SOE para lograr la funcionalidad deseada.

Obtener un análisis de ruta de costo en ArcObjects fue relativamente sencillo utilizando .NET ESRI.ArcGIS.SpatialAnalyst.RasterDistanceOpClass , específicamente los métodos CostDistanceFull () y CostPath ().

Algunos fragmentos de código de cómo estoy haciendo las cosas:

Pitón

# 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);

Un análisis de ruta de costo en ArcPy (usando sa.CostDistance y sa.CostPath) toma aproximadamente 15-20 segundos. Usando exactamente las mismas entradas, la rutina basada en ArcObjects tarda 55-60 segundos. Incluso el uso del geoprocesador .NET es significativamente más lento que arcpy.

Creo que mis preguntas aquí son:

¿Las implementaciones de ArcPy y ArcObjects apuntan a la misma base de código (a través de sus envoltorios Python y .NET)?
¿Algún consejo para optimizar el análisis de ruta de costo basado en ArcObject?

— usuario890
fuente

¿ha perfilado su código para encontrar exactamente qué llamada está tardando más? ¿Puedes mostrar un fragmento de código?

— Ragi Yaser Burhum

Entendí que ArcPy era solo un contenedor alrededor de ArcObjects, por lo que es curioso. No sé si esto es relevante, pero hay una respuesta aquí: gis.stackexchange.com/questions/171304/… .. Observa que las herramientas de GeoProcessing deben cargarse, en comparación con las herramientas de la GUI. Entonces, si ArcPy crea una instancia del código relevante de antemano o ajusta una función GUI en lugar de la función ToolBox, podría omitir algún tiempo de configuración. Suficientemente fácil de verificar al ver si la brecha de velocidad se reduce con conjuntos de datos más grandes.

— AnserGIS

Según el Tour , solo debe hacerse una pregunta por pregunta.

— PolyGeo

Creo que es porque su Python está utilizando ArcPy para llamar a tareas de geoprocesamiento, que se ejecutan en procesos de 64 bits . ArcObjects ocurre en procesos de 32 bits .

— alexGIS
fuente

No hay suficiente información en esta publicación para hacer esas suposiciones. Aun así, el servidor es de 64 bits o si tiene BG de 64 bits instalado, podría ejecutar su herramienta de función contra él. Sin embargo, para entretener el pensamiento, simplemente pasar de 32 a 64 bits no proporciona un aumento de rendimiento. Es muy situacional cuando / si 64 bits es "más rápido" que 32 bits.

— KHibma

OP puede aclarar si estos supuestos están fuera de la base o no. Los enlaces que proporcioné respaldan los supuestos, como que el rendimiento es mejor porque hay acceso a más recursos del sistema, etc. Hay una razón por la cual la mayoría de los sistemas operativos son de 64 bits en estos días, y uno de los grandes es el aumento del rendimiento. Así que, en igualdad de condiciones, especialmente con un gran número de procesos, los procesos de 64 bits superarán los procesos de 32 bits.

— alexGIS