Nouvelle dénomination open météo

[sctfic]

Probe2/controllers/queryDbController.js

Line 730 in 5fe3d20

function getHistoricalMapping() {

Description

A regression has been observed for a few days where soil_temperature_7_to_28cm and soil_moisture_7_to_28cm values collected from Open-Meteo are returning empty (null).

The source code hasn't changed recently, meaning the issue originates from an API update on Open-Meteo's side. They have homogenized their soil variables mapping, and the old legacy ERA5 depth brackets (7_to_28cm) are no longer consistently mapped or populated in recent datasets when using default mixed models.

Location

The issue is located in the fetchOpenMeteoArchiveStream(params) function inside:
controllers/queryDbController.js

Proposed Solution (Option 1)

Update the Open-Meteo API query parameters to migrate from the deprecated depth brackets to the new standardized depths currently supported by Open-Meteo's updated models.

We need to:

1. Identify the closest matching new depth layers available for our targeted locations (e.g., switching to specific depths like 18cm or new brackets like 9_to_27cm / 3_to_9cm depending on the exact dataset requirements).
2. Update the query parameters mapping inside fetchOpenMeteoArchiveStream.
3. Ensure the database schema or parsing logic accommodates these new variable names if they differ.

Steps to reproduce

1. Run a query that triggers fetchOpenMeteoArchiveStream for recent dates.
2. Inspect the stream payload.
3. Observe that soil_temperature_7_to_28cm and soil_moisture_7_to_28cm arrays contain empty/null values.

[sctfic]

Description

Une régression récente entraîne l'absence de données (valeurs nulles) pour certaines variables d'humidité et de température du sol en raison de modifications de l'API Open-Meteo. L'ancienne tranche de profondeur (7_to_28cm) a été dépréciée ou n'est plus alimentée de façon cohérente pour les dates récentes.

De plus, les données d'archive standards ont une certaine latence, ce qui crée un manque d'informations pour les jours les plus proches (les derniers jours).

Solution proposée

Pour conserver un jeu de données continu et précis sans valeurs manquantes (null), nous devons mettre en place une stratégie de récupération en deux étapes :

1. Pour les données historiques anciennes : Continuer à utiliser archive-api.open-meteo.com en utilisant les nouvelles variables harmonisées (par exemple, soil_temperature_18cm et soil_moisture_9_to_27cm).
2. Pour les données récentes (par exemple des 14 derniers jours) : Utiliser historical-forecast-api.open-meteo.com/v1/forecast, qui donne accès aux jeux de données de prévisions réelles pour le passé immédiat, garantissant ainsi l'absence de données manquantes pour les jours récemment écoulés.

Détails de l'implémentation

Mettre à jour la fonction fetchOpenMeteoArchiveStream(params) (ou créer un module de récupération dédié) dans le contrôleur controllers/queryDbController.js pour découper intelligemment la période demandée :

• Interroger l'archive-api pour les plages de dates où les données consolidées sont disponibles.
• Interroger l'historical-forecast-api pour la fenêtre temporelle la plus récente.
• S'assurer que les nouveaux appels d'API interrogent les nouvelles variables harmonisées au lieu des anciennes profondeurs.

[sctfic]

Après analyse plus approfondie du fonctionnement interne d'Open-Meteo, une solution beaucoup plus simple et performante est envisageable sans avoir à combiner deux API différentes (archive et historical-forecast) au quotidien.

Nouvelle approche proposée

Puisque le projet rafraîchit déjà les données toutes les heures sur une fenêtre glissante de deux semaines, nous pouvons exploiter pleinement l'API Forecast standard (api.open-meteo.com) avec le paramètre past_days=14.

À $J-14$, les données calculées par les derniers "runs" de l'API Forecast convergent vers les données consolidées de l'API Archive. Les écarts deviennent négligeables.

Avantages

1. Un seul appel d'API : Pas besoin de gérer une logique de découpage de dates complexe dans le code.
2. Données lissées et stables : Les données récentes bénéficient des derniers réajustements ("runs") d'Open-Meteo, tandis que les données à $J-14$ sont stabilisées.
3. Zéro trou de données : La transition est transparente et l'API Forecast permet également de récupérer les prévisions futures si nécessaire.

Modifications à réaliser dans queryDbController.js

• Ajouter le paramètre past_days=14 (et optionnellement forecast_days pour les prévisions).
• Basculer définitivement sur les nouvelles variables de sol harmonisées : soil_temperature_18cm et soil_moisture_9_to_27cm.