เข้าใจว่าทำไมเครื่องมือ ArcPy Cost Path Analysis เร็วกว่า ArcObjects [ปิด]


15

แม้ว่าฉันจะใช้หลามเพื่อสร้างสคริปต์ / บริการประมวลผลเชิงภูมิศาสตร์ แต่ฉันก็รู้สึกว่าการใช้ ArcObjects เพื่อทำงานที่เทียบเท่าจะมีประสิทธิภาพที่ดีขึ้น

ฉันได้โพสต์ArcGIS Server GP Service แล้ว - RasterIO.dll crashing ArcSOC.exeและArcGIS Geoprocessing Script ทำงานได้ดีในเดสก์ท็อป แต่ล่มเป็น Geoprocessing Service? ในช่วงสองสามวันที่ผ่านมาเกี่ยวกับการรับสคริปต์ประมวลผลทางภูมิศาสตร์ที่ใช้เครื่องมือวิเคราะห์เชิงพื้นที่เพื่อทำงานเป็นบริการประมวลผลเชิงภูมิศาสตร์ กำหนดเส้นตายของฉันใกล้เข้ามาอย่างรวดเร็วดังนั้นฉันจึงตัดสินใจที่จะใช้เส้นทาง SOE เพื่อให้สามารถใช้งานได้ตามที่ต้องการ

การรับการวิเคราะห์เส้นทางต้นทุนใน ArcObjects นั้นค่อนข้างตรงไปตรงมาโดยใช้. NET ESRI.ArcGISSpatialAnalyst.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")

ค#

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 ก็ช้ากว่าอาร์คpyอย่างมาก

ฉันเดาคำถามของฉันที่นี่:

  1. การใช้งาน ArcPy และ ArcObjects ชี้ไปที่ฐานรหัสเดียวกัน (ผ่าน Python และ. NET wrappers) หรือไม่
  2. เคล็ดลับใด ๆ ในการเพิ่มประสิทธิภาพการวิเคราะห์เส้นทางต้นทุน ArcObject?

2
คุณทำโปรไฟล์ของคุณเพื่อหา iut ว่าการโทรใดที่ใช้เวลานานที่สุด? คุณสามารถแสดงข้อมูลโค้ดได้หรือไม่
Ragi Yaser Burhum

ความเข้าใจของฉันคือ ArcPy เป็นเพียงเสื้อคลุมรอบ ๆ ArcObjects เพื่อที่จะอยากรู้ ฉันไม่รู้ว่าสิ่งนี้เกี่ยวข้องหรือไม่ แต่มีคำตอบเดียวที่นี่: gis.stackexchange.com/questions/171304/ … .. โปรดทราบว่าเครื่องมือ GeoProcessing จำเป็นต้องโหลดเมื่อเทียบกับเครื่องมือ GUI ดังนั้นหาก ArcPy สร้างรหัสที่เกี่ยวข้องล่วงหน้าหรือตัดฟังก์ชั่น GUI แทนฟังก์ชั่นกล่องเครื่องมือมันอาจข้ามเวลาการตั้งค่าบางอย่าง ง่ายพอที่จะตรวจสอบโดยดูว่าช่องว่างความเร็วลดลงด้วยชุดข้อมูลขนาดใหญ่
AnserGIS

ตามทัวร์ควรมีเพียงหนึ่งคำถามที่ถามต่อคำถาม
PolyGeo

คำตอบ:


0

ผมเชื่อว่าเพราะงูหลามของคุณใช้ ArcPy จะเรียกงาน Geoprocessing ซึ่งมีการทำงานในกระบวนการ 64 บิต ArcObjects ที่เกิดขึ้นในกระบวนการ 32 บิต


2
โพสต์นี้มีข้อมูลไม่เพียงพอที่จะตั้งสมมติฐาน ถึงกระนั้นเซิร์ฟเวอร์ก็เป็น 64 บิตหรือถ้าเขามีการติดตั้ง 64 บิต BG เขาก็สามารถเรียกใช้เครื่องมือฟังก์ชั่นของเขาได้ อย่างไรก็ตามเพื่อความบันเทิงความคิดเพียงไปจาก 32 ถึง 64 บิตไม่ได้เพิ่มประสิทธิภาพ เป็นสถานการณ์เมื่อ 64 บิตเป็น 'เร็วกว่า' บิต 32
KHibma

OP สามารถอธิบายได้ว่าสมมติฐานเหล่านี้ไม่ได้อยู่ในฐานหรือไม่ ลิงก์ที่ฉันให้ไว้สนับสนุนสมมติฐานเช่นประสิทธิภาพการทำงานที่ดีขึ้นเนื่องจากมีการเข้าถึงทรัพยากรระบบมากขึ้น ฯลฯ มีเหตุผลว่าทำไมระบบปฏิบัติการส่วนใหญ่ถึง 64 บิตในปัจจุบันและหนึ่งในนั้นคือประสิทธิภาพที่เพิ่มขึ้น ดังนั้นทุกสิ่งเท่าเทียมกันโดยเฉพาะอย่างยิ่งเมื่อเกิดการบีบอัดจำนวนมากกระบวนการ 64 บิตจะดำเนินการกระบวนการ 32 บิต
alexGIS
โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.