Nach dem Erhalt der Daten haben wir uns die Frage gestellt, was das Ziel der Visualisierung sein soll. Deshalb haben wir uns das Ausmass der Daten angesehen und uns überlegt, welchen Mehrwert die zu programmierende Visualisierung bieten soll, dies war zugleich die grösste Herausforderung in diesem Schritt. Nach langem Reflektieren haben wir uns entschlossen, dass wir die Störungsmeldungen von den drei Verkehrsbetrieben miteinander vergleichen. Gleichzeitig haben wir uns darauf geeinigt, dass wir die geplanten von den ungeplanten Störungsmeldungen trennen, damit beim Vergleich der Verkehrsbetriebe kein verzerrtes Bild entsteht.
Auf Basis des festgelegten Zieles haben wir in den D3-Bibliotheken nach einer geeigneten Visualisierungsmöglichkeit gesucht, die die Störungsmeldungen von den verschiedenen Verkehrsbetrieben darstellt. Uns ist schnell klar geworden, dass wir für die geplanten und ungeplanten Verkehrsmeldungen nicht die gleiche Visualisierung benutzen wollen. Der Grund der Entscheidung war die Diskrepanz im Mengengerüst zwischen den geplanten und ungeplanten Störungsmeldungen, sowie auch die hierarchischen Beziehungen, die von den Grundideen ausgingen. Den Fokus bei den ungeplanten Verkehrsmeldungen haben wir auf den Tageszeitpunkt sowie Linien und bei den geplanten Verkehrsmeldungen auf den Jahreszeitpunkt sowie die Häufigkeit gesetzt. Für die ungeplanten Verkehrsmeldungen eignete sich ein Pack-Layout während zu den geplanten Verkehrsmeldungen ein Bar-Chart und ein Line-Chart passte.
Als nächsten Schritt haben wir nach Snipp-Codes gesucht und mit dem Programmieren begonnen. Die Snipp-Codes konnten wir nicht 1:1 übernehmen und mussten diverse Anpassungen vornehmen, die aber nicht auf Anhieb geklappt haben. Zwischendurch entstanden auch Zweifel an der Visualisierung und wir haben uns immer wieder die Frage nach dem Mehrwert gestellt und sind dann wieder zum ersten Schritt zurückgegangen.
Wir haben die Daten dann nach Typ unter uns aufgeteilt, da sich jeder so auf ein Layout und eine Darstellung konzentrieren konnte. Bei den ungeplanten Verkehrsstörungen mussten wir eine tiefere Bereinigung vornehmen. Oft kam es vor, das Zellenwerte von Störungsmeldungen fehlten oder sich Werte untereinander widersprachen. Da wir aber kein «verschönendes» Bild der Meldungen kreieren wollten, haben wir versucht die Werte an die Meldung anzupassen.
Nachdem die Werte der Störungsmeldungen frei von Fehlern waren, konnten wir dann mit der Struktur der Daten beginnen. Für die geplanten Verkehrsstörungen musste eine Aggregation der Störungsmeldungen je Monat, beginnend mit dem Startpunkt durchgeführt werden. Die Berechnungen haben wir in einem Excel-File durchgeführt und anschliessend in einem csv-Format übertragen.
Für die ungeplanten Verkehrsstörungen haben wir Zeitcluster nach bestimmten Perioden erstellt und die Startzeitpunkte der Störungen den Clustern zugeordnet. Unser Ziel war es eine Aussage über die Frage «Welche Linie war in welcher Zeitperiode wie hoch (in absoluten Zahlen) belastet» machen zu können. Demzufolge mussten die in den Clustern drin eine erneute Gliederung und Aggregation der Störungen nach Linien vornehmen. Um auch eine Aussage über die Belastungsdauer der Störungen machen zu können, haben wir auch die Dauer der Störungen ausgerechnet, um sie später im Tooltip anzuzeigen.
Nachdem die Daten für beide Typen bereinigt und strukturiert waren, konnten die mit der Datentransformation beginnen. Für die geplanten Verkehrsstörungen konnten wir die bestehenden csv-Files der Verkehrsbetriebe anwenden. Das Pack-Layout erforderte jedoch eine hierarchische Darstellung der Daten und so mussten wir die csv-Formate in ein JSON-File umschreiben.
Nachdem wir die passenden Snipp-Codes in unsere Editoren eingebettet hatten, mussten wir noch zahlreiche Anpassungen vornehmen bis sie einwandfrei funktionierten. Unter der Anwendung von HTML, CSS und JavaScript konnten wir nach zahlreichen Fehlversuchen sämtliche Tags und Befehle nach unseren Wünschen umschreiben.
Nachdem wir die Codes angepasst hatten, bemerkten wir, dass das JSON-File wegen zu wenigen Hierarchiestufen noch einmal bearbeitet werden musste. Erst dann entsprach die Darstellung unserer ursprünglichen Idee.
Die visuellen Darstellungen der Codes waren sehr ansehnlich, jedoch fehlte ein passendes Layout für die App. Mithilfe von Bootstrap konnten wir diese Lücke dann auch schliessen und uns nach vielen Absprachen auf ein Gesamtlayout einigen.
