ArcView 3.x एवेन्यू बिटमैप (टैब?) बनाम ArcView 10 पायथन कर्सर


9

नोट: जबकि इस प्रश्न का उत्तर है, कर्सर प्रक्रिया के अनुकूलन के लिए किसी भी अन्य सुझाव की बहुत सराहना की जाएगी। मैं किसी भी अपडेट के लिए निगरानी रखूंगा।

वर्तमान में, मेरे बॉस (एवेन्यू में काम करते हैं) और मैं (पायथन में काम कर रहे) दोनों एक ही समस्या को हल करने का प्रयास कर रहे हैं। बल्कि, हम दोनों ने इसे हल कर लिया है, लेकिन जिस गति से हमारे समाधान संचालित होते हैं ... कम से कम कहने के लिए, निराश हैं। 2 घंटे में उसकी स्क्रिप्ट प्रक्रियाएं मुझे 6 तक ले जा सकती हैं। वाक्यविन्यास और तर्क में कार्यान्वयन का एकमात्र वास्तविक अंतर 3.x के बिटमैप्स और 10.x के कर्सर से आता है। हम दोनों:

1) तालिका 1 से स्टोर मान।
2) तालिका 2 में एक पंक्ति को क्वेरी करने के लिए उन मानों का उपयोग करें।
3) एक नई पंक्ति के रूप में तालिका 3 में प्रविष्टि के लिए तालिका 2 से स्टोर मान।

दोनों लिपियों में, इन प्रक्रियाओं को दो नेस्टेड छोरों में पूरा किया जाता है। इससे पहले कि मैं कोड अनुकूलन की अद्भुत दुनिया में खुदाई करना शुरू करूं, क्या एवेन्यू स्क्रिप्ट के प्रदर्शन की तुलना पायथन से करना एक अपेक्षित घटना है? यह पहली बार नहीं है जब उनकी लिपियों ने ऑपरेशन के समय के संदर्भ में मेरा बहुत बेहतर प्रदर्शन किया है, इसलिए मैं यह जानना चाहूंगा कि क्या कोई ऐसी चीज है जिसके बारे में मुझे पता होना चाहिए इससे पहले कि मैं खुद को डरावनी स्क्रिप्टिंग के लिए क्रूस पर चढ़ाऊं।

यहाँ मेरी स्क्रिप्ट बाहरी बिट्स है:

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)

संपादित करें : अब तक की कुछ टिप्पणियों को देखते हुए, मुझे आश्चर्य है कि अगर जॉन्स के माध्यम से ऐसा करने का एक बेहतर तरीका हो सकता है, हालांकि मुझे टेबल के आकार के ब्रबडिंगनागियन (दिन का शब्द!) को देखते हुए संदिग्ध है। प्रसंस्करण का दिल एक टेबल से दूसरी मिलान में किसी भी मिलान रिकॉर्ड की जानकारी संलग्न करना और केवल महत्वपूर्ण क्षेत्रों से युक्त एक तीसरी तालिका बनाना है। मैं एसडीई का उपयोग करके यह कोशिश करना चाहता था, लेकिन यह एक उपलब्ध विकल्प नहीं प्रतीत होता है। विचार? मैं माफी मांगता हूं अगर मेरे सवाल हमेशा शामिल होते हैं , लेकिन मैं लंबे समय से चली आ रही झुंझलाहट की तह तक जाने की कोशिश कर रहा हूं।

उत्तर दिया गया : अकेले याकूब के सरल सुझाव ने प्रसंस्करण समय को 30 सेकंड प्रति 500 ​​रिकॉर्ड से घटाकर 3 सेकंड प्रति 500 ​​रिकॉर्ड कर दिया। हर डालने पर सम्मिलित कर्सर को फिर से शुरू करना, चीजों को धीमा कर देता है (स्पष्ट रूप से)। हालांकि यह इस प्रक्रिया के लिए सबसे अधिक अनुकूलन नहीं हो सकता है जब आर्कव्यू 3.x की गति के खिलाफ रखा जाता है, यह इस समय मेरे उद्देश्यों के लिए पर्याप्त है। आगे के सुझावों का बहुत स्वागत है!


1
अपनी स्क्रिप्ट पोस्ट करने का मन करता है? मुझे जीपी बेंचमार्क का उपयोग करके किसी भी एवेन्यू / अजगर का पता नहीं है।
डेरेक स्विंगले

टेबल जॉइन और क्वेरीज पुराने आर्कवे 3.2 (एवेन्यू) में किसी भी आर्कजीआईएस 8.x से 10. * आर्कपी / पायथन की तुलना में अधिक तेज हैं। मूल रूप से आर्कगिस उत्पादों में कोड की राशि (बहुत अधिक) के कारण।
Mapperz

2
@ मैपरज़ आप काफी सही हैं। हालाँकि, ArcView 3.x में पंक्ति-दर-पंक्ति प्रसंस्करण प्रत्येक अनुरोध के लिए 10,000X व्याख्यात्मक ओवरहेड के कारण छिपकर धीमा है (मैंने इसे बेंचमार्क किया है)। जब आप लूप से बच सकते हैं - जैसे कि आप सुझाव देते हैं कि "हाई लेवल" अनुरोधों का उपयोग करते हुए - ArcView 3.x आर्कगिस से पैंट को हरा देगा, लेकिन यह प्रशंसनीय है कि रिकॉर्ड से अधिक स्पष्ट लूप वाले सिर से लेकर सिर तक का परीक्षण या तो एक अपेक्षाकृत मामूली अंतर से जीत सकता है।
whuber

@Huber @ डेरेक थार हो।
नाथानुस

जवाबों:


2

मैं प्रोग्रामिंग के लिए नया नहीं हूं, लेकिन पायथन के लिए बहुत नया हूं इसलिए इसे नमक के दाने के साथ लें ...

copyRecord = arcpy.InsertCursor(outData)

क्या फ़ॉरवर्ड लूप से पहले इन्सर्ट कर्सर सेट नहीं होना चाहिए ? मुझे लगता है कि अगर "आउटडेटा" डेटा का पथ "आउटडेटा" चर में संग्रहीत किया जाता है, तो फिर हर बार पुनरावृति करने के लिए इसे रीसेट करने की आवश्यकता नहीं है। मुझे लगता है कि इससे चीजों में काफी तेजी आनी चाहिए।


अच्छी पकड़। मैं अगले सप्ताह कार्यालय में वापस आने पर कोशिश करूंगा।
नाथानुस

5

मुझे लगता है कि आप आर्कपी या आर्कगिसस्क्रिप्टिंग सर्का 9.3 का उपयोग कर रहे हैं। किसी भी तरह से यहां की तकनीकें आपके प्रसंस्करण को गति देंगी .... शायद आपके मालिकों से बेहतर हो।

पहली बात यह है कि लुक अप और मेमोरी के अलावा किसी भी माध्यम से इंसर्शन आपकी प्रक्रियाओं को धीमा करने वाला है। एवेन्यू को जल्दी से काम करने के लिए अनुकूलित किया गया है, और एक C \ C ++ (सही होने पर मुझे सही करें) कोड आधार का उपयोग करता है जो कि अधिकांश अन्य भाषाओं की तुलना में IO में स्वाभाविक रूप से तेज है। पायथन भी जल्दी है (सिर्फ जल्दी के रूप में) को छोड़कर जहां ऑपरेशन करने के लिए पुस्तकालयों में हुक करने में ओवरहेड्स होते हैं, जैसे कि आर्कपी या आर्कगिसस्क्रिप्टिंग।

तो पहले यह प्रयास करें:
1. उन तालिकाओं को कॉपी करें जिनकी आपको विधियों का उपयोग करके मेमोरी में उपयोग करने की आवश्यकता है -

  • gp.CopyFeatures ("Path toclclass \ FeatureclassName", "'in_memory' \ FeatureclassName") - फ़ीचर कक्षाओं के लिए और;
  • gp.CopyRow ("Pathclass \ FeatureTableName के लिए पथ", "'in_memory' \ FeatureTableName") - एक 'in_memory' सुविधा वर्ग या तालिका के लिए तालिका के लिए।

    यह आपको रैम डिस्क की तरह मेमोरी का उपयोग करने की अनुमति देगा, और आपको बहुत सारे डिस्क थ्रैशिंग को बचाएगा। आप 'In_memory' के साथ FeatureDataset पैरामीटर को प्रतिस्थापित करके मेमोरी में एक फीचर क्लास या टेबल भी बना सकते हैं।

जितना संभव हो, अजगर कंटेनरों का उपयोग करें। इससे स्पीड भी बढ़ेगी।

अंत में ESRI प्रारूपों के लिए जानकारी पढ़ने और लिखने में दक्षता के लिए आदेश है

  1. शेपफाइल (उदास लेकिन सच)
  2. व्यक्तिगत जिओदाटबेस
  3. फाइल जियोडेटाबेस
  4. आर्कएसडीई (सीधे कनेक्ट के साथ भी यह धीमा है)

इन सुझावों को आज़माएं, क्योंकि मैं उन चीजों की एक सूची संकलित करने की कोशिश कर रहा हूँ जो यहाँ gis.stackexchange.com पर काम करती हैं। यहाँ देखें


स्मृति विकल्प उपयोगी लगता है, लेकिन तालिका के संयुक्त मैं लगभग 1 gb पर घड़ियों के खिलाफ क्वेरी कर रहा हूँ। मेरा मानना ​​है कि यह संभव बनाने के लिए मेरे पास पर्याप्त रैम है, लेकिन क्या मेज का विशाल आकार एक हिंसक दुर्घटना का जोखिम उठाएगा? इसके अलावा, अजगर कंटेनर क्या है?
नाथानुस

मुझे आश्चर्य है कि आपने व्यक्तिगत gdb को फ़ाइल gdb से अधिक तेज़ स्थान दिया है, क्योंकि यह सीधे मेरे अनुभव से उल्टा है। यह पता लगाना दिलचस्प होगा कि कहीं न कहीं / समय।
मैट विल्की

यह वह प्रक्रिया हो सकती है, जिसके साथ मैं वर्तमान में काम कर रहा हूं, लेकिन मैंने पाया है कि एक फ़ाइल gdb धीमी है, लेकिन केवल। मैं कहूँगा कि वे बराबर हैं, और मैं फ़ाइल सीमाओं के कारण विशुद्ध रूप से व्यक्तिगत gdb पर एक फ़ाइल gdb चुनूँगा। मुझे इसके लिए एक बेंचमार्क तैयार करने में बहुत दिलचस्पी है। क्या आप मुझे कुछ परीक्षणों को परिभाषित करने में मदद करने में रुचि रखते हैं?
ऑप्टिमाइज़प्राइम

मैंने शेपफाइल को मेमोरी में डालने की कोशिश की, और यह मदद करने के लिए बहुत कम लग रहा था ... वास्तव में, इसके तुरंत बाद स्क्रिप्ट ने प्रसंस्करण बंद कर दिया।
नाथानुस

3

मुझे विश्वास है कि एवेन्यू पायथन की तुलना में तेज है, लेकिन यह कि आर्क व्यू 3 आर्कजीआईएस (आप क्या करने की कोशिश कर रहे हैं) की तुलना में तेज है।

चूँकि इसकी ध्वनि से यह अनिवार्य रूप से एक गैर-स्थानिक अभ्यास है जिसे आप डेटाबेस सारणी तक पहुँचने के साथ प्रयोग करना चाहते हैं (जैसे कि आर्कपी का उपयोग न करें) dbfpy या odbc जैसी किसी चीज़ के साथ (स्वयं में से किसी ने भी प्रयास नहीं किया है)। व्यक्तिगत रूप से मैंने गेल्ड / ओगर सुइट के कमांडलाइन ogr2ogr को आर्किसिस में समान लेनदेन की तुलना में तेजी से आदेश देने के लिए पाया है । मैंने केवल ओजीआर क्वेरी क्षमताओं में हल्के से डूबा हुआ है, और मैंने केवल अजगर बाइंडिंग का उपयोग करके कुछ भी नहीं बनाया है, इसलिए मुझे नहीं पता कि क्या गति बढ़ जाती है।


यहाँ केवल यह है कि मैं स्थानिक डेटा को गैर-स्थानिक डेटा जोड़ रहा हूँ। IE मैं Shapeकुछ अन्य लोगों के साथ क्षेत्र ले रहा हूं और एक नया रिकॉर्ड बना रहा हूं जिसमें ज्यामिति और अतिरिक्त गैर-स्थानिक डेटा शामिल होंगे। क्या चलती Shapesखेतों (और उनकी ज्यामिति) के लिए dpfpy और odbc खाता होगा ?
नाथानुस

यह। के रूप Shapeमें संग्रहीत नहीं है आकार के साथ काम नहीं करेगा । सैद्धांतिक रूप से यह ओडबेक का उपयोग करके एक व्यक्तिगत जियोडेटाबेस (.mdb) के साथ काम कर सकता है, लेकिन मैं उस दृष्टिकोण का लाभ उठा रहा हूं, खासकर क्योंकि ओजीआर के साथ पहले से ही एक सिद्ध मार्ग है, जो पहले से ही आकार और व्यक्तिगत gdb दोनों को जानता है।
मैट विल्की

1

यह इस समय विशेष रूप से उपयोगी उत्तर नहीं है, लेकिन आर्कजीआईएस 10.1 का इंतजार करें। इस वर्ष के एसरी देव शिखर सम्मेलन में हमें बताया गया कि आर्कपी 10.1 कर्सर समर्थन पूरी तरह से फिर से लिखा गया है और काफी तेज है। प्लेनरी के दौरान लगभग 8x की गति में सुधार का दावा किया गया था।


जानकारी के लिए धन्यवाद। आगे देखने के लिए कुछ, अगर कुछ नहीं।
नाथानुस
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.