Par-ci par-là

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.

Chères données

2024-01-21T20:04:00+01:00

Sommaire

Introduction
L’importance des données
L’exemple de la cartographie interractive
En conclusion
Notes

Introduction

retourner au sommaire

Cette semaine, j’ai présenté mes activités professionnelles à un stagiaire de seconde. Classique, me direz-vous : je suis bien d’accord. Néanmoins, je me dis que ce que je lui apprends alors, vous l’ignorez peut-être, vous aussi. Dans le doute, je reprends pour vous.

Pour le contexte, je travaille dans une DSI (Direction des Systèmes d’Information), et j’y suis en charge de l’un des systèmes d’information (SI). Mon boulot a cela de particulier que je gère et j’utilise ce SI (contrairement à certains de mes collègues qui gèrent mais n’utilisent pas leurs applications).

L’importance des données

retourner au sommaire

Pour commencer, un SI, c’est quoi ? C’est, en gros tout ce qu’il faut pour servir de l’information. C’est, ensemble, un ou plusieurs logiciels, le matériel sur lequel ils tournent, les humains qui l’administrent et… l’information (les données). Pour arriver à son objectif, il collecte des informations, les traite si besoin, les stocke si besoin, et les diffuse.

Dans le système que je gère, une partie du traitement réalisée par l’humain (ou sous son contrôle étroit). Je ne parle pas de la saisie, que j’assimile à la collecte, mais bien du traitement. Je présente souvent mon travail par la finalité de ce SI (car je l’utilise), ce qui correspond à la diffusion de l’information. La réalité, c’est que la très grande majorité de mon temps est dédié à la collecte et au traitement.

Beaucoup de ces traitements sont automatisables (et j’en automatise beaucoup). La raison principale pour laquelle on a toujours besoin de quelqu’un, et on en aura peut-être besoin longtemps, c’est que le besoin exprimé par les utilisateurs (moi inclus) concerna toujours l’information diffusée. À partir de cette seule partie finale du travail, il faut concevoir et mettre en place tout le reste du système. Et n’oublions pas les procédures de maintenance.

Pour faire une analogie avec un autre domaine, c’est comme pour le train : vous, utilisateur, souhaitez aller d’un point A à un point B, le plus rapidement possible. Acquérir le foncier, réaliser les ouvrages, mettre en place l’infrastructure ferroviaire et les gares, exploiter le réseau, acheter et maintenir le matériel roulant, le conduire : vous ne le demandez même pas. OK, ce n’est pas vous qui demandez ; mais même l’autorité en charge des transports ne demandera finalement qu’une fréquence de passage entre tels et tels lieux (et une accessibilité, un confort, etc.).

L’exemple de la cartographie interractive

retourner au sommaire

Revenons à nos SI. Voilà une illustration de la vie de tous les jours pour un certain nombre d’entre vous : si vous avez l’habitude d’utiliser des cartes interactives, par exemple celle proposée par votre moteur de recherche, vous y voyez de nombreuses choses, en particulier des traits, des aplats et des symboles de différentes couleurs. Mais quelles données sont derrière tout ça ? Quelle est leur complexité ?

Dans OpenStreetMap, nous avons accès à ces données et pouvons les consulter (et les modifier). Si vous ne l’avez pas encore remarqué, il existe un outil « Interroger les objets » (c’est une flèche avec un point d’interrogation, en bas des outils proposés à droite de l’écran).

Pour vous en rendre compte par vous-même, vous pouvez utiliser cet outil et observer tous les objets derrière la carte, ainsi que les données associées à chacun d’entre eux. Vous trouverez des objets administratifs, les zonages notamment (commune, canton, etc.), ainsi que les voies, le mobilier urbain, les bâtiments, les boutiques et administrations.

Chacun de ces objets a des attributs qui dépendent notamment de son type. Le revêtement peut être précisé pour une voie mais il ne le sera jamais pour une commune. Les liens entre les objets sont également indiqués : les nœuds partagés entre plusieurs chemins, les relations entre objets (par exemple, entre une rue et les numéros de cette rue). Cet ensemble est vraiment complexe, d’où l’intérêt d’avoir quelqu’un derrière tout ça.

Je vous invite à parcourir OpenStreetMap à la recherche d’un escalier ; observez alors les informations le concernant. Si vous n’en avez pas dans la carte à proximité ou que vous avez des difficultés avec la navigation dans la carte, en voici un exemple d’escalier sur OpenStreetMap (pour les connexions limitées, vous pouvez consulter les fiches xml associées [1]).

L’objet représentant un escalier (« steps » signifie « marches » en anglais) est connecté de chaque côté à un autre élément (souvent de type chemin piéton). Cette connexion se fait par le biais d’un nœud, qu’il partage à son extrémité avec cet élément. C’est indispensable pour calculer des itinéraires. Car l’information que c’est un escalier, si elle vous peut être utile pour se repérer sur une carte, peut aussi être exploitée de manière non graphique dans des calculs. C’est d’ailleurs utilisé comme ça dans les calculs d’itinéraire qui tiennent compte de l’accessibilité, qui devraient bientôt être généralisés (et s’ils ne le sont pas encore, c’est parce que les données ne sont pas disponibles partout).

Je vous invite, si vous en avez la curiosité, à parcourir le modèle de données [2] du standard CNIG d’accessibilité du cheminement en voirie, partie 3.2 (à partir de la page 17) de la dernière version du standard à cette date. Les escaliers y sont représentés par un type spécifique de « tronçon de cheminement ». Ils sont situés entre 2 nœuds, lesquels sont alors également les extrémités d’autres cheminement, potentiellement de type circulation (ou bien un autre escalier, une rampe, etc.). Ça vous rappelle quelque chose ? En effet, le modèle de données est proche de celui d’OpenStreetMap : il y a d’ailleurs un outil qui convertit les données d’OpenStreetMap vers ce standard.

En conclusion

retourner au sommaire

J’ai illustré ici l’importance des données dans le monde des SI, qu’on ne perçoit pas toujours en tant qu’utilisateur. Et pourtant, si le mot « système » est important dans « Systèmes d’Information », il ne faut pas oublier le mot « information » !

Nous n’avons fait qu’effleurer le sujet des données. Il reste tant de choses à dire toutes les conditions pour qu’elle soit utilisable. Ainsi, les prochains billets de la thématique des données pourront porter sur leur besoin :

de structuration (et donc au préalable de modélisation),
de qualité, ce qui va avec son évaluation et sa qualification,
de documentation, au travers des métadonnées,
de standardisation (qui doit prendre en compte l’ensemble des points précédents), préalable à une diffusion, en open data ou non,
de confidentialité et de gestion des privilèges.

Comme vous le voyez, le sujet est vaste !

J’espère que la lecture de ce billet vous a été plaisante et enrichissante. N’hésitez pas à me faire des retours ! Pour notre prochain billet, nous pourrons aborder une nouvelle thématique et introduire un peu de code.

namori

PS : Je suis désolé si vous vous attendiez à ce que je parle de vol de données personnelles, ou encore du coût d’acquisition des données… Je n’ai pas trouvé meilleur titre, même s’il manque certainement de précision !

Notes

retourner au sommaire

[1]

Les fiches XML suivantes représentent les éléments de cet exemple :

Vous retrouverez bien le nœud référence 3696172618 dans l’escalier et dans le deuxième objet de type way (signifiant « chemin » en anglais).

[2]

Le modèle de données, c’est la représentation qui permet de concevoir la structure dans laquelle on va pouvoir sauvegarder les données, les traiter et les diffuser. La structure des données est souvent appelée elle-même modèle de données.

Les données de chaque type peuvent par exemple être réuni dans une table et des relations peuvent être faites entre des objets de plusieurs tables, si le modèle le prévoit. Ce modèle est adapté aux bases de données dites structurées relationnelles. Les modèles sont cruciaux pour les bases de données non structurées, car la structure de la base de données est alors moins explicite et sa compréhension est parfois très délicate sans documentation.

Bienvenue

2024-01-06T12:25:00+01:00

Sommaire

C’est quoi, Par-ci par-là ?
C’est qui, namori ?
Il y aura quoi, ici (et là) ?
Aparté sur ma vie professionnelle
La vie du blog

Salut et bienvenue sur Par-ci par-là !

C’est quoi, Par-ci par-là ?

retourner au sommaire

Par-ci par-là, c’est ce blog. Pourquoi ce nom ? Parce que je cherchais un nom à consonance géographique, mais pas trop barbant. Par-ci par-là, c’est du langage courant, c’est facile à retenir.

Par-ci par-là, avec ou sans virgule ? J’essaie de toujours l’écrire sans, par simplicité et par cohérence, mais elle risque d’apparaître par-ci, par-là !

Pour la petite histoire, j’avais pensé à un nom encore plus court, comme là.xyz, mais par commodité, j’ai préféré éviter les accents dans le nom de domaine. Ce sera donc par-ci.fr. En .fr, finalement, pour la simplicité juridique et administrative (pas très envie de régler un éventuel conflit aux US). En plus, c’est pas trop cher.

C’est qui, namori ?

retourner au sommaire

C’est moi, namori. Vous m’avez peut-être déjà vu, sur les RS ou sur IRC. Ou pas. Dans tous les cas, vous êtes ici et vous êtes les bienvenus. De mon côté, je ne suis ni jeune ni vieux, peut-être 40 un de ces jours. Je vis quelque part en France, à un endroit qui est plutôt pratique pour être visible et compté quand on manifeste ses opinions dans la rue (oui, Paris) (Paris, c’est une notion qui dépasse la commune ou le département).

Il y aura quoi, ici (et là) ?

retourner au sommaire

On parlera donc, ici, de geekeries et de géographie. De géomatique, un peu. De mes déboires personnels et professionnels contre la machine, son code et ses utilisateurs. Le tout sous couvert d’anonymat quand nécessaire, ou de pseudonymat avec autorisation.

On ne parlera pas : de mes éventuels ennuis de santé, de famille, d’amitié, d’amour, de sexualité et autres. On parlera par contre de vie associative, de vie professionnelle (avec certaines limites, voir ci-dessous), de programmes et de programmation, et de politique quand c’est en rapport avec l’un des éléments précédents.

Il est possible que des bouts de code fassent leur apparition. Du code exemplaire (à mes yeux) ou des contre-exemples, parfois même ici de mon corpus. Du code sur la géographie ou du code comme ça, un regard sur une repo ouverte, etc. Si vous n’êtes pas à l’aise avec le code, aucun problème ; j’essaierai d’inclure le mot-clé « code » systématiquement pour que vous puissiez filtrer les billets concernés.

Tout au plus, je ferai peut-être un jour des statistiques de visite, agglomérées par jour et sans discriminer l’origine. Pour l’instant, visitez sans prise de tête : personne d’autre que votre FAI ne le saura (et peut-être Google si vous utilisez son navigateur : ne le faites pas) (et optez pour un FAI associatif).

Aparté sur ma vie professionnelle

retourner au sommaire

J’ai longtemps essayé de découpler ma vie personnelle et professionnelle. Je vous le dis tout de suite : c’est fini, tout ça ! Non pas que ça m’apporte grand chose, professionnellement ; ce serait plutôt l’inverse (c’est pour arrêter de me prendre la tête à tout dissocier). Je travaille dans le public, et les devoirs d’un agent public sont assez contraignants. C’est pourquoi je ne donnerai pas le nom de mon employeur. Peut-être pourrez-vous le deviner : si vous y parvenez, je vous demanderai de le garder pour vous. C’est juste plus simple, ça évite qu’un moteur de recherche associe mes écrits à son nom. Ça n’empêchera pas mon employeur de me chercher des noises si je contreviens à mes obligations.

Je suis : administrateur d’une application, avec ses utilisateurs et leurs données (et celles de l’administration), mais aussi un peu data manager. À ce titre, j’évalue, je documente (chères métadonnées), j’améliore, je traite les données. Depuis quelques années, Python est mon ami. Par le passé, j’ai appris avec d’autres langages, j’en ai utilisé d’autres, mais je ne touche plus qu’au Python… ou presque. Presque, car je suis administrateur de mon application, qui a une partie web dans laquelle je dois bricoler un peu : miam, des JSP (non, c’est une blague, fuyez ces objets du Démon).

La vie du blog

retourner au sommaire

Nous allons tenter un rendez-vous toutes les deux semaines. Comme ça risque de ne pas être toujours précis (je préfère l’espace au temps), je vous invite à vous abonner au flux RSS (Atom) pour être averti⋅e de tout nouveau billet.