In den ersten beiden Teilen meiner informellen Blog-Serie zu Datenqualität habe ich den Begriff der Datenqualität etwas genauer eingeführt und gezeigt, für welche Betrachtungseinheiten man die Datenqualität grundsätzlich beschreiben kann. Letzteres geht nämlich nicht nur auf Datensatz-Ebene, sondern zum Beispiel auch auf Feature- oder Objekt-Ebene, auf Attribut-Ebene etc. In diesem dritten Teil möchte ich nochmals tiefer einsteigen und die Datenqualitätsmasse erläutern, die der Standard ISO 19157 kennt. Erst diese konkreten Masse geben dem etwas abstrakten Begriff der «Datenqualität» diskutier- und kritisierbaren Inhalt.

Fünf interne Masse und ein externes

ISO 19157 unterscheidet für räumliche Daten zwischen internen Datenqualitätsmassen, die sich aus dem Datensatz selbst beziehungsweise aus dem Vergleich mit einer Referenz herleiten lassen, und einem externen Datenqualitätsmass, das den Bezug zur beabsichtigten Anwendung herstellt. Ich beziehe mich hier auf ISO 19157:2013 und das Amendment von 2018 – die neue Fassung aus 2023, ISO 19157:2023, welche die frühere Fassung dereinst ablösen wird, geht das Thema leicht anders an, vor allem die Usability-Komponente.

In der Übersicht postuliert ISO 19157:2013 folgende Masse für die Datenqualität:

• Interne Datenqualitätsmasse
  • Vollständigkeit
  • Logische Konsistenz
  • Lagegenauigkeit
  • Thematische Genauigkeit
  • Zeitliche Genauigkeit
    
• Externes Datenqualitätsmass
  • Usability

Am Rand: Der Metadatenstandard des US-amerikanischen Federal Geographic Data Committee (FGDC), den man manchmal im Kontext von US-amerikanischer Software antrifft, setzt die Akzente etwas anders: Das FGDC nennt zusätzlich die sogennante Lineage – also die Herkunft und sämtliche Aufbereitungsschritte der Daten – und die Wolkenbedeckung, als relevante Masse. Die Wolkenbedeckung ist natürlich nur eine sinnvolle und potenziell wertvolle Information für optische Fernerkundungsdaten – also selbst innerhalb der Geodaten ein kleines Subset der gängigen Datenarten. Das FGDC verzichtet dafür aber interessanterweise auf die zeitliche Genauigkeit. Man sieht: Datenqualität zu operationalisieren ist kein triviales Unterfangen. Selbst etablierte Standards setzen unterschiedliche Prioritäten.

Im Folgenden gehe ich die sechs Datenqualitätsmasse nach ISO der Reihe nach durch.

Vollständigkeit: In beide Richtungen!

Vollständigkeit beschreibt das Vorhandensein oder das Fehlen von Dateninhalten wie Features, ihren Attributen und ihren Beziehungen untereinander. Auslassungen oder Einfügungen in Daten können bewusst entstehen (zum Beispiel durch Generalisierung oder die Anwendung von Minimaldimensionen bzw. minimum mapping units) oder aber unbewusst durch Mess-, Erhebungs- oder Aufbereitungsfehler.

Wichtig – und in der Praxis gerne vergessen – ist, dass Abweichungen von der Vollständigkeit in beide Richtungen gehen können. Man spricht in diesem Zusammenhang von diesen zwei Fehlern:

• Completeness omission: Der Datensatz enthält ein Feature nicht, das enthalten sein sollte. Vergleiche auch den Begriff error of omission.
  
• Completeness commission: Der Datensatz enthält ein Feature, das nicht enthalten sein sollte. Vergleiche auch den Begriff error of commission.

Wer einen Datensatz also auf Vollständigkeit prüft, sollte nicht nur fragen, was möglicherweise fehlt, sondern auch, was eventuell zu viel ist. Weiter unten tauchen die beiden Konzepte commission und omission nochmals auf, bei der thematischen Genauigkeit.

Logische Konsistenz: Mehrdimensional

ISO 19157 unterteilt die logische Konsistenz von Daten in vier Aspekte:

• Konzeptionelle Konsistenz: Stimmt der Dateninhalt mit dem gewünschten konzeptionellen Schema überein? Werden zum Beispiel die Kardinalitäten von Beziehungen eingehalten? Im Minimalen Geodatenmodell (MGDM) «Basismodell Sachpläne» (pdf) des Bundes wäre das etwa die Frage, ob die Beziehungen zwischen Objekten der Klasse SectoralPlan und ihren abhängigen Objekten korrekt instanziiert sind (vgl. Abbildung oben oder Seite 10 im pdf).
  
• Domänenkonsistenz: Halten die Attributwerte die Domänen des jeweiligen Attributs (Wertebereiche, Wertelisten bzw. -kataloge) ein? Im obigen MGDM-Beispiel muss Document.Language einem LanguageCode_ISO639_1 entsprechen, also «de», «fr», «it», «en» und so weiter und nicht zum Beispiel «Deutsch» , «frz.» oder «Italian».
  
• Topologische Konsistenz: Werden Standard-Konventionen (zum Beispiel keine self-intersections von Polygonen) und gewünschte topologische Beziehungen eingehalten?
  
  Bei den administrativen Grenzen aus swissBOUNDARIES3D erwartet man keine Überlappungen von Gemeinden untereinander bzw. von Kantonen untereinander sowie keine Lücken* zwischen Gemeinde- und Kantonsgrenzen.
  * im Allgemeinen … – die uneinheitliche Handhabung von Seen im Datensatz der Gemeindegrenzen lassen wir mal aussen vor.
  
  Bei einem GIS-Datensatz eines Strassennetzes (Knoten und Kanten, siehe Abbildung unten) für die Verkehrsmodellierung erwartet man zum Beispiel die Einhaltung der folgenden topologischen Eigenschaften:
  • Jede Kante beginnt und endet in einem Knoten.
  • Jeder Knoten liegt am Anfang oder Ende mindestens einer Kante.
  • Eine Kante beginnt und endet nicht im selben Knoten (keine Loops)
  • Sich kreuzende Strassen teilen sich denselben Knoten – ausser bei niveaufreien Kreuzungen.
    
• Formatkonsistenz: Werden die formalen Regeln der jeweiligen Datenstruktur eingehalten? Beispielsweise muss eine Linie mindestens zwei Vertices umfassen, ein Polygon richtig geschlossen und die Digitalisierungsrichtung korrekt sein.

Lagegenauigkeit: Absolut und relativ

Bei der Lagegenauigkeit – horizontal, vertikal oder umfassend – ist die Unterscheidung zwischen absoluter und relativer Genauigkeit zentral:

• Absolute Genauigkeit: Wie gut stimmt die Lage eines Features mit derjenigen des realen Objekts überein?
• Relative Genauigkeit: Wie gut stimmt die relative Lage von Features untereinander mit derjenigen der realen Objekte überein?

Die beiden Genauigkeiten können auseinanderfallen. Ein Strassennetz beispielsweise kann konsistent um wenige Meter verschoben sein und damit eine schlechte absolute, aber eine gute relative Genauigkeit aufweisen. Je nach beabsichtigtem Anwendungsfall ist das mehr oder weniger problematisch.

Für die Quantifizierung der Lagegenauigkeit gibt es verschiedene Metriken, beispielsweise den Root Mean Square Error (RMSE), den Circular Standard Error (CSE) oder den Circular Error Probable (CEP). Für Linien und Flächen werden manchmal sogenannte Epsilonbänder eingeführt, die eine Art Toleranz-Korridor um den Verlauf der Liniengeometrie legen.

Thematische Genauigkeit

Die thematische Genauigkeit beschreibt, wie gut die Attributwerte eines Features, die Klasse von Features oder die Klasse von Beziehungen zwischen Features mit der Realität übereinstimmen. Die Genauigkeit quantitativer Werte und die Genauigkeit qualitativer Werte (z.B. Kategorien bzw. Klassen) müssen in der Regel mit unterschiedlichen Metriken operationalisiert werden.

Besonders anschaulich – und auch für Daten-Spezialist-inn-en ausserhalb der Geoinformation relevant – ist die thematische Genauigkeit von Klassifikationen, etwa in der Auswertung von Fernerkundungsdaten. Deshalb möchte ich hier einen Exkurs wagen.

Confusion Matrix

Wer sich schon einmal mit Machine Learning beschäftigt hat, wird ein wichtiges Werkzeug kennen: die sogenannte Confusion Matrix. Sie stellt das Resultat einer Klassifikation der Referenz (in der Fernerkundung: der «Ground Truth») gegenüber und erschliesst damit zwei Fehlertypen (die ich weiter oben schon erwähnt habe):

• Typ-1-Fehler, False Positives oder Commission Error: Ein Datenpunkt (in der Fernerkundung in der Regel: ein Pixel) wurde einer Klasse zugeordnet, obwohl er nicht dazugehört.
• Typ-2-Fehler, False Negatives oder Omission Error: Ein Datenpunkt oder Pixel wurden einer Klasse nicht zugeordnet, obwohl er eigentlich dazugehört.

Im visuellen Beispiel: Anhand der folgenden realen Situation (links) und der Klassifikation (Mitte) resultieren Abweichungen (rechts).

Die Confusion Matrix zählt richtig und falsch klassierte Pixel (oberes der folgenden Bilder). Anhand der Confusion Matrix kann ich die Güte meiner Klassifikation reflektieren (unteres der folgenden Bilder).

Aber natürlich kann ich das ganze auch quantitativ weiter auswerten: Aus der Confusion Matrix lassen sich neben den beiden Fehlertypen (Typ-1-Fehler vs. Typ-2-Fehler etc.) drei weitere wichtige Kennzahlen ermitteln, die unterschiedliche Perspektiven auf dieselbe Klassifikation beleuchten. Diese Kennzahlen sind:

• Producer’s Accuracy (auch bekannt als Recall oder Sensitivity): Die producer’s accuracy beschreibt, wie der Name sagt, die Klassifikationsgenauigkeit aus Sicht des Produzenten oder der Produzentin. Der Produzent oder die Produzentin der Daten möchte (u.a.) wissen, wie gut seine bzw. ihre Klassifikation mit der Referenz übereinstimmt. Die producer’s accuracy stellt folgende Frage: Wie viele Pixel der realen Klasse A wurden korrekt erkannt, sprich, als Klasse A klassifiziert?
  
• User’s Accuracy (auch bekannt als Precision): Die user’s accuracy beschreibt, wie der Name sagt, die Klassifikationsgenauigkeit aus Sicht der Nutzenden. Die Nutzenden der Daten möchten (u.a.) wissen, wie gut eine Klasse (z.B. Klasse A) mit der Realität übereinstimmt. Aus Sicht der Nutzenden sinkt die Qualität mit der Anzahl von Pixeln, die in der Klasse sind, es aber nicht sein sollten. Die user’s accuracy stellt somit folgende Frage: Wenn ich auf ein als A klassiertes Pixel schaue, in welchem Anteil aller Fälle ist es in der Realität auch wirklich A?
  
• Overall Accuracy (wenn man die Begriffe «Recall»/«Sensitivity» und «Precision» nutzt, spricht man statt von «Overall Accuracy» häufig einfach von «Accuracy»): Die overall accuracy kombiniert ein Stück weit beide Aspekte. Sie analysiert den Anteil korrekt klassierter Pixel über alle Klassen hinweg.

Visuell erklärt ist das Ganze vielleicht noch etwas eingängiger:

Auch wenn das Ganze etwas kompliziert anmutet: Der entscheidende Punkt an diesen drei Genauigkeitsmetriken ist, dass sie sich erheblich unterscheiden können. Eine Klasse kann zum Beispiel eine user’s accuracy oder precision von 100% haben und gleichzeitig eine producer’s accuracy oder einen recall von nur 80%. Konkret würde das heissen: «Alles, was ich in der Klassifikation als A erkenne, ist auch in der Realität A. Aber: Ich erkenne längst nicht alle As als solche.» Wenn man zum Beispiel nur die overall accuracy anschaut, verkennt man potenziell solche Asymmetrien in der thematischen Genauigkeit. Je nach Anwendungszweck sind false positives oder false negatives kritischer.

Ein häufiges Beispiel in einem ganz anderen Themengebiet: Für HIV-Tests wünscht man vor allem eine hohe sensitivity. Die precision ist demgegebenüber weniger kritisch bzw. wird im Trade-Off mit der sensitivity geringer gewichtet. (Weshalb?)

Neben den betrachteten gibt es noch weitere, fortgeschrittenere Metriken für die Güte von Klassifikationen, wie beispielsweise F1-scores, welche precision und recall kombinieren oder, etwas klassischer, zum Beispiel Cohen’s Kappa. Aber das führt hier zu weit.

Zeitliche Genauigkeit

Zeitliche Genauigkeit beschreibt, wie gut die zeitlichen Attribute eines Features mit denjenigen des realen Objekts übereinstimmen. Die Wichtigkeit dieses Datenqualitätsmasses könnte zunehmen: Zumindest mir sind in letzter Zeit sogenannte temporale Geodaten in Studien- und Konzeptaufträgen öfters begegnet. ISO 19157:2013 unterscheidet hier sinngemäss drei Aspekte:

• Genauigkeit von Zeitangaben: Zum Beispiel von GNSS-Aufzeichnungen einer Trajektorie (siehe Abbildung unten) oder von Gültigkeitsperioden eines Features (zum Beispiel in einem historisierten Datensatz).
  
• Zeitliche Konsistenz: zum Beispiel die plausible Abfolge des Auftretens von Features.
  
• Zeitliche Validität: schlicht die Frage, ob es sich bei Attributwerten überhaupt um gültige Daten und Zeiten handelt, also zum Beispiel nicht der 31. Februar.

Usability: Das einzige, was am Ende wirklich zählt?

Alle oben aufgeführten internen Datenqualitätsmasse nach ISO 19157 – Vollständigkeit, logische Konsistenz, Lagegenauigkeit, thematische Genauigkeit und zeitliche Genauigkeit – sind letztlich Mittel zum Zweck. Das einzige externe Datenqualitätsmass, die Usability – in der Praxis häufig auch etwas anschaulicher Fitness-for-Use genannt – stellt die Fragen, die uns in Teil 1 dieser Serie schon zur Definition von Qualität begegneten:

• Passen die Daten zu den beabsichtigten Anwendungen?
  
• Konkreter: Genügen die einzelnen Ausprägungen der internen Datenqualitätsmasse (und allenfalls weitere Eigenschaften der Daten*) den Anforderungen, die aus der beabsichtigen Anwendung heraus formuliert werden (müssen)?

* Usability darf neben den internen Datenqualitätsmassen auch andere Anforderungen der Nutzenden aufgreifen, etwa wie einfach die Daten zu verwenden sind. Zum Beispiel Bezugskanäle (Bulk Download, API-Zugriff, …) oder Formate (offen, proprietär, de facto-Standard, …).

Die Qualität von Daten meint wie in Teil 1 gelernt eben nicht nur inhärente Charakteristika sondern auch den Erfüllungsgrad von Anforderungen. Nur auf Fitness-for-Use sollte Datenqualität aber auch nicht verkürzt werden.

Streng genommen gibt es also keine «guten Daten». Oder höchstens in dem Sinn, dass die internen Datenqualitätsmasse der fraglichen Daten so sind, dass die Usability für viele, die meisten, alle (?) … denkbaren Anwendungsfälle gegeben oder sogar sehr gut ist. Klingt so aber etwas weniger cool, nicht?

Und … in der Praxis?

Schauen wir uns zum Schluss das Wimmelbild der realen Datenwelt an. Mir scheint, in der Praxis sind die Angaben zur Datenqualität (von Geodaten, aber auch anderen Daten) häufig nur äusserst rudimentär – oder fehlen im schlechten Fall sogar ganz. Oft findet man Angaben zu Gültigkeitsstand, Erhebungszeitpunkt und Lagegenauigkeit. Vereinzelt gibt es vielleicht noch Hinweise zur thematischen Genauigkeit von Attributen, aber auch das in meiner Erfahrung nur für wenige Typen von Daten.

Je nach Datensatz gelten für die Abwesenheit anderer Datenqualitätsmasse gute oder schlechte Gründe:

• Die Datenqualitätsmasse sind nicht anwendbar und nicht relevant, zum Beispiel:
  • zeitliche Genauigkeit bei Daten ohne Zeitbezug
  • Domänenkonsistenz bei Attributen ohne feste Domänen
  • topologische Konsistenz bei Daten, für die das kein sinnvolles Kriterium ist (zum Beispiel STATPOP- und STATENT-Hektarrasterdaten).
    
• Die Güte der Datenqualität(smasse) wird stillschweigend als gegeben erachtet (vom Produzenten und von den Nutzenden), zum Beispiel hohe Vollständigkeit bei Daten aus Behördenhand. Diese Annahme kann natürlich gefährlich sein.
  
• Die Qualität der Daten wird als «best effort» erachtet, sinngemäss: «Das ist das beste, was wir zum Thema produzieren können bzw. was zum Thema erhältlich ist.» Das kann natürlich so sein. Die Unkenntnis von Datenqualitätsmassen ist aber auch in diesem Fall nicht gut. Hätte man genauere Kenntnis von Einschränkungen der Datenqualität, könnten vielleicht Probleme in der Nutzung der Daten verhindert oder mindestens abgemildert werden.
  
• Die Datenqualitätsmasse sind zu aufwändig zu erheben oder zu kompliziert aus internen Systemen auszugeben. Hier stünde die datenproduzierende Stelle in der Pflicht, solche Hürden zu überwinden. Tut sie das nicht, sollten die Nutzenden, schon nur aus Eigeninteresse und so gut es eben geht, die Datenqualität beurteilen. Für manche Datenqualitätsmasse ist das machbar, für andere geht es prinzipiell nicht (mangels genauer Kenntnis der Produktionsprozesse).

Die Konsequenz für alle, die mit bezüglich Qualität schecht annotierten Daten arbeiten: Es gilt häufig, die Datenqualität für den eigenen Anwendungszweck selbst zu beurteilen. Gleichzeitig sollte man nur so viel prüfen, wie notwendig ist. Denn der Suchraum für mögliche Qualitätsprobleme ist schon bei relativ einfachen Daten riesig. Datenqualität interessiert potenzielle Nutzende, wie in Teil 1 und oben herausgearbeitet, aber immer in Bezug auf einen Verwendungszweck, nicht als absolute Grösse. Die Kompetenz besteht darin, gezielt diejenigen Dimensionen der Datenqualität zu prüfen, die für die geplante Anwendung kritisch sind.

Safe to say: Wenn Sie bis hierhin gelesen haben, interessieren Sie sich wie ich für Daten, deren Qualität, Verwendungszwecke, Potenziale, … Hat Sie etwas vom Geschriebenen angesprochen? Dreht Ihnen eine Frage im Kopf? Oder haben Sie ein anderes Daten-«Problem»? – Melden Sie sich gerne bei mir.