Nota: Embora esta pergunta tenha uma resposta, qualquer outra dica para otimizar um processo de cursor seria muito apreciada. Eu estarei monitorando todas as atualizações.
Atualmente, meu chefe (que trabalha na Avenue) e eu (trabalhando em Python) estão tentando resolver o mesmo problema. Em vez disso, nós dois resolvemos isso, mas a velocidade com que nossas soluções operam são ... desconexas, para dizer o mínimo. O que o script dele processa em 2 horas pode levar o meu até 6. A única diferença real na sintaxe e na implementação da lógica vem dos Bitmaps do 3.x e dos Cursores do 10.x. Nós dois:
1) Armazene valores da Tabela 1.
2) Use esses valores para consultar uma linha na Tabela 2.
3) Armazene valores da Tabela 2 para inserção na Tabela 3 como uma nova linha.
Nos dois scripts, esses processos são concluídos em dois loops aninhados. Antes de começar a explorar o maravilhoso mundo da otimização de código, isso é uma ocorrência esperada ao comparar o desempenho do script Avenue com o Python? Essa não é a primeira vez que seus scripts superam os meus em termos de tempo de operação, então eu gostaria de saber se há algo que eu deva saber antes de me crucificar por scripts horríveis.
Aqui está o meu script sem bits estranhos:
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)
Edição : Dado alguns dos comentários até agora, pergunto-me se pode haver uma maneira melhor de fazer isso através de junções, embora eu seja duvidoso devido ao tamanho brobdingnagian (palavra do dia!) Das tabelas. O coração do processamento é anexar informações de uma tabela a qualquer registro correspondente em uma segunda tabela e criar uma terceira tabela contendo apenas os campos importantes. Eu queria tentar isso usando o SDE, mas isso parece não ser uma opção disponível. Pensamentos? Peço desculpas se minhas perguntas estão sempre tão envolvidas , mas estou tentando chegar ao fundo de um aborrecimento de longa data.
Respondido : A sugestão simples de Jakub diminuiu o tempo de processamento de 30 segundos por 500 registros para 3 segundos por 500 registros. Reiniciar o cursor de inserção em cada inserção diminuiu consideravelmente as coisas (obviamente). Embora essa possa não ser a maior otimização possível para esse processo quando comparada à velocidade do ArcView 3.x, é o suficiente para meus propósitos no momento. Mais sugestões são muito bem-vindas!
fonte
Respostas:
Eu não sou novo em programação, mas muito novo em Python, então leve isso com um pouco de sal ...
O cursor de inserção não deve ser definido antes do loop For Next? Parece-me que, se o caminho para os dados "fora" estiver armazenado na variável "outData", ele não precisará ser redefinido toda vez que você iterar. Eu acho que isso deve acelerar as coisas significativamente.
fonte
Suponho que você esteja usando o ArcPy ou o arcgisscripting da 9.3. De qualquer maneira, as técnicas aqui agilizarão seu processamento ... talvez seja melhor que seus chefes.
A primeira coisa a fazer é procurar e inserções com qualquer outro meio que não seja a memória vai retardar seus processos. O Avenue é otimizado para funcionar rapidamente e usa uma base de código C \ C ++ (me corrija se estiver errado), que é inerentemente mais rápida no IO do que na maioria dos outros idiomas. O Python também é rápido (da mesma maneira), exceto onde há sobrecargas nas bibliotecas c para executar operações, como ArcPy ou arcgisscripting.
Portanto, tente primeiro:
1. Copie as tabelas que você precisa usar na memória usando os métodos -
Isso permitirá que você use memória como o disco RAM e economize muito espaço em disco. Você também pode criar uma classe ou tabela de recurso na memória substituindo o parâmetro FeatureDataset por 'in_memory'.
Use contêineres python o máximo possível. Isso também aumentará a velocidade.
Finalmente, a ordem de eficiência na leitura e gravação de informações para os formatos ESRI é
Experimente estas sugestões, pois estou tentando compilar uma lista de coisas que funcionam aqui em gis.stackexchange.com, veja aqui
fonte
Aposto que não é que o Avenue seja mais rápido que o Python, mas o ArcView3 seja mais rápido que o ArcGIS (no que você está tentando fazer).
Como, pelo que parece, este é essencialmente um exercício não espacial, você pode querer acessar as tabelas do banco de dados diretamente (por exemplo, não use arcpy) com algo como dbfpy ou odbc (não tentei nenhuma delas). Pessoalmente, achei a linha de comando ogr2ogr do conjunto gdal / ogr como ordens de magnitude mais rápidas que transações equivalentes em arcgis. Porém, eu apenas mergulhei levemente nas habilidades de consulta do OGR e não construí nada usando apenas as ligações python, para não saber se essa velocidade é transferida.
fonte
Shapecampo com alguns outros e criando um novo registro que conterá a geometria e os dados não espaciais adicionais. O dpfpy e o odbc serão responsáveis pela movimentação deShapescampos (e sua geometria)?Shapenão é armazenado no .dbf. Teoricamente, ele poderia trabalhar com um geodatabase pessoal (.mdb) usando odbc, mas eu desconfio dessa abordagem, especialmente porque já existe uma rota comprovada com o OGR, que já conhece o shapefile e o gdb pessoal.Essa não é uma resposta especialmente útil no momento, mas aguarde o ArcGIS 10.1. Na cúpula do esri dev deste ano, fomos informados de que o suporte ao cursor do arco 10.1 foi completamente reescrito e é significativamente mais rápido. Durante o plenário, houve uma reivindicação de melhorias na velocidade de cerca de 8x.
fonte