Entendendo por que a ferramenta ArcPy Cost Path Analysis é mais rápida que o ArcObjects? [fechadas]

Fechado . Esta questão precisa ser mais focada . No momento, não está aceitando respostas.

Deseja melhorar esta pergunta? Atualize a pergunta para que ela se concentre apenas em um problema editando esta postagem .

Fechado há 3 anos .

Embora eu use python para criar scripts / serviços de geoprocessamento, fiquei com a impressão de que o uso do ArcObjects para realizar operações equivalentes terá melhor desempenho.

Eu publiquei o ArcGIS Server GP Service - RasterIO.dll, causando um erro fatal no ArcSOC.exe e no ArcGIS Geoprocessing Script, funciona bem na área de trabalho, mas falha como serviço de geoprocessamento? nos últimos dias, sobre como obter scripts de geoprocessamento que usam as ferramentas do Spatial Analyst para trabalhar como serviços de geoprocessamento. Meu prazo está se aproximando rapidamente, por isso decidi seguir a rota SOE para alcançar a funcionalidade desejada.

Obter uma análise de caminho de custo no ArcObjects foi relativamente simples, usando o .NET ESRI.ArcGIS.SpatialAnalyst.RasterDistanceOpClass , especificamente os métodos CostDistanceFull () e CostPath ().

Alguns trechos de código de como estou fazendo as coisas:

Pitão

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

Uma análise de caminho de custo no ArcPy (usando sa.CostDistance e sa.CostPath) leva aproximadamente 15 a 20 segundos. Usando exatamente as mesmas entradas, a rotina baseada em ArcObjects leva de 55 a 60 segundos. Mesmo usando o geoprocessador .NET é significativamente mais lento que o arcpy.

Eu acho que minhas perguntas aqui são:

As implementações do ArcPy e ArcObjects estão apontando para a mesma base de código (por meio de wrappers Python e .NET)?
Alguma dica para otimizar a análise de caminho de custo baseada no ArcObject?

— user890
fonte

você definiu o perfil do seu código para descobrir exatamente qual chamada está demorando mais? Você pode mostrar um trecho de código?

— Ragi Yaser Burhum 08/07/12

Meu entendimento era que o ArcPy era apenas um invólucro do ArcObjects, o que é curioso. Não sei se isso é relevante, mas há uma resposta aqui: gis.stackexchange.com/questions/171304/… .. Observa que as ferramentas de GeoProcessing precisam carregar, em comparação com as ferramentas da GUI. Portanto, se o ArcPy instancia o código relevante antecipadamente ou quebra uma função da GUI em vez da função ToolBox, ele pode pular algum tempo de configuração. Fácil de verificar, verificando se a diferença de velocidade diminui com conjuntos de dados maiores.

— AnserGIS 29/03

De acordo com o Tour , deve haver apenas uma pergunta por pergunta.

— PolyGeo

Acredito que é porque seu Python está usando o ArcPy para chamar tarefas de geoprocessamento, que estão sendo executadas em processos de 64 bits . ArcObjects acontece em processos de 32 bits .

— alexGIS
fonte

Não há informações suficientes neste post para fazer essas suposições. Mesmo assim, o servidor tem 64 bits ou, se tiver 64 bits instalado, ele poderá executar sua ferramenta de função. No entanto, para entreter o pensamento, simplesmente passar de 32 para 64 bits não fornece um aumento de desempenho. É muito situacional quando / se 64 bits é 'mais rápido' que 32 bits.

— KHibma

O OP pode esclarecer se essas suposições estão fora da base ou não. Os links que forneci suportam as premissas, como desempenho melhor porque há acesso a mais recursos do sistema etc. Há uma razão pela qual a maioria dos sistemas operacionais tem 64 bits atualmente e um dos grandes é o aumento de desempenho. Portanto, sendo tudo igual, especialmente com processamento de números pesados, os processos de 64 bits executarão processos de 32 bits.

— AlexGIS