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 verfügbaren Lead Time unter Ihren Filtern. Es passt für Produktkurven, Dashboards, Feature-Berechnung und Backtesting ohne Data Leakage.

/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-Zeitpunkt für /timeseries: Nur Modellläufe, die zu diesem Zeitpunkt oder davor erzeugt wurden, sind gültig. Nutzen Sie es für Backtesting ohne Data Leakage.

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 verfügbare 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 zu rekonstruieren, welche Vorhersagedaten zu jedem historischen Zeitpunkt verfügbar waren. Kombinieren Sie Vorhersage-Datasets mit Analyse- oder Beobachtungs-Datasets als Vergleichsbasis. 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.