Nahmd,
Bittschön: 146665 Zeilen als Gzip (1.7Mb) oder Bzip2 (1.4Mb).
Gruß Wolf
Dankschön für die 146665 Zeilen, von denen nach Ausfiltern von /[Cc]adastre|eea:cdda:sitecode|area:ha/ (Cadastre FR, Naturschutzgebiete CZ) noch 23170 übrig bleiben. Dann noch tschechische is_in-Tags weg: /[Cc]adastre|eea:cdda:sitecode|area:ha| kraj, CZ/ und es sind noch 13236 Zeilen, mal eben ein Faktor 10 weniger als im Original.
… und noch ein Beispiel für hübsch formatierte, aber sinnlose Gleitkommazahlen: http://www.openstreetmap.org/browse/way/190063651
Man beachte hierbei die Rundungsfehler durch die begrenzte Auflösung von IEEE 754 double. Hätte der Ersteller wohl lieber ein double extended genommen 
Derselbe Import ist auch mit leeren Tags ganz gut dabei.
Nahmd,
Ja sorry, ich hab mit dem DE einhüllenden Rechteck geschnitten, das ergibt viel Beifang. Mehr war auf die Schnelle nicht drin. Deshalb hab ich die Koordinaten zugegeben, um ein sauberes Schneiden zu ermöglichen. Vorgefiltert habe ich nichts; die Daten sollen ja dazu dienen, der Diskussion eine Grundlage zu geben.
Gruß Wolf
Ach so - ich dachte, Du hättest germany.osm genommen, und hatte mich schon gewundert, daß der Beifang so groß ist. Kannst ja mal (eilt nicht) nur germany.osm durchzählen.
Meine Datenbank sagt 237 Schlüssel, davon 16 (new tags) und dann kommen die conditional-Werte (natürlich in alter Schreibweise). Und nein meine DB ist nicht Defekt, die Tagtabelle beinhaltet 62.146.667 Datensätze (Stand Germay-Extrakt vom 28.2.2013)
Bei den Werten sind es dann 5.598.419 davon 2.616 Werte mit ein führenden und/oder schließenden Leerzeichen. Als Schlüssel sind hier führend: name, addr:street, ref und addr:city.
Nochmal zur Diskussionsgrundlage: Unter http://toolserver.org/~mapjedi/leading_trailing_whitespace_de.txt habe ich die aktuellen Vorkommen von führendem/folgendem Leerraum abgelegt. Im Gegensatz zu Netzwolfs früherer Auswertung sind mehrfache Leerzeichen im Inneren sowie Tabs usw. nicht berücksichtigt - abgesehen von geringem Beifang durch mehrzeilige Tags, wo vor oder nach \n zu allem Überfluß auch noch ein Leerzeichen steht, etwa:
n956383142 value "inscription" "Den 28. October 1868
begrub hier der hiesige
Rittergutspächter R.
Rossberg sein 31 Jahre
altes Reitpferd nachdem
es ihm 21 Jahre viel gute
Dienste geleistet hatte"
Von Leerraum im Wert betroffene Schlüssel (ab 10 Stück)
1144 "name"
319 "addr:street"
116 "phone"
92 "building"
88 "note"
63 "wheelchair:description"
62 "eea:cdda:sitecode"
62 "area:ha"
57 "addr:housenumber"
48 "source"
48 "addr:housename"
42 "operator"
35 "description"
34 "landuse"
31 "addr:city"
29 "designation"
25 "surface"
24 "website"
24 "contact:phone"
23 "shop"
23 "opening_hours"
17 "amenity"
16 "ref"
14 "reservoir_type"
12 "roof:material"
12 "email"
11 "fax"
11 "contact:email"
10 "man_made"
10 "fixme"
Hier mal der aktuelle Stand meiner Überlegungen zum Thema, nachdem ich mir die obigen Wortmeldungen noch einmal durchgelesen habe.
Grundidee ist immer noch, Leerraum nur dann zu entfernen, wenn hierdurch eine nennenswerte Verbesserung erzielt wird. Die von mir ursprünglich angedachte Unterscheidung zwischen Festwert- und Freitext-Tags vermutlich nicht das beste Kriterium, denn auch in Freitext-Werten kann Leerraum störend sein (Sortierreihenfolge, Suchabfragen). Auch der Ansatz mit einer Positivliste von Schlüsselnamen, bei denen Leerraum im Wert geputzt wird, ist spätestens dann nicht mehr praktikabel, wenn man sich von der Trennung Festwert/Freitext löst.
Inzwischen denke ich daher eher in die Richtung, Leerraum grundsätzlich überall zu beseitigen und nur endlich viele Ausnahmen zu definieren. Diese Ausnahmen senken zugegebenermaßen die Zahl der Bearbeitungen nur unwesentlich und bei einer Größenordnung von insgesamt 2500 Bearbeitungen (plus zukünftig fortlaufend weitere; 2500 entspricht grob dem Aufkommen innerhalb eines Jahres) könnte man das Argument “Aufblähen des Datenbestandes” wohl noch übergehen, aber es widerstrebt mir einfach, bei Tags, die per se völlig unsinnig sind (Stichwort area:ha), Leerraum-Kosmetik zu betreiben, wenn eigentlich ein viel gründlicheres Aufräumen angebracht wäre.
Konkret hieße das, folgende Tags zu sperren:
-
note, fixme, FIXME - nur für interne Zwecke gedacht, schadet also niemandem
-
eea:cdda:sitecode, area:ha - liegen ohnehin in Tschechien und resultieren wie üblich aus einem Import; area:ha ist per se unsinnig, ebenso Tags wie dummy=JOSM und ein aufs OSM-Wiki zeigendes website-Tag, was sich alles in demselben Import findet.
-
source - wird das irgendwo genutzt?
-
designation - de facto ist das Tag in DE unbrauchbar, da schadet etwas Leerraum auch nicht
Die Sperre soll dabei im Filter erfolgen, d.h. das Filterprogramm spricht nur an auf Leerraum in Schlüsseln sowie Leerraum in Tags außer den gesperrten. Ein Objekt mit designation=“Wohnhaus˽” wird also nicht ausgefiltert, eines mit designation=“Wohnhaus˽” und building=“˽yes” dagegen schon (eines nur mit building=“˽yes” natürlich auch). Das Korrekturprogramm entfernt anschließend sämtlichen Leerraum, den es in den Tags der Kandidaten findet (wenn das genannte building=“˽yes” schon angefaßt wird, dann auch designation=“Wohnhaus˽”).
Tags mit leerem (“”) oder nur aus Leerraum bestehendem Wert sollen im gleichen Zuge komplett entfernt werden.
Bei Konflikten zwischen Tags, deren Schlüssel sich nur um Leerraum unterscheiden (“ref”=1, “ref˽”=2) keine Änderung; falls kein Konflikt vorliegt (“ref”=1, “ref˽”=1), Löschung desjenigen mit dem Leerraum (“ref˽”).
Das Korrekturprogramm werde ich noch so erweitern, daß es nur Tags bearbeitet, die auch in allen Vorgängerversionen genau so vorhanden waren. Damit will ich Fälle ausschließen, wo bei einem Bearbeitungsversuch z.B. versehentlich vorhandener Text überschrieben wurde (“Bahnhof Kleinkleckersdorf” → “Bahnhof˽”). Streichen oder abschwächen kann man diese Vorsichtsmaßnahme später immer noch, wenn sie sich als nicht notwendig erweist.
Soweit meine aktuellen Überlegungen. Was haltet ihr davon?
Der weitere Fahrplan bei Wall·E sieht wie folgt aus: Wenn bis dahin keine neuen Probleme mehr auftauchen, werde ich bei der Marke von insgesamt 6000 Bearbeitungen den Probebetrieb der Adresskorrekturen für beendet erklären (d.h. nicht mehr jedes Objekt einzeln im Brauser kontrollieren, sondern nur noch die Logfiles durchschauen, auch das nach und nach nur noch stichprobenartig) und auch den Korrekturprozeß als cronjob laufen lassen. Eigentlich ändert sich nur für mich selbst etwas (weniger Arbeit), außer daß Wall·E zukünftig immer zu festen Zeiten loslegt.
Die Leerraum-Korrektur wird in jedem Fall erst danach starten: voraussichtlich zuerst in einem Aufwasch nur die Schlüssel mit Leerraum, dann weiter in Paketen von z.B. 200 Objekten pro Änderungssatz (nach ein paar Tests mit weniger Objekten).
Ich würde “ohne Rücksicht auf Ansehen” bei allen Tags einen generellen Trim sowohl bei Key als auch Value machen weil am Anfang und am Ende dort keine Spaces (bedeutet das nicht Zwischenraum?) stehen sollten. Danach kannst du die Besonderheiten und Eigenheiten spezieller Tags berücksichtigen.
Das ganze natürlich iterativ: wenn bei Splitten von Tags neue zur trimmende Spaces auftauchen → weg damit.
Und wenn dabei leere Keys oder Values entstehen sollten → weg damit. Obwohl ich derzeit mir dieses nicht vorstellen kann - aber wer weiß?
Gruss
walter
@wambacher: +1
Hast du vor, das hier auf Deutschland beschränkt laufen zu lassen? Das ist bei den Straßennamen ja sinnvoll, aber Leerraumentfernung braucht es weltweit und es hilft auch nicht, wenn jede nationale Community jetzt da ihren eigenen Bot für entwickelt. Insofern hoffe ich doch, dass du das, wenn das deine Ressourcen zulassen, weltweit anwenden wirst.
Das kann ich natürlich machen. Ich gebe zu, daß mein Unbehagen kein zwingendes Argument ist - aber wie gesagt mißfällt es mir, mit etwas Schleifpapier-Kosmetik in die Objekthistorie einzugehen, wenn eigentlich der große Winkelschleifer mit Trennscheibe angesagt wäre.
Jetzt hast Du mich abgehängt. Was meinst Du mit Splitten?
Erst einmal ja, allerdings auf Geofabrik-Deutschland (das Nachschneiden ist unnötig, da die Korrektur als solche nicht landesspezifisch ist).
Für DE (oder andere nicht importverseuchte Länder) lasse ich mich evtl. noch von euch überzeugen, alle Tags zu bearbeiten; aber vor einer möglichen weltweiten Anwendung würde ich definitiv bestimmte Tags sperren. Wie ich anhand der von Netzwolf aufbereiteten Liste festgestellt habe, stammt weltweit der Großteil des überschüssigen Leerraums aus Importen und steht oft in (häufig völlig sinnbefreiten) Spezialtags, wo er niemanden stört. Da ginge es dann tatsächlich um Hunderttausende Bearbeitungen ohne jeden Nutzen.
Mach doch der xybot weltweit, wenn er mal wieder rennt. Oder täusche ich mich da? Ich hätte da auf jeden Fall keinerlei Bedenken.
Wenn du z.B. Straße und Hausnummer in zwei Tags aufteilst. Ist aber wohl deine andere Baustelle.
Wie kriegst du eigentlich den Zeitunterschied in den Griff?
Das Objekt, daß du gerade korrigieren willst, kann ja in den Live-Daten schon total anders aussehen? Da kannst du ja wohl nur was mit der Live-Api (http://api.openstreetmap.org/) machen. So machen es zumindest die mir bekannten Bots und auch von mir erstellte Programme (*)
Gruß
walter
*) Keine Angst, die laufen nur read-only; mich hat die Materie nur interessiert.
Die würden dann aber auch nur einmal bearbeitet werden. Nach dem Import ändern die Tags sich ja meist nicht mehr. Neue Imports haben dann auch wieder neue Spezialtags, die du dann immer wieder extra filtern müsstest. Ich bin auch für ein bearbeiten von allen Tags ohne Außnahmen.
Genau so isses. Die übergeordnete Funktion liest die Kandidatendatei ein und schleift dann durch die Liste, verwirft uninteressante Objekte (z.B. taglose Knoten, die nur als Element des eigentlich interessierenden Wegs in der Datei sind) und teilt der Handlangerfunktion nur Objekttyp und ID mit. Diese holt sich das Objekt vom Server, bearbeitet es und lädt es im Erfolgsfall wieder hoch, arbeitet also stets nur mit ganz frischen Versionen.
Im Grunde könnte man auf das Nachladen vom Server aber sogar verzichten. Wenn das Objekt zwischendurch verändert wurde, funktioniert mit der Version aus dem Extrakt das Hochladen nicht, weil der Server das Objekt nicht annimmt - es besteht also keine Gefahr. Entweder holt man sich dann die aktuelle Version und versucht die Korrektur erneut, oder man ignoriert das Problem bis zum nächsten Programmlauf. Falls dann der Fehler immer noch vorliegt, landet das Objekt dann ja auch wieder im Filter.
sauber!
Danke
walter
Tags mit leerem Key oder Value können noch nützliche Informationen beinhalten! Beispiel: " "=“asphalt” Ob das in den Daten auch so vorkommt, kann ich allerdings nicht beurteilen.
Tags mit leerem Key und Value können mMn gelöscht werden.
Das mit der Vorgängerversion find ich ne gute Idee. Bei solchen Fällen kann man dann schauen, obs hilfreich ist.
Der Rest gut so.
Kommt vor, wenn auch eher selten. Ist vielleicht besser, diese zuerst einmal auch außen vor zu lassen. Die Schwierigkeit wird (auch für menschliche Korrekteure) in der Frage bestehen, ob der Verursacher das Tag löschen wollte oder nicht.
Nachtrag dazu: Ein Beispiel für einen Wert mit nur Leerraum - http://www.openstreetmap.org/browse/way/205351516 . Aus source=" " kann man nun wirklich nichts ableiten. Etwa bei shop=" " wäre es anders, da wäre es naheliegend, daß der User ein Geschäft eintragen wollte - wenn dann noch ein name=* vorhanden ist, könnte ein menschlicher Korrekteur evtl. schon sinnvoll raten. Allerdings habe ich gerade mal die Daten durchgeschaut: bei den vorhandenen Tags der Form key=" " gibt es nichts zu raten, die Schlüssel sind source (13), name (9), addr:housenumber (6), maxstay, fee, addr:housename (je 1). Insofern bin ich im Moment doch geneigt, Tags mit nur Leerraum im Wert ersatzlos zu löschen. Der Einwand von MasiMaster ist zwar grundsätzlich richtig, aber in der Praxis ist aus den halbleeren Tags nichts herauszuholen.
Der Weisheit letzter Schluß ist das Kriterium allerdings noch nicht; in seiner Rohform führt es nämlich bei ersten Tests (lokal, ohne Hochladen) dazu, daß kaum ein Objekt in Version >1 angefaßt wird.
Aus “Tag in allen Vorgängerversionen vorhanden und identisch” ist soeben “Tag in allen Vorgängerversionen, falls vorhanden, identisch zur aktuellen Version” geworden. Damit klappt es schon besser.
Nachtrag: Hier ist mal so ein Beispiel, wo Leerraum bei der Bearbeitung entstanden ist: “Untere Bärenlocherstraße” wurde zu " Bärenlocherstraße" geändert. In diesem Fall war die Entfernung von “Untere” vermutlich Absicht, denn parallel zur " Bärenlocherstraße" gibt es noch eine “Untere Bärenlocherstraße” - d.h. es ist ein “echter” Leerraum-Fehler. http://www.openstreetmap.org/browse/way/143180717/history
Wie gesagt, solche Fälle will ich über die Kontrolle der Historie erst einmal außen vor lassen. Wenn die anderen Fälle abgetragen sind, sieht man bei diesen vielleicht auch klarer.
So, ich habe mal ein bißchen was gebastelt. Der Code sollte bereits alle wesentlichen Punkte enthalten: Leerraum in Schlüssel oder Wert, Kontrolle der Versionshistorie, Abgleich mit bestehenden Tags bei Änderung eines Schlüssels. Logging etc. und Pflege von Sperrlisten sind bisher nur rudimentär umgesetzt, aber das kommt noch. Danach werde ich den Code noch einmal kontrollieren und aufräumen, anschließend im kleinen Maßstab an realen Daten testen.
Hier ist aber schon mal ein Überblick mit Beispielen, welche Fälle bisher berücksichtigt werden. Bitte schaut mal, ob euch Situationen einfallen, die noch durchrutschen könnten. Material sollte ausreichend vorhanden sein, um alle denbaren Konstellationen abzudecken (über 2000 Objekte in germany.osm). Vielleicht findet sich auch noch ein grundsätzlicher Fehler in meinen Überlegungen.
Die Korrekturfunktion schleift durch alle Tags (Schlüssel-Wert-Paare).
Zuerst wird für jedes Tag nach Leerraum am Anfang/Ende des Werts geschaut. Wird welcher gefunden, wird überprüft, ob unter dem zugehörigen Schlüssel in allen Versionen entweder der gleiche oder kein Wert (also auch nicht “”) eingetragen war. Das Tag muß also entweder in allen Versionen vorhanden gewesen sein oder irgendwann dazugekommen und dann in allen weiteren Versionen unverändert geblieben sein; zwischenzeitliche Löschung und exakte Wiederherstellung geht auch durch. Andernfalls ist - für das betrachtete Tag - an dieser Stelle Schluß.
Nun wird der überschüssige Leerraum aus dem Wert entfernt. Ist danach der Wert “”, wird das Tag komplett gelöscht. (Das Log stellt Leerraumentfernung und ggf. Löschung als einen Schritt dar.)
Weiter geht’s mit dem Schlüssel. Zunächst wieder Suche nach Leerraum und Kontrolle aller Vorgängerversionen.
Der Schlüssel (als String) wird von Leerraum befreit. Wenn dann nur noch “” übrig ist, wird das Tag gelöscht. Andernfalls wird geprüft, ob ein Tag mit dem gleichen Schlüssel schon vorhanden ist (Beispiel: aktuell betrachteter Schlüssel war “highway˽”, der geänderte String ist “highway” - gibt es schon ein Tag highway=*?). Falls es keines gibt, wird der geänderte String als Schlüssel in das Tag übernommen und die Korrektur ist abgeschlossen.
Gibt es bereits ein Tag, werden die beiden Werte verglichen. Sind sie identisch, wird das betrachtete Tag kurzerhand gelöscht, weil redundant. Beispiel: (ursprünglich) “˽highway”=“residential” sowie “highway”=“residential”, das erstgenannte entfällt. Sind sie verschieden, wird der Korrekturversuch abgebrochen, weil der Konflikt nicht gelöst werden kann.
Jetzt endlich ein paar Beispiele.
Leerraum im Wert: http://www.openstreetmap.org/api/0.6/node/13927006
editing node #13927006, http://www.openstreetmap.org/browse/node/13927006
modified tag [key="wheelchair:description"] value="Präsenzzeit des mobilen Service von 06:00 Uhr bis 22:40 Uhr " -> "Präsenzzeit des mobilen Service von 06:00 Uhr bis 22:40 Uhr"
(simulation run - no upload to the database)
Gibt’s auch am Anfang des Werts: http://www.openstreetmap.org/api/0.6/node/26597860
editing node #26597860, http://www.openstreetmap.org/browse/node/26597860
modified tag [key="name:fr"] value=" Frisingue" -> "Frisingue"
(simulation run - no upload to the database)
In beiden Fällen ist das fragliche Tag erst in der letzten Version dazugekommen, existiert also jeweils nur mit diesem einen Wert.
Ein Fall, wo der Wert nur aus Leerraum besteht und das Tag weggeworfen wird: http://www.openstreetmap.org/api/0.6/node/209876355
editing way #209876355, http://www.openstreetmap.org/browse/way/209876355
value of "addr:housenumber"=" " consists only of whitespace: tag removed.
(simulation run - no upload to the database)
Bei diesem Objekt verbietet die Objekthistorie die Leerraumbeseitigung: http://www.openstreetmap.org/api/0.6/way/209872722 : in Version 1 lautet das name-Tag “Adler Modemarkt˽˽” (zwei Leerzeichen), in Version 2 “Adler Modemarkt˽” (ein Leerzeichen). Da das Programm in diesem Fall nichts tut, schreibt es auch nichts ins Log. Eine Ausgabe auf der Konsole wird es geben, aber bisher gibt sich das Programm noch recht einsilbig.
(osm-task-fix-lt-whitespace 'way 209872722 nil nil t)
nil
Leerraum im Schlüssel: http://www.openstreetmap.org/api/0.6/node/2234071140
editing node #2234071140, http://www.openstreetmap.org/browse/node/2234071140
modified tag key=" website" -> "website" [value="http://www.kioskguide-hannover.de/index.php?seite=kioskdetails&id=113"]
(simulation run - no upload to the database)
Im folgenden Fall besteht ein Konflikt zwischen den Werten zu den beiden Schlüsseln “amenity” und “˽amenity”. Keine Änderung, kein Eintrag ins Log, bloß eine Nachricht, die auf der Konsole landen soll: http://www.openstreetmap.org/api/0.6/node/2010219552
can't fix whitespace in tag of node #2010219552: " amenity"="drinking_water": tag "amenity"="waste_disposal" exists
Hallo Oli-Wan
Ich kann dich nur bewundern,
- wie du konstant beim Thema dran bleibst
- wie du das Thema in kleinere überschaubare Einheiten zerlegst
- wie gründlich du Möglichkeiten und Fallstricke vorab erforscht
- wie du stets die sichere Seite bevorzugst
- wie detailiert du dein geplantes Vorgehen beschreibst (und damit)
- wie du andere in dein Projekt einbindest.
Dafür wollte ich mal mein Lob aussprechen und Danke sagen.
(Mir scheint alles, was du im Vorpost zu Leerraum in Wert und Schlüssel erklärt hast, sinnvoll und angemessen.)
Edbert (EvanE)
Ja, in den genannten Fällen ist nichts herauszuholen. Allerhöchstens könnte es für fee=yes stehen, aber das ist Spekulation.
Ich hatte das erwähnt, weil dein Programm später sicher mal ohne (große) Aufsicht rennen soll, dann weiß man nie welche Tags “anfallen”.
Gut, bei fehlendem Value ist das sicher nicht so tragisch, bei fehlendem Key könnte man bestimmt mehr ableiten. Kommt aber sicher selten vor!?
einige Beispiel die mir grade fürs Ersetzen einfallen:
highway=“” → highway=road
building=“” → building=yes
bridge / tunnel → *=yes
shop → *=yes
Du hast Recht, auf Dauer werde ich das Programm nicht engmaschig überwachen. Andererseits hat xybot zuletzt vor gut einem Jahr Leerraum und leere Tags aufgeräumt. Ansonsten scheint da seitdem niemand großflächig was gemacht zu haben, daher sollte das aktuelle Aufkommen schon halbwegs repräsentativ sein.
Die Information über gelöschte Tags steht ja in jedem Fall im Log; ergänzend dazu ist es auch kein großer Akt, in eine zusätzliche Datei z.B. jeweils den Schlüssel zu schreiben, der zusammen mit dem leeren Wert gelöscht wurde, um den Überblick zu behalten.
Was die leeren Schlüssel angeht: diese sind in der Tat extrem selten. Das kann man andererseits gerade auch als Argument sehen, sie menschlichen Korrekteuren zu überlassen.
Das Programm, dessen Arbeit oben skizziert ist, ist erst einmal nur eine Testversion. Da ist noch nichts in Stein gemeißelt, und ich bin offen für jede Änderung (und daher dankbar für Deine Anmerkungen). Bei den leeren Schlüsseln etwa bin ich selbst unschlüssig, aber vielleicht lasse ich die lieber stehen. Bei leeren Werten denke ich eher, daß ein zusätzliches Log ausreichen sollte, um den Überblick (und die Kontrolle) zu behalten. Alternativ könnte man auch mit einer Whitelist arbeiten: “diese Schlüssel dürfen bei leerem Wert entsorgt werden, Raten ist aussichtslos”.