Introduction

Ce projet (la Dalle Météo) a été réalisé dans le cadre du Hackathon Météo France du 08 et 09 avril 2024.

Le lien vers le repo contenant le code et la présentation est : https://github.com/MaximePawlakFr/hackathon-meteo-team-tls

Problématique et proposition de valeur

A quelle problématique s’attaque notre projet ?

La difficulté constatée est d’explorer, de regrouper les données nécessaires, de gérer les différents formats disponibles. Il y a beaucoup de données météo, mais pour des cas "courants", la première étape de prise en main est vite décourageante.

Quelle est notre proposition de valeur ?

La proposition de valeur est de permettre de requêter les données ouvertes par Météo France très simplement, sans connaissance approfondie des modèles météo et de leurs formats de données.

En plus de faciliter l'accès, cela permet de récupérer les données qui nous intéressent, sans avoir à télécharger l'ensemble des archives éparpillées.

En plus d'économiser de la bande passante, cela réduit le temps entre l'idée et la réutilisation de ces données.

Solution

Description de la solution et de ses fonctionnalités

Notre application fournit une interface web simple qui permet de requêter des données météo dans un format humainement compréhensible JSON (ou CSV).

Il n’est plus besoin de regrouper des fichiers différents (département, archives) ou d’apprendre à exploiter chacun des formats (grib2, netCDF, geotiff...)

Un formulaire et la présence d'un LLM permet même de ne pas avoir à connaître le langage SQL.

Dans un premier temps, un service télécharge régulièrement les données météo depuis data.gouv.fr (via un cron job qui consomme l’API et vérifie si des nouvelles données sont disponibles). Ces données sont majoritairement aux formats .grib2 ou .csv.gz.

Ces données sont transformées au format parquet (via pandas, xarray ou gdal) puis téléverser (uploader) dans data.gouv.fr via leur API.

Il ne reste plus qu'à l'application web de consommer ces données.

Cela se passe notamment par l'intégration d'un outil très puissant : duckdb.

L'interface permet donc de créer la requête qui va consommer ces fichiers, puis de les visualiser.

Pour créer une requête SQL, il y a 3 méthodes :

• un formulaire web classique
• la requête SQL peut directement être rentrée
• un modèle LLM permet également de créer la requête SQL

Dans un premier temps, nous nous concentrons sur les données suivantes : AROME et les données des stations d’observations. Et nous ne gardons que les paramètres les plus courants : Pluie Vent, Température et Humidité.

Technologies utilisées

• App data : pandas/GDAL => files *.parquet
• App front : React, Cesium, DuckDB

Quel usage est fait des données ? Que nous permettent-elles de faire ?

Les données sont récupérées depuis data.gouv.fr et transformées en .parquet.

Une fois en parquet, elles sont plus facilement exploitables par notre application (grâce à DuckDB) et nous pouvons directement les consommer via une URL. Il n’est pas utile de gérer et maintenir une base de données.

Quelle est la méthode de création de la solution ?

La solution a été créée de la manière suivante.

Après une présentation des membres de l'équipe et des problématiques pressenties, nous nous sommes vite rendus compte que l'accès à ces données n'était pas évident pour des non-experts.

Grâce à nos connaissances en data et logiciel, nous avons rapidement suggéré d'utiliser le format parquet. De fil en aiguille, nous avons trouvé DuckDB pour consommer facilement ces données en parquet. Enfin, suite à des discussions avec des mentors, nous avons ajouté l'option d'utiliser l'application web avec un LLM pour accroître davantage l'accessibilité des données.

La solution réside en 3 blocs :

• app data = moteur de données qui récupère les données de data.gouv.fr et les transforme en parquet
  • imaginé avec des technologies serverless dans un premier temps
• data.gouv.fr qui héberge les données originales et également nos données transformées
• app front = application web qui consomme efficacement ces données météo
  • hébergé comme un site web statique (Gitlab/Github Pages, S3 Bucket, ...)

Impact envisagé

Que permet de faire la solution ?

La solution permet de télécharger plus efficacement les données dont l’utilisateur a besoin.

En se limitant à une interface basique (au pire à du SQL), notre application facilite l’ouverture et la réutilisation des données de Météo France.

Il n’est plus nécessaire d’étudier les spécificités des formats des données météorologiques : grib2, netCDF, geotiff, csv.gz, ...

Qui sont les usagers visés, et qu’en feraient-ils ?

Les usagers sont divers :

• Service public (pompiers, préfecture...) dans la prévision et la planification des risques (crues, canicules, feux de forêt, ...)
• Scientifiques ne souhaitant pas télécharger l’ensemble complet des données d’un modèle mais uniquement un ensemble de sous-paramètres.
• Souscripteurs et Courtiers en Assurance Paramétrique
• Métiers de l'aéronautique ( facilitation pilotage automatique des ballon / drones, Optimisation du temps vol/durée batteries )
• Grand public ( curieux voulant visualiser en 3D les données météorologiques ),

[Facultatif] Retours sur la qualité des données exploitées

Quelles sont les difficultés que nous avons rencontrées dans l’usage des données ?

Les données météorologiques sont vastes et nécessitent un bagage scientifique important. Un utilisateur novice souhaitant “simplement” récupérer le vent doit s’accrocher pour trouver ce qu’il cherche.

Après avoir compris la différence entre AROME et ARPEGE, il doit apprendre à lire un fichier .grib2, lire la nomenclature des paramètres des modèles, faire la différence entre les champs surface, isobare et hauteurs. Le vent est présent à peu près partout. Avec un peu de chance et beaucoup de détermination, il finira peut être par trouver la force et la direction du vent pour son application de parapente.

pourquoi la dalle ?

Parce qu'un ensemble de parquets forme une dalle...