L'open data concernant les choses situées géographiquement est une mine d'or d'informations mal foutues. Les transformer en vue de les comparer à ce qui existe dans OpenStreetMap est un travail qui a été réalisé de plusieurs façons par bien des personnes différentes.
Aussi je me devais de réaliser une autre façon de faire cela en me concentrant sur des données au format Geojson. Ainsi est né le projet Wololo. L'idée est d'avoir quelques scripts qui vont prendre un certain jeu de données et y appliquer une configuration de conversion en ignorant les données qui ne rentrent dans aucune partie du convertisseur pour en sortir un autre fichier geojson que l'on peut ensuite examiner dans JOSM ou dans d'autres outils d'analyse.
https://forge.chapril.org/tykayn/wololo
Vous pouvez par exemple voir ce que cela donne sur le jeu de données Data Gouv des bornes de recharge pour véhicules électriques qui contient une cinquantaine de propriétés différentes:
git clone https://forge.chapril.org/tykayn/wololo
cd wololo
npm install
make irveLe makefile permet de lancer des scripts prédéfinis sur le point d'entrée principal du projet, du Nodejs écrit en TypeScript à qui on donne un fichier à convertir et une configuration de conversion.
ts-node convert_to_osm_tags.tsVous avez le fichier geojson qui a suivi les conversions selon le Mapper IRVE, et celui ci contient des tags OpenStreetMap. Ça se passe par ici: https://forge.chapril.org/tykayn/wololo/src/branch/main/mappings/converters/configIRVE.ts
Un petit exemple de la partie tags
Lorsqu'une feature du Geojson d'origine contient des informations sur plusieurs points de charge, on fait une feature de station de recharge (amenity=chargingstation), et si il n'y en a qu'un seul, on un fait une feature de point de charge (amenity=chargingpoint). Les autres propriétés de la feature sont ajoutées selon certaines conditions de clés et de valeurs, puis éventuellement formatées selon les standards déterminés par le Wiki d'OpenStreetMap comme par exemple pour les puissance en kW ou les numéros de téléphone. Les travaux d'intégration des données ouvertes sont documentées dans le wiki OSM, ici par exemple pour les bornes de recharge: https://wiki.openstreetmap.org/wiki/France/data.gouv.fr/Bornes_de_Recharge_pour_V%C3%A9hicules_%C3%89lectriques Ce qui permet de savoir comment convertir les propriétés de l'open data.
J'ai aussi ajouté des tags wikidata concernant quelques opérateurs de stations de recharge.
Faire une conversion peut être assez difficile car les producteurs de données sont plus de 3000 et ont chacun les bras cassés d'une façon différente, ce qui est très courant dans l'open data en général. Comme dit l'adage, garbage in, garbage out: on ne peut faire de bonnes conversions que si les données d'entrée sont bonnes. https://fr.wikipedia.org/wiki/GIGO
Pour limiter cela, des filtres sont possibles si on change le fichier de configuration afin de tester des résultats sur des plus petits ensembles de données, et le convertisseur informe de la présence de filtres activés lors de l'exécution du script principal.
Conversion de clé
Dans un Mapper, c'est la partie qui s'occupe de définir comment on convertit les propriétés de chaque Feature du Geojson:
const MappingIRVE: MappingConfigType = {
tags: {
nbre_pdc: 'capacity',
siren_amenageur: 'owner:ref:FR:SIREN',
date_mise_en_service: 'start_date',
nom_station: 'description',
// ... etc
}
}On convertit la clé "sirenamenageur" en "owner:ref:SIREN" et on garde la même valeur.
Conversion avec des transformations avancées
La configuration accepte aussi les objets JS pour définir quoi faire selon les valeurs. Ici pour la puissance on devrait avoir des kW, mais comme je disais avant, c'est rempli avec les pieds, on applique donc une fonction de conversion qui va se charger de deviner la puissance. La fonction n'est pas définie dans le Mappeur, mais dans le moteur de conversion qui reconnaîtra la clé socketoutputfindcorrespondances pour lancer une fonction sur les données de chaque Feature pour tenter de trouver une valeur correcte.
const MappingIRVE: MappingConfigType = {
tags: {
puissance_nominale: {
key_converted: 'charging_station:output',
socket_output_find_correspondances: true,
}
// ... etc
}
}La fonction qui permet de trouver la puissance des sockets est détaillée dans ce fichier:
Dans les exemples suivants je masquerai la partie autour des exemples se trouvant dans la partie tags
Valeurs conditionnelles
L'accessibilité a été décrite de plusieurs façons, notamment avec la notion de "réservé aux PMR" que je n'ai pas retrouvé dans le wiki d'OSM. J'ai donc mis une conversion de valeur conditionnelle vers "wheelchair=yes" dans le cas de plusieurs valeurs particulières pour la propriété "accessibilitepmr".
accessibilite_pmr: {
key_converted: "wheelchair",
conditional_values: {
"Accessibilité inconnue": {
ignore_this_data: true, // ne pas ajouter de tag wheelchair si la valeur est égale à Accessibilité inconnue.
},
"Accessible mais non réservé PMR": {
value_converted: "yes"
},
"Réservé PMR": {
value_converted: "yes"
},
"Non accessible": {
value_converted: "no"
},Inversion de valeur booléenne
Quand l'open data demande si une station est gratuite à l'usage et que l'on a une clé openstreetmap qui dit oui quand ce n'est pas gratuit, il faut inverser la valeur du oui de l'open data.
/**
* l'info de gratuité a été mal renseignée par les opérateurs, ils mettent TRÈS souvent que c'est gratuit alors que ce n'est pas vrai.
*/
gratuit: {
key_converted: 'fee',
convert_to_boolean_value: true,
invert_boolean_value: true,
},Suppression de clé originale
stationdeuxroues est une propriété qui n'a pas de tag dans OSM, mais on veut ajouter trois autres tags quand on la croise et qu'elle vaut "vrai". J'ai donc dû faire en sorte de supprimer une clé et ajouter des tags de façon conditionnelle. En gardant la logique précédente on a donc ceci:
station_deux_roues: {
remove_original_key: true,
conditional_values: {
// ajout de trois tags si la valeur est yes
"yes": {
tags_to_add: [
{ bicycle: "yes" },
{ scooter: "yes" },
{ motorcar: "no" },
]
}
}
},Ces quelques règles simples de transformations à appliquer aux features permettent d'avoir une description lisible et des fonctions réutilisables d'un jeu de données à un autre.
Certaines clés du Mappeur permettent de ne pas avoir à décrire quoi faire pour toutes les clés où les opérateurs ont eu la flemme de remplir les données ou d'apprendre à écrire des accents. Exemple ici, où on ignore les Features si la valeur est "Non renseigne":
https://forge.chapril.org/tykayn/wololo/src/branch/main/mappings/converters/configRouen_PAV.ts
tags_to_ignore_if_value_is: ['Non renseigne'],Nous avons aussi la possibilité de toujours mettre un certain tag et une certaine valeur à toutes les Features que l'on ajoute à notre conversion. Pour les points d'apport volontaire décrivant ds conteneurs, on voudra toujours avoir ces deux tags à minimum: amenity=recycling et recyclingtype=container
default_properties_of_point: {
'amenity': 'recycling',
'recycling_type': 'container',
},Comment ajouter un convertisseur de jeu de données:
Une documentation détaille les étapes pour créer votre Mappeur et l'intégrer au projet. https://forge.chapril.org/tykayn/wololo/src/branch/main/docs/ajout_jeu_de_donn%C3%A9es.md
Pour d'avantage de flemme, un script python permet de vous proposer des choses à mettre dans la partie tag d'un Mappeur sans avoir à aller chercher toutes les propriétés possibles des features à la mano.
python propose_mapping_from_data.py etalab_data/musées/fr.geojsonLes propositions restent en console et ne sont pas écrites dans un fichier de Mappeur, vous n'avez plus qu'a copier et faire le tri dans un futur Mappeur. Cela vous permettra aussi de détecter des propriétés similaires si vous avez affaire à des champions des bras cassés de l'open data.
Le projet Wololo permet aussi d'appliquer des conversions sur des geojson issus d'Osmose.
https://osmose.openstreetmap.fr
Extraction de données depuis OpenStreetMap
On peut faire des extractions thématiques sur des données OpenStreetMap un peu à la façon Geodatamine. https://geodatamine.fr/
Ça se passe dans les extractors, ce sont des scripts bash qui utilisent une requête overpass et une fonction bash pour faire un geojson d'export, que l'on stocke dans osmoutput.
https://forge.chapril.org/tykayn/wololo/src/branch/main/mappings/extractors/planning_familiaux.sh
La fonction extractfromosm : https://forge.chapril.org/tykayn/wololo/src/branch/main/update_scripts/functions.sh
On peut lancer tous les extracteurs à la suite avec ce script de mise à jour pour ensuite travailler sur des données fraîches.
bash update_scripts/run_all_extractors.shPour ne pas blinder l'espace disque de la forge logicielle, les extractions et les fichiers geojson transformés ne sont pas versionnés, merci au Gitignore.
Bonnes conversions de données ouvertes!
