Ich habe mir mal erlaubt, die Vorschläge von BFX mitaufzunehmen.
(+) Schreibweise Straßennamen an highways
(+) Fehler in addr:*
(+) leere Tags
(+) Whitespace
(+) Knoten mehrfach in Wegen
(+) Wege mit nur einem Knoten
(+) unverknüpfte ungetaggte Knoten
(-) identischen Geometrien mit gleichen Tags
Zur Schreibweise von Strassennamen: Ich schreibe generell kein ‘ß’ (das habe ich mir eben von oben kopiert ), aber es ist mir egal, wie entsprechende Strassennamen in der Datenbank stehen - es sollte nur einheitlich sein. Die Alternative für mich wäre halt, diese Strassennamen nicht einzutragen, da ich auch nicht möchte, dass ein anderer User hinterher “aufräumen” müsste. Selbiges gilt für addr:street.
Zu den mehrfachen Knoten: Das gilt nur, wenn ein Knoten zweimal direkt hintereinander in einem Way vorkommt?
Zu den identischen Geometrien mit gleichen Tags: Das ist imo ausser leeren Tags das Seltenste und könnte (wie auch “Whitespace”) möglicherweise beabsichtigt sein.
Mit dem PlugIn poly kannst du sie dir in josm anschauen. Ein Problem sind wahrscheinlich die ganzen Exklaven. Da müsste man dann mal schauen, ob man daraus ein Polygon basteln kann mit ganz feinen Stegen.
Danke - im Gegensatz zu den Polyfiles, die ich mir eben gebastelt habe, kann ich mir Deine tatsächlich in JOSM ansehen.
Ich bin fast geneigt, die Exklaven einfach zu verwerfen, sollte es damit irgendwelche Probleme geben. (Es geht dabei um 0,03 % der Fläche Deutschlands, die dann nicht in den Genuß automatischer Korrekturen kämen.) Ich muß erst einmal ein bißchen mit osmosis herumspielen; das Programm habe ich bisher nur eine Handvoll Male benutzt, und das vor langer Zeit.
Kann man mit einem Polygon dieser Größe (~80 000 Knoten) noch sinnvoll filtern oder sollte man das vorher noch vereinfachen?
(+) Schreibweise Straßennamen an highways
(+) Fehler in addr:*
(+) leere Tags
(+) Whitespace
(+) Knoten mehrfach hintereinander in Wegen
(+) Wege mit nur einem Knoten
Ich habe jetzt erst einmal osmosis benutzt. Dessen Geschwindigkeit spielt eine untergeordnete Rolle: der Großteil der Rechenzeit bleibt bei bzcat und awk hängen (ich benutze osm.bz2-Dateien und ein awk-Programm zum Filtern nach Tags). Die wenigen Daten, die dann noch übrig bleiben, sortiert und filtert osmosis schnell genug.
Der Prozeß, aus einem .osm.bz2 alle Knoten und Wege mit “Strasse” etc. im name-Tag auszufiltern, die nicht zwischengespeicherten Wegknoten von der API nachzuladen, das Ergebnis zu sortieren und zu filtern, dauert gut 30s (davon 6s für osmosis) für den Regierungsbezirk Köln (mein bevorzugtes Testgelände); hochgerechnet wäre das etwa eine Viertelstunde für DE. Damit könnte ich schon leben, auch wenn sich die Ausführungszeit mit stärker spezialisierten Werkzeugen sicher noch ein wenig drücken läßt.
Viel wichtiger als die Geschwindigkeit: das Filtern mit dem von Dir bereitgestellten Polygon scheint korrekt zu funktionieren - ein paar “Strassen” im angrenzenden Belgien fliegen erfolgreich raus. Die technischen Herausforderungen lassen sich also lösen - mal sehen, ob das mit den grundsätzlichen Vorbehalten, die einige hier haben, auch klappt Entsprechender Thread dazu dann in den nächsten Tagen.
Noch eine Anmerkung: Ich bin dafür, daß Straßen, die ein weiteres doppel-s im Namen haben nicht korrigiert werden. Einfach, weil es nach der Korrektur so aussieht, als wäre es sicher, daß das andere ss kein ß ist. Z.B. Schloßstraße vs. Schlossstraße vs Schlossstrasse. Stattdessen ein Fixme ergänzen.
(+) Schreibweise Straßennamen an highways
(-) Fehler in addr:*
(+) leere Tags
(+) Whitespace
(+) Knoten mehrfach hintereinander in Wegen
(+) Wege mit nur einem Knoten
Fixme anzuhängen halte ich für keine gute Idee. Stell dir nur vor, da ist ein Fixme, du kontrollierst das, alles ist ok, du entfernst das Fixme. Beim nächsten Botlauf ist es wieder da nerv
Natürlich sollte nicht generell jedes ss durch ß ersetzt werden. Nur bei bekannten Wörtern wie z.b. …straße.
Ein Fixme anhängen wäre mMn der falsche Weg.
Jedenfalls würde ich es befürworten, wenn dieser Bot auch in der Schweiz automatische Reparaturen vornimmt (wie gesagt, hier einfach ohne das ß). Der xybot hat nämlich auch hier in der Schweiz immer recht viel korrigiert. Und wenn das nun wegfällt, würde die Qualität mMn recht nachlassen.
Das denke ich auch. Ein wie auch immer gearteter Bot sollte nur solche Ersetzungen vornehmen, bei denen ein Irrtum mit an Sicherheit grenzender Wahrscheinlichkeit ausgeschlossen werden kann (und für Sonderfälle ggf. eine Veto-Liste pflegen). Im Zweifelsfall wird das Objekt einfach nicht angefaßt.
Im Falle der Schlo(ß|ss)stra(ß|ss)e sehe ich aber eigentlich kein Problem: strasse ist - in DE - in jedem Fall falsch, Schloß bzw. Schloss kann richtig oder falsch sein. Nach der Ersetzung strasse → straße hat das Wort in jedem Fall einen Fehler weniger, im Idealfall gar keinen mehr.
Ich hoffe eigentlich, daß es nicht nur “den” Bot geben wird - sondern daß sich für die verschiedenen Aufgaben mehrere Freiwillige finden, die ein auf die jeweilige Aufgabe zugeschnittenes Werkzeug entwickeln, pflegen und mit der Zustimmung der Community betreiben. Für die “Strassen” (und ggf. Adressen, die technisch ähnlich anzugehen sind) habe ich mich schon angeboten und werde hier in den nächsten Tagen einen eigenen Thread dazu starten. Bei den anderen (und evtl. weiteren, in meiner Aufzählung noch nicht aufgeführten) Aufgaben hoffe ich auf weitere Freiwillige.
Wie gesagt, hatte ich zuerst einmal an die Anwendung auf DE gedacht. In der Folge kann man das natürlich erweitern. Die Spielregeln für “mechanical edits” sehen bekanntlich vor, daß der Betrieb eines Bots mit der jeweiligen Community diskutiert werden soll. Das deutsche Forum kann nur seinen Segen für Bearbeitungen in DE geben - aber wenn ein Bot schon einige Monate saubere Arbeit in einem Land vorweisen kann, wird die Diskussion über den Einsatz in einem anderen Land oder gar dem Rest der Welt sicher deutlich einfacher.
(+) Schreibweise Straßennamen an highways
(+) Fehler in addr:*
(+) leere Tags
(+) Whitespace
(+) Knoten mehrfach hintereinander in Wegen
(+) Wege mit nur einem Knoten
Da Du es im Chaos-Faden noch einmal angesprochen hast: grundsätzlich wäre ich auch für eine automatische Duplikatbereinigung, und es finden sich sicher noch ein paar weitere Putzaufgaben, die man sinnvoll automatisieren könnte.
Leider ist die Bereinigung von Duplikaten eine ganz andere Hausnummer als etwa die Korrektur der Straßennamen, mit der ich gerade begonnen habe. Letztere Aufgabe ist im Vergleich geradezu simpel: ein Tag austauschen (dabei eine Handvoll Ausnahmen beachten) und die anderen Eigenschaften nicht kaputtmachen. Duplikate muß man erst einmal sauber erkennnen: zwei Knoten am selben Fleck sind noch einfach, aber mehrere übereinanderliegende Wege sind schon schwieriger. Findet sich alles noch irgendwie, aber dann kommt die Reparatur: welches von mehreren identischen Objekte entfernt man? Was tun, wenn einer oder mehrere der Wege Mitglieder von Relationen sind? Oder wenn doppelte Knoten Elemente unterschiedlicher Wege sind? Oder wenn man zwei Wege aus jeweils identischen Knoten hat, von diesen Knoten aber manche noch in anderen Wegen hängen oder Tags tragen?
Selbst JOSM behebt nur einen Teil dieser Fehler automatisch, und faßt dabei auch oft mehr Objekte an als nötig wäre.
Ich selbst traue mich da nicht heran. Das einzige, was ich mir noch zutrauen würde, wären doppelte POI: doppelte Knoten mit identischen Tags, die nicht Mitglied irgendwelcher Wege oder Relationen sind. Oder vielleicht noch solche, wo die Tags des einen eine Teilmenge der Tags des anderen bilden (etwa wo bei sonst identischen Tags wheelchair=* an einem der Knoten ergänzt wurde). Diese Fälle machen allerdings nur einen winzigen Bruchteil der Duplikate aus (auch wenn man argumentieren kann, daß sie für manche Anwendungen besonders lästig sind). Aber vielleicht findet sich ja jemand anders, der in dieses Thema eine Menge Gehirnschmalz investieren möchte. Wenn man z.B. ein Drittel der doppelten Knoten - sauber - automatisch bereinigen könnte, wäre sicher schon einiges gewonnen.
Zusammenfassend zum bisherigen Meinungsbild aus diesem Faden: Es zeichnet sich ab, daß die ehemals von xybot durchgeführten Korrekturen grundsätzlich wieder aufgenommen werden könnten (nach Diskussion der Details, versteht sich). Mit den Straßennamen habe ich ja schon begonnen. Wenn diese Korrektur stabil läuft, werde ich auf die anderen noch einmal zurückkommen; die vorhandenen Werkzeuge sollten sich recht einfach auf addr:*, leere Tags und Whitespace erweitern lassen. Wenn mir aber jemand zuvorkommen will, nur zu.
Wäre ich klar dagegen. Wie du schon sagst wäre das erkennen noch machbar, aber das reparieren nahezu unmöglich.
Es ist eines meiner “Hobbies” mit dem OSMI-Routing-View Fehler zu beseitigen. Dazu gehören auch übereinander liegende Straßen. Manchmal ist der Fall einfach und die Wege liegen wirklich einfach nur kopiert übereinander. Manchmal ist aber auch ein Weg Mitglied in einer Relation, der andere nicht, hat dafür aber ein paar mehr Eigenschaften. Wenn diese beiden Wege zusammen gehören und es keine widersprüchlichen Tags gibt, wäre es auch noch möglich. Aber was machst du bei einem track mit grade1 der über einem track mit grade3 verläuft? Oder bei einer Telefonzelle, die quasi an einer Stelle mit dem Postkasten liegt.
Für mich sind das einfach zu viele Unklarheiten, sodass ich hier keinen Bot unterstützen wollte.
Wogegen? Gegen einen Bot, der versucht als eierlegende Wollmilchsau sämtliche Duplikate zu beseitigen - da sind wir uns wohl einig, daß derlei nahezu unmöglich ist und daß man lieber die Finger davon lassen sollte.
Oder auch gegen Versuche, einzelne klar abgegrenzte Spezialfälle (etwa die doppelten POI oben) automatisch zu korrigieren? Ich denke, daß dies mit der gebotenen Sorgfalt schon möglich wäre. Dann müßten sich die menschlichen Korrekteure “nur noch” um die schwierigeren Fälle kümmern.
Ungetaggte Nodes, die exakt die gleiche Koordinate haben, könnte man mergen und wenn sie nicht zu einem Weg oder zu einer Relation gehören auch gleich ganz löschen. Viel mehr würde ich aber nicht machen. Exakt deshalb, weil es durchaus Mapper gibt, die landuse und highway verdammt dicht aneinander legen. Denen wird es bestimmt nicht gefallen, wenn man das nun merged. Auch bei doppelten POI wäre ich vorsichtig. In den USA hab ich auch fälle gesehen, da waren diverse Schul-POI und der place-Node exakt auf einer Koordinate. Wird wohl ein Import gewesen sein. Da wäre es einfach falsch die diversen Schul-POI zu mergen.
Fünf Schulen und ein place-Knoten haben ganz sicher keine identischen Tags (place=town, name=Potlatch vs. amenity=school, name=John Quincy Adding Machine Memorial High School).
Aber zwei Schulen mit gleichem Namen, gleicher Adresse usw. am gleichen Ort braucht es nicht.
Exakte Übereinstimmung der Position hatte ich ohnehin vorausgesetzt (unabhängig davon, was ich persönlich von den beliebten 2cm-Spalten zwischen zwei landuses halte).
), aber es ist mir egal, wie entsprechende Strassennamen in der Datenbank stehen - es sollte nur einheitlich sein. Die Alternative für mich wäre halt, diese Strassennamen nicht einzutragen, da ich auch nicht möchte, dass ein anderer User hinterher “aufräumen” müsste. Selbiges gilt für addr:street.