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


9

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

В настоящее время мой босс (который работает в 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, в настоящее время этого достаточно для моих целей. Дальнейшие предложения очень приветствуются!


1
Хотите опубликовать свой сценарий? Я не знаю ни одного авеню / питона, использующего тесты GP.
Дерек Суингли

Соединения и запросы к таблицам в старом ArcView 3.2 (авеню) выполняются намного быстрее, чем в любых 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 или 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, смотрите здесь.


Опция памяти кажется полезной, но объединенная мощь таблицы, к которой я обращаюсь к часам, составляет почти 1 ГБ. Я полагаю, что у меня достаточно оперативной памяти, чтобы сделать это возможным, но рискует ли огромный размер стола серьезным сбоем? Кроме того, что такое контейнер Python?
Натан

Я удивлен, что вы размещаете личный GDB так же быстро, как файл GDB, так как это прямо перевернуто из моего опыта. Было бы интересно изучить это где-нибудь / время.
Мэтт Уилки

Это может быть процесс, с которым я сейчас работаю, но я обнаружил, что файл GDB медленнее, но только. Я бы сказал, что они на одном уровне, и я бы выбрал файл GDB вместо личного GDB исключительно из-за ограничений файла. Я очень заинтересован в разработке эталона для этого. Вы заинтересованы в том, чтобы помочь мне определить некоторые тесты?
OptimizePrime

Я попытался поместить шейп-файл в память, и это, казалось, очень мало помогло ... действительно, вскоре после этого сценарий перестал обрабатываться.
Натан

3

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

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


Единственный недостаток в том, что я добавляю непространственные данные к пространственным данным. IE Я беру Shapeполе вместе с несколькими другими и создаю новую запись, которая будет содержать геометрию и дополнительные непространственные данные. Будут ли dpfpy и odbc учитывать движущиеся Shapesполя (и их геометрию)?
Натан

Он не будет работать с шейп-файлами, поскольку Shapeон не хранится в .dbf. Теоретически он может работать с личной базой геоданных (.mdb) с использованием odbc, но я опасаюсь такого подхода, тем более что уже есть проверенный маршрут с OGR, который уже знает как шейп-файл, так и личный gdb.
Мэтт Уилки

1

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


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