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 capacità 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, variabili per modelli predittivi e backtesting basato sui run del modello.

/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 cutoff sull'orario del run del modello per /timeseries: sono candidate solo le righe con forecasted_at uguale o precedente a quel momento.

Va letto dal punto di vista dell'orario del run del modello, non come l'orario in cui GribStream ha indicizzato o reso disponibili i dati.

Usalo per backtesting basato sui run del modello, senza includere cicli successivi nella richiesta.

No. asOf usa l'orario del run del modello, non l'orario esatto in cui un run è diventato disponibile in GribStream.

Per esempio, un run GFS 12Z può essere idoneo con asOf: "12:30Z" perché il suo forecasted_at è 12:00Z, anche se alle 12:30Z non era ancora visibile nell'API.

Se devi approssimare la disponibilità reale dell'API in un backtest, il flusso pubblico standard è applicare un margine conservativo prima di impostare asOf. Parti dall'orario storico di decisione, sottrai una stima del ritardo abituale di pubblicazione e indicizzazione, e usa quel timestamp precedente come asOf.

Il margine dovrebbe basarsi sul ritardo abituale tra il ciclo nominale del modello e il momento in cui il fornitore pubblica gli orizzonti rilevanti nello storage pubblico a oggetti/blob, con margine extra per ritardi occasionali del fornitore o di GribStream. Nei feed NOAA come GFS, i file vengono caricati in ordine di orizzonte di previsione, quindi un flusso che usa solo le prime 48 ore di previsione può spesso usare una correzione più piccola rispetto a uno che richiede il run completo.

GribStream non pubblica ancora indicazioni di ritardo per dataset e orizzonte nelle pagine dei modelli; prevediamo di affrontarlo separatamente. Puoi richiedere includeMetadata: ["index_updated_at"] per vedere il timestamp più recente delle righe di indice usate da ogni risultato, ma non va trattato come un registro stabile della prima disponibilità. Flussi sperimentali basati sull'orario di indicizzazione possono essere disponibili su richiesta, ma non fanno parte del contratto pubblico stabile dell'API.

Le risposte vengono inviate in streaming in un ordine ottimizzato per le prestazioni. 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 idoneo più breve. 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 la migliore previsione sotto un cutoff sull'orario del run del modello. Se devi approssimare la disponibilità esatta nell'API in tempo reale, prima di impostare asOf sottrai un margine conservativo basato sul ritardo abituale di pubblicazione del fornitore per gli orizzonti usati. Poi combina dataset di previsione con dataset di analisi o osservazioni come obiettivi di valutazione, e 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.