Сценарии расчета длины и площади ArcGIS [закрыто]


13

Попытка получить представление о том, как длина и площадь рассчитываются в различных сценариях в ArcGIS. Я не знаю, почему я не могу найти ответ в полях класса пространственных объектов, но я не могу найти точный ответ, если я чего-то не понимаю и знаю, что есть какая-то история. Можете ли вы помочь мне заполнить вопросительные знаки? Или скажите мне, почему я все это делаю неправильно; )

GCS = Географическая система координат PCS = Проектируемая система координат
Все ссылки на 10.1 Справочные документы -

  1. Поля shape_length и shape_area класса объектов
    a. GCS -?
    б. PCS - Использование простого планара
    c. Всегда ли он обновляется автоматически, кроме шейп-файлов? да

  2. Инструмент измерения ArcMap
    a. GCS - геодезическая по умолчанию, альтернативы Loxodrome и Great Elliptic, но не плоские. Расчет площади недоступен!
    б. PCS - планар по умолчанию, альтернативы Geodesic, Loxodrome и Great Elliptic
    http://resources.arcgis.com/en/help/main/10.1/index.html#//00s500000022000000

  3. Калькулятор таблицы атрибутов
    a. GCS - недоступно
    b. PCS - планарный
    http://resources.arcgis.com/en/help/main/10.1/index.html#//005s00000027000000

  4. Инструмент вычисления поля (набор инструментов для управления данными)
    a. GCS - геодезическая линейная, площадь доступная, но сомнительная
    b. PCS - планарный
    http://resources.arcgis.com/en/help/main/10.1/index.html#//00170000004m000000

  5. Буферный инструмент (и другие инструменты в продаже)
    a. GCS - геодезическая
    б. PCS - планарный или указать вывод GCS http://resources.arcgis.com/en/help/main/10.1/index.html#//000800000019000000

  6. Javascript API Clientside
    a. GCS - геодезическая площадь и функции длины
    b. PCS - может конвертировать из веб-mercator в географический (или использовать сервис геометрии) http://help.arcgis.com/en/webapi/javascript/arcgis/help/jsapi/namespace_geometry.htm

  7. Клиент Flex API
    a. GCS - геодезическая площадь и функции длины, «Длина [или площадь] будет рассчитана с использованием пользовательской цилиндрической проекции равной площади». Это не упоминается в API javascript!
    б. PCS - может конвертировать из веб-mercator в географический http://resources.arcgis.com/en/help/flex-api/apiref/com/esri/ags/utils/GeometryUtil.html

  8. API REST ArcGIS Server - Сервис геометрии
    a. GCS - геодезическая
    б. PCS - планарный
    http://help.arcgis.com/en/webapi/javascript/arcgis/help/jsapi/geometryservice.htm

Другой вопрос, что именно является геодезическим измерением? Я думал, что это означает формулу трехмерного триггера на сфероиде (haversine?). И слишком ли медленно это использовать при расчете площади, и поэтому используются проекции равных площадей?

Другой вопрос при определении длины и площади - является ли проекция равной площади более точной, чем геодезический расчет с использованием той же базы данных, сфероид? И вкратце почему?


2
Что касается последнего вопроса, см. Какова наиболее точная система координат для расчета площадей многоугольников? , Для предпоследнего, поскольку существуют равные проекции площадей для эллипсоидов, гораздо проще вычислить площади с такими проекциями, чем писать код, специфичный для эллипсоидов. Ситуация не так хороша для вычисления расстояний, потому что ни одна проекция точно не воспроизводит все расстояния: таким образом, прямые сферические и эллипсоидальные формулы расстояния часто реализуются в хороших ГИС.
whuber

1
1.b, 3.b и 4.b используют спроецированную систему координат, поэтому плоская. 1.c всегда автоматически обновляется при использовании базы геоданных (персональная / файловая / SDE).
Йенс

2
Я думаю, что было бы лучше разделить ваши вопросы. Таким образом, вы получите лучшие ответы для каждого. Так было бы проще проголосовать за ответы.
РК

1
Я думаю, что здесь есть около 10 вопросов, на каждый из которых, скорее всего, ответили бы быстро, если бы они были представлены по одному (в виде отдельных Вопросов). Сочетание множества вопросов в одном затрудняет наш стиль ответов на вопросы и ответы.
PolyGeo

1
Это не хороший кандидат на CW. Более того, он, возможно, не слишком широк: он кажется таким только благодаря тщательному перечислению множества различных способов, которые ArcGIS предлагает для вычисления площади и длины. Это все еще один вопрос, который был очень четко сфокусирован.
whuber

Ответы:


5

По сути, ваш вопрос касается точного (и эффективного) расчета длины и площади в большом регионе. Практические детали (в данном случае, касающиеся ArcGIS) уже заполняются вами и другими. Они также указывают на следующие общие выводы:

  • длина лучше всего рассчитывается по геодезическим (географическим) координатам
  • площадь лучше всего рассчитывать с помощью плоских координат проекции равных площадей [Правка: Но сложность границы или количество вершин, необходимых для ее описания, тоже является фактором - см. ответ @ cffk]

Вот некоторые объяснения:

Геодезическая является

самая короткая линия между двумя точками на математически определенной поверхности (как прямая линия на плоскости или дуга большого круга на сфере)

http://wordnetweb.princeton.edu/perl/webwn?s=geodesic%20line (к сведению, на эллипсоиде геодезическая, как правило, слегка S-образная.)

Хотя расчеты геодезических (длин на эллипсоиде) относительно сложны, по сравнению с использованием известного уравнения Пифагора они возможны и точны. Однако они относительно просты по сравнению с расчетами площадей на эллипсоиде.

Проекции карты обычно не сохраняют линейные масштабы, поэтому координаты проекции, как правило, не подходят для расчета длины. (Существуют исключения, но они зависят от того, где вы находитесь на проекции или в каком направлении вы движетесь.) Что касается области , существует класс проекций, который точно сохраняет ареальный масштаб: проекции равных площадей. Вычислить площади на плоскости довольно просто, и, если используется проекция равной площади, это точно.

Есть много хороших источников по геодезии или картографическим прогнозам, которые могут помочь. Например, « Геометрическая геодезия: использование информационных и компьютерных технологий», автор Maarten Hooijberg.


Характеризуя геодезическую как S-образную, возможно, вводит в заблуждение, потому что это подразумевает, что это не самый короткий путь. Мне известны различные фигуры, которые изображают геодезическую в виде S-образной кривой, зажатой между двумя нормальными участками. Но я подозреваю, что они не точны.
cffk

Если ни одна из двух нормальных секций не является геодезической, разве геодезическая не должна быть зажата между ними и соответственно совпадать с каждой на концах?
Мартин Ф

4

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

  1. спроецируйте многоугольник на равную площадь проекции, вставив достаточное количество дополнительных вершин на каждом ребре, чтобы проецируемые ребра точно следовали геодезической, и измерьте площадь в проецируемом пространстве;
  2. используйте формулы для площади геодезического многоугольника.

Второй метод, как правило, быстрее и точнее, если ребра многоугольника не очень короткие. К сожалению, Arcgis не реализует этот метод (но он должен!). Однако GeographicLib и проектируемый (версия 4.9.0 и выше) делают. См. Статью Wikipedia о площади геодезического многоугольника для получения дополнительной информации.


+1 Однако я беспокоюсь о точности геодезических расчетов применительно к небольшим полигонам (таким как участки жилых участков): поскольку при сложении и вычитании огромных площадей получается конечная зона, происходит огромная отмена и потеря точность. Когда координаты имели действительно двойную точность, это, вероятно, не было проблемой, но с ГИС, которые дискретизируют свои координаты в интегральную сетку для своих вычислений (которая включает в себя ArcGIS), это могло бы правдоподобно уничтожить почти всю присущую точность и привести к ошибочным результатам.
whuber

Ничего особенного не поделаешь, если в начальных координатах есть ошибки. Однако общая точность формул геодезической площади, использующих двойную точность, составляет не более 0,1 м ^ 2 на вершину. Типичных ошибок гораздо меньше. Я тщательно проверил границы разных провинций в Польше. Например, полигон для Кракова имеет 8416 вершин (самый длинный край = 405 м, самый короткий край = 0,02 м). Истинная площадь (WGS84) = 326798565.428446 м ^ 2, расчетная площадь (утилита GeographicLib's Planimeter) = 326798565.4285 м ^ 2.
cffk

Справа: двойная точность хороша, потому что она имеет точность около 52 бит, и вы теряете не более 20 с вычислениями Гаусса-Бонне (угловое превышение). Но целые числа со знаком имеют максимальную точность 32 бита (и часто немного меньше, в зависимости от того, как инициализируется область анализа), поэтому потеря 20 из них может стать заметной. Я говорю о потере точности в расчетах, а не о последствиях ошибок в самих координатах.
whuber

Я не уверен, почему я хотел бы представлять любые реальные величины в виде целых чисел со знаком в середине вычисления, подобного этому. (Кроме того, откуда берется ваша оценка в 20 цифр для потери точности?) Я согласен с тем, что оценить ошибку для реалистичных полигонов сложно. Таким образом, в случае Кракова, приведенного выше, я вычислил истинную площадь методом грубой силы (оценивая формулы площади, сохраняя 20 терминов в серии и используя арифметику из 75 цифр). У меня также есть аналогичные данные для других областей Польши и для всей страны (68000 вершин), площадь = 312e9 м ^ 2, ошибка = 0,001 м ^ 2.
cffk

1
OK. Однако я до сих пор не понимаю, почему представление координат в целочисленной сетке требует выполнения вычислений для этих координат с использованием целых чисел вместо двойной точности. Так что мне кажется, что вы берете удар по точности, квантуя координаты в сетку. Однако дополнительная ошибка, связанная с усечением ряда и округлением во время вычисления площади, может быть довольно небольшой (см. Примеры выше).
cffk
Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.