-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Am 08.06.2011 16:32, schrieb Igor Podolskiy:
> Irgendjemand, der in Montabaur wohnt, weiß, um welches Limburg es sich > handelt, der sagt dann auch immer "Limburg". Irgendjemand aus Passau oder > London würde vielleicht "an der Lahn" interessieren. Also muss es auch die > Anwendungen interessieren, die diese Leute benutzen. Natürlich ist die Information "Limburg an der Lahn" wichtig, es kann aber für die Darstellung auf einer Karte sinnvoll sein, den Teil "an der Lahn" wegzulassen oder kleiner darzustellen. Woher soll die Software aber wissen, welcher der Kern-Teil ist bei name="Limburg an der Lahn" und name="Hansestadt Hamburg"? (bzw. "Freie und Hansestadt Hamburg") Mit einer Kombination name="Limburg", name:suffix="an der Lahn" und name:prefix="Hansestadt", name="Hamburg" wäre das wesentlich einfacher. Und die Zusammensetzung name:prefix+" "+name+" "+name:suffix ist in den meisten Fällen auch einfach. (aber s.u.) > de:Frankfurt am Main -> Transliteration -> ru:Франкфурт-ам-Майн (falsch) > de:Frankfurt am Main -> Übersetzung -> ru:Франкфурт-на-Майне (richtig) > > Also bräuchtest du ein name:suffix:ru, wenn du tatsächlich name=Frankfurt und > name:suffix=am Main hinschreibst. Und die Bindestriche gehören im Russischen > anders als im Deutschen wirklich dahin. Frankfurt ist nicht Hintertupfingen, > da kannst du nicht sagen "wer das anders als in Deutsch lesen will, hat Pech > gehabt". 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. > On 08.06.2011 14:02, Walter Nordmann wrote: >> Entweder muss die Software den zerstückelten Namen wieder zusammensetzten, >> wenn sie den vollständigen Namen haben will oder sie muss den vollständigen >> Namen irgendwie zerstückeln wenn sie den "Kern-Namen" haben will; >> da ist mir ersteres wegen der einmaligen manuellen Bearbeitung 1000x lieber >> als ein Rumgerate der Software +1 Manuelles Zerstückeln und automatisches Zusammensetzen ist wesentlich einfacher als umgekehrt. Wenn man das einmal umstellt, würde die Software vorläufig nur den Kern-Namen anzeigen, bis sie entsprechend angepaßt ist. > Mir ist es als Mapper lieber, eine einfache Regel zu haben, wo ich nicht > jedes Mal im Wiki nachschauen muss und nachgrübeln muss, was jetzt der Zusatz > ist und was nicht. Und als Anwendungsentwickler ist es mir lieber, eine > (eventuell regional angepasste) Heuristik für _einen_ Tag zu entwerfen, als x > Heuristiken für y Kombinationen aus z Tags für all die unterschiedlichen > Variationen von der Sichtweise, was jetzt ein Zusatz ist und was nicht, die > bei solchen Sachen unweigerlich aufkommen. 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. 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? > 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. Viele Grüße Bodo -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iEYEARECAAYFAk3v3+YACgkQnMz9fgzDSqcDmACcCE3uSS8cR3Ll7dHvPBYQ1IIc 5Y8AoKJJdV5+swdDEBnoz3/SqheqP2tM =zlyn -----END PGP SIGNATURE----- _______________________________________________ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
