Re: [OSM-talk-fr] Sous relations itinéraires cyclables
Bonjour, Effectivement, il peut y avoir une discussion autour de ces données. Mais la question portait plus ici sur les différentes modélisations possibles des relations. Pas d'idées ? Gaël. -- View this message in context: http://gis.19327.n5.nabble.com/Sous-relations-itineraires-cyclables-tp5848869p5848950.html Sent from the France mailing list archive at Nabble.com. ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Sous relations itinéraires cyclables
Je pense qu'il faut s'intéresser de prêt à ce sujet, car il risque de conditionner le futur des relations cyclables. Mais comme je ne maitrise pas le sujet, je m'abstiens Stf Le 26/06/2015 10:16, GaelADT a écrit : Bonjour, Effectivement, il peut y avoir une discussion autour de ces données. Mais la question portait plus ici sur les différentes modélisations possibles des relations. Pas d'idées ? Gaël. -- View this message in context: http://gis.19327.n5.nabble.com/Sous-relations-itineraires-cyclables-tp5848869p5848950.html Sent from the France mailing list archive at Nabble.com. ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Sous relations itinéraires cyclables
J'essaye de résumer les discussions que l'on a eu avec notre stagiaire. Je rappelle qu'il s'agit de relations de plusieurs centaines de km : 1) Il serait possible d'avoir une relation avec uniquement des ways dedans. On est d'accord, c'est très moche, et compliqué à maintenir. Mais pourtant ce que l'on a déjà sur certaines relations en France. 2) Il est possible d'avoir une relation composée d'autres relations (voies vertes) existantes et des ways. Exemple La Véloroute de la Meuse (relation 2096855) http://www.openstreetmap.org/relation/2096855 . C'est bien car on réutilise les voies vertes existantes. C'est un peu moche car on a plein de ways à côté. 3) On peut également faire un découpage de la véloroute en étapes. Ces étapes on bien souvent une existance (document papier et panneaux). Du coup on on aurait une véloroute composée de sous relations, où chacune de ses sous relations serait une étape clairement identifiée. Exempmle : La Vélodyssée (relation 4774799) : http://www.openstreetmap.org/relation/4774799 C'est plus joli non ? :) Gaël -- View this message in context: http://gis.19327.n5.nabble.com/Sous-relations-itineraires-cyclables-tp5848869p5848955.html Sent from the France mailing list archive at Nabble.com. ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Chiffres romains
Bof, on déplace la responsabilité d'une mauvaise gestion de la donnée de l'utilisateur vers le contributeur. Pour moi, la solution devrait venir de l'utilisateur, et il me semble qu'un dictionnaire, par exemple, permet de régler le problème. C'est pas d'ailleurs comme ça que procèdent les scripts bano, d'ailleurs ? Le 26/06/2015 18:02, Jo a écrit : Mais s'il n'y a que I ou V, il serait quasi impossible d'être sûr si c'est un chiffre romain. Qu'est-ce que vous pensez d'un nouveau tag? name_contains_numeral=5 ref_contains_numeral=3 ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Chiffres romains
Pour moi décrire le monde de façon explicite vaut mieux que décrire de façon opaque. Polyglot 2015-06-26 18:11 GMT+02:00 JB jb...@mailoo.org: Bof, on déplace la responsabilité d'une mauvaise gestion de la donnée de l'utilisateur vers le contributeur. Pour moi, la solution devrait venir de l'utilisateur, et il me semble qu'un dictionnaire, par exemple, permet de régler le problème. C'est pas d'ailleurs comme ça que procèdent les scripts bano, d'ailleurs ? Le 26/06/2015 18:02, Jo a écrit : Mais s'il n'y a que I ou V, il serait quasi impossible d'être sûr si c'est un chiffre romain. Qu'est-ce que vous pensez d'un nouveau tag? name_contains_numeral=5 ref_contains_numeral=3 ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Chiffres romains
Je crois qu'Éric voudrait savoir s'il existe un moyen pour qu'un synthétiseur vocal prononce une rue nommée Georges V comme si c'était écrit Georges 5, et non pas Georges Vé Francescu Le 26 juin 2015 15:19, Vincent Privat vincent.pri...@gmail.com a écrit : Tu peux préciser ce que tu ne parviens pas à faire avec JOSM ? Je ne vois pas de souci immédiat avec les chiffres romains. Le 26 juin 2015 2:00 PM, Eric Sibert courr...@eric.sibert.fr a écrit : Bonjour, Il y a moyen de saisir des chiffres romains dans OSM/Josm? Parce que quand le logiciel de guidage me parle de George vé ou Henry ivé, j'ai du mal :-p Je pourrais aussi avoir des références comportant des chiffres romains et pour certains traitements, ça serait bien que ce soit reconnu comme des nombres mais affiché comme des chiffres romains sur les cartes. Eric ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Chiffres romains
Mais s'il n'y a que I ou V, il serait quasi impossible d'être sûr si c'est un chiffre romain. Qu'est-ce que vous pensez d'un nouveau tag? name_contains_numeral=5 ref_contains_numeral=3 that way it's unambiguous for routers that are smart enough to take such tag into account. Jo 2015-06-26 17:29 GMT+02:00 Yves Pratter yves.prat...@laposte.net: Je pense que la synthèse vocale devrait gérer ça avec un dictionnaire. -- Yves Le 26 juin 2015 16:42, Eric SIBERT courr...@eric.sibert.fr a écrit : Je cherche un moyen pour indiquer que c'est n'est pas juste un enchaînement de lettre mais un nombre écrit en chiffres romains et pouvoir l'exploiter en conséquence par exemple pour une synthèse vocale. -- Éric ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Chiffres romains
@Vincent : Je pense que sa demande est simplement de voir si l'on peut avoir deux écritures au niveau balise afin de facilité l'interprétation du tag name pas les algos des logiciels de guidage @Eric: Je pense que le problème c'est l'interprétation du logiciel de guidage qui lie les chiffres Romains lettre par lettre... C'est pas avec JOSM (qui sert à faire de l'édition) que l'on peut changer le problème. C'est soit le référenciel OSM soit le logiciel de guidage. Malheureusement il n'y a pas un seul code page qui permet d'avoir les chiffres romain comme lettre isolé pour chaque chiffre romain. Les chiffre sont donc des lettres et sont interprétés phonétiquement comme tels. Le mieux serait de normaliser l'écriture afin de faciliter la détection et l'interprétation. Il y a aussi le cas des ref:D 8III qui sera lu dans ton cas Dé Trois i i i Ce que tu demandes c'est interprétation des chiffres mais on peut aussi aller plus loin sur l'interprétation des mots directement avec une transcription phonétique. En clair on force la diction en courcircuitant une parti de l'algorithme qui va servir à traduire un mot en phonétique. Je pense qu'isolé la partie chiffre romain (en mettant juste un espace pour séparer) et faire un algo de détection en regex permettrait de régler le problème de lecture. Mais, il faut voir si cette norme sera approuvé pour l'édition... Puis signaler le problème et la solution de détection éventuelle aux développeurs de ta solution de guidage. exemple George VI et D 8 III Dans les cas précédents les lettres chiffres romains ne sont pas collés au mot donc un regex est possible pour l'interprétation. Le problème c'est que le regex ne doit pas prendre les premières lettre dans le tag ref ... Car D est aussi un chiffre romain (500). Donc ça implique d'avoir des cas spéciaux partout pour une interprétation correcte ... La solution la plus simple est de proposer un tag de lecture phonétique. Cela corrige tous les problèmes d'interprétation: - les problèmes liés au contexte régionaux l'interprétation du s en fin de nom de commune par exemple l'interprétation des noms en alsacien (sheim prononcé saïm) - les problèmes de lecture des abréviations - les noms étrangers mal prononcés Il existe différents systèmes de transcription phonétique dont un qui est international. A voir si l'on peut faire un outil qui permettrait d'en facilité l'utilisation. exemple: name:Avenue George V name:phonetics:fr=*ˈævənju: **ʒɔrʒ sε̃k* name:phonetics:en=*avnyˈdʒɔ:dʒ faɪv* *PS: Je sais, c'est pas très facile à lire, mais c'est comme une autre langue ;-) * Le 26 juin 2015 15:18, Vincent Privat vincent.pri...@gmail.com a écrit : Tu peux préciser ce que tu ne parviens pas à faire avec JOSM ? Je ne vois pas de souci immédiat avec les chiffres romains. Le 26 juin 2015 2:00 PM, Eric Sibert courr...@eric.sibert.fr a écrit : Bonjour, Il y a moyen de saisir des chiffres romains dans OSM/Josm? Parce que quand le logiciel de guidage me parle de George vé ou Henry ivé, j'ai du mal :-p Je pourrais aussi avoir des références comportant des chiffres romains et pour certains traitements, ça serait bien que ce soit reconnu comme des nombres mais affiché comme des chiffres romains sur les cartes. Eric ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Chiffres romains
Bonjour Le 26/06/2015 13:58, Eric Sibert a écrit : Parce que quand le logiciel de guidage me parle de George vé ou Henry ivé, j'ai du mal :-P Les chiffres romains sont UTF-8, donc si tout le monde s'accordait à utiliser les chiffre romaines UTF-8 au lieux des lettres latines, cela éviterait le problème de la synthèse vocale qui ne fait que lire lesdites lettres latines Cordialement -- David Crochet ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Chiffres romains
Je pense que la synthèse vocale devrait gérer ça avec un dictionnaire. -- Yves Le 26 juin 2015 16:42, Eric SIBERT courr...@eric.sibert.fr a écrit : Je cherche un moyen pour indiquer que c'est n'est pas juste un enchaînement de lettre mais un nombre écrit en chiffres romains et pouvoir l'exploiter en conséquence par exemple pour une synthèse vocale. -- Éric ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Chiffres romains
Je cherche un moyen pour indiquer que c'est n'est pas juste un enchaînement de lettre mais un nombre écrit en chiffres romains et pouvoir l'exploiter en conséquence par exemple pour une synthèse vocale. -- Éric ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Chiffres romains
Il y en en encore d'autres: il y a encore d'autres chiffres codés pour 500, mille, un million et un chiffre spécial en forme de C à l'envers pour former des grand nombres (en combinaison avec le C et le I). A cela il y a encore la convention utilisant les macrons (tirets hauts) en un ou plusieurs exemplaires comme multiplicateur par 1000. Ces chiffres sont utilisés dans CLDR (cependant il ne doit pas y avoir beaucoup de cas de noms de rues avec des nombres supérieurs à 500, la plupart sont des petits nombres et le dernier que je vois est le 23 (pour le pape Jean XXIII qui a donné des noms de rues). Les dates parfois sont notées en romains (pour les années) mais utilisent les chiffres latins de base MDCLXVI, mais rarement sur les noms de rues (ils sont plus souvent vus sur les dates de publication ou de copyright des œuvres). L'autodétection simple poserait problème dans certains cas: DI, LI, IL mais comme par convention on n'utilise pas l'écriture en toutes capitales, l'idée serait que seuls les nombres romains entièrement en capitales seraient reconnus comme tels et pour les autres cas on capitalisera uniquement l'initiale si nécessaire: Li, di, il qui ne seront donc pas lus comme des romains. Cependant des navigateurs GPS ont des formats de fichier imposant la conversion entièrement en capitales (c'est leur façon de compresser les données). Ils ne pourront pas faire la différence et devront se débrouiller (ils ne savant pas non plus lire les extensions phonétiques, mais e,n revanche peuvent afficher certains champs de note à défaut de les prononcer). Bref on revient à la solution de fournir un alt_name=* utilisant les chiffres arabo-européens (0-9) pour lever les ambiguités éventuelles d'une lecture incorrecte de cas comme D 8III ; les navigateurs GPS font une reconnaissance automatique des nombres romains isolés si on les écrit en mots séparés : D 8 III et donc Georges V est lu sans problème (d'autant plus qu'on évite les abréviations dans les noms). Le 26 juin 2015 19:39, Jérôme Seigneuret jseigneuret-...@yahoo.fr a écrit : En effet, j'ai trouvé ça dans la partie *general ponctuation* de la table utf-8 Voici les codes Unicode Caractère UTF-8 encodage HTML name U+2160 Ⅰ 226133160 #8544; ROMAN NUMERAL ONE U+2161 Ⅱ 226133161 #8545; ROMAN NUMERAL TWO U+2162 Ⅲ 226133162 #8546; ROMAN NUMERAL THREE U+2163 Ⅳ 226133163 #8547; ROMAN NUMERAL FOUR U+2164 Ⅴ 226133164 #8548; ROMAN NUMERAL FIVE U+2165 Ⅵ 226133165 #8549; ROMAN NUMERAL SIX U+2166 Ⅶ 226133166 #8550; ROMAN NUMERAL SEVEN U+2167 Ⅷ 226133167 #8551; ROMAN NUMERAL EIGHT U+2168 Ⅸ 226133168 #8552; ROMAN NUMERAL NINE U+2169 Ⅹ 226133169 #8553; ROMAN NUMERAL TEN U+216A Ⅺ 226133170 #8554; ROMAN NUMERAL ELEVEN U+216B Ⅻ 226133171 #8555; ROMAN NUMERAL TWELVE U+216C Ⅼ 226133172 #8556; ROMAN NUMERAL FIFTY U+216D Ⅽ 226133173 #8557; ROMAN NUMERAL ONE HUNDRED U+216E Ⅾ 226133174 #8558; ROMAN NUMERAL FIVE HUNDRED U+216F Ⅿ 226133175 #8559; ROMAN NUMERAL ONE THOUSAND U+2170 ⅰ 226133176 #8560; SMALL ROMAN NUMERAL ONE U+2171 ⅱ 226133177 #8561; SMALL ROMAN NUMERAL TWO U+2172 ⅲ 226133178 #8562; SMALL ROMAN NUMERAL THREE U+2173 ⅳ 226133179 #8563; SMALL ROMAN NUMERAL FOUR U+2174 ⅴ 226133180 #8564; SMALL ROMAN NUMERAL FIVE U+2175 ⅵ 226133181 #8565; SMALL ROMAN NUMERAL SIX U+2176 ⅶ 226133182 #8566; SMALL ROMAN NUMERAL SEVEN U+2177 ⅷ 226133183 #8567; SMALL ROMAN NUMERAL EIGHT U+2178 ⅸ 226133184 #8568; SMALL ROMAN NUMERAL NINE U+2179 ⅹ 226133185 #8569; SMALL ROMAN NUMERAL TEN U+217A ⅺ 226133186 #8570; SMALL ROMAN NUMERAL ELEVEN U+217B ⅻ 226133187 #8571; SMALL ROMAN NUMERAL TWELVE U+217C ⅼ 226133188 #8572; SMALL ROMAN NUMERAL FIFTY U+217D ⅽ 226133189 #8573; SMALL ROMAN NUMERAL ONE HUNDRED U+217E ⅾ 226133190 #8574; SMALL ROMAN NUMERAL FIVE HUNDRED U+217F ⅿ 226133191 #8575; SMALL ROMAN NUMERAL ONE THOUSAND Sinon, la phonétique c'est un autre cas peut-être plus complexe, mais ça évite les interprétations incorrectes. ;-) Le 26 juin 2015 19:37, David Crochet david.croc...@free.fr a écrit : Bonjour Le 26/06/2015 18:11, JB a écrit : Pour moi, la solution devrait venir de l'utilisateur Hum, je pense pas, mais cela dépasse la sphère JOSM ou OSM ou autre, c'est au monde entier de l'informatique d'abandonner le code ISO et de passer à l'UNICODE Ce sera déjà un grand pas dans l'uniformisation des données Cordialement -- David Crochet ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Chiffres romains
C'est l'autre piste et ça m'étonne que Philippe n'a pas encore écrit 1,5 épistle là-dessus. C'était aussi ma première idée, mais c'est certain que ça complique l'édition, car il n'y a personne avec ces code points sur leur clavier. Jo 2015-06-26 19:07 GMT+02:00 David Crochet david.croc...@free.fr: Bonjour Le 26/06/2015 13:58, Eric Sibert a écrit : Parce que quand le logiciel de guidage me parle de George vé ou Henry ivé, j'ai du mal :-P Les chiffres romains sont UTF-8, donc si tout le monde s'accordait à utiliser les chiffre romaines UTF-8 au lieux des lettres latines, cela éviterait le problème de la synthèse vocale qui ne fait que lire lesdites lettres latines Cordialement -- David Crochet ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Chiffres romains
Bonjour Le 26/06/2015 18:11, JB a écrit : Pour moi, la solution devrait venir de l'utilisateur Hum, je pense pas, mais cela dépasse la sphère JOSM ou OSM ou autre, c'est au monde entier de l'informatique d'abandonner le code ISO et de passer à l'UNICODE Ce sera déjà un grand pas dans l'uniformisation des données Cordialement -- David Crochet ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Chiffres romains
Pourquoi pas simplement alt_name=... Georges 5 pour fournir une lecture de Georges V ? sinon on peut aussi utiliser le code BCP47 pour l'extension phonétique API: name:fr-finapi=ˈævənju: ʒɔrʒ sε̃k (et non pas name:phonetic qui est une extension on standard) l'extension -fonapi est standard dans BCP47. Le 26 juin 2015 19:10, Jo winfi...@gmail.com a écrit : C'est l'autre piste et ça m'étonne que Philippe n'a pas encore écrit 1,5 épistle là-dessus. C'était aussi ma première idée, mais c'est certain que ça complique l'édition, car il n'y a personne avec ces code points sur leur clavier. Jo 2015-06-26 19:07 GMT+02:00 David Crochet david.croc...@free.fr: Bonjour Le 26/06/2015 13:58, Eric Sibert a écrit : Parce que quand le logiciel de guidage me parle de George vé ou Henry ivé, j'ai du mal :-P Les chiffres romains sont UTF-8, donc si tout le monde s'accordait à utiliser les chiffre romaines UTF-8 au lieux des lettres latines, cela éviterait le problème de la synthèse vocale qui ne fait que lire lesdites lettres latines Cordialement -- David Crochet ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Chiffres romains
Non, car Osmose nous proposera Georges V (avec un s)... Note: les **nombres** romains sont surtout codés dans Unicode pour compatibilité avec les polices asiatiques, ils ne sont pas codés pour être composables comme chiffres dans des plus grands nombres qu'isolément (chaque caractère est codé et visualisé dans un unique carré de composition sinographique). C'est pourquoi ils incluent tous les nombres de 1 à 12 (pour représenter les mois de l'année ou les heures d'un cadran d'horloge) alors qu'Unicode aurait pu se contenter des chiffres I,V,X dans cet intervalle (les autres sont des nombres précomposés à éviter, hors de l'usage de compatibilité avec les polices sinographiques et jeux de caractères codés des normes nationales ou régionales de Chine, des RAS de Hong Kong et Macao, du Japon et des deux pays en Corée). Il n'y a strictement aucun rendu fiable des grands nombres avec les chiffres romains codés (pourtant CLDR propose un encodeur de nombres latino-arabes vers romains) mais il n'est qu'une suggestion encore largement en bêta, et pas une norme en tant que tel. Le 26 juin 2015 19:31, David Crochet david.croc...@free.fr a écrit : Bonjour Le 26/06/2015 19:10, Jo a écrit : mais c'est certain que ça complique l'édition, car il n'y a personne avec ces code points sur leur clavier. c'est là qu'osmose (ou consœur) serait utile : - on rentre « George V » - Osmose nous propose « George Ⅴ » Cordialement -- David Crochet ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Chiffres romains
Bonjour Le 26/06/2015 19:10, Jo a écrit : mais c'est certain que ça complique l'édition, car il n'y a personne avec ces code points sur leur clavier. c'est là qu'osmose (ou consœur) serait utile : - on rentre « George V » - Osmose nous propose « George Ⅴ » Cordialement -- David Crochet ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Chiffres romains
Ha ben j'aurais pas perdu ma soirée, comme ça ! J'imaginais pas que les chiffres romains avaient leurs caractères utf-8 à eux… (Mais quand je vois l'accueil qui a été fait aux tirets cadratins, notamment sur certains arrêts de métro, je vous souhaite bonne chance, vous encourage à continuer par là, mais je ne me battrais pas avec vous cette fois…) JB. Le 26/06/2015 19:07, David Crochet a écrit : Le 26/06/2015 13:58, Eric Sibert a écrit : Parce que quand le logiciel de guidage me parle de George vé ou Henry ivé, j'ai du mal :-P Les chiffres romains sont UTF-8, donc si tout le monde s'accordait à utiliser les chiffre romaines UTF-8 au lieux des lettres latines, cela éviterait le problème de la synthèse vocale qui ne fait que lire lesdites lettres latines ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Chiffres romains
Si osmose le détecte, le GPS aussi... C'est à l'outil d'analyser les mots. Éventuellement osmose peut aider à détecter une mauvaise ponctuation qui apporterait de la confusion. Ajouter de la phonétique... Comme si osm n'était pas déjà assez compliqué ;) Le 26 juin 2015 19:17, David Crochet david.croc...@free.fr a écrit : Bonjour Le 26/06/2015 19:10, Jo a écrit : mais c'est certain que ça complique l'édition, car il n'y a personne avec ces code points sur leur clavier. c'est là qu'osmose (ou consœur) serait utile : - on rentre « George V » - Osmose nous propose « George Ⅴ » Cordialement -- David Crochet ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Chiffres romains
En effet, j'ai trouvé ça dans la partie *general ponctuation* de la table utf-8 Voici les codes Unicode Caractère UTF-8 encodage HTML name U+2160 Ⅰ 226133160 #8544; ROMAN NUMERAL ONE U+2161 Ⅱ 226133161 #8545; ROMAN NUMERAL TWO U+2162 Ⅲ 226133162 #8546; ROMAN NUMERAL THREE U+2163 Ⅳ 226133163 #8547; ROMAN NUMERAL FOUR U+2164 Ⅴ 226133164 #8548; ROMAN NUMERAL FIVE U+2165 Ⅵ 226133165 #8549; ROMAN NUMERAL SIX U+2166 Ⅶ 226133166 #8550; ROMAN NUMERAL SEVEN U+2167 Ⅷ 226133167 #8551; ROMAN NUMERAL EIGHT U+2168 Ⅸ 226133168 #8552; ROMAN NUMERAL NINE U+2169 Ⅹ 226133169 #8553; ROMAN NUMERAL TEN U+216A Ⅺ 226133170 #8554; ROMAN NUMERAL ELEVEN U+216B Ⅻ 226133171 #8555; ROMAN NUMERAL TWELVE U+216C Ⅼ 226133172 #8556; ROMAN NUMERAL FIFTY U+216D Ⅽ 226133173 #8557; ROMAN NUMERAL ONE HUNDRED U+216E Ⅾ 226133174 #8558; ROMAN NUMERAL FIVE HUNDRED U+216F Ⅿ 226133175 #8559; ROMAN NUMERAL ONE THOUSAND U+2170 ⅰ 226133176 #8560; SMALL ROMAN NUMERAL ONE U+2171 ⅱ 226133177 #8561; SMALL ROMAN NUMERAL TWO U+2172 ⅲ 226133178 #8562; SMALL ROMAN NUMERAL THREE U+2173 ⅳ 226133179 #8563; SMALL ROMAN NUMERAL FOUR U+2174 ⅴ 226133180 #8564; SMALL ROMAN NUMERAL FIVE U+2175 ⅵ 226133181 #8565; SMALL ROMAN NUMERAL SIX U+2176 ⅶ 226133182 #8566; SMALL ROMAN NUMERAL SEVEN U+2177 ⅷ 226133183 #8567; SMALL ROMAN NUMERAL EIGHT U+2178 ⅸ 226133184 #8568; SMALL ROMAN NUMERAL NINE U+2179 ⅹ 226133185 #8569; SMALL ROMAN NUMERAL TEN U+217A ⅺ 226133186 #8570; SMALL ROMAN NUMERAL ELEVEN U+217B ⅻ 226133187 #8571; SMALL ROMAN NUMERAL TWELVE U+217C ⅼ 226133188 #8572; SMALL ROMAN NUMERAL FIFTY U+217D ⅽ 226133189 #8573; SMALL ROMAN NUMERAL ONE HUNDRED U+217E ⅾ 226133190 #8574; SMALL ROMAN NUMERAL FIVE HUNDRED U+217F ⅿ 226133191 #8575; SMALL ROMAN NUMERAL ONE THOUSAND Sinon, la phonétique c'est un autre cas peut-être plus complexe, mais ça évite les interprétations incorrectes. ;-) Le 26 juin 2015 19:37, David Crochet david.croc...@free.fr a écrit : Bonjour Le 26/06/2015 18:11, JB a écrit : Pour moi, la solution devrait venir de l'utilisateur Hum, je pense pas, mais cela dépasse la sphère JOSM ou OSM ou autre, c'est au monde entier de l'informatique d'abandonner le code ISO et de passer à l'UNICODE Ce sera déjà un grand pas dans l'uniformisation des données Cordialement -- David Crochet ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Chiffres romains
@Philippe : Le alt_name n'est pas la solution car par défaut il n'est pas prioritaire vu que c'est name qui l'est. Mais le cas de la phonétique je note car ça c'est intéressant pour des cas spécifiques. Sinon pour en revenir au message de départ d'Eric, sont problème est bien que le V n'est pas détecté. Donc c'est soit l'algo de l'application GPS qui n'est pas bon. Soit l'appli n'utilise que le caractère unicode qui va bien, soit ils ont un dictionnaire de clés de remplacement. @jean-batiste: On ne force personne à l'utiliser, c'est juste pour traiter des cas particuliers! Et il y a, comme tu le sous-entends si bien, plus compliqué dans OSM comme la gestion des relations. La phonétique est dans le dico bilingue Larousse (pour le cité comme exemple) si tu ne sais pas comment l'écrire. Et c'est comme une langue (ou un langage de programmation), ça s'apprend. ;-) @Eric, quelle est l'application que tu as utilisé et sur laquelle tu as rencontré ce problème. A voir : - les tag name et name* avec les priorités utilisés pour le guidage vocal de l'application, - quel est l'algo d'interprétation utilisé par l'appli GPS (dixit le message de Philippe sur le CLDR) - CLDR est-il capable de lire une chaîne date en chiffre romain (Pour voir si un cas un peu tordu est bien traité). Perso j'ai pas testé et je pense que ça dépend du langage de programmation utilisé et de l'intégration des évolution de la dite norme. - l'application est-elle en capacité de lire du BCP47 (tag name:fr-finapi=*) d'ailleurs y a t-il une application qui l'utilise? Je pense qu'avec ça on aura fait avancer le schmilblick ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Chiffres romains
attention fr-fonapi=* (j'ai fait une faute de frappe dans la première occurence) et non finapi Le 26 juin 2015 21:26, Jérôme Seigneuret jseigneuret-...@yahoo.fr a écrit : @Philippe : Le alt_name n'est pas la solution car par défaut il n'est pas prioritaire vu que c'est name qui l'est. Mais le cas de la phonétique je note car ça c'est intéressant pour des cas spécifiques. Sinon pour en revenir au message de départ d'Eric, sont problème est bien que le V n'est pas détecté. Donc c'est soit l'algo de l'application GPS qui n'est pas bon. Soit l'appli n'utilise que le caractère unicode qui va bien, soit ils ont un dictionnaire de clés de remplacement. @jean-batiste: On ne force personne à l'utiliser, c'est juste pour traiter des cas particuliers! Et il y a, comme tu le sous-entends si bien, plus compliqué dans OSM comme la gestion des relations. La phonétique est dans le dico bilingue Larousse (pour le cité comme exemple) si tu ne sais pas comment l'écrire. Et c'est comme une langue (ou un langage de programmation), ça s'apprend. ;-) @Eric, quelle est l'application que tu as utilisé et sur laquelle tu as rencontré ce problème. A voir : - les tag name et name* avec les priorités utilisés pour le guidage vocal de l'application, - quel est l'algo d'interprétation utilisé par l'appli GPS (dixit le message de Philippe sur le CLDR) - CLDR est-il capable de lire une chaîne date en chiffre romain (Pour voir si un cas un peu tordu est bien traité). Perso j'ai pas testé et je pense que ça dépend du langage de programmation utilisé et de l'intégration des évolution de la dite norme. - l'application est-elle en capacité de lire du BCP47 (tag name:fr-finapi=*) d'ailleurs y a t-il une application qui l'utilise? Je pense qu'avec ça on aura fait avancer le schmilblick ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Chiffres romains
Le 26 juin 2015 17:50, Jérôme Seigneuret jseigneuret-...@yahoo.fr a écrit : name:phonetics:en=*avnyˈdʒɔ:dʒ faɪv* Lecture à ne pas imposer en anglais, qui lit plutôt l'ordinal Georges the Fifth et non Georges Five pour les petits nombres. Cependant pour des noms de rues ou d'hôtels en France, la prononciation à la française s'impose dans Rue Joorje Sainq et non Rue Djoorj Faïve (C'est encore questionable avec le mot avenue écrit pareil en anglais et français). C'est plus délicat à trancher pour Hôtel Georges V (malgré l'accent circonflexe que les anglophones ignorent) où la langue anglaise est une langue de travail évidente avec ses clients qui parlent rarement bien le français. Vous pouvez toujours essayer de les joindre au téléphone en anglais pour tester en aveugle comment ils prononcent le nom de l'établissement à leur accueil. Mais quelle que soit la façon dont VOUS prononcerez le nom, la personne au standard ne vous corrigera pas et emploira la même prononciation appropriée pour votre langue (dans ce genre d'hotel on vous répondra aussi bien en français qu'en anglais, chinois, arabe, japonais ou russe, même si les touristes ont l'usage d'essayer d'abord en anglais s'ils ne savent pas bien le français). Vous remarquerez d'ailelurs que le nom de l'hôtel contient maintenant deux mots anglais Four Seasons Georges V Paris (et qu'il est écrit entièrement en capitales pour ne pas y mettre un seul accent, en supprimant même le mot Hôtel). Four Seasons est en effet un groupe dont le siège est au Canada à Toronto et gérant des hôtels et resorts surtout aux USA et en Asie, et quelques-uns en Europe et en Afrique/Moyen-Orient, le chinois et l'anglais sont des langues obligatoires dans leurs établissements, le site officiel du groupe est bilingue anglais/français. ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Chiffres romains
Le 26 juin 2015 21:26, Jérôme Seigneuret jseigneuret-...@yahoo.fr a écrit : @Philippe : Le alt_name n'est pas la solution car par défaut il n'est pas prioritaire vu que c'est name qui l'est Il n'y a pas de priorité : alt_name=* complète le name=* en y ajoutant de la sémantique. Il ne la remplace pas comme le font entre eux les name:lang=* - les tag name et name* avec les priorités utilisés pour le guidage vocal de l'application, Pas de priorité, s'il y a ambiguité pour lire un name=* (après avoir sélectionné la langue) les autres noms alt_name=* sont encore accessibles pour lever ces ambiguités : si la seule différence entre les deux porte entre V et 5 on a une interprétation non ambigue. - quel est l'algo d'interprétation utilisé par l'appli GPS (dixit le message de Philippe sur le CLDR) Tu mélanges deux choses séparées: - d'une part il y a l'algo de reconnaissance qui peut détecter certains petits mots formés uniquement de lettres latines formant un nombre romain. - d'autre part il y a l'algo décrit dans CLDR permettant de convertir un nombre au format romain. - CLDR est-il capable de lire une chaîne date en chiffre romain (Pour voir si un cas un peu tordu est bien traité). Perso j'ai pas testé et je pense que ça dépend du langage de programmation utilisé et de l'intégration des évolution de la dite norme. CLDR décrit l'algo entièrement dans les DEUX sens avec un système de règles de conversion et substitution (au format RBNF, Rule-Based Number Format). Et c'est bel et bien utilisé dans la bibliothèque ICU (et d'autres qui savent lire les règles RBNF). On n'est pas obligé d'utiliser un moteur de règles RBNF pour écrire ou décoder un nombre romain mais les règles utilisées devraient fonctioner de façon équivalente. Mais sans moteru RBNF on ne pourra pas traiter correctement toutes les données CLDR (il faudra en revanche reconnaitre les noms symboliques de formats de nombres romains), mais un moteur RBNF est indispensable pour pouvoir épeler un nombre en mots dans de nombreuses langues (et aussi pouvoir les convertir en sens inverse) ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Intégration des Boites Postale dans Osmose
si ça peut aider dans mon coin (Plœmeur 56270, mais aussi un peu les villes limitrophes) Osmose me propose 3 erreurs par boites aux lettres 1 Boîte postale sans ref:FR:LaPoste (en violet) 1 Boîte postale, proposition d'intégration (en vert) 1 Boîte postale non intégrée (en vert) à 1-5 m de la boite déjà présente (une bonne partie me semble acceptable à ~1m près, quelques boites sont très mal placée cf l'aéroport 10-20 m) ça fait beaucoup pour la même boite je précise que les boites de ce coin ont été mapées par moi même en cumulant photo perso pour le repérage précis et photo bing (je ne connaissais pas l'orthophoto de la région Bretagne à l'époque) en plus d'une bonne connaissance de leur position relative aux bâtiments (j'ai travaillé un temps comme facteur, j'en connais une bonne part de mémoire) je suis donc confiant sur leurs positions à disons 0,5-1 m (même si j'ai pu me tromper par moments) http://osmose.openstreetmap.fr/fr/map/#item=7051%2C8022%2C8023zoom=13lat=47.7354lon=-3.4318layer=Mapnikoverlays=FFFT Le 26 juin 2015 à 13:52, Christian Quest a écrit : Oui, il y a un mix. Je suis en contact avec le responsable côté Poste et j'avais eu le fichier entre les mains il y a déjà quelques semaines. J'avais remonté des problèmes, suggéré de re-géocoder ça avec la BAN via addok, mais visiblement ça n'a pas été fait. Ce qu'on peut aussi faire, c'est comparer les lat/lon retournés par addok+BAN à ceux fournis. Si il y a trop de différence, il faut faire attention. Le 25/06/2015 23:09, Frédéric Rodrigo a écrit : Vu la description de la fiabilisation sur data.gouv ça ne doit pas être autre chose que du géocodage. À relire l'explication je me demande s'il ne mélangent pas adresse et coordonnées géographiques. Je vais poser la question. Le 25/06/2015 22:52, Christian Quest a écrit : ça sent TRES fort le géocodage... et le géocodage pas frais. As-tu essayé de re géocoder ça avec addok/BAN sur adresse.data.gouv.fr http://adresse.data.gouv.fr ? ça évitera d'en avoir en plein champs ;) Le 25 juin 2015 22:31, Pierre-Yves Berrard pierre.yves.berr...@gmail.com mailto:pierre.yves.berr...@gmail.com a écrit : Le 25 juin 2015 22:05, Frédéric Rodrigo fred.rodr...@gmail.com mailto:fred.rodr...@gmail.com a écrit : Bonsoir, Depuis quelques jours les boites au lettre de la poste dans l'espace public sont disponible sur data.gouv.fr http://data.gouv.fr https://www.data.gouv.fr/fr/datasets/liste-des-boites-aux-lettres-de-rue-france-metropolitaine-et-dom-1/ La qualité est assez bonne mais ça sent quand même le géocodage. Elles sont disponibles pour intégration dans Osmose : http://osmose.openstreetmap.fr/fr/map/#item=7051,8022,8023 C'est un peu comme un saint Graal qui devient accessible ;) Frédéric, mappeur de ref de boites aux lettres. Sympa. Je vais regarder si ça colle avec les ref que j'ai déjà rentrées. PY ___ Talk-fr mailing list Talk-fr@openstreetmap.org mailto:Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr -- Christian Quest - OpenStreetMap France ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr -- Christian Quest - OpenStreetMap France ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Sous relations itinéraires cyclables
Mon avis perso Le 26 juin 2015 10:58:48 CEST, GaelADT gael.sauva...@gmail.com a écrit : J'essaye de résumer les discussions que l'on a eu avec notre stagiaire. Je rappelle qu'il s'agit de relations de plusieurs centaines de km : 1) Il serait possible d'avoir une relation avec uniquement des ways dedans. On est d'accord, c'est très moche, et compliqué à maintenir. Mais pourtant ce que l'on a déjà sur certaines relations en France. J'utiliserai cette solution pour les petits itineraire 2) Il est possible d'avoir une relation composée d'autres relations (voies vertes) existantes et des ways. Exemple La Véloroute de la Meuse (relation 2096855) http://www.openstreetmap.org/relation/2096855 . C'est bien car on réutilise les voies vertes existantes. C'est un peu moche car on a plein de ways à côté. Celle ci j'eviterai au maximum mais elle diminue le travail :-) 3) On peut également faire un découpage de la véloroute en étapes. Ces étapes on bien souvent une existance (document papier et panneaux). Du coup on on aurait une véloroute composée de sous relations, où chacune de ses sous relations serait une étape clairement identifiée. Exempmle : La Vélodyssée (relation 4774799) : http://www.openstreetmap.org/relation/4774799 C'est plus joli non ? :) Ci les étapes sont documentées c'est pour moi la meilleur solution Gaël -- View this message in context: http://gis.19327.n5.nabble.com/Sous-relations-itineraires-cyclables-tp5848869p5848955.html Sent from the France mailing list archive at Nabble.com. ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Sous relations itinéraires cyclables
C'est curieux que la notion d'étape n'existe pas déjà dans les relations cycle. On a bien les stop pour les transports en commun. En revanche, ça ne change rien à la difficulté de gérer de très grandes relations. Le 26/06/2015 10:58, GaelADT a écrit : 3) On peut également faire un découpage de la véloroute en étapes. Ces étapes on bien souvent une existance (document papier et panneaux). Du coup on on aurait une véloroute composée de sous relations, où chacune de ses sous relations serait une étape clairement identifiée. Exempmle : La Vélodyssée (relation 4774799) : http://www.openstreetmap.org/relation/4774799 C'est plus joli non ? :) Je suis d'accord, c'est plus sexy, mais ça complique la réutilisation, et cela risque de revenir au même débat que celui qui entoure les relations associatedstreet vs addr: sur les node Je pense qu'avec cette solution, il faudrait en premier lieu voir ce qui va être cassé auprès de ceux qui réutilise déjà les données. Mais ça risque de prendre du temps... Stf ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Sous relations itinéraires cyclables
Les étapes me semblent un bon compromis. Pas trop complexe à modéliser, pas trop complexe à réutiliser. Le 26/06/2015 11:48, Stéphane Péneau a écrit : C'est curieux que la notion d'étape n'existe pas déjà dans les relations cycle. On a bien les stop pour les transports en commun. En revanche, ça ne change rien à la difficulté de gérer de très grandes relations. Le 26/06/2015 10:58, GaelADT a écrit : 3) On peut également faire un découpage de la véloroute en étapes. Ces étapes on bien souvent une existance (document papier et panneaux). Du coup on on aurait une véloroute composée de sous relations, où chacune de ses sous relations serait une étape clairement identifiée. Exempmle : La Vélodyssée (relation 4774799) : http://www.openstreetmap.org/relation/4774799 C'est plus joli non ? :) Je suis d'accord, c'est plus sexy, mais ça complique la réutilisation, et cela risque de revenir au même débat que celui qui entoure les relations associatedstreet vs addr: sur les node Je pense qu'avec cette solution, il faudrait en premier lieu voir ce qui va être cassé auprès de ceux qui réutilise déjà les données. Mais ça risque de prendre du temps... Stf ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr -- Christian Quest - OpenStreetMap France ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
[OSM-talk-fr] Chiffres romains
Bonjour, Il y a moyen de saisir des chiffres romains dans OSM/Josm? Parce que quand le logiciel de guidage me parle de George vé ou Henry ivé, j'ai du mal :-p Je pourrais aussi avoir des références comportant des chiffres romains et pour certains traitements, ça serait bien que ce soit reconnu comme des nombres mais affiché comme des chiffres romains sur les cartes. Eric ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Chiffres romains
Tu peux préciser ce que tu ne parviens pas à faire avec JOSM ? Je ne vois pas de souci immédiat avec les chiffres romains. Le 26 juin 2015 2:00 PM, Eric Sibert courr...@eric.sibert.fr a écrit : Bonjour, Il y a moyen de saisir des chiffres romains dans OSM/Josm? Parce que quand le logiciel de guidage me parle de George vé ou Henry ivé, j'ai du mal :-p Je pourrais aussi avoir des références comportant des chiffres romains et pour certains traitements, ça serait bien que ce soit reconnu comme des nombres mais affiché comme des chiffres romains sur les cartes. Eric ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Intégration des Boites Postale dans Osmose
Oui, il y a un mix. Je suis en contact avec le responsable côté Poste et j'avais eu le fichier entre les mains il y a déjà quelques semaines. J'avais remonté des problèmes, suggéré de re-géocoder ça avec la BAN via addok, mais visiblement ça n'a pas été fait. Ce qu'on peut aussi faire, c'est comparer les lat/lon retournés par addok+BAN à ceux fournis. Si il y a trop de différence, il faut faire attention. Le 25/06/2015 23:09, Frédéric Rodrigo a écrit : Vu la description de la fiabilisation sur data.gouv ça ne doit pas être autre chose que du géocodage. À relire l'explication je me demande s'il ne mélangent pas adresse et coordonnées géographiques. Je vais poser la question. Le 25/06/2015 22:52, Christian Quest a écrit : ça sent TRES fort le géocodage... et le géocodage pas frais. As-tu essayé de re géocoder ça avec addok/BAN sur adresse.data.gouv.fr http://adresse.data.gouv.fr ? ça évitera d'en avoir en plein champs ;) Le 25 juin 2015 22:31, Pierre-Yves Berrard pierre.yves.berr...@gmail.com mailto:pierre.yves.berr...@gmail.com a écrit : Le 25 juin 2015 22:05, Frédéric Rodrigo fred.rodr...@gmail.com mailto:fred.rodr...@gmail.com a écrit : Bonsoir, Depuis quelques jours les boites au lettre de la poste dans l'espace public sont disponible sur data.gouv.fr http://data.gouv.fr https://www.data.gouv.fr/fr/datasets/liste-des-boites-aux-lettres-de-rue-france-metropolitaine-et-dom-1/ La qualité est assez bonne mais ça sent quand même le géocodage. Elles sont disponibles pour intégration dans Osmose : http://osmose.openstreetmap.fr/fr/map/#item=7051,8022,8023 C'est un peu comme un saint Graal qui devient accessible ;) Frédéric, mappeur de ref de boites aux lettres. Sympa. Je vais regarder si ça colle avec les ref que j'ai déjà rentrées. PY ___ Talk-fr mailing list Talk-fr@openstreetmap.org mailto:Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr -- Christian Quest - OpenStreetMap France ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr -- Christian Quest - OpenStreetMap France ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
