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

Примечание. Хотя на этот вопрос есть ответ, любые дополнительные советы по оптимизации работы курсора будут с благодарностью. Я буду следить за любыми обновлениями.

В настоящее время мой босс (который работает в Avenue) и я (работающий в Python) пытаются решить одну и ту же проблему. Скорее, мы оба решили это, но скорость, с которой работают наши решения, ... разобщена, если не сказать больше. То, что его сценарий обрабатывает за 2 часа, может занять у меня до 6. Единственное реальное различие в синтаксисе и реализации в логике заключается в растровых изображениях 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)

РЕДАКТИРОВАТЬ : Учитывая некоторые комментарии до сих пор, я задаюсь вопросом, может ли быть лучший способ сделать это с помощью объединений, хотя я сомневаюсь, учитывая brobdingnagian (слово дня!) Размер таблиц. Суть обработки заключается в добавлении информации из одной таблицы к любым соответствующим записям во второй таблице и создании третьей таблицы, содержащей только важные поля. Я хотел попробовать это с помощью SDE, но это, кажется, не доступный вариант. Мысли? Я прошу прощения, если мои вопросы всегда так вовлечены , но я пытаюсь докопаться до давнего раздражения.

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

Я не новичок в программировании, но очень плохо знаком с Python, поэтому возьмите это с крошкой соли ...

copyRecord = arcpy.InsertCursor(outData)

Разве курсор вставки не должен быть установлен до цикла For Next? Мне кажется, что если путь к данным "out" хранится в переменной "outData", то его не нужно сбрасывать при каждой итерации. Я думаю, что это должно значительно ускорить процесс.

Я предполагаю, что вы используете ArcPy или arcgisscripting около 9.3. В любом случае методы здесь ускорят вашу обработку .... может быть, лучше, чем ваши боссы.

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

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

• gp.CopyFeatures («Путь к featureclass \ FeatureclassName», «in_memory» \ FeatureclassName ») - для классов объектов и;
• gp.CopyRow («Путь к FeatureClass \ FeatureTableName», «in_memory» \ FeatureTableName ») - для таблиц в классе или таблице пространственных объектов« in_memory ».
  
  Это позволит вам использовать память, такую ​​как RAM-диск, и сэкономит вам много памяти. Вы также можете создать класс пространственных объектов или таблицу в памяти, заменив параметр FeatureDataset на in_memory.

Максимально используйте контейнеры Python. Это также увеличит скорость.

Наконец, порядок эффективности чтения и записи информации для форматов ESRI

1. Шейп-файл (грустно, но верно)
2. Персональная база геоданных
3. Файловая база геоданных
4. ArcSDE (даже при прямом подключении он медленнее)

Попробуйте эти предложения, так как я пытаюсь составить список вещей, которые работают здесь, на gis.stackexchange.com, смотрите здесь.

Спорим, дело не в том, что Avenue быстрее, чем Python, а в том, что ArcView3 быстрее, чем ArcGIS (что вы пытаетесь сделать).

Поскольку по сути это непространственное упражнение, вы можете поэкспериментировать с прямым доступом к таблицам базы данных (например, не использовать arcpy) с чем-то вроде dbfpy или odbc (не пробовал ни один из них сам). Лично я обнаружил, что командная строка ogr2ogr из набора gdal / ogr на несколько порядков быстрее, чем эквивалентные транзакции в arcgis. Я только слегка углубился в возможности запросов OGR, и я ничего не построил, используя только привязки Python, поэтому я не знаю, переносится ли эта скорость.

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