Catatan: Sementara pertanyaan ini memiliki jawaban, kiat-kiat lebih lanjut untuk mengoptimalkan proses kursor akan sangat dihargai. Saya akan memantau setiap pembaruan.
Saat ini, bos saya (yang bekerja di Avenue) dan saya (bekerja dengan Python) sama-sama berusaha menyelesaikan masalah yang sama. Sebaliknya, kami berdua telah memecahkannya, tetapi kecepatan di mana solusi kami beroperasi ... terputus-putus, untuk sedikitnya. Apa yang proses skripnya dalam 2 jam dapat menambang hingga 6. Satu-satunya perbedaan nyata dalam sintaksis dan implementasi dalam logika berasal dari Bitmap 3.x dan Cursors 10.x. Kami berdua:
1) Simpan nilai dari Tabel 1.
2) Gunakan nilai-nilai itu untuk kueri baris di Tabel 2.
3) Simpan nilai dari Tabel 2 untuk dimasukkan ke dalam Tabel 3 sebagai baris baru.
Dalam kedua skrip, proses ini diselesaikan dalam dua loop bersarang. Sebelum saya mulai menggali dunia yang luar biasa dari optimasi kode, apakah ini kejadian yang diharapkan ketika membandingkan kinerja skrip Avenue ke Python? Ini bukan pertama kalinya skripnya mengungguli skrip saya dalam hal waktu operasi, jadi saya ingin tahu apakah ada sesuatu yang harus saya ketahui sebelum saya menyalibkan diri saya untuk skrip yang mengerikan.
Inilah skrip saya tanpa bit:
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 : Mengingat beberapa komentar sejauh ini, saya bertanya-tanya apakah mungkin ada cara yang lebih baik untuk melakukan ini melalui bergabung, meskipun saya meragukan mengingat ukuran tabel brobdingnagian (kata hari ini!). Inti dari pemrosesan adalah menambahkan informasi dari satu tabel ke catatan yang cocok di tabel kedua dan membuat tabel ketiga hanya berisi bidang-bidang penting. Saya ingin mencoba ini menggunakan SDE, tetapi itu tampaknya bukan pilihan yang tersedia. Pikiran? Saya minta maaf jika pertanyaan saya selalu begitu terlibat , tetapi saya mencoba untuk sampai ke dasar gangguan lama.
Dijawab : Saran sederhana Jakub sendiri mengurangi waktu pemrosesan dari 30 detik per 500 catatan menjadi 3 detik per 500 catatan. Memulai kembali kursor sisipan pada setiap sisipan memperlambat banyak hal (jelas). Meskipun ini mungkin bukan yang paling optimal yang dapat dilakukan untuk proses ini ketika dihadapkan dengan kecepatan ArcView 3.x, itu sudah cukup untuk keperluan saya saat ini. Saran lebih lanjut sangat disambut!
sumber
Jawaban:
Saya bukan orang baru dalam pemrograman tetapi sangat baru di Python, jadi ambil ini dengan sebutir garam ...
Harus tidak memasukkan kursor diatur sebelum loop Untuk Berikutnya? Tampak bagi saya bahwa jika path ke data "out" disimpan dalam variabel "outData" maka itu tidak perlu diatur ulang setiap kali Anda mengulanginya. Saya akan berpikir bahwa ini akan mempercepat segalanya secara signifikan.
sumber
Saya akan menganggap Anda menggunakan ArcPy, atau arcgisscripting sekitar tahun 9.3. Bagaimanapun teknik di sini akan mempercepat pemrosesan Anda .... mungkin lebih baik daripada bos Anda.
Hal pertama adalah melakukan pencarian dan penyisipan dengan media apa pun selain memori akan memperlambat proses Anda. Avenue dioptimalkan untuk bekerja dengan cepat, dan menggunakan basis kode C \ C ++ (koreksi saya jika saya salah) yang secara inheren lebih cepat di IO daripada kebanyakan bahasa lainnya. Python juga cepat (sama cepatnya) kecuali di mana ada overhead dalam menghubungkan ke c library untuk melakukan operasi, seperti ArcPy atau arcgisscripting.
Jadi coba ini dulu:
1. Salin tabel yang perlu Anda gunakan ke dalam memori menggunakan metode -
Ini akan memungkinkan Anda untuk menggunakan memori seperti disk RAM, dan menghemat banyak hard disk. Anda juga dapat membuat kelas fitur atau tabel dalam memori dengan mengganti parameter FeatureDataset dengan 'in_memory'.
Gunakan wadah python sebanyak mungkin. Ini juga akan meningkatkan kecepatan.
Akhirnya urutan efisiensi dalam membaca dan menulis informasi untuk format ESRI adalah
Cobalah saran ini, karena saya mencoba menyusun daftar hal-hal yang berfungsi di gis.stackexchange.com, lihat di sini
sumber
Saya yakin bukan Avenue yang lebih cepat dari Python, tetapi ArcView3 lebih cepat dari ArcGIS (pada apa yang Anda coba lakukan).
Karena dari suaranya, ini pada dasarnya adalah latihan non-spasial Anda mungkin ingin bereksperimen dengan mengakses tabel database secara langsung (mis. Jangan menggunakan arcpy) dengan sesuatu seperti dbfpy atau odbc (belum pernah mencoba salah satu dari mereka sendiri). Secara pribadi saya telah menemukan baris perintah ogr2ogr dari gdal / ogr suite menjadi pesanan yang lebih besar lebih cepat daripada transaksi yang setara di arcgis. Saya hanya mencelupkan sedikit ke dalam kemampuan kueri OGR, dan saya belum membuat apa pun hanya menggunakan binding python jadi saya tidak tahu apakah kecepatan itu membawa.
sumber
Shapebidang bersama beberapa orang lain dan membuat catatan baru yang akan berisi geometri dan data non-spasial tambahan. Akankah dpfpy dan odbc memperhitungkanShapesbidang bergerak (dan geometrinya)?Shapetidak disimpan di .dbf. Secara teoritis itu bisa bekerja dengan personal geodatabase (.mdb) menggunakan odbc tapi saya curiga dengan pendekatan itu, terutama karena sudah ada rute yang terbukti dengan OGR, yang sudah tahu shapefile dan gdb pribadi.Ini bukan jawaban yang sangat membantu saat ini, tetapi tunggu ArcGIS 10.1. Pada KTT esri dev tahun ini kami diberi tahu bahwa dukungan kursor 10.1 arcpy telah sepenuhnya ditulis ulang dan secara signifikan lebih cepat. Selama pleno ada klaim peningkatan kecepatan sekitar 8x.
sumber