Обчислення площі QGIS відрізняється, коли на ходу ввімкнено перетворення CRS

Коли я відкриваю QGIS, додаю шар та обчислюю площі формфайлу за допомогою калькулятора поля, я отримую іншу площу, ніж коли я відкриваю QGIS і поставте галочку "Увімкнути під час трансформації CRS" та обчислити площу. Це незважаючи на те, що проект та шар мають однакову систему координат (той самий номер EPSG). Що я роблю неправильно?

У мене є файл форми з обчисленнями площі, зроблений за допомогою ArcGIS (не будь мені, дані мені передали, і я не маю жодного поняття, для якої CRS область була розрахована за допомогою ArcGIS). Шаром форми CRS є EPSG: 21781 (Швейцарія). У QGIS, якщо я не зміню налаштування OTF і залиште проект CRS як EPSG: 4326 (WGS84), я отримаю таке ж значення, як значення області ArcGIS. Однак якщо я зміню OTF перед тим, як додати шар до EPSG: 21781, я отримаю різні значення площі. Як я розумію, це говорить про те, що площа ArcGIS була розрахована за допомогою CRS EPSG: 4326.

Перший робочий процес:

відкритий QGIS
проект CRS: EPSG 4326
додати шар
Проект CRS адаптується автоматично і є EPSG 21781 зараз
обчислити $ область за допомогою калькулятора поля

Другий робочий процес:

відкритий QGIS
проект CRS: EPSG 4326
Увімкніть OTF, встановіть проект CRS на EPSG 21781
додати шар
обчислити $ область за допомогою калькулятора поля

Крок 5 першого та другого робочого процесу НЕ створюють однакову площу.

qgis coordinate-system area

— калакару
джерело

чи можете ви навести приклад робочого процесу та використовуваних інструментів; Я спробував це з увімкненим і відключеним на ходу в WGS84, і це дало ту саму область. Це використовується $areaу поданому калькуляторі. Коротше кажучи, під час польоту впливає спосіб відображення геометрії без зміни даних фактично. Таким чином, більш ймовірно, що помилка пов'язана з робочим процесом.

— dof1985

$ area обчислює площу на основі шарів або системи координат проектів?

— калакару

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

— dof1985

Це може бути корінь моєї проблеми. У мене є файл форми з обчисленнями площі, зроблений за допомогою ArcGis (не будь мені, дані мені передали, і я не маю жодного поняття, для якого CRS область була розрахована за допомогою ArcGIS). Шар форми CRS є EPSG: 21781 (Швейцарія). Якщо я не зміню налаштування OTF і залиште проект CRS як EPSG: 4326 (WGS84), я отримаю те саме значення, що і значення ArcGis Area. Однак якщо я зміню OTF перед тим, як додати шар до EPSG: 21781, я отримаю різні значення площі. Як я розумію, це говорить про те, що площа ArcGIS була розрахована за допомогою CRS EPSG: 4326.

— kalakaru

наскільки я знаю, Аркгіз може обчислити геометрію багатьма способами. Використовуючи вираз python калькулятора, !shape.area!слід надати область відповідно до шару crs; ніж обчислення геометрії може працювати інакше. Тому важко сказати, що саме було зроблено в аркгізі, але якщо ви отримаєте такий самий результат, наприклад, градуси, а не метри, це означає, що обчислення площі справді базувалося на ESPG: 4326.

— dof1985

Відповіді:

EDIT - Відмова: Я хотів би направити читачів на обговорення з ChrisW нижче. Можливо, отримання області на базі OTF CRS все-таки не є помилкою; тобто, щонайменше, в аркгізі він також використовується для того, щоб дозволити геообробці двох шарів з різних CRS.

Сформулювати вищезазначене питання. Як показав AndreJ, як це було запропоновано, це помилка в поточній версії qgis. Однак слід зазначити, що проблема не в тому, що це неправильна область, а що на ходу перетворення так чи інакше впливає на обчислення площі.

Мета трансформації / проекції на льоту - вирівняти дані з різних джерел та з різними CRS. Це переважно для цілей відображення. EG arcmap автоматично виконує на ходу проекцію в будь-якому випадку, рівень CRS не відповідає кадру даних CRS.

Arcmap також надає можливість редагувати дані під час прогнозування на ходу, але також зазначає, що: ( джерело )

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

Конкретні операції редагування, які можуть спричинити проблеми, включають зміни форми функцій, прив’язку до краю або межі функцій або розширення та обрізання функцій. Ці проблеми, швидше за все, виникають, коли функції, які ви редагуєте, наближаються до краю або за межами області використання системи координат.

Тобто, трансформація на ходу є менш гострою, ніж просто проектувати дані в іншу КРС (що також вводить власні проблеми).

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

Щоб бути більш практичним, якщо ваша мета - обчислити площу, не використовуйте на ходу. Якщо у вас неправильна CRS, запроектуйте свої дані.

— dof1985
джерело

Я не впевнений у QGIS, але, на відміну від того, що ви згадуєте тут, ArcGIS насправді може виконати обчислення геометрії, використовуючи проекцію OTF або зовсім іншу проекцію взагалі залежно від методу (тобто, клацніть правою кнопкою миші стовпчик атрибутів та виберіть «Розрахувати геометрію проти» -код / код калькулятора поля виклику shape.area). Іноді надаються варіанти використання CRS 1) даних / рівня, 2) поточного фрейму даних, 3) зазначеного CRS, не пов'язаного з 1 або 2. Зазвичай (знову ж таки, ArcGIS), якщо вибір не представлений, він буде зроблений у поточна CRS кадрів даних, незалежно від того, що це за дані (отже, OTF).

— Кріс Ш

Я також повинен зазначити, що OTF не тільки для цілей відображення - не потрібно переробляти набір даних, щоб запустити інструмент геообробки, який також використовує набір даних з іншою CRS; OTF це вдається. Є деякі винятки, коли обидва набору даних дійсно повинні бути в одних і тих же СВК.

— Кріс Ш

@ChrisW, якщо я правильно розумію; деякі інструменти для геообробки приймають ORSF CRS, оскільки це був CRS шару. Таким чином, отримання області на базі OTF CRS не обов'язково є помилкою. Це правильно? Щодо Arcgis, припустимо WGS84 як OTF; як щодо дзвінка на зразок:!shape.area@meters!

— dof1985

Це правильно. Ваш кадр даних та перший шар може бути WGS84, а ви можете додати другий шар, який є NAD83. Другий шар проектується OTF, і ви можете запустити на ньому будь-який звичайний інструмент на зразок Intersect або Union, і операція відбувається в WGS84. Отримати площу точно не помилка. У мене є клієнт, який хоче даних у NAD83, але для введення інформації потрібні одиниці в десятках, і я працюю в запланованому CRS. Зазвичай я просто змінюю проекцію фрейму даних, область обчислення, а потім перемикаю його назад. Не впевнений, яким чином оброблятиметься цей виклик, оскільки я думаю, що перетворення одиниць є окремим від обчислення.

— Кріс Ш

Я можу підтвердити, що це, здається, помилка.

Створіть файл csv із таким вмістом:

E N
600000 200000
700000 200000
700000 300000
600000 300000

Імпортуйте його у форматі з розмежуваним текстом за допомогою EPSG: 21781, увімкніть оснащення та намалюйте файл форми з багатокутниками на чотирьох точках.

Без OTF результат $area/1000000.010000 м² (що, очевидно, правильно).

Включення OTF на , і вибрати той же EPSG: 21781, Ви отримуєте 9988.2338 м².

Вибір іншої CRS, наприклад, EPSG: 4326, забезпечує 9990,5339 м², тому що обчислення проводиться на іншому еліпсоїді (WGS84 замість bessel).

Vector --> Geometry Tools --> Export/Add Geometry Columns здається, подає правильні значення.

У помилки вже є кілька квитків: https://issues.qgis.org/isissue/10966 та https://isissue.qgis.org/isissue/12473

— AndreJ
джерело