y ist wohl die anzahl der täglich gelegten eier in abhängigkeit von x dem tagestemperaturmaximum
0,975 ist die tägliche mortabilitätsrate adulter bienen ohne spritzschäden und wespenmassaker.
hab es so erstanden das es einen brutüberhang gibt also das verhältnis brut zu adulten bienen 120% beträgt – das volk ist kurz vorm explodieren ;)
Dazu läßt sich dann doch Einiges finden, denn Bernhard Heuvel hat es veröffentlicht.
Die Betriebsweise (bei ihm Warré) dürfte nur wenig Einfluß auf die Anwendbarkeit des Modells haben, sofern die starke Außentemperatur-Kopplung durch offenen Gitterboden wie bei anderen Magazin-Systemen gegeben ist. Bretschkos Erkenntnisse allerdings sind mit Carnica entstanden; daß diese Erkenntnisse wahrscheinlich übertragbar sind auf andere Rassen in unseren Breiten, dazu finden sich jedenfalls Hinweise bei Ruttner 1976, erwähnt in: Imdorf, Ruoff, Fluri: Volksentwicklung der Honigbiene:
Interessanterweise zeigten nicht die Völker gleicher Abstammung, sondern die Völker am gleichen Standort ein ähnliches Brutverhalten […]. Dies beweist, dass die Umwelteinflüsse stärker wirken als die Einflüsse der erblichen Veranlagungen.
Ende 2012 veröffentlichte er unter dem Titel “Voraussage der Brutentwicklung im Frühjahr” (http://www.immenfreunde.de/forum/viewtopic.php?t=633) seine ersten (?) Umsetzungen dazu beruhend auf Bretschko, Bergmann, Gerstung
in diesem thread sind auch die (wohl) ursprünglichen Versionen der von @karsten erwähnten Rechenblätter verlinkt (je zwei Blätter; downloads funktionierten dort nur noch teilweise, daher hier als backup: EntwicklungVoelker.xls (84.5 KB), EntwicklungVoelker.ods (76.1 KB)
sein “hand-out” aus dem thread (seine ersten Erkenntnisse des Frühjahrs 2013 mit diesem Rechenmodell): http://www.immenfreunde.de/docs/TempMaxSumm.pdf
zu den verschieden gefärbten Feldern und roten Trennern usw. siehe oben verlinkten thread
in den Rechenblättern sollten die Werte in Spalte C mit z.B. ROUND bearbeitet werden:
=ROUND(22,8295*MAX(0;$B4)^1,4252;0) (Hinweis aus gleichen thread, andere Stelle http://www.immenfreunde.de/forum/viewtopic.php?f=10&t=633&start=10#p7311)in diesem französischen thread sind von Bernhard Heuvel Versionen der Rechenblätter in französisch verlinkt: Projet: la température maximale et le couvain - La ruche Warré
In einem anderen thread und Forum zeigt Herr Heuvel die gute Anwendbarkeit des Prinzips der Temperatursummen z.B. für den Raps:
Es kommt weniger auf “warme” Tage an, sondern auf aufgelaufene Temperatursummen. Die sich aufaddierende Differenz der Tageshöchst- und Tagesniedrigtemperatur seit Jahresanfang ergibt eine Temperatursumme. Wobei Raps bei 753 beginnt zu blühen. Und bei 1116 aufhört zu blühen.
[…]
Damit konnte ich in den vergangenen Jahren fast tagesgenau den Blütenbeginn von Pflaume, Kirsche und Raps prognostizieren.
(aus: Raps 2017 - März - Imkerforum seit 1996)
Dort ist auch das erwähnte Rechenblatt “Raps-Blührechner” verlinkt (leider auf ggl docs; kann gerne jemand raw hier ablegen) https://docs.google.com/spreadsheets/d/1jFZXPEes0-OgFnRzRjfYP_Uy8FRrKkAuMvjak0Lyq9s/edit?usp=sharing#
Heuvel’s Blührechner für Raps, Kirsche und Pflaume (je drei Blätter):
Blütenrechner.ods (40.6 KB) , Blütenrechner.xlsx (156.9 KB)
Insgesamt denke ich, daß es für uns mit den inzwischen gegebenen Möglichkeiten in unserem Datenmischwerk sehr interessant wäre, Temperatursummen-Prinzipien sowohl
zu erschließen bzw. einzubinden. Schon die Grünlandtemperatursumme und auch ihre Vorhersage (mit und ohne MOSMIX-Hilfe) könnte in Grafana aus Bordmitteln erzeugt werden (ob nun mit Werten der nächsten DWD-Station oder selbst gemessen).
Wenngleich dies wichtig ist, sind natürlich die Zeitpunkte der Massentrachten noch wichtiger. Die Wachstumsgradtage mögen jeweils leicht errechnet sein, aber es fehlen uns einige Koeffizienten wie oben für den Raps, um dies in z.B. phenodata oder als Hilfsdatenquelle für Influx/Grafana anlegen zu können … Leider sind in den Tabellen Rekursionen vorhanden, die zu realisieren so in Influx/Grafana nicht einfach klappt, und für welche ich erstmal mit @andreas und @wtf in Klausur gehen muß… ;)
weil es sich gerade schön verlinkt: erwähnte historische Literatur zum Thema:
“Gerstung, Ferdinand : Das Grundgesetz der Brut- und Volksentwicklung des Biens” (1902)
http://digital.zbmed.de/download/pdf/2437832?name=Das%20Grundgesetz%20der%20Brut-%20und%20Volksentwicklung%20der%20Bienen
Nur zur Info, er hat aktuell nicht mehr Warre, sondern seit er das hauptberuflich macht Dadant.
Mal unabhängig davon wie gut das Modell unterbaut ist, wäre es doch interessant es zumindest in einem Template zur Verfügung zu stellen und damit einen breiteren Test zu ermöglichen. Leider komme ich mit meinen nicht vorhandenen Grafana Kenntnissen schnell an die Grenzen. Bisher habe ich in einem Graph umgesetzt
Maximaltemperatur des Vortrages:
SELECT max("Temperatur") FROM "balkon_stand_sensors" WHERE $timeFilter GROUP BY time(1d) fill(null)
daraus die Eiablage nach Formel oben:
SELECT 22.8295*pow(max("Temperatur"),1.4254) FROM "balkon_stand_sensors" WHERE $timeFilter GROUP BY time(1d) fill(0)
Damit sollte dann die Summe der Eiablage der letzten 20 Tage die Anzahl der Brutzellen sein. Aber wie bekomme ich die aufsummiert - kann da jemand helfen?
Korrekt, das haut schonmal hin. Aber Du hast recht: die auflaufende Brut (also der Wert “Eiablage 20 Tage zuvor” läßt sich nicht einfach per query-Ausdruck ab dem 21. Tag abziehen.
Ein ähnliches Problem habe ich auch gerade bei der Erstellung der Grünlandtemperatursumme (da werden z.B. bei vielen Versionen die Werte monatsabhängig verschieden gewichtet, Startdatum und ggf. -offset der Funktion müßten einstellbar sein usw.), und das geht leider z.Z. doch nicht mit Bordmitteln. Grafana erlaubt gegenwärtig zusammen mit der aktuellen Version von InfluxDB keine queries, die auf mehr als den jeweils gewählten Zeitraum arbeiten, ein dafür nötiges time shift im query kann InfluxDB, aus Grafana heraus bedient, noch nicht (nur im view innerhalb Grafana).
Das zu lösen, ist nicht trivial, aber möglich. Ich bereite da gerade etwas vor für die Diskussion in der hiveeyes-Kerntruppe, aber als Vorgriff darauf:
InfluxDB 2.0 ist wenige tage vor dem alpha-release (master branch wird auf 2.0 umgeschaltet) , da sollten dann alle Probleme gelöst sein!™ ;)
Natürlich noch nicht gleich, denn die alpha muß erst etwas reifen, bevor sie produktiv verwendet werden kann. Aber dort ist in der query language offenbar der timeshift als Bestandteil eines queries möglich, so wie in Graphite oder Prometheus. - Die Grafana-Leute haben wegen Quantensprung auf InfluxDB 2.0 angekündigt, daß diese umgehend in Grafana unterstützt werden wird.
es gibt MetaQuery, eine synthetische Datenquelle für u.a. diese timeshift-Funktion sowie für Arithmetic . Das Teil ist auch auf swarm.hiveeyes.org installiert und als data source auswählbar (auch mit Mixed) .
Leider verzweifeln @wtf und ich regelmäßig an diesem Ding; die Beispiele sind ‘nur’ für ein ElasticSearch backend, den Syntax bei arithmetic für InfluxDB bekommen wir nicht in funktionierend hin; das, was klappt, ist nur trivial und nicht reproduzierbar 8( …
Bestimmte Arten von nesting sind damit nicht möglich:
Known Issues
Moving average of moving average is not supported
Moving average of time shift is not supported
Time shift of Moving average is not supported
Time shift of Time Shift is not supported
… aber ob die begehrten arithmetics auch geschachtelt werden können, haben wir noch nicht erkunden können. Auch bereits eine funktionierende timeshift-Möglichkeit mithilfe dieses plugins, welche man sich im Anschluß im eigenen query zunutze macht, wäre schön!
Also: wer sich schaffen möchte, darf gern die MetaQuery ausprobieren, da ist Forschungsbedarf.
Metaquery als generell begehrenswerte Funktionalität ist auch ohne diesen Kontext des plugins auf der Agenda der Grafana-Entwickler; das interessiert auch jene, die andere Datenbanken als InfluxDB nutzen - und uns, die wir damit die in diesem thread angesprochenen Funktionen erledigen könnten. Ob und wie weit das ab 2.0 vielleicht schon integriert sein wird, kann ich noch nicht abschätzen. Daß die das bislang noch nicht gebaut haben, sondern nur dieses ‘Fremd’-plugin existiert, hat den Grund, daß es sehr viel Gehirnschmalz braucht: da der Rechenaufwand einer solchen Funktionalität schnell exponentiell steigen kann, muß die Last gut zwischen back end und front end verteilt werden, gewiß nicht trivial… ;)
Die anderen Möglichkeiten (influxdb-timeshift-proxy; kotori um weitere vendor specific -Dinge erweitern; continuous queries; Kapacitor verwenden für z.B. sowas ; …) wäre immer höherer Aufwand bis ungewünscht, oder nur ein Teillösung, oder nur ein Hack, oder es bräuchte jeweils immer ein (anderes) user interface… also erstmal verschoben.
Aber die MetaQuery -“Datenquelle” darf gern verwendet werden, das Ding könnte die schnellste Lösung für das Problem darstellen.
Die Grünlandtemperatursumme kann ggf. auch durch phenodata extrahiert werden, exquisiter wäre natürlich der Errechnung aufgrund der eigenen gemessenen Werte (auch Zuhilfenahme der nächsten DWD-Station), damit wir letztlich soetwas hier als automatische synthetische Datenquelle für einen Standort selbst erstellen könnten (dashboard von @clemens; über die annotations hovern):
Danke für die tollen Vorschläge. Auch wenn wir alle schon sehnsüchtig auf InfluxDB 2.0 und Flux warten und es so bald wie möglich ausprobieren wollen, will ich hier auch noch auf den weiteren potentiellen Kandidaten TimescaleDB hinweisen, den wir ebenfalls ins Auge gefasst hatten, weil diese Datenbank u.U. ebenfalls einige Probleme lösen könnte, die wir derzeit so bei der Datenverwaltung haben.
Wenn der aufgemotzte PostgreSQL die von Euch gewünschten arithmetischen Dinge gut beherrscht, könnten wir so Meß- und Metadaten in der selben Datenbank verwalten - das hört sich erst einmal nicht unpraktisch an ;].
Gefällt mir, ich hoffe wir können das für die kommende Saison realisieren.
OK, dann warten wir mal was die neue Version so bringt. Wenn man über die letzten 20 Tage aufsummieren könnte hätte man schon einmal die aktuelle #brutzellen. Für die Anzahl Bienen müsste man im prinzip immer nur die Mortalität multiplizieren und die schon berechnete Legerate addieren (Bienen*0,975 + legerate(-20d)).
Auch wenn ich das noch nicht in Excel modelliert habe könnte ich mir vorstellen, daß das Modell intrinsisch robust ist und es keine Grenzbedingungen braucht. Im Winter wird die Legerate automatisch niedrig, es sollte sich also eine Population auf niedrigem Niveau einstellen (ich tippe mal, daß diese etwas unterschätzt, da die Mortalität für Winterbienen zu hoch angesetzt ist). Unter Null geht das ganze aber ja nie und auch die Legerate wird mit der Formel nie Null, wodurch immer Bienen vorhanden sind. Im Frühling müssten sich dann von alleine die gewünschten Werte einstellen, die auch realistischer sind. Dann wird das Verhältnis Bienen/Brut ggf. aussagekräftig. Natürlich sind hier keine Trachtlimitierungen, Milbenschäden, etc. drin. Aber im Grunde geht es ja auch nur darum, daß die Werte von April bis Juni einigermaßen realistisch sind, wenn Schwärme fallen könnten und da sollte immer Tracht vorhanden sein (außer man steht im Raps) und Milben sind hoffentlich noch nicht kritisch.
Die Temperatursummen-Theorie bedeutet am Ende ja, dass die Volksgröße, sagen wir mal zu Beginn der Schwarmsaison, nur von der Startgröße der Population im Januar, d.h. bei Brutbeginn nach der brutfreien Zeit und den Temperatursummen abhängt.
Bienen fangen nach der Winterphase, die normalerweise brutfrei ist, Ende Januar an zu brüten. Auch da wäre spannend, wie sie den Zeitpunkt bestimmen, Vermutlich merken sie, dass die Tage länger werden und nehmen dann – unabhängig von der Außentemperatur – das Brutgeschäft auf. Aber auch das ist nur ein Faktor, die absolute Außen-Temperatur spielt auch eine Rolle und kann zu einem früheren Beginn führen, Kollegen berichten z.B. schon jetzt zu Hl. Dreikönig von Brut in den Völkern! Mit dem milden Winter gibt es also auch frühere Startpunkte. Für die Bienen ist das natürlich eine Wette auf Leben und Tod, wenn es gut geht, d.h. das Futter reicht und sich auch kein Futterabriss einstellt – weil es doch mal noch kälter wird und die Bienen auf der Brut sitzen bleiben und sie wärmen und dann nicht zum “Treibstoff” nebenan kommen und so auf gut vollen Waben verhungern – haben sie einen Entwicklungsvorsprung von anderen Vökern, die erst später mit dem Brutgeschäfft anfangen. Wenn das Futter nicht reicht, weil sie gegen zu viel Kälte heizen müssen oder sie nicht ans Futter kommen kann es auch den Tod des Volks bedeuten.
Der Brutbeginn ist also ein wichtiger Faktor, damit hängt dann auch wieder die Varroavermehrung zusammen, der Futterverbrauch, die Futterversorgung von außen. D.h. für die erste Aufwärtsentwicklung können neben den Temperatursummen noch andere gravierende Faktoren dazukommen.
Bleibt noch die Frage ob dank Klimawandel der Brutbeginn überhaupt noch so relevant ist - zumindest meine Bienen brüten bisher mehr oder minder durch. Es soll ja auch Imker geben die den Bienen “etwas gutes tun” und sie in Italien überwintern, was die Winterpause auch deutlich verkürzen düfte. In den Tropen gibt es eh keine wirkliche Brutpause. Brutbeginn erfordert typischerweise Pollen (so die klassische Denkweise) und den gibt es hier meist mit der Blüte der Salweide, deswegen ist es sicher auch spannend die Blühphasen in Dashboard zu haben.
Habe mal etwas mit dem Modell gespielt für zwei extreme (wobei dann doch wieder recht ähnliche Standorte) List auf Sylt und Oberstdorf (die nördlichste und südlichste DWD Station). Hier erst mal die Brutzellen und die Zahl der Bienen über die letzten beiden Jahre:
Und dann das Verhältnis von Brut zu Bienen:
Hier sieht man, erst mal, daß das Modell natürlich im ersten Monat nicht brauchbar ist (Anfangswert für Bienen war 0). Es fällt auf, daß eigentlich nie Schwarmstimmung einsetzt (Sterblichkeit zu klein?) und im zweiten Jahr in Oberstdorf die Brut früher beginnt - da war es letztes Jahr offenbar Anfang März mal zwei Wochen kurz recht warm.
Eine Schwäche ist sicher auch, daß hier alle Bienen berücksichtigt werden. An anderer Stelle habe ich aber einmal gelesen, daß es vor allem die Ammenbienen sind und gerade bei einer Massentracht wird im Volk eben auch schnell einmal umgeschult, damit mehr zum sammeln raus können (siehe Seeley).
Nachtrag: Eigentlich müsste man mit den Daten die wir ohnehin schon haben auch die Sammelbienen abschätzen können
Falls jemand einen der Lichtchranken-Bienenzähler an seiner Beute hat könnte man das sogar einmal validieren - dann reicht es schon fast für ein halbes Paper.
Korrekt! Siehe auch die Beschreibung der shift() Funktion als Bestandteil der neuen Anfragesprache Flux.
from(bucket: "hotzenplotz")
|> range(start: -5m)
|> shift(shift: 12h)
from(bucket: "hotzenplotz")
|> range(start: -5m)
|> shift(shift: -12h)
Wird leider nicht so einfach sein, da ja während die “Spätaufsteher” erst ausfliegen, die ersten frühen schon wieder reinkommen. Wir wissen nur, wann die Bienen anfangen auszufliegen, da gibt es eine Gewichtssenke in der Grafik. Dann kommen wieder Bienen mit Nektar rein, es fliegen aber auch wieder wlche aus. Wie viel eine Biene tatsächlich einträgt hängt auch von der Flugstrecke ab, wenn sie weit weg muss ist der Eintrag weniger, da sie auch Futter für den Flug braucht. Daher werden wir die Ausflüge / Sammlerinnen nicht alleine mit dem Honigblaseninhalt errechnen können. Auch beim Nektar gibt es Unterschiede in der Zusammensetzung, vielleicht bekommen auch die Sammlerinnen wenig und kehren mit halbvoller Honiglbase zurück. In der Zwischenzeit trocknen die Bienen auch wieder den Nektar, d.h. am Abend ist weniger da als absolut gesehen eingetragen wurde.
Habe ich, liegt als Prototyp schon Jahre im Schrank. ;-)s
Was davon hast Du im Schrank: den Zähler oder das paper?! ;p
Den bee counter! ;-) fürs Paper hab ich deswegen noch keine Daten.
Übersicht und Auswahl::
https://www.isip.de/coremedia/generator/isip/Kulturen/Gruenland/GruenlandTempSum/Land.html
direkt: Baden-Württemberg, Bayern, Brandenburg, Hessen, Mecklenburg-Vorpommern, Niedersachsen, Nordrhein-Westfalen, Rheinland-Pfalz und Saarland, Sachsen, Sachsen-Anhalt
Für Schleswig-Holstein und Thüringen sowie die Stadtstaaten sind keine Messungen ausgewiesen, zumindest für die letzteren sind aber in deren Randregionen representative Stationen der angrenzenden Bundesländer zu finden.
Über die Dienstleistungszentren Ländlicher Raum Rheinland-Pfalz (DLR RLP) lassen sich die GTS für die Stationen folgender Bundesländer finden:
Baden-Württemberg, Bayern, Rheinland-Pfalz und Thüringen
Die Werte der identischen Stationen zwischen ISIP und DLR RLP sind gleich (kaum verwunderlich), der Voraussagezeitraum ist aber bei letzteren vier Tage länger. Bei DLR RLP sind außerdem noch die historischen Werte ab 1994 an gleicher Stelle abrufbar.
Abbildung für Januar: 0,5 * (positive Tagestemperatur-Mittelwerte)
Die beispielhafte Darstellung ist geringfügig zu optimistisch, da u.a. der Startwert nicht richtig in die Kalkulation genommen wird / werden kann in IFQL. Umsetzung auf FLUX ist noch in Arbeit.
Eine erste Umsetzung in Flux ist für die DWD-Daten fertig: Ein Query, der aus drei einzelnen Queries für die jeweils anders gewichteten Zeiträume besteht, die resultierenden Tabellen mittels union() in einer zusammenfasst und diese dann als Tageswerte yield()et sowie ne akkumulierte Summe rauswirft:
jan = from(bucket: "dwd_cdc")
|> range(start:2019-01-01T00:00:00Z, stop: 2019-01-31T23:59:59Z)
|> filter(fn: (r) =>
r._measurement == "dwd_cdc_temp_2m_c" and
r._field == "value" and
r.sta_name == "$COMMON_CDC_NAME" and
r.quality_level == "2" and
r.produkt == "10_minutes"
)
|> aggregateWindow(every: 1d, fn: mean)
|> keep(columns: ["_value", "_time"])
|> filter(fn: (r) => r._value > 0)
|> map(fn: (r) => ({
_time: r._time,
_value: r._value * 0.5
}))
feb = from(bucket: "dwd_cdc")
|> range(start:2019-02-01T00:00:00Z, stop: 2019-02-28T23:59:59Z)
|> filter(fn: (r) =>
r._measurement == "dwd_cdc_temp_2m_c" and
r._field == "value" and
r.sta_name == "$COMMON_CDC_NAME" and
r.quality_level == "2" and
r.produkt == "10_minutes"
)
|> aggregateWindow(every: 1d, fn: mean)
|> keep(columns: ["_value", "_time"])
|> filter(fn: (r) => r._value > 0)
|> map(fn: (r) => ({
_time: r._time,
_value: r._value * 0.75
}))
rest = from(bucket: "dwd_cdc")
|> range(start:2019-03-01T00:00:00Z, stop: 2019-12-31T23:59:59Z)
|> filter(fn: (r) =>
r._measurement == "dwd_cdc_temp_2m_c" and
r._field == "value" and
r.sta_name == "$COMMON_CDC_NAME" and
r.quality_level == "2" and
r.produkt == "10_minutes"
)
|> aggregateWindow(every: 1d, fn: mean)
|> keep(columns: ["_value", "_time"])
|> filter(fn: (r) => r._value > 0)
|> map(fn: (r) => ({
_time: r._time,
_value: r._value * 1.0
}))
union(tables: [jan, feb, rest])
|> sort(columns: ["_time"], desc: false)
|> map(fn: (r) => ({
_time: r._time,
_value: r._value,
foo: "Tag"
}))
|> yield(name: "bars")
|> cumulativeSum(columns: ["_value"])
|> map(fn: (r) => ({
_time: r._time,
_value: r._value,
foo: "Total"
}))
Oder auch zum Angucken als dediziertes Dashboard im DWD-Folder: Wetter: DWD / Grünlandtemperatursumme (GTS) und Kältesumme
Wo sich des mit den separaten Zeiträumen und Schwellwerten nun so schön in Flux abbilden lässt: Wünscht sich jemand noch andere, Pflanzen/Bienen/Einhörner-spezifische, Temperatursummen? [Da gibts ja noch ganz andere Rechenwege für andere Pflanzen. Edit: Damn, sind ist immernoch keine Exponenten berechenbar in Flux. Auch selbst eine Exponentialfunktion zu implementeren scheint mir bislang nicht trivial.]
Flux Abfragemonster here…
jan = from(bucket: "dwd_cdc") |> range(start:2019-01-01T00:00:00Z, stop: 2019-01-31T23:59:59Z) [...]
Saustark! Sieht nach ordentlich bewältigter Flux Lernkurve aus.
P.S.: Bei Gelegenheit muss ich mir von Euch mal erklären lassen, was Ihr da tut.
You’ve asked for it, darling. Ick geh den Query mal Schritt für Schritt durch (wer nicht Flux lernen will, sollte hier vmtl. mit dem Lesen abbrechen.)
jan = from(bucket: "dwd_cdc")
Wir nehmen uns mal die “dwd_cdc”-Datenbank, aaaber tun das Ergebniss dieses ja noch weiter spezifizierten Queries in eine Art Variable und nennen sie “jan”.
|> range(start:2019-01-01T00:00:00Z, stop: 2019-01-31T23:59:59Z)
Joar, hier würde mensch sonst[tm] “$range” in die Klammern schreiben: Eine Variable, die Grafana anhand des aktuell gewählten Zeitfensters Flux-gerecht bereitstellt. Aber wir wollen ja mal nur den Januar betrachten. Unsere DB denkt in UTC, der DWD auch: Schick.
|> filter(fn: (r) =>
r._measurement == "dwd_cdc_temp_2m_c" and
r._field == "value" and
r.sta_name == "$COMMON_CDC_NAME" and
r.quality_level == "2" and
r.produkt == "10_minutes"
)
Lasst uns unsere Datenbank filtern! “r” definieren wir als unsere response. “interne” Variablen beginnen mit nem Undersore; das ist für _measurement, _field und _value gegeben. Übrige/individuelle tags werden ohne
_ angegeben. Der Wert aus der Variable $CDC_COMMON_NAME stellt das Grafana über unser Station-Dropdown bereit (hier könnte auch nen Stationsname “hardcodet” stehen).
|> aggregateWindow(every: 1d, fn: mean)
Ist ne Helper-Function, die eigentlich erstmal window() aufruft, und denn die einzelnen Series wieder group()t. Damit lassen sich auch verschiedene Messrhytmen “normalisieren” und vergleichen. In diesem Fall machen wir aus unseren “alle 10min-Daten” die gewünschten Tagesmittelwerte.
|> keep(columns: ["_value", "_time"])
Lasst uns unnötiges Wegschmeißen.
|> filter(fn: (r) => r._value > 0)
Ah, wir interessieren uns ja nur für Tagesmittelwerte über 0°C! Also filtern wir mal auf die. Das macht ja auch jetzt erst Sinn, weil wir vorher noch nicht auf Tagesmittelwerte aggregiert haben.
|> map(fn: (r) => ({
_time: r._time,
_value: r._value * 0.5
}))
Tja, dann müssen wa noch unseren Wert gewichten. Ist ja Januar, also mit 0.5. _time muss mit aufgerufen werden, damits überlebt.
Ok, dasselbe für
feb = from(bucket: "dwd_cdc")
und analog für
rest = from(bucket: "dwd_cdc")
Jetz dieses union():
union(tables: [jan, feb, rest])
|> sort(columns: ["_time"], desc: false)
Sortierung ist wichtig, sonst kommt etwa der 1.-11. Februar zuerst in die Tabelle und dananch erst der 1.-31. Januar und das arme Grafana ist sehr verwirrt und malt plötzlich Kreise. (Srsly. Grafana supports time-travel!)
|> map(fn: (r) => ({
_time: r._time,
_value: r._value,
foo: "GTS Tag"
}))
Boar, diese Beschriften von einzelnen Datenserien ist die Hölle mit Grafana & Flux. Hier fügen wir an jeden Messwert noch nen key-value-Päarchen, damit wir die Serie als “Tag”(eswert) wiedererkennen können.
|> yield(name: "bars")
Weil wir hier grafisch Balken nehmen, heissts “bars” und es wird die Series an genau dieser Stelle per yield() “vermeldet”, also als separate result-Tabelle ausgeworfen und gemalt, ehe wir sie weiter modizifieren. Somit haben wir jetz erstmal alle gewichteten Tagesmittelwerte > 0°C im Bild.
|> cumulativeSum(columns: ["_value"])
Wir wollen aber auch die kummulierte Summe aller Werte! (Bei single stats: Nur sum() )
|> map(fn: (r) => ({
_time: r._time,
_value: r._value,
foo: "GTS Total"
}))
Also benennen wir unser lustiges Feld nochmal um und brauchen es nicht nochmal yield(en), weil wir jetzt ja am Ende sind und damit eh unsere/(die) eine Ergebnistabelle rendern.
Sorry for the buzz, aber wir können jetzt auch die Grünlandtemperatur-Berechnung mit der 10-Tage-Vorhersage weiterführen und dies auch auf die Kältesumme anwenden. Gibts nun in einem einzelnen Panel integriert im Referenz-Dashboard für die Grünlandtemperatursumme, funktioniert auch für Bremen (und auch für den Brocken, wenns etwas kälter sein darf):
… ja, das sind dann auch nur im positiven je Zeitraum drei und für die Vorhersage je nochmal 3x2 = 6 Teilabfragen in einen Query (Kältesumme läuft separat). [Edit: Ein Glück müssen wa nun nicht mehr für die zwei Darstellungen (je Tag vs. akkumulierten Gesamtwert) noch einen Satz Queries fahren. :]
[Edit: Was die Populations-Abschätzung anbelangt muss ich leider feststellen, dass Flux zwar viel mehr tolles Neues kann, aber auch noch einige Grundlagen noch nicht. Zu diesen gehört leider leider auch noch das Rechnen mit Exponenten. 
]
