ArcView 3.x Avenue Bitmaps (Tabs?) Vs. Cursores do ArcView 10 Python


9

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!


11
Tem vontade de postar seu script? Não conheço nenhuma avenida / python usando benchmarks de GP.
Derek Swingley

As junções e consultas de tabela são muito mais rápidas no ArcView 3.2 antigo (avenue) do que qualquer ArcGIS 8.x a 10. * arcpy / python. basicamente devido à quantidade (muito mais) de código nos produtos ArcGIS.
Mapperz

2
@Mapperz Você está certo. No entanto, o processamento linha a linha no ArcView 3.x é terrivelmente lento devido à sobrecarga interpretativa de 10.000X para cada solicitação (eu testei isso). Quando alguém pode evitar loops - usando solicitações de "alto nível", como junções e consultas, como você sugere - o ArcView 3.x supera o ArcGIS, mas é plausível que em um teste frente a frente envolvendo loops explícitos sobre registros , qualquer um poderia vencer por uma margem relativamente pequena.
whuber

@Whuber @Derek Thar seja.
Nathanus

Respostas:


2

Eu não sou novo em programação, mas muito novo em Python, então leve isso com um pouco de sal ...

copyRecord = arcpy.InsertCursor(outData)

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.


Boa pegada. Vou tentar quando voltar ao escritório na próxima semana.
Nathanus

5

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 -

  • gp.CopyFeatures ("Caminho para featureclass \ FeatureclassName", "'in_memory' \ FeatureclassName") - para classes de recurso e;
  • gp.CopyRow ("Caminho para a classe da feature \ FeatureTableName", "'in_memory' \ FeatureTableName") - para tabelas em uma classe ou tabela de recursos 'in_memory'.

    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 é

  1. Shapefile (triste, mas verdadeiro)
  2. Geodatabase Pessoal
  3. Geodatabase de arquivo
  4. ArcSDE (mesmo com conexão direta, é mais lento)

Experimente estas sugestões, pois estou tentando compilar uma lista de coisas que funcionam aqui em gis.stackexchange.com, veja aqui


A opção de memória parece útil, mas o poder combinado da tabela em que estou consultando os relógios está em quase 1 GB. Acredito que tenho memória RAM suficiente para tornar isso possível, mas o tamanho da tabela arriscará um acidente violento? Além disso, o que é um contêiner python?
Nathanus

Estou surpreso que você coloque o gdb pessoal mais rápido que o arquivo gdb, pois isso é invertido diretamente da minha experiência. Seria interessante explorar isso em algum lugar / hora.
mate Wilkie

Pode ser o processo com o qual estou trabalhando atualmente, mas descobri que um arquivo gdb é mais lento, mas apenas. Eu diria que eles estão no mesmo nível, e eu escolheria um arquivo gdb em vez de pessoal, por causa das limitações do arquivo. Estou muito interessado em criar uma referência para isso. Você está interessado em me ajudar a definir alguns testes?
OptimizePrime

Tentei colocar o shapefile na memória, e isso pareceu fazer muito pouco para ajudar ... na verdade, o script parou de ser processado logo depois.
Nathanus

3

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.


O único problema aqui é que estou anexando dados não espaciais a dados espaciais. Ou seja, estou entrando em 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 de Shapescampos (e sua geometria)?
Nathanus 23/04

Não funcionaria com shapefiles, pois 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.
Matt Wilkie

1

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.


Obrigado pela informação. Algo pelo que esperar, se nada mais.
Nathanus
Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.