@Thierry : Tu as résumé le fond du problème. Je n'ai pas encore traité du X-SAMPA mais j'ai plus l'impression que c'est un parallèle ASCII de l'IPA Unicode d'ailleurs il y a des types phonétiques qui sont dans X-SAMPA et qui ne sont pas dans l'IPA
J'ai pas encore trouvé une seule valeur utilisant le tag name:fr-fonapi et le fameux codage BCP47 Celui est mentionné par Philippe Verdy : - http://comments.gmane.org/gmane.comp.gis.openstreetmap.region.fr/72406 Ducoup je sais qu'Eric nous parle OsmAnd sur android ;-) L'alphabet phonétique international (IPA est l'abréviation anglaise) répond est un standard iso (15924) Je suis allé faire un tour sur la doc BCP 47 <https://tools.ietf.org/html/bcp47> et donc la structure n'est pas encore la bonne car en me tapant la doc je viens de voir qu'on parle d'un suffixe *fonipa*. Surement une erreur involontaire dans la page de Wikipedia. En même temps je préfère avoir les informations à la source. *An example of such a "no-prefix" variant is the subtag 'fonipa', which represents the* * International Phonetic Alphabet, a scheme that can be used to transcribe many languages* Je suis allé sur du code Android et j'ai trouvé ça comme variante de language 1. FONIPA{"alphabet phonétique international"} 2. FONUPA{"alphabet phonétique ouralique"} name:fonipa est valable pour une traduction international name:fr-fonipa pour la France en respect à la RFC 5646 <https://tools.ietf.org/html/rfc5646> Le 27 juin 2015 16:33, Thierry Bézecourt <[email protected]> a écrit : > Bonjour, > > En ce qui concerne les chiffres romains, je vois mal comment une détection > automatisée pourrait fonctionner. Quelle expression régulière pourra-t-elle > deviner que "George V" utilise un chiffre romain mais pas "Avenue D" (à > Manhattan), "Quai C" ou "Escalier I" ? > > Exemple : cette requête Overpass (certes imparfaite) essaie de détecter > les cas d'utilisation de nombres en chiffres romains. Difficile de séparer > les cas où c'est vraiment des chiffres romains (pas si nombreux) de ceux où > c'est une lettre : http://overpass-turbo.eu/s/a8O > > Et surtout, comme le signalait Jérôme Seigneuret, le problème des chiffres > romains n'est que l'arbre qui cache la forêt des prononciations locales ou > irrégulières. Un GPS m'a un jour conseillé de prendre la direction "Kimpé" > lors d'un voyage en Bretagne... > > En fait, c'est même plus général que le GPS. La prononciation des données > d'OSM est une question générale d'accessibilité (malvoyants, etc.), que > seul un champ spécifique peut résoudre. Il n'y a pas des réflexions à ce > sujet ? > > Le 27/06/2015 03:41, Philippe Verdy a écrit : > >> >> Bref on revient à la solution de fournir un alt_name=* >> > > Pourquoi alt_name ? J'attends de mon GPS vocal qu'il utilise le "name", > puisque c'est lui qui figure sur les panneaux en bord de route. Et si on > met la prononciation dans le alt_name parce qu'on sait que certains GPS > utilisent le alt_name d'une certaine manière, c'est qu'on tague pour le > GPS... > > Il me paraît bien plus logique, du point de vue de la base de données > comme des utilisateurs, d'utiliser un champ spécifique, quel que soit son > nom (name:fr-fonapi, name:phonetics, name:fr:phonetics). Ensuite, celui qui > exporte les données OSM vers un GPS pourra toujours, le cas échéant, mettre > ce champ là où ce sera le plus utile pour le GPS (ou pour tel lecteur > d'écran). > > D'autant qu'on n'est pas obligé d'exiger la saisie en API. Une saisie > approximative ("Quimpère", "George 5") pourrait faire l'affaire. Il y a > aussi X-SAMPA, version ASCII de l'API, mais je ne sais pas si c'est > vraiment une simplification, surtout pour la langue française. > > -- > Thierry B. > > > _______________________________________________ > Talk-fr mailing list > [email protected] > https://lists.openstreetmap.org/listinfo/talk-fr >
_______________________________________________ Talk-fr mailing list [email protected] https://lists.openstreetmap.org/listinfo/talk-fr
