Copiando atributos de uma camada de polígono para outra?

Eu tenho um problema que eu não consigo entender. Eu tenho duas camadas de polígono:

• Polígono A - é um subconjunto do polígono B com os mesmos campos e possui polígonos idênticos ao polígono B
• Polígono B - possui os dados de atributo que quero que estejam no Polígono A

Como isso pode ser feito? Eu tentei a ferramenta QGIS "Join Attributes by Location", mas como alguns polígonos estão em outros, ela tende a se vincular à primeira interseção encontrada (o polígono externo).

A @Dano levanta, com razão, alguns problemas que são melhor abordados em uma resposta completa.

Uma dificuldade , já observada por @Celenius, é que uma junção entre B e A (em qualquer direção) duplica todos os campos; pode ser oneroso corrigir isso. Sugeri nos comentários que a maneira fácil e óbvia (exportar para uma planilha) levanta questões de integridade dos dados. Outra dificuldade , já abordada pela proposta de Celenius, diz respeito à solução desse problema quando nenhuma combinação de atributos pode servir como chave para A e B, porque isso impede uma associação ao banco de dados. A junção espacial contorna esse problema.

Qual é, então, uma boa solução? Uma abordagem usa A para identificar os registros correspondentes de B contendo os dados desejados. Dependendo das suposições sobre as configurações dos polígonos - se elas se sobrepõem, se algumas podem conter outras, etc. - isso pode ser realizado de várias maneiras: usando uma camada para selecionar objetos na outra ou através de junções. O ponto aqui é que tudo o que queremos fazer nesta fase é selecionar o subconjunto de B correspondente a A.

Tendo alcançado essa seleção, exporte a seleção e deixe-a substituir A. Concluído .

Esta solução pressupõe que todos os campos em B se destinam a substituir seus pares em A. Caso contrário, é realmente necessário executar uma junção 1-1 de B (origem) a A (destino). A junção com base nos identificadores é a melhor opção, mas fazer uma junção na identidade de polígono (Celenius) funcionará bem se os IDs não estiverem disponíveis e não houver chance de as formas de polígono correspondentes em A e B poderem diferir, mesmo que ligeiramente . (Esse é um ponto sutil e a causa potencial de erros traiçoeiros, porque edições anteriores em B de polígonos que não correspondem a A ainda podem modificar invisivelmente os outros polígonos em B se o GIS estiver "estalando" ou "mantendo a topologia" ou fazer alterações globais automaticamente durante as edições locais.)

Nesse momento, existem duas cópias de cada campo: se [Foo] for um campo comum para A e B, a junção conterá A. [Foo] e B. [Foo]. Usando um cálculo de campo , copie B. [Foo] para A. [Foo]. Repita para todos os campos necessários. Depois disso, remova a associação.

Embora esse procedimento possa ser um pouco oneroso quando há muitos campos envolvidos, seus méritos incluem

• É simples e rápido de escrever.
• Os scripts deixam uma trilha de auditoria documentando o processamento que está sendo feito nos dados. Isso é crucial para proteger a integridade dos dados.
• Ele defende contra alguns tipos de erros por atacado, como reter o campo errado após a junção (mantendo assim os dados antigos em vez dos novos dados para esse campo) ou excluindo um campo crucial.
• Ele aproveita as defesas internas oferecidas pelo sistema de gerenciamento de banco de dados, como a imposição de tipos de dados e a imposição de regras de negócios, que funcionam para prevenir e identificar erros e manter a consistência entre todas as tabelas e camadas no banco de dados.

Alguns dos princípios orientadores envolvidos nesta sugestão são

1. Use seu sistema de gerenciamento de banco de dados para processar dados, em vez de usar software não projetado ou inadequado para esta tarefa.
2. Evite alterar as estruturas do banco de dados (como excluir ou adicionar campos) quando as operações não exigirem absolutamente.
3. Use os recursos de software para automação para simplificar o trabalho, documentá-lo e tornar as operações reproduzíveis.

Pode-se objetar que, em muitos casos, existem maneiras mais rápidas e fáceis de alcançar o mesmo resultado. Sim, pode haver, e eles podem ser eficazes e geralmente funcionam quando realizados com cuidado. Porém, soluções que arriscam os dados são difíceis de recomendar e defender como respostas de uso geral. Eles são melhor empregados em situações pontuais com pequenos conjuntos de dados em que a corrupção nos dados deve se tornar rapidamente óbvia e as consequências de tais erros são irrelevantes.

No Arcmap, você pode unir espacialmente o Polígono B ao Polígono A; isso relacionaria os atributos. Como os nomes dos campos são os mesmos, ele criará uma nova combinação do nome.

Exporte a tabela para o Shapefile "B" para o Excel e exclua as colunas que são redundantes e quaisquer colunas que contenham informações que você não precisa. Mantenha a coluna do identificador compartilhado e salve-a na pasta apropriada. Entre no ArcMap, adicione a tabela e, em seguida, clique com o botão direito no Shapefile "A" e faça a junção da tabela . O link deve levar a um vídeo sobre como fazer isso.

@ whuber - Toda a abordagem é sólida e garante a integridade dos dados. A única coisa que posso dizer para refutar essa resposta é que certas situações / projetos não nos dão tempo ou orçamento para ser tão metódico em nossa abordagem.

Um exemplo realista:

Uma empresa de mineração júnior está sentada em uma grande empresa com centenas de milhões de dólares em infusões de dinheiro, repousando em sua capacidade de "provar" o recurso. Uma análise em desktop de publicações e mapas / dados geológicos leva a um programa de perfuração muito direcionado e muito caro. Quando os ensaios retornam da primeira execução, esses valores são marcados em seus respectivos locais de pontos por meio de uma junção de tabela e retornados em um formato Excel, onde os dados são cuidadosamente preparados para importação no DataMine (para interpolação em 3D).

Na minha experiência , os geólogos do projeto exigiram que esses dados fossem preparados no Excel, que seguissem TODAS as regras / convenções de formatação à letra (sem espaços, caracteres especiais etc.) e que o arquivo de importação do DataMine fosse entregue no formato .csv (naquela época mesmo assim). Isso levaria a mais investimento em perfuração direcionada e revisaríamos o processo (em alguns casos) várias vezes. Tudo isso geralmente ocorreu em um cronograma excepcionalmente rígido e crítico.

Cada um de nós tem sua própria história e nossa própria gama de experiências que incorporamos à nossa abordagem de como fazemos as coisas. Dito isto, minha experiência viu o Excel como uma necessidade absoluta e uma ferramenta vital em meus fluxos de trabalho; é o que eu sei. Tomamos todas as precauções de controle de qualidade / controle de qualidade na preparação desses dados. Onde vocês se esquivavam do Excel, eu não tinha escolha a não ser usá-lo.

No final dos anos 90, recebemos uma atualização em larga escala de todos os nossos corpos d'água e cursos de água, cobrindo cerca de 55 mapas NTS e milhares de recursos não lembrados. Precisávamos manter os atributos de valor agregado de nossa antiga hidrologia (nomes de lagos, elevação da superfície etc.) e substituir a geometria. A geometria do antigo e do novo era próxima o suficiente para garantir que os centróides de cada polígono ainda seriam limitados pelos novos limites do polígono - este é um ponto importante, sem essa certeza básica, a abordagem abaixo não é uma boa ideia.

A solução nesse caso específico foi, em vez de trazer os atributos para a geometria, trazer a geometria para os atributos. Então, conceitualmente:

1. de * Layer_with_attributes *, exclua polígonos, mas mantenha os registros da tabela,
2. de * Layer_with_polys * copie e cole a geometria em * Layer_with_attributes *
3. mesclar e salvar.

Veja aqui uma descrição e uma receita mais ampliadas para arcinfo-worksation . Não tenho certeza de que seja possível, no Arcgis ou Qgis moderno, excluir uma geometria sem excluir simultaneamente o registro de atributo, mas ei, apenas por precaução, aqui está a idéia.

Não tenho certeza, mas talvez alguns DBMSs realizem operações de igualdade nos campos Shape em SQL (?). Parece-me que, se duas geometrias são idênticas, o =operador SQL deve retornar true ( WHERE A.Shape = B.Shape).

Se isso for verdade para o banco de dados que você está usando, você poderá fazer uma junção espacial usando a mesma sintaxe que faria para uma junção não espacial.

Parece que o método ST_Equals (um padrão OGC) poderia ser usado para isso.

Como sempre, o whuber está certo. Você precisa pensar bem sobre o seu processo. Especialmente se esses conjuntos de dados forem grandes e essa operação for realizada várias vezes ou se os dados forem de missão crítica.

Considere seus dados e responsabilidades:

O que é que você fez?

O que você está fazendo?

O que você pretende fazer?

E sempre pergunte: por que?

Agora, uma resposta fácil direcionada diretamente para a pergunta. Tendo em mente, sempre há pelo menos cinco maneiras de fazer as coisas, mas geralmente apenas uma melhor.

Supondo que o conjunto completo possua todos os atributos que você deseja que estejam no subconjunto e o subconjunto ainda não possui nada, exceto informações desatualizadas.

Supondo que a topologia do subconjunto corresponda ao conjunto completo (incluindo Origem / Projeção e Tolerância XY).

1) Use Feature to Point com a caixa de seleção "Inside" marcada e crie uma classe de recurso de pontos ou shapefile a partir do subconjunto.

2) Use um Selecionar por junção espacial para encontrar todos os polígonos no conjunto completo que correspondem ao subconjunto com base na classe de recurso Point ou no shapefile recém-criado.

3) Exporte a seleção do conjunto completo e esse pode ser seu novo subconjunto.

Certamente, se o Polígono A for um subconjunto do Polígono B, a abordagem mais fácil seria fazer um loop pelo Polígono A, use o ID que estaria no Polígono A (e B se A fosse um subconjunto ou B) para procurar os dados da linha em Polígono B e atualize a linha no Polígono A.