Nach allem, was ich von den Verhandlungsfortschritten mitbekomme, sollte es das erstmal gewesen sein. Die anderen Gemeinden werden sich vermutlich dagegen entscheiden.
Was anderes: Gab es nicht mal eine Möglichkeit, sich grafisch darstellen zu lassen, wo überall name:hsb-Tags vorhanden sind? Ich meine, mich daran zu erinnern.
overpass turbo wäre geeignet: Für ein kleines Gebiet kann man sich auch alles ausgeben lassen, bei grösseren Gebieten sollte man vielleicht ein bisschen filtern, z.B. nur place=* oder natural=peak.
Ich habe mal ein wenig was zusammengeschrieben…
http://overpass-turbo.eu/s/fPr (Achtung: durch die Grenze dauert die Abfrage etwas)
abgefragt werden alle place-Nodes innerhalb der Grenze des annerkannten sorbischen Siedlungsgebietes und die nicht place=locality sind. Warum die Place-Nodes um Lübben und Calau fehlen, weiß ich nicht, evt. hängt das damit zusammen, daß ich die Grenze ja erst kürzlich aktualisiert habe.
die Farben:
hellblau mit dunkelbauen Rand: vorhanden: name=, name:dsb=, name:hsb=; nicht vorhanden: name:de
rot: vorhanden: name=; nicht vorhanden: name:dsb=, name:hsb=, name:de
schwarz: vorhanden:name=, name:dsb=; nicht vorhanden: name:hsb=, name:de
orange mit rotem Rand: name=, name:hsb=; nicht vorhanden: name:dsb=, name:de
blau: vorhanden: name=, name:hsb=, name:dsb=, name:de
braun: vorhanden: name=, name:dsb=*, name:de; nicht vorhanden: name:hsb
Schwarze Umgrenzung: “anerkanntes sorbisches Siedlungsgebiet”
Leider habe ich Textboxen nicht hinbekommen, die entweder nur name:dsb oder name und name:dsb anzeigen.
Sven
node[!name][!name:de][!name:hsb]
[name:dsb]
{
symbol-size:6;
color:green;
fill-color:green;
width:1;}
node[!name:de][!name:hsb]
[name][name:dsb]
{
symbol-size:6;
color:red;
fill-color:green;
width:1;
}
(nur) name:dsb ist (noch) vernachlässigbar, da es da nix gibt.
http://overpass-turbo.eu/s/fPA
Das ganze mal etwas übersichtlicher (im Code) um Redundanzen eingekürzt und name+name:dsb ergänzt.
edit: sehe grad, dass das schon drin war, nur andere Farbe …
Da hab ich mich missverständlich ausgedrückt… mit text:name erscheint der Wert des name-Tags permanent. Ich will aber den Wert in name:dsb permanent anzeigen. Vergleiche auch mein Extra-Beitrag: http://forum.openstreetmap.org/viewtopic.php?id=54410
Sven
In deiner Abfrage ist noch ein Fehler drin, da fehlt bei der Relation der Name.
Du meinst oben, im Abfrageabschnitt…?
Ja, stimmt… ist aber z.Z. die einzige Grenze, die so ist…
Mir fehlen aber noch ein paar MapCSS - Beispiele.
Sven
Nöö, zoom einfach mal bisschen raus … 
Hier mal ein Blick über den Tellerrand des deutschen Michels, insbesondere die Regelungen in Südtirol scheinen mir - angesichts der historisch belasteten Situation - doch sehr pragmatisch.
http://wiki.openstreetmap.org/wiki/Multilingual_names#Alto_Adige.2FS.C3.BCdtirol_.28South_Tyrol.29
Gruß
Klaus
Also wie schon oben gesagt: das erschwert es der Software das multilinguale Darstellen etc umzusetzen und zweitens, warum ist das Deutsche an erster Stelle und nicht an zweiter 
? Evtl. wird ja Deutsch doch bevorzugt? Also wenn man solche ‘Konflikte’ mit in die GeoDB reinholen will, kann man das machen. Aber ‘pragmatisch’ ist das garantiert nicht, man könnte auch inkonsequent sagen
Und Regeln wie die hier machen das ganze dann quasi unmöglich für jede nutzende Software die z.B. nur DE ausspucken soll:
Also mein Argument ist hauptsächlich: warum nicht alle Fähigkeiten der DB auch dafür nutzen und die Daten normalisieren? Und die Tools zum Editieren, Visualisieren und Routen sind davon komplett losgelöst. Aber diese Debatte sollten wir wahrscheinlich noch etwas energischer & länger führen da das schon wichtig für die Zukunft von OSM ist (IMO). So wie auch hier beschrieben, wenn auch in einem anderem Kontext: https://karussell.wordpress.com/2015/11/01/units-in-openstreetmap/
Ja, von der Mehrheit der Einwohner dieser Gemeinde. In der Nachbargemeinde kann es andersrum sein. Dass ein italienische Name dabei sein muss, steht im Autonomiestatut, die Reihenfolge steht dort nicht. Deshalb …
Ich finde, für uns wäre es pragmatisch, die Leute da draussen in der echten Welt den Schilderstreit führen zu lassen und einfach das Ergebnis zu übernehmen. Das entlastet uns eher von den Konflikten, finde ich. Jedenfalls die Menschen, die Datenbanken nicht…
Mit automatischen Umrechnen von Fuß in Meter ist das schwer vergleichbar. Ob der Betrachter einer Karte lieber metrische Angaben mag, kann man ihn einstellen lassen oder raten. Wie die lokale Bevölkerung ihren Ort nennt, ist schwer zu sagen. Dafür bräuchten wir entweder ein Tag, das uns den “Ortschildnamen” (für Router: “Wegweisernamen”) aus name:xx zusamenbasteln lässt, oder wir tragen Regionen ein und legen für die fest, welche Sprachen dort bevorzugt werden (entweder per Einzelfallentscheidung anhand politischer Grenzen “in Südirol reicht deutsch”, oder mit diesen Sprachregionen, die Streckenkundler gerade malt). Ich glaube aber nicht, dass sich Regionen durchsetzen werden, bei jedem Namen eine geometrische Abfrage durchzuführen, wird nicht beliebt werden.
Ansonsten bleibt uns nur die Orientierung an der Zielgruppe (“wir nehmen immer metrische Angaben und name:de”), dann kommt sowas wie der deutsche Stil raus, bei dem wir uns dann wieder darum streiten, ob name:de nicht zu revisionistisch klingt 
Grüße, Max
Also ich meinte folgendes: OpenStreetMap ist die Geodatebank, die im Idealfall normalisierte und separate Daten speichert (multilinguale Namen, Zahlen, Einheiten). Und die Editor-Software schafft einen Layer wo man als normalo Mensch / Mapper diese DB benutzt. Aktuell nutzt man ja quasi direkt die rohe DB und das verleitet dann zu solchen komischen Lösungen wo dann zwar der Mapper checkt was los ist* aber es für die Software schwierig wird. Aber eine DB ist dafür da das Software die Daten darin leicht verarbeiten kann und nicht für Menschen.
(* “DE kommt hier zuerst, aber hier als Zweites im Name” oder “Bindestrich steht hier für das Trennungszeichen der Sprachen, aber hier für den Teil des Namens”)
Sowas?
name:de=Cottbus
name:dsb=Chóśebuz
name:hsb=Choćebuz
name:lt=Kotbusas
name:official_lang=de;dsb
name:official_lang:delimiter=/
name:most_common_lang:de
Von einem recht theoretischen Standpunkt aus gesehen schon schön …
Das Problem besteht nur, wenn man versucht, ein name:de aus name=* herauszuholen. Wenn es einen name:de gibt, sollte man doch den nehmen.
Der Ausweg wäre also, erstens konsequent alle Sprachversionen in name:xx zu taggen, ggf. sogar in anderer Schrift, und zweitens vorhandene “name=”-Einträge entweder unverändert zu übernehmen oder (für sprachspezifische Anzeige) zu ignorieren.
Dann gerät man auch nicht in Gefahr, sich in die Nesseln lokaler Empfindlichkeiten zu setzen.
Die übliche Praxis (z.B. Mapnik) nimmt zuerst name=* und daher der Anreiz, da alles reinzupacken.
+1
Außer in Bozen und einigen Gebieten im unteren Eisacktal südlich davon, ist Südtirol überwiegend deutschsprachig bzw. im Val Gardena ladinischsprachig, siehe Grafik lt. Zensus-Daten in dem in #50 verlinkten Wiki-Artikel http://wiki.openstreetmap.org/wiki/File:Language_distribution_in_South_Tyrol,_Italy_2001.png
Zur Reihenfolge der Sprachen gibt es in Südtirol die Konvention, die lokal dominante Sprache in name=* zuerst zu setzen - wie auf den Straßenschildern!
In name=* werden alle amtlichen Sprachen deutsch - italienisch (und ggf.) - ladinisch abgebildet. Zusätzlich wird name:de, name:it und name:lld erfasst.
Gruß
Klaus
Eben… Das setzt aber voraus, daß die Editor-Software weiß, welche in diesem Fall name-Tags sie darstellen soll…
Wir habe doch die ganzen name:xy=* Tags… Wenn ich nun für Südbrandenburg eine Grenze erstellen würde, die aussagt: ‘Das ist die offizielle zweisprachige Grenze mit name:de und name:dsb’, dann gebe ich dem Renderer das notwendige Mittel dazu, dann kann ein Renderer genau für diesen Bereich die Namen entsprechend rendern und muß nicht Tags dazu verbiegen. Daß es für angrenzende Orte außerhalb dieser Grenze auch einen Namen in der betreffenden Sprache gibt ist da erst mal unerheblich.
Sven
Ah, okay. Also mit dem Kompromis kann ich leben. Auch wenn das Datenduplikation ist und m.E. weniger Sinn macht.
Meran ist da übrigens weiße Fläche.
Das ist mMn der einzig gangbare Weg in Gebieten mit mehreren Amtssprachen. Ich hätte sogar nichts dagegen, name=* dann wegzulassen, aber da spielen die meisten Anwendungen nicht mit. Dann fiele nur die Information weg, was offizielle Namen sind. Damit muss man das arme name=*-Tag aber nicht unbedingt überladen.
Weil die Sprachgruppenverteilung dort 50/50 beträgt, sehr kleingedruckte Fußnote unter der Legende.
