Blog SIG & Territoires

Les algorithmes de gestion et de traitement des données SIG sont construits avec l’hypothèse que la géométrie des entités répond à certaines spécifications. Lorsque les algorithmes de traitement des données traitent des données qui ne respectent pas ces spécifications, le logiciel peut tout simplement planter ou, pire, l’opération peut réussir sans problème apparent, mais le résultat est faux. Le sujet est compliqué car il n’y a presque pas de documentation relative à ce que fait chaque logiciel. Et si vous pensez qu’une commande « Réparer les géométries » vous tire d’affaire, vous êtes loin du compte…
A l’origine des mauvaises géométries, on retrouve essentiellement les fichiers de formes ESRI (shapefile). Ce format très ancien (années 80) n’a pas été conçu pour intégrer les contraintes topologiques d’un SIG. Par exemple, deux polygones contigus peuvent se superposer sans problème, leurs limites peuvent être doubles, il peut y avoir des espaces vides entre les deux limites,…
Malheureusement, il est devenu un format standard d’échange de données entre les différents logiciels SIG, et même si tous les éditeurs ainsi que les projets OpenSource s’évertuent à proposer des formats de gestion alternatifs, puissants et nettement plus sûrs (ESRI geodatabase, PostGis, Spatialite,…) les utilisateurs optent le plus souvent par la solution de facilité du shapefile.
Mais pour ceux qui optent pour ces formats de base de données actuels, le problème n’est résolu que pour les données créées directement dans ces formats. Lorsque les fichiers de formes (shapefile) sont chargés dans les géodatabases ESRI (personnelles ou fichiers), dans une base PostGis ou Spatialite, etc., les géométries sont copiées telles quelles, avec tous les problèmes de géométrie existants. La même prudence et les soins qui doivent être de mise lors de l’utilisation des données de shapefiles, doivent être pris lors de l’utilisation des autres formats où ces données sont importées.

Le travail indispensable comprend deux étapes, traduites généralement par deux outils SIG:

• analyser les géométries pour détecter des anomalies, généralement sous la forme d’un outil « Vérifier les géométries »
• corriger les anomalies détectées, généralement sous la forme d’un outil « Réparer les géométries »

L’outil Vérifier Géométrie va générer un rapport de toutes les entités avec des problèmes de géométrie dans les couches géographiques fournies. Pour résoudre ces problèmes, l’outil de réparation des géométries prendra en charge la correction automatique.

Ceci paraît magique, mais c’est beaucoup plus compliqué qu’il n’y paraît.

Bien qu’il existe différentes définitions pour un polygone, la plupart des logiciels de SIG utilisent maintenant celle de l’Open Geospatial Consortium (OGC) et l’Organisation internationale de normalisation (ISO), et offrent des fonctions de validation pour garantir la conformité des polygones à la définition. Il y a de petites variations entre les différentes implémentations, mais on peut considérer la validation d’un polygone à deux dimensions comme un problème résolu au niveau théorique. Avoir une définition commune, ainsi que des outils de validation, devrait assurer aux utilisateurs SIG, la possibilité d’échanger des ensembles de données et utiliser les opérations d’analyse spatiale avec ces données (une entrée valide est une condition préalable pour la plupart des opérations).
Toutefois, si un polygone ne se conforme pas à la définition, alors il faut le réparer. La plupart des outils de validation donnent à l’utilisateur une liste des erreurs et les endroits où ils se trouvent, mais l’utilisateur doit les corriger manuellement. Ceci est une tâche très fastidieuse et chronophage.

D’où la tentation évidente d’utiliser les outils automatiques de réparation des géométries.

Nous allons voir dans cette série d’articles comment se comportent les principaux logiciels SIG au niveau de la détection et de la correction des géométries. Disons le tout de suite, si vous en voulez un qui marche à 100%, vous serez déçu. Mais mieux vaux savoir tout ce qu’on fait de mal ou d’approximatif que de fermer les yeux dessus, n’est-ce pas?

Le premier problème auquel on est confronté pour aborder ce thème est le manque quasi total de documentation des logiciels. Nous allons donc prendre une couche de polygoners contenant des anomalies et la traiter dans les différents logiciels.

Nous allons utiliser une couche des communes italiennes fournie par ISTAT, l’Institut Statistique Italien. C’est cette couche qui est utilisée dans la page sur la validation des géométries de Spatialite :SQL functions based on liblwgeom support in version 4.0.0.

La couche est téléchargeable sur ce lien : https://www.nasca.ovh/downloads/com2011.zip.

Validation de la géometrie avec ArcGis

Posons le cadre :
– nous utilisons ArcGis 10.3 en version anglaise
– la commande utilisée est Toolbox -> Data Management Tools -> Features -> Check Geometry
– la couche à tester est la couche com2011.shp que nous avons téléchargé

Une fois la commande exécutée, la table avec la liste des enregistrements invalides est chargée dans ArcMap

Vous constaterez que la commande n’a trouvé aucune géométrie invalide.

Si nous recherchions dans l’aide ArcGis, la seule description du travail réalisé par la commande Vérifier les géométries se trouve dans la page http://desktop.arcgis.com/fr/desktop/latest/tools/data-management-toolbox/check-geometry.htm

Il est précisé que les erreurs détectées sont:

• Short segment : certains segments sont plus courts que ce qu’autorisent les unités système de la référence spatiale associée à la géométrie.
• Null geometry : l’entité n’a aucune géométrie ou rien dans le champ SHAPE.
• Incorrect ring ordering : le polygone est simple d’un point de vue topologique, mais ses boucles peuvent ne pas être orientées correctement (boucles externes : sens horaire, boucles internes : sens anti-horaire).
• Incorrect segment orientation : des segments particuliers ne sont pas orientés de manière cohérente. Le point d’arrivée du segment i doit correspondre au point de départ du segment i+1.
• Self intersections : un polygone ne doit pas être auto-sécant.
• Unclosed rings : le point d’arrivée du dernier segment dans une boucle doit correspondre au point de départ du premier segment.
• Empty parts : la géométrie comporte plusieurs parties et l’une d’elles est vide (n’a aucune géométrie).
• Duplicate vertex : la géométrie a deux sommets ou plus qui ont des coordonnées identiques.
• Mismatched attributes : la coordonnée Z ou M de l’extrémité d’un segment de ligne ne correspond pas à la coordonnée Z ou M de l’extrémité coïncidente sur le segment suivant.
• Discontinuous parts : une des parties de la géométrie est composée de parties déconnectées ou discontinues.
• Empty Z values : la géométrie présente un ou plusieurs sommets incluant une valeur Z vide (NaN, par exemple).
• Bad envelope : l’enveloppe ne correspond pas à l’étendue des coordonnées de la géométrie.
• Bad dataset extent : l’étendue du jeu de données ne contient pas toutes les entités.

Satisfaits de notre test, nous allons charger ce shape dans une base Spatialite. Remarquez que ce serait la même chose dans une base PostGis, les outils SQL de validation étant exactement les mêmes. Dans le prochain article, nous allons utiliser Spatialite car vous n’avez pas besoin d’installer PostGres ni rien de particulier pour le faire, si vous disposez d’ArcGis ou de QGis.

Si cet article vous a intéressé et que vous pensez qu'il pourrait bénéficier à d'autres personnes, n'hésitez pas à le partager sur vos réseaux sociaux en utilisant les boutons ci-dessous. Votre partage est apprécié !

Atilio Francois