ArcView 3.x Avenue Bitmaps (Tabs?) Vs. ArcView 10 Python Cursors


9

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!


1
Ingin memposting skrip Anda? Saya tidak tahu jalan / python menggunakan benchmark GP.
Derek Swingley

Gabungan dan Query Tabel jauh lebih cepat di ArcView 3.2 (avenue) lama daripada ArcGIS 8.x hingga 10. * arcpy / python. pada dasarnya karena jumlah (lebih banyak) kode dalam produk ArcGIS.
Mapperz

2
@Mapperz Anda benar. Namun, pemrosesan baris demi baris di ArcView 3.x sangat lambat karena overhead interpretif 10.000X untuk setiap permintaan (saya telah membandingkan ini). Ketika seseorang dapat menghindari loop - menggunakan permintaan "tingkat tinggi" seperti gabungan dan pertanyaan seperti yang Anda sarankan - ArcView 3.x akan mengalahkan ArcGIS, tetapi masuk akal bahwa dalam tes head-to-head yang melibatkan loop eksplisit atas catatan , salah satu bisa menang dengan selisih yang relatif kecil.
whuber

@Whuber @Derek Semoga begitu.
Nathanus

Jawaban:


2

Saya bukan orang baru dalam pemrograman tetapi sangat baru di Python, jadi ambil ini dengan sebutir garam ...

copyRecord = arcpy.InsertCursor(outData)

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.


Tangkapan yang bagus. Saya akan mencobanya ketika saya kembali ke kantor minggu depan.
Nathanus

5

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 -

  • gp.CopyFeatures ("Jalur ke Featureeclass \ eksklusifeclassName", "'in_memory' \ featureclassName") - untuk kelas fitur dan;
  • gp.CopyRow ("Jalur ke Featureeclass \ FeatureTableName", "'in_memory' \ FeatureTableName") - untuk tabel di kelas atau tabel fitur 'in_memory'.

    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

  1. Shapefile (sedih tapi benar)
  2. Database Geodat pribadi
  3. File Geodatabase
  4. ArcSDE (bahkan dengan koneksi langsung lebih lambat)

Cobalah saran ini, karena saya mencoba menyusun daftar hal-hal yang berfungsi di gis.stackexchange.com, lihat di sini


Opsi memori tampaknya berguna, tetapi kekuatan gabungan dari tabel yang saya tanyakan terhadap jam di hampir 1 gb. Saya percaya saya memiliki RAM yang cukup untuk memungkinkan hal ini, tetapi apakah ukuran meja yang tipis akan berisiko crash hebat? Juga, apa itu wadah python?
Nathanus

Saya terkejut Anda menempatkan gdb pribadi lebih cepat daripada file gdb, karena itu langsung terbalik dari pengalaman saya. Akan menarik untuk mengeksplorasi suatu tempat / waktu.
matt wilkie

Mungkin ini adalah proses yang saat ini saya kerjakan, tetapi saya mendapati bahwa file gdb lebih lambat, tetapi baru saja. Saya akan mengatakan mereka setara, dan saya akan memilih gdb file daripada gdb pribadi murni karena keterbatasan file. Saya sangat tertarik untuk merancang tolok ukur untuk ini. Apakah Anda tertarik membantu saya mendefinisikan beberapa tes?
OptimizePrime

Saya mencoba meletakkan shapefile di memori, dan itu tampaknya tidak banyak membantu ... memang, skrip berhenti diproses tak lama kemudian.
Nathanus

3

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.


Satu-satunya gosok di sini adalah bahwa saya menambahkan data non-spasial ke data spasial. Yaitu saya mengambil Shapebidang bersama beberapa orang lain dan membuat catatan baru yang akan berisi geometri dan data non-spasial tambahan. Akankah dpfpy dan odbc memperhitungkan Shapesbidang bergerak (dan geometrinya)?
Nathanus

Ini tidak akan berfungsi dengan shapefile karena 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.
matt wilkie

1

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.


Terima kasih untuk informasi. Sesuatu yang dinanti-nantikan, jika tidak ada yang lain.
Nathanus
Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.