Расчет площади 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

— kalakaru
источник

Можете ли вы привести пример рабочего процесса и инструментов, которые вы использовали; Я попробовал это с включенным и выключенным на лету в WGS84, и это дало ту же самую область. Это используется $areaв поле калькулятора. Короче говоря, на лету влияет, как отображается геометрия, без фактического изменения данных. Таким образом, более вероятно, что ошибка связана с рабочим процессом.

— dof1985

$ area вычисляет площадь на основе слоев или системы координат проектов?

— Калакару

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

— dof1985

Это может быть корнем моей проблемы. У меня есть шейп-файл с вычислениями площади, выполненный с помощью ArcGis (не я, данные были переданы мне, и я не знаю, для какого CRS площадь была рассчитана с помощью ArcGIS). Слой шейп-файла CRS - EPSG: 21781 (Швейцария). Если я не изменю настройки OTF и оставлю проект CRS как EPSG: 4326 (WGS84), я получу то же значение, что и значение ArcGis Area. Однако, если я изменю OTF перед добавлением слоя в EPSG: 21781, я получу другие значения площади. Насколько я понимаю, это говорит о том, что ArcGIS Area была рассчитана с использованием CRS EPSG: 4326.

— kalakaru

Насколько я знаю, Arcgis может вычислять геометрию разными способами. Использование выражения python калькулятора поля !shape.area!должно дать площадь в соответствии с уровнем crs; чем вычисление геометрии может работать иначе. Поэтому трудно сказать, что именно было сделано в arcgis, но если вы получите тот же результат, например, градусы, а не метры, это означает, что расчет площади действительно был основан на ESPG: 4326.

— dof1985

Ответы:

РЕДАКТИРОВАТЬ - Отказ от ответственности: я хотел бы направить читателей на обсуждение с ChrisW ниже. Возможно, что получение области на основе OTF CRS не является ошибкой; то есть, по крайней мере, в arcgis он также используется для геообработки двух слоев из разных CRS.

Чтобы уточнить вопрос выше. Как и предполагал AndreJ, это, вероятно, ошибка в текущей версии qgis. Однако следует отметить, что проблема не в неправильной области, а в том, что преобразование «на лету» в любом случае влияет на вычисления области.

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

Arcmap также предоставляет возможность редактировать данные во время проецирования на лету, но также отмечает, что: ( источник )

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

Конкретные операции редактирования, которые могут вызвать проблемы, включают изменение форм элементов, привязку к краю или границе элементов или расширение и обрезку элементов. Эти проблемы чаще возникают, когда редактируемые объекты находятся близко к краю или за пределами области использования системы координат.

То есть: преобразование на лету менее точно, чем просто проецирование данных в другой CRS (что также создает свои проблемы).

Сказав, что неудивительно, что на основе преобразования «на лету» вычисляется неправильная область, все же удивительно, что факт включения «на лету» каким-либо образом влияет на вычисление геометрии, которое должно основываться на данных. Таким образом, не имеет значения, если преобразование на лету основано на одном и том же или другом CRS, вычисление площади должно быть одинаковым каждый раз.

Чтобы быть более практичным, если ваша цель - вычислить площадь, не используйте на лету. Если у вас неправильный CRS, спроецируйте свои данные.

— dof1985
источник

Я не уверен насчет QGIS, но в отличие от того, что вы упомянули здесь, ArcGIS может на самом деле выполнять расчет геометрии с использованием проекции OTF или совершенно другой проекции в зависимости от метода (т. Е. Щелкните правой кнопкой мыши по столбцу атрибутов и выберите «Рассчитать геометрию по сравнению с -код / вызов поля калькулятора shape.area). Иногда есть выбор использовать CRS: 1) данные / слой, 2) текущий фрейм данных, 3) определенный CRS, не связанный с 1 или 2. Обычно (опять же, ArcGIS), если выбор не представлен, это будет сделано в CRS текущего кадра данных, независимо от того, что это за данные (следовательно, OTF).

— Крис W

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

— Крис W

@ChrisW, если я правильно понимаю; некоторые инструменты геообработки принимают OTF CRS, поскольку это был CRS слоя. Таким образом, получение области на основе OTF CRS не обязательно является ошибкой. Это верно? Что касается Arcgis, давайте примем WGS84 как OTF; как насчет звонка, как:!shape.area@meters!

— dof1985

Это правильно. Ваш фрейм данных и первый слой могут быть WGS84, и вы можете добавить второй слой, который называется NAD83. Второй слой - это проекция OTF, и вы можете запустить на нем любой обычный инструмент, такой как Intersect или Union, и операция происходит в WGS84. Получение области определенно не ошибка. У меня есть клиент, которому нужны данные в NAD83, но для информации требуются единицы в акрах, и я работаю в прогнозируемом CRS для ввода информации. Я обычно просто изменяю проекцию кадра данных, вычисляю площадь, а затем переключаю ее обратно. Не уверен, как будет обрабатываться этот вызов, так как я думаю, что преобразование единиц отличается от расчета.

— Крис W

Я могу подтвердить, что это похоже на ошибку.

Создайте CSV-файл со следующим содержимым:

E N
600000 200000
700000 200000
700000 300000
600000 300000

Импортируйте его как текст с разделителями с помощью EPSG: 21781, включите привязку и нарисуйте многоугольный шейп-файл по четырем точкам.

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

Включение OTF на , и выбрать тот же EPSG: 21781, Вы получаете 9988.2338 м².

Выбор другого CRS, такого как EPSG: 4326, дает 9990,5339 м², потому что расчет выполняется для другого эллипсоида (WGS84 вместо бессела).

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

У ошибки уже есть несколько билетов: https://issues.qgis.org/issues/10966 и https://issues.qgis.org/issues/12473

— Andrej
источник