OpenStreetMap
"Maproulette" in JOSM
Posted by poppei82 on 7 October 2013 in German (Deutsch). Last updated on 15 October 2013.Hallo!
Ich bin schon etwas länger damit beschäftigt mich nach Lust und Laune mit dem Thema Qualitätssicherung zu befassen. Das Tool Keepright hat mir bisher am besten gefallen, sodass ich einige Zeit damit verbracht und in Rheinland-Pfalz regelmäßig versucht habe die Bestandsdaten zu verbessern. Meine Erfahrung habe ich im Keepright Users Guide zusammengefasst.
Dennoch war das Bearbeiten mit viel unnötigem “Herumgeklicke” verbunden. Darum war ich sehr froh, als Nutzer Groppo sein Qualitätssicherungs-Skript vorgestellt hat. Damit ist es möglich, sich innerhalb von JOSM Fehler anzeigen zu lassen und diese zu korrigieren - auch Fehler von OSMI und Osmose. Das Prinzip kennt man von MapRoulette, das allerdings wohl wieder eingeschlafen ist.
Jedenfalls kann man mit dem QAT-Skript sein eigenes MapRoulette in JOSM veranstalten! Die tollste Funktion ist, dass man nur Fehler innerhalb selbst definierter Grenzen anzeigen lassen kann; auch administrative Grenzen! So kann man regelmäßig “sein” Gebiet (Kommune oder Bundesland) fehlerfrei halten.
Ganz dringend sollten Navigationsfehler behoben werden, die eine reibungslose Fuß-/Rad- und MIV-Navigation verhindern. Eine Fehlerart für fehlerhafte Navigation ist die beinahe Verbindung. Angesichts dieser kleinen Tabelle ist ein “Maproulette Deutschland” bitter nötig (Stand: 7.10.2013):
- Bundesland - Anzahl “beinahe Verbindungen” - Fehler pro Quadratkilometer
- Baden-Württemberg - 2941 - 0,082 Fehler/qkm
- Bayern - 1697 - 0,024 Fehler/qkm
- Berlin - 362 - 0,408 Fehler/qkm
- Brandenburg - 1773 - 0,060 Fehler/qkm
- Bremen - 517 - 1,234 Fehler/qkm
- Hamburg - 321 - 0,425 Fehler/qkm
- Hessen - 1498 - 0,071 Fehler/qkm
- Mecklenburg-Vorpommern - 959 - 0,041 Fehler/qkm
- Niedersachsen - 3391 - 0,071 Fehler/qkm
- Nordrhein-Westfalen - 5914 - 0,173 Fehler/qkm
- Rheinland-Pfalz - 23 - 0,001 Fehler/qkm (mir Pälzer sin die Beschde!)
- Saarland - 199 - 0,078 Fehler/qkm
- Sachsen-Anhalt - 1151 - 0,056 Fehler/qkm
- Sachsen - 1447 - 0,079 Fehler/qkm
- Schleswig-Holstein - 595 - 0,038 Fehler/qkm
- Thüringen - 1122 - 0,069 Fehler/qkm
- Deutschland gesamt: 23910
Ich wette um einen Kasten Kirner Landbier (dunkel), dass bis Ende des Jahres nichtmal 25 % der o. g. Fehler gelöst sind!!!
PS: Nicht verbundene Schnittpunkte ist auch ein navigationsrelevanter Fehlertyp.
Discussion
Comment from dcp on 8 October 2013 at 18:48
Ich wette nicht: Es könnte noch mehr dazu kommen!
Ich hätte gern gewüsst wie die Routing Software mit “beinahe Verbindung” fertig wird. Richtig programmiert könnte die Routing Software beinahe Verbindung ignorieren und eine Verbindung bis zur n-meter als gegeben annehmen.
Da wir alle Fehler machen sollte man Analysieren warum solche Fehler entstehen. Sind es nur Newbies? Liegt es an eine bestimmte Editor, Potlach, iD oder JOSM? IMHO es liegt an Newbies und Potlach/iD. Als JOSM liebhaber bin ich Voreingenommen; das weiss ich auch. Es gibt viele Oldies die noch Potlach/iD verwenden die viele Fehler noch machen. JOSM nützer, stelle ich fest, machen weniger Fehler.
Auch “Duplicate Ways” sind für “Routing” schlecht. Gerade seit die Einführung von iD werden bedeutend mehr “Duplicate ways” ersichtlich: Ist das Zufall?
Comment from tyr_asd on 13 October 2013 at 19:10
@dcp:
zu 3.: Echt? Wäre mir noch nicht aufgefallen. Hast du ein Beispiel dafür? (Denn nur damit kann man herausfinden, wieso das passiert und wie man das Programm korrigieren kann.)
zu 1.: Das wäre recht fahrlässig für eine Routing Software, denn es kommt schon häufig vor, dass bei Wegen trotz nahe beieinanderliegender Enden keine Verbindung existiert, weil z.B. eine Mauer dazwischen liegt.
Comment from dieterdreist on 13 October 2013 at 20:23
Bitte nicht blind Verbindungen herstellen, wenn Ihr die Stellen nicht kennt. Es gibt auch viele Stellen, wo man im echten Leben nicht durchkommt, zumindest nicht mit dem Auto, oft aber auch nicht mal zu Fuß (unterschiedliche Höhenebenen). Klar, das ist dann nicht besonders detailliert gemappt, wenn da nur 2 nicht verbundene Straßen sind und nicht z.B. ein Fußweg, ein fence, eine retaining_wall, etc. aber ohne Ortskenntnis geht das halt nicht. Falsche Verbindungen sind genauso schlecht wie nicht verbundene Straßen, die eigentlich verbunden gehören.
Comment from MKnight on 13 October 2013 at 21:28
Da wette ich mit ;) etwa 25% der Beinahe-verbindungen, die mir Keepright anzeigt sind false positive (Bzw. von Software schwer zu berechnen).
Mal als Beispiel: http://keepright.ipax.at/report_map.php?… (oder auch bspw. (global sicher nicht ganz repräsentativ) die ganze Region die ich permanent im Auge habe. (die nicht als false positive markierten sind Stellen, die ich bisher nicht einsehen konnte, Bing suggeriert aber dass auch die reell nicht verbunden sind) … Sicher eine Ausnahme, aber hier kann ich von annähernd 100% ausgehen, wenn ich die 2 changesets von gerade eben weglasse ;) )
In den restlichen 75% kommt es (mir, als QA-Junkie) immer wieder vor, dass ich auf Stellen stosse, die zwar im Sinne des Erfinders “kaputt” sind, wo mir persönlich das Fixen aber egal ist. Beispiel: Ein Fussweg ist (irgendwo) mit einer Strasse verbunden und endet dann 10m weiter im Nichts. Wenn ich sehe, dass der nicht verbunden werden muss sondern eigentlich weitergemalt, dann fasse ich den in der regel nicht an.
Comment from poppei82 on 14 October 2013 at 13:16
Hallo alle! Klar sollte man ohne Ortskenntnis nicht blind irgendwelche Wege einzeichnen, nur damit der Fehler behoben ist. Meistens sind es auch keine false positives, sondern korrekt erkannte Fehler, wo es aber dennoch nicht weiter geht (z. B. kein Pfad zwischen Parkplatzweg und daneben verlaufendem Fahrradweg. Dann sollte man aber ein noexit=yes an den Endnode des Parkplatzweges setzen. Denn es ist kein false positive (im Sinne von: keepright hat es falsch erkannt), sondern ein Fehler in den OSM-Daten.
Danke und ich bin gespannt, was am Ende des Jahres dabei herauskommt!!
Poppei
Comment from Chaos99 on 15 October 2013 at 14:55
Ich nutze auch seit kurzem die QA-Skripts in JOSM und mache mich ans fixen der Fehler in meiner Region. False Positives markiere ich dabei bei keepright, allerdings bleiben diese ja meines wissens nach nicht dauerhaft ausgeblendet, sondern poppen beim nächsten Lauf wieder auf. (Oder zumindest, falls das Objekt in einem changeset neu auftaucht.)
Viele beinahe-Verbindungungen enstehen bei mir hier durch das verwenden von highway=platform, wenn diese nur in der Mitte und nicht vorne und hinten angeschlossen wird. Auch Fussgängerzonen, in denen dann unangeschlossene Einzelwege liegen machen Probleme. KeepRight (und die Router) kommen mit begeh/fahrbaren Flächen einfach noch nicht zurecht.
Comment from Chaos99 on 15 October 2013 at 15:05
PS: wenn du wie in den Kommentaren hier: http://blog.openstreetmap.de/2013/10/wochennotiz-nr-168/#comment-96035 (zum jetzigen Zeitpunkt noch nciht freigeschaltet) vorgeschlagen ein hashtag für den changeset-comment vorgibst, kann man hinterher schöne Statistiken und Animationen über die Aufräumaktion machen.
Gruss, Chaos
Comment from poppei82 on 15 October 2013 at 15:16
Hi! @chaos99: false positives werden dauerhaft ausgeblendet (
). Wenn du den Fehler gelöst hast und es somit als vorübergehend ignorieren markierst (
), dann wird der Fehler nicht wieder sichtbar. Es sei denn du hast es fälschlich als gelöst markiert (also als gelöst markiert, obwohl du es nicht behoben hast). In dem Fall steht dann im Kommentarfeld bei QAT: error still open. Mehr Infos hier.
Zu dem highway=platform: ja, das markiere ich als false positive. Habe Harald Kleiner vor mehr als einem Jahr darüber informiert, aber noch hat er den Fehler nicht behoben (beheben können). Der Fehler verliert eigentlich auch an Bedeutung, weil ja auf lange Sicht highway=platform durch public_transport=platform ersetzt werden soll.
Danke auch für den Vorschlag mit dem Hash-Tag. Ich hoffe nicht, dass es hierfür zu spät ist. Ich kann das hier gerne nochmal in den BLog editieren. Ich hatte lediglich vor im neuen Jahr nochmal alle Bundesländer abzuklappern und aufzuschreiben, wieviele Fehler es da noch gibt.
Comment from Geonick on 15 October 2013 at 18:56
Ich bin daran zu überlegen, ob mit einem ReCAPTCHA die Leute, die sich bei OSM (oder so) registrieren wollen - und das CAPTCHA ausfüllen müssen - dazu zu bringen, genau solche fehlenden Verbindungen zu bestätigen - oder abzulehnen; mit “gesundem Menschenverstand”, ansonsten wenn es sein muss mit Luftbild. Wir werden aber sicher nicht vor Dezember 2013 fertig sein - von daher ist deine Wette also noch nicht in Gefahr :-).
LG, Stefan alias Geonick
Comment from slint on 18 January 2014 at 16:59
False positives bitte mit noexit kennzeichnen