Leerstelle am Ende von description

Ich bin grad über eine Bäckerei gestolpert, bei der der Wert des description-Tags mit einem Leerzeichen endet. Ich denke nicht, dass das verboten ist, aber ich frage mich, ob solche Leerzeichen eher unerwünscht sind? Was ist da die gängige Meinung? Und sollte man das ändern?

Naja, sinnvoll sind sie nicht. Sehe jetzt aber auch keinen Grund sie zwanghaft entfernen zu müssen.

3 Likes

Ich bin durch Zufall mal in einer “historischen” Diskussion gelandet, in der es um die maschinelle Korrektur von offensichtlichen Taggingfehlern ging, unter anderem auch um Leerstellen am Anfang und Ende eines Wertes.

Der eine hat angeboten, diesen vermeintlichen “Müll” per Skript zu entsorgen, der andere war strikt dagegen. Beide haben ausführlich aufeinander eingedroschen - eine typische Forumsdebatte ohne Ergebnis, zumindest soweit ich mich erinnere, siehe hier.

Unabhängig davon würde ich die Leerstelle entfernen, aber nur, wenn ich das Objekt ohnehin bearbeiten wollte. Ansonsten ignorieren, da stimme ich Henning zu.

5 Likes

Ja, schrecklich diese Debatten…

Danke dir für den Link. (Ich glaube, ich hatte das tatsächlich schon mal gelesen. Aber bei der Streiterei hört man typischerweise sehr schnell auf, weiterzulesen…) :roll_eyes:

Hat sich eventuell erledigt…

1 Like

OT:

Nee, das is ja ein Ding. Beim Speckle-Bäck hab ich selber schon Weckle geholt und nu macht der auch dicht. 2 Dörfer weiter in Ringse hat vor nicht allzu langer Zeit der Bosche-Bäck auch zugemacht, weil sich niemand gefunden hat, der heute noch eine traditionelle Bäckerei betreiben will. Das ist schon irgendwie traurig … und wir sind die Totengräber auf OSM :cry:

Die Leerstelle kommt wahrscheinlich vom Smartphone, wenn man Wortvorschläge annimmt. Ich bin jetzt zu faul zum Nachgucken, bilde mir aber ein, dass einige Apps das inzwischen selber wegtrimmen (sprich: Das bei Eingabe durch den User einfach entfernen). Macht Sinn.

1 Like

Das ist gut. Meiner Meinung nach sollte man noch einen Schritt weiter gehen und den Server das automatisch wegtrimmen lassen. Aber da gibt’s andere Meinungen, wie wir ja gerade schon erfahren haben.

1 Like

Ich finde das ist Aufgabe der Editoren, und JOSM macht das ja bereits seit Urzeiten.

2 Likes

Naja, aber es gibt offensichtlich Editoren, die das nicht machen. Das führt dann dazu, dass man solche Leerzeichen in den Daten hat, und wenn die da erst mal drin sind (oder sein können), muss jegliche Software, die mit den Daten arbeitet, mit solchen Leerzeichen umgehen können. Das verursacht viel Aufwand. Bei serverseitigem Löschen könnte man das ausschließen und sich den Aufwand sparen. Deswegen wäre ich mehr für ein serverseitiges Löschen.

1 Like

Der Server könnte vieles machen. Aber ein Server der automatisch Tags verändert passt nicht zu unserem ATYL-Ansatz. :wink:

Leute die ein description auswerten sollte zugemutet werden mit Strings umgehen zu können und sei es nur den String darzustellen.

2 Likes

Finde ich nicht. Das ATYL-Prinzip sorgt dafür, dass wir in der Datenbank auch einiges an Müll haben, was immer mal wieder aufgeräumt werden muss. Das ist in Ordnung, weil durch das Prinzip Raum für neue Ideen geschaffen wird und das ist ganz klar eine der Stärken von OSM. Leerstellen am Anfang und Ende sind Tippfehler, keine neuen Ideen, was bedeutet, dass man den unerwünschen Müll hat, aber keinen Nutzen. Deswegen finde ich, dass sowas durchaus serverseitig beseitigt werden kann. (Und: Wenn es nicht so wäre, wäre das Verhalten der Editoren, die diese löschen nicht in Ordnung.) Naja, ist halt meine Meinung. Ich weiß, dass sich da bei OSM nichts ändern wird. Aber meine Meinung kundtun, will ich trotzdem. :upside_down_face:

5 Likes

Ich stimme Dir ohne Einschränkung zu. Zur Pflege einer Datenbank gehört nicht nur das permanente Neuerfassen von Daten, sondern auch die Qualitätskontrolle der erfassten Daten und das Korrigieren von Fehlern. Dazu gehören auch ganz klar die hier thematisierten Leerstellen.

Ab und zu gibt es ja tatsächlich Aufräumaktionen, z.B.

Bot proposal: values cleanup for roof:shape

Wird leider viel zu wenig gemacht, weil die meisten von uns lieber mappen wollen als die ATYL-Missgeschicke wegzuräumen, die andere hinterlassen haben.

2 Likes

Mag sein, dass ein für dich immer ein Tippfehler ist. In anderen Sprachen/Kulturen evtl. nicht, vor allem in description. Bspw. ist es im chinesischen nicht unüblich, dass ein Textabsatz mit 2 Leerzeichen anfängt.

Ich habe kein Problem damit, wenn du dich hinsetzt, dir die Fälle one-by-one anschaust und dann Tippfehler behebst. Aber halt weder automatisch. :wink:

2 Likes

Bei jedem anderen tag hätte ich Verständnis und wäre dafür.
Da Description aber immer Freitext bleibt, stört mich das eine byte deutlich weniger als das zusätzliche changeset, wenn man es wegnähme…
Es gilt ja nur den Wert anzuzeigen. Das ist schon die ganze “Auswertung”.

:gear: :bearded_person:t4:

3 Likes

Wird leider viel zu wenig gemacht, weil die meisten von uns lieber mappen wollen als die ATYL-Missgeschicke wegzuräumen, die andere hinterlassen haben.

klare Fehler (residental, …) soll man fixen, aber wenn es um kaum benutzte, ad hoc neu erfundene tags geht, dann schrillen mir bei der Vokabel “wegräumen” die Alarmglocken. Unser tagging-System ist keineswegs “komplett” und solche freien tags schaden dem System überhaupt nicht sondern sind von vornherein vorgesehen und essenziell für die Weiterentwicklung. Diese Experimente müssen nicht alle “gut gehen” (adoptiert werden), aber oft sind jetzt etablierte tags mal aus solchen freien tags hervorgegangen. Wenn sich dann mehrere tags für dasselbe entwickeln sollten kann man die später vereinigen, wobei das auch sonst nur ein kleines Convenienceproblem wäre, im Gegensatz zur Verwendung desselben tags für unterschiedliche Dinge, das ist tödlich.

(responding to autotranslated version)

I would distinguish

(A) typos (definitely worth fixing), I just started edit that will replace colour=Blue with colour=blue
though note that fixing highway=residental typo may result in creating duplicated roads where highway=residential was mapped. In comparison property such as colour or building=residental may be safer to fix.

I would encourage looking at data before starting bot. I found some vandalism/abuse this way.

(B) duplicates, ATYL gone wrong

shop=bäckerei or shop=piekarnia is likely autofixable to shop=bakery

we also have some colour=weiß and other values in German

this is worth fixing but one should not be overenthusiastic, to avoid damaging data (what if something is not an actual duplicate? Or “rot” means different color in a different language and globally editing it to red broke data?

(C) bad data - some can be fixable with bot, but again in some cases it may hide worse problems

That is why I look at landuse=wood and natural=forest one by one, about half of them have much deeper problems.

And I seen person who went with mass edit to remove name=House descriptive name. Removal may make sense on building=house but definitely not on shop=clothes

Overall bot edit may make sense, and there are many that make sense but it is easy to break things this way.
I think we should do more bot edits, but it makes sense only when they are done while actually using brain and person doing them is willing to fix any damage and/or revert edit if it turns out to be wrong.

2 Likes

Take it easy … es geht mir nur um die “Missgeschicke”, also eindeutige Fehler, wie z.B. Tippfehler, Buchstabendreher, Großbuchstaben in Standardwerten und so weiter. Diese treten bei ATYL-Tags naturgemäß wesentlich öfters auf als bei den Standard-Tags, die aus den Presets der Editoren übernommen werden.

I fully agree to all of your comment and I am very much aware that doing such bot cleanups is very tricky and takes a lot of work and time. Frankly spoken I am happy I have no clue how to do that so I can say “sorry, I can’t help with that” without lying and go on mapping instead of investing a lot of time into quality assurance of the database.

I have no doubt we could engage an expert to do database cleanup as a full-time job and he/she would not be able to catch up with the masses of values being typos, wrong language, duplicates etc. or sometimes even simply nonsense.

4 Likes

Danke für diesen wichtigen Punkt. Das ändert einiges! :grinning:

Mir würde das (automatisierte) Aufräumen durchaus Spaß machen. (Hab’ zum Beispiel vor 20 Jahren mit Hilfe von Bots die deutschen Wikibooks aus dem englischen Wiki rausgezogen, das hatte mehrere Monate gedauert.) Aber: Massenedits muss man vorher in der Community diskutieren und auf die Diskussionen habe ich keinen Bock. Also fange ich erst gar nicht damit an.

1 Like