Daten BTW 2017
Closed this issue · 11 comments
Hi, gibt es denn jetzt schon Daten von Sonntag?
Hi, leider noch nicht, aber wir sind dran - @kawie hat heute Mittag eine Informationsfreiheitsanfrage gestellt. Wir halten euch auf dem Laufenden und informieren, wenn es was Neues gibt :)
Die IFG-Anfrage hat zwar leider noch keine Daten geliefert, dafür hat @torfsen aber ein zweites Repository angelegt, um die Daten auf Stadtteilebene zu vergleichen.
Falls jemand die Tage mal Zeit und Lust hat, die Daten der BTW17 reinzunehmen - sie sind jetzt da! :)
Hey zusammen,
ich hab hierfür mal den Branch "election_data_2017" angelegt.
In dem Ordner "resources" habe ich die CSV-Datein "Ergebnisse (Stadtteile)" und "Ergebnisse (Wahlbezirke)" also JSON-Datei abgelegt.
Für die geojson Struktur:
Habt Ihr da ein Script geschrieben, dass die Row-Daten in das richtig Format verarbeitet oder habt Ihr diese per Hand umgeformt?
Cool, danke dir :)
Genau, @torfsen hatte ein Python-Skript geschrieben, mit dem er die Wahlergebnisse von 2013 in das GeoJSON mit den Wahlbezirken gemergt hat. Für 2017 gibt es jetzt kleine Abweichungen in den Wahlbezirken (zum Vergleich: BTW2013 vs. BTW2017). Im ersten Schritt müsste man sich daher genauer anschauen, wo es Abweichungen gibt und wie man mit diesen umgeht.
Ich hab mir jetzt mal angeschaut, wie sich die Wahlbezirke von 2013 auf 2017 geändert haben. Im Prinzip gibt es 3 Kategorien:
- Bezirke, die sich nicht geändert haben
- Bezirke, die sich nur geringfügig geändert haben
- Bezirke, die sich stark geändert haben. Dazu gehören auch Bezirke die in einem anderen Bezirk aufgegangen sind.
Kategorie 1 ist überhaupt kein Problem, bei Kategorie 2 würde ich die Änderungen in der Praxis ignorieren. Spannend ist Kategorie 3, da wir da nicht einfach drüber bügeln können, weil z.B. manche Bezirke von 2013 gar nicht mehr existieren.
Aus Sicht unseres bisherigen UI-Ansatzes ist es aber zwingend notwendig, dass wir eine gemeinsame Einteilung für 2013 und 2017 finden.
Ein Ansatz wäre, für die Kategorie 3 "virtuelle" Bezirke zu bilden, die aus der Vereinigung mehrerer "echter" Bezirke bestehen. Wenn also z.B. der Bezirk A von 2013 bei der Wahl 2017 in den Bezirken B und C aufgegangen ist, dann würde man einen virtuellen Bezirk A + B + C erstellen und die Statistiken entsprechend umrechnen. Dieser wäre dann in seiner Gesamtheit bei beiden Wahlen gleich.
Ich habe die Kandidaten für virtuelle Bezirke mal herausgesucht:
2013 2017
==== ====
006-01, 006-02, 006-03 006-01, 006-02
008-01, 008-02 008-01
008-07, 008-08, 008-09, 008-10 008-06, 008-07, 008-08
012-01, 012-02, 012-03, 012-04, 012-05, 012-06 012-01, 012-02, 012-03, 012-04, 012-05
016-04, 016-05 016-04
017-02, 017-03, 017-04 017-02, 017-03
Jede Zeile ist ein virtueller Bezirk, aufgelistet sind jeweils die Bezirke die 2013 bzw. 2017 darin enthalten wären.
Dazu kommen noch Wahlkreise, bei denen sich die Nummer geändert hat:
2013 2017
==== ====
006-04 006-03
006-05 006-04
006-06 006-05
006-07 006-06
006-08 006-07
008-03 008-02
008-04 008-03
008-05 008-04
008-06 008-05
008-11 008-09
016-06 016-05
016-07 016-06
016-08 016-07
016-09 016-08
Insgesamt keine ideale Situation, aber durchaus in den Griff zu kriegen. Einige Details am UI müsste man dann auch noch anpassen, z.B. müssen wir uns überlegen ob und wie wir die Namen der Bezirke anzeigen.
Was meint ihr?
Aktuell bin ich mir noch nicht sicher, ob wir die Kombination aus den 2013er und 2017er Wahlbezirken immer anzeigen sollen. Von den neun Szenarien gehen ja nur "Wechselwähler*innen" und "Größte Änderung" auf die Unterschiede zwischen den beiden Wahlen ein - für den Rest wären die Wahlbezirke von 2017 ausreichend und genauer.
Aus Sicht unseres bisherigen UI-Ansatzes ist es aber zwingend notwendig, dass wir eine gemeinsame Einteilung für 2013 und 2017 finden.
Andererseits haben wir das Ganze aber wie du schreibst so aufgebaut, dass ein Unterschied der Wahlbezirke zwischen den Szenarien nicht reinpasst. Die Lösung mit den virtuellen Bezirken finde ich da gut - glaube so haben wir den geringsten Eingriff in die Ergebnisse und trotzdem die einheitliche Karte, daher würde ich es tatsächlich so machen. Für die Kennzeichnung und Benennung der virtuellen Wahlbezirke können wir uns ja noch was überlegen.
Guter Hinweis, dass ja nur 2 Visualisierungen die Ergebnisse von 2013 und 2017 nutzen, @hcorinna! Dann hätte ich hier noch einen Vorschlag für die Umsetzung:
Von den 6 virtuellen Bezirken sind bei zweien für 2017 jeweils nur 1 Bezirk dabei (es wurden also mehrere Bezirke von 2013 für 2017 in einem zusammen gelegt). Hier kann man die Stimmen aus 2013 einfach addieren. Verbleiben 4 virtuelle Bezirke mit größeren Änderungen, die entsprechenden Bezirke für 2017 sind:
006-01
006-02
008-06
008-07
008-08
012-01
012-02
012-03
012-04
012-05
017-02
017-03
Also 12 von 188 Bezirken. Dies könnte man in den 2 betroffenen Visualisierungen deaktivieren bzw. entsprechend markieren und mit einem Hinweis versehen (etwa "Dieser Wahlbezirk hat sich gegenüber der Bundestagswahl 2013 stark verändert, so dass kein direkter Vergleich möglich ist").
Dann könnten wir mit der Geometrie von 2017 fahren (bestehende UI kann also weitergenutzt werden) und das Problem wäre klar kommuniziert.
Bei 12 von 188 Bezirken in 2 von 9 Visualisierungen halte ich das für eine vertretbare Lösung.
Was meint ihr?
Hm...schonmal gut zu wissen, dass nur wenige Bezirke betroffen sind. Die virtuellen Bezirke fände ich zumindest für die zwei Vergleichsszenarien nach wie vor gut, aber der Aufwand ist natürlich deutlich größer als die Deaktivierung der betroffenen Bezirke in den beiden Szenarien. Solange wir wie du schreibst klar kommunizieren, was wir gemacht haben, ist der Ansatz der Deaktivierung meiner Meinung nach ein vernünftiger Kompromiss.
Im Nachhinein muss ich sagen, dass ich mit meiner manuellen Zuweisung von Wahlbezirken nicht wirklich glücklich bin: Dieser Ansatz lässt einfach zuviel Spielraum für Ungenauigkeiten. Unser Ziel sollte es auf jeden Fall sein, nur fundierte Daten zu präsentieren -- im Zweifelsfall also lieber nichts zeigen anstatt etwas zu kaschieren. Realität ist, dass sich einige Wahlbezirke teilweise stark verändert haben, also sollten wir das auch so darstellen.
Ich habe mir daher die Daten noch einmal angeschaut und exakt berechnet, wie stark sich die Wahlbezirke in Bezug auf ihre räumliche Verortung geändert haben. Dann habe ich als Untergrenze 95% Übereinstimmung zwischen 2013 und 2017 festgelegt. Damit haben die folgenden 2017er Wahlbezirke keinen eindeutige 2013er Entsprechung:
003-05
003-07
003-09
003-10
004-02
004-03
006-01
006-02
006-03
007-03
007-06
007-07
007-09
008-02
008-06
008-07
008-08
009-01
009-02
009-03
009-04
009-05
009-06
010-04
010-05
010-06
011-02
011-06
012-01
012-02
012-03
012-04
012-05
015-01
015-02
015-03
015-06
015-07
016-03
017-01
017-02
017-03
019-06
019-08
020-07
027-02
027-04
027-05
Das ist eine nicht unerhebliche Zahl, was sich auch auf der Karte niederschlägt -- hier die entsprechenden Bezirke:
Wie aber oben erwähnt halte ich es mittlerweile für schlichtweg falsch, hier so zu tun als hätte sich nichts geändert. Dementsprechend werde ich jetzt schauen, dass ich die 2017er Daten auf dieser Basis in die App einbaue.
Für die Fälle wo 2013er Wahlbezirke 2017 zu einem einzigen Wahlbezirk zusammengelegt wurden würde ich die Daten nachwievor aggregieren.
Für die Ansicht Größte Änderung sollten wir außerdem von der absoluten Änderung (in Stimmen) zu einer relativen Änderung (in Prozentpunkten) übergehen, da wir sonst z.B. Bevölkerungsänderungen oder eine veränderte Wahlbeteiligung falsch berücksichtigen.
Schade, dass die Änderungen doch so groß waren, aber die aktuelle Darstellung passt meiner Meinung nach, vor allem weil schnell erkennbar ist, welche Wahlbezirke für das Szenario ausgeklammert wurden.