Achtung, Pokémon-Alarm!

Pokémon Go nutzt in erster Linie Google Maps.

Google Maps hat zwar mit Google Map Maker auch eine Möglichkeit, als Nutzer die Daten zu bearbeiten, aber Google Map Maker hat wohl auch einen Sichtungsmechanismus.

Eben… und Änderungen sind mal eben nicht gleich da, wie wir es von OSM her kennen… und die Datenbank-Daten sind dort eben nicht so leicht zugänglich, wie bei uns… …und man kann dort Sachen eben nicht schnell man verändern die dann in der nächsten Minute bereits verfügbar sind, wie bei uns. So lese ich das jedenfalls bei Wikipedia.

Sven, dem dieser Popelmonk-Hype gehörig auf den Zeiger geht…

Dass die Wikipedia zu langsam wäre und man zu schwer Änderungen durchführen kann liest man wirklich selten als Kritik an der Wikipedia. Sonst wird immer die angeblich mangelnde Qualität kritisiert. Die Sichtungen gehen normalerweise (wenn es genügend Leute gibt, die den betreffenden Wikipedia-Artikel beobachten) auch recht schnell.

Schwierig ist es aber wenn es eine zu kleine Community gibt. Ich kenne das z.B. in der Esperanto-Wikipedia. Da habe ich auch mangels genügend Beiträgen keine Sichter-Rechte und es dauert ewig bis meine Änderungen gesichtet werden. Andere kleine Wikipedias werden das gleiche Problem haben.

In der Praxis dauert es aber in OSM viel länger als eine Minute bis die Änderungen sichtbar sind. Zwar sind die Änderungen sofort in der Datenbank da und kurz später in der Standardkarte aber es sind ja diverse Karten in Verwendung, die nicht alle so schnell neu erstellt werden wie die Standardkarte. Da dauert es dann um einiges länger. Beispielsweise war in einer Karte, auf der die Freifunk seine Zugangspunkte angezeigt hat, ein schon längst korrigierter Fehler noch Monate später noch zu sehen. (Das war allerdings ein Ausnahmefall und der Tile-Provider musste dann eh gewechselt werden.) Bei Navigations-Apps mit OSM-Offline-Daten dauert es auch länger bis sie die Daten aktualisieren.

Ja und nein. Ich gebe dir Recht, dass es derzeit unbefriedigend ist, wenn Mapper bewusst oder unbewusst Unsinn eintragen oder bestehende Daten beschädigen. Aktuell läuft man solchen Änderungen immer hinterher und es kostet viel Zeit, die Änderungen in einem Gebiet zu überwachen und Änderungen rückgängig zu machen.

Einen Sichtungsmechanismus wie bei der Wikipedia halte ich bei OpenStreetMap jedoch nur für begrenzt einsetzbar. Zum einen muss es immer genug Leute geben, die die Änderungen reviewen und freischalten. Das bindet die Mapper, kostet Zeit und Aufwand. In ländlichen Gegenden mit wenigen Mappern kann es zum Beispiel dazu kommen, dass es einen engagierten Neumapper gibt, dessen Änderungen aber nicht zeitnah freigeschaltet werden, weil es in der Gegend sonst keine Mapper gibt.

Bei der Wikipedia ist es noch vergleichsweise einfach, einzelne Stände der voneinander unabhängigen Artikel zu verwalten. OpenStreetMap hat dagegen den Nachteil, dass die einzelnen Objekte viel mehr voneinander abhängen. Einzelne Versionszustände von einzelnen Objekten als “nicht gesichtet” zurückzuhalten, würde zu inkonsistenten Daten führen. Dann müssten schon gesamte Änderungssätze gesichtet werden. Doch auch hier stellen sich Fragen zur Konsistenz der Daten: Können noch nicht gesichtete Daten erneut bearbeitet werden? Wie sollen gesichtete und nicht gesichtete Daten im Editor unterschieden werden?

Stattdessen bin ich eher für einen Monitoring-Ansatz: Grundsätzlich darf jeder alles bearbeiten, aber es braucht mächtige Tools, mit denen frühzeitig und mit wenig Aufwand Vandalismus oder falsche Änderungen erkannt werden können, die man dann gezielt anschauen und korrigieren kann.

Wie dieser Blogpost zeigt, lassen sich mit den bestehenden Tools schon viele Probleme erkennen, aber vieles ist mit einigem manuellem Aufwand verbunden. Es müssen erst Overpass-Abfragen formuliert werden, und einmal geschriebene Tests lassen sich nicht wirklich für andere Mapper abspeichern. Dadurch gibt es häufig nur ein paar engagierte Mapper, die für sich selbst Overpass-Abfragen schreiben, die aber sonst niemandem zur Verfügung stehen. Was wir dringend brauchen ist ein Qualitätssicherungstool, das einfach um Checks erweitert werden kann. Also sowas wie Overpass Turbo, wo man jedoch einzelne Abfragen abspeichern kann und diese dann wie z.B. in Keepright als Ansichten zur Verfügung stehen.

Bestehende Tools wie Achavi, Whodidit, Overpass Turbo, JOSM Validator oder Keepright gehen in die richtige Richtung, müssten aber in meinen Augen noch besser verzahnt werden und noch besser wichtiges von unwichtigem trennen. Momentan zeigen Whodidit oder Achavi sehr schön die Änderungen in einer Gegend an, jedoch wirklich alles was dort editiert wurde. Der JOSM Validator oder Keepright prüfen auf sehr viele Fehler, aber beinhalten keinen zeitlichen Aspekt. Schön wäre eine Mischung aus beidem: Zum Beispiel ein Tool wie Whodidit, was aber z.B. nur Änderungen von Maps.me Usern anzeigt, bei denen in das name=* Tag irgendwelche asiatischen Zeichen eingetragen wurden.

Der Monitoring-Ansatz behebt Vandalismus leider auch erst nachdem er stattgefunden hat. Wenn man aber mit effizienten Tools mit wenig Aufwand große Gebiete überwachen kann und somit sehr schnell auf Vandalismus reagieren kann, verlieren solche Leute hoffentlich schnell das Interesse. Da gibt es einige Parallelen zur Kriminalitätsbekämpfung im realen Leben, Stichwort “Broken-Windows-Theorie”.

(Crosspost von http://blog.openstreetmap.de/blog/2017/01/achtung-pokemon-alarm/))

Gruß
Alex

Das halte ich noch für das am leichtesten zu lösende Problem. Der Sichtungsmechanismus würde in OSM nur in den Gebieten angewandt, die auch jemand in seiner Beobachtungsliste hat.

Aber ja, mir ist natürlich auch klar, dass ein Sichtungsmechanismus in OSM technisch viel schwieriger zu implementieren wäre als in der Wikipedia. Umso mehr finde ich eine Aussage wie “…nicht zur Wikipedia Nr. 2 werden zu lassen…” unangebracht.

Mit welchen Mitteln auch immer: Mit der zunehmenden Datendichte, Datenqualität und Popularität von OSM wird die Qualitätssicherung immer wichtiger. Wenn OSM immer mehr verwendet wird zieht das natürlich immer mehr Leute an, die “schlechte” Änderungen wie eben die der Pokémon-Go-Spieler durchführen. Es wäre schade wenn OSM irgendwann zusammenbrechen würde weil es mit dem Vandalismus nicht fertig wird und dann alle wieder Google Maps und HERE nutzen würden weil da die Qualität besser überprüft wird.

+1

Daher sehe ich es als Ziel für die weitere Zukunft von OSM, die Datenqualität zu halten bzw. zu steigern, indem Vandalismus verhindert und die Daten aktuell gehalten werden.

Eine Schwierigkeit wird sein, die Mapper dazu zu motivieren. Denn Qualitätssicherung macht nicht so viel Spaß und erzeugt nicht so sichtbare Fortschritte wie das Mappen weißer Flecken, ist aber mindestens genauso viel Arbeit. Zu dem Thema gab es mal einen interessanten Vortrag: https://www.youtube.com/watch?v=KNTSZGnQVRw.

Bei der Wikipedia beklagt man ja bereits seit einiger Zeit einen Autorenschwund und auch bei OSM scheint dieser zumindest in Deutschland langsam spürbar zu sein: https://twitter.com/pascal_n/status/821788856135647241

Gruß
Alex

Also, mir macht das Aktuell-Halten und Verfeinern von Daten durchaus Spaß, und auch im ziemlich vollständig erfassten Schland gibt es viele Landstraßen, die noch wie mit der Axt gemappt aussehen. Da geh ich dann gern mal mit dem Skalpell bei.

Diesen Kreisverkehr hab ich im Oktober eingetragen (da sah er ziemlich neu aus), Goggele kennt ihn heute noch nicht.

–ks

Man muss bei der „Rasterfahndung“ nach Pokémon-Jüngern wirklich aufpassen. Ich dachte gerade, in Eppingen (Landkreis HN) einen Pokémon-Jünger ertappt zu haben – brandneuer Benutzer, der ausschließlich Parks, Spielplätze und Fußwege gemappt hat, das sah doch sehr eindeutig aus. Aber, schöne Überraschung, alle gemappten Objekte existieren auch auf dem Luftbild! Ich schicke ihm jetzt meine Willkommensmail mit ein paar Tips.

Bis nach Ísland: https://www.openstreetmap.org/changeset/45656104

Zunächst möchte ich ich auf den bereits vorhandenen Thread verweisen und auch vor überzogen Reaktionen abraten. Da sind möglicherweise wirklich ein paar zukünftige OSMler zu gewinnen. In wieweit die neue Version auf OSM basierende Daten verwendet, weiß ich nicht. Viele von mir bereits früher eingetragene Wege, Gebäudegrunrisse waren auf Pokemon nicht, weil nicht auf Google. Da mein Junior nur eine begrenzte Datenmenge hat :), flog die App nach einiger Zeit wieder raus. Vermute mal, dass es die Spielemachern nicht um detailgetreue Darstellung der Straßensituation geht und daher auch Eintragungen in OSM nicht zeitnah bei Aktualisierungen umgesetzt werden. Und nur das könnte für einen Spieler Sinn machen.
Cepesko

Ein Sichtungsmechanismus für potentiell als problematisch einzustufende Änderungen (z.B. neuer User oder gebrochene Relationen etc.) wäre schon sehr sinnvoll.
Ich hatte mir kürzlich einige Gedanken gemacht, wie ein derartiger Sichtungsmechanismus funktionieren könnte (https://github.com/openstreetmap/iD/issues/3699).
Wichtig ist dabei:

  • Mappen wird nicht behindert, auch nicht in Gegenden mit einer geringen Aktivität.

  • Fehler werden effizient erkannt und bereinigt.

  • Fehler sollen bis zu Ihrer Bereinigung Anwendungen nicht beeinträchtigen.

Dies ist keine triviale Aufgabe, jedoch scheint sie im Wesentlichen lösbar zu sein.

Mein erster Ansatz, Änderungen erst nach einer Sichtung in die Datenbank zu schreiben, funktioniert wohl leider nicht, da Konflikte insbesondere mit nachfolgenen Änderungen des gleichen Users auftreten würden und die Konfliktbereinigung problematisch erscheint.

Vielversprechender ist es, auch die potentiell problematischen Änderungen direkt in die Datenbank zu schreiben. Danach könnte eine von einem modifizierten Maproulette organisierte Sichtung der Changesets erfolgen. Die Sichtung selbst würde mit JOSM erfolgen, wobei wohl das Reverter-Plugin gute Dienste bei der Analyse leisten dürfte. Eine zurückgewiesene Sichtung wäre ggf. technisch als Revert auszuführen, wobei natürlich stattdessen eine Korrektur der Fehler zu bevorzugen ist.

Um zu verhindern, dass die Fehler bereits vor der Sichtung Anwendungen beeinträchtigen, wird eine Slave-Datenbank benötigt, die jedoch noch zur Sichtung anstehende Changesets erst nach einem Timeout übernimmt. Diese Slave-Datenbank hat dann die Anwendungen zu bedienen. Dieses kann auch später noch dem Sichtungsmechanismus hinzugefügt werden.

Die Idee klingt auf den ersten Blick nicht schlecht. Die Slave-Datenbank würde dann auch eine eigene Renderinginstanz des Carto-Stils benötigen die z.B. nur für angemeldete Benutzer sichtbar ist. Der Mapper-Feedback Mechanismus ist imho wichtig.

Ich halte nicht viel davon. Zum einen wird durch das Sichten eine weitere Zeitdimension eingeführt, die dazu führt, dass Änderungen auf der Slave-DB nicht mehr in chronologischer Reihenfolge der ursprünglichen Änderungen erfolgen. Das wird ein heilloses Chaos und Konflikte produzieren. Zum anderen ist die Main DB heute schon um die 7 TB groß. Ich glaube nicht, dass jemand für diesen Zweck Hardware und Adminaufwände für eine weitere DB in dieser Größenordnung genehmigen würde.

Auch die dahinterstehende Grundidee, dass OSM zu einem bestimmten Zeitpunkt “korrekt” sein könnte, ist von vornherin zum Scheitern verurteilt. OSM ist nie “korrekt”, und es wird auch kaum möglich sein, innerhalb des Timeouts genügend Leute zu finden, die überhaupt in der Lage sind, Änderungen zu Reviewen. Mangels Ortskenntnis werden da nur grobe Schnitzer auffallen. Das geht aber auch alles heute schon mit deutlich weniger Aufwand.

m.E. also eher eine Schnapsidee, die nur auf Powerpoint funktionieren mag, aber nicht in der Praxis.

Da liegt ein Gedankenfehler vor. Die Slave-Datenbank ist die verzögerte Datenbank und somit weniger für das Mapper-Feedback geeignet. Ich würde davon ausgehen, dass die meisten Mapping-Tools und auch die OSM-eigene Renderinginstanz weiterhin mehr oder weniger direkt von der Hauptdatenbank versorgt werden.

Ich würde auch nicht soweit gehen, noch nicht gesichtete Änderungen z.B. vor nicht angemeldeten Benutzern verstecken zu wollen. Es geht vielmehr darum, um ggf. auch professionellen Anwendungen einen alternativen Datensatz anbieten zu können, der zumindest von der Mehrzahl der groben Fehler befreit ist. Z.B. Routinganwendungen sind besonders fehlerempfindlich. Bei der Erzeugung von selten aktualisierten Offline-Karten ist es auch sehr wünschenswert, wenn man die gröbsten Schnitzer der letzten Tage heraushalten kann.

Der Update-Algorithmus für die Slave-Datenbank wird sicher nicht trivial sein. Es wird nötig sein, auch auf noch zu sichtenden Changesets aufbauende Changesets zu verzögern. Ich halte es aber für ein lösbares Problem, da die Änderungen über einen gewissen Zeitraum noch nicht global so strark miteinander verwoben sein dürften, dass sie nicht mehr in Gruppen zerlegt werden können, die unabhängig voneinander in die Datenbank eingetragen werden können, ohne Inkonsistenzen zu generieren.

Die Slave-Datenbank auf die History gut verzichten, was sie wohl deutlich kleiner macht. Der Zweck der Slave-Datenbank ist die Bereitstellung verlässlicherer Daten, um insbesondere gewisse professionelle Anwendungen zu ermöglichen. Dafür sollte sich doch wohl eine Datenbank lohnen. Wir dürften ja ach jetzt schon einige Kopien der Datenbank im Einsatz haben. Für den eigentlichen Sichtungsmechanismus brauchen wir die Slave-Datenbank ohnehin nicht. Ggf. könnte ein derartiger Slave-Datenbankservice auch später kommerziell bereitgestellt werden, auch wenn es schade wäre, wenn dieser nicht für Jedermann frei zugänglich ist.

Die Grundidee ist eher, dass OSM zu jedem Zeitpunkt so fehlerhaft ist, dass man durch ein geeignetes Vermischen verschiedener Datanbankstände insgesamt bessere Daten erhält.

Daher ist die Idee, den Review-Aufwand möglichst klein zu halten. Dies kann zum Beispiel dadurch erfolgen, dass kritische Teile von Änderungen von Editor in ein separates Changeset ausgelagert werden, wobei nur dieses einem Review zugeführt wird. Der Editor sollte auch gleich Informationen liefern, was wahrscheinlich beschädigt wurde. Ein Vandalismus bezogenes Review weniger Changesets neuer User ist vermutlich auch ein begrenzter Aufwand.

Gerade die groben Schnitzer können Anwendungen von OSM stark beeinträchtigen.

Überall wird meist bei “Neulingen” eine Sichtung und Freischaltung vorgenommen - selbst hier im Forum glaube ich.
Wenn man eine “ordentliche Mitteilung” an den “Neuling” nach dem ersten CS sendet, wird ein “interessierter” dies auch akzeptieren.

Es gibt einige “ältere” die täglich online sind und die neuen CS kurz prüfen könnten. Bei Fehlern kann man helfen oder das CS + User freigeben / markieren zur Freigabe des User.

Ich hatte selbst diese Probleme vor Ort. Der User reagierte weder auf CS-Kommentare noch PN und konnte -zig Änderungssätze bis zur Sperre hochladen konnte. Die Korrekturen waren aufwendiger als “10 Neulinge pro Tag zu prüfen”. Die meisten Neulinge produzieren ja auch keine “böswilligen” Fehler.

Das ist richtig, hat aber einen anderen Hintergrund. Der Auslöser war die massive Verbreitung von SPAM im Forum, nicht das inhaltliche Sichten von Posts. SPAM wird gelöscht, echte Beiträge von Menschen werden unabhängig vom Inhalt immer unverändert freigeschaltet.

Das technische Problem bei “Sichten und Freischalten” ist enorm.

  • Wenn die Daten scheinbar verschwinden, werden viele Leute sie nochmal eintragen, vermutlich in leicht veränderter Form, um den “Fehler” zu korrigieren. Das war ein großes Problem hier im Forum wenn die Posts nicht sofort erschienen sind. Als Mod mußte man immer aufpassen ob inzwischen Doppel- und Dreifachposts aufgelaufen sind und die auch noch aufräumen.
  • wenn die Daten eine Weile zur Sichtung zurückgehalten werden, besteht die Gefahr daß jemand anders Änderungen in derselben Gegend vornimmt, so daß ein Konflikt entsteht oder die Daten vom Zusammenhang nicht mehr passen. Dann kann man sie nicht mehr einfach freischalten sondern muß erst noch die Konflikte auflösen.

Grundsätzlich bin ich auch für eine Sichtung, aber eher mit der optimistischen Denkweise daß ein neuer Beitrag wahrscheinlich gut (gemeint) ist und bleiben kann. Ich halte es für sinnvoller zu Markieren, Sichten und im Problemfall wieder zu löschen. Also so ähnlich wie heute, nur unterstützt durch einen Meldemechanismus und schnelle Prüfung anstatt erst viel später wenn jemand zufällig auf Probleme gestoßen ist. Mit einer Markierung könnte man dem vorbeugen, daß mehrere Leute unkoordiniert an den ungesichteten Daten editieren und so einen sauberen Revert verhindern.

by, Nop

Die Ansicht, dass “Neulinge” einer besonderen Aufsicht bedürften, teile ich überhaupt nicht. Den größten Mist in meinen Stammgebieten haben User verzapft, die schon auf dreistellige Changeset-Zahlen verweisen konnten. Ich nenne hier mal beispielhaft denjenigen, der eine Zeitlang unter dem Namen “Posemuckel” unterwegs war, und den inzwischen entschwundenen r-michael. Der eine hat ohne Sinn und Verstand von uralten Karten/Luftbildern abgemalt, der andere hat sehr eigene Interpretationen von highways vertreten.

Alle, die hier für eine “Sichtung” eintreten, sollten sich im übrigen fragen, ob sie selbst bereit wären, möglicherweise stundenlang zu sichten.

Um mal auf das Ursprungsthema des Threads zurückzukommen … meine ich das nur, oder geht die Anzahl der Pokemonedits zurück?

Gruß
tux67

Hallo tux67,

Ja. Am Sonntagvormittag bin ich die Edits frisch hinzugestoßener Neulinge durchgegangen. Pokémon-Mapper habe ich keine mehr gefunden, dafür die üblichen Neulingsedits. Gesichtet habe ich Änderungen, die zwischen Samstagabend (ca. 19:00) und Sonntagvormittag (ca. 11:00 Uhr) hochgeladen wurde. Das war am Wochenende davor eine Pokémon-Hochphase. Anscheinend hat es sich herumgesprochen, dass es zwecklos ist, Quatsch einzutragen.

Ob es in anderen Gegenden der Welt auch besser geworden ist, weiß ich nicht.

Viele Grüße

Michael