[Talk-de] Demo mehrsprachige Karte

[Martin Koppenhoefer]

Am 1. Dezember 2012 13:09 schrieb Andreas Labres <list at lab.at>:
> Interessant wäre auch die Frage, wie man eigentlich sagen soll "diese name Tags
> sind deutschsprachig"? Also wenn jemand z.B. eine Karte en(de) will, dass dann
> eben "Munich (München)" dort steht, obwohl es den name:de Tag vielleicht nicht
> gibt. Oder sollte man für alle Orte in DE, AT und CH (dt.) ein name:de setzen
> wollen?


die Frage taucht ja regelmäßig auf. Eine der Ideen dazu ist, überhaupt
kein "name" mehr zu verwenden, dafür einen Extratag, welches die
"Standardsprache(n)" für ein Feature ist/sind, also so was wie lang=de
und name:de=München

Alternativ könnte man natürlich auch alle name-Einträge doppeln (name
und name:de=München setzen).

Oder man nimmt die Daten wie sie jetzt sind und macht es mit
Boundaries und preprocessing: "Deutschland"-Polygon nehmen, alle
Features die einen "name" und kein "name:de" haben darin auswählen und
bei allen "name" ein zusätzliches "name:de" setzen, oder irgendwie
sonst einen flag, dass "de" die Standardsprache ist (wobei die
Realität ja komplizierter ist, so gibt es auch in Deutschland z.B. die
Gebiete der Sorben, wo es neben Deutsch noch eine andere
Standardsprache gibt). Auch weiss ich nicht genau, ob wir z.B. für die
Schweiz ein Polygon der deutschsprachigen Gebiete haben (wobei die
Schweizer glaub wegen Ihrer Mehrsprachigkeit sowieso disziplinierter
ein name:de ergänzen als die Deutschen).

Nachteil der Preprocessing-Variante: funktioniert nicht gut mit
live-updates der db. Theoretisch könnte man auch eine stark
vereinfachte Grenze hernehmen und damit live jeweils prüfen, wo man
gerade ist, aber das wird a) trotzdem ein bisschen länger dauern und
b) auch im Grenzbereich zu Problemen führen.

Das Problem von doppelten Tags (z.B. name und name:de in der db für
Deutschland explizit vorhalten) ist, dass man redundante Daten hat,
und z.B. Fehler jeweils doppelt korrigieren muss (d.h. es kann zu
Abweichungen zwischen name und name:de kommen, man verschwendet Platz
in der db, und Eintragungen wie Änderungen sind doppelt so viel
Tippaufwand).

Am einfachsten auszuwerten, auch mit dynamischen Datenbanken, wäre
wohl die eingangs erwähnte Variante, auf ein "name" komplett zu
verzichten und einen zusätzlichen "lang"-tag (oder ähnlich)
einzuführen. Für "dumme" Software (d.h. nicht angepasste sw) könnte
man dann auch einfach die Daten vorprozessieren und aus lang plus dem
"name:xx"-tag einen zusätzlichen "name"-tag generieren.

Gruß Martin