[Talk-de] Bericht zur QS-Session auf der FOSSGIS

Mo Mär 15 15:24:27 UTC 2010

Community Session "Tools zu Qualitätssicherung"

Auf der FOSSGIS-Konferenz hatten wir eine Community Session zum Thema "Tools zu
Qualitätssicherung" [1], über die ich hier kurz berichten will. Sie fand im
Anschluß zu meinem Vortrag über den OSM Inspector [2,3] statt, in dem ich
erzählt habe, wie und warum der OSM Inspector entstanden ist, wie er bedient
wird und auch einen kleinen Einblick hinter die Kulissen gegeben habe [4,5].

Die Community Session wurde durch einen Kurzvortrag von Mitja Kleider zu
OpenStreetBugs (OSB) [6] eingeleitet, der uns etwas zur Entstehungsgeschichte
und dem derzeitigen Stand bei OSB berichtete. Es gibt viele Ideen zur
Verbesserung von OSB, aber so richtig klar ist es nicht, welche Richtung
eingeschlagen werden soll. Allgemein befürwortet wird wohl eine Integration
in die offizielle OSM-Seite (www.openstreetmap.org), dazu muss das System
aber auf Rails umgestellt werden. Ein Wunsch für OSB war eine Ortssuche und
vielleicht die Speicherung der letzten Position in einem Cookie, damit man
schneller an den gewünschten Ort findet.

Harald Kleiner berichtete dann über sein Tool Keepright [7,8] und zeigte es
kurz. Anders als alle anderen Tools dieser Art hat es einen "Rückkanal", über
den false positives (Fehler, die keine sind) gemeldet werden können. Diese
werden dann in Zukunft nicht mehr angezeigt.

Weitere Tool-Autoren waren leider nicht vor Ort. Weitere Tools gibts unter [9].

Danach gingen wir in eine allgemeine Diskussion über.

Tools für Newbies

Ein Thema war die Vereinfachung der Tools, die heute meist nur für Spezialisten
verständlich sind. Das läßt sich häufig auch nicht vermeiden, da es in vielen
Fällen doch um komplexe Materie geht und man auch etwas Erfahrung mit OSM
braucht, um einschätzen zu können, was wirklich ein Fehler ist und was nicht.
Aber trotzdem sollten wir Ausschau halten nach Fällen, wo ein einfaches Tool
für spezifische Fälle genügt und solche Tools schaffen.

Erkennen von "false positives"

Ein Problem sind immer die "false positives", also Meldungen der Tools über
Fehler, die garkeine sind. Es gibt zwei Ansätze, damit umzugehen: Entweder man
fügt in den OSM-Daten irgendwelche Tags hinzu, die die Fehlermeldung
unterdrücken oder das Tool speichert entsprechende Informationen selbst. Wir
wollen in OSM natürlich keine Tool-spezifischen Tags haben, aber in manchen
Fällen macht der erste Ansatz durchaus Sinn, z.B. wenn eine Straße, die
wirklich endet mit "noexit=yes" getagged wird. Das macht nicht nur einem Tool,
sondern jedem deutlich, dass es sich hier um eine Sackgasse handelt und nicht
etwa um unvollständige Daten. In vielen Fällen ist aber der zweite Ansatz
vorzuziehen, um die Datenbank nicht mit unnötigem Kram zu belasten.  Dazu
könnte das Tool z.B. die Id des oder der OSM-Objekte speichern, aus denen ein
false positive generiert wurde (so arbeitet Keepright). Allerdings sollte bei
einer Änderung des Objektes dieses Flag wohl zurückgesetzt werden, weil es ja
sein kann, dass durch die Änderung dieser Fehler nun doch "echt" ist. Eine
erörterte Möglichkeit wäre es, eine Checksumme (MD5 oder dergl.) des oder der
beteiligten Objekte mit allen Tags zu berechnen und bei Änderung der Checksumme
den Fehler wieder anzuzeigen.

Zusammenarbeit der Tools

Ein weiteres großes Thema war die Frage der Zusammenarbeit der verschiedenen
Tools. Jedes Tool hat seine Stärken und Schwächen und es gibt viel doppelte
Arbeit. Ein Ansatz wäre eine gemeinsame Fehler-Datenbank zu schaffen (oder z.B.
die von OSB dazu zu verwenden). Jedes Tool kann dann dort seine Fehler
einkippen. Andere Tools können alle Fehler, an denen sie interessiert sind,
dort auslesen und darstellen. Das scheitert aber wohl an der großen Datenmenge
und den häufig nötigen Updates. Außerdem ist nicht klar, was dort überhaupt
reingehört. Der OSM-Inspector zum Beispiel erzeugt neben vielen Fehlerlisten
auch große Mengen an Daten (täglich ca. 20 Mio Objekte), die keine Fehler
darstellen, sondern nur den Kontext zu einem Fehler zeigen oder einfach nur
bestimmte Daten hervorheben wollen.

Um die Probleme einer großen, zentralen Datenbank zu umgehen, könnte man eine
einheitliche API entwerfen, über die die verschiedenen Tools ihre Daten zur
Verfügung stellen. Eine User-Interface-Komponente kann dann die APIs
verschiedener Tools abfragen und die Daten holen, die es interessiert.

Der OSM-Inspector stellt seine Daten derzeit schon per WMS und WFS zur
Verfügung [10]. Das sind weit verbreitete Protokolle, für die es schon viel
Software-Unterstützung gibt. Es ist aber unklar, ob sie alle Features haben,
die wir brauchen.

Die Komponente, die "false positives" speichert (siehe oben) könnte ebenfalls
herausgelöst werden, damit die nicht jeder implementieren muss.

Details einer solchen Architektur konnten aber nicht mehr erörtert werden,
weil die Zeit nicht reichte.

Insgesamt war die Community Session ein guter Schritt in der Diskussion, aber
zu kurz, um wirkliche Ergebnisse zu erzielen. Die Arbeit sollten in weiteren
Workshops und natürlich auf den Mailinglisten fortgesetzt werden.

Links:
[1] http://www.fossgis.de/konferenz/2010/events/104.de.html
[2] http://tools.geofabrik.de/osmi/
[3] http://wiki.openstreetmap.org/wiki/OSM_Inspector
[4] http://www.fossgis.de/konferenz/2010/events/102.de.html
[5] http://www.fossgis.de/konferenz/2010/attachments/85_slides-fossgis2010-osmi.pdf
[6] http://www.openstreetbugs.org/
[7] http://wiki.openstreetmap.org/wiki/DE:Keep_Right
[8] http://keepright.ipax.at/
[9] http://wiki.openstreetmap.org/wiki/Category:Quality_Assurance
[10] http://wiki.openstreetmap.org/wiki/OSM_Inspector/WxS

-- 
Jochen Topf  jochen at remote.org  http://www.remote.org/jochen/  +49-721-388298