Re: [Talk-de] Sprache des Namens Fehler in Kort.
Hallo Hans, Ich kann nur nochmals ganz kurz wiederholen, auf Simon Beitrag oben verweisen, und mit den Worten von Peter W. sagen: Den name-Tag rausfliegen zu lassen halte ich für eine ganz ganz blöde Idee. LG, Stefan Am 25. Juni 2013 23:21 schrieb fly lowfligh...@googlemail.com: On 25.06.2013 22:46, Hans Schmidt wrote: Am 24.06.2013 22:53, schrieb Peter Wendorff: Ich habe jetzt mal eine E-Mail zur JOSM-developer-Liste geschrieben, zusammen mit einem Mockup, den ich in Excel gestellt habe. Für sowas ist https://josm.openstreetmap.de die besser Adresse, aber das wird schon klappen. Auch hättest Du Dich nicht erst auf der Mailingliste anmelden müssen sonder hättest sogar anonyme bleiben können ! Ich mecker nicht nur, sondern entwerfe das auch :) Super. Mal sehen, was daraus wird und wie die Reaktionen sind. Erwarte nicht zu viel. JOSM wird gerade von 1-4 Entwicklern aktiv entwickelt. Grüße fly ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Sprache des Namens Fehler in Kort.
Hallo, Am 24.06.2013 09:03, schrieb Jo: Ich wohne in Belgien. Es ist natürlich noch etwas komplexer als dann mussen beide Sprachen angezeigt werden. 1. haben wir 3 offizielle Sprachen: nl, fr, de 2. Im norten nl, im süden fr, im osten de und in Brüssel fr-nl/nl-fr. In manche Fazilitätgemeinde nl-fr, in andere fr-nl. In der Schweiz passiert warscheinlich etwas ähnliches. Ich würde Name ersetzen mit Referenzen zu ISO Abkürzungen, z.B.: name:nl=Brussel name:de=Brüssel name:fr=Bruxelles name:en=Brussels name=fr - nl Dieser Vorschlag geht in die richtige Richtung, aber IMHO nicht weit genug. Use Cases, die damit nicht umgesetzt werden können: - Anzeige der Toponyme in der/den Amtssprache(n), also: Deutsch und Italienisch in Südtirol, Französisch und Niederländisch in Brüssel, Französisch in Wallonien, Niederländisch in Flandern, Katalanisch und Kastilisch in Katalonien. Während dies in manchen mehrsprachigen Regionen schon im name-Tag umgesetzt ist, hat man anderswo einen anderen Weg gewählt, z.B. in Katalonien: name=Girona, name:es=Gerona. - Anzeige der Toponyme in der Regionalsprache, also: Bretonisch in der Bretagne, Katalanisch in Katalonien (ausser im Val d'Aran, dort Aranesisch), Valencia, den Balearen, in Andorra und dem katalanischsprachigen Teil Frankreichs,... - Anzeige der Toponyme auf Deutsch sofern es sich um heutige oder historische Endonyme handelt, also: Königsberg, Straßburg, Bozen, Laibach Damit auch diese Use Cases abgedeckt werden können, werden für jeden mit name:xx erfassten Namen zusätzlich folgende Informationen benötigt: - es handelt sich um die Bezeichnung in einer vor Ort üblichen Sprache (Endonym) oder um eine Fremdbezeichnung (Exonym) - bei Endonymen: Amtssprache oder nicht, Regionalsprache oder Landessprache, historisch (Königsberg) oder zeitgenössisch (Kaliningrad) Derartige Informationen sollten sinnvollerweise nicht für jedes einzelne Objekt erfasst werden sondern zentral für die betroffene boundary-Relation bzw. gesonderte Relationen für Sprachgebiete. Das Thema ist recht komplex, teilweise auch politisch sensibel, so dass ich mich inzwischen frage, ob man es in einer geografischen Datenbank wie OSM befriedigend abbilden kann. Gruß Rainer ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Sprache des Namens Fehler in Kort.
Am 24.06.2013 22:53, schrieb Peter Wendorff: Ticket? GUI-Skizze? Funktionsidee, wie entschieden wird, welche Sprachen vorgeschlagen werden? Ich habe jetzt mal eine E-Mail zur JOSM-developer-Liste geschrieben, zusammen mit einem Mockup, den ich in Excel gestellt habe. Ich mecker nicht nur, sondern entwerfe das auch :) Mal sehen, was daraus wird und wie die Reaktionen sind. Viele Grüße ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Sprache des Namens Fehler in Kort.
On 25.06.2013 22:46, Hans Schmidt wrote: Am 24.06.2013 22:53, schrieb Peter Wendorff: Ich habe jetzt mal eine E-Mail zur JOSM-developer-Liste geschrieben, zusammen mit einem Mockup, den ich in Excel gestellt habe. Für sowas ist https://josm.openstreetmap.de die besser Adresse, aber das wird schon klappen. Auch hättest Du Dich nicht erst auf der Mailingliste anmelden müssen sonder hättest sogar anonyme bleiben können ! Ich mecker nicht nur, sondern entwerfe das auch :) Super. Mal sehen, was daraus wird und wie die Reaktionen sind. Erwarte nicht zu viel. JOSM wird gerade von 1-4 Entwicklern aktiv entwickelt. Grüße fly ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Sprache des Namens Fehler in Kort.
Ich wohne in Belgien. Es ist natürlich noch etwas komplexer als dann mussen beide Sprachen angezeigt werden. 1. haben wir 3 offizielle Sprachen: nl, fr, de 2. Im norten nl, im süden fr, im osten de und in Brüssel fr-nl/nl-fr. In manche Fazilitätgemeinde nl-fr, in andere fr-nl. In der Schweiz passiert warscheinlich etwas ähnliches. Ich würde Name ersetzen mit Referenzen zu ISO Abkürzungen, z.B.: name:nl=Brussel name:de=Brüssel name:fr=Bruxelles name:en=Brussels name=fr - nl name:nl=Berlijn name:fr=Berlin name:de=Berlin name:en=Berlin name=de Wenn sowas einmal akzeptiert werden kann, ist est nur noch einen kleinen Schritt um weitere Redundanz zu eliminieren: name:nl=Berlijn name:de=Berlin name:fr=de name:en=de name:hu=de name:pl=de name:sv=de name:tr=de name=de Polyglot ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Sprache des Namens Fehler in Kort.
Am 24. Juni 2013 04:40 schrieb Dirk Sohler s...@0x7be.de: Wenn langfristig name rausfliegen soll, und durch name:de ersetzt werden soll (was nur sinnvoll wäre), muss es irgendwann verschoben werden (...) Nein; es gibt keinen Grund, den name-Tag rausfliegen zu lassen. Dies wegen den mehrsprachigen Ortsnamen und Strassen, wie Biel/Bienne oder Martins Beispiel: name=Bolzano - Bozen name:it=Bolzano name:de=Bozen Solche Beispiele gibt es ziemlich sicher auch in Deutschland, nicht nur in Österreichm, Italien, der Schweiz und Spanien. Vgl. oben. LG, Stefan Am 24. Juni 2013 04:40 schrieb Dirk Sohler s...@0x7be.de: Stefan Keller schrieb: Die name-Tags sind dazu da, das zu erfassen, was Mapper sehen und Renderer ohne weitere Angaben darstellen können. Deren Values sollten daher nicht verschoben sondern ggf. kopiert werden (z.B. nach name:de=München). Wenn langfristig name rausfliegen soll, und durch name:de ersetzt werden soll (was nur sinnvoll wäre), muss es irgendwann verschoben werden, spätestens mit Version N+1, wenn name nicht mehr unterstützt wird, muss bis Version N jegliches vorkommen von name durch name:de ersetzt werden (name:de, oder name:en, oder name:ru, etc.). Je eher das gemacht wird, desto besser. Grüße, Dirk -- Local time :: Ortszeit :: DE-HH 2013-06-24T04:37:59+0200 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Sprache des Namens Fehler in Kort.
On 24.06.2013 09:03, Jo wrote: Ich würde Name ersetzen mit Referenzen zu ISO Abkürzungen, z.B.: name:nl=Brussel name:fr=Bruxelles name=fr - nl Das name ist aber schon ziemlich Taggen für den Renderer. Ich denke es sollte die Entscheidung des Renderer sein wie er die Namen darstellen möchte. Ob mit Bindestrich, Schrägstrich, in Klammern oder sonst noch was. Wenn eine Community in einem mehrsprachigen Gebiet beschließt dass es bei ihnen auf eine gewisse Art getrennt wird, dann gut. Sollen sie es so hinschreiben. Dann hat eine Karte die nur den name tag verwendet weltweit ziemlich verschiedene Trennzeichen. Dein Vorschlag sind ja schon technische Referenzen auf andere Datenfelder. Dann lieber gar kein name tag in so einer Situation. Stephan ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Sprache des Namens Fehler in Kort.
Am 23.06.2013 21:01, schrieb Martin Raifer: Am 23.06.2013, 20:19 Uhr, schrieb Peter Wendorff wendo...@uni-paderborn.de: Das klingt nicht schlecht, bisher finde ich noch keine Gegenbeispiele. Hast Du Gegenbeispiele? Immerhin redest du von den meisten Fällen. Konkretes Gegenbeispiel habe ich auch keines. Aber theoretisch könnte sich ein Name in zwei (oder mehr) anderen Sprachen so ungeschickt überschneiden, dass der Algorithmus ausgehebelt wird. Konstruiertes Beispiel: name=Great Mount Doom name:1=Mount Doom name:2=Great Mount Der vorgeschlagene Algorithmus wprde aber auch hier funktionieren, weil er nicht nacheinander die Sprachvarianten entfernt, sondern alle Sprachvarianten erst markiert. Der Algorithmus würde also: Great Mount Doom betrachten, und darin nach Mount Doom suchen. Das wird gefunden und markiert. Unmarkierter Teil ist jetzt noch Great . Es würde in Great Mount Doom (!) nach Great Mount gesucht, das wird gefunden und die Markierung wird entsprechend erweitert: Es bleibt kein unmarkiertes Zeichen mehr übrig. Der Rest vom name-Tag nach der Markierung aller Sprachvarianten ist also eine leere Zeichenkette, und damit wird das akzeptiert. (weil maximal whitespace und Trenner wie Slash, Bindestrich etc. drin vorkommen). Keine Ahnung, ob das irgendwo auf der Welt vorkommt. Viel häufiger dürfte aber der Fall sein, dass ein Name in mehreren Sprachen gleich lautet: name=London name:de=London Hier fehlt offensichtlich das name:en=London, allerdings kann man hier unabhängig vom Algorithmus (ohne Vergleichs-Datenbank) nicht viel machen... Richtig. Der Algorithmus kann nicht alles finden, aber immerhin dürften es wenige falsche Fehlermeldungen sein. Gruß Peter ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Sprache des Namens Fehler in Kort.
Ich muss Stefan recht geben. Im name Tag sollte vor allem das enthalten was tatsächlich auf dem Schild an der Strasse steht (mal von der Abkürzungsproblematik abgesehen), machen wir das nicht, ist es für einen der Sprache / Alphabet nicht mächtigen praktisch nicht möglich heraus zu finden ob er am richtigen Ort ist. Für die Leute mit zu wenig Phantasie stellt euch mal vor ihr steht in China vor einem Schild und habt eine OSM Strassenkarte oder App dabei. Das ist unabhängig davon was wir sonst in der Datenbank speichern: offizielle Namen, Übersetzungen etc. Konkretes Beispiel in Biel (bilinguale Gemeinde) sind viele Strassen zweisprachig angeschrieben, sprich das was man visuell erfasst ist weder der offizielle französische oder deutsche Namen Das der Informatiker in uns alles gern normaliseren möchte ist dabei belanglos. Simon Am 23.06.2013 21:18, schrieb Hans Schmidt: Am 23.06.2013 15:18, schrieb Peter Wendorff: Wenn man das also als Warnung beanstanden würde, sollte man erstmal generell in osm propagieren, dass generell lokalisierte Namen angegeben werden sollten - und das ist, soweit ich bisherige Diskussionen dazu im Kopf habe, zwar nicht verpönt, aber bei weitem nicht Konsens. Ich denke, das liegt auch einfach daran, dass der Renderer (=osm.org) das nicht unterstützt. Es wäre vielleicht sinnvoll, dass der Renderer einfach den name-Tag komplett ignoriert und NUR noch die einzelnen name:xx unterstützt werden. Für Deutschland ist das nämlich nicht notwendig, von daher wird da niemals jemand einen name:de schreiben. Bei anderen Ländern schon. Es wäre dann natürlich möglich, in Ländern, wo kein name:xx-Tag vorhanden ist, einfach den name auf name:xx zu verschieben. Aber das Problem liegt halt im Renderer. Solange der mehrsprachige Renderer, der hier vor einiger Zeit mal vorgestellt wurde, nicht a) auf der OSM-Hauptseite, b) auf allen anderen Webseiten direkt unterstützt wird, passiert da nichts. Außerdem sollte JOSM z.B. direkt immer den lokalisierten name-Tag anzeigen und bei dem normalen name direkt eine Warnung. Im Grunde ist die einzige Möglichkeit aus dem Schlamassel herauszukommen, den name-Tag komplett zu entfernen. Aber wenn der Renderer da nicht mitspielt, dann wird das auch nichts. Dieses aktuelle „Ich packe einfach mal alles was auf dem Straßenschild steht in den name-Tag“ sieht einfach nur unglaublich bescheuert aus. Also, was gemacht werden muss: 1. OSM.org muss den mehrsprachigen Renderer unterstützen. Dann muss entsprechend der Browser-Sprache automatisch für jeden Benutzer die entsprechende Sprache angezeigt werden (deutscher Browser sieht name:de). 2. Alle name-Tags müssen verschoben werden (in USA nach name:en, in Deutschland nach name:de. In Belgien, der Schweiz usw. wird wahrscheinlich sowieso schon alles mehrsprachig existieren, da muss man das notfalls manuell machen). 3. JOSM/Potlatch/was auch immer muss je nach Ort automatisch in den entsprechenden name:xx-Tag schreiben. In Deutschland nach name:de. In der Schweiz/Belgien usw. müssen beide Felder gleichzeitig angezeigt werden. 4. In JOSM muss endlich eine tabellarische Anzeige der Namen der Nodes her. Sonst kann man das nicht vernünftig taggen. (-- Unglaublich wichtig für mehrsprachige Karten!) 5. Anschließend alle name= löschen. Gerne auch mit einem Bot dafür sorgen, dass es weg bleibt. Dann hätte man wesentlich weniger Probleme. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Sprache des Namens Fehler in Kort.
Hallo Hans,
Den name-Tag rausfliegen zu lassen halte ich für eine ganz ganz blöde
Idee. Begründung folgt.
Zunächst mal gebe ich dir recht: Solange keine weiter verbreitete
Anwendung die lokalisierten Namen nutzt, wird das wenig getagged, weil
viele Mapper keine Notwendigkeit dafür sehen.
Aber schon deine Aussage
Am 23.06.2013 21:18, schrieb Hans Schmidt:
Für Deutschland ist das nämlich nicht notwendig, von daher wird da
niemals jemand einen name:de schreiben.
Ist jedoch nicht vollständig richtig.
Könnte ich chinesische Schriftzeichen tippen und dabei sicherstellen,
die richtigen eingetippt zu haben, dann hätte ich schon mehrere
chinesische Restaurants nach dem Muster
name=Pan-Tau
name:cn={chinesische Schriftzeichen}
eingetragen, und durch die Qualitätskontrolle wäre aufgefallen, dass
dabei offensichtlich eine lokalisierte Namensvariante (nämlich die, die
Pan-Tau abdeckt) fehlt, also hätte ich
name:de=Pan-Tau oder so hinzugefügt (eventuell mit vorheriger
Rücksprache, ob das jetzt als name:de oder name:cn-lat oder so getagged
werden sollte).
Für Grenzgebiete in alle Richtungen, Hafenstädte, Kasernen der Briten,
Franzosen oder Amerikanre und so weiter gilt das ähnlich.
Bei anderen Ländern schon.
Richtig.
Es wäre dann natürlich möglich, in Ländern, wo kein name:xx-Tag
vorhanden ist, einfach den name auf name:xx zu verschieben.
Sicher?
wenn name=La Petit France an einem Bistro in Deutschlan eingetragen
ist - ist dann wirklich name:de=La Petit France korrekt? (das wäre ja
das Ergebnis, wenn man sowas ungeprüft verschöbe). Aber andererseits:
wäre name:de=Das kleine Frankreich besser/richtiger?
Das ist möglicherweise nur eine Übersetzung, aber nicht der Deutsche
Name des Bistros.
Aber das Problem liegt halt im Renderer. Solange der mehrsprachige
Renderer, der hier vor einiger Zeit mal vorgestellt wurde, nicht a) auf
der OSM-Hauptseite, b) auf allen anderen Webseiten direkt unterstützt
wird, passiert da nichts.
Das ist nur dann richtig, wenn man den name-Tag wirklich wegließe, und
das halte ich für nicht richtig, weil Namen, zu denen es keine
Übersetzung gibt, üblicherweise auch in jeder Fremdsprache erstmal eins
zu eins übernommen werden. Wie fragst Du in New York nach der 23.
Avenue? Ein deutsches Wort ist Avenue nicht, übersetzen wirst Du es
aber ziemlich sicher auch nicht, weil es dann (bei Übersetzung als
Straße) nicht mehr von der 23. Street unterscheidbar ist, oder (bei
Übersetzung als Chaussee) vermutlich kaum jemand weiß, was du meinst
(selbst wenn derjenige Deutsch kann).
Aber willst du deshalb name:en=23. Avenue, name:de=23. Avenue
eintragen (und das gleiche für die anderen x-hundert Sprachen dieser
Welt auch)? Ist dann nicht name=23. Avenue besser, als bekannter
Fallback: Wenn ich nichts besseres gezielt auswählen kann als Namen,
dann nehme ich das, was vor Ort passt, und in allen Sprachen, die es
nicht übersetzen, passt das dann auch direkt.
Außerdem sollte JOSM z.B. direkt immer den
lokalisierten name-Tag anzeigen und bei dem normalen name direkt eine
Warnung.
Die Warnung könnte dann auch nach dem vorgeschlagenen (oder einem
ähnlichen) Algorithmus vorgehen, wenn der name-Tag nämlich nicht auch
noch in sprachvarianten mit abgedeckt ist.
Im Grunde ist die einzige Möglichkeit aus dem Schlamassel
herauszukommen, den name-Tag komplett zu entfernen.
Aus der Datenbank entfernen: Ich vermute, die Konsequenzen währen
ähnlich verheerend wie beim Lizenzwechsel, und diesmal hätten sie
nichtmal einen Sinn.
Aber wenn der
Renderer da nicht mitspielt, dann wird das auch nichts.
Renderer und Datenbank haben damit hier aber nichts zu tun.
Rendering-Regeln können auch vorhandene name-Tags ignorieren, ohne dass
die aus der Datenbank verschwinden müssen.
Dieses aktuelle „Ich packe einfach mal alles was auf dem Straßenschild
steht in den name-Tag“ sieht einfach nur unglaublich bescheuert aus.
richtig (es sieht bescheuert aus), aber es ist nicht falsch.
Wenn ein Analphabet nach Brüssel kommt und eine Straße sucht, kann er
bei vollständigem name-Tag (wie auf dem Straßenschild) visuell
vergleichen, ob das passt. Aber nach der on-the-ground-regel ist es
korrekt, und ich würde es insofern auch nicht verbieten wollen.
Also, was gemacht werden muss:
1. OSM.org muss den mehrsprachigen Renderer unterstützen.
Klingt gut - setzt du das um?
Dann muss
entsprechend der Browser-Sprache automatisch für jeden Benutzer die
entsprechende Sprache angezeigt werden (deutscher Browser sieht name:de).
Nein, danke.
Ich möchte nicht die name:de-Varianten im ehemaligen Ostpreußen
angezeigt kriegen. Die sind immer noch korrekt, und vielleicht
interessiere ich mich auch ab und zu dafür, aber bitte dann wahlweise,
nicht automatisiert.
Und vor allem möchte ich doch bitte keine leere Karte, nur weil 80% der
Welt keine deutschen Namen getagged hat. Was wird dann angezeigt?
2. Alle name-Tags müssen verschoben werden (in USA nach name:en, in
Deutschland nach name:de. In Belgien, der Schweiz usw. wird
Re: [Talk-de] Sprache des Namens Fehler in Kort.
Am 24.06.2013 02:07, schrieb Stefan Keller: Die name-Tags sind dazu da, das zu erfassen, was Mapper sehen und Renderer ohne weitere Angaben darstellen können. Deren Values sollten daher nicht verschoben sondern ggf. kopiert werden (z.B. nach name:de=München). Vgl. auch meine Ausführungen zu Endonyme und Exonymen oben. Und wozu führt das dann? Dass niemand z.B. in Deutschland name:de nutzt, weil „Was sollen wir denn mit name:de, wir können auch name nutzen“. Und das führt eben genau zu dem jetzigen Chaos mit name. Wieso soll man das unbedingt in einen Tag quetschen? Die Schilder haben nun einmal mehrere Sprachen, die auch für jeden sichtbar trennbar sind. Das ist ja nur auf einem Schild, weil es in der Realität eben keine Trennung in name:xx gibt. Wenn ich in Brüssel ein Straßenschild namens „Quai de Mariemont/Mariemontkaai“ habe, wieso soll ich das in den name-Tag tun? Was genau bringt es mir? 1. Ein französischsprachiger Brüsseler will eh nur „Quai de Mariemont“ sehen. 2. Ein holländischsprachiger Brüsseler will „Mariemontkaai“ sehen. Dass Renderer es nicht können, ist keine Argumentation. Dann müssen die Renderer es eben können. Ein bisschen Feuer am Hintern hat noch niemandem geschadet ;) Ein einziger name-Tag führt halt unweigerlich zu Streitigkeiten in mehrsprachigen Gebieten. Wenn es nur name:xx gibt, wird niemand bevorteiligt. Bei Wikipedia gibt es doch auch nur verschiedene Sprachversionen, aber keine allgemeine. Im Übrigen finde ich, dass die Argumentation mit Begriffen wie „Endonym“ und „Exonym“ das Problem nur verkompliziert. Da halten sich wieder manche Leute wie doof an so einem Kunstwort auf und versuchen, die Diskussion mit Pseudo-Sachlichkeit zu unterfüttern, ersticken aber im Grunde jede Diskussion damit. Und man könnte im Übrigen ja einen Stichtag machen: 1. Ab Tag x zeigen die Webseiten nur noch name:xx an. 2. Bis dahin müssen alle name-Tags kopiert werden und auch überarbeitet. 3. An dem Tag werden rigoros alle name-Tags gelöscht 4. JOSM erlaubt ab dem Zeitpunkt auch keine Erstellung von name-Tags mehr, vorher gibt JOSM eine Warnung aus, wenn kein name:xx-Tag vorhanden ist. Aber besonders Punkt Zwei benötigt, wie ich immer predige, eine tabellarische Auflistung aller Punkte mit ihren name-Tags. Es muss also möglich sein, alle Punkte/Flächen einer Stadt, welche einen Namen haben, gleichzeitig anzuzeigen, so dass a) man schnell erkennen kann, welche Punkte noch keinen name:xx haben, b) man sehen kann, wo möglicherweise etwas falsch kopiert wurde c) viele Tags auf einmal bearbeitet werden können: Nicht immer ein Objekt anklicken, Doppelklick auf jede einzelne Eigenschaft, tippen, auf OK drücken, nächstes Objekt suchen... Ich möchte nur mal jedem raten, der nicht glaubt, wie sinnvoll eine tabellarische Übersicht ist, mal in einem Stadtteil jedem Gebäude einen zusätzlichen name-Tag zu geben. Viel Spaß. Am 24.06.2013 09:03, schrieb Jo: Wenn sowas einmal akzeptiert werden kann, ist est nur noch einen kleinen Schritt um weitere Redundanz zu eliminieren: name:nl=Berlijn name:de=Berlin name:fr=de name:en=de name:hu=de name:pl=de name:sv=de name:tr=de name=de Das finde ich zu kompliziert. Der Speicherplatz wird ja wohl kaum das Problem sein, und nur bei ganz wenigen Nodes gibt es zig Sprachen. In den meisten Fällen wird es sowieso nur einen name:xx-geben (in Deutschland z.B.), zwei-drei (Belgien, Schweiz) oder oft auch mit Transkription. Nur Großstädte wie Berlin o.ä. haben viele internationale Namen, aber es gibt ja keinen Sinn, eine Bahnhofstraße zu übersetzen. Das wäre ja auch gar nicht praktikabel. Von daher wäre folgendes am besten: Es wäre allerdings notwendig, für die meisten Ländern eine Fallback-Sprache zu definieren: Wenn in Deutschland kein name:fr vorhanden ist, gehe auf name:de zurück. Das ist natürlich dann nur in zweisprachigen Gebieten ein Problem, aber selbst da kann man ja notfalls noch computergeneriert den jetzigen name-Tag simulieren. Das obige Beispiel sollte dann z.B. so aussehen: name:nl=Berlijn name:de=Berlin (Standard in Deutschland) name:fr=nicht vorhanden name:en=nicht vorhanden name:hu=nicht vorhanden name:pl=nicht vorhanden name:sv=nicht vorhanden name:tr=nicht vorhanden name=nicht vorhanden Und der Renderer greift dann bei einer englischen Kartendarstellung automatisch auf name:de zurück. Weiterhin wäre für nicht-lateinischsprachige Gebiete eine spezieller Tag für Umschriften notwendig. In vielen Fällen macht das im Moment der name:en-Tag, aber das finde ich relativ schlecht, da es eben kein Englisch ist. Beispiel, was besser wäre: name:ja=札幌 name:ja-romanization=Sapporo. Hier wäre eine Eingabe der Umschrift in name:en falsch, da es eben kein Englisch ist (Was auch dazu führt, dass ein Deutscher dann für sich auch wieder ein name:de haben möchte... usw). Für westlichsprachige Benutzer sollte nun ja-romanization (oder ähnlich) dargestellt werden. Chinesischsprachige Nutzer wollen allerdings eher name:ja sehen. Das heißt dann
Re: [Talk-de] Sprache des Namens Fehler in Kort.
On 24/giu/2013, at 02:07, Stefan Keller sfkel...@gmail.com wrote: Die name-Tags sind dazu da, das zu erfassen, was Mapper sehen und Renderer ohne weitere Angaben darstellen können. Deren Values sollten daher nicht verschoben sondern ggf. kopiert werden (z.B. nach name:de=München). Vgl. auch meine Ausführungen zu Endonyme und Exonymen oben. jein, es gab vor einiger Zeit mal Überlegungen, nur noch name:Sprache zu taggen und die offiziellen Sprachen in einem gesonderten Tag wie z.B. lang festzuhalten, das ist bisher aber nicht umgesetzt. Gruß, Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Sprache des Namens Fehler in Kort.
Am 24.06.2013, 14:08 Uhr, schrieb Martin Koppenhoefer dieterdre...@gmail.com: jein, es gab vor einiger Zeit mal Überlegungen, nur noch name:Sprache zu taggen und die offiziellen Sprachen in einem gesonderten Tag wie z.B. lang festzuhalten, das ist bisher aber nicht umgesetzt. Und was bringt das, außer dass sehr viele bestehende Anwendungen nicht mehr richtig funktionieren werden? Statt name=XY + name:foo=XY hat dann halt name:foo=XY und lang=foo. Die Anzahl der Tags bleibt gleich, lediglich die Redundanz wird reduziert. Ich dachte aber immer, ein gewisses Maß an Redundanz in OSM wäre erwünscht, da man damit mehr Möglichkeiten hat potentielle Fehler oder fehlende Daten zu finden. Außerdem schafft man sich durch so ein Konstrukt neue Grenzfälle, die gesondert betrachtet werden müssten (und den Mappern erstmal beigebracht werden müssten): * Was macht man mit Namen, von denen man nicht weiß, in welcher Sprache sie vorliegen? * Was ist mit Namen, die man gar nicht direkt einer Sprache zuordnen kann? Beispiele: name=google, name=Museion, name=UPIM, name=Bar Mary, usw. (Alles Real-Life Beispiele, nach denen ich nicht lange suchen musste.) * Oder Namen, die in mehreren Sprachen gleich lauten. Unser aktuelles Datenmodell deckt alle diese Fälle ganz natürlich mit ab. Viele Grüße Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Sprache des Namens Fehler in Kort.
Am 24.06.2013 11:01, schrieb Peter Wendorff: Sicher? wenn name=La Petit France an einem Bistro in Deutschlan eingetragen ist - ist dann wirklich name:de=La Petit France korrekt? (das wäre ja das Ergebnis, wenn man sowas ungeprüft verschöbe). Aber andererseits: wäre name:de=Das kleine Frankreich besser/richtiger? Das ist möglicherweise nur eine Übersetzung, aber nicht der Deutsche Name des Bistros. In diesem Falle muss man allerdings etwas flexibel sein – Ich denke aber, dass sich das aus dem gesunden Menschenverstand ergibt. In Deutschland gibt es im Grunde ja keine zweisprachigen Beschilderungen (Mit Ausnahme von sorbischen Gebieten o.ä.) Auch wenn „La Petit France“ natürlich zuerst als Sprache an sich Französisch ist, richtet es sich an deutschsprachige Leser. Das ist ja auch der „Haupttitel“ des Bistros. Wenn das Bistro jetzt natürlich zwei Titel hat (Nehmen wir mal dein Beispiel von dem China-Restaurant, dann ist es schon sinnvoll, das dann in name:zh (nicht cn) zu schreiben. Umgekehrt würde ich in Japan beispielsweise ein Geschäft mit einem Namen in lateinischen Buchstaben (gibt es) trotzdem in name:ja schreiben. Ich finde, da machst du dir zu viele Gedanken. Das ist doch recht logisch. Wenn ich in einem deutschen Text eine Überschrift in Latein schreibe, dann ist die Überschrift an sich zwar von der Sprache her Latein, aber sie „gilt“ sogesehen trotzdem als Deutsch. Nichts anderes ist das hier. Auch mit Google usw. Am 24.06.2013 11:01, schrieb Peter Wendorff: Also, was gemacht werden muss: 1. OSM.org muss den mehrsprachigen Renderer unterstützen. Klingt gut - setzt du das um? Nein, dazu reichen meine Programmierkenntnisse nicht aus. Allerdings gibt es das Projekt doch schon. Wie ich in der Vergangenheit allerdings schon mehrmals erklärt habe, wäre ich bei einem Spendenaufruf zur Verbesserung der OSM-Webseite gerne bereit, mehrere Euros abzugeben. Am 24.06.2013 11:01, schrieb Peter Wendorff: Nein, danke. Ich möchte nicht die name:de-Varianten im ehemaligen Ostpreußen angezeigt kriegen. Die sind immer noch korrekt, und vielleicht interessiere ich mich auch ab und zu dafür, aber bitte dann wahlweise, nicht automatisiert. Und vor allem möchte ich doch bitte keine leere Karte, nur weil 80% der Welt keine deutschen Namen getagged hat. Was wird dann angezeigt? Habe ich doch geschrieben. Für jedes Land muss es eine Fallback-Sprache geben: Für Deutschland name:de, für UK name:en, für Frankreich name:fr. Am 24.06.2013 11:01, schrieb Peter Wendorff: mit der Sprache zur Auswahl), aber auch mit der Möglichkeit, das NICHT zu tun, denn wenn ich in irgendeinem (mehrsprachigen) Land die Sprache eines Namens nicht kenne, die schrift aber lesen kann, dann ist name korrekt, name:xx kann ich aber nicht eintragen). Bei aller Liebe: Dann solltest du lieber gar nichts eintragen oder die Landesschrift lernen. Übrigens, da ich gerade sehe, dass du deine E-Mail unter Linux geschrieben hast: Unter Linux kann man mit AltGr+V und AltGr+B die deutschen Anführungszeichen ohne irgendwelche Konfiguration verwenden: „“. Das sieht dann nicht so hässlich und falsch aus wie . So als kleiner Tipp für die Zukunft. Am 24.06.2013 15:02, schrieb Martin Raifer: Und was bringt das, außer dass sehr viele bestehende Anwendungen nicht mehr richtig funktionieren werden? Da ist ein kleiner Tritt in den Hintern nie verkehrt: Die Anwendungen sollen dann mal eine neue Version herausbringen. Das kann man ja alles gerne mit genügend zeitlichem Abstand machen (à la: In 1 Jahr stellen wir um, bitte bis dahin die Funktion unterstützen). Funktioniert bei anderen Projekten auch. Man muss sich nicht mit Gewalt an irgendwelchen vorsintflutlichen Standards halten, die überholt sind. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Sprache des Namens Fehler in Kort.
Am 24.06.2013 13:36, schrieb Hans Schmidt: Am 24.06.2013 02:07, schrieb Stefan Keller: Die name-Tags sind dazu da, das zu erfassen, was Mapper sehen und Renderer ohne weitere Angaben darstellen können. Deren Values sollten daher nicht verschoben sondern ggf. kopiert werden (z.B. nach name:de=München). Vgl. auch meine Ausführungen zu Endonyme und Exonymen oben. Und wozu führt das dann? Dass niemand z.B. in Deutschland name:de nutzt, weil „Was sollen wir denn mit name:de, wir können auch name nutzen“. Und das führt eben genau zu dem jetzigen Chaos mit name. Wieso soll man das unbedingt in einen Tag quetschen? Die Schilder haben nun einmal mehrere Sprachen, die auch für jeden sichtbar trennbar sind. Das ist ja nur auf einem Schild, weil es in der Realität eben keine Trennung in name:xx gibt. Wenn ich in Brüssel ein Straßenschild namens „Quai de Mariemont/Mariemontkaai“ habe, wieso soll ich das in den name-Tag tun? Was genau bringt es mir? 1. Ein französischsprachiger Brüsseler will eh nur „Quai de Mariemont“ sehen. 2. Ein holländischsprachiger Brüsseler will „Mariemontkaai“ sehen. Und ich, der ich weder Französisch noch Holländisch spreche, kann den Namen gar nicht mehr eintragen, weil ich nicht weiß, was davon welche Sprache ist. Dass Renderer es nicht können, ist keine Argumentation. Dann müssen die Renderer es eben können. Ein bisschen Feuer am Hintern hat noch niemandem geschadet ;) Und wem willst Du Feuer machen? Der Software? Den Entwicklern? Die sagen dir dann zurecht, dass du warten musst oder es selbst umsetzen sollst - sonst machen sie das, wenn sie wollen - und das IMHO zurecht. Ein einziger name-Tag führt halt unweigerlich zu Streitigkeiten in mehrsprachigen Gebieten. Wenn es nur name:xx gibt, wird niemand bevorteiligt. Bei Wikipedia gibt es doch auch nur verschiedene Sprachversionen, aber keine allgemeine. Der Vergleich hinkt. Du nimmst die Streitigkeiten aus den Daten raus, und in Zukunft sind diejenigen Schuld, die die Rendering-Regeln definieren. Wenn name:de nicht existiert, name nicht mehr Mariemmont/Mariemontkaai enthält und in meinem Browser weder Französich noch Holländisch als akzeptierte Sprache definiert ist - was soll die Karte dann denn zeigen? Irgendjemand wird das entscheiden müssen, und die Konflikte gehen von vorne los, nur dass jetzt nicht mehr Mapper untereinander einen Konsens finden müssen, geschweige denn regional, sondern die Entwickler des Kartenstils sind an allem Schuld. Ich glaube nicht, dass das wirklich viel besser macht. [...] Und man könnte im Übrigen ja einen Stichtag machen: 1. Ab Tag x zeigen die Webseiten nur noch name:xx an. 2. Bis dahin müssen alle name-Tags kopiert werden und auch überarbeitet. 3. An dem Tag werden rigoros alle name-Tags gelöscht 4. JOSM erlaubt ab dem Zeitpunkt auch keine Erstellung von name-Tags mehr, vorher gibt JOSM eine Warnung aus, wenn kein name:xx-Tag vorhanden ist. Es gibt keine Regeln für Tags, und es gibt absolut gar keinen Grund, hier jetzt eine einzuführen. Was willst Du dann noch alles technisch durchsetzen? Im Übrigen würdest du insbesondere praktisch jede Software mit dieser Änderung unbrauchbar machen, die es bisher gibt, denn der name-Tag dürfte so ziemlich die zentralste, akzeptierteste Eigenschaft in osm-daten sein, die es gibt. Aber besonders Punkt Zwei benötigt, wie ich immer predige, eine tabellarische Auflistung aller Punkte mit ihren name-Tags. Es muss also möglich sein, alle Punkte/Flächen einer Stadt, welche einen Namen haben, gleichzeitig anzuzeigen, so dass a) man schnell erkennen kann, welche Punkte noch keinen name:xx haben, b) man sehen kann, wo möglicherweise etwas falsch kopiert wurde c) viele Tags auf einmal bearbeitet werden können: Nicht immer ein Objekt anklicken, Doppelklick auf jede einzelne Eigenschaft, tippen, auf OK drücken, nächstes Objekt suchen... Die Idee finde ich tatsächlich gut - und ich glaube, ich hab das auch schonmal so geschrieben. JOSM kann erweitert werden - schreib das Plugin dafür! Ich wette, es hätte relativ großes Potential, auf Dauer in den Core von JOSM zu wandern. Motivieren, lokalisierte Namen anzugeben, ist sicher nicht falsch, und das Eitragen lokalisierter Namen zu vereinfachen auch nicht. Aber nur, weil du - auch mehrfach - danach schreist, hat noch nicht notwendigerweise jemand Zeit dafür. Ich möchte nur mal jedem raten, der nicht glaubt, wie sinnvoll eine tabellarische Übersicht ist, mal in einem Stadtteil jedem Gebäude einen zusätzlichen name-Tag zu geben. Viel Spaß. Stimmt. Am 24.06.2013 09:03, schrieb Jo: Wenn sowas einmal akzeptiert werden kann, ist est nur noch einen kleinen Schritt um weitere Redundanz zu eliminieren: name:nl=Berlijn name:de=Berlin name:fr=de name:en=de name:hu=de name:pl=de name:sv=de name:tr=de name=de Das finde ich zu kompliziert. Der Speicherplatz wird ja wohl kaum das Problem sein, und nur bei ganz wenigen Nodes gibt es zig Sprachen. In den meisten Fällen wird es
Re: [Talk-de] Sprache des Namens Fehler in Kort.
Am 24.06.2013 15:44, schrieb Hans Schmidt: [...] Ich finde, da machst du dir zu viele Gedanken. Das ist doch recht logisch. Wenn ich in einem deutschen Text eine Überschrift in Latein schreibe, dann ist die Überschrift an sich zwar von der Sprache her Latein, aber sie „gilt“ sogesehen trotzdem als Deutsch. Nichts anderes ist das hier. Auch mit Google usw. Dann reden wir mal nicht direkt übers lesen, sondern übers Sprechen. Wenn Du mir Google vorliest - wie sprichst Du es aus? Vermutlich (korrekt) so ungefähr Guhgel. Warum? Weil Du weißt, dass es im allgemeinen wie im Englischen ausgesprochen werden soll. Wüsstest Du das nicht, würdest Du z.B. deutsch gohgle sagen. Das ist aber keine Kleinigkeit: OSM soll ja vor allem auch z.B. in Navigationssystemen eingesetzt werden, und die sollten bitte nicht La Petite Franze (mit stimmhaftem e natürlich) lesen, sondern La Peti Frongz oder so ähnlich, weil es eben französisch ist - und auch in einem deutschen Textkontext französisch bleibt. Wenn ich jetzt von Screenreadern für Blinde rede dabei, verweist du mich in die Niesche - von mir aus. Aber spätestens das Navi, das nach Möglichkeit doch bitte Sprachanweisungen geben soll, stimmst du mir hoffentlich zu. Am 24.06.2013 11:01, schrieb Peter Wendorff: Nein, danke. Ich möchte nicht die name:de-Varianten im ehemaligen Ostpreußen angezeigt kriegen. Die sind immer noch korrekt, und vielleicht interessiere ich mich auch ab und zu dafür, aber bitte dann wahlweise, nicht automatisiert. Und vor allem möchte ich doch bitte keine leere Karte, nur weil 80% der Welt keine deutschen Namen getagged hat. Was wird dann angezeigt? Habe ich doch geschrieben. Für jedes Land muss es eine Fallback-Sprache geben: Für Deutschland name:de, für UK name:en, für Frankreich name:fr. und wer definiert die? Du? Ich? Ein Israeli? Ein Palästinenser? Ein Ostpreuße, der im heutigen Polen lebt? Einfacher wird es dadurch jedenfalls noch lange nicht. Am 24.06.2013 11:01, schrieb Peter Wendorff: mit der Sprache zur Auswahl), aber auch mit der Möglichkeit, das NICHT zu tun, denn wenn ich in irgendeinem (mehrsprachigen) Land die Sprache eines Namens nicht kenne, die schrift aber lesen kann, dann ist name korrekt, name:xx kann ich aber nicht eintragen). Bei aller Liebe: Dann solltest du lieber gar nichts eintragen oder die Landesschrift lernen. ? Wenn ich in Tansania bin, kann ich die Schrift lesen, und oft ist das sogar sehr einfach, weil viele afrikanische Sprachen, wenn sie geschrieben werden, recht nah an der Lautschrift in lateinischen Buchstaben geschrieben werden. Aber in Tansania werden über 100 Sprachen gesprochen. Bei einem Namen an einem Laden irgendwo Abseits der Städte wäre ich mir also nicht sicher, dass das wirklich Suaheli ist, obwohl Suaheli die de-facto-Nationalsprache ist. Klar: Ich kann dann auch einfach gar nichts eintragen. Aber wäre nicht ein Name (der als solcher korrekt ist, nur dass ich nicht weiß, welche Sprache das ist) besser als gar keiner? Übrigens, da ich gerade sehe, dass du deine E-Mail unter Linux geschrieben hast: Unter Linux kann man mit AltGr+V und AltGr+B die deutschen Anführungszeichen ohne irgendwelche Konfiguration verwenden: „“. Das sieht dann nicht so hässlich und falsch aus wie . So als kleiner Tipp für die Zukunft. Ich weiß, aber ehrlich gesagt bin ich dazu einfach zu faul - da sind mir dann komplette Sätze mit Prädikat wichtiger. ;) Am 24.06.2013 15:02, schrieb Martin Raifer: Und was bringt das, außer dass sehr viele bestehende Anwendungen nicht mehr richtig funktionieren werden? Da ist ein kleiner Tritt in den Hintern nie verkehrt: Die Anwendungen sollen dann mal eine neue Version herausbringen. Das kann man ja alles gerne mit genügend zeitlichem Abstand machen (à la: In 1 Jahr stellen wir um, bitte bis dahin die Funktion unterstützen). Funktioniert bei anderen Projekten auch. Man muss sich nicht mit Gewalt an irgendwelchen vorsintflutlichen Standards halten, die überholt sind. Ich fasse zusammen: - In Editoren sollte sinnvollerweise eine einfache Möglichkeit geschaffen werden, mehrsprachige Varianten tabellarisch zu erfassen. Helfen willst du dabei nicht, weil du nicht genug programmieren kannst. - In den Kartenstilen soll der name-Tag nicht mehr angezeigt werden, um Mapper dazu zu zwingen, lokalisierte Varianten zu nutzen. Ob du dabei helfen willst oder nicht, hast du nicht gesagt - aber tu dir keinen Zwang an. - Um das performant umsetzen zu können, muss vermutlich das Datenbankschema leicht geändert werden (damit nicht Mapnik bei jedem Objekt den richtigen name-Tag algorithmisch suchen muss). - Alle Entwickler sämtlicher Anwendungen auf Basis von OSM sollen sich darauf einstellen, dass es keine name-Tags mehr gibt, und ihre Software entsprechend patchen - Du schlägst vor, das über Länderlisten zu regeln (also: Deutschland: name:de, Frankreich: name:fr und so weiter). Abgesehen davon, dass das nicht reicht (vgl. mehrsprachige Gebiete), setzt das für jede
Re: [Talk-de] Sprache des Namens Fehler in Kort.
Am 24.06.2013 17:31, schrieb Peter Wendorff: Und ich, der ich weder Französisch noch Holländisch spreche, kann den Namen gar nicht mehr eintragen, weil ich nicht weiß, was davon welche Sprache ist. Dann wäre es aber sinnvoll, wenn du es erst gar nicht eintragen würdest. Ich würde auch mal behaupten, dass der Anteil der ausländischen Nutzer, die nicht in ihrem Heimatland mappen und von den dortigen Landessprachen absolut keine Ahnung haben, unglaublich gering ist. Und ein Einheimischer kann das normalerweise sofort unterscheiden. Mal davon abgesehen ist das auch für einen Nicht-Einheimischen recht klar (Dass „Quai de Mariemont“ Französisch ist, und „Mariemontkaai“ Holländisch ist ja doch schon recht ersichtlich). ? Wenn ich in Tansania bin, kann ich die Schrift lesen, und oft ist das sogar sehr einfach, weil viele afrikanische Sprachen, wenn sie geschrieben werden, recht nah an der Lautschrift in lateinischen Buchstaben geschrieben werden. Aber in Tansania werden über 100 Sprachen gesprochen. Bei einem Namen an einem Laden irgendwo Abseits der Städte wäre ich mir also nicht sicher, dass das wirklich Suaheli ist, obwohl Suaheli die de-facto-Nationalsprache ist. Das stimmt natürlich, allerdings könnte das ja ein Einheimischer machen. Trennen musst du das ganze ja so oder so: Es gibt ja jetzt auch schon andere Tags wie name:suaheli oder name:xulu (Ich kenne gerade die Codes nicht). Die sollten doch auch genutzt werden, oder nicht? Das ist ja im Grunde auch der Kern des ganzen Problems: Die entsprechen name:xx-Tags werden nicht genutzt, weil alles in name hineingeschrieben wird. Aber es ist doch sinnvoll, getrennte name-Tags zu haben, oder? Ein Suaheli-Nutzer würde halt gerne nur alles in Suaheli sehen. Wenn aber die Namen nur in „name“ stehen, dann kann man das nicht trennen. In deinem speziellen Fall kann man das ja auch einfach in den Kommentar schreiben, mit der Bitte, dass jemand Kundiges das später trennt. Und wem willst Du Feuer machen? Der Software? Den Entwicklern? Die sagen dir dann zurecht, dass du warten musst oder es selbst umsetzen sollst - sonst machen sie das, wenn sie wollen - und das IMHO zurecht. Natürlich, aber man kann dann natürlich auch einfach sagen: „In einem Jahr wird es so nicht mehr funktionieren. Wenn deine Software dann nicht mehr geht, hast du Pech. Änder was dran.“ So funktioniert halt technischer Fortschritt: Ohne Anpassung geht nichts. Ein Netscape Navigator 1.0 wird mit der aktuellen OSM-Seite auch nichts mehr anfangen können. Besonders bei Open-Source-Projekten fällt mir allerdings auf, dass man immer krampfhaft versucht, jede Software zu unterstützen, und es so gar nicht voran geht. Wie gesagt, das muss nicht von heute auf morgen geschehen, aber wenn da mal ein anständiger Plan existiert, der vernünftig kommuniziert wird und auch mit einer großzügigen Zeitspanne, dann sehe ich da eigentlich nicht wirklich ein Problem. Aber nun gut, ich gebe zu, es ist komplizierter als ich gedacht habe. Wenn name:de nicht existiert, name nicht mehr Mariemmont/Mariemontkaai enthält und in meinem Browser weder Französich noch Holländisch als akzeptierte Sprache definiert ist - was soll die Karte dann denn zeigen? Irgendjemand wird das entscheiden müssen, und die Konflikte gehen von vorne los, nur dass jetzt nicht mehr Mapper untereinander einen Konsens finden müssen, geschweige denn regional, sondern die Entwickler des Kartenstils sind an allem Schuld. Ich glaube nicht, dass das wirklich viel besser macht. Das stimmt zwar, aber in dem Fall kann man den name-Tag (bzw. die Anzeige, nicht den Tag selber) ja automatisch generieren lassen. Ich würde mal sagen (ohne es jetzt genau zu wissen), dass es einem Belgier völlig egal ist, wie der name-Tag aufgebaut ist, wenn er normalerweise eh nur den französischen Tag sieht. Ich kenne das von Japan her: Da steht im name-Tag aller möglicher Schranz, weil die Einheimischen eh nur der name:ja-Tag interessiert. Das ging doch auch schon in diesem Test von dem mehrsprachigen Render: name:fr / name:nl (oder so ähnlich), und dann wurde einfach beides dargestellt. Am 24.06.2013 17:31, schrieb Peter Wendorff: JOSM kann erweitert werden - schreib das Plugin dafür! Typisches Open-Source-Problem: Nicht jeder Benutzer/Teilnehmer an einem Projekt kann programmieren. Selbst wenn man es kann, kann man es vielleicht nicht gut genug für das spezielle Problem. Ich predige das andauernd und ständig: Manche Leute haben halt ihre Fähigkeiten in einem anderen Fachgebiet und verdienen damit gut ihr Geld. Sie wären völlig bereit, jemanden monetär zu vergüten, wenn er eine gewünschte Funktion einbaut. Leider gibt es die Möglichkeit bei OSM z.B. absolut gar nicht. Ich wäre sehr dafür, dass es mal einen Spendenaufruf wie 1x jährlich bei Wikipedia gäbe, der allerdings nicht (nur) in die Server fließt, sondern auch ganz banal mal in die Software (besonders OSM.org; JOSM ist ja schon ganz gut, auch wenn dort manche Verbesserungen gebraucht werden
Re: [Talk-de] Sprache des Namens Fehler in Kort.
Am 24.06.2013 19:43, schrieb Hans Schmidt: Am 24.06.2013 17:31, schrieb Peter Wendorff: Und ich, der ich weder Französisch noch Holländisch spreche, kann den Namen gar nicht mehr eintragen, weil ich nicht weiß, was davon welche Sprache ist. Dann wäre es aber sinnvoll, wenn du es erst gar nicht eintragen würdest. Ich würde auch mal behaupten, dass der Anteil der ausländischen Nutzer, die nicht in ihrem Heimatland mappen und von den dortigen Landessprachen absolut keine Ahnung haben, unglaublich gering ist. Und ein Einheimischer kann das normalerweise sofort unterscheiden. Mal davon abgesehen ist das auch für einen Nicht-Einheimischen recht klar (Dass „Quai de Mariemont“ Französisch ist, und „Mariemontkaai“ Holländisch ist ja doch schon recht ersichtlich). Dann nimm Holländisch und Belgisch, oder Hebräisch und Arabisch oder Englisch und Schottisch oder oder oder (und nimm an, du kannst jeweils keine der Sprachen näher). Ich gebe dir recht, es ist häufig ersichtlich, was was ist, aber nicht immer. Und dann trag nichts ein ist eine Möglichkeit - aber das Argument ist blöd, wenn sonst da auch niemand mapped, und ich die Möglichkeit dazu hätte. Du versuchst hier, eine Regel festzuschreiben - etwas, das bei OSM ganz ganz selten und nur mit extrem guten Gründen passiert. Was aber auch ein Grundsatz von OSM ist - nicht festgeschrieben, aber vielfach in Tagging-Schemata manifestiert: Wenn ich ein Detail nicht weiß, sollte ich in der Lage sein, mein nicht-so-detailliertes Wissen trotzdem beizutragen, z.B. indem ich building=yes eintrage statt building=residential oder highway=road (wenn ich nicht beurteilen kann, was für eine Straße das ist). Das ist nicht perfekt, aber besser als nichts. name=foo ist nicht perfekt, aber besser als nichts. Du versuchst das hier umzudrehen: Wenn du die Sprache nicht kennst, lass den Namen komplett weg. Sorry: Halte ich in der OSM-Kultur schon als Ratschlag/Hinweis für nicht für akzeptabel, als Regel, die ausnahmsweise technisch durchgedrückt wird, noch viel viel weniger. ? Wenn ich in Tansania bin, kann ich die Schrift lesen, und oft ist das sogar sehr einfach, weil viele afrikanische Sprachen, wenn sie geschrieben werden, recht nah an der Lautschrift in lateinischen Buchstaben geschrieben werden. Aber in Tansania werden über 100 Sprachen gesprochen. Bei einem Namen an einem Laden irgendwo Abseits der Städte wäre ich mir also nicht sicher, dass das wirklich Suaheli ist, obwohl Suaheli die de-facto-Nationalsprache ist. Das stimmt natürlich, allerdings könnte das ja ein Einheimischer machen. Klar. Aber tun sie das? Haben sie die notwendigen technischen Mittel? Das notwendige Wissen? Die notwendige Zeit? Die Motivation? Ist nicht die Karte trotzdem sinnvoll? Trennen musst du das ganze ja so oder so: Es gibt ja jetzt auch schon andere Tags wie name:suaheli oder name:xulu (Ich kenne gerade die Codes nicht). Die sollten doch auch genutzt werden, oder nicht? Das ist ja im Grunde auch der Kern des ganzen Problems: Die entsprechen name:xx-Tags werden nicht genutzt, weil alles in name hineingeschrieben wird. Aber es ist doch sinnvoll, getrennte name-Tags zu haben, oder? Ein Suaheli-Nutzer würde halt gerne nur alles in Suaheli sehen. Wenn aber die Namen nur in „name“ stehen, dann kann man das nicht trennen. Dass ein Suaheli-Nutzer nur Suaheli sehen will, halte ich für genauso ein Gerücht, wie dass ein deutschsprachiger Nutzer nur deutschsprachige Namen sehen will. Ich will je nach Anwendung sehen, was mir weiterhilft. In Frankreich helfen mir Deutsche Namen nicht bei der Orientierung, in Afrika genausowenig (aber es gibt sowas z.B. aus der Kolonialvergangenheit durchaus). Um darüber hier zu reden hätte ich gerne deutsche Namen, aber vor Ort in Paris suche ich den/die/das Champs-Élysées, und nicht die Schose Lisee, obwohl ich ungefähr von letzterem hier sprechen würde (ich weiß, das ist nicht der richtige Wert für name:de, aber ein Beispiel dafür, warum die lokale Schreibweise wichtig ist). Du hast recht: wenn die Namen nur in name stehen, kann man das nicht trennen, aber das verlange ich ja auch gar nicht. Ich sage nur: den name-Tag zu löschen ist falsch, denn das hilft bei keinem Problem weiter, und zur Erziehung der Mapper taugen Vorschriften von Tags nicht. Und wem willst Du Feuer machen? Der Software? Den Entwicklern? Die sagen dir dann zurecht, dass du warten musst oder es selbst umsetzen sollst - sonst machen sie das, wenn sie wollen - und das IMHO zurecht. Natürlich, aber man kann dann natürlich auch einfach sagen: „In einem Jahr wird es so nicht mehr funktionieren. Wenn deine Software dann nicht mehr geht, hast du Pech. Änder was dran.“ Klar kann man das, aber 1) Es muss schon verdammt gute Gründe geben, Nutzer zu vergraulen (denn das passiert, wenn jemand veraltete Software benutzt, die nicht gewartet wird, oder wenn Programmierer dann eben keine Lust haben, ihre Software anzupassen), und 2) du vergraulst Mapper, wenn du - auch in einem Jahr
Re: [Talk-de] Sprache des Namens Fehler in Kort.
Lieber Martin Am 19. Juni 2013 10:25 schrieb Martin Raifer tyr@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@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
Re: [Talk-de] Sprache des Namens Fehler in Kort.
On 23/giu/2013, at 14:04, Stefan Keller sfkel...@gmail.com wrote: 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). ausgezeichnete Idee, die lokale Variante (z.B. Dialekt) zu taggen. Problem ist dabei, dass diese praktisch nie geschrieben werden, (aber es gibt wohl teilweise Regeln, das Alphabet zu erweitern um Laute abzubilden). Gruß, Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Sprache des Namens Fehler in Kort.
Hi. (Kürzungen in den Folgenden Zitaten nur abschnittsweise, deshalb nicht im Einzelnen kenntlich gemacht) Am 23.06.2013 14:04, schrieb Stefan Keller: Zu deinen Verbesserungsvorschlägen: Am 19. Juni 2013 10:25 schrieb Martin Raifer tyr@gmail.com: 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. Klar ist das eine Definitionsfrage, was man als Fehler und was nur als Warnung betrachtet, aber ich denke, die einzig sinnvolle Definition hier, wenn es sich um das Bearbeiten von OSM-Daten handelt, ist die, dass ich, um etwas einen Fehler zu nennen, schon sicher sein sollte, dass es falsch ist. Ein Fehler sagt dem Empfänger der dazugehörigen Meldung: So ist das falsch, pfui! Eine Warnung ist dagegen eher: sag mal: das, was du da grade gemacht hast, ist zwar möglich, aber zumindest ungewöhnlich. Hast du das wirklich so gemeint? Es gibt eigentlich noch eine dritte Kategorie, und das sind die fehlenden Daten. Nicht falsch, aber eben einfach nicht vorhanden. Fehler werden daraus nur, wenn man in der Auswertung Zufällig andere Default-Annahmen trifft als man müsste ;) Zu dieser Kategorie gehören die lokalisierten name-Tags. ein nicht-lokalisierter name-Tag irgendwo mitten in Deutschland, der den Namen auf Deutsch enthält, ist doch erstmal nicht falsch, das ist der Name. Mitten in Deutschland wird auch jede Software, die das berücksichtigen will, selst mit groben Heuristiken diesen Namen als deutschsprachig interpretieren (als best-guess eben). Deshalb alle name-Tags ohne sprachvariante als Fehler zu bezeichnen, ist falsch, und auch eine Warnung ist zumindest regional zu hoch gegriffen. Wenn wir tatsächlich wollten, dass die OSM-Datenbank für jeden Namen mindestens einen name:xx-Tag enthält, dann wär das schonmal 'ne ganz schöne Hausnummer: laut Taginfo gibt es in osm: name: 35.535.456 mal der verbreitetste lokalisierte Tag dazu ist name:en: 831.929 mal - das sind 2,34% danach kommen: name:ru (314.898, 0,89%) name:ja (241.130, 0,68%) name:fr (203.957, 0,57%) name:de (182.59, 0,51%) und so weiter. Ganz grob überschlagen gibt es etwa zehnmal so viele name-Tags wie alle lokalisierten Name-Tags zusammengenommen. Wenn man das also als Warnung beanstanden würde, sollte man erstmal generell in osm propagieren, dass generell lokalisierte Namen angegeben werden sollten - und das ist, soweit ich bisherige Diskussionen dazu im Kopf habe, zwar nicht verpönt, aber bei weitem nicht Konsens. Eine Ausnahme allerdings sehe ich schon: WENN ein Objekt - ein name-Tag hat - und mindestens ein lokalisiertes name:** besitzt, - und keines der lokalisierten name:**-Tags im name-Tag enthalten ist (als Teil des Namens, damit auch die Kombinierten name-Tags wie Brüssel/Bruxxelex oder so nicht als fehler erkannt werden), DANN fehlt offensichtlich mindestens ein name, und der ist dann auch sinnvoll einzutragen, z.B., um bei textbasierten OSM-Diensten die Browser-Sprache bedienen zu können. Gruß Peter ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Sprache des Namens Fehler in Kort.
Am 23. Juni 2013 15:18 schrieb Peter Wendorff wendo...@uni-paderborn.de: Es gibt eigentlich noch eine dritte Kategorie, und das sind die fehlenden Daten. Nicht falsch, aber eben einfach nicht vorhanden. Richtig! Die neue Kort-Fehlerkategorie fehlende Küche (= fehlender Tag cuisine) ist so ein Beispiel. Das ist einer der Neuerungen des Kort Games. Die Daten kommen von meiner EOSMBOne (d.h. aus osm2pgsql). LG, Stefan Am 23. Juni 2013 15:18 schrieb Peter Wendorff wendo...@uni-paderborn.de: Hi. (Kürzungen in den Folgenden Zitaten nur abschnittsweise, deshalb nicht im Einzelnen kenntlich gemacht) Am 23.06.2013 14:04, schrieb Stefan Keller: Zu deinen Verbesserungsvorschlägen: Am 19. Juni 2013 10:25 schrieb Martin Raifer tyr@gmail.com: 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. Klar ist das eine Definitionsfrage, was man als Fehler und was nur als Warnung betrachtet, aber ich denke, die einzig sinnvolle Definition hier, wenn es sich um das Bearbeiten von OSM-Daten handelt, ist die, dass ich, um etwas einen Fehler zu nennen, schon sicher sein sollte, dass es falsch ist. Ein Fehler sagt dem Empfänger der dazugehörigen Meldung: So ist das falsch, pfui! Eine Warnung ist dagegen eher: sag mal: das, was du da grade gemacht hast, ist zwar möglich, aber zumindest ungewöhnlich. Hast du das wirklich so gemeint? Es gibt eigentlich noch eine dritte Kategorie, und das sind die fehlenden Daten. Nicht falsch, aber eben einfach nicht vorhanden. Fehler werden daraus nur, wenn man in der Auswertung Zufällig andere Default-Annahmen trifft als man müsste ;) Zu dieser Kategorie gehören die lokalisierten name-Tags. ein nicht-lokalisierter name-Tag irgendwo mitten in Deutschland, der den Namen auf Deutsch enthält, ist doch erstmal nicht falsch, das ist der Name. Mitten in Deutschland wird auch jede Software, die das berücksichtigen will, selst mit groben Heuristiken diesen Namen als deutschsprachig interpretieren (als best-guess eben). Deshalb alle name-Tags ohne sprachvariante als Fehler zu bezeichnen, ist falsch, und auch eine Warnung ist zumindest regional zu hoch gegriffen. Wenn wir tatsächlich wollten, dass die OSM-Datenbank für jeden Namen mindestens einen name:xx-Tag enthält, dann wär das schonmal 'ne ganz schöne Hausnummer: laut Taginfo gibt es in osm: name: 35.535.456 mal der verbreitetste lokalisierte Tag dazu ist name:en: 831.929 mal - das sind 2,34% danach kommen: name:ru (314.898, 0,89%) name:ja (241.130, 0,68%) name:fr (203.957, 0,57%) name:de (182.59, 0,51%) und so weiter. Ganz grob überschlagen gibt es etwa zehnmal so viele name-Tags wie alle lokalisierten Name-Tags zusammengenommen. Wenn man das also als Warnung beanstanden würde, sollte man erstmal generell in osm propagieren, dass generell lokalisierte Namen angegeben werden sollten - und das ist, soweit ich bisherige Diskussionen dazu im Kopf habe, zwar nicht verpönt, aber bei weitem nicht Konsens. Eine Ausnahme allerdings sehe ich schon: WENN ein Objekt - ein name-Tag hat - und mindestens ein lokalisiertes name:** besitzt, - und keines der lokalisierten name:**-Tags im name-Tag enthalten ist (als Teil des Namens, damit auch die Kombinierten name-Tags wie Brüssel/Bruxxelex oder so nicht als fehler erkannt werden), DANN fehlt offensichtlich mindestens ein name, und der ist dann auch sinnvoll einzutragen, z.B., um bei textbasierten OSM-Diensten die Browser-Sprache bedienen zu können. Gruß Peter ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Sprache des Namens Fehler in Kort.
Am 23.06.2013, 15:18 Uhr, schrieb Peter Wendorff wendo...@uni-paderborn.de: [...] Wenn man das also als Warnung beanstanden würde, sollte man erstmal generell in osm propagieren, dass generell lokalisierte Namen angegeben werden sollten - und das ist, soweit ich bisherige Diskussionen dazu im Kopf habe, zwar nicht verpönt, aber bei weitem nicht Konsens. Darum geht es in bei den hier angesprochenen Kort-Aufträgen bzw. KeepRight-Warnungen auch gar nicht. Eine Ausnahme allerdings sehe ich schon: WENN ein Objekt - ein name-Tag hat - und mindestens ein lokalisiertes name:** besitzt, - und keines der lokalisierten name:**-Tags im name-Tag enthalten ist (als Teil des Namens, damit auch die Kombinierten name-Tags wie Brüssel/Bruxxelex oder so nicht als fehler erkannt werden), DANN fehlt offensichtlich mindestens ein name, und der ist dann auch sinnvoll einzutragen, z.B., um bei textbasierten OSM-Diensten die Browser-Sprache bedienen zu können. Genau davon sprechen wir hier die ganze Zeit. ;) Der Standard-Use-Case für die redundante Eintragung des Namens ist beispielsweise in etwa folgender: Man möchte eine Karte erstellen, die Labels in folgender Sprach-Reihenfolge anzeigt: 1. Deutsch, 2. Englisch, 3. der lokale Name (siehe http://mlm.jochentopf.com/). Wenn nun bei München kein redundantes name:de=München angegeben ist (also nur name=München name:en=Munich), wird es für den Renderer sehr schwierig die Karte wie gewünscht anzuzeigen; wahrscheinlicher würde dann der englische Name angezeigt werden. Allerdings ist dein Kritierium keines der lokalisierten name:**-Tags [ist] im name-Tag enthalten auch nicht hinreichend. Das wieso werde ich in einem weiteren Posting gleich ausführen. Grüße Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Sprache des Namens Fehler in Kort.
Hallo Martin Am 23. Juni 2013 17:48 schrieb Martin Raifer tyr@gmail.com: Genau davon sprechen wir hier die ganze Zeit. ;) Der Standard-Use-Case für die redundante Eintragung des Namens ist beispielsweise in etwa folgender: Man möchte eine Karte erstellen, die Labels in folgender Sprach-Reihenfolge anzeigt: 1. Deutsch, 2. Englisch, 3. der lokale Name (siehe http://mlm.jochentopf.com/). Wenn nun bei München kein redundantes name:de=München angegeben ist (also nur name=München name:en=Munich), wird es für den Renderer sehr schwierig die Karte wie gewünscht anzuzeigen; wahrscheinlicher würde dann der englische Name angezeigt werden. Ich bin immer noch nicht ganz sicher, ob wir uns verstehen, denn die Redundanz bei name=München und name:de=München scheint mir kaum vermeidbar. Der Tag name=München ist für mich der offizielle Name (Endonym). Der Tag name:de=München zeigt einem Programm, wie der Name auf *deutsch* heisst (ähnlich wie name:de=Peking); das :de ist hier wichtig. Lokalisierte Namen sind für mich ein Zusatz. Für München könnte es name:gsw=Minga sein. LG, Stefan Am 23. Juni 2013 17:48 schrieb Martin Raifer tyr@gmail.com: Am 23.06.2013, 15:18 Uhr, schrieb Peter Wendorff wendo...@uni-paderborn.de: [...] Wenn man das also als Warnung beanstanden würde, sollte man erstmal generell in osm propagieren, dass generell lokalisierte Namen angegeben werden sollten - und das ist, soweit ich bisherige Diskussionen dazu im Kopf habe, zwar nicht verpönt, aber bei weitem nicht Konsens. Darum geht es in bei den hier angesprochenen Kort-Aufträgen bzw. KeepRight-Warnungen auch gar nicht. Eine Ausnahme allerdings sehe ich schon: WENN ein Objekt - ein name-Tag hat - und mindestens ein lokalisiertes name:** besitzt, - und keines der lokalisierten name:**-Tags im name-Tag enthalten ist (als Teil des Namens, damit auch die Kombinierten name-Tags wie Brüssel/Bruxxelex oder so nicht als fehler erkannt werden), DANN fehlt offensichtlich mindestens ein name, und der ist dann auch sinnvoll einzutragen, z.B., um bei textbasierten OSM-Diensten die Browser-Sprache bedienen zu können. Genau davon sprechen wir hier die ganze Zeit. ;) Der Standard-Use-Case für die redundante Eintragung des Namens ist beispielsweise in etwa folgender: Man möchte eine Karte erstellen, die Labels in folgender Sprach-Reihenfolge anzeigt: 1. Deutsch, 2. Englisch, 3. der lokale Name (siehe http://mlm.jochentopf.com/). Wenn nun bei München kein redundantes name:de=München angegeben ist (also nur name=München name:en=Munich), wird es für den Renderer sehr schwierig die Karte wie gewünscht anzuzeigen; wahrscheinlicher würde dann der englische Name angezeigt werden. Allerdings ist dein Kritierium keines der lokalisierten name:**-Tags [ist] im name-Tag enthalten auch nicht hinreichend. Das wieso werde ich in einem weiteren Posting gleich ausführen. Grüße Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Sprache des Namens Fehler in Kort.
Am 23.06.2013, 18:36 Uhr, schrieb Stefan Keller sfkel...@gmail.com: Ich bin immer noch nicht ganz sicher, ob wir uns verstehen, denn die Redundanz bei name=München und name:de=München scheint mir kaum vermeidbar. Der Tag name=München ist für mich der offizielle Name (Endonym). Der Tag name:de=München zeigt einem Programm, wie der Name auf *deutsch* heisst (ähnlich wie name:de=Peking); das :de ist hier wichtig. Lokalisierte Namen sind für mich ein Zusatz. Für München könnte es name:gsw=Minga sein. Ich glaube dass wir uns schon verstehen, denn genau das wollte ich durch mein Beispiel unterstreichen. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Sprache des Namens Fehler in Kort.
Eine bewusst gewählte Eigenheit von Kort ist, dass nur ein Tag aufs Mal korrigiert bzw. ergänzt werden kann (d.h. es wird z.B. zu bei name=Biel/Bienne der Tag name:de=Biel ergänzt). Bei der nächsten Aktualisierung sollte es dann immer noch als Fehler taxiert werden, weil da ein weiterer name:XX fehlt (nämlich name:fr=Bienne). Bin nun nicht unsicher, ob das keepright so handhabt. Falls ja, wird es auch in Kort nochmals fragen und man kann name:fr=Bienne eintgragen. Dann haben also Keepright und Kort doch nicht so unrecht, dass ein name:XX fehlt!? Man könnte höchstens ergänzen dass ein oder mehrere name:XX fehlen. LG, Stefan Am 23. Juni 2013 18:47 schrieb Martin Raifer tyr@gmail.com: Am 23.06.2013, 18:36 Uhr, schrieb Stefan Keller sfkel...@gmail.com: Ich bin immer noch nicht ganz sicher, ob wir uns verstehen, denn die Redundanz bei name=München und name:de=München scheint mir kaum vermeidbar. Der Tag name=München ist für mich der offizielle Name (Endonym). Der Tag name:de=München zeigt einem Programm, wie der Name auf *deutsch* heisst (ähnlich wie name:de=Peking); das :de ist hier wichtig. Lokalisierte Namen sind für mich ein Zusatz. Für München könnte es name:gsw=Minga sein. Ich glaube dass wir uns schon verstehen, denn genau das wollte ich durch mein Beispiel unterstreichen. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Sprache des Namens Fehler in Kort.
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? OK: Ich nehme mal an, dass es Konsens ist, bei Namen, die bereits teilweise multilingual erfasst sind, auch die ursprüngliche(n) Haupt-Sprache(n) des name-Tags redundant mit aufzunehmen. Die Frage ist jetzt, wie man am besten herausfindet, ob eines oder mehrere dieser name:* Tags fehlen. == Naive Kriterien == Zur Zeit überprüft KeepRight folgendes Kriterium: Ist keines der lokalisierten name:**-Tags mit dem name-Tag identisch? Das funktioniert aber, wie bereits gesagt, bei mehrsprachigen name-Tags nicht. Beispiel: name=Bruxelles - Brussel name:fr=Bruxelles name:nl=Brussel Die von Peter vorgeschlagene Variante: Ist keines der lokalisierten name:**-Tags im name-Tag enthalten? Dieses Kriterium deckt aber nicht alle Fälle ab. Gegenbeispiele: name=Bolzano - Bozen name:it=Bolzano name:de=Bozen name:lld=Bulsan Hier würde ein evtl. fehlendes name:it oder name:de nicht entdeckt werden. name=Roma name:it=Roma name:en=Rome name:de=Rom Hier würde ein evtl. fehlendes name:it nicht gefunden werden. == Besseres Kriterium == Mit folgendem Algorithmus hatte ich experimentiert: 1. Man iteriert über alle name:* und markiert alle Vorkommen des jeweiligen Namen im name Tag. 2. Anschließend entfernt man alle markierten Zeichen. 3. Wenn der Rest nur mehr aus Whitespace und/oder Trennzeichen [-/,;()] besteht, dann sollte der Name OK sein. Meines Erachtens nach werden damit die meisten Fälle zuverlässig abgedeckt. Viele Grüße Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Sprache des Namens Fehler in Kort.
Am 23.06.2013, 19:03 Uhr, schrieb Stefan Keller sfkel...@gmail.com Dann haben also Keepright und Kort doch nicht so unrecht, dass ein name:XX fehlt!? Nein, denn der Fehler wird aktuell auch dann angezeigt, wenn die jeweiligen name:XX _nicht_ fehlen: http://keepright.ipax.at/report_map.php?zoom=18lat=46.66927lon=11.15956layers=B0Tch=0%2C360show_ign=1show_tmpign=1 vs. http://www.openstreetmap.org/browse/node/64777070 Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Sprache des Namens Fehler in Kort.
Am 23.06.2013 19:06, schrieb Martin Raifer: Die von Peter vorgeschlagene Variante: Ist keines der lokalisierten name:**-Tags im name-Tag enthalten? Dieses Kriterium deckt aber nicht alle Fälle ab. Gegenbeispiele: name=Bolzano - Bozen name:it=Bolzano name:de=Bozen name:lld=Bulsan Hier würde ein evtl. fehlendes name:it oder name:de nicht entdeckt werden. Moment! Es geht nicht darum, jede Sprachvariante, auch nicht, jede regional offizielle Sprache, zu entdecken. Aber du hast schon recht: Man könnte das noch weiter verfeinern. name=Roma name:it=Roma name:en=Rome name:de=Rom Hier würde ein evtl. fehlendes name:it nicht gefunden werden. Stimmt, wobei ich mit meiner Teilstring-Idee vermutlich vor allem nicht weit genug gegangen bin. Verfeinert man das und fordert einen sinnvoll abgetrennten Teil, dan wird Roma doch als fehlend markiert. In Bolzano - Bozen hingegen würde Bolzano und Bozen gesucht, wenn nicht Bolzano - Bozen als name:xx existiert. == Besseres Kriterium == Mit folgendem Algorithmus hatte ich experimentiert: 1. Man iteriert über alle name:* und markiert alle Vorkommen des jeweiligen Namen im name Tag. 2. Anschließend entfernt man alle markierten Zeichen. 3. Wenn der Rest nur mehr aus Whitespace und/oder Trennzeichen [-/,;()] besteht, dann sollte der Name OK sein. Meines Erachtens nach werden damit die meisten Fälle zuverlässig abgedeckt. Das klingt nicht schlecht, bisher finde ich noch keine Gegenbeispiele. Hast Du Gegenbeispiele? Immerhin redest du von den meisten Fällen. Gruß Peter ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Sprache des Namens Fehler in Kort.
Am 23.06.2013, 20:19 Uhr, schrieb Peter Wendorff wendo...@uni-paderborn.de: Das klingt nicht schlecht, bisher finde ich noch keine Gegenbeispiele. Hast Du Gegenbeispiele? Immerhin redest du von den meisten Fällen. Konkretes Gegenbeispiel habe ich auch keines. Aber theoretisch könnte sich ein Name in zwei (oder mehr) anderen Sprachen so ungeschickt überschneiden, dass der Algorithmus ausgehebelt wird. Konstruiertes Beispiel: name=Great Mount Doom name:1=Mount Doom name:2=Great Mount Keine Ahnung, ob das irgendwo auf der Welt vorkommt. Viel häufiger dürfte aber der Fall sein, dass ein Name in mehreren Sprachen gleich lautet: name=London name:de=London Hier fehlt offensichtlich das name:en=London, allerdings kann man hier unabhängig vom Algorithmus (ohne Vergleichs-Datenbank) nicht viel machen... Grüße Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Sprache des Namens Fehler in Kort.
Am 23.06.2013 15:18, schrieb Peter Wendorff: Wenn man das also als Warnung beanstanden würde, sollte man erstmal generell in osm propagieren, dass generell lokalisierte Namen angegeben werden sollten - und das ist, soweit ich bisherige Diskussionen dazu im Kopf habe, zwar nicht verpönt, aber bei weitem nicht Konsens. Ich denke, das liegt auch einfach daran, dass der Renderer (=osm.org) das nicht unterstützt. Es wäre vielleicht sinnvoll, dass der Renderer einfach den name-Tag komplett ignoriert und NUR noch die einzelnen name:xx unterstützt werden. Für Deutschland ist das nämlich nicht notwendig, von daher wird da niemals jemand einen name:de schreiben. Bei anderen Ländern schon. Es wäre dann natürlich möglich, in Ländern, wo kein name:xx-Tag vorhanden ist, einfach den name auf name:xx zu verschieben. Aber das Problem liegt halt im Renderer. Solange der mehrsprachige Renderer, der hier vor einiger Zeit mal vorgestellt wurde, nicht a) auf der OSM-Hauptseite, b) auf allen anderen Webseiten direkt unterstützt wird, passiert da nichts. Außerdem sollte JOSM z.B. direkt immer den lokalisierten name-Tag anzeigen und bei dem normalen name direkt eine Warnung. Im Grunde ist die einzige Möglichkeit aus dem Schlamassel herauszukommen, den name-Tag komplett zu entfernen. Aber wenn der Renderer da nicht mitspielt, dann wird das auch nichts. Dieses aktuelle „Ich packe einfach mal alles was auf dem Straßenschild steht in den name-Tag“ sieht einfach nur unglaublich bescheuert aus. Also, was gemacht werden muss: 1. OSM.org muss den mehrsprachigen Renderer unterstützen. Dann muss entsprechend der Browser-Sprache automatisch für jeden Benutzer die entsprechende Sprache angezeigt werden (deutscher Browser sieht name:de). 2. Alle name-Tags müssen verschoben werden (in USA nach name:en, in Deutschland nach name:de. In Belgien, der Schweiz usw. wird wahrscheinlich sowieso schon alles mehrsprachig existieren, da muss man das notfalls manuell machen). 3. JOSM/Potlatch/was auch immer muss je nach Ort automatisch in den entsprechenden name:xx-Tag schreiben. In Deutschland nach name:de. In der Schweiz/Belgien usw. müssen beide Felder gleichzeitig angezeigt werden. 4. In JOSM muss endlich eine tabellarische Anzeige der Namen der Nodes her. Sonst kann man das nicht vernünftig taggen. (-- Unglaublich wichtig für mehrsprachige Karten!) 5. Anschließend alle name= löschen. Gerne auch mit einem Bot dafür sorgen, dass es weg bleibt. Dann hätte man wesentlich weniger Probleme. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Sprache des Namens Fehler in Kort.
Hans Schmidt schrieb: Also, was gemacht werden muss: [1-5] Perfekt zusammengefasst! Grüße, Dirk -- Local time :: Ortszeit :: DE-HH 2013-06-24T01:57:10+0200 signature.asc Description: PGP signature ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Sprache des Namens Fehler in Kort.
Am 23. Juni 2013 21:18 schrieb Hans Schmidt z0idb...@gmx.de: 2. Alle name-Tags müssen verschoben werden Die name-Tags sind dazu da, das zu erfassen, was Mapper sehen und Renderer ohne weitere Angaben darstellen können. Deren Values sollten daher nicht verschoben sondern ggf. kopiert werden (z.B. nach name:de=München). Vgl. auch meine Ausführungen zu Endonyme und Exonymen oben. LG, Stefan Am 24. Juni 2013 01:57 schrieb Dirk Sohler s...@0x7be.de: Hans Schmidt schrieb: Also, was gemacht werden muss: [1-5] Perfekt zusammengefasst! Grüße, Dirk -- Local time :: Ortszeit :: DE-HH 2013-06-24T01:57:10+0200 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Sprache des Namens Fehler in Kort.
Stefan Keller schrieb: Die name-Tags sind dazu da, das zu erfassen, was Mapper sehen und Renderer ohne weitere Angaben darstellen können. Deren Values sollten daher nicht verschoben sondern ggf. kopiert werden (z.B. nach name:de=München). Wenn langfristig name rausfliegen soll, und durch name:de ersetzt werden soll (was nur sinnvoll wäre), muss es irgendwann verschoben werden, spätestens mit Version N+1, wenn name nicht mehr unterstützt wird, muss bis Version N jegliches vorkommen von name durch name:de ersetzt werden (name:de, oder name:en, oder name:ru, etc.). Je eher das gemacht wird, desto besser. Grüße, Dirk -- Local time :: Ortszeit :: DE-HH 2013-06-24T04:37:59+0200 signature.asc Description: PGP signature ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Sprache des Namens Fehler in Kort.
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@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Sprache des Namens Fehler in Kort. War: Kort Game mit neuer Aktion/Kampagne dieses Wochenende!
Zum language unknown Layer von keepright hatte ich bereits vor einiger Zeit eine kurze Diskussion mit dem Macher von keepright. Mein Fazit: Fakt ist, dass der für diesen Layer verwendete Fehlersuch-Algorithmus spätestens bei echt mehrsprachigen Regionen versagt und nur noch false-positives ausspuckt. Beispiel: Freiburg[1] (name=Fribourg - Freiburg, name:de=Freiburg, name:fr=Fribourg) wird in keepright [2] fälschlicherweise angezeigt. Oder noch extremer: fast Alles in Südtirol[3], Brüssel, … Unter anderem deshalb befindet sich dieser Layer in keepright auch in der Kategorie Warnung und nicht unter Fehler. Das Feature in keepright mag zwar gut gemeint sein und könnte für nicht-mehrsprachige Regionen vielleicht auch sinvoll sein. Für mehrsprachige Namen bedarf es aber einer genaueren Auswertung um herauszufinden in welchen Sprachen der Name vorliegt. Jedenfalls wird Kort durch das Einbinden dieser Warnungen in mehrsprachigen Regionen leider komplett unspielbar. :( Liebe Grüße Martin [1] http://www.openstreetmap.org/browse/node/1685926271 [2] http://keepright.ipax.at/report_map.php?zoom=18lat=46.80319lon=7.1523layers=B0Tch=0%2C360show_ign=1show_tmpign=1 [3] http://keepright.ipax.at/report_map.php?zoom=16lat=46.67399lon=11.15604layers=B0Tch=0%2C360show_ign=1show_tmpign=1 Am 18.06.2013, 16:04 Uhr, schrieb Stefan Keller sfkel...@gmail.com: Hallo Simeon Vorab: Kort basiert auf Daten von keepright und neu auf mittels osm2pgsql nach PostgreSQL aufbereitete Daten. Sprache des Namens ist ein Fehlertyp von keepright. Wie soll ein Auswertesystem merken in welcher Sprache ein Name geschrieben ist? Sprache des Namens finde ich sehr sinnvoll, denn es ist durchaus nicht so, dass Ländergrenzen eine Sprachgrenze bilden würden, geschweige denn dass innerhalb eines Landes oder Region nur eine Sprache gesprochen wird (auch wenn das einige Landsmänner aus DE, FR, IT oder den USA immer wieder meinen ;-)). LG, Stefan ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Sprache des Namens Fehler in Kort. War: Kort Game mit neuer Aktion/Kampagne dieses Wochenende!
Hallo Martin Am 18. Juni 2013 16:44 schrieb Martin Raifer tyr@gmail.com: Fakt ist, dass der für diesen Layer verwendete Fehlersuch-Algorithmus spätestens bei echt mehrsprachigen Regionen versagt und nur noch false-positives ausspuckt. Die absolute Angabe nur noch... scheint mir etwas übertrieben. ... Das Feature in keepright mag zwar gut gemeint sein und könnte für nicht-mehrsprachige Regionen vielleicht auch sinvoll sein. Für mehrsprachige Namen bedarf es aber einer genaueren Auswertung um herauszufinden in welchen Sprachen der Name vorliegt. Genau das ist Teil der Aufgabe beim Spielen. Und sowohl bei keepright (ignore) wie auch bei Kort (nicht lösbar) kann man false positives als solche angeben. Jedenfalls wird Kort durch das Einbinden dieser Warnungen in mehrsprachigen Regionen leider komplett unspielbar. :( Komplett unspielbar?? Erstens ist es - wie du selber sagst - in einsprachigen Regionen offenbar spielbar, zweitens gibt es noch sieben andere Fehlertypen (vgl. [1]). Warum also das Kind gleich mit dem Bade ausschütten? LG, Stefan [1] https://kort.uservoice.com/knowledgebase/articles/206970-was-f%C3%BCr-auftr%C3%A4ge-und-%C3%9Cberpr%C3%BCfungen-gibt-es- Am 18. Juni 2013 16:44 schrieb Martin Raifer tyr@gmail.com: Zum language unknown Layer von keepright hatte ich bereits vor einiger Zeit eine kurze Diskussion mit dem Macher von keepright. Mein Fazit: Fakt ist, dass der für diesen Layer verwendete Fehlersuch-Algorithmus spätestens bei echt mehrsprachigen Regionen versagt und nur noch false-positives ausspuckt. Beispiel: Freiburg[1] (name=Fribourg - Freiburg, name:de=Freiburg, name:fr=Fribourg) wird in keepright [2] fälschlicherweise angezeigt. Oder noch extremer: fast Alles in Südtirol[3], Brüssel, … Unter anderem deshalb befindet sich dieser Layer in keepright auch in der Kategorie Warnung und nicht unter Fehler. Das Feature in keepright mag zwar gut gemeint sein und könnte für nicht-mehrsprachige Regionen vielleicht auch sinvoll sein. Für mehrsprachige Namen bedarf es aber einer genaueren Auswertung um herauszufinden in welchen Sprachen der Name vorliegt. Jedenfalls wird Kort durch das Einbinden dieser Warnungen in mehrsprachigen Regionen leider komplett unspielbar. :( Liebe Grüße Martin [1] http://www.openstreetmap.org/browse/node/1685926271 [2] http://keepright.ipax.at/report_map.php?zoom=18lat=46.80319lon=7.1523layers=B0Tch=0%2C360show_ign=1show_tmpign=1 [3] http://keepright.ipax.at/report_map.php?zoom=16lat=46.67399lon=11.15604layers=B0Tch=0%2C360show_ign=1show_tmpign=1 Am 18.06.2013, 16:04 Uhr, schrieb Stefan Keller sfkel...@gmail.com: Hallo Simeon Vorab: Kort basiert auf Daten von keepright und neu auf mittels osm2pgsql nach PostgreSQL aufbereitete Daten. Sprache des Namens ist ein Fehlertyp von keepright. Wie soll ein Auswertesystem merken in welcher Sprache ein Name geschrieben ist? Sprache des Namens finde ich sehr sinnvoll, denn es ist durchaus nicht so, dass Ländergrenzen eine Sprachgrenze bilden würden, geschweige denn dass innerhalb eines Landes oder Region nur eine Sprache gesprochen wird (auch wenn das einige Landsmänner aus DE, FR, IT oder den USA immer wieder meinen ;-)). LG, Stefan ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
