Questions fréquentes

Les crédits sont facturés sur ce que l'API retourne réellement, pas seulement sur les heures demandées.

Credits = returned_valid_times * parameters * ceil(coordinates / 500)

returned_valid_times désigne les heures valides réellement retournées par emplacement. Pour les requêtes d'ensemble, chaque membre d'ensemble est sa propre série temporelle.

• Les datasets sous-horaires sont facturés selon les heures valides sous-horaires retournées.
• Les datasets à horizons dispersés ne sont facturés que pour les heures retournées.
• Les requêtes servies depuis le cache sont facturées à 10 % du coût normal.

Oui. Pour un backfill important, nous pouvons configurer temporairement le quota ou le débit afin que vous puissiez extraire davantage de données sur une courte fenêtre.

Contactez info@gribstream.com avec les datasets, variables, période, nombre de coordonnées et délai cible.

Un 429 indique généralement un quota épuisé ou une limitation de débit en rafale.

• Si le quota est épuisé, Retry-After donne les secondes jusqu'à la prochaine réinitialisation quotidienne UTC.
• Pour la limitation en rafale, il s'agit souvent d'une pause courte.

Respectez Retry-After, utilisez un backoff exponentiel avec jitter, et évitez les boucles de nouvelles tentatives serrées.

Cela arrive quand un client continue à retenter des requêtes refusées à haute fréquence. Pour protéger la capacité partagée, GribStream peut bloquer temporairement l'IP source.

Évitez cela en corrigeant l'authentification avant de retenter des 401, en respectant Retry-After sur les 429, et en limitant les tentatives.

Les quotas quotidiens sont réinitialisés à 00:00 UTC. Le compte à rebours exact est visible dans le tableau de bord de votre token.

/timeseries retourne la meilleure valeur disponible pour chaque heure valide, avec le Lead Time (horizon de prévision) le plus court sous vos filtres. C'est le bon choix pour des courbes de produit, tableaux de bord, variables de modélisation et backtesting sans fuite d'information.

/runs retourne toutes les valeurs correspondantes par exécution du modèle et horizon. Utilisez-le pour comparer les cycles, analyser la dérive entre exécutions ou faire de la recherche.

Utilisez fromTime/untilTime pour des fenêtres denses et continues. Utilisez timesList lorsque vous connaissez déjà les horodatages exacts et voulez une extraction éparse.

asOf est un horodatage de coupure pour /timeseries : seuls les runs produits par le modèle à cette date ou avant sont éligibles. Utilisez-le pour du backtesting sans fuite d'information.

Les réponses sont envoyées en streaming dans un ordre optimisé pour le débit. Si vous avez besoin d'un ordre déterministe, triez côté client après téléchargement.

Un sélecteur est un objet JSON exact comme { "name": "TMP", "level": "2 m above ground", "info": "" }. Copiez name, level et info depuis la page du modèle ; ce ne sont pas des libellés à traduire.

La grille demandée n'intersecte probablement pas le domaine du dataset. Vérifiez la couverture du modèle, les bornes latitude/longitude et le step, puis testez une coordonnée connue dans le domaine.

Pour les datasets d'ensemble, utilisez le champ members. S'il est omis, GribStream retourne seulement le premier membre disponible, généralement le membre de contrôle 0. Ajouter des membres augmente le nombre de lignes et les crédits presque linéairement.

Dans /timeseries, chaque heure valide utilise le Lead Time le plus court disponible. Quand le run source du modèle change près d'une limite de cycle, la série peut montrer un saut. Utilisez /runs pour garder un run fixe du modèle.

Pour de grands backfills, gardez des requêtes bornées et prévisibles : visez environ 10 à 15 secondes par requête, maximisez les coordonnées dans cette cible, utilisez timesList pour les horodatages épars, limitez les variables, puis faites un essai à blanc sur une petite tranche avant de passer à l'échelle.

Les hits de cache coûtent 10% des crédits normaux et sont généralement plus rapides. Le cache aide surtout pour les requêtes répétées récentes ou à faible Lead Time. Changer les coordonnées change souvent la clé de cache, et les très grandes requêtes de coordonnées ne sont pas éligibles.

Base recommandée :

• Authorization: Bearer <token>
• Content-Type: application/json
• Accept: text/csv, application/json ou application/ndjson
• Accept-Encoding: gzip pour les réponses volumineuses

Utilisez les expressions et filtres de l'API lorsqu'ils réduisent le volume renvoyé dès la requête : conversions d'unités, seuils, filtres d'événements et formules simples. Utilisez le post-traitement pour la logique à état, les jointures entre datasets, l'enrichissement externe ou les pipelines complexes.

Oui. Utilisez /timeseries avec asOf pour reconstruire les données de prévision disponibles à chaque horodatage historique, puis combinez les datasets de prévision avec des datasets d'analyse ou d'observation comme cibles d'évaluation. Utilisez timesList si les horodatages d'évaluation sont épars.

Le GRIB2 brut donne un contrôle maximal au niveau des fichiers, mais vous gérez vous-même ingestion, indexation, décodage, stockage, nouvelles tentatives et disponibilité. L'API GribStream retourne seulement les variables, lieux, temps et formats nécessaires, avec beaucoup moins de charge opérationnelle.

Beaucoup de modèles encodent le vent avec les composants u et v. Calculez vitesse et direction météorologique avec :

speed = math.sqrt(u*u + v*v)
direction = (270 - math.atan2(v, u) * 180 / math.pi) % 360

Dans les expressions GribStream, utilisez func.Hypot(uwind, vwind) et func.Atan2(vwind, uwind).

Convertissez la température de Kelvin en Celsius et appliquez l'approximation Magnus-Tetens :

T_C = T - 273.15

a = 17.27
b = 237.7

gamma = (a * T_C) / (b + T_C) + math.log(RH / 100)
dew_point_C = (b * gamma) / (a - gamma)

Vous pouvez retourner dew_point_C ou dew_point_K comme colonnes dérivées avec les expressions GribStream.