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.
la source
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.Réponses:
Dans la spécification OGC, qui peut être téléchargée [ici], ( http://www.opengeospatial.org/standards/sfs ), ils indiquent:
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
la source
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:
Accès simple aux fonctionnalités (ISO 19125-1) également utilisé dans WKT / GML / KML et diverses implémentations SQL:
Dans la plupart des implémentations, l'ordre des anneaux dans un POLYGON est important (par opposition aux fichiers de formes)
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 :
É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
GeoJSON (RFC7946) :
TopoJSON : force les anneaux extérieurs dans le sens horaire par défaut
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:
la source
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:
Ainsi, la gamme complète d'options existe et est mise en œuvre là-bas. C'est un monde sauvage!
la source