Zweisprachige Namen im Siedlungsgebiet der Sorben/Wenden reloaded

@J busissin: ich meinte nur die Karte. GraphHopper selbst liest aktuell nur das name tag: https://github.com/graphhopper/graphhopper/issues/259

Aber genau das meine ich: nur weil die meiste Software aktuell noch limitiert ist, sollten wir nicht für diese Karten- oder Routenplanersoftware die Datenbank falsch füttern, weil es der ‘korrekten’ Software dann das Leben schwer bzgl. unmöglich macht.

Ich meine aber, daß es aber datentechnisch keine saubere Lösung ist, vor allem bei Namen ist, alles in einen Wert zu schreiben. Das ist für mich Sache des Renderers. …
Man muß aber immer im Hinterkopf haben, daß OSM eine Geodatenbank ist.

Danke & Genau :slight_smile: !

Dazu eine Anmerkung: Lübben/Lubin und Calau/Kalawa sind ab sofort Teil des amtlichen Siedlungsgebietes und müssten dementsprechend ergänzt werden: http://www.rbb-online.de/politik/beitrag/2016/04/luebben-und-calau-offiziell-sorbisches-siedlungsgebiet.html

Postrow/Gruß,
j.

Ah… Sehr schön…

Ich schaue mal was das Amtsblatt Brandenburg sagt und passe die Grene Zeitnah an…

Sven

Dobry wjacor!

so… Gemeinden Lübben, Calau und Wiesengrund zur Relation https://www.openstreetmap.org/relation/6001479#map=10/51.7338/14.2496&layers=N hinzugefügt… mal sehen, welche noch hinzu kommen…Es gibt ja noch ein paar Kandidaten.

Quelle: http://service.brandenburg.de/lis/detail.php/bb3.c.279168.de und http://www.mwfk.brandenburg.de/media_fast/4055/PM%2038%20Siedlungsgebiet%20Sorben.pdf

Postrow/Gruß,

Sven, der leider aber kein sorbisch kann.

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 … :slight_smile:

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 :slight_smile: ? 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 :slight_smile:

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 :wink:

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