[abgelehnt] Tag-Proposal-Abstimmung Default Language Format

Nakaner · 2018-10-18T19:28:05.000Z

Hallo,

über das oben genannten Proposal kann bis zum 29. Oktober 2018 abgestimmt werden. Da es auf den ersten Blick recht kompliziert aussieht und es anscheinend mehrere Interpretationsweisen zu geben scheint, würde ich mich freuen, wenn sich andere die Zeit nehmen würden, es durchlesen und ihre Wahlempfehlung aussprechen würden.

Viele Grüße

Michael

EDIT: "[abgelehnt] " im Titel eingefügt

Prince_Kassad · 2018-10-18T19:55:00.000Z

Worum es m. E. geht: der Proposer will name= langfristig komplett aus der Datenbank tilgen.

Der Grund dafür ist folgender: in mehrsprachigen Regionen (Südtirol) und noch viel mehr außerhalb der industrialisierten Welt (Nepal) herrscht ein heilloses Chaos, welche Sprache für name= verwendet werden soll. In Südtirol etwa wird in name= der Name auf Deutsch und Italienisch geschrieben - getrennt durch einen Bindestrich. In Nepal und dort vor allem im Himalaya kommt alles mögliche vor, sogar Englisch (ist dort nirgends Amtssprache!).

Mit default:language soll nun für jedes Objekt festgelegt werden, welche Sprache am Ort des Objekts vorrangig gesprochen wird, damit der Renderer den Namen nur noch einsprachig rendern muss, nämlich entweder in der Sprache, die der Benutzer bevorzugt, oder alternativ in der Standardsprache.

Meine ehrliche Meinung dazu: der Vorschlag ist gut gemeint, taugt aber nicht als Tag an einzelnen Objekten. Ich sehe schon Grabenkämpfe in Städten wie Brüssel kommen, ob dort nun Französisch oder Flämisch die meistgesprochene Sprache ist. Wir brauchen wirklich nicht noch mehr Brandherde als OSM eh schon hat (gerade bei umstrittenen Territorialansprüchen, um die dann auch “virtuell” gekämpft wird). Auch in autoritäten Ländern wie China wird es sehr lustig werden, wenn dort Minderheiten wie Tibeter und Uiguren um die Vorherrschaft kämpfen. Nein Danke. Der Vorschlag, einfach mehrere Standardsprachen per Semikolon abzutrennen, damit der Renderer dann die entsprechenden Werte zu einem String kombiniert, funktioniert schon bei anderen Eigenschaften nicht, und hier auf einmal soll das klappen? Und natürlich kann es auch hier zu Grabenkämpfen kommen, ob z. B. Tibetisch in China bedeutend genug ist um als “Standardsprache” zu gelten.

streckenkundler · 2018-10-18T20:38:04.000Z

Hei,

wenn ich z.B. dahingehend nur meine heimatliche Lausitz betrachte mit den beiden sorbischen Sprachgebieten könnte ich sagen “Ja… damit könnten die Rendering-Probleme gelöst werden…” In meinen Augen ist das aber recht egoistisch… Hier ist es gesetzlich recht gut gelöst, was zum jeweiligen sorbischen Sprachgebiet gehört, und was nicht. In anderen Regionen der Welt könnte ich da durchaus schon größere Problem erahnen…

Ich hab mir abschließend noch keine Meinung gebildet… Ich sehe es aber so, daß es nur in irgend einer Form einer Abgrenzung funktionieren kann, der Ansatz, da Admin-Grenzen nachzunutzen, ist erst mal nicht schlecht, könnte aber auch dazu führen, daß bestimmte Gebiete administrativ weiter geteilt werden, wo es nicht nötig ist, um eventuell sprachliche Grenzen abzuteilen.

Please do not create new boundaries that do not have official recognition. These tags should only be placed on verifiable administrative boundaries, boundaries declared by the government (including indigenous lands), or on individual features as described above.

Das funktioniert meiner Ansicht nach nicht, man sollte zur Überprüfung eine hinreichend valide, am besten über amtliche Angaben nachvollziehbare Grenze haben… (ok, in einigen Teilen der Welt durchaus eine Wunschvorstellung), die man andererseits auch gleich als entsprechende Grenze der Mehrsprachigkeit heranziehen kann.

Es ist ja noch etwas Zeit…

Sven

imagico · 2018-10-18T21:04:27.000Z

Ich glaube Prince Kassad sieht das genau falsch herum. Das ‘friss oder stirb’-Konzept hinter dem name=* ist die Ursache für Grabenkämpfe. Die Idee genau diese Quelle von Konflikten durch eine flexiblere Methode, Namen in verschiedenen Sprachen und ihre Funktion zu erfassen, zu ersetzen ist m.E. sehr gut (sie stammt ja in gewisser Hinsicht auch von mir ;-)). Die einzelnen Namen sind ja meist unstrittig, umstritten ist höchstens ihre spezifische lokale Funktion. Das beides zu trennen ist folglich nahe liegend.

Das Ganze ist am Ende natürlich ein enormes Unterfangen, welches nur dann eine Chance auf Erfolg hat, wenn es weitreichende Unterstützung von Editoren- und Kartenstil-Entwicklern erhält. Und selbst damit wird es viele Jahre dauern, bis das umfassend in den Daten umgesetzt wird. Es gibt 65 Millionen name-Tags und die zehn häufigsten name:-Tags zusammen sind im Moment nur etwa 1/10 so viel.

Die ganze Idee ist eigentlich nicht wirklich kompliziert, hat aber für eine Tagging-Idee einen etwas untypischen Grad an Abstraktion und das Proposal ist nicht wirklich gut darin, dies auf den Punkt zu bringen und es gibt im Detail einige Unklarheiten, was genau die praktische Bedeutung des vorgeschlagenen Tags ist. Aber der Kern ist die Idee der Trennung der Erfassung der einzelnen Namen in verschiedenen Sprachen und der Erfassung der Information darüber, welche dieser Namen ggf. in welcher Form die lokal dominierende Form der Benennung sind. Diesen Kern umzusetzen wäre ungeachtet der genauen Details der Implementierung drumherum etwas, was für OSM ein enormer Gewinn wäre. Ob die Zeit dafür reif ist wird man sehen müssen.

Was auch wichtig ist im Auge zu behalten: Kein Datennutzer wäre mit diesem Konzept gezwungen, die in OSM erfassten Informationen zur Default-Sprache tatsächlich zu nutzen. Aber im Gegensatz zur nicht-Nutzung des derzeitigen name=*, welche natürlich auch möglich ist, kann der Datennutzer zuverlässig damit rechnen, dass die einzelnen Namen in den einzelnen lokal verwendeten Sprachen auch tatsächlich individuell erfasst sind - denn sie wären dann ja auch für die normale Namens-Darstellung auf Basis des erfassten Defaults notwendig.

Mammi71 · 2018-10-18T21:19:41.000Z

Ich sehe das Vorhaben kritisch. Um bei den Beispielen Südtirol und Lausitz zu bleiben: meine default language wird sicher deutsch sein. Wenn ich aber in der Lausitz oder in Südtirol Urlaub mache, möchte ich sehr wohl beide Namen angezeigt bekommen, ohne meine default-Einstellung ändern zu müssen. Und auf den Ortseingangsschildern steht - wenn ich mich recht erinnere - auch beides drauf.

J_budissin · 2018-10-19T07:24:56.000Z

Da habe ich zunächst einmal eine Verständnisfrage: In den angesprochenen Regionen wäre dann – zumindest dort, wo das offiziell zutrifft – also der Wert für default language z.B. “de;it” oder “de;hsb”? Das würde zumindest dem Renderer einen klaren Auftrag erteilen und die Behelfslösung mit “de - hsb” nicht mehr nötig machen.

Wenn dem so sein sollte, habe ich da kein Problem. Wichtig ist nur, dass die Standardausgabe in zweisprachigen Regionen zweisprachig ist – es sei denn, es wird explizit eine einsprachige italienische, deutsche oder sorbische Karte angefordert.

glglgl · 2018-10-19T08:07:38.000Z

Vielleicht sollte die “default language” nicht an den einzelnen Objekten festgemacht werden, sondern über default-Relationen definiert werden. Diese sind zwar noch nicht arg weit verbreitet, aber es gab da letztens einen neuen Proposal. Ich denke, darüber könnte da was gedreht werden.

Nachteil wäre allerdings, man müsste dann immer nachschauen, in welcher geografischen Entität das Objekt dann liegt, und sich darüber dann hochhangeln.

miche101 · 2018-10-19T08:14:08.000Z

glglgl:

Vielleicht sollte die “default language” nicht an den einzelnen Objekten festgemacht werden, sondern über default-Relationen definiert werden.

So wie das verstehe soll das an Admingrenzen Landes-/Regions-/Gemeindegrenzen:

Administrative boundaries: Relation with type=boundary and boundary=administrative, admin_level=2 to 10 or 11

kreuzschnabel · 2018-10-19T08:21:46.000Z

miche101:

So wie das verstehe soll das an Admingrenzen Landes-/Regions-/Gemeindegrenzen:

Wäre sinnvoll. Kann man natürlich auch kleiner granulieren. Aber an jedem Briefkasten die default-Language dranzutaggen … wozu haben wir eine geospatiale Datenbank? Da können wir ja gleich zum is_in=* zurück, dann tut’s auch ne einfache Tabelle

–ks

J_budissin · 2018-10-19T11:10:01.000Z

glglgl:

Vielleicht sollte die “default language” nicht an den einzelnen Objekten festgemacht werden, sondern über default-Relationen definiert werden.

Wäre zumindest in den hier genannten Beispielen auch kein Problem. In Sachsen und Brandenburg z.B. ist das offiziell zweisprachige Gebiet klar definiert und streckenkundler hat da zumindest für die Niederlausitz auch schon eine Relation gebastelt.

Nakaner · 2018-11-02T14:51:49.000Z

Das Proposal hat 9 Ja- und 15 Nein-Stimmen erhalten und gilt somit abgelehnt. Es wären bei der Anzahl an Stimmen maximal 25 % Ablehnungen erlaubt, um als akzeptiert zu gelten.