Порядок вершин многоугольника в общей ГИС: по часовой стрелке или против часовой стрелки

23

Два дня назад я задал вопрос о порядке внутреннего хранения вершин многоугольника в шейп-файлах ESRI. На этот вопрос был дан ответ ( хранятся ли полигоны по часовой стрелке или против часовой стрелки в шейп-файле? ), И на него также был дан ответ в старом сообщении ( Создание полигона (вращение по часовой стрелке или нет) )

Но теперь мой вопрос носит более общий характер, и я не знаю, есть ли у него уникальный ответ. Порядок по часовой стрелке только для шейп-файлов ESRI или для общих форматов ГИС? А как насчет внутреннего представления программного обеспечения ГИС? Например, если я использую QGIS и читаю * .shp, содержащий многоугольники, я предполагаю, что внутреннее представление внешней границы идет по часовой стрелке, как в исходном шейп-файле, но как насчет всех форматов файлов, поддерживаемых QGIS? А для ArcGIS? И в случае, если существует формат файла с полигонами, хранящимися против часовой стрелки, если эти файлы загружаются в QGIS, ArcGIS и т. Д., Внутренняя ориентация изменяется, поэтому, если я, например, считываю данные с помощью PyQGIS, полигоны располагаются по часовой стрелке упорядоченный?

Моя цель - написать плагин для QGIS, но источником данных могут быть шейп-файлы ESRI или другие форматы. Поскольку мне нужно проверить углы между последовательными сторонами многоугольников, используя их азимуты, мне нужно знать, если порядок по часовой стрелке. Одним из решений является вычисление площади каждого многоугольника, и, если я правильно помню, если он положительный, то порядок по часовой стрелке, а если отрицательный, то порядок против часовой стрелки.

Вычисление площади не является интенсивной задачей, поэтому она не будет сильно замедлять мой плагин. Но в особом случае QGIS кто-нибудь знает, хранит ли он многоугольники по часовой стрелке или против часовой стрелки, независимо от порядка в исходном источнике? К настоящему времени я работаю с шейп-файлами ESRI и координатами в layer.getFeatures (). Geometry (). AsPolygon () хранится по часовой стрелке для внешней границы и против часовой стрелки для отверстий, т.е. как в исходном * .shp.

jgpallero
источник
Это зависит от того, как хранятся данные. Oracle - против часовой стрелки gis.stackexchange.com/questions/20817/…
Mapperz
@Mapperz, ваша ссылка ведет на docs.oracle.com/cd/B10501_01/appdev.920/a96630/…, где четко указано, Polygons are oriented correctly. (Exterior ring boundaries must be oriented counterclockwise, and interior ring boundaries must be oriented clockwise.)что означает, что Oracle работает против часовой стрелки.
user30184

Ответы:

27

В спецификации OGC, которую можно скачать [здесь], ( http://www.opengeospatial.org/standards/sfs ) они заявляют:

«Вращение многоугольника не определено этим стандартом; фактическое вращение многоугольника может быть по часовой стрелке или против часовой стрелки».

В документации Oracle четко указано, что границы внешних колец ориентированы против часовой стрелки, а границы внутренних колец - по часовой стрелке. Аналогично, в SQL Server Spatial тип данных географии следует правилу против часовой стрелки для внешнего кольца и по часовой стрелке для внутренних колец - см. Этот блог MicroSoft для получения дополнительной информации. Кажется, Postgis допускает это в любом случае для геометрий и имеет функции, которые заставляют геометрию многоугольника следовать правилу правой или левой руки, см. ST_ForceRHR и ForceLHR . JTS / Geos, похоже, следовали правилу правой руки, то есть ориентации внешнего кольца по часовой стрелке, так что на самом деле все немного неясно.

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


Из комментария @mxfh: OGC OpenGIS Simple Feature Access (ISO 19125-1) определяет направление вращения против часовой стрелки для внешних колец, начиная с документа версии 1.2.1 [OGC 06-103r4] 6.1.11.1/page 26 от opengeospatial.org / стандарты / SFA. Изменения были внесены между версиями 1.1.0 и 1.2.0 в 2006 году. Сноска, на которую вы ссылаетесь, не обновлялась с 2005 года.

Джон Пауэлл
источник
Хороший ответ Джон. Я не уверен, что использование порядка узлов для идентификации внутренних и внешних колец - единственный способ, которым векторный формат данных мог бы достичь этого. Я согласен с вами, хотя какой-то механизм должен быть на месте. Например, для GeoJSON первый список узлов обозначается как внешний, а все последующие списки являются внутренними отверстиями. Это работает как (если не больше) эффективно.
WhiteboxDev
Да, это верно и для WKT для геометрии. Для географии это, безусловно, имеет большее значение.
Джон Пауэлл
Это очень верно;)
WhiteboxDev
@WhiteboxDev причина, по которой чередуются порядки намотки вложенных колец, состоит в том, что при расчете площади с помощью метода шнурков вычисляются подписанные области в зависимости от направления кольца. В целом, вложенные кольца первого порядка считаются отверстиями и имеют альтернативное направление внешнего кольца. Их вклад в стоимость области отрицателен. Где как внешнее кольцо положительно; так же как и вложенные кольца четного порядка. Таким образом, общая площадь всех функций кольца является суммой всех подписанных областей.
mxfh
1
@mxfh: строго говоря, "порядок намотки вложенных колец" является спорным для OCG (и многих других) полигонов .... так как это запрещено. Способ представления вложенного многоугольника внутри «дыры» другого состоит в использовании MultiPolygon ... в этом случае каждый составляющий многоугольник следует исходным правилам намотки. Хорошо, хорошо: это равносильно чередованию намотки «вложенных линейных колец» ... но просто указывает на то, что это позволяет не Polygon как таковой, а определение MultiPolygon.
Дан Х
23

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

Вот краткий обзор направлений внешнего кольца полигонов в различных форматах по их спецификациям:

Иллюстрация порядка намотки шейп-файлов и простых функций

  • Простой доступ к функциям (ISO 19125-1) также используется в WKT / GML / KML и различных реализациях SQL:

    • наружные кольца: против часовой стрелки
    • внутренние кольца (отверстия): по часовой стрелке.

    Полигон - это плоская поверхность, определяемая 1 внешней границей и 0 или более внутренними границами. Каждая внутренняя граница определяет отверстие в многоугольнике. [...]

    Внешняя граница LinearRing определяет «вершину» поверхности, которая является стороной поверхности, с которой внешняя граница пересекает границу в направлении против часовой стрелки . В салоне LinearRings будет иметь ориентацию противоположной, и появляется как по часовой стрелке , если смотреть «сверху» ... простой функцию спецификации доступа

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

    Для многоугольника с отверстиями его первый подэлемент является его внешним кольцом, его второй подэлемент является его первым внутренним кольцом, его третий подэлемент является его вторым внутренним кольцом и так далее. Oracle Spatial

    Более глубокие вложения, называемые островом в озере на острове ... должны быть представлены как мультиполигоны ( см. Рисунок 2.10 (4) ), поскольку может быть только одна внешняя граница и более глубокие вложения, чем внутренние кольца не определены.

  • Шейп-файлы ESRI / SHP :

    • внешние кольца: по часовой стрелке
    • внутренние кольца: против часовой стрелки

    Многоугольник состоит из одного или нескольких колец. Кольцо - это связная последовательность из четырех или более точек, которые образуют замкнутую несамопересекающуюся петлю. Многоугольник может содержать несколько внешних колец . Порядок вершин или ориентации кольца указывает, какая сторона кольца является внутренней частью многоугольника. Окрестность справа от наблюдателя, идущего по кольцу в порядке вершин, является окрестностью внутри многоугольника. Вершины колец, определяющих отверстия в многоугольниках, направлены против часовой стрелки . Поэтому вершины для одного окружного многоугольника всегда располагаются по часовой стрелке . [...]

    Порядок колец в массиве точек не имеет значения. ESRI Whitepaper

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

    Если вы не упорядочите точки правильно, у вас будут только перекрывающиеся полигоны. pyshp

  • GeoJSON (RFC7946) :

    ПРИМЕЧАНИЕ. В оригинальной спецификации GeoJSON 2008 не был применен порядок намотки

    • порядок намотки: наружное кольцо против часовой стрелки (правило правой руки)
    • внутренние кольца по часовой стрелке
    • порядок колец важен:

      Для многоугольников с несколькими кольцами первое должно быть внешним кольцом, а любые другие должны быть внутренними кольцами или отверстиями. GeoJSON spec

  • TopoJSON : по умолчанию заставляет внешние кольца по часовой стрелке

Иллюстрация порядка намотки шейп-файлов и простых функций

Экскурсия:

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

Обычно вложенные кольца (внутренние границы) считаются отверстиями и имеют альтернативное направление внешнего кольца. Их вклад в значение подписанной области отрицательный. Где как внешние кольца положительные. Общая площадь всех элементов кольца является суммой всех подписанных областей.

Как реализовано в ESRI, смотрите эту запись базы знаний: Какой алгоритм используется ArcGIS для определения площади многоугольника?

Предложенный Мнемоник

Открытые концы букв, которые интерпретируются как стрелки:

  • S- файл: S → ᔑ → ↻
  • Простой Р е Atur е ы: е → ᘓ (обмотки наружу куб.см стрелки) → ↺
  • GeoJSON: G (основа G - стрелка) → ↺
mxfh
источник
4

Я не знаю, кто-нибудь сможет дать однозначный ответ на ваш вопрос, поскольку каждый формат векторного файла различен, и каждая ГИС с точки зрения внутренней обработки этих данных также будет отличаться. Но я могу с уверенностью сказать, что упорядочение по часовой стрелке относится не только к шейп-файлам ESRI. Существуют и другие форматы, в которых используется аналогичное обозначение по часовой стрелке для внешних колец и против часовой стрелки для внутренних многоугольников отверстий. Например, структура векторного полигона JTS использует аналогичный формат. На самом деле, говорится здесь , что исторически это должно было быть аналогичен подходу ESRI. Я также могу однозначно сказать, что нет, не во всех форматах есть это требование. Например, спецификации формата GeoJSONне предъявлять таких требований к упорядочению вершин в их формате многоугольника. Спецификация KML фактически заявляет:

Полигоны for должны быть указаны в направлении против часовой стрелки. Полигоны следуют «правилу правой руки», которое гласит, что если вы поместите пальцы правой руки в направлении, в котором указаны координаты, ваш большой палец будет указывать в общем направлении геометрической нормали для многоугольника.

Таким образом, существует полный набор опций, которые реализуются там. Это дикий мир!

WhiteboxDev
источник
1
Обратите внимание, что «правило правой руки» KML - это то, что обычно называют «правилом левой руки» (когда вы идете по периметру с вытянутыми руками, ваша левая рука будет внутри фигуры). В Esri есть несколько подходов, поскольку шейп-файлы являются единственным форматом, в котором используется правило правой руки (в многопользовательских базах геоданных внутреннее правило используется левое правило, но API C позволяет запрашивать их в любом порядке). GML требует только, чтобы внутренние кольца были в порядке, противоположном внешним кольцам, и чтобы первое кольцо было внешним.
Винс
@ Винс, я этого не знал. Разве это не орехи? Спасибо, что дал мне знать. Я думаю, что мне нравится подход GML больше всего; не имеет значения порядок, пока они противоположны. Это имеет большой смысл.
WhiteboxDev