OpenAQ, Sensor.Community, Grafana.
Ein Agent kann aus diesen drei Namen leicht einen scheinbar vollständigen Plan erzeugen: Daten anbinden, Formate vereinheitlichen, Diagramme anzeigen. Er passt zu fast jedem Projekt mit Datenquellen und Visualisierung. Was die eigentliche Arbeit bestimmt, bleibt unausgesprochen.
OpenAQ bietet nahezu aktuelle und historische Luftqualitätsdaten samt Metadaten. Sensor.Community ist ein von Beitragenden getragenes Umweltsensornetz. Grafana dient der Abfrage und Darstellung von Daten. Ihre vorhandenen Fähigkeiten können zu unterschiedlichen Produkten organisiert werden. OpenAQ-API, Sensor.Community, Grafana-Grundlagen
Eine historische Kandidatenaufzeichnung von ToWow schlug drei Wege vor: Datenadapter, Differenzsonde und Luftqualitätsatlas. Es waren quellenbasierte, unvalidierte Entwürfe. Dieser Text untersucht weiter, wie die Produktwahl die anschließende Arbeit verändert.
Ein Adapter liefert einen wiederholbaren Datenweg
Seine Nutzer haben möglicherweise bereits eine Analyse und möchten ein anderes Eingabeformat nicht jedes Mal von Hand aufbereiten. Zunächst brauchen sie ein stabiles Umwandlungsergebnis.
Die sinnvolle Arbeit liegt in der Feldzuordnung: Wie wird die Messgröße dargestellt, welche Zeitstempelkonvention gilt, wie bleibt die Quelle erhalten, was geschieht bei fehlenden Feldern? Für ein Quellfeld kann es im Ziel keinen Platz geben. Der Adapter muss erklären, wo diese Information bleibt.
Das erste prüfbare Ergebnis darf klein sein: eine Beispieleingabe, die zugehörige Ausgabe und eine Zuordnungserklärung für jedes Feld. Nutzer sollen damit ihren nächsten Schritt ausführen können, ohne die Absicht des Konverters erneut erraten zu müssen.
Der Nutzen liegt in weniger wiederholter Integrationsarbeit. Der passende Vergleich ist deshalb ein vorhandener Konnektor oder ein kurzes Skript: Welche Methode hält dieselben Eingaben leichter korrekt, und wie viel muss bei einer Quellenänderung repariert werden?
Eine Differenzsonde liefert untersuchenswerte Aufzeichnungen
Ihr Nutzer besitzt bereits beide Datenbestände und möchte wissen, welche Unterschiede weitere Prüfung verdienen.
Das Zwischenergebnis kann eine Vergleichstabelle sein. Die folgenden fiktiven Felder veranschaulichen den Entwurf; sie entsprechen weder realen API-Formaten noch tatsächlichen Beobachtungen.
| Aufzeichnung aus Quelle A | Aufzeichnung aus Quelle B | Zuordnungsbedingungen | Nächster Schritt |
|---|---|---|---|
| Messung an einem Ort in einem Zeitraum | Gleichartige Messung in der Nähe im selben Zeitraum | Gleiche Einheit, räumlicher Abstand | Abstand und Messbedingungen erhalten, dann Differenz untersuchen |
| Stundenmittelwert | Momentanwert einer Minute | Unterschiedliche zeitliche Aggregation | Zunächst gleiche Zeitbasis beschaffen |
| Messwert ohne Gerätebeschreibung | Messwert mit Geräteinformationen | Kontext zur Erklärung von Unterschieden fehlt | Metadaten nachschlagen |
Die Tabelle bewahrt eine Entscheidung, die bloßes Zeichnen nicht abnimmt: Warum werden diese Werte verglichen? Bei einer Differenz lässt sich nach Zahlen, Zeit, Ort, Gerät und Verarbeitung fragen.
Der Entwurf kann zunächst einen Ort und einen kurzen Zeitraum bearbeiten und Rohdaten, Zuordnungsschritte sowie Gründe gescheiterter Zuordnung erhalten. Die erste Runde soll einem Nutzer helfen, untersuchenswerte Beobachtungen zu finden. Muss er weiterhin alle Daten neu bereinigen, übernimmt die Tabelle die Hauptarbeit nicht.
Grafana anzuschließen ist hier eine Darstellungsentscheidung. Vergleichbarkeit zu definieren ist der Kern der Sonde. Schon eine gewöhnliche Tabelle kann zeigen, ob dieser Weg nützlich ist.
Ein Atlas liefert eine eigenständig lesbare Erklärung
Seine Leser betreiben möglicherweise keine Pipeline und wollen keine Anomalien einzeln prüfen. Sie möchten verstehen, wie sich ein Ort in einem Zeitraum verändert hat.
Ein exportierbares Bild braucht deshalb Kontext: Ort, Zeitraum, Messgröße, Einheit, Quellen und die zum Verständnis nötigen Erläuterungen. Auch außerhalb des ursprünglichen Systems muss erkennbar bleiben, was es beschreibt.
Das verändert die Visualisierung. Ein Dashboard unterstützt laufend wechselnde Filter. Ein Atlas für andere verlangt eine gewählte Perspektive, Hinweise auf bemerkenswerte Veränderungen und einen Zugang zu Originaldaten. Der Screenshot ist nur ein Teil des Ergebnisses; die Erklärung gehört dazu.
Man kann mit einem Ort und einem Zeitfenster beginnen und das Ergebnis Zielpersonen vorlegen. Was verstehen sie, wo fragen sie nach? Davon hängt ab, ob Interaktion oder mehr Umfang nötig werden. Seiten- und Diagrammzahl liegen weiter vom Zweck entfernt als ein richtiges Verständnis.
Zuerst ein Zwischenergebnis auswählen
Die drei Wege schließen einander nicht aus, müssen aber nicht zugleich beginnen. Der Adapter liefert zuerst eine wiederholbare Umwandlung, die Sonde eine untersuchbare Zuordnung, der Atlas eine eigenständig lesbare Erklärung. Diese ersten Schritte verlangen unterschiedliche Arbeit an Code, Daten und Nutzung.
Ein späterer historischer Lauf erzeugte tatsächlich ein Verzeichnis von Dokumentationsschnappschüssen der drei Projekte mit Bytezahlen, Zeilen, Überschriften und Hashes. Er bereitete Material vor, beschaffte jedoch keine Beobachtungsdaten. Die nächste Prüfung aller drei Wege muss daher mit realen Eingaben und Zielnutzern beginnen. Details des Artefakts stehen im Quellennachweis.
In einem generierenden System wünsche ich mir Vorschläge mit dieser Genauigkeit: Was ist die erste Lieferung, wer nutzt sie für welchen Schritt, und welche Rückmeldung würde die Richtung ändern? Erst dann wird aus einer Werkzeugliste eine voranbringbare Arbeit.