Daten nach Datum aufsummieren
- __blackjack__
- User
- Beiträge: 14028
- Registriert: Samstag 2. Juni 2018, 10:21
- Wohnort: 127.0.0.1
- Kontaktdaten:
@viechdokter: Man kann ja mehrere Subplots in eine Figure packen die sich eine X-Achse teilen. Und es sieht immer noch so aus als würdest Du die Datumsangaben als Zeichenketten übergeben und nicht als Datumsobjekte. Mit Zeichenketten kann Matplotlib halt nix anderes anfangen als die einfach so 1:1 darzustellen. Da kann es nicht den Zeitraum ermitteln, und auch nicht Lücken lassen wo keine Werte vorliegen, denn man kann halt keinen (hier sinnvollen) Abstand zwischen zwei Zeichenketten berechnen, wohl aber zwischen zwei Datumsangaben.
„A life is like a garden. Perfect moments can be had, but not preserved, except in memory. LLAP” — Leonard Nimoy's last tweet.
- viechdokter
- User
- Beiträge: 42
- Registriert: Samstag 11. Dezember 2021, 20:52
@__blackjack__ Die subplots habe ich extra übereinander sub-geplottet und nicht zusammen, damit man die Verläufe in den Altersgruppen und die Fallzahlen pro Altersgruppe auf einen Blick sehen kann. Wenn sie alle in einer Figur wären (was ich auch ausprobiert habe), gibt das ein ziemliches Durcheinander an sich überlagernden und kreuzenden Linien. In meiner Darstellung fällt mir zum Beispiel auf, daß die über 80jährigen den 60-79jährigen Fällen zeitlich "hinterherlaufen".
Mit den Datumsobjekten hast du natürlich recht, und das ist genau das nächste, was ich ergründen will. Genau genommen bin ich etwas Python-geschädigt, weil ich ständig Fehlermeldungen bekommen habe, wenn zwei Sachen bei einer " == -Abfrage " nicht 110%ig übereingestimmt haben. In Python ist vieles String, was auf den ersten Blick nach Integer aussieht und man muss ständig alles ineinander umwandeln und anpassen. Sonst gibt es endlose Tracebacks! Vielleicht ist das Datumsobjekt ja wirklich viel einfacher anzuwenden, das wäre schön! Daher gleich mal eine Frage dazu:
Ist denn ein Datumsobjekt, das zum Beispiel "23/12/2021" formatiert ist, identisch (==) mit einem Datumsobjekt, das "23-12-2021 00:00:00 +00" formatiert ist? Oder muß das Format erst umgewandelt werden, damit man die beiden vergleichen kann?
Mit den Datumsobjekten hast du natürlich recht, und das ist genau das nächste, was ich ergründen will. Genau genommen bin ich etwas Python-geschädigt, weil ich ständig Fehlermeldungen bekommen habe, wenn zwei Sachen bei einer " == -Abfrage " nicht 110%ig übereingestimmt haben. In Python ist vieles String, was auf den ersten Blick nach Integer aussieht und man muss ständig alles ineinander umwandeln und anpassen. Sonst gibt es endlose Tracebacks! Vielleicht ist das Datumsobjekt ja wirklich viel einfacher anzuwenden, das wäre schön! Daher gleich mal eine Frage dazu:
Ist denn ein Datumsobjekt, das zum Beispiel "23/12/2021" formatiert ist, identisch (==) mit einem Datumsobjekt, das "23-12-2021 00:00:00 +00" formatiert ist? Oder muß das Format erst umgewandelt werden, damit man die beiden vergleichen kann?
Python..., wie sage ich das jetzt am besten...?
Es liegt nicht an dir. Es liegt an mir...!
Es liegt nicht an dir. Es liegt an mir...!
- __blackjack__
- User
- Beiträge: 14028
- Registriert: Samstag 2. Juni 2018, 10:21
- Wohnort: 127.0.0.1
- Kontaktdaten:
@viechdokter: In einem `Figure` ≠ alle übereinander in einem Plot. Du hast da mehrere Plots, die aber alle eine X-Achse(n-Beschriftung) haben. Die muss man nicht bei jedem Subplot wiederholen, es reicht wenn die am untersten ist. Und die Y-Beschriftung kann man auf dem `Figure`-Objekt setzten, damit ”Fallzahl” einmal, mittig für alle Subplots da steht.
Das ist eigentlich keine Eigenschaft von Python das vieles Zeichenkette ist was nach ganzen Zahlen aussieht. Das ist in den meisten Programmiersprachen so, dass Zahlen was anderes als Zeichenketten sind, also auch Zeichenketten die Ziffern enthalten sind nicht automagisch Zahlen. Es gibt Programmiersprachen die machen das so, aber ich würde dann bei denen eher sagen, dass die den Programmierer schädigen. Und es gibt da in der Regel dann auch die ein oder andere komische Überraschung wenn sich Programme plötzlich komisch verhalten weil eine Zeichenkette, die nur aus Ziffern bestand, tatsächlich eine Zeichenkette sein und auch bleiben sollte, aber dann nicht ist.
Zeichenketten sind nur gleich Zeichenketten die die gleichen Zeichen enthalten. ``"42" == 42`` ergibt `False` und das ist auch gut so. Und eine Zeichenkette ist demnach auch nicht gleich einem Datumsobjekt. Nach welchem Kriterium sollte denn da auch verglichen werden? Soll geraten werden? Beispielsweise bei "02/04/2021" kann man nicht wirklich sagen ob das nun der 2. April oder der 4. Februar ist. Noch schlimmer wird es wenn die Jahreszahl nur zweistellig angegeben ist. Raten kann an in einer Bibliothek machen, wo der Benutzer das an- und abschalten kann und eventuell auch noch Hinweise geben kann, aber grundsätzlich bei allen Vergleichen mit Datumsobjekten mit Zeichenketten zu raten ob das vielleicht passt oder nicht ist weder performant noch robust.
Man muss auch nicht ständig alles umwandeln. Wenn die Daten in das Programm rein kommen wandelt man sie *dort* in eine Repräsentation mit der man arbeiten kann. Also innerhalb des Programms sollte sich in einer Funktion, die etwas mit Zahlen oder Datumswerten macht, nie die Frage stellen ob und wie man da mit Zeichenketten umgeht, weil diese Werte als Zahlen oder Datumsobjekte übergeben werden. Werden sie das nicht, ist irgendwo vorher im Programm was falsch gelaufen. Und das ist wie gesagt auch nicht Python-spezifisch, das macht man in so ziemlich allen Programmiersprachen so, wenn man nicht massive Kopfschmerzen bekommen möchte.
Das ist eigentlich keine Eigenschaft von Python das vieles Zeichenkette ist was nach ganzen Zahlen aussieht. Das ist in den meisten Programmiersprachen so, dass Zahlen was anderes als Zeichenketten sind, also auch Zeichenketten die Ziffern enthalten sind nicht automagisch Zahlen. Es gibt Programmiersprachen die machen das so, aber ich würde dann bei denen eher sagen, dass die den Programmierer schädigen. Und es gibt da in der Regel dann auch die ein oder andere komische Überraschung wenn sich Programme plötzlich komisch verhalten weil eine Zeichenkette, die nur aus Ziffern bestand, tatsächlich eine Zeichenkette sein und auch bleiben sollte, aber dann nicht ist.
Zeichenketten sind nur gleich Zeichenketten die die gleichen Zeichen enthalten. ``"42" == 42`` ergibt `False` und das ist auch gut so. Und eine Zeichenkette ist demnach auch nicht gleich einem Datumsobjekt. Nach welchem Kriterium sollte denn da auch verglichen werden? Soll geraten werden? Beispielsweise bei "02/04/2021" kann man nicht wirklich sagen ob das nun der 2. April oder der 4. Februar ist. Noch schlimmer wird es wenn die Jahreszahl nur zweistellig angegeben ist. Raten kann an in einer Bibliothek machen, wo der Benutzer das an- und abschalten kann und eventuell auch noch Hinweise geben kann, aber grundsätzlich bei allen Vergleichen mit Datumsobjekten mit Zeichenketten zu raten ob das vielleicht passt oder nicht ist weder performant noch robust.
Man muss auch nicht ständig alles umwandeln. Wenn die Daten in das Programm rein kommen wandelt man sie *dort* in eine Repräsentation mit der man arbeiten kann. Also innerhalb des Programms sollte sich in einer Funktion, die etwas mit Zahlen oder Datumswerten macht, nie die Frage stellen ob und wie man da mit Zeichenketten umgeht, weil diese Werte als Zahlen oder Datumsobjekte übergeben werden. Werden sie das nicht, ist irgendwo vorher im Programm was falsch gelaufen. Und das ist wie gesagt auch nicht Python-spezifisch, das macht man in so ziemlich allen Programmiersprachen so, wenn man nicht massive Kopfschmerzen bekommen möchte.
„A life is like a garden. Perfect moments can be had, but not preserved, except in memory. LLAP” — Leonard Nimoy's last tweet.
- viechdokter
- User
- Beiträge: 42
- Registriert: Samstag 11. Dezember 2021, 20:52
- __blackjack__
- User
- Beiträge: 14028
- Registriert: Samstag 2. Juni 2018, 10:21
- Wohnort: 127.0.0.1
- Kontaktdaten:
Ich habe meins auch mal nach Altersgruppen getrennt plotten lassen: 

„A life is like a garden. Perfect moments can be had, but not preserved, except in memory. LLAP” — Leonard Nimoy's last tweet.
- viechdokter
- User
- Beiträge: 42
- Registriert: Samstag 11. Dezember 2021, 20:52
Ist es möglich, ein horizontales Grid in alle subplots zu bekommen? Ich bekomme es nur in das unterste.
Und wie hast du die rechte und obere Begrenzung der subplots entfernt?
Und wie hast du die rechte und obere Begrenzung der subplots entfernt?
Python..., wie sage ich das jetzt am besten...?
Es liegt nicht an dir. Es liegt an mir...!
Es liegt nicht an dir. Es liegt an mir...!
- __blackjack__
- User
- Beiträge: 14028
- Registriert: Samstag 2. Juni 2018, 10:21
- Wohnort: 127.0.0.1
- Kontaktdaten:
@viechdokter: `Axes`-Objekte haben eine `grid()`-Methode. Einfach auf jedem Subplot aufrufen, entweder mit `True` als Argument, oder konkreten Wünschen wie das gezeichnet werden soll. Ich hab's bei mir mal gemacht, wobei ich auch vertikal zeichnen lasse — die Hauptticks sind da bei mir ja nur die beiden Jahreszahlen:

Die „spines“ oben und rechts waren doch schon bei meinem ersten einzelnen Plot weg. Dafür gab's schon den Quelltext. Aber hier noch mal komplett für den aktuellen Stand:

Die „spines“ oben und rechts waren doch schon bei meinem ersten einzelnen Plot weg. Dafür gab's schon den Quelltext. Aber hier noch mal komplett für den aktuellen Stand:
Code: Alles auswählen
#!/usr/bin/env python3
from pathlib import Path
import pandas as pd
from matplotlib import pyplot as plt
from matplotlib.dates import DateFormatter, MonthLocator, YearLocator
SELF_PATH = Path(__file__).parent
CSV_FILE_PATH = SELF_PATH / "RKI_COVID19_Niedersachsen.csv"
def main():
LANDKREIS = "SK Braunschweig"
data = pd.read_csv(
"RKI_COVID19_Niedersachsen.csv",
parse_dates=["Meldedatum", "Refdatum"],
infer_datetime_format=True,
)
data = (
data[
(data["Landkreis"] == LANDKREIS)
& (data["Altersgruppe"] != "unbekannt")
][["Meldedatum", "Altersgruppe", "AnzahlFall"]]
.groupby(["Altersgruppe", "Meldedatum"])
.sum()
)
age_groups = data.groupby("Altersgruppe")
figure, axes = plt.subplots(
len(age_groups), sharex=True, sharey=True, figsize=(10, 7)
)
for (age_group_name, group_data), ax in zip(age_groups, axes):
ax.plot(
group_data.loc[age_group_name].index,
group_data["AnzahlFall"],
linewidth=1,
color="tab:red",
)
ax.xaxis.set_major_locator(YearLocator())
ax.xaxis.set_minor_locator(MonthLocator())
ax.xaxis.set_minor_formatter(DateFormatter("%m"))
for label in ax.xaxis.get_minorticklabels():
label.set_name("Roboto Condensed")
ax.grid(linestyle=":", linewidth=1)
for side in ["top", "right"]:
ax.spines[side].set_visible(False)
ax.set_title(
f" {age_group_name.replace('A', '').replace('-', '–')} Jahre",
fontsize="small",
loc="left",
y=0.9,
verticalalignment="top",
)
figure.suptitle(
f"Corona-Fallzahlen im {LANDKREIS} nach Meldetag und Altersgruppe"
)
figure.supylabel("Fallzahl")
figure.tight_layout()
plt.show()
if __name__ == "__main__":
main()
„A life is like a garden. Perfect moments can be had, but not preserved, except in memory. LLAP” — Leonard Nimoy's last tweet.
- viechdokter
- User
- Beiträge: 42
- Registriert: Samstag 11. Dezember 2021, 20:52
Ich sehe bei dir unheimlich effizienten Code mit einer Menge shortcuts, Wahnsinn! Wieviele Jahre machst du eigentlich schon Python?
Interessant find ich übrigens auch, daß das Aufhübschen der Grafik doppelt soviel Code braucht wie die Berechnung der Daten selbst. Die Berechnung steckt sogar nur in den paar Zeilen nach dem zweiten "data = ...", wenn ich das richtig sehe:
Mein eigenes Programm brauchte letzlich so um die 100 Zeilen (ohne die Kommentare). Aber da ich bisher noch nie von pandas&Co. gehört hatte, bin ich schon ganz stolz, daß ich überhaupt brauchbare Ergebnisse bekommen habe.
Ich bin übrigens noch einen Schritt weiter gegangen und habe mal recherchiert, wieviele Menschen in Deutschland in die einzelnen Altersgruppen gehören. Von Braunschweig selber finde ich keine genauen statistischen Daten zur Altersverteilung. Wenn ich aber davon ausgehe, daß die Altersverteilung hier in Braunschweig ungefähr der in ganz Deutschland entspricht, sind zwei Altersgruppen prozentual gesehen deutlich überrepräsentiert bei den Fallzahlen. Da fängt es an, spannend zu werden.
Außerdem frage ich mich, warum das RKI ausgerechnet diese seltsamen Altersgruppengrenzen für die Statistik verwendet hat. Sie sind erstens völlig ungleich "bevölkert", ungleich "lang" und soziologisch keiner wirklichen Bevölkerungsgruppe zuzuordnen (wie z.B. Schulkinder (6-16 oder sogar 18 Jahre), junge Erwachsene (18-25 Jahre?), Berufseinsteiger o.ä.) Es sieht irgendwie zusammengewürfelt aus. Ich gehe davon aus, daß sie intern wesentlich genauere Unterteilungen benutzen. Aber wir können ja schon froh sein, überhaupt Daten öffentlich verfügbar zu bekommen. Ich will mich also nicht beschweren...
Irgendwann, wenn ich soweit bin, kann ich dann mal versuchen, eine "Zeitkarte" zu programmieren, auf der man sehen kann, wie sich die Fälle im Land "ausbreiten". Da scheint es schon interaktive Landkarten zu geben, die man einbinden könnte. Aber das ist noch ein langer, entbehrungsreicher Weg mit vielen IndexErrors usw.
Interessant find ich übrigens auch, daß das Aufhübschen der Grafik doppelt soviel Code braucht wie die Berechnung der Daten selbst. Die Berechnung steckt sogar nur in den paar Zeilen nach dem zweiten "data = ...", wenn ich das richtig sehe:
Code: Alles auswählen
data = (
data[
(data["Landkreis"] == LANDKREIS)
& (data["Altersgruppe"] != "unbekannt")
][["Meldedatum", "Altersgruppe", "AnzahlFall"]]
.groupby(["Altersgruppe", "Meldedatum"])
.sum()
)
Mein eigenes Programm brauchte letzlich so um die 100 Zeilen (ohne die Kommentare). Aber da ich bisher noch nie von pandas&Co. gehört hatte, bin ich schon ganz stolz, daß ich überhaupt brauchbare Ergebnisse bekommen habe.
Ich bin übrigens noch einen Schritt weiter gegangen und habe mal recherchiert, wieviele Menschen in Deutschland in die einzelnen Altersgruppen gehören. Von Braunschweig selber finde ich keine genauen statistischen Daten zur Altersverteilung. Wenn ich aber davon ausgehe, daß die Altersverteilung hier in Braunschweig ungefähr der in ganz Deutschland entspricht, sind zwei Altersgruppen prozentual gesehen deutlich überrepräsentiert bei den Fallzahlen. Da fängt es an, spannend zu werden.
Außerdem frage ich mich, warum das RKI ausgerechnet diese seltsamen Altersgruppengrenzen für die Statistik verwendet hat. Sie sind erstens völlig ungleich "bevölkert", ungleich "lang" und soziologisch keiner wirklichen Bevölkerungsgruppe zuzuordnen (wie z.B. Schulkinder (6-16 oder sogar 18 Jahre), junge Erwachsene (18-25 Jahre?), Berufseinsteiger o.ä.) Es sieht irgendwie zusammengewürfelt aus. Ich gehe davon aus, daß sie intern wesentlich genauere Unterteilungen benutzen. Aber wir können ja schon froh sein, überhaupt Daten öffentlich verfügbar zu bekommen. Ich will mich also nicht beschweren...
Irgendwann, wenn ich soweit bin, kann ich dann mal versuchen, eine "Zeitkarte" zu programmieren, auf der man sehen kann, wie sich die Fälle im Land "ausbreiten". Da scheint es schon interaktive Landkarten zu geben, die man einbinden könnte. Aber das ist noch ein langer, entbehrungsreicher Weg mit vielen IndexErrors usw.
Python..., wie sage ich das jetzt am besten...?
Es liegt nicht an dir. Es liegt an mir...!
Es liegt nicht an dir. Es liegt an mir...!
- viechdokter
- User
- Beiträge: 42
- Registriert: Samstag 11. Dezember 2021, 20:52
Ich weiß, die Formatierung der Grafik könnte besser sein...



Python..., wie sage ich das jetzt am besten...?
Es liegt nicht an dir. Es liegt an mir...!
Es liegt nicht an dir. Es liegt an mir...!
- __blackjack__
- User
- Beiträge: 14028
- Registriert: Samstag 2. Juni 2018, 10:21
- Wohnort: 127.0.0.1
- Kontaktdaten:
@viechdokter: Der älteste sinnvolle, noch erhaltene Python-Quelltext den ich von mir habe ist von Januar 2003. Und inhaltlich kommt das auch mit meinem Umstieg von Perl auf Python hin, weil der Grund damals mein Frust über Perl bei einem Skript war, mit dem ich die benutzten Instrumente in MIDI-Dateien untersucht hatte. Was dann auch das besagte Python-Skript macht.
Das Ungleichgewicht bei der Anzahl der Code-Zeilen zwischen einlesen und vorverarbeiten der Daten und dem anpassen des Plots kommt massgeblich von Pandas denke ich mal. Das ist halt ein Werkzeug was genau für solche typischen Aufgaben wie einlesen, filtern, und aggregieren von tabellarischen Daten gemacht ist.
Wenn ich so gut wie alles rumbasteln am Plot rauswerfe, kommt das hier dabei heraus:

Da sieht man ganz gut den Unterschied zwischen Texten bei Deinem Plot und Datumsobjekten bei Meinem als Daten für die X-Achse. Die Beschriftung wird hier von Matplotlib automagisch ausgewählt, sowohl was die Anzahl und Positionen angeht, als auch dass Jahr und Datum als Text dran steht. Weil mit Datumsobjekten gerechnet werden kann. Und man muss auch nicht selbst 0-Werte für nicht vorhandene Datumsangaben einfügen, weil auch bei unregelmässig verteilten Datenpunkten die korrekte Position auf der X-Achse ausgerechnet wird.
Subplot-Überschriften lassen sich hier für die Altersgruppen nicht ohne dran rum zu basteln nutzen, weil die entweder in die anderen Subplots hineinragen, zu klein sind, oder wenn man Platz dafür schafft (was auch wieder Code braucht) dann steht weniger Platz für die Y-Achsen der Daten zur Verfügung. Der Platz dafür ist ja sowieso schon recht knapp. Darum habe ich hier die Legende für die Anzeige der Altersgruppen genommen. Die automatische Platzierung der Legende wird pro Subplot gemacht. Das ist natürlich unschön, weil das hier nicht regelmässig ist, aber in allen Plots oben links Platz gewesen wäre.
Um sich schnell mal einen Überblick zu verschaffen und als Ausgangspunkt sind die Voreinstellungen ganz okay, aber wenn man es irgendwo zeigen möchte, bastel ich an der Darstellung in der Regel immer noch ein bisschen herum um überflüssges rauszuwerfen und die Darstellung klarer zu machen.
Zu den Altersgruppen: Die müssen ja irgendwie eine Schnittmenge bilden aus dem was die einzelnen Bundesländer an Einteilungen machen und ans RKI melden, und auch für Corona-Meldungen und für Todesfälle gleich sein. Da gibt's vielleicht auch unterschiedliche Einteilungen. Und das dann vielleicht auch noch mal pro Bundesland.
Ansonsten sind es vielleicht Gruppen, die für Gesundheitsämter eine Bedeutung haben. 0-4 sind Säuglinge und Kleinkinder. 5-14 sind Schulkinder, danach sind's keine Kinder mehr sondern mindestens mal Jugendliche und das kommt auch mit Einschulung + in der Regel 9 Jahre Schulpflicht hin. Also 15-34 dann Jugendliche und junge Erwachsene. 35-59 Erwachsene und ältere Erwachsene. 60-79 Senioren und Rentner. 80+ scheintot.
Das Ungleichgewicht bei der Anzahl der Code-Zeilen zwischen einlesen und vorverarbeiten der Daten und dem anpassen des Plots kommt massgeblich von Pandas denke ich mal. Das ist halt ein Werkzeug was genau für solche typischen Aufgaben wie einlesen, filtern, und aggregieren von tabellarischen Daten gemacht ist.
Wenn ich so gut wie alles rumbasteln am Plot rauswerfe, kommt das hier dabei heraus:

Da sieht man ganz gut den Unterschied zwischen Texten bei Deinem Plot und Datumsobjekten bei Meinem als Daten für die X-Achse. Die Beschriftung wird hier von Matplotlib automagisch ausgewählt, sowohl was die Anzahl und Positionen angeht, als auch dass Jahr und Datum als Text dran steht. Weil mit Datumsobjekten gerechnet werden kann. Und man muss auch nicht selbst 0-Werte für nicht vorhandene Datumsangaben einfügen, weil auch bei unregelmässig verteilten Datenpunkten die korrekte Position auf der X-Achse ausgerechnet wird.
Subplot-Überschriften lassen sich hier für die Altersgruppen nicht ohne dran rum zu basteln nutzen, weil die entweder in die anderen Subplots hineinragen, zu klein sind, oder wenn man Platz dafür schafft (was auch wieder Code braucht) dann steht weniger Platz für die Y-Achsen der Daten zur Verfügung. Der Platz dafür ist ja sowieso schon recht knapp. Darum habe ich hier die Legende für die Anzeige der Altersgruppen genommen. Die automatische Platzierung der Legende wird pro Subplot gemacht. Das ist natürlich unschön, weil das hier nicht regelmässig ist, aber in allen Plots oben links Platz gewesen wäre.
Um sich schnell mal einen Überblick zu verschaffen und als Ausgangspunkt sind die Voreinstellungen ganz okay, aber wenn man es irgendwo zeigen möchte, bastel ich an der Darstellung in der Regel immer noch ein bisschen herum um überflüssges rauszuwerfen und die Darstellung klarer zu machen.
Zu den Altersgruppen: Die müssen ja irgendwie eine Schnittmenge bilden aus dem was die einzelnen Bundesländer an Einteilungen machen und ans RKI melden, und auch für Corona-Meldungen und für Todesfälle gleich sein. Da gibt's vielleicht auch unterschiedliche Einteilungen. Und das dann vielleicht auch noch mal pro Bundesland.
Ansonsten sind es vielleicht Gruppen, die für Gesundheitsämter eine Bedeutung haben. 0-4 sind Säuglinge und Kleinkinder. 5-14 sind Schulkinder, danach sind's keine Kinder mehr sondern mindestens mal Jugendliche und das kommt auch mit Einschulung + in der Regel 9 Jahre Schulpflicht hin. Also 15-34 dann Jugendliche und junge Erwachsene. 35-59 Erwachsene und ältere Erwachsene. 60-79 Senioren und Rentner. 80+ scheintot.
„A life is like a garden. Perfect moments can be had, but not preserved, except in memory. LLAP” — Leonard Nimoy's last tweet.
- viechdokter
- User
- Beiträge: 42
- Registriert: Samstag 11. Dezember 2021, 20:52
Das mit 80+ habe ich jetzt mal einfach überlesen...
aber "automagisch " ist ein schönes Wort für all das, was diese Bibliotheken so im Hintergrund leisten. Jetzt, wo ich mich ziemlich viel mit Pyplot beschäftigt und einiges (wennauch lange nicht alles) über die grafische Dartsellung von Daten gelernt habe, werde ich wohl verstärkt versuchen, mich in Pandas einzuarbeiten. Da braucht man nicht soviel Code zu schreiben... 
Danke, daß du mich bezüglich der 0-er-Tage auch endlich "erhellt" hast. Das hat im Hintergrund weiter an mir genagt...
Es könnte allerdings bei einem Linienplot, wenn zwei Nicht-Nuller über einen oder mehrere Nullertage hinweg verbunden werden, ein falscher Eindruck entstehen, daß es an diesen Nullertagen doch Fälle gegeben hat. Ich glaube, da in deinen Diagrammen ein paar größere "Ausrutscher" bei 7/2020 in AK15-35 und AK35-59 sowie zwei lange Fehlerstrecken bei den Altersgruppen darunter am Anfang zu sehen. Da sollte man dann doch lieber barplot oder scatter benutzen, was? Alternativ könnte man nicht benutzte Daten direkt auf Null setzen lassen, was wahrscheinlich bei Pandas auch nur 1 Zeile mehr wäre. Bei mir hatte ich das über die Nuller-dictionaries mit viel Aufwand gelöst...
Am unglücklichsten finde ich übrigens bei den Altersklassen die 15-34 gewählt. Völlig unterschiedliche Lebenssituationen und damit Ansteckungsrisiken. Übrigens gibt es wesentlich mehr 80+ (ca 6 Mio) als 0-4 (ca. 4 Mio)!
Danke, daß du mich bezüglich der 0-er-Tage auch endlich "erhellt" hast. Das hat im Hintergrund weiter an mir genagt...
Am unglücklichsten finde ich übrigens bei den Altersklassen die 15-34 gewählt. Völlig unterschiedliche Lebenssituationen und damit Ansteckungsrisiken. Übrigens gibt es wesentlich mehr 80+ (ca 6 Mio) als 0-4 (ca. 4 Mio)!
Python..., wie sage ich das jetzt am besten...?
Es liegt nicht an dir. Es liegt an mir...!
Es liegt nicht an dir. Es liegt an mir...!
@viechdoktor
ich habe beruflich mit solchen medizinischen Stratifizierungen zu tun. In der Regel wählt man diese auf Basis medizinischer Gegebenheiten/Risikoprofile für z.B. bestimmte Erkrankungen.
Im konkreten Fall würde ich vermuten, dass hier ggf. bestimmte "Ausbildungsstufen" des Immunsystems eine Rolle spielen. Evtl. spielt auch die Risikowahrscheinlichkeit für Lungenerkrankungen oder Diabetes eine Rolle.
Es ist bei dieser Art von Clusterbildung nicht das Ziel "gleich große" Gruppen zu haben, sondern die Individuen innerhalb der Gruppe sollen möglichst gut untereinander vergleichbar /homogen sein, so dass man darauf basierend weitere Kennzahlen/Indikatoren bauen kann.
Insbesondere bei Mortalitätsraten ist das eben ein Unterschied, wie sinnvoll die Cluster gebildet sind. Würde man hier "gleich" große Gruppen bilden, kämen leider Aussagen heraus, die an groben Unfug grenzen.
Skizze:
Man könnte ja folgendes überlegen:
Menschen werden ca. 80 Jahre alt. Also teilt man in der Mitte.
Gruppe 1: 0 -39 Jahre
Gruppe 2: ab 40 Jahre
Würde man hiervon die Mortalitätsraten berechnen, hätte man ein recht verzerrtes Bild darüber, wie viele junge Menschen betroffen sind.
LG
ich habe beruflich mit solchen medizinischen Stratifizierungen zu tun. In der Regel wählt man diese auf Basis medizinischer Gegebenheiten/Risikoprofile für z.B. bestimmte Erkrankungen.
Im konkreten Fall würde ich vermuten, dass hier ggf. bestimmte "Ausbildungsstufen" des Immunsystems eine Rolle spielen. Evtl. spielt auch die Risikowahrscheinlichkeit für Lungenerkrankungen oder Diabetes eine Rolle.
Es ist bei dieser Art von Clusterbildung nicht das Ziel "gleich große" Gruppen zu haben, sondern die Individuen innerhalb der Gruppe sollen möglichst gut untereinander vergleichbar /homogen sein, so dass man darauf basierend weitere Kennzahlen/Indikatoren bauen kann.
Insbesondere bei Mortalitätsraten ist das eben ein Unterschied, wie sinnvoll die Cluster gebildet sind. Würde man hier "gleich" große Gruppen bilden, kämen leider Aussagen heraus, die an groben Unfug grenzen.
Skizze:
Man könnte ja folgendes überlegen:
Menschen werden ca. 80 Jahre alt. Also teilt man in der Mitte.
Gruppe 1: 0 -39 Jahre
Gruppe 2: ab 40 Jahre
Würde man hiervon die Mortalitätsraten berechnen, hätte man ein recht verzerrtes Bild darüber, wie viele junge Menschen betroffen sind.
LG
- __blackjack__
- User
- Beiträge: 14028
- Registriert: Samstag 2. Juni 2018, 10:21
- Wohnort: 127.0.0.1
- Kontaktdaten:
@viechdokter: Ui, wenn man Linie zeichnen an Tagen mit 0-Meldungen weg lässt:

Das waren jetzt mit Pandas 5 Zeilen mehr um die Daten vor dem Plotten zu resamplen, damit alle Tage einen Wert haben, und die dadurch eingefügten 0-Werte durch NaN zu ersetzen, damit Matplotlib dort beim Zeichnen die Linie unterbricht:
@Buchfink: So etwas in der Richtung hatte ich vermutet. Das vielleicht mit 35 die Leute einen Partner haben und gesetzter werden/sind und da so langsam Couch-Kartoffel-Symptome anfangen auf die Gesundheit einzuwirken. 

Das waren jetzt mit Pandas 5 Zeilen mehr um die Daten vor dem Plotten zu resamplen, damit alle Tage einen Wert haben, und die dadurch eingefügten 0-Werte durch NaN zu ersetzen, damit Matplotlib dort beim Zeichnen die Linie unterbricht:
Code: Alles auswählen
group_data = (
group_data.resample("D", level="Meldedatum")
.sum()
.replace(0, math.nan)
)
„A life is like a garden. Perfect moments can be had, but not preserved, except in memory. LLAP” — Leonard Nimoy's last tweet.
- viechdokter
- User
- Beiträge: 42
- Registriert: Samstag 11. Dezember 2021, 20:52
Ich hatte es an einigen Stellen in deinem Plot gesehen, daß die Linien nicht stimmen können, aber jetzt fällt auf, wie viele falsch geplottete Tage darunter waren. Warum lässt du die Daten nicht auf Null statt auf NaN und plottest sie einfach mit?__blackjack__ hat geschrieben: Donnerstag 23. Dezember 2021, 16:57 @viechdokter: Ui, wenn man Linie zeichnen an Tagen mit 0-Meldungen weg lässt:
5 Zeilen Code mehr? Das ist grenzwertig! Gibt es da nicht auch schon wieder eine Bibliothek, die einem diese extreme Arbeit abnimmt?


Python..., wie sage ich das jetzt am besten...?
Es liegt nicht an dir. Es liegt an mir...!
Es liegt nicht an dir. Es liegt an mir...!
- viechdokter
- User
- Beiträge: 42
- Registriert: Samstag 11. Dezember 2021, 20:52
@Buchfink Danke für die Erklärung. An medizinische Risikofaktoren hatte ich bisher gar nicht gedacht, sondern immer nur an soziologische Faktoren, Lebensumstände usw. Da könntest du natürlich recht haben. Meinst du, daß das RKI intern die Daten wesentlich feiner strukturiert? 6 Altersklassen erscheint mir immer noch recht grob...
Python..., wie sage ich das jetzt am besten...?
Es liegt nicht an dir. Es liegt an mir...!
Es liegt nicht an dir. Es liegt an mir...!
- __blackjack__
- User
- Beiträge: 14028
- Registriert: Samstag 2. Juni 2018, 10:21
- Wohnort: 127.0.0.1
- Kontaktdaten:
@viechdokter: Na wenn ich die 0 nicht ersetze, dann sind das vier Zeilen weniger, weil dann der verbleibende Ausdruck auf eine Zeile passt, womit das hinzufügen der fehlenden Daten mit dem Wert 0 tatsächlich nur eine weitere Code-Zeile ist:
Code: Alles auswählen
group_data = group_data.resample("D", level="Meldedatum").sum()
„A life is like a garden. Perfect moments can be had, but not preserved, except in memory. LLAP” — Leonard Nimoy's last tweet.
@__blackjack__
ab 35 ist bei den meisten "der Lack ab"
Neulich hatte ich auch mal einen Artikel zur Hand, dass es zwei biolgische "Altersstufen" gibt, bei denen die Verschleißerscheinungen sprunghaft steigen. 35 Jahre war einer dieser Punkte und dann später nochmal 70 Jahre (Den Artikel finde ich leider nicht mehr)
Tja nun
@viechdoktor
Wenn man sich das Meldeblatt anschaut, wird in Brandenburg z.B. das Geburtsdatum des Patienten erfasst:
https://www.rki.de/DE/Content/Infekt/If ... cationFile
Wenn die Daten per FHIR übertragen werden, würde ich vermuten, dass wohl das Geburtsdatum übertragen wird.
https://simplifier.net/covid-19labormel ... nt-example
Das wäre natürlich am einfachsten für's RKI, denn auf Basis des Geburtsdatums kann man natürlich die Cluster so bilden, wie man sie zu Auswertungszwecken konkret braucht.
Ich bin mir allerdings, wie oben bereits erwähnt nicht sicher, ob das auch so zum RKI exportiert werden darf. In den meisten mir bekannten Softwaresystemen im stationären und niedergelassenen Bereich wird aber ohnehin über das Geburtsdatum des Patienten gearbeitet. (Man kennt das, wenn man zum Arzt geht und die immer nach dem Geburtsdatum fragen)
D.h. in diesen Bereich ist das Geburtsdatum des Patienten quasi immer im System bereits irgendwo vorhanden (weil man das auch zur Abrechnung mit der Krankenkasse braucht)
Aber aus Datenschutzgründen wäre es denkbar, dass statt des Geburtsdatums das Alter (in Monaten oder Jahren) exportiert wird. Auch auf dieser Basis hätte das RKI ja aber auch die Möglichkeit "relativ" beliebige Cluster zu bilden.
Ich möchte erwähnen, dass ich zwar was ähnliches beruflich mache, aber um eine wirklich qualifizierte Aussage dazu zu treffen, müsste man wohl mehr Zeit investieren als ich das jetzt getan habe. Ich habe jetzt nur sehr grob überflogen, was das RKI für SWA zur Verfügung stellt. Und HL7 / FHIR ist eine Wissenschaft für sich. Es gibt dafür eigene Schulungen etc
LG
Edit: Der Werwolf ist dem Wessenwolf sein Tod, Genitiv-Korrektur
ab 35 ist bei den meisten "der Lack ab"

Neulich hatte ich auch mal einen Artikel zur Hand, dass es zwei biolgische "Altersstufen" gibt, bei denen die Verschleißerscheinungen sprunghaft steigen. 35 Jahre war einer dieser Punkte und dann später nochmal 70 Jahre (Den Artikel finde ich leider nicht mehr)
Tja nun

@viechdoktor
Das hängt davon ab, wie sie die Daten erfassen bzw. wie diese zum RKI _genau_ exportiert werden. Hier müsste man sich im Detail die Spezifikation ansehen.Meinst du, daß das RKI intern die Daten wesentlich feiner strukturiert? 6 Altersklassen erscheint mir immer noch recht grob...
Wenn man sich das Meldeblatt anschaut, wird in Brandenburg z.B. das Geburtsdatum des Patienten erfasst:
https://www.rki.de/DE/Content/Infekt/If ... cationFile
Wenn die Daten per FHIR übertragen werden, würde ich vermuten, dass wohl das Geburtsdatum übertragen wird.
https://simplifier.net/covid-19labormel ... nt-example
Das wäre natürlich am einfachsten für's RKI, denn auf Basis des Geburtsdatums kann man natürlich die Cluster so bilden, wie man sie zu Auswertungszwecken konkret braucht.
Ich bin mir allerdings, wie oben bereits erwähnt nicht sicher, ob das auch so zum RKI exportiert werden darf. In den meisten mir bekannten Softwaresystemen im stationären und niedergelassenen Bereich wird aber ohnehin über das Geburtsdatum des Patienten gearbeitet. (Man kennt das, wenn man zum Arzt geht und die immer nach dem Geburtsdatum fragen)
D.h. in diesen Bereich ist das Geburtsdatum des Patienten quasi immer im System bereits irgendwo vorhanden (weil man das auch zur Abrechnung mit der Krankenkasse braucht)
Aber aus Datenschutzgründen wäre es denkbar, dass statt des Geburtsdatums das Alter (in Monaten oder Jahren) exportiert wird. Auch auf dieser Basis hätte das RKI ja aber auch die Möglichkeit "relativ" beliebige Cluster zu bilden.
Ich möchte erwähnen, dass ich zwar was ähnliches beruflich mache, aber um eine wirklich qualifizierte Aussage dazu zu treffen, müsste man wohl mehr Zeit investieren als ich das jetzt getan habe. Ich habe jetzt nur sehr grob überflogen, was das RKI für SWA zur Verfügung stellt. Und HL7 / FHIR ist eine Wissenschaft für sich. Es gibt dafür eigene Schulungen etc

LG
Edit: Der Werwolf ist dem Wessenwolf sein Tod, Genitiv-Korrektur
- viechdokter
- User
- Beiträge: 42
- Registriert: Samstag 11. Dezember 2021, 20:52
@__blackjack__ Neue Bibliotheken, neue Fehler...! Ich habe mir mal ein Einsteigertutorial für Pandas angesehen und folgenden Code ausprobiert:
1. findet er nur Objekte. Ich hätte gedacht, daß er auch Zahlen finden müsste. Die Fallzahlen eben. IdBundesland;"Bundesland";"Landkreis";"Altersgruppe";"Geschlecht";"AnzahlFall";"AnzahlTodesfall";"ObjectId";"Meldedatum";"IdLandkreis";"Datenstand";"NeuerFall";"NeuerTodesfall";"Refdatum";"NeuGenesen";"AnzahlGenesen";"IstErkrankungsbeginn";"Altersgruppe2" object
dtype: object
2. er scheint nur eine column zu finden (Data columns (total 1 columns):)
3. Ich bekomme ein riesenlanges Traceback zum Thema: KeyError: "Meldedatum", obwohl Meldedatum doch in den Überschriften vorhanden ist.
Was mache ich diesmal falsch?
Code: Alles auswählen
import pandas as pd
covid_df = pd.read_csv('RKI_COVID19.csv')
print (covid_df.dtypes)
print(covid_df.info())
meldedatum = covid_df["Meldedatum"]
print(meldedatum)
dtype: object
2. er scheint nur eine column zu finden (Data columns (total 1 columns):)
3. Ich bekomme ein riesenlanges Traceback zum Thema: KeyError: "Meldedatum", obwohl Meldedatum doch in den Überschriften vorhanden ist.
Was mache ich diesmal falsch?
Python..., wie sage ich das jetzt am besten...?
Es liegt nicht an dir. Es liegt an mir...!
Es liegt nicht an dir. Es liegt an mir...!
- viechdokter
- User
- Beiträge: 42
- Registriert: Samstag 11. Dezember 2021, 20:52
@Buchfink 
Da bin ich von beiden, gottseidank, weit weg!dass es zwei biolgische "Altersstufen" gibt, bei denen die Verschleißerscheinungen sprunghaft steigen. 35 Jahre war einer dieser Punkte und dann später nochmal 70 Jahre

Python..., wie sage ich das jetzt am besten...?
Es liegt nicht an dir. Es liegt an mir...!
Es liegt nicht an dir. Es liegt an mir...!
- viechdokter
- User
- Beiträge: 42
- Registriert: Samstag 11. Dezember 2021, 20:52
Sorry, ich habe gerade herausgefunden, daß es verschiedene Formate dieser Covid-Datei gibt. Die, bei der es nicht geklappt hat, hatte Semikolons als Trennzeichen. Warum auch immer. Ich habe die Datei noch einmal neu heruntergeladen, und jetzt hat sie Kommas und alles funktioniert. Dann fummele ich mich mal weiter durch Pandas!
Python..., wie sage ich das jetzt am besten...?
Es liegt nicht an dir. Es liegt an mir...!
Es liegt nicht an dir. Es liegt an mir...!