Domande frequenti

I crediti vengono addebitati in base a ciò che l'API restituisce davvero, non solo agli orari richiesti.

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

returned_valid_times sono gli orari di validità effettivamente restituiti per ogni località. Nelle richieste ensemble, ogni membro dell'ensemble è una propria serie temporale.

• I dataset con risoluzione sub-oraria vengono addebitati sugli orari validi sub-orari restituiti.
• I dataset con lead time sparsi vengono addebitati solo sugli orari che ritornano.
• Le risposte servite dalla cache costano il 10 % dei crediti normali.

Sì. Per un backfill importante possiamo configurare temporaneamente crediti o throughput in modo che tu possa estrarre più dati in una finestra breve.

Scrivi a info@gribstream.com con dataset, variabili, periodo, numero di coordinate e tempi desiderati.

Un 429 di solito indica crediti esauriti o un limite di burst.

• Se i crediti sono esauriti, Retry-After indica i secondi fino al prossimo reset giornaliero in UTC.
• Se è un limite di burst, spesso è una pausa breve.

Rispetta Retry-After, usa exponential backoff con jitter ed evita loop di retry troppo stretti.

Succede quando un client continua a riprovare richieste rifiutate ad alta frequenza. Per proteggere la capacità condivisa, GribStream può bloccare temporaneamente l'IP sorgente.

Evitalo correggendo l'autenticazione prima di riprovare dopo un 401, rispettando Retry-After sui 429 e limitando il numero di tentativi.

I crediti giornalieri vengono resettati alle 00:00 UTC. Il countdown esatto è visibile nella dashboard del tuo token.

/timeseries restituisce il miglior valore disponibile per ogni orario di validità, usando il lead time più breve consentito dai tuoi filtri. È la scelta giusta per curve di prodotto, dashboard, feature per modelli predittivi e backtesting senza data leakage.

/runs restituisce tutti i valori corrispondenti per run del modello e lead time. Usalo per confrontare cicli, analizzare la deriva tra run o fare ricerca.

Usa fromTime/untilTime per finestre dense e continue. Usa timesList quando conosci già gli orari esatti e vuoi un'estrazione sparsa.

asOf è un timestamp di riferimento per /timeseries: sono candidati solo i run del modello prodotti in quel momento o prima. Usalo per backtesting senza data leakage.

Le risposte vengono inviate in streaming in un ordine ottimizzato per throughput. Se ti serve un ordine deterministico, ordina lato client dopo il download.

Un selettore è un oggetto JSON esatto come { "name": "TMP", "level": "2 m above ground", "info": "" }. Copia name, level e info dalla pagina del modello; non sono etichette da tradurre.

Probabilmente la griglia richiesta non interseca il dominio del dataset. Controlla la copertura del modello, i limiti latitudine/longitudine e lo step, poi prova una coordinata nota dentro il dominio.

Per dataset ensemble, usa il campo members. Se lo ometti, GribStream restituisce solo il primo membro disponibile, di solito il membro di controllo 0. Aggiungere membri aumenta righe e crediti quasi linearmente.

In /timeseries, ogni orario di validità usa il lead time più breve disponibile. Quando il run sorgente cambia vicino al confine tra cicli, la serie può mostrare un salto. Usa /runs per mantenere fisso il run del modello.

Per backfill grandi, mantieni le richieste limitate e prevedibili: punta a circa 10-15 secondi per richiesta, massimizza le coordinate entro quella soglia, usa timesList per orari sparsi, limita le variabili e fai prima un test su una piccola finestra.

Le risposte servite dalla cache costano il 10% dei crediti normali e di solito sono più veloci. La cache aiuta soprattutto con richieste ripetute recenti o a basso lead time. Cambiare coordinate spesso cambia la chiave di cache, e le richieste con moltissime coordinate non sono idonee alla cache.

Base consigliata:

• Authorization: Bearer <token>
• Content-Type: application/json
• Accept: text/csv, application/json oppure application/ndjson
• Accept-Encoding: gzip per risposte grandi

Usa expressions e filtri nell'API quando riducono il payload già nella richiesta: conversioni di unità, soglie, filtri di eventi e formule semplici. Usa post-processing per logica con stato, join tra dataset, arricchimento esterno o pipeline complesse.

Sì. Usa /timeseries con asOf per ricostruire quali dati di previsione erano disponibili in ogni momento storico, poi combina dataset di previsione con dataset di analisi o osservazioni come obiettivi di valutazione. Usa timesList quando gli orari di valutazione sono sparsi.

Il GRIB2 grezzo offre massimo controllo a livello di file, ma devi gestire ingestione, indicizzazione, decodifica, archiviazione, nuovi tentativi e disponibilità. L'API GribStream restituisce solo variabili, località, tempi e formati necessari, con molto meno lavoro operativo.

Molti modelli codificano il vento con componenti u e v. Calcola velocità e direzione meteorologica con:

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

Nelle expressions di GribStream puoi usare func.Hypot(uwind, vwind) e func.Atan2(vwind, uwind).

Converti la temperatura da Kelvin a Celsius e applica l'approssimazione 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)

Puoi restituire dew_point_C o dew_point_K come colonne derivate con le expressions di GribStream.