Comprendre pourquoi l'outil ArcPy Cost Path Analysis est plus rapide qu'ArcObjects? [fermé]

Fermé . Cette question doit être plus ciblée . Il n'accepte pas actuellement les réponses.

Voulez-vous améliorer cette question? Mettez à jour la question afin qu'elle se concentre sur un problème uniquement en modifiant ce message .

Fermé il y a 3 ans .

Bien que j'utilise python pour créer des scripts / services de géotraitement, j'avais l'impression que l'utilisation d'ArcObjects pour effectuer les opérations équivalentes aurait de meilleures performances.

J'ai publié le service ArcGIS Server GP - RasterIO.dll plante ArcSOC.exe et le script de géotraitement ArcGIS fonctionne correctement sur le bureau, mais se bloque en tant que service de géotraitement? au cours des derniers jours sur l'obtention de scripts de géotraitement qui utilisent les outils Spatial Analyst pour fonctionner en tant que services de géotraitement. Mon échéance approche à grands pas, j'ai donc décidé de suivre la voie SOE pour atteindre la fonctionnalité souhaitée.

Obtenir une analyse du chemin de coût dans ArcObjects était relativement simple à l'aide des méthodes .NET ESRI.ArcGIS.SpatialAnalyst.RasterDistanceOpClass , en particulier les méthodes CostDistanceFull () et CostPath ().

Quelques extraits de code de la façon dont je fais les choses:

Python

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

Une analyse de la trajectoire des coûts dans ArcPy (en utilisant sa.CostDistance et sa.CostPath) prend environ 15-20 secondes. En utilisant exactement les mêmes entrées, la routine basée sur ArcObjects prend 55 à 60 secondes. Même l'utilisation du géoprocesseur .NET est beaucoup plus lente que l'arcpy.

Je suppose que mes questions ici sont:

Les implémentations ArcPy et ArcObjects pointent-elles vers la même base de code (via leurs wrappers Python et .NET)?
Des conseils pour optimiser l'analyse des chemins de coûts basée sur ArcObject?

— user890
source

avez-vous profilé votre code pour trouver exactement quel appel prend le plus de temps? Pouvez-vous montrer un extrait de code?

— Ragi Yaser Burhum

Ma compréhension était ArcPy juste un wrapper autour d'ArcObjects, donc c'est curieux. Je ne sais pas si cela est pertinent mais une réponse ici: gis.stackexchange.com/questions/171304/… .. Remarque que les outils de géotraitement doivent être chargés, par rapport aux outils GUI. Ainsi, si ArcPy instancie le code pertinent à l'avance ou encapsule une fonction GUI au lieu de la fonction ToolBox, cela peut sauter un certain temps de configuration. Assez facile à vérifier en voyant si l'écart de vitesse se réduit avec des ensembles de données plus importants.

— AnserGIS

Selon le Tour, il ne devrait y avoir qu'une seule question posée par question.

— PolyGeo

Je pense que c'est parce que votre Python utilise ArcPy pour appeler des tâches de géotraitement, qui s'exécutent dans des processus 64 bits . ArcObjects se produit dans des processus 32 bits .

— alexGIS
source

Il n'y a pas assez d'informations dans ce post pour faire ces hypothèses. Même ainsi, le serveur est 64 bits ou s'il a BG 64 bits installé, il pourrait exécuter son outil de fonction contre lui. Cependant, pour alimenter la réflexion, le simple fait de passer de 32 à 64 bits ne permet pas d'augmenter les performances. C'est très situationnel lorsque / si 64 bits est «plus rapide» que 32 bits.

— KHibma

OP peut clarifier si ces hypothèses sont hors base ou non. Les liens que j'ai fournis prennent en charge les hypothèses, comme l'amélioration des performances car il y a accès à davantage de ressources système, etc. Donc, toutes choses étant égales par ailleurs, en particulier avec une forte compression des nombres, les processus 64 bits exécuteront des processus 32 bits.

— alexGIS