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.
źródło
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.Odpowiedzi:
W specyfikacji OGC, którą można pobrać [tutaj] ( http://www.opengeospatial.org/standards/sfs ), stwierdzają:
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
źródło
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:
Prosty dostęp do funkcji (ISO 19125-1) również używany w WKT / GML / KML i różnych implementacjach SQL:
W większości implementacji ważna jest kolejność pierścieni w POLYGONIE (w przeciwieństwie do plików kształtów)
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 :
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
GeoJSON (RFC7946) :
TopoJSON : domyślnie wymusza zewnętrzne pierścienie zgodnie z ruchem wskazówek zegara
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:
źródło
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:
Tak więc istnieje pełen zakres opcji i są one tam zaimplementowane. To jest dziki świat!
źródło