Sehe ich genauso! Am Donnerstag, 6. Februar 2014 schrieb Peter Wendorff :
> Und wie viel Auswertung verlangst du für jede Software? > Wir sind uns doch einig, dass es nicht schwieriger für Mapper ist, die > ausgeschriebene Fassung in den name-Tag zu schreiben. > Für Software ist es einfach, eine vorhandene Langform bei Bedarf > abzukürzen. > Damit eine Software - egal welche - die Kurzform korrekt verlängern > kann, muss sie > 1) die Sprache kennen, das ist nur selten direkt der Fall, > alternativ > 1a) aus der Lage die Sprache erraten - das geht, erfordert aber eine > entsprechende Heuristik sowie eine geometrische Abfrage, wo der Name auf > der Welt vorkommt, > 2) Kommt ein Name mit einer entsprechenden Abkürzung in einem Gebiet > vor, in dem eigentlich eine andere Sprache vorherrscht, so muss der > Mapper dies wissen und entgegen deiner Regel die Langform eintragen, > weil jede Heuristik oder Sprachsuche sonst fehlschlagen muss. > > Mit (2) wird deine Regel also zu: > Die Langform in name schadet nicht, aber für bestimmte Abkürzungen (im > Deutschen mindestens Dr. für Doktor, St. für Sankt und Str. für Straße, > wobei bei einem str am ende des Wortes auf keinen Fall der Punkt > vergessen werden darf), ist es in Ordnung die Abkürzung als Abkürzung zu > belassen, weil wir von Softwareentwicklern entsprechende > Auswertungsintelligenz erwarten. > > Alleine für deine erste Näherung (und dass das auch nur eine Näherung > ist, betonst du ja), braucht jede Software also entweder eine Verbindung > zum Netz oder eine Datenbank, die eine Zuordnung zwischen Land und > Sprache(n) zu bilden. > Das erfordert aber schon, dass ich zu dem Namen das Land kenne, sonst > brauch ich auch noch eine Zuordnung von Koordinatenbereichen zum Land > (oder direkt zur Sprache), denn im Zweifelsfall gibt es in den OSM-Daten > keine Informationen zum Land, weil diese z.B. nur eine Stadt abdecken, > und auch addr:country nicht belegt ist. > > Noch mal: Ich weiß, dass das möglich ist; erst Recht mit Referenz auf > fremde Quellen; aber wofür OSM nutzen, wenn wir hinterher wikipedia, > ethnologue.com und alles mögliche andere brauchen, um die Daten nutzen > zu können. > > Ich hab nichts dagegen, Daten einzusparen, wo sie wirklich sinnlos sind > - z.B. in der aktuellen und wiederkehrenden Diskussion um > Mengen-Relationen; aber hier ist es sehr wenig bis gar kein Aufwand, der > viel bis sehr viel Aufwand auf anderer Seite spart und außerdem in OSM > alleine eine eindeutige Situation schafft, die keinen > Interpretationsspielraum braucht, erst recht keine Drittquellen. > > Gruß > Peter > > Am 06.02.2014 23:20, schrieb Fabian Schmidt: > > > > Am 06.02.14 schrieb Peter Wendorff: > > > >> Ich weiß nicht, ob du das mitgekriegt hast, aber Dr. steht auch im > >> Englischen nicht nur für Drive. Zugegeben - da heißt es dann Doctor, > >> nicht Doktor... > > > > Probier es aus: das DFKI interpretiert "Welcome to Dr. Mulholland!" als > > Doctor. > > > >> Klar: Lässt sich durch Angabe unterschiedlicher name:[lang]-Werte lösen > >> - aber wenn die nicht da sind, hilfts eben nicht. > > > > Entweder interpretiere ich die Sprache richtig, dann weiß ich, was die > > Abkürzung heißt. Oder ich spreche den Namen falsch aus und hab damit ein > > größeres Problem als mit dem Unterschied Saint - Sankt. > > > >> Für den > >> Name-Tag ist das schon schwieriger, weil die Sprache nicht bekannt ist. > >> Das geht also nur, wenn die Sprache durch die Namensgleichheit mit einem > >> lokalisierten name-Tag identifiziert werden kann; > > > > Einfacher ist, anderswo anhand der Sprachgrenzen rauszufinden, was denn > > dort gesprochen werden kann, in erster *Näherung* schau ich bei > > ethnologue.com o.ä., welche Hauptsprache es in dem Land gibt. > > > >> wär ich mir bei z.B. einer südamerikanischen Kirche nicht sicher, ob > >> der Name jetzt im Original Spanisch, Portugisisch oder Deutsch ist, > >> lässt sich anhand des "St" aber nicht unbedingt ablesen > > > > San und São haben kein t, die Sprachgrenze in Südamerika ist sehr klar, > > und warum sollte der Name deutsch sein? > > > > > > Gruß, Fabian. > > > > > > _______________________________________________ > > Talk-de mailing list > > Talk-de@openstreetmap.org <javascript:;> > > https://lists.openstreetmap.org/listinfo/talk-de > > > > > _______________________________________________ > Talk-de mailing list > Talk-de@openstreetmap.org <javascript:;> > https://lists.openstreetmap.org/listinfo/talk-de > _______________________________________________ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
