Diskussionsthread EDOMI-Releases/Updates

[gaert]

Und schon erledigt - man hat ja nix besseres zu tun

• Breite bzw. Höhe: legt die Breite bzw. Höhe der Visuelemente fest (relativ oder absolut)
  • Hinweis: die Größe der Visuelemente wird nicht automatisch begrenzt (z.B. durch die Ränder der Visuseite)
  • •
    : legt fest, ob die Angabe relativ oder absolut angewendet wird
    • deaktiviert: die Angabe wird relativ angewendet, dabei kann die Angabe entweder in Pixeln oder in Prozent erfolgen
      • Angabe in Pixeln: z.B. verringert "-5" die aktuelle Breite bzw. Höhe des Visuelement um 5, "7" erhöht diese um 7
      • Angabe in Prozent: z.B. verringert "-50%" die aktuelle Breite bzw. Höhe des Visuelement um 50%, "70%" erhöht diese um 70%
    • aktiviert: die Angabe wird absolut angewendet, z.B. setzt "3" die Breite bzw. Höhe auf 3

[shortyle]

Gibt jetzt nur noch gerade Zahlen als Größenangaben

[gaert]

Wäre denkbar, allerdings kann dies natürlich zu Rundungsfehlern führen (falls Du z.B. 50% von 103px berechnen lassen möchtest). Ich pack's mal uff Liste

[shortyle]

Kurze Frage zum neuen Feature seit 1.62 bei dem mehrere Visuelemente gleichzeitig bearbeitet werden können. Ist es möglich, das Verkleinern/Vergrößern auch prozentual zu erlauben? Somit könnte man auch unterschiedlich große Elemente gleichzeitig und gleichmäßig vergrößern bzw. verkleinern.
zB.
Ausgangswert: Element1 B100 H100 und Element2 B50 H50
Ziel: B50 H50 und B25 und B25
Aktuell kann ich die beiden Elemente nicht gemeinsam um die Hälfte verkleinern sondern müsste dies einzeln erledigen.

Falls die Frage schon gestellt wurde (habe nichts dazu gefunden) bitte ich um Nachsicht

[gaert]

(Hilfetext in #872 aktualisiert)

[gaert]

Weil's so schön ist, werden die Verdichtungen dann auch gelogged (das Löschen älterer Einträge übrigens demnächst auch):

...
2019-02-04 05:54:35	569093	EXEC	36299	Datenarchiv (1) verdichtet: 4665 Einträge von 8608 verrechnet und entfernt, 3943 Einträge verbleibend	Ok

[gaert]

Upps... Bedankt!

[Brick]

Freu mich...

eine Woche entspricht dabei einem Zeitraum von Montag bis Sonntag - auch über Jahresgrenzen

[gaert]

Hier schonmal die (vorläufige) Hilfe vorab:

• Automatische Datenverdichtung: ermöglicht optional das Zusammenfassen älterer Einträge innerhalb eines Intervalls z.B. zu einem Mittelwert
  • die automatische Datenverdichtung berechnet z.B. monatliche Mittelwerte sämtlicher Einträge eines Zeitraums und fügt diesen berechneten Wert (anstelle der zugrunde liegenden Einträge) in das Datenarchiv ein
  • dieser Vorgang wird beim Start von EDOMI und jeweils täglich um 00:00:00 Uhr ausgeführt
  • Achtung: Die der Berechnung zugrunde liegenden Einträge werden dauerhaft aus dem Datenarchiv gelöscht!
  • Wichtig: Eine Verdichtung erfolgt nur, wenn innerhalb des entsprechenden Intervalls mindestens 2 Einträge vorhanden sind.
  • Datenverdichtung: aktiviert ggf. die automatische Datenverdichtung und legt die Art der Berechnung fest
    • deaktiviert: die automatische Datenverdichtung ist deaktiviert, die nachfolgenden Optionen werden ausgeblendet
    • Mittelwert berechnen: die Einträge im angegebenen Intervall (s.u.) werden addiert und durch deren Anzahl geteilt (Mittelwert)
    • Minimum berechnen: es wird der kleinste Eintrag im angegebenen Intervall (s.u.) ermittelt
    • Maximum berechnen: es wird der größte Eintrag im angegebenen Intervall (s.u.) ermittelt
  • Berechnungsintervall: definiert den Zeitraum der Einträge, die zu einem einzelnen Wert verdichtet werden sollen
    • stündlich: sämtliche Einträge jeweils einer vollen Stunde werden zu einem Wert zusammengefasst
    • täglich: sämtliche Einträge jeweils eines Wochentages werden zu einem Wert zusammengefasst
    • wöchentlich: sämtliche Einträge jeweils einer Kalenderwoche werden zu einem Wert zusammengefasst
    • monatlich: sämtliche Einträge jeweils eines Monats werden zu einem Wert zusammengefasst
    • jährlich: sämtliche Einträge jeweils eines Jahres werden zu einem Wert zusammengefasst
  • Mindestalter: legt zusammen mit der Einheit (s.u.) das Mindestalter der Einträge fest, die verdichtet werden sollen
    • erlaubt sind nur ganzzahlige Angaben im Bereich 1..∞
  • Einheit: definiert die Einheit für das zuvor angegebene Mindestalter
    • "gleitend": die Einheit bezieht sich unmittelbar auf das aktuelle Datum/Uhrzeit (Beispiel: es ist der 15.03.2019 12:30:00 Uhr, die Angabe "1 Tage (gleitend)" umfasst alle Einträge bis zum 14.03.2019 12:29:29 Uhr)
      • Stunden: die Einträge müssen älter als [Mindestalter] Stunden sein, eine Stunde entspricht dabei 60 Minuten (z.B. ist heute Mittwoch 15:30:00 Uhr, "1 Stunde" führt zu einer Verdichtung sämtlicher Daten bis einschließlich Mittwoch 14:29:29 Uhr)
      • Tage: die Einträge müssen älter als [Mindestalter] Tage sein, ein Tag entspricht dabei 24 Stunden (z.B. ist heute Mittwoch 15:30:00 Uhr, "1 Tag" führt zu einer Verdichtung sämtlicher Daten bis einschließlich Dienstag (Gestern) 15:29:29 Uhr)
      • Wochen: die Einträge müssen älter als [Mindestalter] Wochen sein, eine Woche entspricht dabei 7 Tagen (z.B. ist heute Mittwoch 15:30:00 Uhr, "1 Woche" führt zu einer Verdichtung sämtlicher Daten bis einschließlich Dienstag letzter Woche 15:29:29 Uhr)
      • Monate: die Einträge müssen älter als [Mindestalter] Monate sein, ein Monat entspricht dabei 28..31 Tagen (z.B. ist heute der 15. März 15:30:00 Uhr, "1 Monat" führt zu einer Verdichtung sämtlicher Daten bis einschließlich zum 14. Februar 15:29:29 Uhr)
      • Jahre: die Einträge müssen älter als [Mindestalter] Jahre sein, ein Jahr entspricht dabei 365/366 Tagen (z.B. ist heute der 15.03.2019 15:30:00 Uhr, "1 Jahr" führt zu einer Verdichtung sämtlicher Daten bis einschließlich zum 14.03.2018 15:29:29 Uhr)
    • "kalendarisch": die Einheit beschreibt stets einen vollen Tag bzw. Stunde, Woche, Monat oder Jahr (Beispiel: es ist der 15.03.2019 12:30:00 Uhr, die Angabe "1 Tage (kalendarisch)" umfasst alle Einträge bis zum 14.03.2019 23:59:59 Uhr)
      • Stunden: die Einträge müssen älter als [Mindestalter] volle Stunden sein (z.B. ist es aktuell 15:30:00 Uhr, "1 Stunde" zu einer Verdichtung sämtlicher Daten bis einschließlich 14:59:59 Uhr)
      • Tage: die Einträge müssen älter als [Mindestalter] Wochentage sein (z.B. führt "2 Tage" zu einer Verdichtung sämtlicher Daten bis einschließlich Vorgestern)
      • Wochen: die Einträge müssen älter als [Mindestalter] Wochen sein, eine Woche entspricht dabei einem Zeitraum von Montag bis Sonntag - auch über Jahresgrenzen hinweg (z.B. ist heute Mittwoch, "1 Woche" führt zu einer Verdichtung sämtlicher Daten bis einschließlich Sonntag letzter Woche 23:59:59 Uhr)
      • Monate: die Einträge müssen älter als [Mindestalter] Monate sein, ein Monat entspricht dabei einem Zeitraum vom 1. bis 28./29./30./31. des entsprechenden Monats (z.B. ist heute der 15. Mai, "1 Monat" führt zu einer Verdichtung sämtlicher Daten bis einschließlich zum 30. April 23:59:59 Uhr)
      • Jahre: die Einträge müssen älter als [Mindestalter] Jahre sein, ein Jahr entspricht dabei einem Zeitraum vom 01.01. bis 31.12. des entsprechenden Jahres (z.B. ist heute der 15.03.2019, "1 Jahr" führt zu einer Verdichtung sämtlicher Daten bis einschließlich zum 31.12.2018 23:59:59 Uhr)
  • Zeitstempel: legt die zeitliche Einordnung (Datum und Uhrzeit) des berechneten Wertes fest
    • Anfang/Mitte/Ende (Quelldaten): der berechnete Wert wird am Anfang/Mitte/Ende der für die Berechnung verfügbaren Einträge im angegebenen Intervall eingefügt (liegen z.B. für das Intervall "wöchentlich" nur Einträge am Mittwoch und Freitag vor, wird der berechnete Wert am Mittwoch (Anfang), Donnerstag (Mitte) oder Freitag (Ende) eingefügt)
    • Anfang/Mitte/Ende (Intervall): der berechnete Wert wird am Anfang/Mitte/Ende des angegebenen Intervalls eingefügt, unabhängig von den für die Berechnung verfügbaren Einträge (liegen z.B. für das Intervall "wöchentlich" nur Einträge am Mittwoch und Freitag vor, wird der berechnete Wert dennoch am Montag (Anfang), Donnerstag (Mitte) oder Sonntag (Ende) eingefügt)
  • Nachkommastellen: der berechnete Wert wird ggf. auf die angegebene Anzahl von Nachkommastellen gerundet

Bildschirmfoto 2019-02-05 um 07.28.54.png

[TSD]

Stimmt, da habe ich nicht dran gedacht. Weitermachen! ;-)

[saegefisch]

Macht man das nicht am besten mit dem min/Max-LBS und von vornherein mit einem eigenen Archiv? Im selben Archiv ergibt (finde ich) nicht so viel Sinn...

[TSD]

Klasse gaert!: Wird es dann auch möglich sein die Min und Maxwerte in separate Datenarchive zu speichern? Grade beim Temperaturwert fände ich das interessant. Evtl. kann man soetwas auch über ein Funktionsfeld lösen?

[gaert]

Naja, hier geht es um "Komprimierung" und nicht um komplexere mathematische Berechnungen. Ein (zeitlich) gewichteter Mittelwert ist durchaus komplexer, ist aber für diese neue Funktion der Komprimierung nicht unbedingt erforderlich - denn hier geht's primär um das Einsparen von Ressourcen (auf Kosten der Genauigkeit und Lesbarkeit natürlich).

Wenn Du unbedingt wissen musst, wann es vor fünf Jahren wie stark geregnet hat...

[Winni]

Warum nicht? Wenn Du z.B. in einem Monat 50 mal 1 und 50 mal 0 hast kommt 0,5 bei heraus. Dies zeigt doch dann sehr schön, dass der Zustand zu 50% der Zeit 1 war.

Du berechnest den Mittelwert incl. Gewichtung aufgrund der Zeit? Ich hab in einer Stunde 20 mal 0 für Trocken und 20mal 1 für Regen in den ersten 10 Minuten und dann 1 durchgehend für die restlichen 10 Minuten. Dann bekomme ich ca. 0,84 berechnet, weil es in der Stunde zu 84% geregnet hat?
Das wäre dann durchaus eine Option. Was passiert in der nächsten Stunde, in der ich evtl. nur eine 0 habe, die in der 58. Minuten auftritt, weil es das Regnen aufgehört habe.
Bitte nicht falsch verstehen, wenn es anderen weiterhilft ist es schön, wenn es dieses Feature gibt. Ich kann jedoch aktuell in nur sehr wenigen Fällen einen Vorteil erkennen. Eine einfach Mittelwertbildung funktioniert nur bei gleichmäßigen Wertintervallen. In einem Regendiagramm das im aktuellen Bereich mit 0/1 arbeitet, in der Vergangenheit aber plötzlich mit Prozentwerten fungiert ist schwierig zu lesen. Ich(!) würde dann lieber ein zweites verdichtetes Archiv aufbauen.
Meine Archive sind meistens recht groß, weil in relative kurzen Zeitintervallen viele eigentlich unnütze Daten eintreffen, da würde mir oben beschriebenes Verfahren eher weiterhelfen. Aber wie gesagt, ich werd' bei Gelegenheit mal versuchen einen LBS zu stricken, schön wäre eine PHP Grundlage wie man sowas am effektivsten angehen könnte.

[gaert]

Es gibt zumindest bei mir einige 0/1 Diagramme, da macht ein Mittelwert keinen Sinn

Warum nicht? Wenn Du z.B. in einem Monat 50 mal 1 und 50 mal 0 hast kommt 0,5 bei heraus. Dies zeigt doch dann sehr schön, dass der Zustand zu 50% der Zeit 1 war.

Der Sinn der Komprimierung ist es ja gerade, Details zu verlieren um den Datenumfang zu verringern.