Données géographiques : avant de manipuler les géométries

2024-02-04T20:11:00+01:00

Introduction
Le problème
La solution
Première amélioration : le fenêtrage
Deuxième amélioration : la rotation du référentiel
En conclusion
Notes

Introduction

Salut ! Je pensais vous montrer dès aujourd’hui quelques petites manipulations sur des données géographiques. En cherchant un exemple, j’ai repensé à un projet que j’avais commencé il y a quelques années, et ça m’a donné une autre idée. On ne va pas faire de code tout de suite, on va d’abord s’échauffer les neurones.

Remarque : si vous êtes spécialiste SIG, ou si vous touchez un peu aux données géométriques (par exemple pour du rendu 3D), vous n’apprendrez pas grand-chose (voire rien du tout) ! Je vous promets de faire quelque chose pour vous un de ces jours. À bientôt 😉️

Le problème

retourner au sommaire

Il faut savoir qu’on n’a pas toujours envie de réinventer le fil à couper le poil dans la main, et qu’on utilise donc beaucoup d’outils clé sur étagère qui font généralement à peu près ce qu’on veut (s’ils fonctionnent bien).

Par exemple :: On a l’emprise du département dans un fichier et des limites de canton dans un autre ; un merveilleux outil va alors découper le territoire et nous fournir les cantons, non plus en limites linéaires, mais en zones surfaciques, ce qui permettra de les utiliser dans des requêtes spatiales ou pour de la représentation cartographique. Honnêtement, pas trop besoin de s’y connaître pour l’opération, même si trouver le bon outil prend plus de temps quand on n’a pas l’habitude.

Notez les nuances dans le paragraphe précédent : parfois, on préfère créer nous-même notre outil, ou bien on doit le faire car il n’existe pas (du moins, pas à notre connaissance). On a encore potentiellement le choix :

on peut préparer les données avec des outils génériques, faire une opération minime « à la main », puis revenir à des outils génériques pour finir les traitements, enregistrer, exporter, etc.
ou bien on peut tout faire à la main : on lit les données, on en génère des données formatées selon l’outil de notre langage, on fait tout, et on exporte (ou on met à jour les quelques éléments modifiés) à la fin.

Dans le premier cas, l’opération est généralement peu gourmande, et on peut se passer d’optimisation (à moins de la faire tourner en temps réel ou même en production à la demande sur le serveur). Dans le deuxième cas, ou si on tombe dans les cas particuliers de la parenthèse, on doit toujours optimiser un minimum. Si on ne le fait pas, notre nouvel outil va bien marcher sur le fichier test avec 10 éléments, puis une fois lancé sur la table de données réelles, sur tout le département ou tout le pays, vous êtes bon pour attendre un loooong moment. C’est le problème avec les données géographiques : la géométrie, c’est facilement coûteux en temps de calcul et, souvent, les données sont lourdes.

La solution

retourner au sommaire

Donc que fait-on ? Le plus simple, c’est d’éviter au maximum de calculer pour rien.

Dans mon exemple (que je ne détaillerai pas ici), je dois évaluer la proximité deux-à-deux entre des éléments linéaires de deux sources distinctes avant d’appliquer un traitement aux couples ainsi formés. J’ai fait ce qui est fait dans toutes les fonctions des SIG (systèmes d’information géographique, comme QGIS) travaillant sur les éléments selon leur proximité, j’ai commencé par évaluer si je peux ne pas faire le calcul pour chaque élément.

Pour ça, calculons les « bounding boxes », ou boîtes englobantes, de chaque élément : nous retenons leurs coordonnées minimale et maximale sur chaque axe. Si je souhaite exclure de tout calcul les éléments distants de plus de 50 m entre eux, j’ajoute une marge de 50 m autour des boîtes de l’une des sources (ou 25 m de toutes les boîtes). Si les boîtes englobantes de deux éléments ne s’intersectent pas, on s’arrête là. Évaluer cette condition revient à évaluer quelques inégalités, et c’est très rapide par rapport au calcul de distance complet : sur tout un jeu de données, on s’épargne un temps fou. Bien sûr, on n’a pas calculé une distance précise, donc quand il y a intersection des boîtes, il faut vérifier un peu la disposition des éléments entre eux.

J’ai fait ça, et c’était toujours (un peu) trop lent. Avant même d’optimiser les calculs suivants, j’ai amélioré encore ce processus de sélection, parce que, contrairement aux outils génériques, je peux tenir compte de mes connaissances sur les données qui seront utilisées par l’outil. En l’occurrence, ce sont des tronçons, découpés à chaque intersection, dans un réseau relativement dense donc avec des longueurs toujours petites par rapport au dimension du territoire.

J’ai eu plusieurs idées d’amélioration sur mesure.

Première amélioration : le fenêtrage

retourner au sommaire

Compte tenu de ma connaissance des données, et je travaille alors par fenêtrage : on ne comparera des éléments que s’ils sont tous deux dans la même fenêtre. Je calcule la longueur maximale des tronçons de chacun des jeux de données, et ma fenêtre sera dimensionnée en fonction du plus petit des maxima des longueurs des deux jeux de données. Après, je traite, position de la fenêtre après position : du premier jeu de données, je retire les données déjà sélectionnées et traitées ; dans le deuxième jeu de données, je les remets à chaque fois en jeu, mais je calcule une seule fois leur position par rapport à la fenêtre après chaque déplacement de celle-ci.

Au niveau algorithmique, en considérant que l’on a respectivement m éléments dans le premier jeu de données et n dans le deuxième, l’idée est ici de se rapprocher d’un calcul de complexité linéaire en O(m+n) plutôt que quadratique en O(m×n).

Bon, en y regardant un peu plus les temps de calcul de mon premier essai, la vraie raison de la lenteur du programme, ce n’est pas les comparaisons des boîtes. En fait, cette étape est tellement rapide que je n’y gagnerais quasiment rien à l’optimiser. J’ai alors laissé tombé de côté cette idée car j’en avais une autre en tête, potentiellement bien plus efficace. En plus, le fenêtre, ça pourrait améliorer un peu le temps de calcul avec un réseau dense, donc pour un territoire urbain ; mais pour un territoire rural, le gain serait encore plus réduit (et tant qu’à faire, si ce n’est pas un gros effort, autant permettre d’utiliser l’outil pour tout type de territoire).

On la met de côté dans notre cas actuel, mais gardez l’idée du fenêtrage dans un coin de la tête, elle peut parfois être très efficace !

Deuxième amélioration : la rotation du référentiel

retourner au sommaire

Mon vrai problème, c’est que les boîtes ne sont pas adaptées. Reprenons quelques paragraphes plus haut: j’ai simplement utilisé les coordonnées dans le système de référence des jeux de données. Du coup, si une ligne est dirigée selon un axe nord-ouest sud-est, je fais un carré, traversé en diagonale par la ligne, et dont 2 des coins sont situés à une distance de la moitié de la longueur de la ligne. C’est beaucoup trop englobant ! Et c’est très fréquent, d’autant plus que mes tronçons ne sont pas franchement sinueux et ne remplissent pas beaucoup les boîtes.

La solution que j’ai appliquée, c’est de calculer des boîtes dans d’autres référentiels, avec une rotation depuis le référentiel initial [1] (à 30° et 60°, par exemple). On augmente un peu le temps de calcul pour les évaluations d’intersection (on prend un peu de temps de préparation initiale puis on peut faire plusieurs évaluations pour un seul couple de lignes), mais pour un réel gain de temps ensuite.

Dans la suite du programme, je passais directement à des calculs plus compliqués et longs, qui servaient à la fois à valider le couple et dont les résultats étaient utiles ensuite pour d’autres calculs, le cas échéant : distance de Hausdorff et comparaison des orientations locales (sur leur partie commune après projection de l’une sur l’autre). Pour éviter encore quelques uns de ces calculs, j’ai ajouté une étape intermédiaire : calcul de la distance du centre de la première ligne à la seconde. Avec la technique des boîtes dans 3 référentiels différents, c’était un peu du bonus ; j’y ai quand même gagné entre 10 et 15 % de cas où j’évite le calcul de la distance de Hausdorff. Là, la pertinence doit être évaluée en fonction des données : avec des lignes simples, la distance est calculée très vite, et cet ajout fait perdre du temps, mais avec des lignes complexes (contenant beaucoup de sommets), on peut être gagnant. J’ai donc laissé cette étape en option dans l’outil.

En conclusion

retourner au sommaire

Bien connaître ses données : c’est important.

J’ai parlé d’opérations préalables aux calculs, au sein de l’outil de traitement, mais il y a autre chose à faire avant même de créer l’outil (ou de le lancer) : il faut préparer ses données. Si on n’a pas besoin d’une précision décimétrique ou plus précise, on peut certainement simplifier les géométries (ce qui fera moins de sommets pour les lignes et les contours des polygones) et on y gagnera sur tous les calculs à venir, ainsi que sur le stockage et sur la réactivité de l’affichage dans une carte dynamique. J’ai pu travailler sur des algorithmes de simplification au travail, et on en parlera peut-être un jour.

À noter que j’ai commencé mes études par une licence ès mathématiques, et ça m’aide. Si vous n’avez pas compris ce qu’était la « distance de Hausdorff », ce n’est pas grave (mais je vous invite à chercher). On peut se passer de ce genre de subtilités et arriver à pas mal de choses quand même. (D’ailleurs, j’utilise plus souvent la semi-distance de Hausdorff, qui n’est pas une distance, parce que les relations sont rarement symétriques et que j’ai rarement besoin d’une vraie distance.)

J’ai surtout fait de la trigonométrie au collège et c’est très souvent utile dans un travail où on fait de la géométrie. Remercions nos enseignants qui ont supporté nos tempéraments de l’époque et qui nous ont tant appris !

A bientôt

Notes

retourner au sommaire

[1]	Pour l’anecdote, depuis le début, sans le dire, je travaillais dans un référentiel local (par translation) pour éviter de tripatouiller des gros nombres pour rien.

Par-ci par-là - géotraitements

Données géographiques : avant de manipuler les géométries

Introduction

Le problème

La solution

Première amélioration : le fenêtrage

Deuxième amélioration : la rotation du référentiel

En conclusion

Notes