Ordre des sommets des polygones en général SIG: dans le sens horaire ou antihoraire


23

Il y a deux jours, j'ai posé une question sur l'ordre de stockage interne des sommets d'un polygone dans les fichiers de formes ESRI. Cette question a été répondue (les polygones sont-ils stockés dans le sens horaire ou antihoraire dans un fichier de formes? ) Et il a également été répondu dans un ancien article ( Création de polygones (rotation dans le sens horaire ou non) )

Mais maintenant ma question est plus générale, et je ne sais pas si elle a une réponse unique. L'ordre dans le sens horaire est-il uniquement pour les fichiers de formes ESRI ou pour les formats SIG généraux? Et qu'en est-il de la représentation interne d'un logiciel SIG? Par exemple, si j'utilise QGIS et que je lis un * .shp contenant des polygones, je suppose que la représentation interne de la limite externe est dans le sens horaire comme dans le fichier de formes d'origine, mais qu'en est-il de tous les formats de fichiers pris en charge par QGIS? Et pour ArcGIS? Et dans le cas où il existe un format de fichier avec des polygones stockés dans le sens antihoraire, si ces fichiers sont chargés dans QGIS, ArcGIS, etc., l'orientation est-elle modifiée en interne, donc si je lis les données à l'aide de PyQGIS, par exemple, les polygones sont dans le sens horaire commandé?

Mon but est d'écrire un plugin pour QGIS, mais la source des données peut être des fichiers de formes ESRI ou d'autres formats. Comme je dois vérifier les angles entre les côtés consécutifs des polygones à l'aide de leurs azimuts, j'ai besoin de savoir si l'ordre est dans le sens horaire. Une solution consiste à calculer l'aire de chaque polygone et, si je me souviens bien, s'il est positif, l'ordre est dans le sens horaire et s'il est négatif, l'ordre est dans le sens antihoraire.

Le calcul de zone n'est pas une tâche intensive, donc cela ne ralentira pas tellement mon plugin. Mais dans le cas particulier de QGIS, quelqu'un sait-il s'il stocke les polygones dans le sens horaire ou antihoraire, quel que soit l'ordre dans la source d'origine? À présent, je travaille avec les fichiers de formes ESRI et les coordonnées dans layer.getFeatures (). Geometry (). AsPolygon () sont stockées dans le sens horaire pour la bordure extérieure et dans le sens antihoraire pour les trous, c'est-à-dire comme dans le fichier * .shp d'origine.


Cela dépend de la façon dont les données sont stockées. Oracle est anti-horaire gis.stackexchange.com/questions/20817/…
Mapperz

@Mapperz, votre lien mène à docs.oracle.com/cd/B10501_01/appdev.920/a96630/… qui indique clairement Polygons are oriented correctly. (Exterior ring boundaries must be oriented counterclockwise, and interior ring boundaries must be oriented clockwise.)ce qui signifie qu'Oracle est dans le sens antihoraire.
user30184

Réponses:


27

Dans la spécification OGC, qui peut être téléchargée [ici], ( http://www.opengeospatial.org/standards/sfs ), ils indiquent:

"La rotation des polygones n'est pas définie par cette norme; la rotation réelle des polygones peut être dans le sens horaire ou antihoraire."

Dans les documents Oracle , il est clairement indiqué que les limites des anneaux extérieurs sont orientées dans le sens antihoraire et les limites des anneaux intérieurs, dans le sens horaire. De même, dans SQL Server Spatial, le type de données geography suit une règle antihoraire pour l'anneau extérieur et dans le sens horaire pour les anneaux intérieurs - consultez ce blog MicroSoft pour plus de détails. Postgis semble l'autoriser dans les deux cas, pour les géométries, et possède des fonctions qui forceront la géométrie d'un polygone à suivre une règle de droite ou de gauche, voir ST_ForceRHR et ForceLHR . Les JTS / Geos semblent avoir suivi la règle de droite, c'est-à-dire une orientation dans le sens des aiguilles d'une montre de l'anneau extérieur, donc tout est un peu flou, vraiment.

En général, il est logique pour un type de données géographiques de forcer l'orientation, car sinon, il serait impossible de dire si un petit polygone n'était que cela ou l'anneau intérieur d'un polygone du monde entier. Avec un type de données de géométrie sur une surface plane, cette confusion ne peut pas se produire, car l'anneau extérieur et l'anneau intérieur suivent dans l'ordre, et s'il n'y a qu'un seul anneau, il sera englobant (quelle que soit l'orientation), contrairement à un globe , qui s'enroule.


D'après un commentaire de @mxfh: OpenGIS Simple Features Access (ISO 19125-1) de l'OGC spécifie une direction antihoraire pour les anneaux extérieurs à partir du document de la version 1.2.1 [OGC 06-103r4] 6.1.11.1/page 26 de opengeospatial.org / normes / sfa. Le changement a été introduit entre la version 1.1.0 et la version 1.2.0 en 2006 au plus tard. La note de bas de page dont vous parlez n'a pas été mise à jour depuis 2005


Belle réponse John. Je ne suis pas sûr que l'utilisation d'un ordre de nœuds pour identifier les anneaux intérieurs et extérieurs soit le seul moyen qu'un format de données vectorielles pourrait atteindre. Je conviendrai cependant avec vous qu'un mécanisme doit être en place. Avec GeoJSON par exemple, la première liste de nœuds est désignée comme extérieure et toutes les listes suivantes sont des trous intérieurs. Cela fonctionne (sinon plus) efficacement.
WhiteboxDev

Oui, cela vaut également pour WKT pour les géométries. Pour les géographies, cela compte clairement plus.
John Powell

C'est très vrai;)
WhiteboxDev

@WhiteboxDev la raison pour laquelle les ordres d'enroulement des anneaux imbriqués alternent est que le calcul de l'aire avec la méthode Shoelace calcule les zones signées en fonction de la direction de l'anneau. En général, les anneaux imbriqués de premier ordre sont considérés comme des trous et ont la direction alternative de l'anneau extérieur. La valeur de leur zone contributive est négative. Où l'anneau extérieur est positif; tout comme les anneaux imbriqués d'ordre égal. Ainsi, la superficie totale de toutes les entités en anneau est la somme de toutes les zones signées.
mxfh

1
@mxfh: à strictement parler, les "ordres d'enroulement des anneaux imbriqués" sont sans objet pour les polygones OCG (et bien d'autres) .... car cela n'est pas autorisé. La façon de représenter un polygone imbriqué à l'intérieur du "trou" d'un autre serait d'utiliser un MultiPolygon ... auquel cas, chaque polygone constitutif suit les règles d'enroulement d'origine. OK, OK: cela revient à alterner l'enroulement de "LinearRings imbriqués" ... mais en soulignant simplement que ce n'est pas le Polygon - en soi - qui permet cela, mais plutôt la définition du MultiPolygon.
Dan H

23

Des directions en anneau (limites) sont nécessaires pour éviter les ambiguïtés des systèmes de coordonnées géographiques qui couvrent une surface finie, car la frontière définirait deux zones, une à gauche et une à droite de la frontière le long de sa direction. Déterminer laquelle de ces deux zones est la plus grande est possible, mais laisse toujours l'ambiguïté.

Voici un aperçu des directions des anneaux externes des polygones dans différents formats par leurs spécifications:

Illustration de l'ordre d'enroulement des fichiers de formes et des fonctionnalités simples

  • Accès simple aux fonctionnalités (ISO 19125-1) également utilisé dans WKT / GML / KML et diverses implémentations SQL:

    • anneaux extérieurs: anti-horaire
    • bagues intérieures (trous): sens horaire.

    Un polygone est une surface plane définie par 1 limite extérieure et 0 ou plusieurs limites intérieures. Chaque limite intérieure définit un trou dans le polygone. [...]

    Le contour extérieur LinearRing définit le «haut» de la surface qui est le côté de la surface à partir duquel le contour extérieur semble traverser le contour dans le sens antihoraire . Les intérieurs LinearRings auront l'orientation opposée, et apparaissent comme dans le sens horaire vu de la « top » ... caractéristiques simples d'accès aux fonctions

    Dans la plupart des implémentations, l'ordre des anneaux dans un POLYGON est important (par opposition aux fichiers de formes)

    Pour un polygone avec des trous, son premier sous-élément est son anneau extérieur, son deuxième sous-élément est son premier anneau intérieur, son troisième sous-élément est son deuxième anneau intérieur, etc. Oracle Spatial

    Les nids plus profonds, alias île-dans-un-lac-sur-une-île, doivent être représentés comme des multipolygones ( voir figure 2.10 (4) ), car il ne peut y avoir qu'une seule bordure extérieure et des nidifications plus profondes que les anneaux intérieurs. ne sont pas définis.

  • ESRI Shapefiles / SHP :

    • anneaux extérieurs: dans le sens horaire
    • bagues intérieures: anti-horaire

    Un polygone consiste en un ou plusieurs anneaux. Un anneau est une séquence connectée de quatre points ou plus qui forment une boucle fermée non auto-intersectée. Un polygone peut contenir plusieurs anneaux externes . L'ordre des sommets ou l'orientation d'un anneau indique de quel côté de l'anneau se trouve l'intérieur du polygone. Le voisinage à droite d'un observateur marchant le long de l'anneau dans l'ordre des sommets est le voisinage à l'intérieur du polygone. Les sommets des anneaux définissant les trous dans les polygones sont dans le sens antihoraire . Les sommets d'un seul polygone annelé sont donc toujours dans le sens des aiguilles d'une montre . [...]

    L'ordre des anneaux dans le tableau de points n'est pas significatif. Livre blanc ESRI

    Étant donné que plusieurs frontières extérieures sont autorisées, des configurations île-dans-un-lac-sur-une-île sont possibles avec cette définition de polygone. Topologiquement, l'île dans un lac ne serait qu'un autre anneau extérieur dans le sens des aiguilles d'une montre. En fait, cela fait d'un polygone ESRI Shapefile un multi-polygone à fonction simple

    Si vous ne triez pas correctement les points, vous n'aurez que des polygones qui se chevauchent. pyshp

  • GeoJSON (RFC7946) :

    REMARQUE: aucune spécification d' origine de GeoJSON 2008 n'a été appliquée

    • ordre d'enroulement: l'anneau extérieur est dans le sens antihoraire (règle de droite)
    • les anneaux intérieurs sont dans le sens horaire
    • l'ordre des anneaux est important:

      Pour les polygones avec plusieurs anneaux, le premier doit être l'anneau extérieur et les autres doivent être des anneaux ou des trous intérieurs. Spécifications GeoJSON

  • TopoJSON : force les anneaux extérieurs dans le sens horaire par défaut

Illustration de l'ordre d'enroulement des fichiers de formes et des fonctionnalités simples

Excursion:

Le raisonnement mathématique expliquant pourquoi les ordres d'enroulement des anneaux imbriqués alternent est que le calcul de la zone avec la formule du lacet ( explication visuelle ) calcule les zones signées en fonction de la direction de l'anneau.

En général, les anneaux imbriqués (limites intérieures) sont considérés comme des trous et ont la direction alternative de l'anneau extérieur. Leur valeur de zone signée contributive est négative. Où les anneaux extérieurs sont positifs. La superficie totale de toutes les fonctions d'anneau est la somme de toutes les zones signées.

Telle qu'implémentée par ESRI, consultez cette entrée de la base de connaissances: Quel algorithme est utilisé par ArcGIS pour déterminer la zone d'un polygone?

Mnémonique proposé

Extrémités ouvertes de lettres interprétées comme des flèches:

  • S hapefile: S → ᔑ → ↻
  • F é atur e s simples : e → ing (enroulement vers l'extérieur en cc) → ↺
  • GeoJSON: G (la tige de G est une flèche) → ↺

4

Je ne sais pas si quelqu'un sera en mesure de fournir une réponse définitive à votre question car chaque format de fichier vectoriel est différent et chaque SIG, en termes de gestion interne de ces données, sera également différent. Mais je peux vous dire avec certitude que l'ordre dans le sens des aiguilles d'une montre ne concerne pas uniquement les fichiers de formes ESRI. Il existe d'autres formats qui utilisent une désignation similaire dans le sens horaire pour les anneaux externes et dans le sens antihoraire pour les polygones de trous intérieurs. Par exemple, la structure polygonale du vecteur JTS utilise un format similaire. En fait, il est dit ici que, historiquement, cela devait être similaire à l'approche ESRI. Je peux aussi dire définitivement que non, tous les formats n'ont pas cette exigence. Par exemple, les spécifications du format GeoJSONne pas imposer une telle exigence sur l'ordre des sommets dans leur format de polygone. La spécification KML indique en fait:

Les polygones for doivent être spécifiés dans le sens antihoraire. Les polygones suivent la "règle de la main droite", qui stipule que si vous placez les doigts de votre main droite dans la direction dans laquelle les coordonnées sont spécifiées, votre pouce pointe dans la direction générale de la normale géométrique du polygone.

Ainsi, la gamme complète d'options existe et est mise en œuvre là-bas. C'est un monde sauvage!


1
Notez que la "règle de la main droite" de KML est ce qui a été conventionnellement appelé la "règle de la main gauche" (lorsque vous marchez le périmètre avec vos bras tendus, votre main gauche sera à l'intérieur de la figure). Esri a plusieurs approches, car les fichiers de formes sont le seul format qui utilise la règle de droite (les géodatabases d'entreprise utilisent la règle de gauche en interne, mais l'API «C» vous permettra de demander dans l'un ou l'autre ordre). GML exige uniquement que les anneaux intérieurs soient dans l'ordre opposé des anneaux extérieurs et que le premier anneau soit extérieur.
Vince

@Vince, je ne le savais pas. N'est-ce pas fou? Merci de me le faire savoir. Je pense que j'apprécie le plus l'approche de GML; peu importe l'ordre tant qu'ils sont opposés. Cela a du sens.
WhiteboxDev
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.