Re: [OSM-talk-fr] Chiffres romains

[Philippe Verdy]

oui mais en comparant:
  name:fr-fonipa
et
  name:phonetic:fr

lequel est le plus "simple" d'après toi ?

Et demandera le moins de travail spécifiqure pour gérer les exceptions aux
règles BCP47 qui sont déjà implémentées dans des bibliothèques partagées et
qui ne demandent pas dêtre maintenaues séparément avec beaucoup moins de
développeurs disponibles pour comprendre ce qu'il en est ? OSM s'est trop
largement tenu à l'écart des normes existantes en voulant créer la sienne
sans aucun bénéfice supplémentaire.

Résultat: la lourdeur extrême d'utilisation de ses bases de données, les
requêtes ultra compliquées pour chercher les features, des scripts d'export
de plus en plus ingérables car les exceptions non maintenues (et souvent
même pas dopcumentées ni réellement décidées) se sont multipliées de façon
incohérente (et souvent même avec des incompatibilités entre elles!)

Il n'y a strictement rien à gagner à s'écarter des normes quand elles sont
suffisantes pour les problèmes à traiter. Bien au contraire ces écarts en
s'accumulant deviennent de véritables boulets qu'on traine ensuite, et qui
du fait des complications qu'ils impliquent, laissent des tas de cas
oubliés, non testés, non gérés, et des anomalies ensuite à l'utilisation.

Même Wikipédia s'en est rendu compte et maintenant uniformise ses codes
langues propriétaires défaillants vers BCP47 (il n'en reste plus beaucoup à
migrer, ils sont tous dans les tubes mais cela demande du travail non pas
dans le code MediaWiki ou son paramétrage mais dans la conversion des
stockages des bases de données, ce qui est énormément plus lourd à faire,
et la conversion de tas de scripts shelle pour la maintenance, l'addittion
de la prise en charge de divers alias pour la transition, la conservation
si possible de noms de domaines pour limiter le nombre de liens brisés...)

S'écarter des normes sans bonne raison justifiée par un bénéfice réel
(alors qu'on est face uniquement çà une spécification technique) est
toujours risquée. En fait cela n'aide même pas les utilisateurs qui au lieu
de se fier à des normes qu'ils connaissent déjà et sont utilisées ailleurs,
doivent apprendre à maitriser un tas d'exceptions purement locales : pour
eux aussi c'est une perte de temps et pour nous aussi un gachis inutile de
ressources et de moyen parce que cela aboutit ensuite à du temps perdu pour
corriger, ou apporter un support technique supplémentaire ou de la
formation. S'écarter des normes en fait les éloigne encore plus du projet
(à commencer par tous les nouveaux arrivants, ou ceux qui ont décroché
pendant un certain temps du projet et y reviennent sans être au courant
qu'il y a de nouvelles exceptions à ce qui logiquement était supposé être
une règle de base).

Le bénéfice réel serait uniquement si cela apportait quelqurechose que la
norme ne sait pas et ne peut pas gérer du tout dans son état actuel (même
dans ses extensions privées autorisées, ce dont BCP47 dispose aussi avec
les préfixes de sous-tags en "-x-", mais là il n'est même pas question
d'extension privée puisque la fonctionnalité est codifiée et déjà
normalisée de façon suffisante pour exactement même but ; une transcription
phonétique, en fait plutôt phonologique, n'est qu'une variante
ortrhographique d'une langue, elle reste même spécifique à cette langue par
rapport à son orthographe habituelle qui s'écarte souvent de la phonétiqure
pure car phonétique et écriture n'évaluent pas au même rythme : la
phonétique évolue beaucoup plus vite alors que les écrits restent là pour
longtemps et existe alors une résistance normale à l'évolution
orthographique qui fait alors apparaitre des lettres muettes, ou pas
écrites de la façon ont elles sont prononcées, ou carrément omises de
l'orthographe : orthographe et phonologie sont deux transcriptiosn de la
même langue mais l'orthographe est plus figée et plus globale que la lange
parlée réelle qui est nettement plus locale et plus restreinte dans le
temps, même sans réelle évolution orale de la grammaire ou du vocabulaire
morphologique).

De fait il existe souvent des tas de réalisations phonologiques d'une même
langue (surtout dans les langues très répandues dans le monde comme
français et anglais) et donc l'apparition de tas de variété dialectales
orales : pour simplifier un peu la phonologie tentent d'unifier certains
sons et l'API n'est utilisée que sur une partie de ses capacités dans les
transcrioptions (mais rien n'interdit pourtant d'utiliser une transcription
non pas phonlogique mais phonétique de la langue y compris avec ses
distinctions dialectales très locales, voire carrément personnelles)

Mais pour nous en s'en tient juste à la phonologie moderne la plus cournate
(celle des dictionnaires) qui devient alors une orthographe supplémentaire
de cette langue



(Le français a quatre orthographes officielles en France :
- 1. traditionnelle (celle de l'Académie depuis sa création tardive),
parfois avec des règles imposées juste pour limtier le nomb re de as même
si phono

Re: [OSM-talk-fr] Chiffres romains

[Thierry Bézecourt]

Merci pour ces explications détaillées qui m'aident à mieux comprendre 
BCP47.


Mais l'un des problèmes que rencontre Wikipédia actuellement, c'est que 
le code wiki est devenu trop compliqué, au point apparemment de rebuter 
de nombreux utilisateurs. Donc ils ont développé un éditeur visuel, qui 
est lourd et qui marche plus ou moins bien.


Ce serait dommage qu'OSM suive le même chemin en imposant des balises 
aux noms non intuitifs. Cela conduirait à une "clubbisation" d'OSM, où 
seuls les experts pourraient comprendre comment cela fonctionne ; 
d'autant que, les projets collaboratifs étant ce qu'ils sont, on ne peut 
pas espérer que le système sera "stable" un jour.


L'utilisateur moyen d'OSM ne lira jamais une RFC en entier. De même, il 
serait exagéré d'exiger que le contenu soit saisi en IPA (tant qu'à 
faire, on pourrait proposer que le "name" soit saisi en HTML ou en RTF 
pour mieux respecter la typographie). Il faut fournir une possibilité de 
le saisir en langage plus simple.


Il y a des outils "conviviaux", certes. C'est sans doute bien pour les 
utilisateurs occasionnels, mais cela complique la tache pour les 
utilisateurs aguerris (libellés différents d'un outil à l'autre, mise à 
jour incertaine des outils par rapport aux "règles" mouvantes d'OSM...).


Bref, choisir des noms de balise compliqués parce qu'ils sont standards, 
cela revient à favoriser le développeur qui utilise les données de la 
base de données par rapport au contributeur moyen d'OSM.


Et encore, cela revient à privilégier le développeur paresseux. Si 
j'exporte les données d'OSM vers une base externe, je vais tout de même 
vérifier un peu que les données sont correctes. Le nom des tags étant 
libre dans OSM, le développeur sérieux ne va pas supposer que toute 
balise "-<...>" est une balise BCP-47. Il devra bien faire des 
vérifications sur le format du tag, donc ça ne constituera pas une 
complexité supplémentaire pour lui de convertir ":phonetics" en 
"-fonapi" au besoin.


On pourrait envisager un système à deux niveaux :
-  name::pronunciation : prononciation approximative ("Quimpère", 
"George 5")

-  name: : prononciation IPA pour les plus motivés

Quant à X-SAMPA, ça n'est pas à la portée du premier venu... Exemple 
(indice : c'est de l'anglais) :


| "@Up@n stri:t m{p s bIlt baI @ k@"mju:nIti @v m{p "drA:p@rz D@t 
k@n"trIbju:t @nd meIn"teIn "deIt@ @"baUt r@Udz | treIlz | "k{feIz | 
"reIlweI "steISn=z | @nd "mVtS mO: | O:l "@Uv@ D@ w3:ld |



Thierry

Le 28/06/2015 09:05, Philippe Verdy a écrit :



Le 28 juin 2015 00:58, Thierry Bézecourt mailto:thie...@thbz.org>> a écrit :

Le 28/06/2015 01:19, Jérôme Seigneuret a écrit :


J'ai pas encore trouvé une seule valeur utilisant le tag
name:fr-fonapi
et le fameux codage BCP47


Bien sûr, parce qu'OpenStreetMap utilise des tags aux noms simples
et compréhensibles. Personne n'utilisera des balises aux noms aussi
absc

ons que "fr-fonapi" ou "und-fonapi"...


"fr-fonipa" n'est abscond que pour ceux qui ne savent pas qu'une telle
norme existe et qui la lisent mal ou en diagonale express (en ne lisant
qu'une phrase piquée dans le texte hors de son contexte et des
définitions qui précèdent concernant les termes utilisés).

  Quand on a compris que ce qui suit "name:*=*" est un code BCP47, on a
accès à toutes ses variantes et on n'est pas réduit aux seul codes à 2
lettres venus de l'ISO 649-1. Et sionon pour beaucoup même "name:fr=*"
est abscond puisqu'ils croient à tord que cela désigne un nom pour la
France (ils confondent codes langues et codes pays et ça donne des trucs
aussi infames que "name:jp=*", ou encore "name:als=*" et
"name:zh-classical" venus d'une confusion grossière entre un nom de
sous-domaine spécifique à une édition de Wikipédia et un véritable code
langue)

BCP47 est en fait très simple et très clair, d'autant plus qu'il est
universel (ce qui n'est pas du tout le cas de pas mal de codifications
dans OSM qui nécessitent un apprentissage spécifique et où il n'y a
aucune cohérence entre tags pourtants similaires !).

Ce n'est pourtant pas compliqué: le premier code avant le premier tiret
est toujours un code langue, les autres sont des extensions dans l'ordre

- un code d'extension pour accéder à un code langue primaire quand le
premier code n'est pas suffisant et que toutes les langues de cette
famille ne sont pas mutuellement compréhensibles (code de famille
linguistique, tels que "roa"): cette extension n'est plus utilisée
depuis que plus de 7000 langues ont été codées dans ISO 639-3, et dans
certains cas ces codes de regroupement étaient même faux (exemple avec
zh-min-nan) ou de format incorrect (zh-classical, en-simple).
- un code d'écriture (ex. ur-Arab contre ur-Deva qui est en fait
pratiquement équivalent à hi-Deva pour le Hindi; meilleur exemple avec
tk-Latn et tk-Arab)
- un code de région (ex. en-US contre en-GB)
- un code de variante orthographique ou linguistique (e.g. en-bootling):
"fonipa" peut être u

Re: [OSM-talk-fr] Chiffres romains

[Philippe Verdy]

Le 28 juin 2015 00:58, Thierry Bézecourt  a écrit :

> Le 28/06/2015 01:19, Jérôme Seigneuret a écrit :
>
>>
>> J'ai pas encore trouvé une seule valeur utilisant le tag name:fr-fonapi
>> et le fameux codage BCP47
>>
>
> Bien sûr, parce qu'OpenStreetMap utilise des tags aux noms simples et
> compréhensibles. Personne n'utilisera des balises aux noms aussi absc

ons que "fr-fonapi" ou "und-fonapi"...
>

"fr-fonipa" n'est abscond que pour ceux qui ne savent pas qu'une telle
norme existe et qui la lisent mal ou en diagonale express (en ne lisant
qu'une phrase piquée dans le texte hors de son contexte et des définitions
qui précèdent concernant les termes utilisés).

 Quand on a compris que ce qui suit "name:*=*" est un code BCP47, on a
accès à toutes ses variantes et on n'est pas réduit aux seul codes à 2
lettres venus de l'ISO 649-1. Et sionon pour beaucoup même "name:fr=*" est
abscond puisqu'ils croient à tord que cela désigne un nom pour la France
(ils confondent codes langues et codes pays et ça donne des trucs aussi
infames que "name:jp=*", ou encore "name:als=*" et "name:zh-classical"
venus d'une confusion grossière entre un nom de sous-domaine spécifique à
une édition de Wikipédia et un véritable code langue)

BCP47 est en fait très simple et très clair, d'autant plus qu'il est
universel (ce qui n'est pas du tout le cas de pas mal de codifications dans
OSM qui nécessitent un apprentissage spécifique et où il n'y a aucune
cohérence entre tags pourtants similaires !).

Ce n'est pourtant pas compliqué: le premier code avant le premier tiret est
toujours un code langue, les autres sont des extensions dans l'ordre

- un code d'extension pour accéder à un code langue primaire quand le
premier code n'est pas suffisant et que toutes les langues de cette famille
ne sont pas mutuellement compréhensibles (code de famille linguistique,
tels que "roa"): cette extension n'est plus utilisée depuis que plus de
7000 langues ont été codées dans ISO 639-3, et dans certains cas ces codes
de regroupement étaient même faux (exemple avec zh-min-nan) ou de format
incorrect (zh-classical, en-simple).
- un code d'écriture (ex. ur-Arab contre ur-Deva qui est en fait
pratiquement équivalent à hi-Deva pour le Hindi; meilleur exemple avec
tk-Latn et tk-Arab)
- un code de région (ex. en-US contre en-GB)
- un code de variante orthographique ou linguistique (e.g. en-bootling):
"fonipa" peut être utilisé ici quelque soit les codes qui précèdent, les
variantes phonétiques sont nommées simplement par convention avec le
sous-code "fon*"
- des codes supplémentaires d'extension pour autre chose que la langue ou
la convention orthographique (par exemple le tri, une préférence de format
de dates ou de monnaie) utilisant un premier code à 1 lettre suivi d'un
code à 2 caractères alphanum ou plus
- des extension totalement privées et libres avec le code "x" suivi d'un
autre code jsuqu'à 8 alphanum

Ce format est immuable (il n'a en fait pas réellement bougé depuis près de
40 ans meˆme s'il a eu des extensions, il est resté compatible; il est
beaucoup plus utilisé qu'OSM qui est encore extrèmement jeune et même plus
encore que l'UCS d'Unicode et ISO/CEI 10646, ou *les* normes ISO 639 qui
sont incompatibles entre leurs éditions sucessives, y compris depuis l'ISO
639-3 qui a rajouté de la complexité et de l'ambiguité que BCP 47 résoud
complètement tout en préservant la compatibilité ascendante).

L'algo pour résoudre les resources dans des jeux de traductions disponible
est standardisé par BCP47 et par les données présentes dans la base IANA
(qui définit les alias et codes préférés), ce qui permet aux applis de
fonctionner même avec des traductions incomplètes sans avoir à chaque fois
à afficher uniquement de l'anglais ni même obliger les applis à fournir une
traduction anglaise complète.



OSM reste une base de données quji sera utilisée par des outils techniques
et les éditeurs peuvent très bien prendre en charge le nom des tags (iD le
fait déjà sans qu'on soit obligé au prermier abord de coder ça
correctement). OSM est destiné à être utilisé par des outils techniques qui
feront des analyses automatiques. Autant donc choisir les techniques
d'automatisation standarisées (déjà implantées dans de très nombreux
logiciels pour ne pas avoir à les réécrire ou les corriger au fur et à
mesure ce qui double le travail pour rien) car de toute façon on ne peut
pas se passer d'une codification technique.

Si on a des éditeurs pour OSM c'est justement pour ne pas avoir à tout
coder à la main, les éditeurs se chargent de contrôler et proposer une
interface facile. Mais sinon "name:fr-fonipa=*" reste tout à fait lisible
une fois qu'on a compris ce que ça représente en ayant lu *seulement* que
le code qui suit un name:* est un code BCP47 standard: si le code ne
correspond pas à cette norme, il ne sera tout bonnement pas lu correctement
par les outils techniques, et la donnée ne sert plus à rien d'autre, c'est
du commentaire, qui ne sera même pas utilisé dans 

Re: [OSM-talk-fr] Chiffres romains

[Thierry Bézecourt]

Le 28/06/2015 01:19, Jérôme Seigneuret a écrit :


J'ai pas encore trouvé une seule valeur utilisant le tag name:fr-fonapi
et le fameux codage BCP47


Bien sûr, parce qu'OpenStreetMap utilise des tags aux noms simples et 
compréhensibles. Personne n'utilisera des balises aux noms aussi abscons 
que "fr-fonapi" ou "und-fonapi"...


Il n'y a aucune raison des suivre un standard à la lettre dans un format 
interne de base de données. C'est lors de l'échange avec des logiciels 
tiers que les standards ont un sens.


Donc la structure interne de la base OSM doit rendre cet échange 
possible : par exemple, il vaut mieux suivre les standards pour les 
codes de langue ("fr", "en"...), qui sont d'ailleurs largement connus. 
Mais pour le reste on fait ce qu'on veut.


Je ne crois pas qu'on ait cité ici le débat sur l'ajout de champs du 
type name::phonetics ou name:phonetics: : 
http://wiki.openstreetmap.org/wiki/Proposed_features/Phonetics


Certains utilisent aussi "pronunciation" :
https://taginfo.openstreetmap.org/search?q=pronunciation

Thierry



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
 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 à laRFC 5646  




















Le 27 juin 2015 16:33, Thierry Bézecourt mailto:thie...@thbz.org>> 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
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.op

Re: [OSM-talk-fr] Intégration des Boites Postale dans Osmose

[Vincent de Château-Thierry]

Le 27/06/2015 18:24, Jérôme Amagat a écrit :

je pense qu'en résonnant comme ça, il faut supprimé pas mal des
intégration possible dans osmose. exemple, les pharmacies, les stations
services, même les écoles, c'est pas toujours facile de savoir ce que
c'est su la photo aérienne (parce que c'est bien ça le problème, que la
photo aérienne ne nous aide pas beaucoup pour placé la boite au lettre).
Moi je proposerai seulement de modifié le commentaire en rouge dans
osmose, là il n'y a que l'adresse, pour certains éléments à intégré, il
y a "géocodé a la rue" ... peut être ajouter quelque chose du genre qui
fait comprendre que c'est pas la position exact.


Un point commun des 3 que tu cites, et qui les différencie des boîtes 
aux lettres et des hydrants, c'est le sens de l'adresse associée. Dans 
les 3 cas on sait qu'on cherche à renseigner un bâtiment, on a donc 3 
sources à dispo : celle configurée dans Osmose (pour l'adresse), bing 
(pour le bâtiment, la cour...), et le cadastre (pour l'adresse et le 
bâtiment). Il y a moyen de recouper, fiabiliser. C'est une différence 
majeure avec une source de boîtes aux lettres, d'hydrants, ou autres 
"petits" éléments.
Comme tu le suggères, dans le cas des BAL, rajouter un avertissement 
quand le n° d'adresse est à 0 ( = pas de numéro) irait dans le bon sens.


vincent

___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

[OSM-talk-fr] Un GPS pour guider les aveugles en randonnee

[THEVENON Julien]

Cet exemple d application je l aurais bien vu a base de donnees OSM. Je pense 
que la FFRP a du faire du micro-mapping pour recenser les 
obstacleshttps://fr.news.yahoo.com/gps-guider-aveugles-randonn%C3%A9e-143514508.html
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Chiffres romains

[Philippe Verdy]

Le 27 juin 2015 19:15, Jérôme Seigneuret  a écrit
:

> Bref c'est pas une mauvaise interprétation est c'est utilisé comme tel
> dans les API et dans le système Android (système sur lequel est installé
> OsmAnd)
>

Android utilise les tags BCP47 standards, sauf pour la nomination interne
des fichiers de ressource dans les sources de ses "bundles" inclus dans les
archives APK ou dans les répertoires applicatifs créés dans /system quand
l'appli est installée. Dans l'API elle-même utilisée par les applis on
n'utilise pas ces codes. L'APÏ supporte aussi quelques extensions obsolètes
venant des premières versions de Java (par exemple "iw" au lieu de "he"
pour l'hébreu), parce que les kits de développement d'Android sont encore
basés sur Java meˆme si Android utilise ensuite sa propre VM différente
(Dalvik ou la nouvelle VM pour Android 5+ qui n'utilise plus la compilation
JIT mais une précompilation à l'installation et qui supporte aussi des
extensions de l'ABI non compatibles avec le JNI standard de Java mais
permettant de livrer aussi du code natif ou s'interfacer dans le noyau avec
du code propriétaire avec un accès direct au chargeur de code binaire et au
linker).
Et pas la peine de parler d'Android quands la base OSM n'est pas faite pour
Android mais pour être neutre, ses tags ne sont pas plus destinés à Windows
que MacOS ou iOS ou BlackBerry, qu'on développe en Java, en PHP, en Ruby,
en Perl, en C/C++ ou C# pour .net ou dans les divers dialectes SQL et
shcémas XML qui peuvent intégrer des données OSM.
On ne parle pas non plus des derniers codes spécifiques de Wikipédia (qui
vont tous disparaitre, tous remplacés un par un par BCP 47; bref pas de
"name:als=*" pour l'alsacien même s'il y a encore des liens Wikipédia
utilisant "als" dans Wikidata; même chose pour "nrm" qui va devenir "nrf",
"zh-classical" qui va devenir "lzh": ces codes incompatibles ne doivent pas
être utilisés dans OSM, qui n'admet psa non plus tout un tas de codes ISO
649 volontairement omis de la base IANA pour BCP47, comme l'explique une de
ses RFC dans le détail)
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Chiffres romains

[Philippe Verdy]

Le 27 juin 2015 19:15, Jérôme Seigneuret  a écrit
:

> En France on parle français(Une seule langue officielle) dans tout les cas
> donc fr ou fr_FR comme français de France. Le problème n'est pas là.
>
Le problème est que tu restreint le tag seulement à la France alors qu'il
est dans le monde entier, partout où on veut parler français.


>

>
Bref c'est pas une mauvaise interprétation est c'est utilisé comme tel dans
> les API et dans le système Android (système sur lequel est installé OsmAnd)
>
> Je ne l'invente pas non plus
> http://www.iana.org/assignments/lang-subtags-templates/fonipa.txt
>

Non car tu oublie le mot important "'variant" et la syntaxe très précise
des labels de langues BCP47 : nulle part il n'est possible d'utiuliser un
sous-label de variante (variant subtag) en tête.

L'expression que tu as trouvée "no-prefix" signifie si tu avais
correctement lu la RFC que le sous-label n'est pas restreint à certains
préfixes maix utilisable pour tous les préfixes (mais un préfixe reste
nécessaire dans la labrel de langue complet)

Bref relis correctement la RFC et commence par la section du décrit la
syntaxe d'un labele de langue qui a obligatoirement en tête un sous-label
de langue primaire (tel que "fr", "mul" ou "und").


> "fonapi" ne renvoi pas de résultat sur IANA mais "fonipa" comme "fonupa"
>
> https://www.iana.org/assignments/lang-subtags-templates/lang-subtags-templates.txt
>
> Et ça fait bien référence à la RFC5646
> https://www.ietf.org/rfc/rfc5646.txt
>
> En effet il doit y avoir un prefix. Pas de problème!
>

Enfin ! Et puis on doit absoluement éviter de référencer une RFC quand on
parles de BCP 47 (ou de n'importe quelle BCP de l'IETF= qui est composé de
plusieurs RFC et de corrections ultérieures, ainsi que du registre IANA.
BCP 47 a été la RFC 646, puis 4646 puis 5646, mais elle a été acompagnée
aussi de plusieurs autres RFC (avec différents statuts: certains normatifs
d'autres informatifs). Concernant les codes acceptés, la référence c'est la
base IANA, mais la RFC décrit seulement l'usage (dans le passé la RFC 646
donnait une liste de codes, c'est fini et remplacé par une référence
normative à la base et plusieurs machanismes et protocoles documentant
comment utiliser les codes de la base IANA ou comment en ajouter, et ce qui
peut y être corrigé ou pas, et comment assurer la compatibilité ascendante
des codes, la chose qu'oublie totalement les différents volets de l'ISO 639
qui n'offre strictement aucune interprétation que pour des codes isolés et
décrits juste par un nom anglais et quelques synonymes: ISO 639 n'est pas
un catalogue assez précis ni stable, la base IANA pour BCP 47 l'est
beaucoup plus).


Concernant les fautes de frappe sur ces codes "fonapi", c'est un enfer sur
un smartphone qui change à la volée plusieurs fois même ce qu'on vient de
corriger déjà, et le rechange encore avant l'envoi d'un texte. Fichu
clavier Android merdique qui insiste pour vouloir trouver des mots français
et ne sait pas gérer un texte utilisant plusierus langues ni retenir le
fait qu'on s'est déjà opposé à la correction automatique d'un mot et qu'il
ne doit pas la remettre derrière ! Ce clavier n'est fait que pour chatter
quelques mots. (Note: c'est aussi merdique sur un clavier mobile pour iOS
ou pour Windows, les correcteurs font n'importe quoi quand ils veulent même
quand on ne le veut pas, et ne re retiennent rien du tout. Pourtant jamais
je n'ai tapé "fonapi", j'ai mis "fonipa" mais en relisant le simpe survol
en défilant le texte faits des corrections sans qu'on les voit, Je me
demande sd'où il a sorti "fonapi" alors que ce mot n'est pas non plus dans
un dico mais pourrait reseembler à "fon" (abréviation courante de
"(télé)phone") et "api" (la pomme), le smartphone connait aussi la marque
"Fon" (fournisseur de hotspots Wifi).
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Plugin Mapillary pour Josm

[Jean-Baptiste Holcroft]

On notera également que Mapillary continue a jouer le jeu en publiant un 
article sur son blog :

http://blog.mapillary.com/update/2015/06/25/josm-mapillary.html

Le 24/06/2015 14:10, Stéphane Péneau a écrit :

Hello tous !

Pour ceux qui ne sont pas au courant, un plugin pour afficher les 
photos de Mapillary directement dans Josm, est en cours de 
développement. Ce plugin est déjà présent dans la liste par défaut des 
versions récentes, vous avez juste à l'activer pour le tester.


Vous pouvez suivre le développement à cette adresse :
http://wiki.openstreetmap.org/wiki/JOSM/Plugins/Mapillary
Et les rapports de bogues ici :
https://josm.openstreetmap.de/query?status=assigned&status=closed&status=needinfo&status=new&status=reopened&component=Plugin+mapillary&desc=1&order=id 



Je trouve que ça fonctionne déjà assez bien.

StephaneP

___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr


--

Jean-Baptiste


___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Chiffres romains

[Jérôme Seigneuret]

En France on parle français(Une seule langue officielle) dans tout les cas
donc fr ou fr_FR comme français de France. Le problème n'est pas là.

Bref c'est pas une mauvaise interprétation est c'est utilisé comme tel dans
les API et dans le système Android (système sur lequel est installé OsmAnd)

Je ne l'invente pas non plus
http://www.iana.org/assignments/lang-subtags-templates/fonipa.txt

"fonapi" ne renvoi pas de résultat sur IANA mais "fonipa" comme "fonupa"
https://www.iana.org/assignments/lang-subtags-templates/lang-subtags-templates.txt

Et ça fait bien référence à la RFC5646 https://www.ietf.org/rfc/rfc5646.txt

En effet il doit y avoir un prefix. Pas de problème!



Le 27 juin 2015 18:46, Philippe Verdy  a écrit :

> Bref aucune erreur dans waikipedua c'est bien toi qui te plantes même en
> allant a la source que tu n'as pas lue ou pas comprise...
> Le 27 juin 2015 18:22, "Jérôme Seigneuret"  a
> écrit :
>
>> @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
>>  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 
>> 
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> Le 27 juin 2015 16:33, Thierry Bézecourt  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.
>>>
>>>
>>> ___
>>> T

[OSM-talk-fr] Opération Libre du 25 au 27 septembre à Chéméré

[Antoine Riche]

A noter dans vos agendas !

La 3e Opération Libre, après Brocas en 2013 et Gérardmer en 2014, aura 
lieu à Chéméré en Loire-Atlantique, du 25 au 27 septembre 2015. Elle est 
organisée par l'association Libertic et le Conseil Général de 
Loire-Atlantique. L'association OpenStreetMap France sera présente, les 
contributrices et les contributeurs sont bien sûr invité.e.s à participer.


Chéméré (http://www.openstreetmap.org/relation/93963) est une commune de 
2500 habitants, située entre Nantes (35 km) et Pornic (15 km). La mairie 
de Chéméré souhaite fortement impliquer les habitants, et nous prévoyons 
de communiquer localement sur l'évènement lors du forum des associations 
le 28 août. OpenStreetMap permet d'imaginer des animations variées, qui 
permettront d'impliquer les habitants selon leurs centres d'intérêt.


Le programme du week-end est à construire ensemble. Nous avons commencé, 
lors d'une rencontre de contributeurs nantais, à énumérer quelques idées 
sur ce pad : 
https://semestriel.framapad.org/p/Operation_Libre_Chemere_OpenStreetMap. 
N'hésitez pas à y contribuer, en suggérant animations, conférences ou 
ateliers, en proposant votre aide pour collecter ou valoriser les 
données ... ou pour coorganiser le week-end. Cela nous permettra 
d'ébaucher un "programme" pour le bon déroulement de l'opération.


D'ici là ... passez un bon été !
Antoine (mandataire OSM France pour la Loire-Atlantique)


___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Chiffres romains

[Philippe Verdy]

Bref aucune erreur dans waikipedua c'est bien toi qui te plantes même en
allant a la source que tu n'as pas lue ou pas comprise...
Le 27 juin 2015 18:22, "Jérôme Seigneuret"  a
écrit :

> @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
>  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 
> 
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> Le 27 juin 2015 16:33, Thierry Bézecourt  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
>> 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

[Jérôme Seigneuret]

Pour info

Il y a une valeur avec *fonetic*
https://taginfo.openstreetmap.org/search?q=fonetic

Un peu plus avec *phonetic*
https://taginfo.openstreetmap.org/search?q=phonetic

;-)



Le 27 juin 2015 18:19, Jérôme Seigneuret  a écrit
:

> @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
>  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 
> 
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> Le 27 juin 2015 16:33, Thierry Bézecourt  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
>> 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 Verdy]

Non tu te plantes deux fois. car la RFC que tu cites qui n'est qu'elle
version et une partie de BCP 47, fait référence a son enregistrement comme
variante dans un label de langue.

"Fonapi" ne peut donc pas être utilisé seul et pas en tant que premier
sous-label d'un label de langue. Un peu DD recherche et tu serais tombe sur
son enregistrement dans la base de donnée IANA pour les labels de langues
BCP 47.

Tu ne fais que survoler un truc en sortant du contexte de sa norme qui
définit clairement l'usage.

Enfin deuxième erreur, "fr-fonapi" ne fait pas référence a la France mais à
la langue française... Une approximation grossière donc.

Pour une prononciation internationale multilingue le label BCP47 standard
est mul-fonapi. Pour une utilisation monolingue dans une langue
indéterminée ou un fallback neutre le label est und-fonapi.

Bref pas de name:fonapi=* puisque fonapi seul n'est pas un label de langue
BCP47 standard.

Mais name:und-fonapi=* est correct.
Le 27 juin 2015 18:22, "Jérôme Seigneuret"  a
écrit :

> @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
>  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 
> 
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> Le 27 juin 2015 16:33, Thierry Bézecourt  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

Re: [OSM-talk-fr] Intégration des Boites Postale dans Osmose

[Jérôme Amagat]

je pense qu'en résonnant comme ça, il faut supprimé pas mal des intégration
possible dans osmose. exemple, les pharmacies, les stations services, même
les écoles, c'est pas toujours facile de savoir ce que c'est su la photo
aérienne (parce que c'est bien ça le problème, que la photo aérienne ne
nous aide pas beaucoup pour placé la boite au lettre).
Moi je proposerai seulement de modifié le commentaire en rouge dans osmose,
là il n'y a que l'adresse, pour certains éléments à intégré, il y a
"géocodé a la rue" ... peut être ajouter quelque chose du genre qui fait
comprendre que c'est pas la position exact.

Le 27 juin 2015 18:09, Vincent de Château-Thierry  a
écrit :

>
> Le 27/06/2015 17:54, Frédéric Rodrigo a écrit :
>
>  Je trouve que tu fait à l'intégration le même procès que à l'import.
>> L'intégration n'a de sens que si entre le clic de souris et la chaise il
>> y un cerveau, je suis d'accord. Mais c'est justement pour cela que l'on
>> passe par une intégration et non une importation.
>>
>> Je ne souhaite pas limite un outil sous prétexte qu'il est trop facile
>> (et rapide) à utiliser.
>>
>
> Pour lever un possible doute, mon message n'est surtout pas un procès
> envers Osmose.
> Ce que je veux pointer, et qui différencie la démarche de celle des
> imports (essentiellement celui du bâti), c'est qu'on ne dispose pas de
> sources opposables à celle proposée dans Osmose, vu la faible emprise des
> objets sur le terrain. Donc le jugement de chacun, (aka le "cerveau"),
> n'est finalement pas si central dans la démarche. Et même l'adresse
> postale, s'agissant d'un géocodage, est d'une aide très moyenne, quand on
> parle d'équipements de la voie publique, et non de caractéristiques d'un
> bâtiment (commerce, ERP, etc). Ok la boîte aux lettres est rttachée, disons
> administrativement, à une adresse, mais ça ne dit pas du tout précisément
> où elle se situe sur le terrain.
>
> Dit autrement : quand la seule source disponible hors OpenData est le
> terrain, faut-il proposer l'intégration, ou juste suggérer une vérification
> sur place ?
>
> vincent
>
>
> ___
> 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

[Jérôme Seigneuret]

@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
 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




















Le 27 juin 2015 16:33, Thierry Bézecourt  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
> 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

[Vincent de Château-Thierry]

Le 27/06/2015 17:54, Frédéric Rodrigo a écrit :


Je trouve que tu fait à l'intégration le même procès que à l'import.
L'intégration n'a de sens que si entre le clic de souris et la chaise il
y un cerveau, je suis d'accord. Mais c'est justement pour cela que l'on
passe par une intégration et non une importation.

Je ne souhaite pas limite un outil sous prétexte qu'il est trop facile
(et rapide) à utiliser.


Pour lever un possible doute, mon message n'est surtout pas un procès 
envers Osmose.
Ce que je veux pointer, et qui différencie la démarche de celle des 
imports (essentiellement celui du bâti), c'est qu'on ne dispose pas de 
sources opposables à celle proposée dans Osmose, vu la faible emprise 
des objets sur le terrain. Donc le jugement de chacun, (aka le 
"cerveau"), n'est finalement pas si central dans la démarche. Et même 
l'adresse postale, s'agissant d'un géocodage, est d'une aide très 
moyenne, quand on parle d'équipements de la voie publique, et non de 
caractéristiques d'un bâtiment (commerce, ERP, etc). Ok la boîte aux 
lettres est rttachée, disons administrativement, à une adresse, mais ça 
ne dit pas du tout précisément où elle se situe sur le terrain.


Dit autrement : quand la seule source disponible hors OpenData est le 
terrain, faut-il proposer l'intégration, ou juste suggérer une 
vérification sur place ?


vincent

___
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

[Frédéric Rodrigo]

Le 27/06/2015 17:37, Vincent de Château-Thierry a écrit :

Bonjour,

(attention c'est long)

Le 27/06/2015 13:53, Frédéric Rodrigo a écrit :

Le 27/06/2015 09:49, Christian Quest a écrit :


Je ne vois non pas trop l'intérêt non plus du addr:postcode sur la boite
aux lettres.


Ça ne peut pas faire de mal.


Ça n'est pas parce que c'est fourni dans la source qu'on en veut
forcément en base, si ? On peut en avoir un usage indirect, si ça permet
de valider la cohérence d'une couche de polygones de codes postaux par
exemple, mais de là à dire que le code postal est un attribut des boîtes
aux lettres *dans* OSM, il y a de la marge.
D'une manière générale, tous les épisodes d'intégration d'OpenData nous
apprennent au moins une chose, c'est qu'on doit être critiques par
rapport aux sources. Ça ne s'applique pas qu'aux valeurs d'attributs ou
à la géométrie, le choix des tags est aussi concerné...


Bon. Si ce tag ne va a personne je l'enlève.


Il est est quand même évident qu'il faut corriger les positions à la
main avant intégration dans OSM.


Mais est-ce si évident ? Pour moi clairement non. Il est très simple
(trop ?) de valider les propositions de création de nodes telles que. Or
en dehors de sa propre connaissance du terrain, on n'a rien à confronter
à la source OD pour vérifier sa qualité. Ici rien n'est visible depuis
une orthophoto, on ne peut pas faire la même démarche qu'avec les routes
ou les bâtiments, où on a au moins bing et le Cadastre à confronter pour
se faire un jugement.
Pour des boîtes aux lettres, comme pour les bancs, les hydrants et
autres "micro" contenus, en dehors des endroits couverts par Mapillary,
on n'est dépourvu de sources à confronter/comparer.
Et comme il est simple de vérifier, sur des boîtes aux lettres de son
environnement, le côté pifométrique de la source (par chez moi c'est
flagrant, avec géocodage à la rue par exemple, ce qui est un non sens),
je suis plus que réservé sur l'intérêt de la proposition d'intégration.

Ce que je verrais plus volontiers :
- proposition de conflation pour les boîtes détectées mais dépourvues de
tag ref
- et simple visualisation (sans possibilité de bascule vers un éditeur)
pour les autres. C'est un simple porté à connaissance, qui peut
aiguiller chacun sur son territoire pour aller vérifier sur place
l'existence *et le positionnement* des boîtes.
Ça paraîtra fastidieux et/ou radical à certains, de mon côté je suis
convaincu de cette nécessité. Sans positionnement fin de ce type
d'objets (je mets les hydrants dans le même sac) OSM n'a pas de valeur
ajoutée à les intégrer. S'il s'agit juste de les accumuler en base sans
apport de qualité, on peut déjà le faire, d'un point de vue utilisateur,
sans passer par la case OSM.

vincent


Je trouve que tu fait à l'intégration le même procès que à l'import. 
L'intégration n'a de sens que si entre le clic de souris et la chaise il 
y un cerveau, je suis d'accord. Mais c'est justement pour cela que l'on 
passe par une intégration et non une importation.


Je ne souhaite pas limite un outil sous prétexte qu'il est trop facile 
(et rapide) à utiliser. Je fais assez confiance au cerveau qui se met au 
bout de la souri avant de cliquer dessus. Je suis toute fois d'accord 
que plus d'implication sur Osmose serait la bien venue. Je me pose 
d’ailleurs de plus en plus la question de la pertinence de séparer les 
intégrations dans un autre "Osmose".


Frédéric.


___
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

[Vincent de Château-Thierry]

Bonjour,

(attention c'est long)

Le 27/06/2015 13:53, Frédéric Rodrigo a écrit :

Le 27/06/2015 09:49, Christian Quest a écrit :


Je ne vois non pas trop l'intérêt non plus du addr:postcode sur la boite
aux lettres.


Ça ne peut pas faire de mal.


Ça n'est pas parce que c'est fourni dans la source qu'on en veut 
forcément en base, si ? On peut en avoir un usage indirect, si ça permet 
de valider la cohérence d'une couche de polygones de codes postaux par 
exemple, mais de là à dire que le code postal est un attribut des boîtes 
aux lettres *dans* OSM, il y a de la marge.
D'une manière générale, tous les épisodes d'intégration d'OpenData nous 
apprennent au moins une chose, c'est qu'on doit être critiques par 
rapport aux sources. Ça ne s'applique pas qu'aux valeurs d'attributs ou 
à la géométrie, le choix des tags est aussi concerné...



Il est est quand même évident qu'il faut corriger les positions à la
main avant intégration dans OSM.


Mais est-ce si évident ? Pour moi clairement non. Il est très simple 
(trop ?) de valider les propositions de création de nodes telles que. Or 
en dehors de sa propre connaissance du terrain, on n'a rien à confronter 
à la source OD pour vérifier sa qualité. Ici rien n'est visible depuis 
une orthophoto, on ne peut pas faire la même démarche qu'avec les routes 
ou les bâtiments, où on a au moins bing et le Cadastre à confronter pour 
se faire un jugement.
Pour des boîtes aux lettres, comme pour les bancs, les hydrants et 
autres "micro" contenus, en dehors des endroits couverts par Mapillary, 
on n'est dépourvu de sources à confronter/comparer.
Et comme il est simple de vérifier, sur des boîtes aux lettres de son 
environnement, le côté pifométrique de la source (par chez moi c'est 
flagrant, avec géocodage à la rue par exemple, ce qui est un non sens), 
je suis plus que réservé sur l'intérêt de la proposition d'intégration.


Ce que je verrais plus volontiers :
- proposition de conflation pour les boîtes détectées mais dépourvues de 
tag ref
- et simple visualisation (sans possibilité de bascule vers un éditeur) 
pour les autres. C'est un simple porté à connaissance, qui peut 
aiguiller chacun sur son territoire pour aller vérifier sur place 
l'existence *et le positionnement* des boîtes.
Ça paraîtra fastidieux et/ou radical à certains, de mon côté je suis 
convaincu de cette nécessité. Sans positionnement fin de ce type 
d'objets (je mets les hydrants dans le même sac) OSM n'a pas de valeur 
ajoutée à les intégrer. S'il s'agit juste de les accumuler en base sans 
apport de qualité, on peut déjà le faire, d'un point de vue utilisateur, 
sans passer par la case OSM.


vincent

___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

[OSM-talk-fr] Rendu QA: retour à la normale...

[Christian Quest]

Le rendu "QA" qui permet de visualiser les zones où il manque
potentiellement des routes et des bâtiments en comparant données OSM et
données carroyées de l'INSEE ne se mettait plus à jour correctement depuis
quelques temps.

Je viens (enfin) de corriger ça, et les premiers niveaux de zooms (6 à 11)
ont aussi été remis à jour.

http://tile.openstreetmap.fr/?zoom=6&lat=46.67312&lon=2.31237&layers=000BTFF

On compte actuellement:
- 405371 carreaux cyan indiquant des bâtiments potentiellement manquants
- 61995 carreaux magenta indiquant des routes potentiellement manquantes...

Ces stats remises à jour chaque nuit et accessibles sur
http://osm13.openstreetmap.fr/~cquest/qa_stats.txt

-- 
Christian Quest - OpenStreetMap France
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Chiffres romains

[Thierry Bézecourt]

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
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Chiffres romains

[Mathias Jérôme]

Le mieux est parfois l'ennemi du bien.Les chiffres créent des problèmes 
d'ambiguïté ? Une succession de lettres est elle un mot ou un nombre ? 
A priori c'est un mot.
Essayez d'écrire "Jean XXIII" et "Henri IV" ou encore "Louis XIV" sur une 
feuille de papier libre. 
Examinez ensuite si la graphie des lettres dans les nombres que vous avez écris 
"à la romaine" est la même que celle des autres lettres de votre écriture. 
Pour ma part ce n'est pas la même. Il s'agit bien de symboles.Le problème viens 
qu'il y a erreur de graphie lorsqu"on écrit "Louis XIV" en remplaçant les 
symboles des chiffres romains par des lettres ordinaires.Les structures de 
données n'ont pas été prévues pour supporter du chiffre romain ou l'utilisation 
des symboles est trop compliquée pour être utilisé dans le nom principal et 
pour autant il faut bien que le sens soit compris.Alors "Jean 23" "Henri 4" et 
"Louis 14" dans le name ont l'avantage de ne pas créé d'ambiguité, 
contrairement à "Henri IV" ou "George V", même si la graphie n'est pas exacte ( 
néanmoins le rendu doit pouvoir être possible en chiffre romains sur les 
cartes), alors que "Georges V" avec V majuscule n'est pas plus exact mais lui 
créé une ambiguité.La mise des chiffres en toute lettre me semble le meilleur 
compromis. 


 Le Vendredi 26 juin 2015 13h59, Eric Sibert  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] Chiffres romains

[Eric SIBERT]

J'ai fait l'essaie. J'ai mis un chiffre romain dans le nom d'une petite 
rue. Je vais voir ce que ça donne en terme de rendu, de recherche du nom 
de la rue et de guidage. Je vous tiens au courant.


Eric

___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Chiffres romains

[Jo]

De l'un côté ça me plaît, car maintenant c'est clair sans ambiguïtés que ce
ne sont pas des lettres. De l'autre côté ça signifie  que chaque client
doit réinterpréter chaque fois de nouveau pour déterminer la valeur. Un tag
supplémentaire pourrait remédier cela.
On Jun 27, 2015 3:01 PM, "Jérôme Seigneuret" 
wrote:

> Salut,
>
> Tous les caractères affichés dans la table marche en copier/coller si tu
> veux. Tu peux copier le tableau et le mettre sous open-office par exemple
> pour l'avoir en local (hors connexion) et copier/coller les chiffres que tu
> souhaites utiliser.
>
> Ce sont les vrai chiffres romain et non des lettres dans le tableau que
> j'ai fourni
>
>
>
> Le 27 juin 2015 14:44, Eric SIBERT  a écrit :
>
>> Le 26/06/2015 19:39, Jérôme Seigneuret 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   Ⅰ ROMAN NUMERAL ONE
>>> U+2161  Ⅱ   226133161   Ⅱ ROMAN NUMERAL TWO
>>>
>>
>>
>> Dans l'idée, ça me plairait. Après, comme ça a déjà été remarqué, c'est
>> un peu bâtard avec les correspondances pour chaque nombre arabe de 1 à 12
>> puis seulement les chiffres romains isolés au-delà.
>>
>> Par contre, je ne trouve pas comment saisir ça dans JOSM/WinXP. Je me
>> perds dans google. Si vous avez des pistes...
>>
>> Le copier/coller de thunderbird vers josm a l'air de fonctionner. Pour V,
>> je trouve dans le fichier osm le code : E2 85 A4.
>>
>> 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

[Jérôme Seigneuret]

Salut,

Tous les caractères affichés dans la table marche en copier/coller si tu
veux. Tu peux copier le tableau et le mettre sous open-office par exemple
pour l'avoir en local (hors connexion) et copier/coller les chiffres que tu
souhaites utiliser.

Ce sont les vrai chiffres romain et non des lettres dans le tableau que
j'ai fourni



Le 27 juin 2015 14:44, Eric SIBERT  a écrit :

> Le 26/06/2015 19:39, Jérôme Seigneuret 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   Ⅰ ROMAN NUMERAL ONE
>> U+2161  Ⅱ   226133161   Ⅱ ROMAN NUMERAL TWO
>>
>
>
> Dans l'idée, ça me plairait. Après, comme ça a déjà été remarqué, c'est un
> peu bâtard avec les correspondances pour chaque nombre arabe de 1 à 12 puis
> seulement les chiffres romains isolés au-delà.
>
> Par contre, je ne trouve pas comment saisir ça dans JOSM/WinXP. Je me
> perds dans google. Si vous avez des pistes...
>
> Le copier/coller de thunderbird vers josm a l'air de fonctionner. Pour V,
> je trouve dans le fichier osm le code : E2 85 A4.
>
> 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] Chiffres romains

[Eric SIBERT]

Le 26/06/2015 19:39, Jérôme Seigneuret 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   Ⅰ ROMAN NUMERAL ONE
U+2161  Ⅱ   226133161   Ⅱ ROMAN NUMERAL TWO



Dans l'idée, ça me plairait. Après, comme ça a déjà été remarqué, c'est 
un peu bâtard avec les correspondances pour chaque nombre arabe de 1 à 
12 puis seulement les chiffres romains isolés au-delà.


Par contre, je ne trouve pas comment saisir ça dans JOSM/WinXP. Je me 
perds dans google. Si vous avez des pistes...


Le copier/coller de thunderbird vers josm a l'air de fonctionner. Pour 
V, je trouve dans le fichier osm le code : E2 85 A4.


Eric



___
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

[Frédéric Rodrigo]

Les latitudes, longitudes sont également présentes. Mais pour l'instant 
l'analyse ne tourne que sur le serveur qui traite la France métropolitaine.


Le 27/06/2015 10:26, erwan salomon a écrit :

question bête
vous avez pris en compte que le mode de projection varie en fonction des
points enregistrés ?
bon j'y connais pas grand chose alors je ne sais pas quelle influence ça a
mais une grosse partie du fichier utilise ESPG :2154
puis ont trouve quelquesEPSG :2975 et EPSG :102113


Le 25 juin 2015 à 22:05, Frédéric Rodrigo a écrit :


Bonsoir,

Depuis quelques jours les boites au lettre de la poste dans l'espace
public sont disponible sur 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.

___
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] Intégration des Boites Postale dans Osmose

[Frédéric Rodrigo]

Le 27/06/2015 09:49, Christian Quest a écrit :

Autre problème avec cette analyse osmose: on avait utilisé jusque
maintenant ref=* et pas ref:FR:LaPoste...
- le rapprochement fait pas osmose ne semble pas se faire (ou alors la
tolérance de distance est insuffisante).
- les formulaires de JOSM prennent en compte ref=*
- on va avoir un mix entre les deux...


Je corrige, passage vers ref.


Il faut à mon avis vraiment la revoir, car entre la mauvaise qualité du
géocodage initial fait par La Poste et ces tags en contradiction avec ce
qui a été fait jusque maintenant on risque sérieusement de dégrader
plutôt que d'améliorer les données OSM.

Je ne vois non pas trop l'intérêt non plus du addr:postcode sur la boite
aux lettres.


Ça ne peut pas faire de mal.



Faites attention aussi à la fraicheur des données... dans mon bled
bourguignon, il y a plusieurs boites aux lettres qui ont été supprimées
à l'automne dernier, mais qui sont encore dans ce fichier opendata.


De mon coté, Bordeaux, en ville donc, je trouve la fraicheur des 
positions plutôt bonne, même si ça reste du géocodage.
Il est est quand même évident qu'il faut corriger les positions à la 
main avant intégration dans OSM.



Le 26 juin 2015 22:06, erwan salomon mailto:r...@gmx.fr>> a
écrit :

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


Concernant les 3 types de remontées c'est le fonctionnement normal 
d'Osmose pour l'intégration de données :

- boites dans OSM pas retrouvées dans l'OpenData
- boites dans l'OpenData pas retrouvées dans OSM
- proposition de rapprochement


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.



___
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

[erwan salomon]

question bête
vous avez pris en compte que le mode de projection varie en fonction des points 
enregistrés ?
bon j'y connais pas grand chose alors je ne sais pas quelle influence ça a
mais une grosse partie du fichier utilise ESPG :2154
puis ont trouve quelques EPSG :2975 et EPSG :102113


Le 25 juin 2015 à 22:05, Frédéric Rodrigo a écrit :

> Bonsoir,
> 
> Depuis quelques jours les boites au lettre de la poste dans l'espace public 
> sont disponible sur 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.
> 
> ___
> 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

[Christian Quest]

Autre problème avec cette analyse osmose: on avait utilisé jusque
maintenant ref=* et pas ref:FR:LaPoste...
- le rapprochement fait pas osmose ne semble pas se faire (ou alors la
tolérance de distance est insuffisante).
- les formulaires de JOSM prennent en compte ref=*
- on va avoir un mix entre les deux...

Il faut à mon avis vraiment la revoir, car entre la mauvaise qualité du
géocodage initial fait par La Poste et ces tags en contradiction avec ce
qui a été fait jusque maintenant on risque sérieusement de dégrader plutôt
que d'améliorer les données OSM.

Je ne vois non pas trop l'intérêt non plus du addr:postcode sur la boite
aux lettres.

Faites attention aussi à la fraicheur des données... dans mon bled
bourguignon, il y a plusieurs boites aux lettres qui ont été supprimées à
l'automne dernier, mais qui sont encore dans ce fichier opendata.



Le 26 juin 2015 22:06, erwan salomon  a écrit :

> 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%2C8023&zoom=13&lat=47.7354&lon=-3.4318&layer=Mapnik&overlays=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
>
>  ?
>
>
> ça évitera d'en avoir en plein champs ;)
>
>
>
> Le 25 juin 2015 22:31, Pierre-Yves Berrard
>
> mailto:pierre.yves.berr...@gmail.com
> >> a
>
> écrit :
>
>
>Le 25 juin 2015 22:05, Frédéric Rodrigo 
>> a écrit :
>
>
>Bonsoir,
>
>
>Depuis quelques jours les boites au lettre de la poste dans
>
>l'espace public sont disponible sur 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  >
>
>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
>
>