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

Dem kann ich mich voll und ganz anschließen!!

Ich habe jetzt mal bisl meine grauen Zellen angestrengt und kann absolut keinen Grund finden, warum mehr als ein Leerzeichen (oder gar TAB) direkt hintereinander innerhalb eines keys und/oder values sein sollte. Also von mir aus können die auch gleich mit verschwinden :wink:

Natürlich wäre es viel schöner und eleganter, wenn die API das direkt verhindert. Gibt es nicht irgendwo eine Wunschliste für die API 0.7???

ja → http://wiki.openstreetmap.org/wiki/API_v0.7

+1 :slight_smile:

Hm, wie meinst du das?
Zumindest Potlatch 2 verwendet:

http://api.openstreetmap.org/api/0.6/changeset/create
http://api.openstreetmap.org/api/0.6/changeset/#/upload
http://api.openstreetmap.org/api/0.6/changeset/#/close

Gruß,
Mondschein

Dann war ich wirklich nicht auf dem aktuellen Stand. Bei Potlatch 1 war/ist das noch anders - zumindest wurde es immer so berichtet. Vielleicht geraten hier ja noch weitere althergebrachte Wahrheiten ins Wanken :wink:

@ Schildbuerger, jman1983, Mondschein (und weitere, die sich in anderen Fäden schon ähnlich geäußert haben):
Danke für die freundlichen Worte; ich verstehe natürlich auch, wenn ihr nicht in jedem solchen Faden posten wollt, ohne wirklich “etwas zu sagen” zu haben. Mein Dilemma ist halt, daß ich nicht wirklich einschätzen kann, wie vielen es ähnlich geht, während sie die Themen aufmerksam verfolgen; oder wie viele andererseits nur der ellenlangen, teils recht technischen Fäden überdrüssig sind - und “Schweigen heißt Zustimmung” ist auch nicht so meine Sache.

Potlatch 1 verwendet AMF:

/api/0.6/amf/read
/api/0.6/amf/write

Der AMF-Controller (auf dem Server) führt dann direkt SQL-Anfragen aus:

Quelle: http://lists.openstreetmap.org/pipermail/talk-de/2012-May/095786.html

Vermutlich meinst du das. :slight_smile:

Gruß,
Mondschein

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…

Meinen irrelevanten Segen hat’s, ist mein Motto doch seit jeher “Wer Tippfehler findet darf sie behalten”.
Gleiches gilt auch für beliebige Schreibvarianten von “Amenty&ParkingAissle”…

Und falls es wirklich wen geben sollte, der mit diesen trailing spaces irgendwelche an Steganographie grenzende Bitfriemel-Signalisierung durchführt, dann gehören demjenigen die Ohren langgezogen, dass er den Hack nicht zumindest irgendwo dokumentiert und kommuniziert hat.

Ich bin dafür.

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

  • es würden keine Informationen verloren gehen
  • Mapper könnten leicht nach den Fällen suchen, um sie einzeln zu bearbeiten.
  • Wenn Mapper das Objekt aus anderen Gründen bearbeiten, dann kennen sie die Lage vor Ort vielleicht und könnten es leicht lösen. Dazu muss ihnen aber das Problem aber erstmal auffallen

Weide

PS: Denn Fall der Key-Verdopplung durch Entfernen von Zeichen (“name” und "name " vorhanden) muss man auch noch passend lösen. Evtl. wie bei den Freitext-Werten vorgeschlagen.

Weißzeichen (space, newline, tab, …) am Anfang/Ende gehören sich IMO immer getrimmt, sowohl in key als auch in value. Mitten im key/value wäre ich konserativ und würde mit einer Art whitelist arbeiten, z.B. key=“social facility” → key=“social_facility” oder key=“highway”, value=“primary link” → value=“primary_link”. Die whitelist kann ja nach und nach erweitert werden.

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.

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.

Ich glaube nicht, dass es da irgendwelche Probleme geben wird sollte: als der Xybot noch stabil lief, hatte dieser das auch in der Aufgabenliste. Das hat nie Ärger gegeben.

Gruss
walter

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

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.

Ansonsten finde ich die Idee sehr gut!

Seh ich auch so

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.

Wer bei OSM Whitespace-Programme hinterlegt, dem ist eh nicht zu helfen… :smiley:

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.

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.

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:*”.

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.

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

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

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

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 “[1]{5}$” einzuhalten.

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.


  1. [:digit:] ↩︎

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.

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.

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?

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.