Растрові зображення ArcView 3.x Avenue (Tabs?) Проти курсорів ArcView 10 Python


9

Примітка. Хоча на це питання є відповідь, будь-які подальші поради щодо оптимізації процесу курсору будуть дуже вдячні. Я буду стежити за будь-якими оновленнями.

Наразі мій бос (який працює в «Авеню») і я (працюю в «Python») намагаємось вирішити одну і ту ж проблему. Швидше, ми обидва це вирішили, але швидкість, з якою діють наші рішення, ... найменше, нерівномірна. Те, що його сценарій обробляє за 2 години, може зайняти до 6-х. Єдина реальна різниця в синтаксисі та реалізації в логіці походить від Bitx-карти 3.x та курсорів 10.x. Ми обидва:

1) Збережіть значення в Таблиці 1.
2) Використовуйте ці значення для запиту рядка в Таблиці 2.
3) Збережіть значення з Таблиці 2 для вставки в Таблицю 3 як новий рядок.

В обох сценаріях ці процеси завершуються в дві вкладені петлі. Перш ніж я почати розкопуватися у чудовий світ оптимізації коду, це очікуване явище при порівнянні продуктивності сценарію Avenue з Python? Це не перший раз, коли його сценарії значно перевершили міну за часом експлуатації, тому я хотів би знати, чи є щось, про що я маю знати, перш ніж розп'яти себе за жахливі сценарії.

Ось мій сценарій без сторонніх бітів:

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 : Враховуючи деякі коментарі до цих пір, мені цікаво, чи може бути кращий спосіб зробити це через приєднання, хоча я сумнівно враховую розмір таблиць brobdingnagian (слово дня!). Основою обробки є додавання інформації з однієї таблиці до будь-яких відповідних записів у другій таблиці та створення третьої таблиці, що містить лише важливі поля. Я хотів спробувати це за допомогою SDE, але це, здається, не є доступним варіантом. Думки? Прошу вибачення, якщо мої запитання завжди настільки задіяні , але я намагаюся дійти до глибини давнього роздратування.

Відповідь : Проста пропозиція Якуба скоротила час обробки з 30 секунд на 500 записів до 3 секунд на 500 записів. Повторне введення курсору вставки на кожну вставку значно сповільнило (очевидно). Хоча це може бути не найбільш оптимізацією, яку можна зробити для цього процесу, коли він протиставляється швидкості ArcView 3.x, для моїх цілей цього наразі достатньо. Подальші пропозиції дуже вітаються!


1
Відчуваєте, що публікуєте свій сценарій? Я не знаю жодного проспекту / пітона, що використовує орієнтири GP.
Дерек Свінглі

З'єднання та запити таблиць у старому ArcView 3.2 (avenue) набагато швидше, ніж будь-який ArcGIS 8.x до 10. * arcpy / python. в основному завдяки кількості (набагато більше) коду в продуктах ArcGIS.
Mapperz

2
@Mapperz Ви абсолютно праві. Однак обробка рядків за рядком в ArcView 3.x надзвичайно повільна через 10 000X інтерпретаційних накладних витрат на кожен запит (я це відмітив). Коли ви можете уникнути циклів - використовуючи запити "високого рівня", такі як приєднання та запити, як ви пропонуєте - ArcView 3.x відбиває штани від ArcGIS, але правдоподібно, що в тесті з головою до голови, що включає явні петлі над записами , або можна було виграти порівняно невеликим відривом.
whuber

@Whuber @Derek Thar це буде.
Нафан

Відповіді:


2

Я не новачок у програмуванні, але дуже новий у Python, тому прийміть це із зерном солі ...

copyRecord = arcpy.InsertCursor(outData)

Чи не слід встановлювати курсор вставки до циклу For Next? Мені здається, що якщо шлях до даних "out" зберігається у змінній "outData", тоді його не потрібно скидати щоразу, коли ви повторюєте. Я думаю, що це повинно значно прискорити справи.


Хороший улов. Я спробую це спробувати, коли наступного тижня я знову в офісі.
Нафан

5

Я припускаю, що ви використовуєте ArcPy або arcgcricripting circa 9.3. У будь-якому випадку методики тут прискорять вашу обробку .... можливо, краще, ніж ваші начальники.

Перше, що потрібно шукати, а вставки з будь-яким носієм, крім пам’яті, сповільнюватимуть ваші процеси. Avenue оптимізована для роботи швидко і використовує коду C \ C ++ (виправте мене, якщо я помиляюся), котра по суті швидша в IO, ніж більшість інших мов. Python також швидкий (так само швидко), за винятком випадків, коли є накладні витрати на підключення до бібліотек c для виконання операцій, таких як ArcPy або arcgisscripting.

Тому спробуйте спочатку:
1. Скопіюйте таблиці, які потрібно використовувати, в пам'ять за допомогою методів -

  • gp.CopyFeatures ("Шлях до функціонального класу \ FeatureclassName", "'in_memory' \ FeatureclassName") - для класів функцій та;
  • gp.CopyRow ("Шлях до особливостікласу \ FeatureTableName", "'in_memory' \ FeatureTableName") - для таблиць до класу чи таблиці "in_memory".

    Це дозволить використовувати пам'ять типу диска оперативної пам’яті та заощадить багато грошей на диску. Ви також можете створити клас пам'яті чи таблицю в пам'яті, замінивши параметр FeatureDataset на "in_memory".

Використовуйте контейнери з пітоном якомога більше. Це також збільшить швидкість.

Нарешті, порядок ефективності читання та запису інформації для форматів ESRI є

  1. Shapefile (сумно, але правда)
  2. Особиста база даних
  3. Файл Geodatabase
  4. ArcSDE (навіть при прямому підключенні це повільніше)

Дайте ці пропозиції спробувати, як я намагаюся скласти список речей , які працюють тут на gis.stackexchange.com подивитися тут


Варіант пам'яті здається корисним, але об'єднана може таблиця, яку я запитую на годинники, майже в 1 Гб. Я вважаю, що у мене є достатня кількість оперативної пам’яті, щоб зробити це можливим, але чи може сам розмір таблиці ризикувати жорстоким збоєм? Також, що таке контейнер пітона?
Нафан

Я здивований, що ви розміщуєте особистий gdb так само швидше, ніж файл gdb, як це прямо перевернуто з мого досвіду. Було б цікаво дослідити це десь / час.
matt wilkie

Можливо, це процес, над яким я зараз працюю, але я виявив, що файл gdb повільніше, але тільки просто. Я б сказав, що вони нарівні, і я вибрав би файл gdb над особистим gdb виключно через обмеження файлів. Мені дуже цікаво розробити орієнтир для цього. Ви хочете допомогти мені визначити деякі тести?
OptimizePrime

Я спробував помістити форм-файл у пам'ять, і це, здавалося, дуже мало допомогло ... дійсно, сценарій перестав обробляти незабаром після цього.
Нафан

3

Надіюсь, що це не те, що Avenue швидше, ніж Python, але ArcView3 швидше, ніж ArcGIS (у тому, що ви намагаєтеся зробити).

Оскільки за звучанням цього, по суті, це непросторове вправу, можливо, ви захочете експериментувати з прямим доступом до таблиць баз даних (наприклад, не використовуйте arcpy) із чимось на зразок dbfpy або odbc (я не намагався жодного з них). Особисто я знайшов командний рядок ogr2ogr в GDAL / OGR люкса бути порядки швидше , ніж аналогічні угоди в ArcGIS. Хоча я лише злегка занурився у здібності запитів OGR, і нічого не створив, використовуючи лише прив'язки пітона, тому не знаю, чи переносить ця швидкість.


Єдине питання, що я додаю непросторові дані до просторових даних. IE Я приймаю Shapeполе разом з кількома іншими і створюю новий запис, який буде містити геометрію та додаткові непросторові дані. Чи будуть dpfpy та odbc враховувати переміщення Shapesполів (та їх геометрію)?
Нафан

Він не працюватиме з shapefiles, оскільки Shapeне зберігається у .dbf. Теоретично він може працювати з персональною базою даних геоданих (.mdb), використовуючи odbc, але я здивований з таким підходом, тим більше, що вже існує перевірений маршрут з OGR, який уже знає і shapefile, і персональний gdb.
matt wilkie

1

Наразі це не особливо корисна відповідь, але зачекайте на ArcGIS 10.1. На цьогорічному саміті esri dev нам сказали, що підтримка курсора arcpy 10.1 була повністю переписана і значно швидша. Під час пленарного засідання було заявлено про покращення швидкості приблизно в 8 разів.


Спасибі за інформацію. Щось чекати, якщо нічого іншого.
Нафан
Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.