On 09.06.2011 13:28, Igor Podolskiy wrote:
Bodo,
On 08.06.2011 22:47, Bodo Meissner wrote:
Das erschwert das Zusammensetzen etwas, weil man einmal ein
Leerzeichen einfügen muß und einmal nicht. Vermutlich lassen sich
(sprachabhängig) Regeln definieren, bei welchen Zeichen das
Leerzeichen entfällt.
Ich will übrigens gar nichts aufbrechen :) Im Gegenteil, ich bin mit
"name=Limburg an der Lahn" vollkommen zufrieden.
Die Software-Entwickler wahrscheinlich nicht.
Die Trennung wäre nicht nur für den Renderer nützlich, sondern auch
für einen Suchalgorithmus. So könnte der Anwender wählen, ob er das
Suchmuster nur im "Kern" oder auch im Präfix oder Suffix suchen möchte.
vielleicht habe ich mich etwas missverständlich ausgedrückt, sorry. Du
hast vollkommen recht, sowohl das Zusammensetzen als auch das Trennen
ist schwierig bis nahezu unmöglich (im Fall der Übersetzung -
maschinelle Übersetzung hat selbst für normalen Fließtext nur eher
bescheidene Ergebnisse und wir reden hier von Eigennamen, die
grundsätzlich aus einem Wörterbuch kommen).
Mein Vorschlag ist, das Zusammensetzen und das Trennen durch Software
vollständig zu eliminieren, indem man immer in jedem einzelnen Tag
einen vollständigen zusammenhängenden Namen einträgt.
Also zum Beispiel (gerade bei alt_name kann man wieder drüber
streiten, allerdings käme das gerade einem Suchalgorithmus zu gute):
name=Frankfurt am Main
short_name=Frankfurt
official_name=Frankfurt am Main, Stadt # Kommt aus dem
Gemeindeverzeichnis
alt_name=Frankfurt (Main);Frankfurt/Main;Frankfurt/M.
name:ru=Франкфурт-на-Майне
short_name:ru=Франкфурт
name=Hamburg
alt_name=Hansestadt Hamburg
official_name=Freie und Hansestadt Hamburg
Das hat für I18N den Vorteil, dass immer vollständige Namen übersetzt
werden. Der Renderer kann sich dann den kürzesten Aussuchen, wenn er
keinen Platz hat. Und ein Suchalgorithmus kannst du auch darüber
laufen lassen, ohne irgendwie Preprocessing mit Präfixen und Suffixen
zu betreiben.
Das ist alles doch schon in Key:name im Wiki erklärt und geregelt.
name:prefix und name:suffix übrigens auch [1], ist eigentlich ganz
überraschend, wofür das eigentlich mal gedacht war.
Da du auch "die Softwareentwickler" angesprochen hast: Ich bin auch
einer ;) Also, hier die ungefilterte Entwicklersicht:
Als Entwickler will ich letzten Endes die Daten mindestens der ersten
Normalform. Und wir diskutieren hier nichts anderes als was die
korrekte erste Normalform für Ortsnamen ist (eigentlich für
administrative Einheiten, aber sei's drum). Die einen sagen: wir
normalisieren in drei Teile, Präfix, Kern, Suffix für irgendeine vage
Definition von Kern, Präfix und Suffix. Ich sage: der Name ist schon
eine Einheit in sich und braucht nicht weiter zerteilt zu werden. Wenn
es mehrere Namen gibt, ist doch schön, sollen sie als mehrere Namen
entsprechend ihrer Bedeutung bitte auch eingetragen werden. Aber ein
Name ist zusammenhängend, in sich abgeschlossen und sollte im
Idealfall von keiner Software irgendwie weiter transformiert werden,
weil das spätestens bei mehreren Sprachen nicht mehr entscheidbar ist.
Manchmal braucht man andere Trennzeichen. Manchmal ändert sich auch
die Reihenfolge der Wörter bei der Übersetzung. Manchmal gibt es einen
gänzlich anderen Namen. Manchmal gibt es zusätzlichen Präpositionen.
Manchmal wird ein Teil des Namens dekliniert.
Mein Problem mit der Präfix-Kern-Suffix-Aufteilung ist auch, dass sie
mehr oder weniger willkürlich und präsentationsorientiert ist. Alle
Tags in Key:name haben auch eine eigene in der echten Welt relevante
Bedeutung. Deswegen präferiere ich diese Variante.
Ich gehe davon aus, daß Du das in den meisten Fällen nach Gefühl
richtig eintragen kannst und nur in Ausnahmefällen die Regeln lesen
müßtest.
Danke für das Vertrauen :) Aber zwischen nur selten und gar nicht
liegt auch ein Unterschied.
Bisher stelle ich mir die Entscheidung recht einfach vor: Welche
Bezeichnung würde ich auf einer Karte erwarten, wenn der Platz knapp
ist? Das wäre der Name. Alles davor ist Präfix, alles danach Suffix.
Oder hast Du ein Beispiel für einen schwierigen Fall?
Martin Strutmann hat in seinen Beiträgen in diesem Thread
dankenswerterweise eine ganze Reihe von Beispielen gebracht. Die
Wakendorf-Serie ist zum Beispiel sehr interessant.
Außerdem ist der von dir geschilderte Gedankengang
Renderer-orientiert. Kann man machen, aber das vernachlässigt wieder
alle anderen Anwendungen. Außerdem: Print oder Web? Welcher Stil?
Welcher Kartenzweck?
Mein Gedankengang ist: "Frankfurt am Main" ist ein zusammenhängender
vollständiger Name, der kommt in einen Tag rein, Ende. "Frankfurt" ist
eine gebräuchliche alternative Verkürzung, also kommt es in "alt_name"
oder "short_name", Ende. Viel einfacher, als über Renderer, Stile und
überhaupt Anwendungen nachzudenken.
Wohlgemerkt: ich habe nichts gegen alternative vollständige Namen
(alt_name, old_name, name:alternative, name:official,
name:$YOUR_QUALIFIER, ...), nur Bedenken gegen das Zerstückeln.
Einmal vollständig und einmal nur der Hauptteil wäre auch möglich,
ist aber etwas redundant und hat IMHO mehr Fehlermöglichkeiten.
Genau das schlage ich vor. Das bisschen Redundanz erspart uns aber
einen Haufen von irgendwelchen Trennungs- und
Zusammensetzungsalgorithmen, die jetzt nicht gerade ein Beispiel für
Robustheit sein werden - natürlich auch IMHO.
Viele Grüße
Igor
[1] http://wiki.openstreetmap.org/wiki/Key:name:prefix
_______________________________________________
Talk-de mailing list
[email protected]
http://lists.openstreetmap.org/listinfo/talk-de
Ich versuche hier nochmal meine Meinungen zu äussern und vielleicht das
Thema / die Themen nochmal differenziert zusammenzufassen:
Vielleicht wissen wir am Ende dann auch wieder über was wir jetzt
eigentlich diskutieren wollen oder müssen.
1. das Einstiegsproblem:
OSMAND findet den Ort "Ostseebad Zingst" nicht, wenn man nach "Zingst"
sucht:
Meiner Meinung tatsächlich ein Softwareproblem von OSMAND, welches sich
durch nicht allzu großen Aufwand lösen lassen müsste, schließlich ist
der String "Zingst" ein Teil des Strings "Ostseebad Zingst".
Gerne wird ja hier darauf verwiesen, das wir kein Mapping für den
Renderer betreiben, für Software eben auch nicht!
2. Nutzung des Keys "name=*":
Hier kam nun die Frage auf, wie viel Name denn nun im Tag "name=*" zu
stecken hat.
Ich halte Namenszusätze hier nicht für Unsinn, schon gar nicht, wenn sie
Teil des amtlichen Stadtnamens sind.
3. Nutzung von Keys "name:$YOUR_QUALIFIER":
Ich will jetzt nicht wiederholen wie viele Varianten es für
"$YOUR_QUALIFIER" gibt. Wer eine für deutschlandweit gültige Liste haben
will, darf sich gerne hier umkucken:
http://wiki.openstreetmap.org/wiki/User:Fortunequest/LOK#name
Diese Liste habe ich mal aus einer Laune heraus erstellt um grade dem
Wildwuchs von Schlüsseln entgegenzuwirken. Alleine bei uns in
Deutschland haben wir aktuell 7280 verschiedene Schlüssel. Viele erzeugt
aufgrund von Rechtschreibfehlern oder wohl aus einer Laune heraus.
4. Wohin gehört denn nun was?:
Wie ich es aktuell halten würde...
key=name -> value="amtlicher Stadtname"
Alle Zusätze die amtlich festgelegt sind kommen da mit hinein.
Sollte es Städtebezeichnungen in Fremdsprachen geben, dann...
z.B. key=name:en -> value="Munich"
z.B. key=name:fr -> value="Aix-la-Chapelle"
usw...
Gleiches für Lokale Variationen.
Für Alternativnamen sollte man sicherlich einen einheitlichen Key
definieren: vorhanden sind schon: "name:alt=*" , "name:alternative=*" ,
"alt_name=*", "alt-name=*", "alternative_name=*", "alternative name=*"
"alt:name=*", ... Liste ist nicht vollständig!
Redundante informationen, die schon anderweitig enthalten sind, würde
ich komplett weglassen.
Ortsnamenzusätze, wie die von mir erwähnten Beispiele:
„Wissenschaftsstadt“, „Universitätsstadt“, „Documentastadt“ ....
gehören nicht in "name=*", Sie stehen ja auch auf den Ortsschildern vom
Ortsnamen abgesetzt.
Wohin mit diesen, ist wohl nach wie vor offen...
5. Der Thread lautet Ortsnamenzusätze:
D.h. Ortsteilnamen erzeugen mit großer Wahrscheinlichkeit neue Probleme...
Gleiches gilt für Gemeinden, Regionen, etc.
6. Quo Vadis:
Leider habe ich keine Mustergültige Lösung parat, ich hoffe, das man
durch ne öffentliche Diskussion am Ende aber mehr Klarheiten erzeugen
kann als Chaos zu stiften!
Abschließend hoffe ich, das sich keiner auf den Schlips getreten fühlt,
wenn ich jetzt meine nicht vorhandene Kompetenz überschritten habe und
Dinge vergessen, oder fälschlich dargestellt haben solte!
Liebe Grüße
Dominik
--
Dominik Wegerle
"fortunequest"
[email protected]
_______________________________________________
Talk-de mailing list
[email protected]
http://lists.openstreetmap.org/listinfo/talk-de
