Am 1. Dezember 2012 13:09 schrieb Andreas Labres <[email protected]>: > 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 _______________________________________________ Talk-de mailing list [email protected] http://lists.openstreetmap.org/listinfo/talk-de
