ArcView 3.x Avenue Bitmap'leri (Sekmeler?) Ve ArcView 10 Python İmleçleri


9

Not: Bu sorunun bir cevabı olsa da, bir imleç sürecini optimize etmek için başka ipuçları da çok takdir edilecektir. Herhangi bir güncellemeyi izleyeceğim.

Şu anda patronum (Avenue'da çalışan) ve ben (Python'da çalışan) aynı sorunu çözmeye çalışıyorlar. Aksine, ikisini de çözdük, ama çözümlerimizin çalışma hızı ... en azından, ayrıktır. Senaryosunun 2 saat içinde işleyişi 6'ya kadar sürebilir. Sözdizimi ve mantıktaki uygulamadaki tek gerçek fark 3.x'in Bitmap'leri ve 10.x'in İmleçlerinden gelir. İkimiz de:

1) Tablo 1'deki değerleri saklayın.
2) Tablo 2'deki bir satırı sorgulamak için bu değerleri kullanın.
3) Tablo 3'teki değerleri yeni bir satır olarak Tablo 3'e eklemek için saklayın.

Her iki komut dosyasında da bu işlemler iki iç içe döngüde tamamlanır. Kod optimizasyonu harika dünyasına kazmaya başlamadan önce, bu Avenue komut dosyası performansını Python ile karşılaştırırken beklenen bir olay mı? Bu, senaryolarının çalışma süresi açısından ilk kez benimkinden daha iyi performans göstermediği için, korkunç senaryo için kendimi çarmıha germeden önce bilmem gereken bir şey olup olmadığını bilmek istiyorum.

İşte benim script sans bit bitleri:

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)

DÜZENLEME : Şimdiye kadar bazı yorumlar göz önüne alındığında, tablolar brobdingnagian (günün sözcüğü!) Boyutu göz önüne alındığında şüpheli olmasına rağmen, birleştirmeler yoluyla bunu yapmak için daha iyi bir yolu olup olmadığını merak ediyorum. İşlemenin kalbi, bir tablodan ikinci bir tablodaki eşleşen kayıtlara bilgi eklemek ve yalnızca önemli alanları içeren üçüncü bir tablo oluşturmaktır. SDE kullanarak denemek istedim, ancak bu kullanılabilir bir seçenek gibi görünmüyor. Düşünceler? Sorularım hep böyle eğer özür dilerim dahil , ama uzun süredir sıkıntı altına almaya çalışıyorum.

Cevap : Jakub'un basit önerisi tek başına işlem süresini 500 kayıt başına 30 saniyeden 500 kayıt başına 3 saniyeye düşürdü . Ekleme imlecini her ek üzerinde yeniden başlatmak işleri (yavaşça) önemli ölçüde yavaşlattı. Bu, ArcView 3.x'in hızına karşı koyulduğunda bu işlem için yapılabilecek en iyi optimizasyon olmasa da, şu anda benim amacım için yeterli. Diğer öneriler çok açıktır!


1
Senaryonuzu göndermek ister misiniz? GP kriterlerini kullanan herhangi bir cadde / python bilmiyorum.
Derek Swingley

Tablo Birleştirmeleri ve Sorguları eski ArcView 3.2'de (cadde) herhangi bir ArcGIS 8.x ila 10. * arcpy / python'dan çok daha hızlıdır. temel olarak ArcGIS ürünlerindeki kod miktarı (çok daha fazlası) nedeniyle.
Mapperz

2
@Mapperz Çok haklısın. Ancak, ArcView 3.x satır satır işleme her istek için 10,000X yorumlama yükü nedeniyle korkunç yavaştır (Ben bu karşılaştırma var). Döngülerden kaçınabildiğinizde - önerdiğiniz gibi birleştirmeler ve sorgular gibi "üst düzey" istekleri kullanarak - ArcView 3.x, pantolonları ArcGIS'ten yener, ancak kayıtlar üzerinde açık döngüler içeren kafa kafaya testte mantıklıdır , biri nispeten hafif bir farkla kazanabilir.
whuber

@Dhuber @Derek Thar olsun.
Nathanus

Yanıtlar:


2

Programlamaya yeni değilim ama Python için çok yeniyim, bu yüzden bunu bir tuz tanesi ile alın ...

copyRecord = arcpy.InsertCursor(outData)

Olmamalı ekleme imleci döngü için sonraki öncesinde ayarlanmalıdır? Bana "out" verilerinin yolu "outData" değişkeninde saklanırsa, o zaman her yinelemede sıfırlanması gerekmez. Bunun işleri önemli ölçüde hızlandırması gerektiğini düşünüyorum.


İyi yakalama. Gelecek hafta ofise döndüğümde bunu deneyeceğim.
Nathanus

5

ArcPy kullandığınızı ya da 9.3 civarında arcgisscripting kullandığınızı varsayacağım. Her iki şekilde de buradaki teknikler işleminizi hızlandıracaktır .... belki patronlarınızdan daha iyi.

İlk şey, arama yapmak ve bellek dışında herhangi bir ortamla eklemeler işlemlerinizi yavaşlatacaktır. Avenue hızlı bir şekilde çalışmak için optimize edilmiştir ve IO'da doğal olarak diğer dillerden daha hızlı olan bir C \ C ++ (yanlışsam beni düzelt) kod tabanı kullanır. Python da ArcPy veya arcgisscripting gibi işlemleri gerçekleştirmek için c kütüphanelerine takılan ek yüklerin olduğu durumlar dışında hızlıdır.

İlk önce şunu deneyin:
1. Kullanmanız gereken tabloları yöntemleri kullanarak belleğe kopyalayın -

  • gp.CopyFeatures ("Featureclass \ FeatureclassName" yolu, "'in_memory' \ FeatureclassName") - özellik sınıfları için ve;
  • gp.CopyRow ("Özellik sınıfının yolu \ FeatureTableName", "'in_memory' \ FeatureTableName") - 'in_memory' özellik sınıfına veya tablosuna tablolar için.

    Bu, RAM diski gibi bir bellek kullanmanıza ve size çok fazla disk harcanmasına neden olur. Ayrıca, FeatureDataset parametresini 'in_memory' ile değiştirerek bellekte bir özellik sınıfı veya tablosu oluşturabilirsiniz.

Mümkün olduğunca python kapları kullanın. Bu da hızı artıracaktır.

Son olarak ESRI formatları için bilgi okuma ve yazmada verimlilik sırası

  1. Shapefile (üzgün ama gerçek)
  2. Kişisel Coğrafi Veritabanı
  3. Dosya Coğrafi Veritabanı
  4. ArcSDE (doğrudan bağlantıda bile daha yavaş)

Burada gis.stackexchange.com üzerinde çalışma olduğu şeylerin bir listesini derlemek çalışıyorum olarak bu öneriler Bir deneyin burada bakın


Bellek seçeneği yararlı görünüyor, ama tablonun kombine olabilir neredeyse 1 gb saatlere karşı soruyorum. Bunu mümkün kılmak için yeterli RAM'ım olduğuna inanıyorum, ancak tablonun büyüklüğü büyük bir çarpışma riskiyle karşı karşıya mı kalacak? Ayrıca, bir python kabı nedir?
Nathanus

Kişisel gdb'yi dosya gdb'den daha hızlı yerleştirdiğinize şaşırdım, bu da doğrudan deneyimimden ters çevrildi. Bunu bir yerde / zamanda keşfetmek ilginç olurdu.
matt wilkie

Şu anda çalıştığım süreç olabilir, ancak gdb dosyasının daha yavaş olduğunu gördüm, ama sadece. Eşit olduklarını söyleyebilirim ve tamamen gdb dosyası nedeniyle kişisel gdb üzerinden gdb dosyası seçerdim. Bunun için bir ölçüt oluşturmakla çok ilgileniyorum. Bazı testleri tanımlamama yardım etmekle ilgileniyor musunuz?
OptimizePrime

Shapefile'ı belleğe koymayı denedim ve bu yardımcı olmak için çok az şey yapmış gibi görünüyordu ... gerçekten, komut dosyası kısa süre sonra işlenmeyi bıraktı.
Nathanus

3

Bahse girerim, Avenue Python'dan daha hızlı değildir, ancak ArcView3, ArcGIS'den daha hızlıdır (yapmaya çalıştığınız şeyde).

Sesinden bu temelde mekansal olmayan bir alıştırma olduğundan, veritabanı tablolarına doğrudan erişmeyi (örneğin arcpy kullanmayın) dbfpy veya odbc (bunlardan birini kendim denemedim ) ile denemek isteyebilirsiniz . Şahsen ben buldum komut ogr2ogr ait gdal / ogr paketi olarak daha hızlı büyüklük sıralaması ArcGIS eşdeğer işlemlere göre daha. Ben sadece hafifçe OGR sorgu yetenekleri içine daldırma, ve ben sadece python bağları kullanarak bir şey inşa etmedim, bu yüzden bu hız devam ederse bilmiyorum.


Buradaki tek ovma, mekansal verilere mekansal olmayan veriler ekliyorum. IE Birkaç Shapealan ile birlikte alan alıyorum ve geometri ve ek uzamsal olmayan verileri içeren yeni bir kayıt oluşturmak. Dpfpy ve odbc hareketli Shapesalanları (ve geometrilerini) açıklar mı?
Nathanus

.Dbf dosyasında Shapesaklanmadığı için şekil dosyaları ile çalışmaz . Teorik olarak odbc kullanarak kişisel bir coğrafi veritabanı (.mdb) ile çalışabilir, ancak özellikle yaklaşımı hem şekil dosyası hem de kişisel gdb'yi bilen OGR ile zaten kanıtlanmış bir rota olduğu için bu yaklaşımı temenni ederim.
matt wilkie

1

Bu şu anda özellikle yararlı bir cevap değil, ancak ArcGIS 10.1'i bekleyin. Bu yılki esri dev zirvesinde, arcpy 10.1 imleç desteğinin tamamen yeniden yazıldığı ve önemli ölçüde daha hızlı olduğu söylendi. Genel oturum sırasında hızın yaklaşık 8 kat arttığı iddiası vardı.


Bilgi için teşekkürler. Başka bir şey yoksa, dört gözle beklemek için bir şey.
Nathanus
Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.