OpenStreetMap Forum

The Free Wiki World Map

You are not logged in.

#26 2013-03-14 13:35:13

Oli-Wan
Member
From: NRW
Registered: 2010-09-14
Posts: 2,814

Re: Wall·E räumt auf: Leerraum in Tags und Rollen

reneman wrote:

Hm, u.a. für genau solche Sorgen hat man das Votingschema bei Proposals eingeführt. Da kann nach fertiger Ausarbeitung/Diskussion die Community ja oder nein sagen wink
Und nach erfolgreicher Abstimmung ist die Proposalseite schon die fast fertige Dokumentation...

Danke, an die Möglichkeit hatte ich gar nicht gedacht. Eine solche Trennung von Diskussion/Entwicklung und Abstimmung werde ich für zukünftige Korrekturprozesse mal im Hinterkopf behalten. Das bisherige Vorgehen hat andererseits den Vorteil, daß jemand, der "dagegen" ist, in der Diskussion entsprechende Argumente anführen kann (bzw. muß, wenn er ernstgenommen werden will), statt nur "hinterher" {{Vote|no}} zu sagen.

Zartbitter wrote:

... Mitten im key/value wäre ich konserativ und würde mit einer Art whitelist arbeiten, z.B. key="social facility" -> key="social_facility" ...

Ich habe offenbar im Eingangsposting nicht hinreichend deutlich geschrieben, daß es mir nur um Extra-Leerraum am Anfang und/oder am Ende von Tags geht. Wie oben schon einmal geschrieben, kann man diesen im Prinzip behandeln, ohne sich den Rest des Tags näher anzusehen. Das von Dir angeführte Beispiel würde ich in eine eigene Korrekturklasse "häufige Tippfehler in Tags" packen und dort, genau wie Du vorschlägst, nur einen endlichen Katalog bekannter falscher Schreibweisen berücksichtigen.

Weide wrote:
Oli-Wan wrote:

Freitext-Werte würde ich dagegen (mit wenigen Ausnahmen) eher nicht beschneiden, weil ich davon ausgehe, daß er niemandem allzu sehr weh tut

Hmm. So ein Key ist falsch, aber er könnte wertvolle Informationen enthalten...

Man könnte solche kaputten Tags ergänzen: "*" durch "BADKEY:*" ersetzen (aber nur einmal).

Das scheint mir keine glückliche Lösung zu sein. Wenn ich den Leerraum direkt lösche, erzeuge ich eine neue Version. Ersetze ich das Tag wie von Dir vorgeschlagen und ein Mapper korrigiert es später ordentlich, entstehen zwei neue Versionen. Also wenn überhaupt, doch lieber gleich löschen. Die Suche nach Tags mit Leerraum ist im übrigen auch nicht schwieriger als die Suche nach einer gesonderten Schlüsselklasse wie "BADKEY:*".

Weide wrote:

PS: Denn Fall der Key-Verdopplung durch Entfernen von Zeichen ("name" und "name " vorhanden) muss man auch noch passend lösen. ...

Hier wäre mein Ansatz, zu prüfen, ob die Werte zu "name" und "name " identisch sind: "name"="Buxtehude" und "name "="Buxtehude" - in diesem Fall kann "name " ersatzlos entfallen; andernfalls nicht anfassen, sondern die Korrektur Menschen überlassen.

traces wrote:

Ich finde es grundsätzlich schon gut, vor Massenedits kurz um Feedback zu bitten, allerdings wäre hier sicher ein technisches Unterforum sinnvoll, in dem dann nicht lange grundsätzlich diskutiert wird. Am besten sogar in englisch und international bezogen.

Ich führe die Diskussion schon lieber hier, wo ich einen breiten Querschnitt der deutschen Mapper erreiche: erfahrene und weniger erfahrene; solche mit mehr oder weniger technischem Hintergrund; Mapper, die z.T. überraschendes, aber durchaus hilfreiches Spezialwissen aus ganz anderen Bereichen einbringen; Mapper aus allen Teilen des Landes (wichtig für regionale Besonderheiten); vor-der-eigenen-Haustür-Mapper und Weltreisende; reine Mapper, Kartenersteller, Auswerter, ...; Anhänger und Gegner von automatischen Bearbeitungen wink usw. In einem kleinen Spezialforum sammeln sich oft "Experten", die alle einen ähnlichen Hintergrund haben und folglich alle auf dem gleichen Auge blind sind (vgl. die "tagging"-Mailingliste).

traces wrote:

Hier konkret z.B. könnte man darauf hinweisen, dass evtl. Freitextfelder in Markdown-Syntax geschrieben sind, was dann heißt, dass Leerzeichen an Zeilenende sehr wohl eine Bedeutung haben, wenn auch ein einzelnes Leerzeichen jeweils ausreicht.

Danke für den Hinweis, darauf wäre ich z.B. nicht gekommen. Aber ein Beispiel würde mich auch interessieren.

wambacher wrote:

p.s. zum Punkt "Löschen leerer Tags" hat sich leider noch niemand geäußert.

Hatte ich ursprünglich als eine separate Aufgabe angesehen, aber eigentlich hast Du Recht: die lassen sich mit der Leerraum-Beseitigung zusammenfassen und können aus meiner Sicht ersatzlos weg. Allerdings nur leere Werte, nicht leere Schlüssel (es sei denn, der Wert ist ebenfalls "" oder enthält nur Leerraum).

Ich würde aber (auch bei der Beseitigung von Leerraum) noch eine Sicherung vorsehen wollen und vor einer automatischen Korrektur überprüfen, ob das beanstandete Tag in allen Versionen des Objekts vorhanden war, also key="" in Version 1 bis N. Gab es in Version N-K noch key="non-nil", könnte key="" in Version N auf eine unbeabsichtigte Löschung zurückgehen. Genauso war es bei dem eingangs erwähnten Weg, wo "addr:city"="Neuss" zu " "="Neuss" wurde. Daher eine automatische Korrektur nur bei Übereinstimmung des problematischen Tags in allen Versionen vornehmen und sonst Menschen die Arbeit überlassen (oder den Algorithmus später erweitern, wenn sich ein Fehlermuster z.B. durch einen bestimmten Editor erkennen läßt).

Jimmy_K wrote:

Man könnte sicher noch ein paar Tags dazunehmen, die zwar im Grunde Freitext beinhalten, deren Format aber doch bestimmten Anforderungen bzw. Standards unterliegt: ich denke da z.B. an die addr:*-Familie,...

Welche Leerzeichen denkst du könnte man da entfernen? Bei Hausnummern (aktuelle Diskussion auf ML), Straßennamen, Ortschaftsnamen sind sie ja meist Absicht und automatisiert kaum zu korrigieren.

Wie gesagt: es geht nur um Leerraum an Anfang und Ende. Von einer Vereinheitlichung von "10a" und "10 a" lasse ich die Finger.
Mir war nur der hohe Anteil von addr:street aufgefallen. Ich weiß noch nicht, ob vielleicht ein Muster (kaputter Editor) dahinter steckt oder es bloß die Gewohnheit ist, Straße und Hausnummer nacheinander einzutippen: Fehler bemerkt, Hausnummer gelöscht und in addr:housenumber geschrieben, Leerzeichen vergessen. Dafür spricht, daß nur in einem von 298 Werten das überzählige Leerzeichen am Anfang steht. Die häufigsten Werte sind (leider hexified):

     15 "Augustastraße "
     13 "Schulstraße "
     10 "Lilienthalstraße "
     10 "Jägerstraße "
      9 "Selmshof "
      9 "Heinrich-Heine-Straße "
      9 "Am Kessner Berg "
      5 "Niemtscher Weg "
      5 "Lübecker Straße "
      4 "Hauptstraße "
      4 "Breiter Weg "
      4 "Branderheide "
      4 "Alsterdorfer Straße "

Aus addr:postcode wird überzähliger Leerraum ja bereits im Zuge der Adresskorrekturen entfernt, um die Form "^[[:digit:]]{5}$" einzuhalten.

hkucharek wrote:

Wer bei OSM Whitespace-Programme hinterlegt, dem ist eh nicht zu helfen... big_smile

Endlich eine Erklärung für die 91 führenden Leerzeichen in "                                                                                           Dr. Konrad Adenauer Str."! Von "esoterischen Programmiersprachen" hatte ich auch noch nie gehört - wieder was gelernt.


No animals were harmed in the writing of this posting.

Offline

#27 2013-03-14 13:45:03

TEL0000
Moderator
From: Berlin
Registered: 2008-06-11
Posts: 968

Re: Wall·E räumt auf: Leerraum in Tags und Rollen

Oli-Wan wrote:

Mir war nur der hohe Anteil von addr:street aufgefallen. Ich weiß noch nicht, ob vielleicht ein Muster (kaputter Editor) dahinter steckt oder es bloß die Gewohnheit ist, Straße und Hausnummer nacheinander einzutippen

Ich denke das liegt daran, dass niemand Lust hat für jede Hausnummer die Straße extra einzutippen, und daher der Wert einfach kopiert wird. Dabei kann es schonmal passieren, dass man versehendlich ein Leerzeichen mitkopiert.

Offline

#28 2013-03-14 15:01:59

traces
Member
Registered: 2012-12-08
Posts: 38

Re: Wall·E räumt auf: Leerraum in Tags und Rollen

TEL0000 wrote:
traces wrote:

Hier konkret z.B. könnte man darauf hinweisen, dass evtl. Freitextfelder in Markdown-Syntax geschrieben sind, was dann heißt, dass Leerzeichen an Zeilenende sehr wohl eine Bedeutung haben, wenn auch ein einzelnes Leerzeichen jeweils ausreicht.

Hast du ein Beispiel? Ich hab das grad mal überflogen. Das einzige was ich finden kann, ist dass ein Leerzeichen am Zeilenende ein Zeilenumbruch erzeugt. Ein Zeilenumbruch am Ende der Value wär aber ebenfalls ein Whitespace der getrimmt gehört.

Das war ja nur als Beispiel gemeint, warum ich es für sinnvoll halte, in einem technischen Kontext bei Massenedits um Feedback zu bitten.

Bei Markdown kann man einen Zeilenumbruch (line feed) im Unterschied zu einem Absatzumbruch eben durch das Anhängen von einem oder mehreren Leerzeichen am Zeilenende generieren. Es wäre ja nun möglich, dass es z.B. im "description"-Feld längere Texte stehen, die mit Markdown formatiert sind, und dort könnte eben durch eine "multiple to single whitespace"-Aufräumaktion die Formatierung verlorengehen. Klar, am Textende ist das irrelevant, weil dort so und so kein Umbruch stehen sollte.

Ich habe mich mit OSM noch nicht auf der API/Datenbankebene beschäftigt, kann deshalb nicht mal schnell herausfinden, ob irgendwo überhaupt Mardown verwendet wird. Sollte eh nicht, wenn es nicht eine definierte Formatangabe dazu gibt, als "description:markup_type" etwa.

Offline

#29 2013-03-14 17:41:46

errt
Member
Registered: 2009-12-01
Posts: 1,068

Re: Wall·E räumt auf: Leerraum in Tags und Rollen

Ich bin auf jeden Fall für I. und II.a. Ich würde ebenfalls das trimmen von Leerzeichen in Freitextvalues unterstützen (da haben sie genausowenig zu suchen, der Code dürfte einfacher werden und verschiedene Probleme, wie Sortierung wurden ja schon angesprochen). Ich würde sogar soweit gehen, und mehrfache Leerzeichen in der Mitte (nicht nur) von Freitextvalues zu einem zusammenfassen: Manche nutzen das nämlich leider, um Namen in Mapnik an ihnen genehmeren Stellen rendern zu lassen. Würde das durch einen Bot gefixt, würden die entsprechenden Mapper schnell darauf hingewiesen, dass das keine gute Praxis ist und es sich in Zukunft wohl anders überlegen. Eventuell könnte man ja, wie bei den anderen Korrekturen durch Wall·E für solche Korrekturen eine Liste führen, damit ein Objekt nicht zweimal angefasst wird, für die seltenen Fälle, wo das vielleicht doch mal sinnvoll sein sollte.

Btw., wenn ich's gerade schon von der Liste habe: Speichert die eigentlich nur das Objekt oder auch, welcher Fehler korrigiert wurde - sprich, wenn jemand das ganze nicht auf den Stand von vorher zurücksetzt, sondern einen neuen, potentiellen Fehler einbaut, greift Wall·E dann nochmal ein, oder nicht?

Offline

#30 2013-03-14 18:13:45

Oli-Wan
Member
From: NRW
Registered: 2010-09-14
Posts: 2,814

Re: Wall·E räumt auf: Leerraum in Tags und Rollen

errt wrote:

Btw., wenn ich's gerade schon von der Liste habe: Speichert die eigentlich nur das Objekt oder auch, welcher Fehler korrigiert wurde - sprich, wenn jemand das ganze nicht auf den Stand von vorher zurücksetzt, sondern einen neuen, potentiellen Fehler einbaut, greift Wall·E dann nochmal ein, oder nicht?

Es gibt eine Sperrliste pro Korrekturgruppe, also bisher eine für Straßennamen (highways) und eine für Adressen. Heißt: wenn Wall·E addr:street korrigiert und jemand später z.B. eine zwölfstellige Postleitzahl einträgt, landet das Objekt im Filter, wird aber vom Programm für Adresskorrekturen ignoriert. Der Whitespace-Killer würde aber ggf. zuschlagen, weil er nur auf seine eigene Sperrliste schaut.

Ersteres ist zugegebenermaßen unschön, aber die Details der Korrektur zu speichern wäre mir zu aufwendig. Im Normalfall wird ein Objekt nur einmal angefaßt und die Information zu den Details der Korrektur wird nie wieder benötigt (falls doch, ist sie immer noch in der OSM-DB vorhanden), zumal die Wahrscheinlichkeit relativ gering ist, daß erneut ein Fehler aus derselben Gruppe eingebaut wird. Die Straßennamenkorrektur schreibt aber bei einem Wiedersehen mit einem früher bearbeiteten Objekt bereits jetzt einen Vermerk ins Log, sodaß Mensch nachsehen kann, was da los ist: [1]

note: way #159489799 is listed in exclusion list - skipping

Für die Adresskorrekturen ist diese Ausgabe derzeit noch deaktiviert, weil der Prozess wegen des eingebauten Limits häufig mehrmals am Tag läuft und dann beim Durchsuchen der Kandidatenliste erneut auf die Objekte trifft, die er im vorigen Durchgang bereits korrigiert hat. (So erklären sich auch vereinzelte Vermerke bei der Straßennamen-Korrektur.)

Am Rande: Der Umzug auf den Toolserver ist vollzogen. Ein cronjob ist nun - hoffentlich - so eingerichtet, daß jeweils am 07., 17. und 27. eines jeden Monats die Korrektur der Straßennamen durchläuft. Die bislang fehlerfrei arbeitenden Adresskorrekturen werde ich ebenfalls bald automatisiert starten (im Moment geschieht nur die Kandidatensuche automatisch, die Korrektur starte ich noch manuell); voraussichtlich täglich oder 2-täglich.

[1] Wenn jemand nachsehen will, bitte nicht nur auf die aktuelle Version, sondern auch in die History schauen. Inzwischen wird die Meldung nicht mehr ausgegeben.

PS. Die spartanische Sperrliste sieht so aus:

((node 308058715 559422772 622142742 669135677 ...)
 (way 23478981 25475868 28416789 46258880 46271268 ...)
 (relation 1617599 2181504))

Nur Objektnummern, keine Details.

Last edited by Oli-Wan (2013-03-14 18:27:16)


No animals were harmed in the writing of this posting.

Offline

#31 2013-03-14 22:49:52

MasiMaster
Member
Registered: 2011-11-22
Posts: 369

Re: Wall·E räumt auf: Leerraum in Tags und Rollen

Schildbuerger wrote:

Betrachte die "fehlende Resonanz" Positiv.
Ich lese immer mit und finde die Korrekturen gut.
Tippfehler passieren immer wieder mal, da kann man noch so sorgfältig arbeiten.
Bitte weiter so!

+1, ich finds auch komisch wenn keine Resonanz kommt, aber mittlerweile denk ich, entweder interessiert es niemanden, oder keiner hat eine gegenteilige Meinung smile

Aber ich schreib auch gerne meinen Senf noch dazu:
generell +1, auch für die sehr gute Informationspolitik!

Jedoch würde ich die Korrektur nicht nur I. & II.a, sondern auch II.b einsetzten, denn:
Wie willst du die "(Mehr oder weniger) echte Festwert-Tags" herraussuchen? Oder willst du jedes mal alle neuen Werte prüfen und ggf. im Wiki nachschlagen, ob es nun ein Festwert ist oder nicht?
Mir fällt kein Grund ein, ein führendes bzw. abschließendes Leerzeichen, Tab o.ä. in einem Tag zu verbauen.
Jedoch würde ich vorher erstmal einen Blick auf die Liste mit den nicht-Festwert-Tags zu werfen, bevor man dort die Zeichen löscht, vielleicht fällt dort direkt was auf.


P.S.: Leere Tags würde ich nicht löschen, sondern per Hand (ggf. fixme setzten) bearbeiten, da sie wohl nicht so viele sind(?). Denk es ist vieeel aufwändiger, die verschiedenen Korrekturmöglichkeiten dem Programm beizubringenden, als den Tag eben per Hand zu untersuchen. (Dies gilt nur, wenn es nicht viele solcher Einträge sind.)

Offline

#32 2013-03-14 23:34:41

Oli-Wan
Member
From: NRW
Registered: 2010-09-14
Posts: 2,814

Re: Wall·E räumt auf: Leerraum in Tags und Rollen

MasiMaster wrote:

Jedoch würde ich die Korrektur nicht nur I. & II.a, sondern auch II.b einsetzten, denn:
Wie willst du die "(Mehr oder weniger) echte Festwert-Tags" herraussuchen? Oder willst du jedes mal alle neuen Werte prüfen und ggf. im Wiki nachschlagen, ob es nun ein Festwert ist oder nicht?

Nein, nicht jedes Mal - initial eine Liste erstellen und diese in größeren Abständen (Monate) ergänzen. Für mich wäre es in der Tat weniger Arbeit, die Leerraumkorrektur ohne Rücksicht auf die Art des Tags durchzuführen (der Code dafür ist im Prinzip fertig). Meine Zurückhaltung bei II.b liegt darin begründet, daß ich eine Korrektur (Eingriff in den Datenbestand, neue Version usw.) nur dann vornehmen will, wenn der Fehler tatsächlich ein Problem darstellt - und nach meiner Wahrnehmung sollten Anwendungen mit überschüssigem Leerraum in Freitext-Tags (daß er dort in aller Regel nicht hingehört, stelle ich nicht in Abrede) keine großen Schwierigkeiten haben. Ich lasse mich aber nur allzu gern vom Gegenteil überzeugen. Das Stichwort Sortierreihenfolge war schon mal ein interessantes Argument.


No animals were harmed in the writing of this posting.

Offline

#33 2013-03-15 00:50:07

EvanE
Member
Registered: 2009-11-30
Posts: 5,716

Re: Wall·E räumt auf: Leerraum in Tags und Rollen

Oli-Wan wrote:
MasiMaster wrote:

Jedoch würde ich die Korrektur nicht nur I. & II.a, sondern auch II.b einsetzten, denn:
Wie willst du die "(Mehr oder weniger) echte Festwert-Tags" herraussuchen? Oder willst du jedes mal alle neuen Werte prüfen und ggf. im Wiki nachschlagen, ob es nun ein Festwert ist oder nicht?

Nein, nicht jedes Mal - initial eine Liste erstellen und diese in größeren Abständen (Monate) ergänzen. ... Meine Zurückhaltung bei II.b liegt darin begründet, daß ich eine Korrektur (...) nur dann vornehmen will, wenn der Fehler tatsächlich ein Problem darstellt - und nach meiner Wahrnehmung sollten Anwendungen mit überschüssigem Leerraum in Freitext-Tags (...) keine großen Schwierigkeiten haben. Ich lasse mich aber nur allzu gern vom Gegenteil überzeugen. ...

Auch ich denke, dass I und II.a (Schlüssel und Festwerte) problemlos sind.
Deine Bedenken zu II.b (Freitextwerte) teile ich, der Nutzen ist ggfs. nur begrenzt. Anders sähe es aus, wenn Wall÷E mehrere WhiteSpace auch innerhalb des Wertes zu einem Blank zusammenfassen würde.

Eine Anregung (für jetzt oder für die Zukunft) wäre auf Blank oder Strich statt Unterstrich in Schlüssel oder Festwert zu prüfen. Das dürften neben falscher Großschreibung (z.B. Yes) die häufigsten Ursachen für 'seltsame' Taggs sein.

Edbert (EvanE)

Offline

#34 2013-03-15 01:36:57

slhh
Member
Registered: 2012-09-02
Posts: 358

Re: Wall·E räumt auf: Leerraum in Tags und Rollen

Weißzeichen am Anfang und Ende sollte man auch bei Freitext-Werten entfernen, da diese vermutlich Suchabfragen z.B. mit der Overpass-API beeinträchtigen würden.
Wenn man möchte, könnte man eine Liste von Schlüsseln (wie z.B. note) aufstellen, für die die Korrektur entbehrlich erscheint, aber ich halte den Aufwand für übertrieben.

Einfache und mehrfache Weißzeichen jeglicher Art in Schlüssel und Wert sollten zu einem einzelnen Leerzeichen konvertiert werden.
Beim Wert müßte man aber anhand der müßte man anhand der vorhandenen Fälle im Datenbestandes prüfen, ob es nicht vielleicht doch unglücklich definierte Schlüssel gibt, bei denen jedes Zeichen im Wert eine kodierte Bedeutung hat.
Beispielweise könne es bei abweichender Definition zum Beispiel ein turn:lanes="L  R" statt turn:lanes=left|||right geben.

Bezüglich Entfernen von Tags ohne Wert sollte man eine Whitelist von Schlüsseln aufstellen, für die dies ohne Informationsverlust möglich ist. Beispiele wären "name=", "lit=" und "maxspeed=".

Ein Gegenbeispiel wäre "maxweight=", da dieses ein Hinweis darauf sein könnte, dass eine der vergleichsweise seltenen Beschränkungen an diese Stelle vorliegt und noch erkundet werden muss.

Offline

#35 2013-03-15 08:03:27

Netzwolf
Member
Registered: 2008-04-01
Posts: 1,665

Re: Wall·E räumt auf: Leerraum in Tags und Rollen

Moins,

damit sich jeder ohne Aufwand ein eigenes Bild machen kann, hab ich die Objekte mit unnormalisierten Blanks in Tags bereitgestellt, rund 1.2 Millionen Einträge (~90Mb) als Bzip2 (gut 6Mb) und als Gzip (knapp 8Mb).

Die meisten Mehrfachblanks sind wohl zufällig entstanden; sie werden aber auch benutzt zum Formatieren (from/to bei Bus-Relation) oder als Ersatz für ";" bei einem automatischen Import. Die sinnvollen(?) wird man kaum von den sinnfreien automatisiert unterscheiden können. Ein Normalisieren “\s+”→“\040” wird also Mitarbeiter verärgern.

Irgendwas ist ja immer. hmm

Gruß Wolf

Offline

#36 2013-03-15 08:17:12

errt
Member
Registered: 2009-12-01
Posts: 1,068

Re: Wall·E räumt auf: Leerraum in Tags und Rollen

Oli-Wan wrote:

Meine Zurückhaltung bei II.b liegt darin begründet, daß ich eine Korrektur (Eingriff in den Datenbestand, neue Version usw.) nur dann vornehmen will, wenn der Fehler tatsächlich ein Problem darstellt

Finde ich löblich, dass du dich nur um problematische Dinge kümmern willst und es sollte natürlich immer darauf geachtet werden, dass es möglichst nicht zu Fehlkorrekturen kommt. Wenn allerdings, wie in diesem Fall, keine Fehlkorrekturen zu erwarten sind, sondern die zusätzlichen Korrekturen bestenfalls überflüssig, aber trotzdem an sich richtig sind, würde ich mir hier an deiner Stelle nicht den zusätzlichen Aufwand machen. Ein zusätzliches Argument hätte ich noch: Wenn du eine Liste von Festwert-Tags führst, wird diese nur die häufigsten solchen Tags beinhalten. Die sind natürlich am problematischsten, aber sie dürften auch am ehesten auffallen. Seltene Tags mit versehentlichem Whitespace findet dagegen möglicherweise nie jemand manuell, also wäre gerade hier ein Bot hilfreich. Alternativ könnte man natürlich eine Liste von Freitext-Tags führen, aber das scheint mir auch nicht wesentlich sinnvoller.

Btw.: Hast du eigentlich vor, das hier auch bei Gelegenheit zu übernehmen? Ich denke, praktisch alle dieser Korrekturen sind gerechtfertigt und waren ja bei Xybot schon soweit anerkannt und betreffen sehr häufige Fehler. Wenn es wirklich einzelne fragwürdige Verbesserungen gibt, dann muss man die ja nicht übernehmen, aber der größte Teil wäre es denke ich wert.

Offline

#37 2013-03-15 15:29:19

mdk
Member
Registered: 2010-08-18
Posts: 304

Re: Wall·E räumt auf: Leerraum in Tags und Rollen

Hi,

Eventuell habe ich den Aspekt in diesem Faden übersehen, aber was ist mit solchen Tags:

motor_vehicle:(Mo-Fr 07:00-16:00) = agricultural;delivery
access:(Mo-Fr 06:00-17:30) = private
bicycle:(Mo-Fr 20:00-09:00, Sa 16:00-24:00, Su,PH 00:00-24:00, 24:00-09:00) = yes

In OSMI findet man sie sehr einfach. Gibt es für diese Art von Tags Regeln, vor allem beüglich der Leerzeichen?

Grüsse

mdk

Offline

#38 2013-03-15 15:32:04

Oli-Wan
Member
From: NRW
Registered: 2010-09-14
Posts: 2,814

Re: Wall·E räumt auf: Leerraum in Tags und Rollen

Netzwolf wrote:

damit sich jeder ohne Aufwand ein eigenes Bild machen kann...

Danke, die Liste ist in der Tat aufschlußreich. Ich habe es zwar erst einmal nur auf Deutschland abgesehen, aber man kann ja auch mal etwas über den Horizont gucken.

Leerraum mittendrin kommt z.B. aus Importen wie diesem: da ist aber nicht nur der Leerraum falsch, sondern auch die GROSSBUCHSTABEN.
Manchmal ist er vermutlich sogar beabsichtigt - zwei Leerzeichen nach einem Punkt als Satztrenner, etwa hier in einer note. Hier kommt mir addr:street auch ohne die Leerzeichen mittendrin spanisch vor. Auch dieser Import läßt eine Vorverarbeitung (hier von name:ko_rm) vermissen, der hier analog (name sowie naptan:CommonName). Und auch die Kann-Weg-Importeure mögen Leerzeichen (zufällig ausgewähltes Beispiel), ebenso die Freunde von Cadastre (source-Tag "... mise à  jour : 2010"). Beim Tiger-Import sind Leerzeichen wie hier in name ohnehin das kleinste Problem. Und bei einem Weg aus diesem schnuckeligen Import sind ebenfalls weniger die Leerzeichen in "massgis:COMMENTS"="BARNSTABLE-ID#  1000028" (Ausgabe mit fester Breite) störend als generell die Schwemme überflüssiger Tags.

Und so weiter, die manuell verbauten mehrfachen Leerzeichen fallen weltweit gegenüber denen aus Importen kaum ins Gewicht.

Der Findvej-Adressimport hat wohl auch einige leere addr:housename generiert, aber besonders hübsch finde ich die Formatierung von - per se schon völlig überflüssigen - Gleitkommazahlen in diesem Import, die u.a. auch führenden Leerraum generiert hat.

Ein Glück, daß bei OSM keine Goldene Himbeere als Publikumspreis für den am meisten vermurksten Import vergeben wird - ich könnte mich gar nicht zwischen den Kandidaten entscheiden. Aber zurück zum Thema. Die Situation hierzulande ist völlig anders als im Rest der Welt (bzw. planet.osm in Summe); kannst Du mal eine gleichartige Tabelle für DE erstellen? Mehr möchte ich ohnehin nicht anfassen (vielleicht später einzelne weitere nicht importverseuchte Länder, falls dort Interesse besteht - aber nach Durchsicht Deiner Liste kommt ein weltweiter Einsatz eher nicht in Frage).


No animals were harmed in the writing of this posting.

Offline

#39 2013-03-15 15:41:35

Oli-Wan
Member
From: NRW
Registered: 2010-09-14
Posts: 2,814

Re: Wall·E räumt auf: Leerraum in Tags und Rollen

mdk wrote:

Eventuell habe ich den Aspekt in diesem Faden übersehen, aber was ist mit solchen Tags:

motor_vehicle:(Mo-Fr 07:00-16:00) = agricultural;delivery
access:(Mo-Fr 06:00-17:30) = private
bicycle:(Mo-Fr 20:00-09:00, Sa 16:00-24:00, Su,PH 00:00-24:00, 24:00-09:00) = yes

Du hast nichts übersehen. OSMI meckert generell über Leerzeichen im Schlüssel - und hat damit ja auch nicht ganz Unrecht. Tags wie die obigen stammen aus der Zeit vor *:conditional (ich habe selbst einige davon fabriziert) und können jetzt entsprechend umgetaggt werden. Das ließe sich eventuell auch teilweise automatisieren (umtaggen, falls gültig - sonst nicht anfassen), aber angesichts der Zahl solcher Tags lohnt der Aufwand m.E. nicht.


No animals were harmed in the writing of this posting.

Offline

#40 2013-03-15 18:13:06

Netzwolf
Member
Registered: 2008-04-01
Posts: 1,665

Re: Wall·E räumt auf: Leerraum in Tags und Rollen

Nahmd,

Oli-Wan wrote:

kannst Du mal eine gleichartige Tabelle für DE erstellen?

Bittschön: 146665 Zeilen als Gzip (1.7Mb) oder Bzip2 (1.4Mb).

Gruß Wolf

Offline

#41 2013-03-15 18:25:08

Oli-Wan
Member
From: NRW
Registered: 2010-09-14
Posts: 2,814

Re: Wall·E räumt auf: Leerraum in Tags und Rollen

Netzwolf wrote:

Bittschön: 146665 Zeilen als Gzip (1.7Mb) oder Bzip2 (1.4Mb).

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 wink
Derselbe Import ist auch mit leeren Tags ganz gut dabei.

Last edited by Oli-Wan (2013-03-15 18:37:03)


No animals were harmed in the writing of this posting.

Offline

#42 2013-03-15 18:38:49

Netzwolf
Member
Registered: 2008-04-01
Posts: 1,665

Re: Wall·E räumt auf: Leerraum in Tags und Rollen

Nahmd,

Oli-Wan wrote:

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.

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

Offline

#43 2013-03-15 18:43:36

Oli-Wan
Member
From: NRW
Registered: 2010-09-14
Posts: 2,814

Re: Wall·E räumt auf: Leerraum in Tags und Rollen

Netzwolf wrote:

Ja sorry, ich hab mit dem DE einhüllenden Rechteck geschnitten, das ergibt viel Beifang.

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.


No animals were harmed in the writing of this posting.

Offline

#44 2013-03-15 20:38:34

user_5359
Member
From: Königswinter
Registered: 2008-12-25
Posts: 264
Website

Re: Wall·E räumt auf: Leerraum in Tags und Rollen

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.

Offline

#45 2013-03-18 12:31:30

Oli-Wan
Member
From: NRW
Registered: 2010-09-14
Posts: 2,814

Re: Wall·E räumt auf: Leerraum in Tags und Rollen

Nochmal zur Diskussionsgrundlage: Unter http://toolserver.org/~mapjedi/leading_ … ace_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"

roll

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"

Last edited by Oli-Wan (2013-03-18 12:38:26)


No animals were harmed in the writing of this posting.

Offline

#46 2013-03-21 13:46:43

Oli-Wan
Member
From: NRW
Registered: 2010-09-14
Posts: 2,814

Re: Wall·E räumt auf: Leerraum in Tags und Rollen

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

Vielleicht noch eine Handvoll weitere, wenn ich die Liste noch einmal gründlicher durchgesehen habe.

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


No animals were harmed in the writing of this posting.

Offline

#47 2013-03-21 14:18:35

wambacher
Member
From: Schlangenbad/Wambach, Germany
Registered: 2009-12-16
Posts: 16,311
Website

Re: Wall·E räumt auf: Leerraum in Tags und Rollen

Oli-Wan wrote:

Soweit meine aktuellen Überlegungen. Was haltet ihr davon?

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

Offline

#48 2013-03-21 14:40:57

errt
Member
Registered: 2009-12-01
Posts: 1,068

Re: Wall·E räumt auf: Leerraum in Tags und Rollen

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

Offline

#49 2013-03-21 14:41:31

Oli-Wan
Member
From: NRW
Registered: 2010-09-14
Posts: 2,814

Re: Wall·E räumt auf: Leerraum in Tags und Rollen

wambacher wrote:

Ich würde "ohne Rücksicht auf Ansehen" bei allen Tags einen generellen Trim ...

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.

wambacher wrote:

Das ganze natürlich iterativ: wenn bei Splitten von Tags neue zur trimmende Spaces auftauchen -> weg damit.

Jetzt hast Du mich abgehängt. Was meinst Du mit Splitten?

errt wrote:

Hast du vor, das hier auf Deutschland beschränkt laufen zu lassen?

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.

Last edited by Oli-Wan (2013-03-21 14:49:49)


No animals were harmed in the writing of this posting.

Offline

#50 2013-03-21 15:06:55

wambacher
Member
From: Schlangenbad/Wambach, Germany
Registered: 2009-12-16
Posts: 16,311
Website

Re: Wall·E räumt auf: Leerraum in Tags und Rollen

Oli-Wan wrote:

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.

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.

wambacher wrote:

Das ganze natürlich iterativ: wenn bei Splitten von Tags neue zur trimmende Spaces auftauchen -> weg damit.

Jetzt hast Du mich abgehängt. Was meinst Du mit Splitten?

Wenn du z.B. Straße und Hausnummer in zwei Tags aufteilst. Ist aber wohl deine andere Baustelle.

Erst einmal ja, allerdings auf Geofabrik-Deutschland

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.

Offline

Board footer

Powered by FluxBB