Puuh, ich dachte schon…
Nahmd,
Deshalb ist es ok, wenn jemand mit irgendwelchen Tools (ich wüsste nicht, wie ich das mit JOSM hinbekomme) Keys mit Blankspace am Anfang und/oder Ende und Attribute mit leeren Werten in die Datenbank schiebt, jedenfalls solange das nicht als “automatisiert” auffällt. Aber “diskussions- und genehmigungspflichtig”™, wenn man den Müll automatisiert tilgt.
Wegen solcher Prinzipienreiterei lasse ich den Müll in der DB. Eine Diskussion (mit dem vorhersehbaren Ergebnis: “schön dass wir darüber gesprochen haben”) würde weitaus mehr Zeit erfordern als die wenigen Minuten zur automatischen Behebung der Fehler.
Gruß Wolf
Also DAS Thema sollte längs klar sein: solche offensichtlichen Datenfehler - egal ob in den Keys oder in den Values - zählen nicht zu den “genehmigungspflichtigen” Mechanical Edis. Aber wenn jemand einen Key oder Wert inhaltlich ändert (zB. aus path footway macht), ist das so nicht erlaubt.
Gruss
walter
Mit JOSM ist das nicht möglich, richtig. Kann aber auch zum Problem werden, wenn man eigentlich doch mal Werte mit mehreren aufeinanderfolgenden Leerzeichen bräuchte (z.B. “railway:ref:DBAG”=*) 
Es ist hauptsächlich eine “wehret den Anfängen”-Geschichte. Im Grunde müsste man eine Regel haben, die lautet: “Automatische Edits sind erlaubt, sofern sie von vernünftigen Leute durchgeführt werden, die sich gut auskennen.” Leider funktioniert die Selbst-Selektion hier nicht so gut (“Klar bin ich vernünftig, und ich habe auch schonmal ein Haus gemappt also kenne ich mich wohl gut genug aus!”). Deswegen haben wir eine Reihe von Hürden aufgestellt, die geeignet sind, diejenigen, die unvernünftig, unwissend, oder auch einfach nur zu ungeduldig sind, zum Stolpern zu bringen (bzw. die dazu führen, dass diese Leute mit Hilfe aus der Community eben doch was vernünftiges hinbekommen).
Das widerspricht eigentlich dem Geist von OSM, denn man muss bei uns ja bei den allermeisten Sachen eben nicht vorher fragen, bevor man etwas macht, und damit sind wir auch bisher ganz gut gefahren. Leider kann man eben mit unsachgemäßer Skript-Nutzung sehr schnell sehr viel Schaden anrichten. Der meiste “Müll”, der hier angesprochen wird, entsteht eben durch solche unüberlegten Aktionen. Selbst erfahrenen Nutzern passiert es noch manchmal, dass sie sich verschätzen oder verrennen (“Was? Keys mit nur einem Buchstaben? Die können ja nichts nütze sein, weg damit!” und dann gab es plötzlich doch eine sinnvolle Anwendung usw.usw.)
Deswegen denke ich, dass es im großen und ganzen schon gut ist, wenn wir sagen “größere Änderungen erfordern auch größere Rechtfertigung”. Das führt dann zwar dazu, dass ein paar Leute keine Lust mehr haben, solche Änderungen anzugehen, aber andrerseits - wer nicht den Atem hat, ein paar extra aufgestellte Bürokratiehürden zu überspringen, der hatte vielleicht auch nicht den Atem, seine geplante Änderung ordentlich vorzubereiten und zu durchdenken 
Bye
Frederik
Nahmd,
Nach meinem Verständnis ist die Mechanical Edit Policy durchaus anderer Ansicht. Dort gibt es keine Ausnahmen.
Nimm das Tool der Wheelchair-Map: die können sogar mehrzeilige Werte eintragen.
Das “vielleicht” und der Smiley lässt offen, ob die Aussage ernst gemeint ist oder nicht. Ich entscheide, dass ich sie ernst nehme.
Also: wenn ich meine Zeit nicht mit Unfug vertun will, so folgert daraus, dass ich die Putzaktion nicht durchdacht habe?
Nicht alles, was quietscht, ist auch ein Argument.
Ist es offizielle OSMF-Policy, dass ich meine begrenzte Zeit zuerst sinnfrei mit “bürokratischen Hürden” verplempern muss, bevor ich die Qualität der Datenbank verbessern darf?
Wow!
Hallo Forum, hat jemand Spaß an der Beschäftigung mit bürokratischen Hürden? Der darf gerne eine Diskussion starten. Die Datei der offensichtlichen Müll-Tags fällt ohnehin täglich an, und ein Kommandozeilen-Tool zum Fixen stelle ich auf Wunsch bereit.
Gruß Wolf
Wunsch! Gerne per OSM-Nachricht.
Nahmd,
Hier die Müll-Tag-Datei (88Mb). Wird täglich irgendwann morgens so gegen 4:00 aktualisiert und hat dann Stand Mitternacht.
Enthält um die 100k Objekte mit Blankspace-Zeichen außer Space und/oder mehr als einem Space-Zeichen in Folge und/oder leading und/oder trailing Blankspace in Keys und Values und/oder leerem Key und/oder leerem Value. Ich normalisiere oder entsorge den Mist beim Einspielen in meinen Datenbestand, ändere dabei aber nichts an der OSM-DB.
Mehrfachleerzeichen und Tabs+Zeilentrenner muss man wahrscheinlich drinlassen, obwohl erstere bei Zeichensätzen variabler Breite praktisch nicht zu erkennen sind (dafür aber Spaß bereiten bei Suchanfragen) und letztere spätestens bei der Bearbeitung mit einem der Standardeditoren verloren gehen, man sich also ohnehin nicht auf die fortdauernde Speicherung verlassen kann.
Ein Verlorengehen bei einer Bearbeitung mit JOSM wäre aber (auch wenn der Bearbeiter nix dazu kann und es möglicherweise nicht einmal merkt) eine manuelle Bearbeitung und kein mechanischer Edit, also erlaubt und erwünscht. Ein Systematisches Aufräumen dagegen … aber warum soll ich der Diskussion vorgreifen?
Gruß Wolf
Gut gemeint, funktioniert aber leider nicht. Wenn ich mir den Kram jetzt ziehe, paar andere Fehler korrigiere und josm den Rest erledigt, bin ich trotzdem der Gelackmeierte.
Nahmd,
Da ist irgendwas falsch angekommen; das sollte keine Aufforderung zu einem versteckten Mechanischen Edit sein.
Wenn die Korrektur des Mülltaggings für mich von Bedeutung wäre, würde ich nicht solche Klimmzüge machen, sondern ein Freund eines Freundes™ würde mit einem Wegwerfaccount die Änderungen von einer nicht belangbaren IP aus einspielen. Was ich als überaus verwerflich ansehen würde.
Aber im Ernst: in meiner Kopie des Datenbestandes sind diese (und diverse andere) Fehler korrigiert; eine Korrektur auch in der OSM-DB könnte/sollte im Interesse der OSM-Gemeinde sein — für mich ist sie bedeutungslos.
Gruß Wolf
Danke!
Kannst du evtl. auch die Fehlerklasse als Spalte mit ausgeben, oder macht das viel Programmieraufwand?
Siehste, das ist genau das, was ich meine. Wenn Du nur lang genug in jedem Posting von “Müll” redest, Listen veröffentlichst (Taginfo hat übrigens auch jede Menge interessante Listen dieser Art, z.B.http://taginfo.openstreetmap.org/reports/characters_in_keys#whitespace) und noch dazu Commandline-Skripts anbietest, die den “Müll” mal eben in einer “Putzaktion” “aufräumen” - wenn man also diese Worte benutzt und diese Stimmung verbreitet, dann gibt es irgendwann auch genug Leute, die den Hintergrund nicht so genau studiert haben und denken “ah klar, Müll, der muss weg, also drück ich hier mal auf den Knopf an dem Programm”.
Es kommt aber eben gerade darauf an, dass nicht ein einzelner entscheidet, was seiner Ansicht nach Müll ist. Du kannst das für Deine private Datenbank gern machen, denn die hat einen ganz bestimmten, von Dir festgelegten Zweck, und im Lichte dieses Zweckes darfst Du als “Müll” “entsorgen”, was Du willst. Das sollte Dich aber nicht dazu verleiten, öffentlich zu suggerieren, dass das, was für Dich Müll ist, für alle anderen selbstverständlich auch Müll ist und daher am besten gleich in OSM “entsorgt” werden soll. Solche Entscheidungen sollte ein Einzelner nicht treffen.
Dass Du das ganze in eine gespielte ist-mir-doch-egal-Haltung verpackst (“wenn ihr den Müll behalten wollt, macht mir das nichts, ich schmeiss ihn ja bei mir eh weg…”), macht die Sache nicht besser. Allein, dass Du die Liste veröffentlichst, zeigt doch, dass Du billigend in Kauf nimmst, dass irgendjemand damit Mist macht. Eine Liste mit diesen Problem-Tags zu erstellen ist für jemanden, der auch nur ansatzweise die Fertigkeiten für einen mechanischen Edit besitzt, eine Sache von Minuten. Aufwendig ist es, sich in Ruhe zu überlegen, welche Tags man als Müll ansieht, oder vielleicht sogar, aufzuspüren, wie sie entstanden sind, und die Ursachen zu beheben.
Deine Einstellung (“mir ist meine Zeit dafür zu schade, Konsensfindung ist was für Warmduscher, ich bräuchte hier nur einen Knopf zu drücken, aber ihr wollt ja Euren Mist behalten, ihr lasst mich die Qualität nicht verbessern, Eure Anforderungen sind sinnfrei, bla bla bla”) kommt bei mir als eine relativ hochnäsige Einzelgänger-Einstellung rüber. Ob ein mechanischer Edit, der die von Dir für “offensichtlichen Müll” gehaltenen Daten entsorgt oder automatisch korrigiert, die Qualität der OSM-Datenbank verbessern würde, ist bei weitem nicht klar. Zum Beispiel:
-
ein automatischer Edit setzt das “last modified”-Datum auf heute, selbst wenn das Objekt seit 5 Jahren nicht angefasst wurde. Dadurch wird zumindest oberflächlich eine Aktualität suggeriert, die nicht existiert. Das ist kein großes Problem, aber zwei aufeinanderfolgende Leerzeichen sind auch kein großes Problem. Welches ist größer?
-
ein automatisches Löschen von leeren Keys oder leeren Values könnte Informationen vernichten, die ein Mensch noch retten würde (hypothetisches Beispiel: wenn irgendwas mit dem Key “highway” und einem leeren Value getaggt ist, kann ich als Mensch es immerhin nach manueller Inspektion auf highway=road setzen, oder wenn etwas mit leerem Key und Value “building” getaggt ist, kann ich ein building=yes draus machen).
Das war nur das, was mir auf Anhieb einfiel; sicherlich gibt es noch mehrere Punkte, die in einer Diskussion zutage treten würden und die abgewogen werden müssen. (Für eine großflächige Änderung ausserhalb des deutschen Sprachraums sollte eine solche Diskussion auch nicht im deutschen Forum geführt werden.)
Also, langer Rede kurzer Sinn - dass großflächige “Müll-Entsorgungen” nicht privat im stillen Kämmerlein geplant und ausgeführt werden, halte ich schon für eine gute Sache, und wem seine Zeit zu schade ist, das mit der doofen Community zu diskutieren, der sollte vielleicht wirklich einfach die Finger davon lassen und sich auf seine private Datenbank beschränken.
Für Nutzer einer privaten (osm2pgsql-)Datenbank gibt es seit einiger Zeit ein noch wenig bekanntes Feature in osm2pgsql, das “Lua Tag Transform”. Damit kann man sich, ganz ohne C-Kenntnisse und Compiler, in der Skriptsprache “Lua” einen Satz von Regeln aufbauen, die Tags verändern, und damit kann man dann relativ einfach eine eigene, gefilterte Datenbank am Laufen halten. Da gehen auch solche Sachen wie “oneway=yes/true/1 in oneway=true wandeln” oder “highway=path mit bicycle=yes in highway=cycleway umwandeln” und und und. Und man kann sein tolles Lua-Skript dann sogar anderen geben, die auch eine “müllfreie” Datenbank haben wollen
https://lists.openstreetmap.org/pipermail/dev/2013-May/026933.html
Bye
Frederik
Bye
Frederik
Moins,
Ich beuge mich der Entscheidung des OSMF-Board-Repräsentanten, habe die Listen vom Server getilgt (wer in der Richtung arbeiten will, kann sie sich mit wenig Aufwand selbst erstellen), und ziehe das Angebot zur Bereitstellung des Tools zurück.
Gruß Wolf
Die Liste ist als Basis für manuelle Edits aber zu gebrauchen, und so verwende ich die dann jetzt auch. Ich nehme sie als QS-Tool, wie OSMI etc., und gucke mir im JOSM die Stellen an.
Vielleicht wäre das ja mal was für eine Wochenaufgabe?
Deine Argumentation kann ich nicht ganz nachvollziehen. Das würde heißen wenn ich nur oft genug hier schreibe das 1+1=3 ist glauben die anderen das sei die Wahrheit? Darum ist es mir verboten sowas auch nur zu denken. Ähm. Naja dürftige Argumentation.
Er hat auch nicht gemeint im Besitz der alleinigen Wahrheit zu sein. Anhand seiner Liste hätte man mit Beispielen wie du zwei rausgegriffen hast doch darüber diskutieren können ob und warum und wie man das Programm/skript so anpassen kann, dass nur das gelöscht wird was objektiv ist. Oder man macht damit eine Liste im Wiki die in Blöcken abgearbeitet wird. Sowas gabs bei Geschäften Plz und einigen anderen Dingen auch schon.
Jetzt haben wir aber erstmal auf jemanden draufgedroschen ohne absehen zu können welchen Schaden das anrichtet. Das sollte nicht die Meinung eines einzelnen sein Bestimmte Dinge zensieren zu dürfen. Auch nicht in der OSMF und der DWG.
Er hat aber konsequent von “Müll” gesprochen. Nicht, zum Beispiel, “Dinge, in denen ich keinen Nutzen erkennen kann” oder irgendwas relativierendes. Stattdessen “offensichtlicher Müll”. Er hat uns lediglich gnädigerweise freigestellt, ob wir den Müll in der Datenbank lassen wollen oder nicht.
Sowas kann man machen, aber Wolf hat ja mehrfach deutlich gesagt dass er auf sowas keine Lust hat, weil es unnötiges Geschwafel ist. Daher richtete sich meine Kritik nicht dagegen, dass irgendjemand sich einen vernünftigen Prozess ausdenkt, (vermeintlich?) unsinnige Tags zu analysieren und zu korrigieren, sondern gegen die bei mir relativ arrogant ankommenden Äusserungen von Wolf: “Das hier ist Müll. Mir ist meine Zeit zu schade, mich weiter drum zu kümmern, weil ihr immer alles erst diskutieren wollt. Eure blöden Community-Regeln könnt ihr selber abarbeiten”. (Jetzt mal von mir umschrieben.)
Jemand, der so austeilt wie Wolf, wird bestimmt nicht gleich den Schwanz einziehen, wenn er mal Kontra kriegt.
Zensur findet, wenn überhaupt, nur durch den Staat statt.
Bye
Frederik
Ich seh da überhaupt kein Problem. Wenn jemand “unsere” “blöden” Community-regeln blöd findet, diese aber nicht bricht, ja ääh, und? Finde ich besser, als Leute, die sich nicht äussern und stattdessen richtig Müll verzapfen. Kann man drüber nachdenken. Letzteres nur reverten (solang man es rechtzeitig findet)
Nahmd,
Möglicherweise ist “Müll” zu heftig ausgedrückt, aber ein “highway=service ” (man beachte das Blank nach dem “e” von service) bewirkt nicht das, was der Erfasser offensichtlich (oder höchstwahrscheinlich) beabsichtigt hat. Reiner Ballast ohne Wirkung. Eine Korrektur würde die Qualität der Datenbank erhöhen.
Die 15k Einträge bestanden ausschließlich aus führenden und abschließenden Leerzeichen sowie aus Tags ohne Wert. Deren Korrektur zu keinen Problemen führen kann.
Wie ohne Beispiele soll ich zeigen, um welches Thema es mir geht?
Wieso ist es korrekt, wenn Taginfo diese Listen anbietet, nicht jedoch, wenn ich eine Liste anbiete?
Bitte nicht aus dem Zusammenhang reißen: ich habe nach jemandem gesucht, der den bürokratischen Weg gehen will, und diesem technische Unterstützung angeboten.
Ich habe im Umfeld von OSM keinerlei waffenfähige Software veröffentlicht. Das Angebot richtete sich exakt an denjenigen, der das vorgeschriebene Prozedere durchlaufen will.
Andererseits: jeder kann das Ergebnis einer OP-Suche nach JOSM laden, dort eine maschinelle Änderung vornehmen, und dann das Ergebnis zurückschreiben. Wieso gibt es keine Kritik an dieser Möglichkeit? Die steht nun wirklich jedem zur Verfügung!
Weil ich eine Diskussion über den Sinn eines Blanks am Ende eines Tag-Wertes nicht antun will, habe ich eben KEINE ÄNDERUNGEN VORGENOMMEN. Ich halte die Regeln ein.
Ich habe mir nur die Freiheit genommen, zu sagen, dass ich die Regel an dieser Stelle für Unfug halte. Du hältst sie für sinnvoll. Ich halte sie für Unfug. Mit ersterem muss ich leben — und verzichte auf die Korrektur. Und mit zweiterem musst Du leben.
Selbstverständlich habe ich die Freiheit zu sagen, dass ich dies und das für Müll halte. Wäre ja noch schöner. Und jeder andere hat die Freiheit, das, was ich von mir gebe, für Müll zu halten.
Wegen des Suggerierens: da wäre ich dankbar für eine Formulierungshilfe: wie kann ich ausdrücken, dass mir etwas nicht gefällt, ohne dass mir nachher der Vorwurf gemacht wird, ich würde andere dazu auffordern, das, was mir nicht gefällt, auch nicht zu mögen, oder es sogar zu tilgen.
Was soll das “gespielt”? Könntest Du bitte auf Unterstellungen verzichten?
Das war eine Beschreibung des Ist-Zustandes. Ich schaue zu, wie das Zeug automatisch repariert wird. Und dabei kommt irgendwann die Idee, dass man doch auch gleich die Original-Daten reparieren könnte, damit alle was davon haben.
- Siehe oben: wie soll ich ein Thema ansprechen, ohne Beispiele dafür anzugeben? Die erste (kurze) Liste enthielt genau die Beispiele, bei denen ich davon ausgehe, dass jeder der Korrektur zustimme.
Erst nachdem (zu meiner Überraschung) sich jemand gemeldet hat mit dem Angebot, das Thema bürokratisch sauber anzugehen, habe ich die zweite Liste als Diskussionsgrundlage bereitgestellt.
- Unterstellst Du auch den Betreibern von Taginfo, billigend in Kauf zu nehmen, dass jemand mit den Listen Mist macht? Unterstellst Du OP, billigend in Kauf zu nehmen, dass jemand Abfrageergebnisse benutzt, um Mist zu machen? Unterstellst Du den Machern von JOSM und iD, billigend in Kauf zu nehmen, dass jemand mit den Tools Mist macht?
Ja warum zum Teufel unterstellst Du es dann MIR?
Ja. Und?
Genau diese Diskussion war gerade dabei zu entstehen. Sieh einfach mal die Pole: ich ging davon aus, dass die Policy eine automatische Korrektur ohne Diskussion ausschließt, ich aber kein Interesse an einer solchen Diskussion habe. Der geschätzte Kollege Wambacher gab zu bedenken, dass eine Korrektur offensichtlicher Fehler möglicherweise auch ohne bürokratischen Aufwand erlaubt ist, und gormo interessierte sich für das Thema und bot an, die bürokratische Seite anzugehen. Ich hab ihn mit Material zum Einarbeiten ausgestattet…
das Projekt könnte auf dem Weg sein, wenn Du Dich einfach rausgehalten hättest.
Ja, dafür ist mir meine Zeit wirklich zu schade. (und jetzt vergeude ich sie für dieses Posting)
Würdest Du bitte auf diese blödsinnigen Unterstellungen verzichten? Danke.
Es ist mehr als auf einen Knopf drücken. Ich schaue halt an und zu in die Logs, und da kam halt der Gedanke, dass man die Korrekturen mit wenig Aufwand in die OSM-DB einspielen könnte. Auch für diesen Gedanken werde ich mich NICHT entschuldigen. So bin ich nun mal. Und da wirst Du nichts dran ändern.
Es ist Dein gutes Recht, das so wahrzunehmen. Sagt aber mehr über Dich als über mich aus.
Ein Split eines Weges setzt die mtime der Teilstücke auf jetzt, dazu die Versionsnummer aller bis auf einen der Teilstücke auf 1. Dadurch wird zumindest oberflächlich eine Aktualität suggeriert, die nicht existiert.
Ein Verschieben eines kompletten Gebäudes von Europa nach Australien verändert die Mtime des Ways NICHT. Dadurch wird zumindest oberflächlich ein Altbestand suggeriert, der nicht existiert.
Ich habe NICHT vorgeschlagen, Folgen von Leerzeichen zu entfernen. Ich habe NUR vorgeschlagen, Leerzeichen am Anfang und Ende von Keys und Values zu tilgen. Damit das Attribut die Wirkung hat, die der Erfasser möglicherweise vorschwebte.
Du bist herzlich eingeladen, die Objekte abzuarbeiten.
Eine Liste mit diesen Problem-Tags zu erstellen ist eine Sache von Minuten.
Wir können die Anforderungen so lange erhöhen, bis sich nichts mehr bewegt.
Du hast jedes Recht zu dieser Meinung.
Wenn Du die Community für doof hältst, ist das ok; sagt halt (siehe oben) mehr über Dich als über die Community aus.
Wenn Du aber damit mir unterstellen willst, dass ich die Community für doof halte: kannst Du diese blöden Unterstellungen nicht einfach mal sein lassen? Danke.
Gruß Wolf
Doch!
Es ist ja eine Aenderung mit einem funktionalen Impakt. Alle Anwender haben ja irgendeinen Weg gefunden, damit umzugehen, die einen normalisieren, die anderen ignorieren solche Tags.
Was willst Du jetzt machen? Löschst Du persistent, dann triffst Du die ersten, mindestens mal in dem Sinne, dass Regressionstests Amok laufen. Und normalisiest Du persistent, dann trifft es die anderen.
Es ist natürlich nicht schön, dass diese zusätzliche Entropie in der Datenbank steckt, und es ist auch nicht schön, wenn ein Router was nimmt was der Renderer nicht malt oder umgekehrt. Aber es ist eben auch Information, weil der highway="service " mit Sicherheit weniger qualitätsgesichert ist als der highway=“service”, und Du solltest nicht sämtlichen OSM-Routern die Entscheidung abnehmen, die Anwender da drüber zu schicken.
Toll fände ichs, wenn’s sowas wie eine “common sense” Normalisierung gäbe, z.B. in Form einer Berechnungsvorschrift auf Basis von Regular Expressions, wo man davon ausgehen kann: ja, so machens die meisten, “oneway=true” wird gerendered, “oneway=ja” aber nicht. Hast Du sowas?