[Talk-de] "Sprache des Namens" Fehler in Kort.

[Stefan Keller]

Lieber Martin

Am 19. Juni 2013 10:25 schrieb Martin Raifer <tyr.asd at gmail.com>:
> danke für deine Antwort. Vielleicht habe ich mich bei dem einen oder anderen
> Satz etwas zu stark ausgedrückt. Meine Gesamtaussage aber bleibt, dass Kort,
> wie es sich zur Zeit präsentiert, in mehrsprachigen Regionen unspielbar ist.
> Und das ist schade.

Danke für deine Ausführungen; jetzt verstehe ich's besser. Mir ist
bewusst, dass es Häufungen von einem "Fehler" geben kann. Mengenmässig
sind weltweit gesehen wohl nur wenige Gebiete betroffen. Trotzdem
braucht es Verbesserungen, wie du sie u.a. unten vorschlägst.

> Ich komme aus Südtirol, eines der wenigen Gebiete in Europa, die "echt
> mehrsprachig" sind.

Dass es "echte" mehrsprachige Gebiete gibt, ist mir als Schweizer
klar, wenn ich u.a. an Fribourg/Freiburg, Teile von Wallis und
Graubünden oder Biel/Bienne denke. Im Kanton Fribourg/Freiburg
entscheiden z.B. Gemeinden autonom, ob nun deutsch, franz. oder beides
gilt). Oft ist dann immer noch unklar, welche Sprache zuerst
geschrieben werden soll (und eine Regelung für Newline-Zeichen gibt es
bei OSM-Tags meines Wissens nicht)!

Wie Peter Wendorff schrieb, geht es hier nicht primär darum,
zusätzliche Übersetzungen anzugeben. Beim name-Tag geht es um mehrere
Aspekte, das letztlich in einem geografischen Namens-Schema
abgehandelt und dokumentiert werden müssten:

1. Im name-Tag steht das was gemäss on-the-ground-Regel draussen zu
sehen ist - und das was offizell und per Default auf der
(Landes-)Karte angezeigt werden soll. Das sollte sich mit der
offiziellen Schreibweise decken (sog. Endonyme, vgl. Wikipedia). Das
kann mitunter auch eine chinesische Schrift sein - oder aber eben eine
"echt" mehrsprachige Bezeichnung wie "Biel/Bienne". Für alle weiteren
Fälle wird der name:XX-Tag verwendet.

2) Mit Blick auf (Welt-)Karten, die z.B. für uns Europäer lesbar sind,
braucht es Exonyme, d.h. für uns lesbare geografische Namen, z.B. für
asiatische Gebiete.

3) Mit Blick auf mehrsprachige Karten sollte eine Software erkennen
können, in welcher Sprache der Name nun gilt.

4. Ausserdem gibt es eine Aussprache von Orten, wie sie inoffiziell,
mundartlich oder historisch von Einheimischen verwendet werden (z.B.
name:gsw=Rapperschwil für Rapperswil, vgl. nominatim).

Es macht daher für mich Sinn, für alle geogr. Namen einen name:XX-Tag
anzugeben auch bei mehrsprachigen name-Tags.

Der Keepright-Fehlertext heißt sinngemäss "Wenn der name-Tag
existiert, wäre es schön (nicht notwendig), wenn ein name:XX-Tag
existierte.". Bei mehrsprachigen Namen gibt es hier nun tatsächlich
ein Problem, dass Kort zurzeit fragt "In welcher Sprache ist der Name
"nnn* geschrieben? (de, fr, etc.)" und dann den Tag "name=nnn" nimmt
und ihn als "name:de=nnn" speichern will.

Für Kort scheint mit da ein "nicht lösbar" immer noch die beste
Antwort. Eine korrekte (Teil-)Lösung wären zwei (bzw. mehrere)
name:XX-Tags. Eine Lösung, wie man in OSM angeben könnte, wo das es
eine offizielle Ein- bzw. Mehrsprachenregelung gibt (wenn denn es eine
gibt), könnten Sprach-Multipolygone sein, doch gibt es meines Wissens
dazu noch keine Diskussion. Jochen Topf mit seiner  Multilingual Map
(http://mlm.jochentopf.com/ ) hat sich dazu ev. einige Überlegungen
gemacht.

Zu deinen Verbesserungsvorschlägen:

> 1. Eine Möglichkeit bestimmte Fehlerkategorien auszublenden und stattdessen
> andere Aufträge anzuzeigen.

Ausgezeichnete Idee. Das leite ich gleich an die Kort-Developpers weiter.

> 2. Immer einen ausgewogenen Mix an Aufträgen anzeigen, z.B. durch das
> bewusste Zurückhalten von Aufträgen einer Kategorie ab einer festgelegten
> maximalen Dichte.
>
> 3. Nie Aufträge stellen, von denen man weiß, dass diese nicht immer sinnvoll
> sind. Vor allem dann nicht, wenn man weiß, dass der "nicht lösbare" Teil
> lokal gehäuft vorkommt. Keine "Warnungen" als "Fehler" verkaufen!

Was nun als "Fehler" gilt und was eine Warnung oder gar irrelevant
sein soll, machmal eine Definitionsfrage.
 Solange es keine "(Mehr-)Sprachgebiete" gibt (wie oben
vorgeschlagen), "weiss man" nicht, was nun gilt.
Eine Dichte-Analyse scheint zwar spannend, ist aber für mich in keinem
Verhältnis von Aufwand und Ertrag, die es betrifft.
Dafür könnte das Fehlerkategorien-Ausblenden eine Abhilfe sein.

> 4. Zusammenarbeit mit dem Hersteller der verwendeten
> Qualitätsicherungssoftware (hier: keepright) zur Verbesserung der Qualität
> der zur Verfügung gestellten Daten.

Wir haben schon mehrmals mit Harald Kleiner kommuniziert. Ausserdem
haben wir dank der EOSMDBOne-DB neu die Möglichkeit, selber
Fehlerdaten zu extrahieren.

> Für diesen speziellen Fall: Ich habe
> bereits mit multilingualen Namen experimentiert und habe auch konkrete
> Ideen,

Das klingt interessant. Ich nehme an, die Diskussion wird hier auf
Talk-de stattfinden?

LG, Stefan



Am 19. Juni 2013 10:25 schrieb Martin Raifer <tyr.asd at gmail.com>:
> Lieber Stefan,
>
> danke für deine Antwort. Vielleicht habe ich mich bei dem einen oder anderen
> Satz etwas zu stark ausgedrückt. Meine Gesamtaussage aber bleibt, dass Kort,
> wie es sich zur Zeit präsentiert, in mehrsprachigen Regionen unspielbar ist.
> Und das ist schade.
>
> Ich erkläre noch einmal etwas ausführlicher wieso ich das denke und führe
> danach ein paar Lösungsvorschläge an:
>
> Ich komme aus Südtirol, eines der wenigen Gebiete in Europa, die "echt
> mehrsprachig" sind. Und zwar sind hier Deutsch, Italienisch (und regional
> Ladinisch) gleichberechtigte Sprachen.[1] Hier sind alle Ortsnamen und
> Straßennamen(!), aber auch Namen von Bushaltestellen, Schulen, Wäldern,
> Berggipfeln, Flüssen, usw. zwei- oder dreisprachig. Manchmal sogar
> Restaurants o.Ä.
> Zur Zeit gibt es in OSM in Südtirol über 8.300 Objekte mit multilingualem
> Namen; (wobei ich aber aus eigener Erfahrung weiß, dass bei Weitem noch
> nicht alle Namen korrekt mehrsprachig erfasst sind).
> Daraus folgt, dass aktuell in Südtirol heute ca. 8.300 solcher, per
> Definition "nicht lösbare" Aufträge existieren. Das heißt, dass hier bereits
> jetzt über 30.000 Benutzerinteraktionen (als unlösbar markieren + je 3
> Verifikationen) benötigt werden ohne auch nur ein einziges Bit an
> Information zu gewinnen. Und bei jedem neu hinzugefügten POI, bei jeder
> aktualisierten Übersetzung und sogar beim Splitten eines Wegs fängt das
> Ganze von vorne an.
> Aber meiner Meinung nach am Schlimmsten ist, dass durch die schiere Menge an
> solchen "unlösbaren" Aufträgen sehr schnell die Lust am Spielen vergeht.
> z.B. sehe ich hier [2] in der unmittelbaren Umgebung 20 "nicht lösbare"
> Aufträge und nur einen einzigen sinnvollen Task (und das liegt nicht daran,
> dass hier Alles so gut gemappt ist - im Gegenteil gäbe es hier eine ganze
> Reihe von POIs ohne Namen, Straßen ohne maxspeed, o.Ä.). Sobald ich den
> einzigen sinnvollen Auftrag abgearbeitet habe, muss ich mindestens 20 mal
> auf "Beantworten->Nicht lösbar" klicken, in der Hoffnung, dass es noch
> weitere sinnvolle Aufträge gibt. Das macht mir keinen Spaß! Und ein Spiel
> ohne Spielspaß halte ich für unspielbar.
>
> Ich hoffe man versteht jetzt das Problem besser. Möglicherweise ist ein Teil
> des Problems sogar noch allgemeiner und nicht nur auf diese spezielle Art
> von Auftrag beschränkt. Z.B. könnte ich mir vorstellen, dass immer dann,
> wenn ein Gebiet von einer einzelnen Fehlerkategorie "dominiert" wird, sehr
> schnell der Spielspaß verloren geht und zwar aufgrund von mangelnder
> Abwechslung beim Spielen (oder weil man, aus welchen Gründen auch immer, an
> diesem Fehlertyp persönlich nicht interessiert ist).
>
> Hier ein paar Denkanstöße zur Verbesserung des Spiels:
>
> 1. Eine Möglichkeit bestimmte Fehlerkategorien auszublenden und stattdessen
> andere Aufträge anzuzeigen. (Das ist aber nur bedingt hilfreich, weil ein
> Neuling im Spiel wahrscheinlich gleich alle Fehler angezeigt bekommt und
> dann unter den oben beschriebenen Umständen zu schnell die Lust am Spiel
> verliert.)
> 2. Immer einen ausgewogenen Mix an Aufträgen anzeigen, z.B. durch das
> bewusste Zurückhalten von Aufträgen einer Kategorie ab einer festgelegten
> maximalen Dichte.
> 3. Nie Aufträge stellen, von denen man weiß, dass diese nicht immer sinnvoll
> sind. Vor allem dann nicht, wenn man weiß, dass der "nicht lösbare" Teil
> lokal gehäuft vorkommt. Keine "Warnungen" als "Fehler" verkaufen!
> 4. Zusammenarbeit mit dem Hersteller der verwendeten
> Qualitätsicherungssoftware (hier: keepright) zur Verbesserung der Qualität
> der zur Verfügung gestellten Daten. Für diesen speziellen Fall: Ich habe
> bereits mit multilingualen Namen experimentiert und habe auch konkrete
> Ideen, wie man die "language unknown" Kategorie verbessern könnte (und habe
> diese dem Macher von keepright auch schon mitgeteilt). Leider habe ich
> selbst weder genügend zeitliche noch technische Ressourcen um mich selbst um
> diese Verbesserung zu kümmern. Falls gewünscht würde ich aber gerne meine
> diesbezüglichen Ideen genauer ausführen!
>
> Schöne Grüße
> Martin
>
> [1] http://de.wikipedia.org/wiki/Südtirol#Sprachen_und_Dialekte
> [2] http://666kb.com/i/cf2mh64tyakrc3td2.jpg
>
> _______________________________________________
> Talk-de mailing list
> Talk-de at openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-de