Automatische Reparaturen: Ersatz für xybot

Ja, genau. In den Erläuterungen hatte ich das geschrieben, im “Fragebogen” habe ich diese Präzisierung vergessen.
Edit: oben soeben geändert.

Thomas

Dann hatte ich es wohl einfach vergessen, bis ich mich durchgelesen hatte :wink:
Ich habe meine Abstimmung oben entsprechend angepasst.

mfg~ray

Die Polygone findest du hier: http://www.aighes.de/data/DACHLI.7z

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. :wink:
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?

Edit: Zahl korrigiert.


(+) Schreibweise Straßennamen an highways
(+) Fehler in addr:*
(+) leere Tags
(+) Whitespace
(+) Knoten mehrfach hintereinander in Wegen
(+) Wege mit nur einem Knoten

Schau dir am besten osmconvert bzw. osmfilter an. Die sollten schneller sein als osmosis.

osmconvert.exe input.osm.pbf -B=deutschland.poly -o=output.osm.pbf

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 :wink: 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.

Grüße,

Baßtölpel

(+) 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.

Aber keine Bange: ich bin erst einmal ausgelastet :wink:

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.

Hab ich nicht genau das geschrieben? :wink:

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).

Diese Bedingung ist leider nicht hinreichend. Wenn z.B. ein Knoten zu einer Brücke gehöhrt und der zweite zu der Straße darunter, würde eine unbeabsichtigte Verbindung der beiden Straßen entstehen.

Sofern damit das Löschen eines der beiden Knoten gemeint ist, ist die Bedingung mit diesem Zusatz hinreichend.

Wenn damit aber das Löschen beider Knoten gemeint ist, hat dies nichts mehr mit Duplikaten zu tun. Man könnte natürlich diskutieren, ob es inzwischen sinnvoll ist, ungetaggte ungenutzte Nodes allgemein zu löschen. Zumindest nach dem Lauf des Redaction-Bot waren diese aber noch teilweise eine Hilfe. Vielleicht werden sie daher in manchen Gegenden noch immer gebraucht.

Das Landuse Problem dürfte durch Regeln, die man für die beteiligten Wege ohnehin aufstellen muss, abgedeckt werden. Siehe dazu mein Beispiel mit der Brücke. Unter bestimmten Bedingungen kann man daher wohl schon eine gewisse Positionsunschärfe zulassen.

Vorsichtig muss man da sein, aber es sollten sich Bedingungen aufstellen lasen, unter denen ein Merge möglich ist.

So ist die Bedingung hinreichend, um einen Knoten löschen zu dürfen. Jedoch kann die Bedingung noch erheblich ausgeweitet werden:

  1. Wenn nur einer der beiden Knoten in keiner Relation und in keinem Weg enthalten ist, kann dieser gelöscht werden.

  2. Wenn einer der beiden Knoten in keiner Relation und in keinem Weg enthalten ist, in denen der zweite Knoten nicht in im wesentlichen identischer Form enthalten ist, kann der erste Knoten gelöscht werden.
    Die im wesentlichen identische Form liegt vor, wenn beide Knoten jeweils unmittelbar hintereinander enthalten sind und bei Relationen zudem die gleiche Rolle haben.

  3. Bei abweichenden Tags kann es eine Positiv-Liste für Keys und Tags geben, die doch gemerged werden dürfen.
    Die Liste müßte dazu die Möglichkeit enthalten, die Tags in beiden Nodes (einschließlich des Nichtvorhandenseins), das resultierende Tag und eine zusätzliche Bedingung auf Basis anderer Tags anzugeben. Auch die Möglichkeit, eine zusätzliche Aktion wie das Setzen eines fixme Tags etc. auszulösen, sollte von der Liste unterstützt werden.

Diese Liste sollte im Wiki abgelegt sein. Der Bot sollte sie aber nicht direkt dort auslesen. Vielmehr müssen Änderungen noch diskutiert werden, bevor sie vom Bot übernommen werden, falls dies nicht bereits vorher geschehen ist.

In der Regel werden Tags, die Zusatzeigenschaften von Objekten beschreiben, in die Positiv-Liste aufgenommen werden können für den Fall, dass der Key nur in einem Weg vorhanden ist (z.B. ein surface Tag).

Bei den Tags, die der grundlegenden Differenzierung von Objekten dienen, wird dies in der Regel jedoch nicht möglich sein. Wenn zum Beispiel amenity=* nur in einem der Knoten vorhanden ist, ist ein automatisches zusammenfassen nicht möglich.

In einigen Fällen sind aber auch unterschiedliche Tags mit gleichem Schlüssel kombinierbar, wenn eines der Tags nur die Verfeinerung enthält. Beispielsweise kann aus surface=paved und surface=asphalt zu surface=asphalt werden.
Wenn man beispielsweise nicht sicher ist, ob dies für alle Arten von Objekten richtig ist, möchte man vielleicht noch eine Bedingung einführen, dass es nur bei highway=* gilt.

Im allgemeinen wird der Bot unterschiedliche Tags mit gleichem Schlüssel natürlich nicht korrekt kombinieren können.
Für gewisse untergeordnete Keys wäre es aber eventuell sinnvoll, dies dennoch provisorisch zu machen. Nehmen wir das bereits genannte Beispiel mit tracktype=grade1 und tracktype=grade3. Wäre es hier nicht eventuell besser, wenn der Bot hier das Duplikat beseitigt und tracktype=grade1;grade3 ggf. kombiniert mit einem fixme Tag zurückläßt. Eine sinnvolle Aussage macht dieses Tag natürlich genausowenig wie die ursprüngliche Situation. Vermutlich ist der verbleibende Restfehler aber für den normalen User (insbesondere wenn er Potlatch verwendet) besser erkennbar und behebbar als das ursprüngliche Duplikat. Man müsste allerdings eine Möglichkeit finden, dem User die History des gelöschen Objektes zugänglich zu machen, da man ihm sonst möglicherweise die Aufklärung erschwert.

  1. Bei Tags, die auf der Slippy Map gerendert werden, könnte man bei wiedersprüchlichen Tags ggf. auch dasjenige auswählen, das auf der Slippy Map (oder im Editor) dominant gerendert wird. Diese Entscheidung würde auf der Annahme beruhen, das die User ihre Arbeit im wesentlichen Anhand der Slippy Map kontrollieren.

  2. Wenn einzelne widersprüchliche Tags vorliegen, könnte der Bot anhand der History prüfen, ob eines der Objekte nachträglich geändert wurde und dann das neuere Tag verwenden. Aber auch hirzu sollte es eine Positivliste von Keys geben, für die dieses Vorgehen zulässig ist. Ansonsten ist das Risiko vermutlich zu groß.

  3. In Abhängigkeit von der Art des Objektes könnte man eine gewisse räumliche Unschärfe zulassen. Ich würde allerdings davor warnen, dies mit den Ausweitungen 2. bis 5. bei einem einzelnen Duplikat zu kombinieren.