Нещодавно я написав швидку функцію Python для перетворення таблиці атрибутів у словник python, де ключ береться з визначеного користувачем унікального поля ідентифікатора (зазвичай це поле OID). Крім того, за замовчуванням всі поля копіюються у словник, але я включив параметр, що дозволяє вказати лише підмножину.
def make_attribute_dict(fc, key_field, attr_list=['*']):
dict = {}
fc_field_objects = arcpy.ListFields(fc)
fc_fields = [field.name for field in fc_field_objects if field.type != 'Geometry']
if attr_list == ['*']:
valid_fields = fc_fields
else:
valid_fields = [field for field in attr_list if field in fc_fields]
if key_field not in valid_fields:
cursor_fields = valid_fields + [key_field]
else:
cursor_fields = valid_fields
with arcpy.da.SearchCursor(fc, cursor_fields) as cursor:
for row in cursor:
key = row[cursor_fields.index(key_field)]
subdict = {}
for field in valid_fields:
subdict[field] = row[cursor_fields.index(field)]
dict[key] = subdict
del subdict
return dict
Це чудово підходить для відносно невеликих наборів даних, але я просто запустив його по таблиці, що містить близько 750 000 рядків і 15 полів - близько 100 Мб у базі даних геоданих. У цих випадках функція працює набагато повільніше, ніж я міг би очікувати: приблизно 5-6 хвилин (і це після копіювання таблиці в in_memory
робочу область). Мені дуже хотілося б знайти спосіб пришвидшити перетворення в словник, або отримати деяке розуміння щодо кращої стратегії маніпулювання великою кількістю даних атрибутів за допомогою Python.
UpdateCursors не спрацює добре для мене, оскільки коли змінюється один рядок, він може викликати зміни в кількох інших. Прокручування та обробка їх по одному занадто громіздко для того, що мені потрібно.
subdict = {}
наскрізь, del subdict
дає час обробки приблизно 10 секунд.
subdict[field] = row[cursor_fields.index(field)]
швидше викликати дзвінки, ніж телефонувати subdict[field] = row.getValue(field)
. В останньому сценарії ви б виконували один крок ... хоча різниця в продуктивності між індексуванням двох списків ( cursor_fields
і row
) та використанням одного ESRI-процесу може бути не набагато кращою, а може бути навіть гіршою!