ArcView 3.x Avenue Bitmap (Tab?) So với ArcView 10 Con trỏ Python


9

Lưu ý: Mặc dù câu hỏi này có câu trả lời, nhưng bất kỳ mẹo nào khác để tối ưu hóa quy trình con trỏ sẽ được đánh giá rất cao. Tôi sẽ theo dõi cho bất kỳ cập nhật.

Hiện tại, ông chủ của tôi (người làm việc ở Avenue) và tôi (làm việc trong Python) đều đang cố gắng giải quyết cùng một vấn đề. Thay vào đó, cả hai chúng tôi đã giải quyết nó, nhưng tốc độ mà các giải pháp của chúng tôi hoạt động là ... rời rạc, để nói rằng ít nhất. Những gì kịch bản của anh ấy xử lý trong 2 giờ có thể khiến tôi mất tới 6. Sự khác biệt thực sự duy nhất về cú pháp và cách triển khai trong logic đến từ Bitmap 3.x và Con trỏ của 10.x. Cả hai chúng tôi:

1) Lưu trữ các giá trị từ Bảng 1.
2) Sử dụng các giá trị đó để truy vấn một hàng trong Bảng 2.
3) Lưu trữ các giá trị từ Bảng 2 để chèn vào Bảng 3 dưới dạng một hàng mới.

Trong cả hai tập lệnh, các quy trình này được hoàn thành trong hai vòng lặp lồng nhau. Trước khi tôi bắt đầu đào sâu vào thế giới tối ưu hóa mã tuyệt vời, đây có phải là sự xuất hiện dự kiến ​​khi so sánh hiệu suất tập lệnh Avenue với Python không? Đây không phải là lần đầu tiên các kịch bản của anh ấy vượt trội so với thời gian hoạt động của tôi, vì vậy tôi muốn biết liệu có điều gì tôi nên biết trước khi tôi đóng đinh chính mình vì kịch bản khủng khiếp.

Đây là kịch bản của tôi sans bit ngoại lai:

import arcpy
import time
import sys
import os

def recordfindcopy(inFile,query,outFile):
    findRecord = arcpy.SearchCursor(inFile,query)
    for record in findRecord:
        copyRecord = arcpy.InsertCursor(outData) # <--- D'oh! (See answer)
        field = record.FIELD
        copy = copyRecord.newRow()
        copy.FIELD = field
        copyRecord.insertRow(copy)

StreetsFileList = [r"Path", 
                r"Path"]

for sfile in StreetsFileList:
    inStreets = sfile
    inTable = r"Path"
    outData = r"Path"
    fsaEntry = arcpy.SearchCursor(inTable)
    for row in fsaEntry:
        id = row.ID
        sQuery = "ID = %s " % (str(id))
        recordfindcopy(inStreets,sQuery,outData)

EDIT : Cho một số ý kiến ​​cho đến nay, tôi tự hỏi liệu có thể có cách nào tốt hơn để thực hiện điều này thông qua các phép nối hay không, mặc dù tôi nghi ngờ về kích thước của brobdingnagian (từ trong ngày!) Của các bảng. Trọng tâm của quá trình xử lý là nối thông tin từ một bảng vào bất kỳ bản ghi khớp nào trong bảng thứ hai và tạo bảng thứ ba chỉ chứa các trường quan trọng. Tôi muốn thử điều này bằng SDE, nhưng dường như đó không phải là một tùy chọn có sẵn. Suy nghĩ? Tôi xin lỗi nếu các câu hỏi của tôi luôn có liên quan , nhưng tôi đang cố gắng tìm đến tận cùng của sự khó chịu từ lâu.

Đã trả lời : Chỉ riêng đề xuất đơn giản của Jakub đã giảm thời gian xử lý từ 30 giây trên 500 hồ sơ xuống còn 3 giây trên 500 hồ sơ. Khởi tạo lại con trỏ chèn trên mỗi lần chèn làm chậm đáng kể (rõ ràng). Mặc dù điều này có thể không phải là tối ưu hóa nhất mà người ta có thể làm cho quá trình này khi áp dụng tốc độ của ArcView 3.x, nhưng nó là đủ cho mục đích của tôi tại thời điểm này. Đề xuất thêm rất được chào đón!


1
Cảm thấy như đăng kịch bản của bạn? Tôi không biết bất kỳ con đường / con trăn nào sử dụng điểm chuẩn GP.
Derek Swingley

Bảng tham gia và truy vấn nhanh hơn nhiều trong ArcView 3.2 (đại lộ) cũ hơn bất kỳ ArcGIS 8.x nào đến 10. * arcpy / python. về cơ bản là do số lượng (nhiều hơn nữa) mã trong các sản phẩm ArcGIS.
Mapperz

2
@Mapperz Bạn hoàn toàn đúng. Tuy nhiên, việc xử lý từng hàng trong ArcView 3.x cực kỳ chậm do chi phí diễn giải 10.000X cho mỗi yêu cầu (tôi đã điểm chuẩn điều này). Khi một người có thể tránh các vòng lặp - sử dụng các yêu cầu "mức cao" như tham gia và truy vấn như bạn đề xuất - ArcView 3.x sẽ đánh bật quần ra khỏi ArcGIS, nhưng điều hợp lý là trong một thử nghiệm trực tiếp liên quan đến các vòng lặp rõ ràng trên các bản ghi , một trong hai có thể giành chiến thắng với một tỷ lệ tương đối nhẹ.
whuber

@Whuber @Derek Thar nó được.
Nathanus

Câu trả lời:


2

Tôi không mới lập trình nhưng rất mới với Python, vì vậy hãy dùng nó với một hạt muối ...

copyRecord = arcpy.InsertCursor(outData)

Không nên đặt con trỏ chèn trước vòng lặp For Next? Dường như với tôi rằng nếu đường dẫn đến dữ liệu "out" được lưu trữ trong biến "outData" thì nó không cần phải được thiết lập lại mỗi khi bạn lặp lại. Tôi nghĩ rằng điều này sẽ tăng tốc mọi thứ lên đáng kể.


Nắm bắt tốt. Tôi sẽ thử điều đó khi tôi trở lại văn phòng vào tuần tới.
Nathanus

5

Tôi sẽ cho rằng bạn đang sử dụng ArcPy hoặc arcgisscripting vào khoảng 9.3. Dù bằng cách nào thì các kỹ thuật ở đây sẽ tăng tốc độ xử lý của bạn .... có thể tốt hơn so với các ông chủ của bạn.

Điều đầu tiên là thực hiện tra cứu và chèn vào với bất kỳ phương tiện nào khác ngoài bộ nhớ sẽ làm chậm quá trình của bạn. Avenue được tối ưu hóa để hoạt động nhanh chóng và sử dụng cơ sở mã C \ C ++ (sửa tôi nếu tôi sai) vốn đã nhanh hơn tại IO so với hầu hết các ngôn ngữ khác. Python cũng nhanh chóng (cũng nhanh như vậy) ngoại trừ nơi có các chi phí trong việc móc vào các thư viện c để thực hiện các hoạt động, chẳng hạn như ArcPy hoặc arcgisscripting.

Vì vậy, hãy thử điều này trước:
1. Sao chép các bảng bạn cần sử dụng vào bộ nhớ bằng các phương thức -

  • gp.CopyFeatures ("Đường dẫn đến featureclass \ FeatureclassName", "'in_memory' \ FeatureclassName") - cho các lớp tính năng và;
  • gp.CopyRow ("Đường dẫn đến featureclass \ FeatureTableName", "'in_memory' \ FeatureTableName") - cho các bảng vào lớp hoặc bảng tính năng 'in_memory'.

    Điều này sẽ cho phép bạn sử dụng bộ nhớ như đĩa RAM và giúp bạn tiết kiệm rất nhiều công việc đập đĩa. Bạn cũng có thể tạo một lớp đối tượng hoặc bảng trong bộ nhớ bằng cách thay thế tham số FeatureDataset bằng 'in_memory'.

Sử dụng container python càng nhiều càng tốt. Điều này cũng sẽ tăng tốc độ.

Cuối cùng, thứ tự cho hiệu quả trong việc đọc và viết thông tin cho các định dạng ESRI là

  1. Shapefile (buồn nhưng đúng)
  2. Cơ sở dữ liệu địa lý cá nhân
  3. Cơ sở dữ liệu địa lý
  4. ArcSDE (ngay cả với kết nối trực tiếp, nó chậm hơn)

Hãy thử những gợi ý này, vì tôi đang cố gắng biên soạn một danh sách những thứ hoạt động ở đây trên gis.stackexchange.com xem tại đây


Tùy chọn bộ nhớ có vẻ hữu ích, nhưng khả năng kết hợp của bảng tôi đang truy vấn đối với đồng hồ ở mức gần 1 gb. Tôi tin rằng tôi có đủ RAM để thực hiện điều này có thể, nhưng liệu kích thước tuyệt đối của bảng có nguy cơ bị sập dữ dội không? Ngoài ra, một con trăn là gì?
Nathanus

Tôi ngạc nhiên khi bạn đặt gdb cá nhân nhanh hơn tệp gdb, vì điều đó trực tiếp đảo ngược từ kinh nghiệm của tôi. Sẽ rất thú vị khi khám phá điều đó ở đâu đó / thời gian.
matt wilkie

Nó có thể là quá trình tôi hiện đang làm việc, nhưng tôi thấy rằng một tệp gdb chậm hơn, nhưng chỉ. Tôi muốn nói rằng chúng ngang bằng nhau và tôi chọn một tệp gdb trên gdb cá nhân hoàn toàn vì giới hạn tệp. Tôi rất quan tâm đến việc đưa ra một tiêu chuẩn cho việc này. Bạn có quan tâm đến việc giúp tôi xác định một số bài kiểm tra?
OptimizePrime

Tôi đã thử đặt shapefile vào bộ nhớ và dường như điều đó rất ít để giúp ... thực sự, kịch bản đã ngừng xử lý ngay sau đó.
Nathanus

3

Tôi cá rằng đó không phải là Avenue nhanh hơn Python, mà ArcView3 nhanh hơn ArcGIS (ở những gì bạn đang cố gắng làm).

Vì từ âm thanh của nó, đây thực chất là một bài tập không phải không gian mà bạn có thể muốn thử nghiệm trực tiếp với các bảng cơ sở dữ liệu (ví dụ: không sử dụng arcpy) với một cái gì đó như dbfpy hoặc odbc (bản thân bạn chưa thử chúng). Cá nhân tôi đã tìm thấy dòng lệnh ogr2ogr của bộ gdal / ogrcác đơn đặt hàng có cường độ nhanh hơn các giao dịch tương đương trong arcgis. Mặc dù vậy, tôi chỉ nhúng nhẹ vào các khả năng truy vấn OGR và tôi chưa xây dựng bất cứ thứ gì chỉ sử dụng các ràng buộc trăn để tôi không biết liệu tốc độ đó có tiếp tục hay không.


Chà duy nhất ở đây là tôi đang nối thêm dữ liệu phi không gian vào dữ liệu không gian. IE Tôi đang tham gia Shapecùng với một vài người khác và tạo một bản ghi mới sẽ chứa hình học và dữ liệu phi không gian bổ sung. Dpfpy và odbc có tài khoản cho Shapescác trường di chuyển (và hình học của chúng) không?
Nathanus

Nó sẽ không hoạt động với shapefiles vì Shapekhông được lưu trữ trong .dbf. Về mặt lý thuyết, nó có thể hoạt động với cơ sở dữ liệu địa lý cá nhân (.mdb) bằng cách sử dụng odbc nhưng tôi không hài lòng với cách tiếp cận đó, đặc biệt là vì đã có một lộ trình đã được chứng minh với OGR, vốn đã biết cả shapefile và gdb cá nhân.
matt wilkie

1

Đây không phải là một câu trả lời đặc biệt hữu ích vào lúc này, nhưng hãy chờ ArcGIS 10.1. Tại hội nghị thượng đỉnh esri dev năm nay, chúng tôi đã nói rằng hỗ trợ con trỏ 10,1 đã được viết lại hoàn toàn và nhanh hơn đáng kể. Trong toàn thể đã có yêu cầu cải thiện tốc độ khoảng 8 lần.


Cảm ơn vì thông tin. Một cái gì đó để mong đợi, nếu không có gì khác.
Nathanus
Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.