Jewellery Proposal für mehr Datenchaos

Ich habe heute durch die Erinnerung auf der Taggingliste erst bemerkt, dass dieser seltsame Vorschlag den shop=jewelry Tag durch shop=jewellery zu ersetzen ein richtiges Proposal ist und schon gevotet wird.

http://wiki.openstreetmap.org/wiki/Proposed_features/Jewellery_shop

Ich weiß nicht ob es guter Stil ist, gegen ein Proposal zu wettern, dass schon im Voting ist, aber ich bin erstaunt was da passiert. Zusammenfassend:

shop=jewelry (L) soll als deprecated markiert werden und durch shop=jewellery (LL) ersetzt werden. Aus dem Grund, dass der Großteil der der OSM Tags British English (BE) sind. Um das mal deutlich zu machen, die American English (AE) Variante ist über 20.000 mal in der Datenbank vorhanden, die BE Variante gerade 200(!) mal, zum Start des Proposals waren es lediglich 180. Im Proposal selbst steht, dass die Editoren und Auswerter derzeit nur L unterstützen.

Wie ich schon an anderen Stellen gezeigt habe, bin ich sehr für Vereinheitlichung, aber das hier soll imho auf einem völlig unsinnigen Level (Sprachdialekte) passieren. Das wird Null Vorteile bringen, außer dass die Leute vielleicht einen Zufallstreffer haben, wenn sie ohne nachzuschauen oder auf die Vorschläge ihres Editors zu achten, etwas taggen und davon ausgehen dass alle OSM Tags BE sind. Und dann auch nur, wenn sie sich bei den vielen Ls und Es nicht verhaspeln. Dafür müssen über 20.000 Objekte umgetaggt werden, muss das Wiki geändert und Editoren und Auswerter überzeugt werden ihre Programmierung anzupassen.

Das ist doch ein Wahnsinn, der nicht hinhauen wird. Und dann wird nämlich genau das zerstört, was das Proposal angeblich herstellen will. Die Konsistenz der Daten, dann wird es keine so eindeutige Mehrheit eines Tags mehr geben, es wird Auswerter geben die nur LL machen, welche die nur L machen und welche die irgendwann beides rendern. Der Zeitplan hört sich ja schön und gut an, wenn OSM aber so strukturiert geregelt wäre dann hätten wir schon ganz andere Projekte auf den Weg gebracht.

Außerdem frag ich mich, ob es bei einer so dermaßen geringen Beteiligung an dem RFC Prozess überhaupt korrekt ist das Voting zu starten?!

Ich glaube, der Verfasser des Proposals ist selber dagegen, und will lediglich, dass alles “seinen ordentlichen Gang” geht statt dass alle einfach so, ohne dokumentierte Entscheidung, von der BE-Norm abweichen.

Darüber kann man jetzt denken, was man will… bei mir ist es eher ein ungläubiges Kopfschütteln :wink:

Bye
Frederik

wurde irgendwann festgelegt, dass es eine BE-Norm geben muss/soll? Also ja, im Grunde fänd ich es auch schicker wenn das einheitlich wäre, aber im Grunde find ich jewelry auch einfach ein schickeres Wort, da es reduziert und einfacher ist. Aber weder das eine noch das andere rechtfertigt meiner Meinung nach einen solchen Eingriff in den Datenbestand und die Programmierungen.

Bei neuen Tags und Proposals kann man ja auf eine BE Norm achten, aber hier ist der Drops eben schon gelutscht.

Ja, es gibt eine derartige Regel! Sie stammt denke ich noch aus den Zeiten vor allgegenwärtigen Proposals, also gibts wohl keine Abstimmung dazu. Bei fast allen Tags wurde sie ja auch korrekt angewendet und hat sie hat von daher unser Taggingschema maßgeblich mitgeprägt.

Eine solche Konvention ist eine wichtige Merkhilfe für Tags, die man bereits kennt – es geht mir nicht um Zufallstreffer. Einheitlichkeit beim Tagging ist ohnehin etwas, auf das bisher zu wenig geachtet wird. Da sollte man sich doch zumindest an die wenigen bestehenden Regeln halten!

Ich bin jedenfalls für das Proposal (wie die Mehrheit der Abstimmenden vor deinem Post auch). Daher finde ich es schade, dass die erste Erwähnung im Forum so ablehnend ist und dass seither die Abstimmung gekippt ist. Gerade durch die enthaltenen Vorschläge zur Strukturierung des Umstiegs wäre es auch ein interessanter Test dafür, wie Änderungen am Taggingschema koordiniert werden könnten. Denn es ist eigentlich nicht tragbar, wenn wir als Projekt nicht imstande sind, einmal gemachte Fehler – seien sie groß oder klein – zu korrigieren.

Daher möchte ich auch diejenigen, die auf diesen Thread hin bereits abgestimmt haben, bitten, für weitere Argumente offen zu sein.

Ich tendiere dazu, das Proposal abzulehnen. Es bringt nur einen unnötigen Mehraufwand für alle (Mapper, Editor-Entwickler und Datennutzer) mit sich, aber keinen Vorteil außer ein L mehr und die Verwendung von BE.

Ich lehne gewöhnlichweise auch Vorschläge ab, die nur des Umbenennens wegen umbenennen wollen, ohne einen Mehrwert mitzubringen. Ich möchte hier nicht von meinen Prinzipien abweichen, weil das sonst meiner Glaubwürdigkeit schadet

Andererseits habe ich auch schon einen mechanischen Edit (das mit den Eisenbahnsignalen vor etwa einem halben Jahr) durchgedrückt, der mit diesem Proposal vergleichbar war.

Sollte dieses Proposal Zustimmung erlagen, ist es nur noch eine Frage der Zeit, bis irgendjemand einen mechanischen Edit durchführt. Wahrscheinlich wieder ohne vorherige Diskussion, sodass er revertiert werden muss. Und ein halbes Jahr später kommt der nächste Depp und macht es wieder. Bei Hydranten ist das schon zwei- oder dreimal passiert. Das muss eigentlich nicht sein. (Vielleicht sollten wir aber auch einfach mehr Werbung für die entsprechenden Richtlinien machen, damit sich mehr Mapper der Richtlinie bewusst sind)

Ich habe noch nicht abgestimmt. (Die Stimmabgabe von Peda (ja) und woodpeck (neutral) hat mich derart überrascht, dass ich etwas Bedenkzeit brauche)

EDIT: Sprachfehler korrigiert

Ich würde mal behaupten, dass viele das überhaupt nicht mitbekommen haben, unter anderem fehlte auch eine Erwähnung in der Wochennotiz (zumindest über das Proposal und start des Votings etc.). Daher vielleicht auch die bisherigen Votes. Ich finde, dass die “Werbung” und beteiligung bisher viel zu gering war um ein solches Proposal durchzuziehen.

Einheitlichkeit beim Taggen ja, bei neuen Tags ja auch gerne, wenn wir zwei Tags haben de doppelt vorkommen und man sich darum für eins entscheiden muss würd ich auch sagen, nehmt meinetwegen das einheitlich Britische, auch wenn AE überwiegen sollte. Aber hier kommen Tags nicht doppelt vor. Bei einem Unterschied von 1:100 sind die BE Varianten keine wirkliche Alternative in der DB.

Hehe. Ich fand es bisher immer recht toll, dass wir mit der BE-rule eine “einheitlich” Sprache verwenden. Wir hatten ja schon einige Proposals, die nochmal geändert wurden oder abgelehnt wurden weil sie AE statt BE verwendeten und es gibt zig Beispiele dafür (center vs centre, Benennung der Highway-Tags usw. usf.). Ich seh das im Fall von Jewellery eher unemotional, finde aber die BE-rule generell wichtig damit wir am Ende nicht height in Meter und width in Inch angeben. Daher hab ich auch dafür gestimmt und stehe dazu :slight_smile:

ok, wie gesagt ich find solche konventionen ja in Ordnung, aber hier ist das Kind irgendwie schon in den Brunnen gefallen.

Es handelt sich ja nicht um ein völlig anderes wort, wenn ich im editor mit jew… anfange kommt ja schon die richtige Entsprechung. Ich finde Regeln als Richtlinien gut, aber nicht wenn sie nur um der Regeln willen angewand werden. Das ist so wie der Wachmann der mir sagt, is verboten weil eben verboten is und nicht weiß warum.

Dann sollten wir uns aber lieber um wirkliche Fehler kümmern die auch ne Problem verursachen und nicht ein Problem verursachen weil wir uns um einen halb-Fehler kümmern.

+1, Fairness sieht anders aus.
Man kann auch neutral auf Proposals hinweisen.

Dass das nicht wirklich geschehen ist, ist ja nicht meine Schuld. Hab ja selbst gesagt:

Also klar, schön ist das so nicht, aber ich kann ja auch nicht meine eigene Meinung dazu verheimlichen. Ich find es problematisch, dass jetzt schon eine WOche Voting vergangen ist, ohne dass der RFC richtig diskutiert wurde.

das wäre dann ja ein Beispiel dafür, das hier ein wirkliches Problem existiert

Das Proposal ist knapp gescheitert.

Wobei ich 3/4 Mehrheit schon sehr streng finde.
Man sollte mal ein Proposal machen, dass 2/3 Mehrheit reicht. :wink:

ja ich find das auch nicht so glücklich, obwohl ich sehr gegen dieses Proposal war. Aber jetzt ist die Situation dadurch nicht besser geklärt, ich hatte eigentlich auch schon angefangen einen Thread dazu zu schreiben. Ich hätte lieber gesehen (und eigentlich auch erwartet), dass das Proposal eindeutig scheitert, oder wäre gespannt auf das Resultat gewesen, wenn es erfolgreich gewesen wäre. Meine Erwartung ist ja, dass das nie richtig umgesetzt worden wäre und das Problem dann noch vergrößert worden wäre.

Aber so ist es wirklich nur aufgeschoben bis zum nächsten Tag… (erkennt jemand die doppeldeutigkeit ;))