Häufige Fragen

Credits werden nach dem berechnet, was die API tatsächlich zurückgibt, nicht nur nach angefragten Uhrzeiten.

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

returned_valid_times sind die gültigen Zeiten, die pro Ort zurückgegeben werden. Bei Ensemble-Abfragen ist jedes Ensemble-Mitglied eine eigene Zeitreihe.

• Bei Datasets mit unterstündlicher Auflösung zählen die zurückgegebenen gültigen Zeiten in dieser Auflösung.
• Datasets mit unregelmäßigen Horizonten werden nur für zurückgegebene Zeiten berechnet.
• Cache-Hits kosten 10 % normaler Credits.

Ja. Für große Backfills können wir temporäre Kontingent- oder Throughput-Anpassungen setzen, damit Sie in einem kurzen Fenster mehr abrufen können.

Kontaktieren Sie info@gribstream.com mit Datasets, Variablen, Zeitraum, Koordinatenanzahl und Zielzeit.

Ein 429 bedeutet meist erschöpftes Kontingent oder Burst-Throttling.

• Bei erschöpftem Kontingent gibt Retry-After Sekunden bis zum nächsten täglichen UTC-Reset an.
• Bei Burst-Throttling ist es meist ein kurzer Cooldown.

Beachten Sie Retry-After, nutzen Sie exponentielles Backoff mit Jitter, und vermeiden Sie enge Retry-Schleifen.

Das passiert oft, wenn ein Client abgelehnte Requests mit hoher Frequenz wiederholt. Zum Schutz geteilter Kapazität kann GribStream die Quell-IP temporär blockieren.

Vermeiden Sie das, indem Sie Authentifizierung vor weiteren 401-Retries korrigieren, Retry-After bei 429 beachten und Retry-Limits setzen.

Tägliche Kontingente werden um 00:00 UTC zurückgesetzt. Der genaue Countdown steht in Ihrem Token-Dashboard.

/timeseries gibt einen besten Wert pro gültiger Zeit zurück, mit der kürzesten zulässigen Lead Time unter Ihren Filtern. Es passt für Produktkurven, Dashboards, Feature-Berechnung und Backtesting auf Basis von Modellläufen.

/runs gibt alle passenden Werte nach Modelllauf und Lead Time zurück. Nutzen Sie es für Zyklusvergleiche, Drift zwischen Modellläufen und Forschung.

Nutzen Sie fromTime/untilTime für dichte, kontinuierliche Fenster. Nutzen Sie timesList, wenn Sie exakte Zeitpunkte kennen und nur diese einzelnen Zeiten abfragen möchten.

asOf ist ein Cutoff nach Modelllaufzeit für /timeseries: Nur Zeilen, deren forecasted_at zu diesem Zeitpunkt oder davor liegt, sind gültig.

Gemeint ist die Sicht der Modelllaufzeit, nicht der Zeitpunkt, zu dem GribStream die Daten indexiert oder verfügbar gemacht hat.

Nutzen Sie es für Backtesting auf Basis von Modellläufen, ohne spätere Zyklen in die Abfrage zu lassen.

Nein. asOf nutzt die Modelllaufzeit, nicht die genaue Uhrzeit, zu der ein Lauf in GribStream verfügbar wurde.

Zum Beispiel kann ein GFS-12Z-Lauf mit asOf: "12:30Z" gültig sein, weil sein forecasted_at bei 12:00Z liegt, auch wenn er um 12:30Z noch nicht in der API sichtbar war.

Wenn Sie in einem Backtest die tatsächliche Live-Verfügbarkeit der API annähern müssen, ist der öffentliche Standardablauf, vor dem Setzen von asOf einen konservativen Puffer anzuwenden. Nehmen Sie den historischen Entscheidungszeitpunkt, ziehen Sie eine Schätzung der üblichen Veröffentlichungs- und Indexierungsverzögerung ab, und verwenden Sie diesen früheren Zeitpunkt als asOf.

Dieser Puffer sollte auf der üblichen Verzögerung zwischen nominalem Modellzyklus und Veröffentlichung der relevanten Vorhersagehorizonte im öffentlichen Objekt-/Blob-Speicher des Anbieters basieren, plus zusätzlichem Spielraum für gelegentliche Verzögerungen beim Anbieter oder bei GribStream. Bei NOAA-Feeds wie GFS werden Dateien nach Vorhersagehorizont hochgeladen. Ein Ablauf, der nur die ersten 48 Vorhersagestunden nutzt, kann daher oft eine kleinere Korrektur verwenden als ein Ablauf, der den vollständigen Lauf benötigt.

GribStream veröffentlicht noch keine Verzögerungsrichtwerte pro Dataset und Horizont auf den Modellseiten; das soll separat folgen. Sie können includeMetadata: ["index_updated_at"] anfordern, um den neuesten Zeitstempel der für jede Ergebniszeile genutzten Indexzeilen zu sehen, aber das ist kein stabiles Protokoll der erstmaligen Verfügbarkeit. Experimentelle Workflows nach Indexzeit können auf Anfrage verfügbar sein, gehören aber nicht zum stabilen öffentlichen API-Vertrag.

Die Zeilen werden in einer für Throughput optimierten Reihenfolge gestreamt. Wenn Sie deterministische Ordnung brauchen, sortieren Sie clientseitig nach dem Download.

Ein Selektor ist ein exaktes JSON-Objekt wie { "name": "TMP", "level": "2 m above ground", "info": "" }. Kopieren Sie name, level und info von der Modellseite; diese Werte werden nicht übersetzt.

Das angefragte Grid schneidet wahrscheinlich den Abdeckungsbereich des Datasets nicht. Prüfen Sie Modellabdeckung, Latitude-/Longitude-Grenzen und step, und testen Sie erst eine bekannte Koordinate im Abdeckungsbereich.

Für Ensemble-Datasets nutzen Sie das Feld members. Wenn es fehlt, gibt GribStream nur das erste verfügbare Mitglied zurück, meist das Kontrollmitglied 0. Mehr Mitglieder erhöhen Zeilen und Credits fast linear.

In /timeseries nutzt jede gültige Zeit die kürzeste zulässige Lead Time. Wechselt der ausgewählte Modelllauf an einer Zyklusgrenze, kann die Serie springen. Nutzen Sie /runs, um einen festen Modelllauf zu behalten.

Für große Backfills sollten Requests begrenzt und vorhersehbar bleiben: zielen Sie auf etwa 10 bis 15 Sekunden pro Request, maximieren Sie Koordinaten innerhalb dieses Ziels, nutzen Sie timesList für einzelne bekannte Zeitpunkte, halten Sie Variablen fokussiert und testen Sie zuerst einen kleinen Ausschnitt.

Cache-Hits kosten 10% normaler Credits und sind meist schneller. Cache hilft vor allem bei wiederholten aktuellen Requests oder bei Requests mit niedriger Lead Time. Andere Koordinaten ändern meist den Cache-Key, und sehr große Koordinaten-Requests sind nicht für den Cache geeignet.

Empfohlene Header-Basis:

• Authorization: Bearer <token>
• Content-Type: application/json
• Accept: text/csv, application/json oder application/ndjson
• Accept-Encoding: gzip für große Antwortkörper

Nutzen Sie API-Expressions und Filter, wenn sie die Response früh verkleinern: Einheitenumrechnungen, Schwellenwerte, Event-Filter und einfache Formeln. Nutzen Sie Post-Processing für zustandsbehaftete Logik, datasetübergreifende Joins, externe Anreicherung oder komplexe Pipelines.

Ja. Nutzen Sie /timeseries mit asOf, um die beste Vorhersage unter einem Cutoff nach Modelllaufzeit zu rekonstruieren. Wenn Sie die exakte Live-Verfügbarkeit in der API annähern müssen, ziehen Sie vor dem Setzen von asOf einen konservativen Puffer auf Basis der üblichen Veröffentlichungsverzögerung des Anbieters für die genutzten Horizonte ab. Kombinieren Sie Vorhersage-Datasets mit Analyse- oder Beobachtungs-Datasets als Vergleichsbasis, und nutzen Sie timesList, wenn die Auswertungszeiten vereinzelt sind.

Rohes GRIB2 bietet maximale Kontrolle auf Dateiebene, aber Sie betreiben Ingestion, Indexierung, Decoding, Speicherung, Retries und Verfügbarkeit selbst. Die GribStream API gibt nur benötigte Variablen, Orte, Zeiten und Formate zurück, mit deutlich weniger Betriebsaufwand.

Viele Modelle codieren Wind mit den Komponenten u und v. Geschwindigkeit und meteorologische Richtung berechnen Sie mit:

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

In GribStream Expressions können Sie func.Hypot(uwind, vwind) und func.Atan2(vwind, uwind) nutzen.

Konvertieren Sie die Temperatur von Kelvin nach Celsius und wenden Sie die Magnus-Tetens-Näherung an:

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)

Sie können dew_point_C oder dew_point_K als abgeleitete Spalten mit GribStream Expressions zurückgeben.