Improving time range control for "grafanimate"

Entwicklung / Development Benutzerschnittstelle / User interface / API
, ,
1

Introduction

  • Daten anschaulicher machen.
  • Erzeugung von Anschauungsmaterial.
  • Die Tagesschau hat auch Wetterfilme.

About

Usage examples

2

Kumulative Zeitintervalle mit grafanimate

Frage:

Ack. Hab ich mir auch schon immer gewünscht ;). Dazu finden sich bereits ein paar Dinge im grafanimate/doc/backlog.rst at 0.5.5 · panodata/grafanimate · GitHub.

  • [o] Start- und Endtime in Unix Epoch oder sogar gemischt (@weef)
  • [o] Introduce ad-hoc mode:
    # Run on designated dashboard, starting time range control at 2015-10-01 with an interval of 1 day
grafanimate http://localhost:3000/d/1aOmc1sik/luftdaten-info-coverage --start=20151001 --interval=1d
  • [o] Implement different datetime output and formatting flavours
  • [o] Actually honor options --start, --end and --interval additionally to the scenario interface

Diskussion

Das Beispiel

z.B. : ab 1.2. bis jetzt, tägliche Bilder

entspräche doch so ziemlich der Notiz

starting time range control at 2015-10-01 with an interval of 1 day

Anforderung

Kumulativ: Alle Frames bekommen einen fixen Startzeitpunkt (oder Endzeitpunkt), nur der Zeitraum (range) wird immer größer – eben in $interval-Inkrementen.

Gedanken

Für einen Film müssen wir jedoch immer Start und Ende angeben, sonst… Das ist also gesetzt, no matter what. Bem.: Bitte korrigiert mich, wenn ich hier falsch liege.

Für die Umsetzung dieses Wunschs brauchen wir also eine orthogonale --cumulative Option o.ä., die einen entsprechenden Modus auslöst oder Vergleichbares. Können wir daraus konkrete Vorschläge für Syntax und Semantik erarbeiten? Ich implementiere das dann gerne wie gewünscht.

3

sowas wünsche ich mir:

statista-14d-back-forward

1 Like
4

Betriebsmodi und deren Semantik

Ich könnte mir vorstellen, dass der aktuell implementierte Betriebsmodus zukünftig per --slide angesteuert werden könnte, während der neu gewünschte der Standardbetriebsmodus wird.

Angelehnt an das aktuelle Interface

self.engine.run(
  dtstart=datetime(2018, 3, 6, 5, 0, 0), 
  dtuntil=datetime(2018, 3, 10, 23, 59, 59), 
  interval='hourly')

wären folgende Modi bzw. Parameter denkbar:

1. Kumulativer Modus

--dtstart=2019-04-01T00:00:00 --dtuntil=now --interval=hourly

Hier müssten wir noch differenzieren, wo ggf. der Anker gesetzt werden soll - ob am Anfang oder am Ende, à la

1.a Expand (Default)

  • Modus: Anker ist am Anfang.
  • Start: Der Zeitraum geht von dtstart bis dtstart + interval.
  • Fortschritt: Zeitraum wird in Richtung Ende erweitert, jeweils + interval.

--dtstart=2019-04-01T00:00:00 --dtuntil=now --interval=hourly --expand

vs.

1.b Shrink

  • Modus: Anker ist am Ende.
  • Start: Der Zeitraum geht von dtstart bis dtuntil.
  • Fortschritt: Zeitraum wird in Richtung Ende verringert, jeweils - interval.

--dtstart=2019-04-01T00:00:00 --dtuntil=now --interval=hourly --shrink

2. Sliding-window Modus

Das wäre der Aufruf für den bisherigen Betriebsmodus, den man zukünftig explizit anfragen müsste:
--dtstart=2019-04-01T00:00:00 --dtuntil=now --interval=hourly --slide

P.S.: Alternative Begriffe für besseres “naming things” nehme ich dankend entgegen.

6

Seitenblicke

Grafana GeoLoop Panel

Wie steuert man das denn beim GeoLoop?
https://grafana.com/plugins/citilogics-geoloop-panel

In den Einstellungen gibt es zwar ein
image

So recht schlau werde ich daraus aus der Ferne aber nicht.

Unten steht:

Cinematography » 2D Animation Glossary

Blender and F-Curves

7

Coming from this verbose Blender scenario “cycling” example, I liked the jargon …

def cycling_scenario(obj):

    lamp = obj.data

    data_path = 'nodes["Emission"].inputs[1].default_value'
    for fr in [100, 130, 150, 200, 300]:
        fr2 = fr+10
        lamp.node_tree.keyframe_insert(data_path=data_path, frame=fr)
        lamp.node_tree.keyframe_insert(data_path=data_path, frame=fr2)

    for fc in lamp.node_tree.animation_data.action.fcurves:
        for kp in fc.keyframe_points:
            kp.interpolation = 'CONSTANT'

– http://web.purplefrog.com/~thoth/blender/python-cookbook/animate-cycles-lamp-strength.html

and came up with a

Proposal

For a compact variant for achieving this (vgl. Betriebsmodi und deren Semantik) as well as to finally leave our “dope sheet” programming behind for basic tasks, I am proposing a simple command line interface like…

1. Cumulative mode

  • Useful for visualizing data expansion over time with graph-like panels.
  • Starting point for each exposure step will always be --dtstart.
  • Expand covered time range by incrementing interval determined by --dtrange.
grafanimate \
  --grafana-url=https://daq.example.org/ --dashboard-uid=1aOmc1sik \
  --dtstart=2019-04-01T00:00:00 --dtuntil=now --dtrange=15m

2. Cycling mode

  • Useful for visualizing data with map-like panels.
  • Limit each exposure step to a specific point in time or time range.
  • Covered time range is determined by cycling through intervals specified by --dtrange.

Just add --cycle.

3. Reverse

Just add --reverse.

9

  • Das mit dem cycling gefällt mir nicht so, dafür gibts im Animationsbereich bereits Verwendung, z.B. für walk cycle. So ein repetitives Moment ist bei Deinem mode 2 ja gar nicht gemeint, sondern die sich aus dtrange ergebenden ‘key frames’ konstituieren immer start und end des frames.

  • reverse könnte komfortabel werden, noch einfacher vielleicht die Angabe einer negativen dtrange - weniger Tippen. ;)

  • alternativ zu dtrange (aka interval) wäre die Angabe der (max.) Anzahl der ‘Einzelbilder’ schön.

  • die beiden themes sollten alternativ auswählbar sein

btw, FLUX hat eine intervals()-Funktion (eigentlich ein helper für window()), da könntest Du Dir ggf. noch Anregungen holen (bei erweitertem Syntax bzw. den Beispielen auf der verlinkten Seite).

1 Like
10

Merci @weef.

Neues --intervals – wie Flux

The intervals() function generates a set of time intervals over a range of time.

Ui, danke! Schönes Interface. Damit konvergiert --cycle definitiv hin zu --intervals, dann muss man auch nicht umlernen.

Negatives --dtrange

Hatte ich auch schon überlegt. Warum nicht.

--frames

Warum nicht. Können wir das nicht berechnen? Grafana muss schließlich in jedem Fall mit time ranges angesteuert werden. Also --dtrange=len(dtend-dtstart) / frames?

--theme

Du meinst die Grafana themes light vs. dark, ja?

1 Like
11

Ja.

Da kann man sich nun ewig ausspinnen mit Auf- und Abrunden und Mindest-Frame-Anzahl und right trim und left trim, oder --exact , wenn start und stop auf Punkt stimmen müssen, dann muß halt intervall übergangen werden usw. usf. Aber muß man alles auch nicht machen, es soll ja kein Schnittprogramm werden!

Themes: ja, die beiden Grafana-eigenen.

neg. dtrange vs. reverse: soll sich nicht ausschließen, wenn man Bildanzahl angibt, bräuchte man reverse, dann ginge kein neg. dtrange.

Aus dem Flux-Universum:

range(start:2019-01-31T23:00:00Z, stop:-1h)

… ist auch schick, da es relative und absolute Zeitpunkte mischen kann (die ‘-1’ bei stop lies: ‘now-1h’)

1 Like
12

Neues --dtrange – wie Flux

Gefällt mir auch sehr. Sollten wir auf --dtrange legen und damit --dtstart sowie --dtuntil ersetzen. Brauchen wir dann das ursprüngliche --dtrange überhaupt noch oder kommen wir dort mit --intervals aus?

Besseres --cycle

Verstehe ich. Hast Du einen besseren Vorschlag, wie wir eine entsprechende Option nennen können, wenn das “kumulative” Vorgehen (s.u.) der default ist?

Vielleicht einfach --slide im Sinne von “sliding window” – wie oben schonmal erwähnt?

Neuer Vorschlag

grafanimate \
  --grafana-url=https://daq.example.org/ --dashboard-uid=1aOmc1sik \
  --dtrange="range(start:2019-01-31T23:00:00Z, stop:-1h)" \
  --dtintervals="intervals(every:15m)"

Credits

Zwischenstand

Fühlt sich rund für mich an. Die Implementierung muss leider noch ein wenig warten. Sag bitte Bescheid, sobald Du Dein Filmset wieder aufbauen willst. Nicht dass am Ende noch die Crew meutert…

13

Na, nutz mal schon weiter Deine pythonesken argv-Parser (äh, config-Parser), Du sollst ja nicht gleich den syntax des Beispiels nehmen! ;) Aber wenn Dir das im scenario mode besser integrierbar erscheint, dann halt so. Wäre mir für auch einen gescripteten command line -Aufruf zu umständlich, das als string zu übergeben, bzw. als etwas, was wie der direkte Funktionsaufruf aussieht. Egal, kleine Befindlichkeit. Aber es wäre schon anders, als Dein bisheriger style, z.B. bei phenodata .

Mir ging es in diesem Beispiel nur darum, Vereinbarkeit von relativen und absoluten start- und stop-Punkten anzudeuten; da war mir Flux willkommen.

ist jetzt eine unnötige Doppelung, oder sogar Verdreifachung. Und das ‘every’ hier auch noch besonders. Kommt daher:

Flux does not support positional arguments or parameters. Parameters must always be named when calling a function.

Deshalb muß leider auch bei dieser Funktion, die nur ein Parameter hat, dessen Name angegeben werden… brauchen wir hier nicht, steht ja schon zweimal zuvor! Also entweder --dtintervals, --intervals oder --every.
Insofern gerne anstelle --dtstart --start nehmen, und --stop anstelle von --dtuntil.

Bei Flux ist außerdem das stop beim range() implizit, daher kann man das stop: weglassen, es wird dann immer now für stop verwendet, ebenso wie bei relativen Angaben wie stop: -1h (wird zu stop: now-1h) . Inzwischen gehen auch Dinge wie -10d12h30m42s.

==>
--start 2019-01-31T23:00:00Z --stop -1h --every 15m

OK? 8)

1 Like
14

Ist mir sehr recht, dann spart man sich auf jeden Fall erstmal den Parser. Und dann noch optional mit --slide oder --reverse bzw. negativem --every?

15

It’s a start already.

Synopsis

now = datetime.now()
yesterday = now - timedelta(days=1)
tomorrow = now + timedelta(days=1)

# Choose one.
intervals = SlidingPeriodicInterval(start=yesterday, stop=tomorrow, every=timedelta(days=1))
intervals = CumulativePeriodicInterval(start=yesterday, stop=tomorrow, every=timedelta(days=1))

for interval in intervals:
    print('{} - {}'.format(interval.start, interval.end))

Examples

$ python grafanimate/timecontrol.py

# Sliding forward
2019-04-21 02:15:04.067580 - 2019-04-22 02:15:04.067580
2019-04-22 02:15:04.067580 - 2019-04-23 02:15:04.067580

# Sliding reverse
2019-04-22 02:15:04.067580 - 2019-04-23 02:15:04.067580
2019-04-21 02:15:04.067580 - 2019-04-22 02:15:04.067580

# Cumulative I (unaligned)
2019-04-21 02:15:04.067580 - 2019-04-22 02:15:04.067580
2019-04-21 02:15:04.067580 - 2019-04-23 02:15:04.067580

# Cumulative II (aligned)
2019-04-22 02:00:00 - 2019-04-22 02:15:00
2019-04-22 02:00:00 - 2019-04-22 02:30:00
2019-04-22 02:00:00 - 2019-04-22 02:45:00
2019-04-22 02:00:00 - 2019-04-22 03:00:00
2019-04-22 02:00:00 - 2019-04-22 03:15:00
2019-04-22 02:00:00 - 2019-04-22 03:30:00
2019-04-22 02:00:00 - 2019-04-22 03:45:00
2019-04-22 02:00:00 - 2019-04-22 04:00:00

Implementation

16

Gerade entdeckt. Geht das vielleicht sogar schon, indem Du jene Stelle im Code bei Dir änderst?

19

About

grafanimate 0.6.0 wurde gerade veröffentlicht. Dank geht an @wtf und @weef, sowohl für den Impuls als auch für einige der hier besprochenen Featurevorschläge.

Beispiel

Szenarien können nun komfortabler beschrieben werden. So kann das aussehen:

Details

Kumulierende Zeitintervalle

Diese Möglichkeit gibt es jetzt, per Adjust the sequencing mode (window, cumulative) by amotl · Pull Request #7 · panodata/grafanimate · GitHub und entsprechender Einstellung mode=SequencingMode.CUMULATIVE.

Accept more timestamp formats

Das klappt jetzt ebenfalls, per When parsing timestamps, allow ISO8801/RFC3339 and Epoch time by amotl · Pull Request #10 · panodata/grafanimate · GitHub.

Out-of-tree Szenariodateien

Bisher musste die integrierte Szenariobeschreibungsdatei grafanimate/scenarios.py bearbeitet werden, um eigene Filme zu entwickeln. Das ist nun nicht mehr nötig, per Introduce a data model for defining animation-scenarios and -sequences by amotl · Pull Request #8 · panodata/grafanimate · GitHub können Szenarien aus beliebigen Python Modulen oder Dateien geladen werden.

3 Likes