besser wäre, wenn diese serverseitig entfernt würden. (Gleiches gilt übrigens auch für die als discardable eingestuften Tags. Die schleifen wir auch schon seit Jahrzehnten unnötig mit uns rum.)
im Ernst, du willst dass jemand entscheidet welche tags “discardable” sind und dann werden die serverseitig gelöscht? M.E. ist da der potentielle Schaden größer als der vermutete Nutzen. Wer rendert oder routet oder geocodet schaut sowieso nur auf die tags die ihn interessieren, und wer alle tags will, der will potentiell auch diese, und es macht sicherlich mengenmäßig nicht viel aus.
Was ist der Unterschied zu dem was derzeit gemacht wird, nämlich: Jemand entscheidet welche tags “discardable” sind und dann werden die so nach und nach von den Editoren (ohne den Nutzer zu fragen) gelöscht?
Meine Antwort: Es dauert einfach nur viel länger. Siehe z.B. die Chronologie von created_by, das hätte man 2010 schon komplett löschen können (ob jetzt vom Server oder durch einen Bot ist egal), stattdessen schleppt man es jahrzehnte lang mit sich rum, mit einer Halbwertszeit von ca. 3 Jahren; wahrscheinlich hat man im Jahr 2100 noch Reste in den Datenbankdumps…
Finde ich merkwürdig, dass du einem erklärten Freitextfeld wie description Regeln verpassen willst und diese Regeln dann auch noch vom Server durchsetzten lassen willst. Aber nur zu… mach das Proposal, stell es zur Abstimmung, programmiere die API,… das hier im deutschen Forum zu diskutieren bringt da nicht viel.
Ich sehe hier keinen Grund description dahingehend einzuschränken.
Da hast du mich wohl falsch verstanden. description war hier der Aufhänger, weil es mir da halt aufgefallen ist. Aber ich rede von allen Tags, genauer von allen keys und values der Tags. Da bei denen ohnehin schon die Leerstellen am Anfang und am Ende von den Editoren entfernt werden, braucht’s da auch kein Proposal; wir ja ohnehin schon umgesetzt. Mir geht’s nur darum, dass man das effektiver machen könnte.
Gibt es bereits einen Präzedenzfall, wo der Server die Eingaben bereinigt? Es klingt jedenfalls so als würden wir hier den Präzedenzfall schaffen.
Ein ganz großer Nachteil von serverseitigen Bearbeitungen liegt darin, dass es von außen unmöglich ist, diese zu ändern. Wenn ein Editor meine Eingaben verändert, obwohl ich halt doch einen bestimmten Inhalt gemeint habe, kann ich einen anderen benutzen oder im Worst Case die OSM-API direkt anzapfen. Geschieht die Veränderung erst hinter der API, geht das nicht.
Weiterhin wäre es natürlich Wartungsaufwand seitens der Serversoftware und es besteht auch die Frage, wie mit potentiellen Bugs umgegangen wird. Da steck ich nicht drin, aber oft genug gesehen, dass Bugs wegen Kompatibilität nicht gefixt werden können und damit faktisch zum Feature werden. Insbesondere in nichttechnischen Bereichen, wie es eine hier geforderte Veränderung der Eingaben wäre.
Insofern ist es meines Erachtens nur sinnvoll, dabei zu verbleiben, dass der Server die technischen Maßnahmen zur Bereitstellung von OSM übernimmt, während die nichttechnischen Anforderungen von Editoren erfüllt werden.
Ja… wie gesagt… solltest du im internationalen Teil diskutieren.
Nur so als Startgedanke: Was soll der Server machen, wenn ich 100 Objekte ändere/lösche/hinzufüge und beim 99ten Objekt habe ich onewy=1 gesetzt.
98 Objekte sind schon in der Datenbank. Was soll der Server jetzt machen? Objekt 99 abweisen? Sprich ich habe dann 98 leere nodes in der Datenbank, weil der way fehlgeschlagen ist?
Wer würde entscheiden, dass onewy=1 nicht ok ist? Was machst du bei umstrittenen Tags wie railway=razed. Und so weiter und so fort.
Die technische Seite wäre gar nicht das Problem - mittels Transaktionen kann der ganze Changeset abgebrochen werden -, davon abgesehen ist das Konzept soweit ich es verstehe eher, Eingaben zu korrigieren, d.h. es werden keine Tags abgewiesen.
Diese Fragen sind viel interessanter, weil sie die nichttechnische Seite beleuchten.
Ich kenne die Server-Software nicht, vermute aber, dass er derzeit fehlerhafte Eingaben einfach abweist. Z.B. Koordinaten >180° und dergleichen. Abweisen einer Eingabe mit Leerzeichen am Anfang und am Ende wäre vielleicht sogar sinnvoller.
Darin sehe ich genau den Vorteil. Man kann sich als User dann drauf verlassen, dass keine Leerzeichen mehr an Anfang und Ende eines Tags vorhanden sind.
Da wäre das Abweisen vermutlich einfacher handzuhaben, weil man da den Bug einfacher beheben kann.
Genauso akzeptieren, wie alles andere. Der Tag hat weder im Key noch im Value irgendwelche Leerzeichen und zudem handelt es sich um keinen discardable Tag, also wird er akzeptiert.
Mir geht es nicht darum, dass der Server Tippfehler korrigiert. Das soll er bitte bleiben lassen, denn wer weiß schon, ob onewy nicht irgendwann ein sinnvoller Tag wird. Und ich kenne auch keinen Editor, der aus onewy ohne zu fragen ein oneway macht. Aber vermutlich gibt es welche, die den User fragen, ob das kein Tippfehler ist. Und das ist auch alles gut so.
Mir geht es darum, sinnlosen Müll aus den Daten rauszuhalten. Also Zeugs, was keinen Nutzen hat (*) und ohnehin schon automatisch entfernt wird, nur halt ineffektiv. Ob das jetzt der Server macht oder ob man das durch regelmäßige automatische Edits macht, ist mir dabei relativ egal. Wenn es der Server macht, kann man sich halt drauf verlassen, dass das Zeugs nicht da ist; das sehe ich als Vorteil, wie oben ja schon geschrieben.
(*) Die Leerzeichen am Anfang können einen marginalen Nutzen haben, da hattest du mich ja auf den Gebrauch in anderen Kulturen aufmerksam gemacht, etwas was ich nicht kannte und weshalb ich da auch ein Herzchen vergeben habe. Aber da Editoren diese Leerzeichen entfernen halte ich es für sinnvoll, das dann auch konsequent durchzuhalten.
Die hast hier erklärt, wie man zwei Leerzeichen vor den Wert/Satz setzt (= Einzug), aber nicht, wie man einen Absatz in einem Tag erzeugt. Dazu müsste man mindestens zwei Sätze eintragen, die durch einen Zeilenumbruch getrennt werden.
Und so weiter und so fort.
Aber da Editoren diese Leerzeichen entfernen halte ich es für sinnvoll, das dann auch konsequent durchzuhalten.