@Dano plantea con razón algunos problemas que se abordan mejor en una respuesta completa.
Una dificultad , ya señalada por @Celenius, es que una unión entre B y A (en cualquier dirección) duplica todos los campos; Puede ser oneroso corregir esto. He sugerido en los comentarios que la forma fácil y obvia (exportar a una hoja de cálculo) plantea preguntas sobre la integridad de los datos. Otra dificultad , ya abordada por la propuesta de Celenius, se refiere a resolver este problema cuando ninguna combinación de atributos puede servir como clave para A y B, porque eso impide una unión a la base de datos. La unión espacial soluciona ese problema.
¿Cuál es, entonces, una buena solución? Un enfoque utiliza A para identificar los registros correspondientes de B que contienen los datos deseados. Dependiendo de los supuestos sobre las configuraciones de los polígonos, si se superponen, si algunos pueden contener otros, etc., esto puede llevarse a cabo de varias maneras: usando una capa para seleccionar objetos en la otra, o mediante uniones. El punto aquí es que todo lo que queremos hacer en esta etapa es seleccionar el subconjunto de B correspondiente a A.
Habiendo logrado esa selección, exporte la selección y deje que reemplace A. Hecho .
Esta solución asume que todos los campos en B están destinados a reemplazar sus contrapartes en A. Si no, entonces es realmente necesario realizar una unión 1-1 de B (fuente) a A (destino). La unión basada en identificadores es la mejor, pero hacer una unión en la identidad del polígono (Celenius) funciona bien si los identificadores no están disponibles y no hay posibilidad de que las formas de los polígonos correspondientes en A y B difieran, aunque sea ligeramente . (Este es un punto sutil, y la causa potencial de errores insidiosos, porque las ediciones previas en B a polígonos que no corresponden a A aún podrían modificar invisiblemente los otros polígonos en B si el SIG está "encajándose" o "manteniendo la topología" o realizar cambios globales de forma automática durante las ediciones locales).
En esta coyuntura, hay dos copias de cada campo: si [Foo] es un campo común para A y B, entonces la unión contiene A. [Foo] y B. [Foo]. Usando un cálculo de campo , copie B. [Foo] en A. [Foo]. Repita para todos los campos necesarios. Una vez hecho esto, elimine la unión.
Aunque este procedimiento puede ser un poco oneroso cuando hay muchos campos involucrados, sus méritos incluyen
- Es sencillo y rápido de escribir.
- La secuencia de comandos deja una pista de auditoría que documenta el procesamiento que se realiza en los datos. Esto es crucial para proteger la integridad de los datos.
- Se defiende contra algunos tipos de errores mayoristas, como retener el campo incorrecto después de la unión (manteniendo así los datos antiguos en lugar de los nuevos para ese campo) o eliminar un campo crucial.
- Aprovecha las defensas integradas que ofrece el sistema de gestión de la base de datos, como la aplicación de los tipos de datos y la aplicación de las reglas comerciales, que funcionan para prevenir e identificar errores y para mantener la coherencia entre todas las tablas y capas de la base de datos.
Algunos de los principios rectores involucrados en esta sugerencia son
- Use su sistema de administración de base de datos para procesar datos en lugar de usar software no diseñado o inadecuado para esta tarea.
- Evite cambiar las estructuras de la base de datos (como eliminar o agregar campos) cuando las operaciones no lo requieren absolutamente.
- Use las capacidades de automatización del software para simplificar el trabajo, documentarlo y hacer que las operaciones sean reproducibles.
Uno podría objetar que en muchos casos hay formas más rápidas y fáciles de alcanzar el mismo resultado. Sí, puede haber, y pueden ser efectivos y generalmente funcionan cuando se realizan con cuidado. Pero las soluciones que ponen en riesgo los datos son difíciles de recomendar y defender como respuestas de uso general. Se emplean mejor en situaciones puntuales con pequeños conjuntos de datos donde la corrupción en los datos debería volverse rápidamente evidente y las consecuencias de tales errores son irrelevantes.