Un pilote : Orléans Métropole
Cette sous-partie explique le processus de mise en place du prototype de l'algorithme. d'audit.
La situation d'Orléans
La métropole d'Orléans dispose d'un jeu de données de stationnements vélo assez dense. Il est mis en Open Data et recense 626 stationnements. De même, OpenStreetMap recense à cette date 402 places, ce qui fait d'Orléans Métropole un très bon terrain d'expérimentation pour l'audit de données.
L'algorithme d'audit
Le choix d'un algorithme en langage Python s'impose en raison du traitement possible directement sur des tableurs Excel.
L'objectif est concaténer les lignes dont les coordonnées de longitude et latitude ont une valeur proche (plus ou moins à 15 mètres de différence en valeur). Ainsi, si une ligne (un stationnement) avec des coodonnées de longitude et latitude dans le jeu de données de la collectivité rencontre une ligne similaire dans le jeu de données OpenStreetMap, les deux lignes se compléteront automatiquement.
Ci-dessous, les versions expérimentales de l'algorithme crée à partir du jeu de données officielles de la métropole d'Orléans, et du jeu de données OpenStreetMap. Des commentaires figurent sur l'algorithme pour expliquer les démarches.
Algorithme intégrant uniquement les données optimisées
Le programme sur Python a la capacité de travailler sur des jeux de données en ligne, à l'avenir, il sera possible de réaliser l'audit de données directement via les données disponibles sur transport.data.gouv.
Algorithme intégrant les données optimisées et les données ne pouvant pas être croisées
Un second algorithme a été pensé lors de la phase de test. Celui-ci permet de conserver les données de source OpenStreetMap ou officielle, ne présentant pas de cohérence l'une avec l'autre. Ainsi, la concaténation s'opère mais ne permet pas de compléter toutes les lignes. L'algorithme ainsi que le fichier obtenu se trouvent ci dessous
Les points bloquants pour la réplicabilité
Les colonnes des fichiers du jeu de données des collectivités territoriales ne suivent pas le même format donc l’audit est difficilement réplicable en ce sens. Il est cependant possible de créer un dictionnaire de valeurs ou une commande de changement automatique de nom de colonnes. Par exemple : mis à jour, date, date d’ajout, horodateur, etc ont plus ou moins le même objectif. Le dictionnaire transformerait ces mots en « Date », par référence à la colonne du fichier national.
On ne garde que les points d’une distance inférieure à 15 mètres, l’approximation permet d'éliminer les doublons. Cependant cette valeur ne permet pas de réunir tous les doublons. Le curseur de cette distance minimale est à faire varier en fonction des spécificités de la donnée. Le point de tension est de ne pas trop l'augmenter pour éviter d'approximer des points qui ne doivent pas l'être, ni de trop le diminuer au risque de conserver de nombreux doublons.
Il n'est pas possible de garder la source de la donnée (si elle vient d'OpenStreetMap ou de la colectivité) puisque c’est la ligne obtenue par le produit des deux précédentes.
Le programme actuel n’intègre pas encore la prise en compte des données n’étant présente que sur OpenStreetMap ou que sur le jeu de données de la collectivité territoriale.
Last updated