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 [email protected] http://www.remote.org/jochen/ +49-721-388298 _______________________________________________ Talk-de mailing list [email protected] http://lists.openstreetmap.org/listinfo/talk-de
