Rząd wierzchołków wielokątów w ogólnym GIS: zgodnie z ruchem wskazówek zegara lub przeciwnie do ruchu wskazówek zegara

23

Dwa dni temu zadałem pytanie o wewnętrzną kolejność przechowywania wierzchołków wielokąta w plikach kształtu ESRI. Na to pytanie udzielono odpowiedzi ( Czy wielokąty są przechowywane zgodnie z ruchem wskazówek zegara, czy przeciwnie do ruchu wskazówek zegara w pliku kształtu? ), A także odpowiedziano na nie w starym poście ( Tworzenie wielokąta (obrót w prawo czy nie) )

Ale teraz moje pytanie jest bardziej ogólne i nie wiem, czy ma unikalną odpowiedź. Czy kolejność zgodna z ruchem wskazówek zegara dotyczy tylko plików kształtów ESRI lub ogólnych formatów GIS? A co z wewnętrzną reprezentacją oprogramowania GIS? Na przykład, jeśli korzystam z QGIS i czytam * .shp zawierające wielokąty, przypuszczam, że wewnętrzna reprezentacja zewnętrznej granicy jest zgodna z ruchem wskazówek zegara, jak w oryginalnym pliku kształtu, ale co ze wszystkimi formatami plików obsługiwanymi przez QGIS? A dla ArcGIS? W przypadku, gdy istnieje format pliku z wielokątami przechowywanymi w kierunku przeciwnym do ruchu wskazówek zegara, jeśli pliki te są ładowane w QGIS, ArcGIS itp., Orientacja jest zmieniana wewnętrznie, więc jeśli na przykład czytam dane za pomocą PyQGIS, wielokąty są zgodne z ruchem wskazówek zegara zamówione?

Moim celem jest napisanie wtyczki do QGIS, ale źródłem danych mogą być pliki kształtów ESRI lub inne formaty. Ponieważ muszę sprawdzić kąty między kolejnymi bokami wielokątów za pomocą ich azymutów, muszę wiedzieć, czy kolejność jest zgodna z ruchem wskazówek zegara. Jednym z rozwiązań jest obliczenie powierzchni każdego wielokąta i, jeśli dobrze pamiętam, jeśli jest dodatnie, kolejność jest zgodna z ruchem wskazówek zegara, a jeśli ujemna, kolejność jest zgodna z ruchem wskazówek zegara.

Obliczanie obszaru nie jest intensywnym zadaniem, więc nie spowolni tak bardzo mojej wtyczki. Ale w szczególnym przypadku QGIS ktoś wie, czy przechowuje wielokąty zgodnie z ruchem wskazówek zegara, czy przeciwnie do ruchu wskazówek zegara, niezależnie od kolejności w oryginalnym źródle? Do tej pory pracuję z plikami kształtów ESRI i współrzędnymi w layer.getFeatures (). Geometry (). AsPolygon () są przechowywane zgodnie z ruchem wskazówek zegara dla zewnętrznej granicy i przeciwnie do ruchu wskazówek zegara dla otworów, tj. Jak w oryginalnym * .shp.

jgpallero
źródło
To zależy od sposobu przechowywania danych. Wyrocznia jest przeciwna do ruchu
Mapperz
@Mapperz, twój link prowadzi do docs.oracle.com/cd/B10501_01/appdev.920/a96630/…, co wyraźnie wskazuje, Polygons are oriented correctly. (Exterior ring boundaries must be oriented counterclockwise, and interior ring boundaries must be oriented clockwise.)co oznacza, że ​​Oracle jest przeciwnie do ruchu wskazówek zegara.
user30184

Odpowiedzi:

27

W specyfikacji OGC, którą można pobrać [tutaj] ( http://www.opengeospatial.org/standards/sfs ), stwierdzają:

„Obrót wielokąta nie jest zdefiniowany w tym standardzie; rzeczywisty obrót wielokąta może być zgodny z ruchem wskazówek zegara lub przeciwnie do ruchu wskazówek zegara”.

W dokumentach Oracle wyraźnie zaznaczono, że zewnętrzne granice pierścieni są zorientowane przeciwnie do ruchu wskazówek zegara, a wewnętrzne granice pierścieni są zgodne z ruchem wskazówek zegara. Podobnie w programie SQL Server Spatial typ danych geograficznych jest zgodny z regułą przeciwną do ruchu wskazówek zegara dla pierścienia zewnętrznego i przeciwną do ruchu wskazówek zegara dla pierścieni wewnętrznych - więcej szczegółów można znaleźć na blogu MicroSoft . Postgis wydaje się na to zezwalać w obu przypadkach, w przypadku geometrii, i ma funkcje, które zmuszą geometrię wielokąta do przestrzegania reguły prawej lub lewej ręki, patrz ST_ForceRHR i ForceLHR . Wygląda na to, że JTS / Geos postępował zgodnie z zasadą prawej ręki, tj. Orientacją zewnętrznego pierścienia w kierunku zgodnym z ruchem wskazówek zegara, więc wszystko jest naprawdę niejasne.

Zasadniczo sensowne jest, aby typ danych geograficznych wymuszał orientację, ponieważ w przeciwnym razie nie byłoby możliwe ustalenie, czy mały wielokąt był właśnie tym, czy też wewnętrznym pierścieniem wielokąta całego świata. W przypadku typu danych geometrii na płaskiej powierzchni zamieszanie nie może powstać, ponieważ pierścień zewnętrzny i pierścień wewnętrzny podążają w kolejności, a jeśli jest tylko jeden pierścień, będzie otaczał (bez względu na orientację), w przeciwieństwie do kuli ziemskiej , który owija się wokół.


Z komentarza @mxfh: OpenGIS Simple Features Access (ISO 19125-1) OGC określa kierunek pierścieni zewnętrznych w kierunku przeciwnym do ruchu wskazówek zegara, począwszy od dokumentu wersji 1.2.1 [OGC 06-103r4] 6.1.11.1/page 26 from opengeospatial.org / standard / sfa. Zmiana została wprowadzona między wersją 1.1.0 a 1.2.0 najpóźniej w 2006 roku. Przypis, który cytujesz, nie był aktualizowany od 2005 roku

John Powell
źródło
Niezła odpowiedź John. Nie jestem pewien, czy użycie kolejności węzłów do identyfikacji pierścieni wewnętrznych i zewnętrznych jest jedynym sposobem na osiągnięcie tego formatu danych wektorowych. Zgodzę się jednak z tobą, że musi istnieć jakiś mechanizm. Na przykład w GeoJSON pierwsza lista węzłów jest oznaczona jako zewnętrzna, a wszystkie kolejne listy są otworami wewnętrznymi. Działa to jako (jeśli nie bardziej) skutecznie.
WhiteboxDev
Tak, dotyczy to również WKT dla geometrii. W przypadku obszarów geograficznych ma to większe znaczenie.
John Powell
To bardzo prawda;)
WhiteboxDev
@WhiteboxDev powodem, dla którego kolejność nawijania zagnieżdżonych pierścieni jest naprzemienna, jest fakt, że obliczanie obszaru za pomocą metody Shoelace oblicza podpisane obszary w zależności od kierunku pierścienia. Zasadniczo zagnieżdżone pierścienie pierwszego rzędu są uważane za otwory i mają naprzemienny kierunek zewnętrznego pierścienia. Ich wartość pola powierzchni jest ujemna. Gdzie jako pierścień zewnętrzny jest dodatni; więc są zagnieżdżone pierścienie o równej kolejności. Tak więc całkowity obszar wszystkich funkcji pierścienia jest sumą wszystkich podpisanych obszarów.
mxfh
1
@mxfh: ściśle mówiąc, „uzwojenie rzędów zagnieżdżonych pierścieni” jest dyskusyjne dla OCG (i wielu innych) wielokątów ... ponieważ jest niedozwolone. Sposobem na przedstawienie zagnieżdżonego wielokąta w „otworze” innego byłoby użycie MultiPolygon… w takim przypadku każdy składowy wielokąt jest zgodny z oryginalnymi regułami uzwojenia. OK, OK: jest to równoznaczne z naprzemiennym uzwojeniem „zagnieżdżonych liniowych pierścieni”… ale po prostu wskazując, że to nie Wielokąt - per se - pozwala, ale raczej definicja MultiPolygon.
Dan H
23

Kierunki pierścienia (granicy) są potrzebne, aby uniknąć dwuznaczności dla geograficznych układów współrzędnych pokrywających skończoną powierzchnię, ponieważ granica definiowałaby dwa obszary, jeden po lewej i jeden po prawej stronie granicy wzdłuż swojego kierunku. Określenie, który z tych dwóch obszarów jest większy, jest możliwe, ale nadal pozostawia dwuznaczność.

Oto przegląd kierunków pierścienia zewnętrznego wielokątów w różnych formatach według ich specyfikacji:

Ilustracja kolejności nawijania plików kształtów i prostych funkcji

  • Prosty dostęp do funkcji (ISO 19125-1) również używany w WKT / GML / KML i różnych implementacjach SQL:

    • pierścienie zewnętrzne: przeciwnie do ruchu wskazówek zegara
    • pierścienie wewnętrzne (otwory): w kierunku zgodnym z ruchem wskazówek zegara.

    Wielokąt jest płaską powierzchnią zdefiniowaną przez 1 zewnętrzną granicę i 0 lub więcej wewnętrznych granic. Każda wewnętrzna granica definiuje otwór w wielokącie. [...]

    Zewnętrzna granica LinearRing określa „górę” powierzchni, która jest stroną powierzchni, od której wydaje się, że zewnętrzna granica przecina granicę w kierunku przeciwnym do ruchu wskazówek zegara . Do wnętrza LinearRings będzie miał orientację przeciwną, i wyglądają jak z ruchem wskazówek zegara , patrząc od góry „...” Simple Feature specyfikacji dostępu

    W większości implementacji ważna jest kolejność pierścieni w POLYGONIE (w przeciwieństwie do plików kształtów)

    W przypadku wielokąta z dziurami jego pierwszym podelementem jest pierścień zewnętrzny, jego drugim podelementem jest jego pierwszy pierścień wewnętrzny, jego trzecim podelementem jest drugi pierścień wewnętrzny i tak dalej. Oracle Spatial

    Głębsze zagnieżdżenia, czyli wyspa-w-jeziorze-na-wyspie-... muszą być reprezentowane jako wielokąty ( patrz rysunek 2.10 (4) ), ponieważ może istnieć tylko jedna zewnętrzna krawędź i głębsze gniazda niż pierścienie wewnętrzne nie są zdefiniowane.

  • Pliki kształtów ESRI / SHP :

    • pierścienie zewnętrzne: zgodnie z ruchem wskazówek zegara
    • pierścienie wewnętrzne: przeciwnie do ruchu wskazówek zegara

    Wielokąt składa się z jednego lub więcej pierścieni. Pierścień jest połączoną sekwencją czterech lub więcej punktów, które tworzą zamkniętą, nie przecinającą się pętlę. Wielokąt może zawierać wiele pierścieni zewnętrznych . Kolejność wierzchołków lub orientacja pierścienia wskazuje, po której stronie pierścienia znajduje się wnętrze wielokąta. Sąsiedztwo po prawej stronie obserwatora idącego wzdłuż pierścienia w porządku wierzchołków to sąsiedztwo wewnątrz wielokąta. Wierzchołki pierścieni definiujących otwory w wielokątach są w kierunku przeciwnym do ruchu wskazówek zegara . Dlatego wierzchołki dla pojedynczego wielokąta pierścieniowego są zawsze w kolejności zgodnej z ruchem wskazówek zegara . [...]

    Kolejność pierścieni w tablicy punktów nie jest znacząca. Oficjalny dokument ESRI

    Ponieważ w tej definicji wielokąta jest możliwe wiele konfiguracji zewnętrznych granic wyspa w jeziorze na jeziorze na wyspie, możliwe są konfiguracje. Topologicznie wyspa na jeziorze byłaby tylko kolejnym zewnętrznym pierścieniem zgodnym z ruchem wskazówek zegara. W efekcie wielokąt kształtu ESRI jest prostą funkcją MultiPolygon

    Jeśli nie uporządkujesz punktów poprawnie, po prostu będą zachodzić na siebie wielokąty. pyshp

  • GeoJSON (RFC7946) :

    UWAGA: Oryginalna specyfikacja GeoJSON 2008 nie była egzekwowana

    • kolejność nawijania: pierścień zewnętrzny jest przeciwny do ruchu wskazówek zegara (reguła prawa)
    • pierścienie wewnętrzne są zgodne z ruchem wskazówek zegara
    • kolejność pierścieni jest ważna:

      W przypadku wielokątów z wieloma pierścieniami pierwszy musi być pierścieniem zewnętrznym, a pozostałe muszą być pierścieniami wewnętrznymi lub otworami. Specyfikacja GeoJSON

  • TopoJSON : domyślnie wymusza zewnętrzne pierścienie zgodnie z ruchem wskazówek zegara

Ilustracja kolejności nawijania plików kształtów i prostych funkcji

Wycieczka:

Matematyczne rozumowanie, dlaczego kolejność nawijania pierścieni zagnieżdżonych jest naprzemienne, polega na tym, że obliczanie obszaru za pomocą wzoru sznurowadła ( objaśnienie wizualne ) oblicza obszary podpisane w zależności od kierunku pierścienia.

Zasadniczo pierścienie zagnieżdżone (granice wewnętrzne) są uważane za otwory i mają naprzemienny kierunek zewnętrznego pierścienia. Ich udział w podpisanej wartości powierzchni jest ujemny. Gdzie jako pierścienie zewnętrzne są dodatnie. Całkowity obszar wszystkich funkcji pierścienia jest sumą wszystkich podpisanych obszarów.

Zaimplementowane przez ESRI zobacz ten wpis w Bazie wiedzy: Jaki algorytm jest wykorzystywany przez ArcGIS do określania obszaru wielokąta?

Proponowane Mnemoniczne

Otwarte końce form interpretowanych jako strzałki:

  • S hapefile: S → ᔑ → ↻
  • Proste F e Atur e s: E → ᘓ (uzwojenie zewnątrz CC-wise) → ↺
  • GeoJSON: G (trzon G to strzałka) → ↺
mxfh
źródło
4

Nie wiem, czy ktokolwiek będzie w stanie udzielić ostatecznej odpowiedzi na twoje pytanie, ponieważ każdy format pliku wektorowego jest inny, a każdy GIS, jeśli chodzi o sposób wewnętrznego przetwarzania tych danych, również będzie inny. Ale mogę z całą pewnością powiedzieć, że porządkowanie zgodnie z ruchem wskazówek zegara dotyczy nie tylko plików kształtu ESRI. Istnieją inne formaty, które używają podobnego oznaczenia porządkowania zgodnie z ruchem wskazówek zegara dla pierścieni zewnętrznych i przeciwnie do ruchu wskazówek zegara dla wielokątów otworów wewnętrznych. Na przykład struktura wielokąta wektora JTS używa podobnego formatu. W rzeczywistości stwierdzono tutaj , że historycznie miało to być podobne do podejścia ESRI. Mogę również definitywnie powiedzieć, że nie, nie wszystkie formaty mają ten wymóg. Na przykład specyfikacje formatu GeoJSONnie stawiają takiego wymogu odnośnie uporządkowania wierzchołków w ich formacie wielokąta. Specyfikacja KML faktycznie określa:

Wielokąty muszą być określone w kolejności przeciwnej do ruchu wskazówek zegara. Wielokąty są zgodne z „regułą prawej ręki”, która mówi, że jeśli umieścisz palce prawej ręki w kierunku, w którym określone są współrzędne, kciuk wskaże ogólny kierunek normalnej geometrycznej wielokąta.

Tak więc istnieje pełen zakres opcji i są one tam zaimplementowane. To jest dziki świat!

WhiteboxDev
źródło
1
Zauważ, że „reguła prawej ręki” KML jest tradycyjnie nazywana „regułą lewej ręki” (kiedy idziesz po obwodzie z wyciągniętymi rękami, lewa ręka znajdzie się wewnątrz figury). Esri ma wiele podejść, ponieważ pliki kształtu są jedynym formatem, który używa reguły prawej ręki (geobazy firmowe używają reguły lewej ręki wewnętrznie, ale API „C” pozwala na żądanie w dowolnej kolejności). GML wymaga tylko, aby pierścienie wewnętrzne były w przeciwnej kolejności niż pierścienie zewnętrzne, a pierwszy pierścień był zewnętrzny.
Vince
@Vince, że tego nie wiedziałem. Czy to nie orzechy? Dzięki, że dałeś mi znać. Myślę, że najbardziej podoba mi się podejście GML; nie ma znaczenia kolejność, o ile są przeciwne. To ma sens.
WhiteboxDev