Collecte de mesures météorologiques à l'aide d'un système autonome : exemple de la métropole rennaise (Zone Atelier Armorique)
Résumé
L'UMR LETG Rennes COSTEL étudie l'îlot de chaleur urbain sur le territoire de Rennes Métropole, observatoire urbain de la Zone Atelier Armorique (ZAA) depuis 2011, et gère dans ce but un réseau de 18 stations météorologiques. Les premières mesures datent de 1996 et proviennent exclusivement des stations Weather Monitor II, fabriquées par Davis Instruments. Le réseau s'est ensuite enrichi de stations plus récentes de la même marque (modèle Vantage Pro 2). Dans le futur, des stations équipées de modem GSM seront installées mais actuellement, un opérateur doit relever
tous les mois 11 stations, tandis que les 7 autres stations sont gérées par des volontaires qui envoient les données par courriel (sous la forme d'un fichier dans un format propriétaire). Outre le temps nécessaire pour relever les mesures sur le terrain et centraliser toutes les données, des données sont perdues lorsqu'une station rencontre un problème (coupures de courant et dysfonctionnement d'un capteur étant les plus fréquents). Une détection plus rapide du problème limiterait ces pertes de données.
L'UMR LETG Rennes COSTEL a ainsi décidé d'équiper son réseau d'un système permettant d'une part de collecter automatiquement et à distance les mesures météorologiques, et d'autre part d'indiquer l'état des stations en temps quasi-réel. Les contraintes budgétaires empêchant d'acquérir
des stations directement équipées d'un modem GSM/GPRS, une alternative à un prix raisonnable devait être trouvée. La solution retenue consiste à connecter des mini-ordinateurs (Raspberry Pi), à la console des stations, pour un coût total inférieur à 70€. Ces mini-ordinateurs émettront d'une part
une information en temps quasi-réel sur un site Web (stockée en JSON), et d'autre partsauvegarderont les données quotidiennes sur un serveur FTP (format csv). Ils profiteront soit du réseau Ethernet soit du Wifi selon leur disponibilité, sachant que le territoire de Rennes Métropole dispose d'une bonne couverture Wifi.
Après plus de 3 semaines de tests couronnées de succès, la phase de développement est désormais achevée et le déploiement se fera progressivement au cours de l'année. L'application a été codée en Python (près de 3000 lignes de code) selon une approche orientée-objet. Le mini-ordinateur peut communiquer avec les deux modèles de station existants sur le réseau : pour la collecte des mesures évidement, mais aussi pour reconfigurer la station météorologique (changement d'heure...). En fait, il s'agit d'un système autonome, capable de supporter et de réagir aux aléas (coupure de courant, station météo déconnectée). Lors du développement, 50 tests unitaires ont été créés pour s'assurer de la robustesse de notre solution. Au démarrage du système, l'application met en place un daemon, sous la surveillance d'un chien de garde. Rendre ce système autonome s'est avéré être l'un des investissements majeurs dans ce projet, après la communication avec le modèle Weather Monitor II, pour lequel peu de codes sources était disponible.
Après avoir présenté notre solution, nous expliquerons nos choix techniques et stratégiques qui nous ont conduit à développer notre propre application plutôt que d'utiliser une solutions existante. Deux raisons principales justifient ce choix : (1) l'absence de solution compatible avec un de nos modèles de station et (2) la nécessité de rester maître des données collectées. L'investissement a été conséquent mais pourra être valorisé sur d'autres réseaux de stations météorologiques gérés par le laboratoire, que ce soit dans la ZAA, au Brésil, ou sur les vignobles étudiés de par le monde. Enfin, cette solution s'intègre dans un projet plus large. Une base de données PostgreSQL/Postgis a été développée pour centraliser et assurer la cohérence de nos données, et une interface web est en cours de développement pour faciliter la maintenance du réseau. En perspective, nous présenterons l'état de notre réflexion sur la mise à disposition future de nos données au sein de l'infrastructure de données géographiques de l'UMR LETG, nommée Indigeo (www.indigeo.fr) : devons-nous rendre la totalité ou une partie seulement des données accessibles, sous quelle forme (flux WMS et/ou téléchargement, données brutes et/ou validées), et pour quel public (OSUR, libre accès) ?
Origine : Fichiers produits par l'(les) auteur(s)