Em um blog anterior explorei o desempenho da captura de dados de alteração sem código versus troca de visualização da fonte em um teste de velocidade quando o objetivo é manter uma camada de feição hospedada - e declarei um empate! Agora tenho um novo participante do mundo das soluções codificadas - usando um notebook hospedado no ArcGIS Online para calcular e aplicar a transação delta para uma camada de feição hospedada onde os dados fonte mudam diariamente.
Meus dados de assunto são os mesmos do blog anterior, pontos de endereço de rua para a cidade de Los Angeles, atualizados diariamente.
Pontos de Endereço de Los Angeles
Há pouco mais de um milhão de pontos no conjunto de dados, com algumas centenas de alterações diárias: inserções, atualizações e exclusões. Tenho interesse em escrever sobre um caso de uso upsert (a combinação de inserção e atualização em uma única transação) há algum tempo, pois agora é suportado com a ferramenta geoprocessing Append no Pro e, portanto, no ArcPy no runtime avançado do notebook.
Estou me adiantando, então vamos primeiro contextualizar. Para considerar um fluxo ETL codificado você precisa estar confiante que seus dados estão bem gerenciados, com pouca ou nenhuma necessidade de fazer correções ou aplicar transformações durante o processo ETL - porque embora você possa visualizar dados em um notebook, é muito difícil fazer uma inspeção profunda dos dados e descobrir problemas. Se você não pode confiar nos seus dados, então deveria estar usando ArcGIS Data Pipelines ou ArcGIS Data Interoperability.
Neste caso, a cidade está entregando dados bem curados, então estou feliz em recomendar um processo codificado lift-and-shift.
Voltando às ferramentas usadas. No download do blog você encontrará uma caixa de ferramentas do ArcGIS Pro 3.6 com um modelo. O modelo cria uma classe de feição em file geodatabase chamada Addresses usando dados CSV que ele baixa do site Open Data da cidade. A classe de feição tem um esquema ajustado (veja o controle do mapa de campos na ferramenta Export Features) e também um campo chave primária House_Number_ID com restrição not-null e índice, requisitos para usar transações upsert.
Modelo Criando Dados de Endereços
Publiquei meu serviço de feição a partir do ArcGIS Pro após aplicar alguma simbologia e comportamento popup e certifiquei-me que House_Number_ID tem um índice único no serviço de feição. Agora para o notebook que mantém o serviço.
Vou deixar você percorrer o código do notebook (no download do blog), mas os passos do processamento são:
- Usar DuckDB para ler o arquivo CSV fonte do URL do site open data baixado
- Enquanto lê, impor um esquema e criar geometria em uma relação (tabela) na memória
- Usando ArcPy, criar uma classe de feição na memória a partir dos dados na relação DuckDB
- Merge os dados existentes e os novos endereços em outra classe de feição na memória
- Isto contém registros antigos e novos
- Usar Find Identical para encontrar sequências idênticas nos dados mesclados através da geometria e todos os campos
- Os dados estão em Web Mercator então uma tolerância de 1m permite diferenças na precisão das coordenadas
- Executar Frequency para ajudar a encontrar linhas que são únicas
- Feições editadas não têm correspondências idênticas
- Usar matemática de conjuntos para determinar os registros upsert e delete
- Executar as funções Append e Delete Rows com os registros corretos
Se você inspecionar as mensagens das células do notebook verá que todo o trabalho levou 9 minutos e meio (dados bastante grandes são lidos no notebook e geoprocessados) mas as gravações reais foram pequenas e levaram apenas alguns segundos - muito bom na minha opinião.
Após configurar o processamento agendado nas manhãs dos dias úteis agora tenho um produto informacional mantido continuamente!
Por favor, comente neste post com quaisquer observações ou perguntas.
