Et la géométrie dans les autres SIG Open Source ? Comparaisons avec GRASS et SAGA#

Date de publication initiale : 1 août 2024

Suite de la série sur la gestion de la géométrie dans les logiciels SIG. Après avoir constaté que les calculs n'étaient pas bons et avoir soulevé le capot de QGIS pour voir comment GEOS se débrouillait. Le moins que le l'on puisse dire c'est que cela nous laisse circonspect, sinon perplexes : GEOS, et donc QGIS, donnent le même résultat mais il n'est pas exactement celui attendu.

Il est temps d'aller voir ailleurs et de revenir à nos premières amours : GRASS et SAGA.

Cet article est la troisième partie de la série d'été sur la gestion de la géométrie dans les SIG.

Le dossier 2 : QGIS et GEOS

Commenter cet article

GRASS : Le vénérable du SIG#

Comme j'ai déjà trahi les petits secrets internes, Julien m'avait demandé proposé de faire une version actualisée de cet article. J'ai procrastiné volontairement attendu jusqu'en 2024, pour fêter les 10 ans de l'article. Mais, ce n'est pas dans celui-là que je le ferai. Néanmoins, on va bien évidemment utiliser GRASS pour tester si notre cas est différent avec GRASS.

Pour notre expérience avec GRASS, il faudra faire quelques manipulations, car on n'a pas la possibilité de faire directement nos calculs avec le WKB. Afin de simplifier la reproductibilité aux lecteurs, j'ai ajouté des modèles de traitements dans le projet ; ils sont également disponibles individuellement sur mon GitHub.

Utilisation de v.overlay#

Dans GRASS, v.overlay permet de réaliser des opérations… d'overlay - superposition en français - (intersection, union, différence) entre deux couches vectorielles. Il nécessite deux vecteurs, dont le second B, doit être de type « area » (polygone en langage OGC). Si le vecteur n'est pas un polygone, il nécessite une conversion avant d'effectuer le traitement ; ce qui est notre cas.

La couche base est une polyligne fermée, elle sera utilisée pour être convertie en polygone. Pour les puristes, on regardera que les coordonnées du WKB sont bien identiques entre le linestring et le (multi)polygone. Il y a plusieurs façons de procéder, mais, pour rendre accessible à tous, nous allons utiliser GRASS via QGIS, j'utilise les premières conversions dans QGIS ; ensuite, nous utiliserons uniquement les outils de GRASS.

Notre algorithme va convertir la base en polygone, puis effectuer l'opération d'overlay. Pour calculer l'intersection entre line et base_poly, on extrait les points d'intersections que l'on peut afficher dans QGIS. On retrouve le même résultat, ici, je passe les détails, mais on retrouve bien nos WKB :

• 0101000000a899efc8c83c3e4175e5698166d55341
• 0101000000b5ebdd9e8f3c3e416bf8515379d55341

Pour le prédicat intersects, nous allons continuer d'utiliser GRASS avec la commande v.select avec l'opération intersects. Encore false… du moins, les points retournés sont ceux des extrémités de line et aucun point pour base ou base_poly.

Le modèle est disponible ici.

C'est au moins rassurant, car derrière v.select avec l'opérateur intersects on utilise… GEOS. Il existe une autre façon de réaliser la sélection, mais je la garde pour la prochaine partie

SAGA : le Chevalier Oublié du SIG#

Si SAGA est le plus puissant des chevaliers du zodiaque, SAGA GIS est malheureusement bien souvent le chevalier oublié du SIG. Il possède certains traitements qui ne sont pas disponibles dans QGIS et peut également se révéler utile pour d'autres existants.

Depuis quelques versions, il n'est plus possible d'avoir les traitements de SAGA directement depuis QGIS. Il faut installer le plugin SAGA NG mais il a quelques limitations m'empêchant de l'utiliser pour l'article. Pour cette partie, je vais directement passer par l'interface de SAGA, notamment afin de visualiser le résultat.

Il est intéressant de comparer le résultat de SAGA avec GEOS/QGIS. En effet, les opérations d'overlay ne reposent pas sur GEOS, mais sur une autre bibliothèque dédiée ; pour ceux intéressés, j'y reviendrai dans la partie sur les algorithmes.

Comme pour les autres, nous allons réaliser les points d'intersection entre line et base, puis tester si ceux-ci intersectent les géométries d'origine et également, combien de lignes de test_line intersectent base.

Tout d'abord, SAGA, ne sait pas lire le GeoPackage. J'ai réalisé une conversion de nos couches dans ce bon vieux ShapeFile.

On charge ces fichiers dans l'interface de SAGA.

Nous affichons nos données. Rien de surprenant, on se retrouve avec nos deux géométries.

Première étape, vérifier le calcul d'intersection. Dans le vocabulaire de SAGA, l'intersection entre lignes s'appelle "Crossing". On exécute le traitement : Geoprocessing -> Shapes -> Lines -> Line Crossing

On retrouve bien nos deux points :

Je passe ici les étapes pour leurs récupérations, mais, les WKB sont bien les mêmes, à savoir :

• 0101000000b5ebdd9e8f3c3e416bf8515379d55341
• 0101000000a899efc8c83c3e4175e5698166d55341

L'algorithme de SAGA qui, rappelons-le, n'utilise pas GEOS retourne le même résultat. Très bien !

Sélection et intersection#

Maintenant, tentons de vérifier si les points intersectent, ou non, notre base. Pour cela, on utilise l'outil « sélection par localisation » : Geoprocessing -> Shapes -> Selection -> Selection by localisation.

Paf, erreur intéressante. Cela fonctionne seulement pour un point avec un polygone !

Dans notre expérience avec GRASS, on avait un problème identique. Nous allons donc tester avec base_poly :

Aucune sélection. Le message d'exécution nous l'indique bien (en Anglais) : "selected shapes: 0"

Même si l'on peut critiquer la méthode, car le dessin a été fait dans un autre contexte, QGIS/GEOS, on va tout de même tester la sélection des lignes :

On va reprendre notre exemple entre base et test_line.

20 sur 34, comme pour GEOS !

C'est normal d'une certaine façon. Cependant, le premier test avec crossing, nous montre également que le point d'intersection n'intersecte pas la géométrie d'origine, comme pour GEOS.

Et qu'en est-il avec les bases de données relationnelles ? C'est ce que nous verrons dans la prochaine partie avec Microsoft SQL Server, Oracle et PostGIS.

4 : les bases de données relationnelles

Auteur·ice#

Loïc Bartoletti#

Après un cursus en Histoire, je me suis orienté vers l'urbanisme sur l'aménagement des territoires.

J'ai travaillé pendant environ 10 ans dans une station touristique dans les Alpes, Megève, en tant qu'urbaniste puis responsable du bureau d'études et administrateur SIG.

Bidouilleur et partisan des solutions OpenSource, j'ai commencé à toucher à GRASS, puis QGIS et PostGIS. Au fil du temps j'ai contribué à ces logiciels, principalement pour migrer des outils DAO vers le SIG et je suis aujourd'hui commiter QGIS, PostGIS et FreeBSD où je m'occupe des paquets des outils OSGeo et plus si affinité.

Licence Beerware #

Ce contenu est sous licence Beerware (Révision 42).
Les médias d'illustration sont potentiellement soumis à d'autres conditions d'utilisation.

Commentaires