Копіювання атрибутів з одного шару багатокутника в інший?

У мене проблема, що я, здається, не можу опустити голову. У мене два полігонні шари:

• Полігон А - це підмножина багатокутника В з однаковими полями і має ідентичні багатокутники Полігону В
• Полігон В - має дані атрибутів, які я хочу знаходити в Полігоні А

Як це можна зробити? Я спробував інструмент QGIS "Приєднати атрибути за місцем розташування", але оскільки деякі полігони знаходяться в межах інших, він, як правило, посилається на перший перетин, який він знайде (зовнішній багатокутник).

@Dano справедливо порушує деякі питання, на які найкраще вирішити повну відповідь.

Одна з труднощів , яку вже зазначав @Celenius, полягає в тому, що з'єднання між B і A (в будь-якому напрямку) дублює всі поля; це може бути важко виправити. У коментарях я припустив, що очевидний простий спосіб (експорт до електронної таблиці) викликає питання цілісності даних. Ще одна складність , на яку вже звертається пропозиція Селеніуса, стосується вирішення цієї проблеми, коли жодна комбінація атрибутів не може слугувати ключовою як для А, так і для В, оскільки це виключає об'єднання бази даних. Просторове з'єднання обходить цю проблему.

Що ж тоді є хорошим рішенням? Один підхід використовує A для визначення відповідних записів B, що містять бажані дані. Залежно від припущень щодо конфігурацій багатокутників - перекриваються вони, чи можуть одні містити інші тощо - це може бути здійснено різними способами: використовуючи один шар для вибору об'єктів в інший або за допомогою з'єднання. Сенс у тому, що все, що ми хочемо зробити на цьому етапі, це вибрати підмножину B, відповідне А.

Досягнувши цього відбору, експортуйте вибір та дозвольте йому замінити А. Готово .

Це рішення передбачає, що всі поля в B призначені для заміни своїх аналогів в A. Якщо ні, то дійсно необхідно здійснити приєднання B 1 (джерело) 1-1 до пункту призначення. Об'єднання на основі ідентифікаторів є найкращим, але введення об'єднання в полігонічну ідентичність (Celenius) працює добре, якщо ідентифікатори недоступні і немає шансів, що відповідні форми багатокутника в A і B можуть, однак, незначно відрізнятися . (Це тонкий момент і потенційна причина підступних помилок, тому що попередні зміни в B на багатокутники, які не відповідають А, все ще могли б незрозуміло змінити інші багатокутники в B, якщо ГІС "оснащується" або "підтримує топологію" або іншим чином автоматично вносити глобальні зміни під час локальних редагувань.)

На цьому переході є дві копії кожного поля: якщо [Foo] є загальним полем для A і B, то приєднання містить A. [Foo] і B. [Foo]. За допомогою обчислення поля скопіюйте B. [Foo] в A. [Foo]. Повторіть для всіх необхідних полів. Після цього вийміть з'єднання.

Хоча ця процедура може бути трохи обтяжливою, коли задіяно багато полів, її достоїнства включають

• Сценарій простий та швидкий.
• Сценарій його залишає аудиторський слід, який документує обробку даних, що виконуються. Це має вирішальне значення для захисту цілісності даних.
• Він захищає від деяких видів оптових помилок, таких як збереження неправильного поля після з'єднання (тим самим зберігаючи старі дані замість нових даних для цього поля) або видаляючи важливе поле.
• Він використовує вбудовані засоби захисту, пропоновані системою управління базами даних, такі як примусові типи даних та виконання ділових правил, які функціонують для запобігання та виявлення помилок та підтримання узгодженості між усіма таблицями та шарами бази даних.

Деякі керівні принципи, пов'язані з цією пропозицією, є

1. Використовуйте систему управління базами даних для обробки даних, а не для використання програмного забезпечення, не призначеного або непридатного для цього завдання.
2. Уникайте змін структур баз даних (наприклад, видалення або додавання полів), коли операції цього абсолютно не вимагають.
3. Використовуйте можливості програмного забезпечення для автоматизації, щоб спростити роботу, документувати її та зробити операції відтворюваними.

Можна заперечити, що в багатьох випадках існують більш швидкі та прості способи досягти однакового результату. Так, вони можуть бути, і вони можуть бути ефективними, і зазвичай вони працюють при обережному виконанні. Але рішення, які ризикують отриманням даних, важко рекомендувати та захищати як відповіді загального призначення. Їх найкраще використовувати в разових ситуаціях з невеликими наборами даних, коли корупція в даних повинна швидко ставати очевидною, а наслідки будь-яких таких помилок несуттєві.

У Arcmap ви могли просторово приєднати багатокутник B до багатокутника A; це стосується атрибутів. Оскільки назви полів однакові, це створить нову комбінацію імені.

Експортуйте таблицю Shapefile "B" в Excel і видаліть надмірні стовпці та будь-які стовпці, що містять інформацію, яка вам не потрібна. Переконайтеся, що ви зберігаєте стовпець спільного ідентифікатора, а потім збережіть його у відповідній папці. Увійдіть до ArcMap, додайте таблицю, потім правою мишкою на Shapefile "A" та проведіть приєднання таблиці . Посилання має вести до відео про те, як це зробити.

@ whuber - Весь підхід є надійним і забезпечує цілісність даних. Єдине, що я можу сказати, щоб спростувати цю відповідь, - це те, що певні ситуації / проекти не дають нам часу чи бюджету бути таким методичним у нашому підході.

Справжній приклад:

Юніорська гірнича компанія сидить на великій ореоді з сотнями мільйонів доларів грошовими вливаннями, спираючись на їх здатність "перевірити" ресурс. Огляд публікацій та географічних карт / даних на робочому столі призводить до дуже цілеспрямованої та дуже дорогої програми буріння. Коли аналізи повертаються з першого запуску, ці значення позначаються у відповідних точкових місцях за допомогою таблиці приєднання та відкачуються назад у форматі Excel, де дані кропітко готуються до імпорту в DataMine (для інтерполяції 3D orebody).

На моєму досвіді , геологи проекту вимагали, щоб ці дані були складені в Excel, щоб вони дотримувалися ВСІХ правил форматування / конвенції до листа (немає пробілів, жодних спеціальних символів тощо) та щоб файл імпорту DataMine був доставлений у форматі .csv (тоді все одно). Це призведе до збільшення інвестицій у цілеспрямоване буріння, і ми переглянемо процес (в деяких випадках) багато разів. Все це, як правило, відбувалося на надзвичайно жорсткій та критичній шкалі часу.

У кожного з нас є своя історія та власний масив досвіду, який ми включили у свій підхід до того, як ми робимо справи. Сказавши це, мій досвід розглядав Excel як абсолютну необхідність і життєво важливий інструмент у моїх робочих процесах; це те, що я знаю. Ми дотримувались всіх заходів щодо забезпечення якості та контролю якості при підготовці цих даних. Там, де ви, хлопці, ухиляєтесь від Excel, я не мав іншого вибору, як використовувати його.

Наприкінці 1990-х ми отримали масштабне оновлення всіх наших водойм та водотоків, що охоплювало близько 55 аркушів карт НТС та безліч тисяч функцій. Нам потрібно було зберегти атрибути доданої вартості нашої старої гідрології (назви озера, підняття поверхні тощо) та замінити геометрію. Геометрія старого і нового була досить близькою, щоб ми могли гарантувати, що центроїди кожного багатокутника все ще будуть обмежені новими межами полігону - це важливий момент, без цієї базової визначеності підхід нижче не є гарною ідеєю.

Рішенням у цьому конкретному випадку було замість приведення атрибутів до геометрії, доведення геометрії до атрибутів. Отже, концептуально:

1. з * Layer_with_attributes *, видаліть багатокутники, але зберігайте записи в таблиці,
2. з * Layer_with_polys * скопіюйте та вставте геометрію в * Layer_with_attributes *
3. злиття і збереження.

Дивіться тут для більш розширеного опису та рецепту арцинфоробота . Я не впевнений, що навіть в сучасних Arcgis або Qgis можливо видалити геометрію, не видаляючи одночасно запис атрибутів, але ей, на всякий випадок, ось ідея.

Я не впевнений, але, можливо, деякі СУБД виконують операції рівності на полях Shape в SQL (?). Мені здається, що якщо дві геометрії однакові, =оператор SQL повинен повернути true ( WHERE A.Shape = B.Shape).

Якщо це справедливо для бази даних, яку ви використовуєте, ви повинні мати можливість зробити просторове з'єднання, використовуючи той самий синтаксис, який ви використовували б для непросторового з'єднання.

Здається, для цього може використовуватися метод ST_Equals (стандарт OGC).

Як звичайно каламут правильний. Вам потрібно добре подумати над своїм процесом. Особливо, якщо це великі набори даних, і ця операція буде проводитися багато разів або дані є критично важливими.

Розглянемо свої дані та обов'язки:

Що ти зробив?

Що ви робите?

Що ти маєш намір робити?

І завжди запитуйте: чому?

Тепер для однієї простої відповіді, спрямованої безпосередньо на поставлене запитання. Маючи на увазі, завжди є щонайменше 5 способів робити речі, але зазвичай лише один найкращий спосіб.

Якщо припустити, що в повному наборі є кожен атрибут, який ви хочете знаходити в підмножині, і підмножина нічого не має в повному наборі, крім застарілої інформації.

Здогадка, що топологія підмножини відповідає повному набору (включаючи походження / проекцію та толерантність XY).

1) Використовуйте функцію для вказівки, щоб встановити прапорець "Всередині" і створити з підмножини клас класу характеристик або форм-файл.

2) Використовуйте Select by Spatial Join, щоб знайти всі полігони в повному наборі, які відповідають підмножині на основі новоствореного класу Point Point або shapefile.

3) Експортуйте Вибір з повного набору, і це може бути ваш новий підмножина.

Безумовно, якщо полігон A є підмножиною многокутника B, найпростішим підходом було б провести цикл через полігон A, використовуйте ідентифікатор, який був би в полігоні A (а B, якщо A було підмножиною або B) для пошуку даних рядків у Полігон В, а потім оновіть рядок у полігоні А.