User:Oli-Wan/Wall-E

From OpenStreetMap Wiki
Jump to: navigation, search

Contents

Short summary in English

Elisp This bot is a native speaker of Emacs Lisp
231+ This bot is 231 safe (unless run on Solaris).
Wikimedia Community Logo-Toolserver.svg This bot enjoys the kind support provided by the Wikimedia Toolserver.

Wall·E is a bot account operated by me (Oli-Wan) that I use to carry out automatic corrections of specific errors. Currently only objects in Germany and Austria are modified; therefore the rest of this wiki page is in German only, except for the following brief outline.

Wall·E currently corrects

  • misspelt or abbreviated road names in Germany, i.e. replaces "Strasse", "Str." and "Str" with "Straße" (and similarly for their all-lowercase counterparts), along with a few more narrowly defined spelling errors, appearing either in the name=* tag of roads or the addr:street=* tag of other objects;
  • several other types of errors in German address tags (ill values of addr:country=*, mis-formatted addr:postcode=*, swapped tags, postal code/city or street/housenumber combined into one tag);
  • superfluous whitespace in tags and roles (Germany, Austria);
  • repeated nodes in ways (Germany, Austria);
  • ways consisting of only one node (Germany).

Care is taken to ensure that country-specific correction algorithms only affect objects within Germany (defined by the OSM boundary) to avoid misfixes in adjacent countries (such as Switzerland, where "Strasse" is actually considered the correct spelling, or the Netherlands, where "str." would have to be expanded differently).

The edits performed by Wall·E are largely inspired by or even modeled after xybot, who used to correct a similar class of errors (though not always being quite aware of boundary issues), but has ceased operation in 2012.

Geographical scope and schedule

country/region road names addresses whitespace repeated nodes one-node-ways
Deutsche Flagge.jpg Germany 07./17./27. daily 07./17./27. 17. being developed
Flag of Austria.svg Austria every other Saturday
Flag of Switzerland.svg Switzerland
Flag of Europe.svg Europe - -
Blue globe icon.svg Planet - - planned (long term)

Übersicht

Elisp Dieser Bot spricht Emacs Lisp als Muttersprache
231+ Dieser Bot ist 231-sicher (außer auf Solaris).
Wikimedia Community Logo-Toolserver.svg Dieser Bot genießt die freundliche Unterstützung des Wikimedia Toolserver.

Wall·E ist ein von mir (Oli-Wan) betriebener Bot-Account, über den ich automatische Korrekturen bestimmter Fehler vornehme.

Derzeit werden folgende Korrekturen durchgeführt:

  • Korrektur der Schreibweise von Straßennamen (Status: Normalbetrieb, Details)
  • Korrektur von Adressfehlern (Status: Normalbetrieb, Details)
  • Amputation überschüssigen Leerraums (Status: Normalbetrieb, Details)
  • Korrektur von Wegen, bei denen ein Knoten mehrfach hintereinander auftritt (Status: Erprobung, Details)
  • Behandlung von Wegen mit nur einem Knoten (Status: Entwicklung, Details)

Mittelfristig geplant sind (vorbehaltlich der notwendigen Diskussion und hinreichender Unterstützung):

  • Korrektur eindeutiger Schreibfehler in Schlüsseln sowie Werten
  • Beseitigung bestimmter Klassen doppelter Knoten
  • ...?

Vorbild der durchgeführten Korrekturen ist xybot, der über lange Zeit eine ganze Reihe von Fehlern beseitigt, jedoch im Jahr 2012 seinen Betrieb eingestellt hat.

Arbeitsgebiete und Ausführungsplan

Land/Region Straßennamen Adressen Leerraum Wiederholte Knoten Ein-Knoten-Wege
Deutsche Flagge.jpg Deutschland 07./17./27. täglich[1] 07./17./27. 17. Entwicklung
Flag of Austria.svg Österreich Samstag alle zwei Wochen
Flag of Switzerland.svg Schweiz
Flag of Europe.svg Europa - -
Blue globe icon.svg Planet - - langfristig vorgesehen
  1. ↑ mit Rücksicht auf die /history-Seite derzeit auf 2-tägliche Ausführung reduziert

Details

Korrektur der Schreibweise von Straßennamen Deutsche Flagge.jpg

Einführung

Ziel der Korrektur ist die Beseitigung falsch geschriebener Straßennamen, welche das Wort "Straße" enthalten; hauptsächlich geht es um die falsche Schreibweise "Strasse" und die Abkürzung "Str." bzw. auch "Str", welche der Konvention widerspricht, daß der Gebrauch von Abkürzungen in OSM möglichst vermieden werden soll. Beispiele: 

Hauptstr. -> Hauptstraße
Bahnhofstrasse -> Bahnhofstraße
Str des Himmlischen Friedens -> Straße des Himmlischen Friedens

Hierbei ist zu beachten, daß die Regeln für die Schreibweise von Straßennamen in Nachbarländern abweichen können (in der Schweiz gilt "Strasse" als korrekte Schreibweise) und ferner die Abkürzung "str." ebenfalls, jedoch für ein anderes Wort in der jeweiligen Landessprache verwendet werden kann (Niederlande: "straat"). Daher ist streng darauf zu achten, Bearbeitungen nach dieser Ersetzungsregel nur innerhalb Deutschlands anzuwenden. Dies wird durch das Filterskript in geeigneter Weise berücksichtigt.

Neben den oben genannten werden auch noch einige weitere Fehlertypen korrigiert; diese sind im einzelnen im Abschnitt "Regelsatz" aufgeführt.

Bearbeitet werden ausschließlich Mf way.svg Wege mit einem gängigen highway=*-Tag, also Straßen im weitesten Sinne, und von diesen nur das name-Tag. Andere Objekte, die ebenfalls häufig nach Straßen benannt werden und ähnliche Fehler enthalten (Trafoboxen, Bushaltestellen, Telefonzellen, Kindergärten, ...) werden ignoriert. Bei diesen könnte man ggf. argumentieren, daß die "korrekte" Bezeichnung jene ist, welche der Betreiber vergeben und/oder auf das jeweilige Objekt geschrieben hat, unabhängig von deren orthographischen Mängeln. Bei Straßennamen wird dagegen allgemein angenommen, daß diese mindestens in Bezug auf den Namensbestandteil "Straße" den Regeln der deutschen Rechtschreibung folgen.

Regelsatz

Es folgt die vollständige Auflistung der angewendeten Ersetzungsregeln. Diese sind als regulärer Ausdruck implementiert, werden hier jedoch der Verständlichkeit halber in Klartext wiedergegeben. 

(1) Strasse/Str/Str. -> Straße
(2) strasse/str/str. -> straße

Diese Korrekturen werden jedoch nur durchgeführt, wenn der ursprüngliche Ausdruck am Wortende steht (genauer: wenn ein Leerzeichen oder das Stringende folgt; alternativ auch eine Ziffernfolge, in diesem Fall wird ein zusätzliches Leerzeichen eingefügt). Bei "Str" ist dies ohnehin erforderlich, da es sonst zu offensichtlich falschen Ersetzungen wie Strandallee -> Straßeandallee käme; darüber hinaus verhindert die Bedingung auch die Bearbeitung von Namen, die von den Orten oder Persönlichkeiten mit Namen "(zur) Strassen" abgeleitet sind (siehe Strassen bei Wikipedia), wie etwa "Zur-Strassen-Allee". Derzeit scheint es (in OSM) keine Straßen solchen Namens zu geben, denkbar sind sie dennoch.

In bestimmten Fällen wird die Korrektur unterdrückt. Dies betrifft einerseits Fälle, wo die Zeichenfolge "strasse" legitim auftritt und kein Schreibfehler von -strasse vorliegt (sondern s und trasse zusammentreffen): 

(E1) Gastrasse, Gleistrasse

(auch Kleinschreibung, wie etwa in Erdgastrasse). Hier wäre eine "Korrektur" falsch - außer wiederum im Fall einer Olga-strasse, für die eine Ausnahme von der Ausnahme eingerichtet ist.

Ferner gibt es auf "-gasse" endende Straßennamen, bei denen der Namensstamm auf st endet und ein bestimmter Tippfehler in "-gasse" (r statt g, angesichts der Nähe von r und g auf einer Qwert[zy]-Tastatur durchaus möglich) ebenfalls die Zeichenfolge "-strasse" erzeugt. Daher wird die Korrektur in solchen Fällen ebenfalls unterdrückt. Berücksichtigt werden derzeit die Zeichenfolgen, die sich durch Ersetzung von g durch r im Suffix "gasse" folgender Straßennamen ergeben: 

(E2a) Augustgasse Baptistgasse Bastgasse Christgasse Ernstgasse Forstgasse Fronfestgasse Fürstgasse
(E2b) Geistgasse Heiligegeistgasse Heiliggeistgasse Herbstgasse Jobstgasse Jostgasse Komstgasse
(E2c) Kostgasse Kunstgasse Mostgasse Nestgasse Obstgasse Ostgasse Pfingstgasse Postgasse Probstgasse
(E2d) Rustgasse Vestgasse Westgasse Wurstgasse Wüstgasse

Die Expansion von "str." wird im Spezialfall der Zeichenkette 

(E3) "Bgmstr." (Bürgermeister)

unterdrückt.

Ferner werden folgende Regeln angewandt, bei denen es im wesentlichen um die Korrektur "einfacher" Tippfehler bzw. Zeichensatzfehler geht: 

(3) STraße, sTraße als isoliertes Wort -> Straße
(4) Stra0e, Stra9e, Stra-e -> Straße
(5) weitere Fälle, in denen das ß in Straße durch ein eines der folgenden Zeichen ersetzt ist:
    s, S, kleines beta, großes Eszet, Unicode replacement character
            -> Straße
(6) Staße, Sraße -> Straße

(4) bis (6) werden analog auch auf die klein geschriebenen Varianten (-straße) angewandt. Ausnahme von (6): Zeichenkette tsraße - hier kann entweder ein Buchstabendreher (s,t) oder ein vergessenes t vorliegen (für den Algorithmus schwer zu unterscheiden).

Im Fall von (3) wurde offenbar die Umschalttaste für die Großschreibung zur falschen Zeit betätigt. In den Fällen (4) ist davon auszugehen, daß der Nutzer die falsche Taste erwischt hat (0 und 9 als Nachbarn von ß auf einer QWERTZ-Tastatur) bzw. Computer und Hände sich nicht über das zu verwendende Tastaturlayout (QWERTZ vs. QWERTY) einig waren. Im Fall (5) wurde vermutlich entweder s bzw. S als Ersatzzeichen für ß benutzt oder versucht, das Zeichen ß mithilfe einer Zeichensatztabelle oder ähnlicher Werkzeuge einzufügen, bzw. im Fall des Unicode replacement character kann auch ein Softwarefehler ursächlich sein. Bei (6) ist offenbar ein Buchstabe verloren gegangen.

Schlußendlich wird auch überschüssiger Leerraum am Anfang oder Ende des name-Tags entfernt: 

(A1) " A-Straße" -> "A-Straße", "B-Straße " -> "B-Straße", " C-Straße " -> "C-Straße",
     wobei der Leerraum jeweils aus einem oder mehreren Leerzeichen oder Tabs (oder sonstigen Leerzeichen im Unicode-Zeichensatz) bestehen kann.

Vorgehensweise (Skizze)

Der Korrekturvorgang faktorisiert vollständig in die Filterung eines Deutschland-Extrakts nach möglichen Kandidaten und die eigentliche Korrektur.

Zur Ermittlung möglicher Kandidaten wird zunächst ein Deutschland-Extrakt der Geofabrik nach Wegen durchsucht, die den oben genannten Kriterien genügen. Da die Extrakte grundsätzlich etwas zu groß zugeschnitten sind, wird anschließend jeder gefundene Weg dahingehend überprüft, ob er mit all seinen Knoten innerhalb eines präzisen Grenzpolygons liegt. Hierzu kommen Standardwerkzeuge der OSM-Welt (osmosis, osmfilter) und ergänzend dazu eigene C++-Programme auf Basis der Osmium-Bibliothek zum Einsatz.

Für die Korrektur wird GNU Emacs mit einem speziellen OSM-Paket eingesetzt. Die Kandidatenliste wird als .osm-Datei eingelesen. Anschließend wird jeder Kandidat erneut vom OSM-Server geladen und die Ersetzungsregel angewandt. Wenn diese zu einer Modifikation des name-Tags führt, wird das Objekt hochgeladen. Das Herunterladen unmittelbar vor der Bearbeitung stellt hierbei sicher, daß keine Probleme (Versionskonflikte) durch veraltete Daten aus dem Extrakt verursacht werden können.

Ausnahmen, Opt-out

Aufgrund von im Zuge der Diskussion entdeckten Ausnahmefällen, bei denen die Zeichenfolge "strasse" in einem Namen legitim vorkommt und kein Schreibfehler von "straße" vorliegt, wurde eine Ausnahmeliste in das Programm eingebaut. Diese umfaßt derzeit die Ausnahmen nach Zeilen E1 und E2 und kann jederzeit ergänzt werden; eine Email über den OSM-Account genügt.

Ferner pflegt das Programm eine Sperrliste, in die jedes bearbeitete Objekt automatisch aufgenommen wird. So wird verhindert, daß dieselbe Korrektur mehrfach durchgeführt wird: Ersetzt ein Mapper im Straßennamen wieder "Straße" durch z.B. "Strasse", nachdem dieser oder ein ähnlicher Fehler zuvor bereits korrigiert wurde, findet keine erneute Korrektur statt. In diesem Fall ist davon auszugehen, daß der Mapper sich bewußt für die (vermeintlich) falsche Schreibweise entschieden hat. Hieraus ergibt sich eine sehr einfache Möglichkeit zum "nachträglichen Opt-out" durch einmaliges Rücksetzen der ungewollten Bearbeitung ohne die Notwendigkeit den Bot-Betreiber zu kontaktieren oder gar das Objekt selbst in eine Sperrliste einzutragen. Dies sollte gerade weniger versierten Nutzern entgegenkommen.

Status, Ausführungsintervall

Seit 01.01.2013 läuft das Korrekturprogramm im Regelbetrieb. Nach zunächst manuellem Start in Abständen von einer bis zwei Wochen wird das Programm seit April 2013 vollautomatisch jeweils am 07., 17. und 27. jeden Monats ausgeführt.

Zuvor wurde ein Probebetrieb durchgeführt mit einer Beschränkung auf zunächst je 10, später 20 Objekte pro Änderungssatz (bei etwa einem Änderungssatz pro Tag).

Diskussion

Die beschriebene Korrektur wurde am 04.12.2012 im deutschen OSM-Forum vorgeschlagen und in der Folge diskutiert. Vorausgegangen war ein orientierendes Meinungsbild zur Wiederaufnahme der vormals von xybot durchgeführten Korrekturen. Der ursprüngliche Regelsatz enthielt nur die Regeln (1) und (2); die spätere Erweiterung um (3) bis (6) und (A1) basiert auf Anregungen aus dem Forum.

Korrektur von Adressfehlern Deutsche Flagge.jpg

Einführung

Hierbei handelt es sich um eine Gruppe verschiedener Korrekturen, die sich mit häufigen und relativ simplen Fehlern in Adresstags befassen. Angewandt werden sie analog zur Korrektur der Straßennamen nur innerhalb Deutschlands, hier jedoch an sämtlichen Objekten mit (fehlerhaften) Adresstags, also ohne weitere Beschränkung anhand des Objekttyps oder weiterer Tags. Einzig bei Relationen erfolgt eine Beschränkung auf solche mit type=multipolygon.

Regelsatz

  • Auf addr:street=* werden die gleichen Ersetzungsregeln angewandt wie bei der Korrektur von Straßennamen, mit den gleichen Ausnahmen.
  • In addr:country=* werden folgende Ersetzungen vorgenommen: 
Deutschland, Germany -> DE unabhängig von Groß- und Kleinschreibung des ursprünglichen Ausdrucks
de -> DE, De -> DE, GER -> DE

auch wenn der ursprüngliche Wert von Leerraum begleitet wird (welcher dann entfernt wird). 

D-12345 /D 12345 /D12345 /D - 12345
DE-12345/DE 12345/DE12345/DE - 12345

d.h. Buchstabe "D" oder Ländercode "DE" (unmittelbar oder nach einem Leerzeichen oder Bindestrich oder der Folge " - ") gefolgt von einer fünfstelligen Ziffernfolge und inklusive vorausgehendem oder nachfolgendem Leerraum durch die Ziffernfolge ersetzt. Falls noch nicht vorhanden, wird addr:country=DE ergänzt.

  • Trennung von Postleitzahl und Ort, wenn diese gemeinsam in ein Tag geschrieben wurden, bzw. Korrektur einer Vertauschung der Tags addr:postcode=* und addr:city=*. Beispiel: 
(1) addr:postcode=98765 Einen a.d. Waffel
(2) addr:city=98765 Einen a.d. Waffel
(3) addr:postcode=98765, addr:city=98765 Einen a.d. Waffel
(4) addr:postcode=98765 Einen a.d. Waffel, addr:city=Einen a.d. Waffel
(5) addr:postcode=Einen a.d. Waffel, addr:city=98765
       jeweils -> addr:postcode=98765, addr:city=Einen a.d. Waffel

Eine Möglichkeit ist, daß entweder addr:postcode=* oder addr:city=* die Form "PLZ Ort" hat (1,2). In diesem Fall wird die falsch verortete Information in das jeweils andere Tag übertragen und das ursprüngliche Tag verkürzt. Die Erkennung des Taginhalts geschieht mittels eines regulären Ausdrucks; ferner wird vor jeder Bearbeitung anhand einer Liste überprüft, ob die beiden Bestandteile zusammenpassen.

Außerdem gibt es Fälle, wo zusätzlich zu "PLZ Ort" in einem der Tags ein Teil der Information im jeweils anderen Tag enthalten ist (3,4). Wenn beide Tags untereinander konsistent sind, wird das überfüllte Tag gekürzt; hierbei wird kein Abgleich mit der PLZ-Liste durchgeführt.

Ebenfalls ein häufiger Fehler ist die Vertauschung beider Tags (5). Eine Korrektur dieser Vertauschung wird vorgenommen, wenn die Kombination von Postleitzahl und Ort in der schon erwähnten PLZ-Liste enthalten ist.

Im Zuge dieser Korrekturen wird auch überschüssiger Leerraum aus den beiden Tags entfernt; und zwar auch dann, wenn dies der einzige vorliegende Fehler ist. Ferner wird die jeweilige Korrektur auch dann vorgenommen, wenn die Postleitzahl in der Form mit vorausgehendem "D" (s.o.) hat; die Postleitzahl wird dann auf die fünfstellige Zahl reduziert.

Zur Erstellung der besagten PLZ-Liste habe ich alle Relationen mit postal_code=* aus germany.osm analysiert und soweit möglich die zugeordneten Namen herausgelesen. Dies sind zum einen admin-Grenzrelationen, wo name=* den Ortsnamen enthält, zum anderen reine PLZ-Relationen, wo der Name meist im Tag note=PLZ Ort steckt. Herausgekommen ist eine Liste, die zu jeder eingetragenen PLZ die damit assoziierten Ortsnamen aufführt, etwa: (49448 "Stemshorn" "Quernheim" "Marl" "Hüde" "Brockum" "Lemförde"). Bei diesem Beispiel würde bei Vorliegen von addr:postcode=Marl, addr:city=49448 die Vertauschung der Tags durchgeführt; im Falle von addr:postcode=Pusemuckel nicht. Analog würde "49448 Hüde" (egal in welchem der beiden Tags) zerlegt; "49448 Kleinkleckersdorf" nicht.

Der Abgleich des zu bearbeitenden Objekts gegen die PLZ-Liste geschieht nun wie folgt: zunächst wird geprüft, ob der mutmaßliche Ortsname mit einem der laut PLZ-Liste mit der Postleitzahl assoziierten Ortsnamen exakt übereinstimmt. Ist dies nicht der Fall und besteht einer der zu vergleichenden Namen aus mehreren Wörtern, wird dessen erstes Wort mit dem - kompletten - anderen Namen verglichen. Auch in diesem Fall wird davon ausgegangen, daß PLZ und Ort aus dem analysierten Tag zusammenpassen. Beispiel: Die PLZ-Liste enthält (55411 "Bingen am Rhein"). Neben "55411 Bingen am Rhein" kann mit der großzügigeren Prüfung auch "55411 Bingen" verarbeitet werden.

  • Trennung von Straße und Hausnummer, wenn beide zusammen in addr:street=* oder addr:housenumber=* geschrieben wurden. Der Korrekturalgorithmus funktioniert im Prinzip analog zur Trennung von Postleitzahl und Ort. 
(1) addr:street=Hauptstraße 123a
(2) addr:housenumber=Hauptstraße 123a
(3) addr:street=Hauptstraße 123a, addr:housenumber=123a
(4) addr:housenumber=Hauptstraße 123a, addr:street=Hauptstraße
       jeweils -> addr:street=Hauptstraße, addr:housenumber=123a

Eine grundsätzliche Komplikation ist hierbei die Existenz einzelner Straßen, an deren Name tatsächlich eine Zahl steht; hier könnte es zu Fehlkorrekturen kommen. Deshalb ist als Sicherheitsvorkehrung ein Abfrage an die Overpass API vorgesehen: die Korrektur wird nur dann durchgeführt, wenn es in der Nähe des bearbeiteten Objekts eine Straße gibt, deren name=* mit dem aus den vorliegenden Tags abgeleiteten Straßennamen übereinstimmt. In den Fällen (3,4) wird ferner verlangt, daß die vorhandenen Tags untereinander konsistent sind.

  • In bestimmten Fällen wird eine weitergehende Korrektur von Straßen- und Ortsnamen versucht. Derzeit lautet das Kriterium auf einen Kleinbuchstaben am Stringanfang (etwa "soliger straße" bzw. "langenfeld"). Bei solch verdächtigen Werten wird der entsprechende Name dahingehend bearbeitet, daß 1) innenliegender Leerraum auf genau ein Leerzeichen normalisiert wird, 2) Kombinationen von Bindestrich und Leerraum auf genau einen Bindestrich reduziert werden und 3) alle Wörter außer (dem Algorithmus bekannten) Präpositionen und Artikeln in Großschreibung gebracht werden (das erste Wort wird stets groß geschrieben). Der so konstruierte Name wird jedoch nur eingesetzt, wenn er durch eine Overpass API-Abfrage verifiziert werden kann: ein Straßenname nur dann, wenn eine entsprechende Straße in der Nähe gefunden wird (Overpass QL: around), ein Ortsname nur, wenn das bearbeitete Objekt innerhalb einer Fläche (Overpass QL: is_in) mit diesem Namen liegt.

Vorgehensweise (Skizze)

Die Vorgehensweise ist weitestgehend analog zu jener bei der Korrektur von Straßennamen. Auch hier wird ein Geofabrik-Extrakt gefiltert, fehlende Objekte nachgeladen und grenzgenau nachgeschnitten, bevor das eigentliche Korrekturprogramm zum Einsatz kommt.

Ausnahmen, Opt-out

Für die Korrekturen in addr:street gelten dieselben Ausnahmen wie bei der Korrektur von Straßennamen.

Ferner ist auch für diesen Korrekturprozeß eine Sperrliste implementiert, welche sicherstellt, daß jedes Objekt nur einmal einer Adresskorrektur unterzogen wird.

Status, Ausführungsintervall

Nach einem erfolgreichen Probebetrieb mit Beschränkung auf zunächst 20, dann 60 Objekte pro Änderungssatz ist das Programm Anfang April 2013 in den Normalbetrieb übergegangen und wird bis auf weiteres täglich ausgeführt.

Diskussion

Beseitigung überschüssigen Leerraums Deutsche Flagge.jpg Flag of Austria.svg

Es wird überschüssiger Leerraum (inklusive Zeilenumbrüchen) am Anfang und/oder Ende von Schlüsseln und Werten entfernt.

Ausnahme: wenn die Entfernung von Leerraum aus einem Schlüssel zu einem Schlüssel führen würde, der bereits vorhanden ist ("key " zu "key", aber "key" bereits vorhanden), und sich die eingetragenen Schlüssel widersprechen. Falls der Schlüssel oder Wert ausschließlich aus Leerraum besteht, nach der Korrektur also leer wäre, wird er nicht angerührt. Ferner wird jedes bearbeitete Tag dahingehend überprüft, ob es in früheren Versionen identisch oder nicht vorhanden war. So sollen z.B. verlorene Wortbestandteile auffindbar bleiben, etwa wenn versehentlich "Kindergarten Pusemuckel" zu "Kindergarten " geändert wurden.

Die Korrektur wird grundsätzlich auf alle Objekte in Deutschland (Geofabrik-Extrakt) angewandt (keine weiteren Beschränkungen). Das Filterprogramm ignoriert jedoch Leerraum in einigen Tags, wo mir dessen Beseitigung unnütz erscheint, da diese Tags ohnehin nur internen Zwecken dienen (source, note, fixme usw.), wegen systematisch falscher Verwendung praktisch nutzlos sind (designation) oder typischerweise im Zusammenhang mit verkorksten Importen auftreten, wo ein viel gründlicheres Aufräumen geboten wäre und die Leerraumbeseitigung reine Kosmetik darstellen würde (area:ha, eea:cdda:sitecode).

Beschreibung des Algorithmus

Wie üblich dient ein Geofabrik-Extrakt als Ausgangsmaterial, aus dem Objekte mit Leerraum in Tags ausgefiltert werden. Auf das grenzgenaue Nachschneiden wird in diesem Fall verzichtet, da die Korrektur nicht landesspezifisch ist. Die erhaltenen Kandidaten werden anschließend durch den Korrekturalgorithmus frisch vom API-Server geladen, erneut überprüft, ggf. korrigiert und wieder hochgeladen.

Die Korrekturfunktion schleift durch alle Tags (Schlüssel-Wert-Paare). Zuerst wird jeweils der Wert untersucht und bei Vorhandensein von Leerraum überprüft, ob eventuelle Vorgängerversionen des Tags identisch waren. Falls nicht, wird abgebrochen; andernfalls wird nun unterschieden, ob der Wert ausschließlich aus Leerraum besteht, nach dessen Beseitigung also leer wäre. Solche Tags werden nicht bearbeitet. Werte, die neben Leerraum noch weitere Zeichen enthalten, werden vom Leerraum befreit. Anschließend geht es weiter mit dem Schlüssel. Der Algorithmus geht hier zunächst völlig analog wie beim Wert vor, prüft vor der Entfernung von Leerraum aber auf Konflikte mit anderen Schlüsseln. Ist der geänderte Schlüssel bereits vorhanden und enthält einen abweichenden Wert, wird die Korrektur unterlassen; bei identischem Wert wird das Tag mit Leerraum im Schlüssel gelöscht. Gibt es keinen konkurrierenden Schlüssel, erfolgt die Leerraumbeseitigung ohne weitere Komplikationen.

Ausnahmen, Opt-out

Auch für diese Korrektur wird eine Sperrliste eingerichtet, welche in diesem Fall aber primär der Fehlersuche dient. Die Möglichkeit zum "nachträglichen Opt-out" ist somit auch hier gegeben, wenngleich hierfür eigentlich bei dieser speziellen Korrektur kein Bedarf bestehen sollte.

Status, Ausführungsintervall

Anfang April 2013 entwickelt, getestet und in den Normalbetrieb überführt. Ausführung nun im gleichen Intervall wie die Korrektur der Straßennamen (07., 17., 27.).

Diskussion

Wall·E räumt auf: Leerraum in Tags: Zunächst lautes Nachdenken und erste Überlegungen zum Vorgehen, schrittweise Entwicklung des Algorithmus und am 01.04.2013 Vorstellung eines Programms. Inbetriebnahme und Erprobung nach kleinen Änderungen. Wenig später Ausdehnung auf Österreich auf Anregung von Walter Schlögl.

Reduktion wiederholter Knoten in Wegen Deutsche Flagge.jpg Flag of Austria.svg

Es geht um die Korrektur von Wegen, die ein und denselben Knoten mehrfach unmittelbar hintereinander enthalten. Hauptursache hierfür ist traditionell ein seit Jahren bekannter, aber nie komplett behobener Bug gleichermaßen in Potlatch 1 und Potlatch 2. Ebenso erzeugt dieser Editor Wege, die nur einen einzigen Knoten enthalten; für diese gibt es jedoch ein eigenes Korrekturprogramm. In jüngerer Zeit haben auch andere Editoren solche Wege erzeugt, darunter JOSM infolge eines Defekts in einem Plugin.

Im Falle wiederholter Knoten werden diese auf jeweils ein Exemplar reduziert: aus A-A-B-C wird A-B-C. Der Algorithmus wird auch mit mehreren wiederholten Knoten fertig (A-A-B-B-B-C-C wird ebenfalls zu A-B-C). Legitime Fälle wie A-B-C-A (geschlossener Weg) oder A-B-C-D-B werden hingegen nicht angefaßt.

Einen Sonderfall bilden solche Wege, die ausschließlich aus Wiederholungen desselben Knoten (A-A-A) bestehen. Da diese äquivalent zu einem Weg aus nur einem Knoten sind, werden sie vom Algorithmus ignoriert.

Beschreibung des Algorithmus

Der Algorithmus prüft einen vom Filterprogramm beanstandeten Weg zunächst dahingehend, ob er 1) tatsächlich Wiederholungen von Knoten enthält (A-B-B-C, nicht A-B-C) und 2) mehr als nur einen einzigen Knoten referenziert (A-B-B, nicht A-A-A). Fällt der Weg in dieses Beuteschema, wird die Knotenliste des Weges per Schleife Element für Element kopiert, sofern das jeweilige Element keine Wiederholung des zuvor kopierten Elements darstellt. Anschließend wird die Knotenliste durch die neue Liste ersetzt und der geänderte Weg hochgeladen.

Die Einrichtung einer Sperrliste erscheint im Fall dieser speziellen Korrektur verzichtbar.

Status, Ausführungsintervall

In Vorbereitung/Erprobung. Regelmäßige Ausführung in DE und AT mit anschließender Kontrolle. Übergang zum Normalbetrieb (d.h. Verzicht auf die nachträgliche Kontrolle) nach einer hinreichenden Zahl unauffälliger Bearbeitungen.

Diskussion

Im deutschsprachigen Forum ab 10.04.2013.; Ausdehnung auf Österreich.

Siehe auch: Tickets/Issues

Wege mit nur einem Knoten

Diese Bearbeitung befindet sich noch in der Entwicklung. Geplante Ergänzungen werden jeweils im Forum vorgestellt und anschließend schrittweise aufgenommen.

Wege mit nur einem Knoten werden von verschiedenen Editoren hinterlassen, führend ist hier Potlatch 2. "Wege" mit nur einem Knoten sind unsinnig, daher sollen sie eliminiert werden. Die einfachste Lösung bestünde in der pauschalen Löschung aller derartigen Wege. Davon möchte ich aber absehen und mich lieber auf Fälle beschränken, wo per Algorithmus (weitestgehend) sicher entschieden werden kann, daß der Weg keine Restinformation enthält, aus der ein menschlicher Korrekteur noch Information herausziehen könnte, die eine "bessere" Korrektur erlauben. Dies trifft in folgenden Fällen zu:

  • 1NW01 Der Weg hat keine Tags, ist nicht Element einer Relation, seine Version ist 1. In diesem Fall enthält der Weg keinerlei Information.
  • 1NW02 Der Weg ist nicht Element einer Relation, seine Version ist 1; die Tags des Weges sind identisch zu den Tags eines weiteren Weges, der denselben Knoten enthält. (Sämtliche mit dem Weg gelöschten Informationen sind an dem anderen Weg weiterhin vorhanden.)
  • 1NW03 Der Weg ist nicht Element einer Relation, seine Version ist > 1; die Tags des Weges sind identisch zu den Tags eines weiteren Weges, der denselben Knoten enthält sowie ferner alle Knoten, die in der Vorgängerversion noch im nun kaputten Weg enthalten waren. In diesem Fall enthält der reguläre Weg neben den Tags auch die gesamte frühere Geometrieinformation des nun defekten Weges.
  • 1NW04 wie 1NW03, jedoch muß der weitere vorhandene Weg nur die noch existierenden Knoten aus der Vorgängerversion des nun defekten Wegs enthalten, d.h. es dürfen auch Knoten gelöscht worden sein. Unterstellt man, daß die Löschung der Knoten (bzw. auch des sie referenzierenden, nun defekten Weges) beabsichtigt war, enthält der defekte Weg keine Information, die nicht auch anderweitig vorhanden ist, und erfüllt auch keine Markerfunktion.

In diesen Fällen wird daher der betroffene Weg gelöscht.

Die obige Liste wird sukzessive ergänzt durch weitere im Zuge von Testing und Diskussion als sicher erkannte Szenarien. Aktuell werden untersucht:

  • 1NW05 wie 1NW02, die Tags des Weges sind jedoch am Knoten selbst statt an einem von dessen übrigen Eltern.
  • 1NW13 wie 1NW03, jedoch keine komplette Übereinstimmung der Tags, sondern nur Übereinstimmung bis auf triviale Tags.
  • 1NW14 wie 1NW04, jedoch keine komplette Übereinstimmung der Tags, sondern nur Übereinstimmung bis auf triviale Tags.
  • 1NW22 analog zu 1NW02, jedoch ist der Weg Element einer oder mehrerer Relationen. Der weitere Weg, welcher den Knoten enthält und die Tags dupliziert, ist ebenfalls Element all dieser Relationen. Der Ein-Knoten-Weg kann in diesem Fall aus den Relationen entfernt und gelöscht werden.

Wenn ein Weg gelöscht wird und der von ihm referenzierte Knoten weder selbst Tags enthält noch Teil eines anderen Weges oder einer Relation ist, kann der Knoten ebenfalls entsorgt werden.

Als trivial gelten neben created_by=* und source=* Tags mit Standardwerten wie layer=0, access=yes und oneway=no.

Ausnahmen, Opt-out

Nicht vorgesehen.

Status, Ausführungsintervall

Das Programm für diese Korrekturgruppe unterliegt noch einer intensiven Entwicklung. Derzeit wird es unregelmäßig mit unterschiedlichen Limits ausgeführt, je nach Entwicklungsstand eines neu zu berücksichtigenden Kriteriums. Bei zufriedenstellenden Ergebnissen wird es sich voraussichtlich in die Riege der etwa 10-täglich durchgeführten Korrekturen einreihen.

Mit den bisher berücksichtigten Kriterien konnte der Bestand an Ein-Knoten-Wegen in (Geofabrik-)DE immmerhin schon von 540 auf 296 gedrückt werden (trotz kontinuierlicher Erzeugung neuer Ein-Knoten-Wege).

Diskussion

Im deutschsprachigen Forum ab 23.04.2013.

Bearbeitungen "nebenbei"

Wall·E entfernt bei Objekten, die er bearbeitet, ein eventuell vorhandenes created_by=*-Tag.

Protokoll

Das vom Programm geschriebene Logfile ist unter http://toolserver.org/~mapjedi/wall-e-log.txt einsehbar (automatische Aktualisierung bei jeder Ausführung). Technisch bedingt fehlen einzelne Läufe (vor allem aus der Erprobungsphase), diese wurden jedoch besonders gründlich überprüft.

Bekannte Fehler

Im folgenden werden falsche Korrekturen und fehlerhafte Bearbeitungen aufgeführt, die bei der Durchsicht der Protokolle und Änderungssätze festgestellt wurden. Die vielen noch vorhandenen Fehler und Unzulänglichkeiten des Programms, welche "nur" z.B. zu Programmabstürzen, aber nicht zu falschen Korrekturen führen, werden dagegen hier ebensowenig diskutiert wie die Fälle, wo Wall·E nicht alle vorhandenen Fehler beseitigen kann oder konnte.

  • Yes check.svg node 1646044567/history Knoten 1646044567: Hier wurde wie vorgesehen "Str" zu "Straße" expandiert. Der tatsächlich vorhandene Fehler bestand jedoch in einem eingefügten Leerzeichen im Wort "Straße", sodaß effektiv "Str aße" durch "Straße aße" ersetzt wurde. Dieser bei der Planung nicht bedachte Sonderfall wird inzwischen abgefangen.
  • Yes check.svg Bei Bearbeitungen bis zum 25. Februar 2013 kam es durch eine falsche Formatangabe bei der Erzeugung von XML-Output zu einer unbeabsichtigen Rundung der Koordinaten von Mf node.png Knoten; im Extremfall konnte hierbei eine Verschiebung um etwa 7 cm entstehen. Dieser Fehler ist behoben.
  • Exclamation.svg Beim Versuch, Wall·E im Toolserver-Cluster auch auf einer Solaris-Maschine auszuführen, stellte sich völlig unerwartet heraus, daß die Solaris-Version von GNU Emacs Ganzzahlen größer als 231 nicht in Gleitkommazahlen umwandelt. Hierbei wurde die Sperrliste für Adresskorrekturen zerschossen und war daher bei einer folgenden Bearbeitung für Knoten jenseits 231 wirkungslos. Hiervon betroffen war jedoch nur ein Objekt, der weiter unten aufgeführte Knoten in einer Brunnenstraße.
  • Yes check.svg node 2287933388/history Knoten 2287933388: Wegen einer falschen Regex-Backreference wurde hier addr:city="47608 Geldern" nicht durch "Geldern", sondern durch eine leere Zeichenkette ersetzt. Der zugrundeliegende Fehler ist behoben.

Ferner wurden Bearbeitungen durch Wall·E in folgenden Fällen rückgängig gemacht, wo ich jedoch nicht von einem Programmfehler sprechen möchte:

  • Der Name der Mf way.png Matthias-Joseph-Mehs-Straße in Wittlich hat sich bereits mehrfach geändert, woran auch Wall·E einen Anteil hatte. Hintergrund ist ein inzwischen behobener Fehler in der kommunalen Straßenliste (Aussage der Gemeindeverwaltung dazu: "Auch wenn wir in der Eifel wohnen schreiben wir Straße nach Duden, d. h. mit "ß". Auch die besagte Joseph-Mehs-Straße."). Inzwischen wird sie in OSM wieder als "Straße" geführt.
  • node 2125594225/history Knoten 2125594225: Wall·E hat hier "Brunnenstrasse" zu "Brunnenstraße" korrigiert. Daraus wurde später wieder "Brunnenstrasse". Da zugleich jedoch die Hausnummer verschwand und der Bearbeiter Anfänger war, halte ich dies nicht für einen bewußten Opt-out.
  • Mf way.png Weg 172319298: "Sülzburgstr." zu "Sülzburgstraße" und zurück.
  • Im Änderungssatz 14723240 wurden Bearbeitungen durch Wall·E revertiert. Wie sich herausstellte, hatte der betreffende User die Nummer eines Änderungssatzes, welchen er revertieren wollte, falsch abgetippt. Nach manueller Entfernung aus der Sperrliste wurden die Objekte erneut korrigiert.
  • node 2335655994/history Knoten 2335655994, node 432634159/history Knoten 432634159: Trennung von Straße und Hausnummer sowie Postleitzahl und Ort durch Wall·E, durch den Ersteller wieder zusammengesetzt.
  • Mf way.png Weg 220429754, Mf way.png Weg 220430191, Mf way.png Weg 220431360:"Mittelstrasse" zu "Mittelstraße" und zurück.
  • Mf way.png Weg 138507704: "Landsberger Strasse" zu "Landsberger Straße" und zurück.

FAQ

  • Warum laufen die Korrekturen nur in Deutschland? In (Land einsetzen) gibt es ganz ähnliche Fehler.
Eine automatisierte Fehlerkorrektur bedarf der Zustimmung der Community. Für DE hat das deutschsprachige Forum zu den oben genannten Korrekturen seinen Segen erteilt. Falls in anderen Ländern Interesse besteht, Wall·E auch dort einzusetzen, bitte mit mir Kontakt aufnehmen.
  • Wall·E hat eine falsche Änderung vorgenommen. Was soll ich tun?
Wenn es nur um einen "einmaligen" örtlichen Sonderfall geht, also kein Muster dahintersteckt, welches auch anderswo zu einer falschen Korrektur führen könnte, genügt es, die Änderung einmalig rückgängig zu machen bzw. das alte Tagging wiederherzustellen. Wall·E ist so programmiert, daß er dieselbe Änderung kein zweites Mal durchführt. (Sollte das wider Erwarten nicht klappen, bitte Nachricht an mich! Technisch bedingt kann dies in Einzelfällen vorkommen.)
Falls derselbe oder ein ähnlicher Sonderfall auch andernorts denkbar ist oder die Korrektur gar nach einem Programmierfehler aussieht (etwa, wenn sie nach den auf der Wiki-Seite dokumentierten Regeln gar nicht stattfinden sollte): bitte Nachricht an mich, damit ich das Programm korrigieren bzw. mit einer weiteren Ausnahmeregel versehen kann. Ansonsten gilt dasselbe wie oben: für das betroffene Objekt genügt es, die Änderung einmalig rückgängig zu machen.
  • Ich habe einen weiteren Vorschlag für Korrekturen, die Wall·E durchführen könnte. Kannst du den mit aufnehmen?
Grundsätzlich ja. Voraussetzung ist aber, daß es tatsächlich um die Korrektur eindeutiger Fehler (nicht etwa das Umtaggen konkurrierender Taggingschemata) geht, diese Korrektur sinnvoll und mit großer Sicherheit automatisierbar ist, und das Vorhaben breite Unterstützung in der Community (repräsentiert z.B. durch das jeweilige Forum oder die Mailingliste) findet. Vorschläge bitte entweder per Mail an mich oder (für Korrekturen in Deutschland) direkt im deutschen OSM-Forum.

Siehe auch

Adressen

Typische Fehler in Adresstags werden unter anderem im housenumbervalidator angezeigt, dessen Filterschema dem von Wall·E verwendeten sehr ähnlich ist. Nahezu alle Adressen, die Wall·E als fehlerhaft erkennt, jedoch nicht korrigieren kann, landen dort. Ein bemerkenswertes Alleinstellungsmerkmal dieses Werkzeugs ist seine Duplikatprüfung.

Schreibfehler in Straßennamen sowie einige andere Fehler lassen sich mit dem Adresslayer des OSM Inspector aufspüren.

Der OSMAddressCorrector zeigt Mut zur Masse. Hier werden neben fehlerhaften bzw. nicht plausiblen Adressen auch zahllose unvollständige Adressen (d.h. solche ohne das Komplettpaket von Adresstags) angezeigt.

Elementare Geometriefehler

Wege mit nur einem Knoten und Wege mit wiederholten Knoten im OSM Inspector.

Technische Einzelheiten

Im folgenden werden die verwendeten Algorithmen am Beispiel der Korrektur von Straßennamen näher erläutert; die übrigen Korrekturen sind weitestgehend analog umgesetzt. Zum grundsätzlichen Verständnis der Vorgehensweise sind diese Einzelheiten nicht nötig; die Informationen hier sind als Starthilfe für den Fall gedacht, daß jemand ein ähnliches Werkzeug entwickeln möchte. (Es geht hier ausschließlich um technische Aspekte; für welche Aufgaben ein Boteinsatz sinnvoll ist, wird hier nicht thematisiert und wird im konkreten Fall mit der Community zu diskutieren sein. Auch an die Mechanical Edit Policy sei erinnert.)

DataFlow Wall-E.svg

Filterung

Vorüberlegungen

Es sollen Kandidaten gefunden werden, die folgenden Kriterien entsprechen

Die Filterung nach Tags darf ruhig etwas grob sein, also zu viele Objekte erfassen, da bei der Korrektur dieses Kriterium ohnehin noch einmal überprüft wird. Dagegen muß die Prüfung der räumlichen Lage zuverlässig und exakt erfolgen, da die zur Korrektur verwendete Plattform hierauf nicht ausgelegt ist.

Als Ausgangsmaterial dient ein Deutschland-Extrakt der Geofabrik im pbf-Format. Dieses wird von einem Filterprogramm eingelesen und Objekt für Objekt auf die Filterkriterien überprüft. Dabei werden jedoch die Abhängigkeiten nicht berücksichtigt, sodaß anschließend die zu einem Wege gehörenden Knoten (und Elemente von Relationen) fehlen. Diese werden von einem weiteren Programm nachträglich aus dem Extrakt gelesen und anschließend durch osmosis mit ihren "Eltern" zusammengeführt. Das Ergebnis ist eine osm-Datei mit den gefilterten Wegen inklusive ihrer Knoten.

Die Geofabrik-Extrakte sind prinzipbedingt stets etwas zu groß, d.h. der Filtervorgang bis hier wird auch Wege außerhalb Deutschlands (insbesondere in der Schweiz) liefern. Mit Hilfe der nachgeladenen Knoten werden die Wege dahingehend überprüft, ob sie vollständig innerhalb des Grenzpolygons liegen. Für diese Filterung kommt osmfilter zum Einsatz (gepatcht um eine höhere Grenze für die Größe von Polygonen).

Algorithmen zur Erkennung der diversen Fehlertypen

Die Algorithmen sind hier schematisch als vereinfachter Auszug aus dem C++-Code dargestellt. Qualifizierer, Elementzugriffe usw. sind der Einfachheit halber teilweise ausgelassen. Die angegebenen Regexe etc. dienen nur der Illustration und nicht notwendigerweise vollständig bzw. aktuell. Übertragungsfehler sind ebenfalls wahrscheinlich.

Straßennamen

bool-Funktion; true im Falle eines Treffers. Wird verwendet in Kombination mit einer Tagfilter-Klasse. 

if (!get_value_by_key ("highway") || !get_value_by_key ("name")) return false;
return (regex_match (get_value_by_key ("highway", "primary(_link)?|secondary(_link)?|...")
         && regex_search (get_value_by_key ("name", "[Ss](tr(asse|\\.)?( |$)|..."));
Adressen

bool-Funktion; true im Falle eines Treffers. Wird verwendet in Kombination mit einer Tagfilter-Klasse. t ist ein Taglist-Objekt.

  • Falls addr:country vorhanden: Veto auf Werte NL,BE,FR,CH,...; Treffer bei sonstigen Werten außer DE. 
if (tag_value = t.get_value_by_key (key_addr_country)) {
  if (regex_match (tag_value, "AT|CH|FR|LU|BE|NL|DK|PL|CZ")) return false;
  if (!regex_match (tag_value, "DE")) return true;
}
  • Falls addr:postcode vorhanden: Treffer, wenn nicht aus fünf Ziffern bestehend 
if (tag_value = t.get_value_by_key (key_addr_postcode.c_str())) {
  if (!regex_match (tag_value, "[[:digit:]]{5}")) return true;
}
  • Falls addr:street vorhanden: Treffer bei falschen Schreibweisen oder Ziffern, zu letzterem jedoch etliche Ausnahmen 
if (tag_value = t.get_value_by_key (key_addr_street)) {
  if (regex_search (tag_value, "[Ss]tr(\\.|asse)?( |$)|...") return true;
  if (regex_search (tag_value, "[[:digit:]]")
      && !(regex_match (tag_value, "(Straße|Platz) des [[:digit:]]{1,2}\\. (Januar|Februar|März|April|Mai|Juni|Juli|August|September|Oktober|November|Dezember)")
           || regex_match (tag_value, "(An der (alten )?)?([ABLK] ?|((Bundes|Landes|Kreis)straße) )[[:digit:]]+")
           || ... // weitere Ausnahmen
      ))
    return true;
}
  • Falls addr:housenumber vorhanden: Treffer bei typischem Fehlermuster "Straße Hausnummer", jedoch verschiedene Ausnahmen 
if (tag_value = t.get_value_by_key (key_addr_housenumber)) {
  if ((regex_search (tag_value, "[[:digit:]]|^[[:lower:]]|[[:lower:]][[:upper:]]"))
      && !(regex_match (tag_value, housenumber_exception1))
      && !(regex_match (tag_value, housenumber_exception2)))
    return true;
}
  • Falls addr:city vorhanden: Treffer bei Ziffer, Kleinbuchstabe am Anfang oder Kombination Kleinbuchstabe-Großbuchstabe 
if (tag_value = t.get_value_by_key (key_addr_city)) {      
  if (regex_search (tag_value, "[[:digit:]]|^[[:lower:]]|[[:lower:]][[:upper:]]")) return true;
}
Leerraum

bool-Funktion; true im Falle eines Treffers. Wird verwendet in Kombination mit einer Tagfilter-Klasse. Der Iterator bezieht sich auf ein Taglist-Objekt. 

for (const_iterator i = begin(); i != end(); ++i) {
  if ((regex_search (i->value(), "[[:blank:]]$|^[[:blank:]]")
       && !(regex_search (i->key(), "note|...")))
      || regex_search (i->key(), "[[:blank:]]$|^[[:blank:]]"))
    return true;
}
return false;
Mehrfache Knoten

Funktion void way() von RepeatedNodesHandler<THandler> als abgeleiteter Klasse von Osmium::Handler::Forward<THandler>. 

osm_object_id_t previous (-1);
bool repeatedNode = false;
for (const_iterator i = way->nodes().begin(); i != way->nodes().end(); ++i) {
  if (i->ref() == previous) {
    repeatedNode = true;
    break;
  }
  previous = i->ref();
}
if (repeatedNode) Forward<THandler>::way (way);
Wege mit nur einem Knoten

Funktion void way() von SingleNodeWaysHandler<THandler> als abgeleiteter Klasse von Osmium::Handler::Forward<THandler> 

if (way->nodes().size() < 2)
  Osmium::Handler::Forward<THandler>::way (way);

Implementierung

Details folgen

(Anstelle des hier zuvor gezeigten AWK-Programms wird ein vielfach schnelleres C++-Programm eingesetzt. Der Quellcode wird später bereitgestellt werden.)

Korrektur

Details folgen

Retrieved from "http://wiki.openstreetmap.org/w/index.php?title=User:Oli-Wan/Wall-E&oldid=916117"
Personal tools
Namespaces

Variants
Actions
site
Toolbox