Re: [OSM-talk-fr] Suppression des tirets cadratins
Le 3 décembre 2012 19:40, te...@free.fr a écrit : Une frontière ça sépare deux pays, à priori sur un pied d'égalité. Il faudrait donc surtout stocker les deux informations et puis c'est le rendu qui décide comment nommer la frontière. À ce sujet, tout à fait d'accord. - Faut-il donner un nom à une frontière ? - Si oui, alors s'il y a un nom différent de chaque côté (c'est-à-dire qu'il n'y a pas consensus), alors pas de name=* mais un name:LANG=* pour toutes les langues LANG qu'on veut, et écrit de la façon la plus appropriée qui soit (selon le niveau des contributeurs). Voilà, on est d'accord : pourquoi diable donner un nom à une frontière, ou plutôt, pourquoi demander le nom de la frontière à un contributeur, surtout si au final le nom se limite à énumérer les deux régions (au sens large, voire géométrique) en utilisant un caractère de séparation. J'ai le sentiment qu'il serait plus pertinent de proposer le ou les tags ou les règles nécessaires pour saisir les deux noms des deux régions. La difficulté : porter une attention particulière à l'objectivité de la saisie de l'information pour ne pas froisser des susceptibilités et déclencher des guerres d'édition. Par exemple, éviter name1 et name2 car de chaque coté on se trouverait lésé. Ca serait quand même plus simple si le schéma de la BD OSM permettait le multivalué sans nécessiter le moindre artifice (un peu comme LDAP). Sur ce, bon troll^Wdiscussion ;-) -- Guilhem BONNEFILLE -=- JID: gu...@im.apinc.org MSN: guilhem_bonnefi...@hotmail.com -=- mailto:guilhem.bonnefi...@gmail.com -=- http://nathguil.free.fr/ ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Suppression des tirets cadratins
2012/12/3 Jo winfi...@gmail.com: Pour chaque niveau nous faisons une relation et dans la relation il y l'indication des deux entités géographiques qui sont séparées par cette frontière. Donc pas besoin de name et encore moins de name:xx. Quand tu auras réparé quelques frontières cassées par des débutants qui ne comprennent pas les 'relations', on en reparlera ;-) Soit on supprime tous les tags (option Sly), soit on garde les tags avec des informations suffisament pertinentes pour les mappeurs. Paradoxalement, je ne pensais même pas au rendu lorsque j'ai lancé cette discussion. Ce qui me gêne, c'est la présence de ce caractère spécial que je suis incapable de reproduire dans un tag 'name', affiché ou pas sur la carte (ça fait longtemps que j'ai dépassé cette problématique de l'affichage). Quant au sujet des caractères spéciaux et spécifiques à certaines langues: c'est pour cette raison-là que unicode a été développé; profitons-en. Oui pour les caractères spéciaux comme é, è, ë, œ qui sont de vrais informations spécifiques à la langue. Mais pas le tiret long, indépendant des langues et qui n'est que pure cosmétique alors qu'il existe d'autres séparateurs plus simples. Pieren ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Suppression des tirets cadratins
De : Pieren 2012/12/3 Jo : Pour chaque niveau nous faisons une relation et dans la relation il y l'indication des deux entités géographiques qui sont séparées par cette frontière. Donc pas besoin de name et encore moins de name:xx. +1 Quand tu auras réparé quelques frontières cassées par des débutants qui ne comprennent pas les 'relations', on en reparlera ;-) Soit on supprime tous les tags (option Sly), soit on garde les tags avec des informations suffisament pertinentes pour les mappeurs. Je rajoute une 3e alternative : soit on se contente des tags nécessaires et jusque là consensuels (admin_level boundary) sans chercher à tagguer en fonction de l'éditeur. Ce qui me gêne c'est avant tout le recours au tag name, qui n'est pas anodin, pour une info qui relève de la note, du post-it, bref, d'une commodité d'édition et surtout pas d'un nom. Dans l'éditeur de relations de JOSM, en laissant son curseur sur une ligne, on a dans une bulle la liste des tags de l'objet en question. En convertissant les 'name=*' en 'note=*' (par exemple), on garde l'info, mais on ne squatte pas 'name'. vincent Une messagerie gratuite, garantie à vie et des services en plus, ça vous tente ? Je crée ma boîte mail www.laposte.net ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Suppression des tirets cadratins
Le 4 décembre 2012 09:50, Pieren pier...@gmail.com a écrit : Quand tu auras réparé quelques frontières cassées par des débutants qui ne comprennent pas les 'relations', on en reparlera ;-) Je te rejoins là dessus ! Combien de fois j'ai déjà vu un commentaire de modification dans la base par quelqu'un qui supprime un chemin de frontière avec l'idée suivante : il n'y a aucune route à cet endroit là, ce trait me gène pour retracer autre chose qui est bien visible, allez hop ! je vire ce truc qui ne sert à rien ! Et voilà il envoie SES objets et n'a rien à faire des autres relations que de toute façon il n'a même pas chargées; il vagabonde sur la carte dans JOSM en ne chargeant presque rien de la base (il ne pouvait donc rien voir du tout, la seule chose qui l'intéresse c'est l'image Bing, et ce ne sont pas les hacuures par dessus l'image qui le gênent, il sait très bien qu'il n'a pas chargé toutes les données de la zone mais n'a pas non plus chargé les relations dépendantes des objets qu'il supprime ou scinde en plusieurs parties, ou bien qu'il remplace par d'autres en traçant d'abord SON chemin, puis en virant l'autre). Et cela ne concerne pas QUE les débutants, un oubli est vite arrivé. Un champ name en revanche est toujours visible, partout chaque fois qu'on sélectionne le moindre objet. Sur un chemin frontière il n'indique aucune priorité droite-gauche, juste une association de deux noms, même si pour clarifier les choses et stabiliser la présentation on peut fixer une règle simple : l'objet le plus peuplé vient en premier. Pour rendre les modifs claires, également, on trie les objets, même si dans la base ou pour le rendu ce n'est pas nécessaire. On précise aussi les rôles inner/outer afin aussi de permettre de recoller les morceaux en cas de casse ultérieure : on voit vite ce qui a été cassé et comment réparer, et on laisse un schéma propre (ceux qui utilisent Potlatch n'ont pas cette option de tri, mais eux ils voient TOUS les objets dépendants (mais sont contraints de travailler sur des zones de plus en plus petites : ils sont incapables de regarder quelquechose de la taille d'une commune entière, les relations frontalières plus grandes qu'un quartier ou un petit village ne sont donc pas créées par eux, ni même les routes les plus longues, ils ont même du mal à charger et voir toute une rue dans une ville dense). Bref Potlatch c'est bien pour des modifs très locales (c'est même plus précis et plus facile et rapide à faire dans Potlatch que dans JOSM : par exemple affiner un tracé pour justement ajouter d'autres détails autour). Les deux éditeurs sont donc complémentaires plutôt que concurrents. Mais la plupart des utilisateurs ne savent utiliser que l'un ou l'autre et ont du mal à se faire à la différence d'interface. Mais même dans Potlatch, il est difficile de savoir à quoi correspond un trait : tous les traits se ressemblent, et le dialogue affichant un nom est souvent masqué. Si quelquechose apparait dans la vue Simplifiée, ce ne sera JAMAIS une note=, mais le name= au moins y sera. On ne verra pas les types de boundary ou admin_level. Le name est la meilleure balise permettant de savoir qu'il y a quelquechose et que c'est une frontière. De plus l'éditeur de relations de Potlatch est très pénible à utilisé tellement il est minimaliste et mal foutu : on a tôt fait de se tromper car on ne voit que des identifiants numériques et pas grand chose d'autre (aucune analyse de connexité ou des membres en doublons ou manquants). Il n'y a pas d'outil idéal, mais JOSM maitrisé permet d'aller plus loin que Potlatch. JOSM fonctionnera bien pour tracer rapidement la structure de quelque chose qu'on affinera ensuite dans Potlatch. Et j'utilise aussi rawedit pour certaines modifs directes en XML (dans Osmose), limitées seulement à quelques attributs (non géométriques et non relationnels comme les listes de membres, mais éventuellement pour corriger un rôle erroné) dans le même objet et faciles à éditer sans erreur dans le XML (Osmose revérifiera derrière si on marque même si on marque corrigé, car l'ovjet a changé alors de version, Osmose ne signale plus rien sur un objet marqué faux positif tant que l'objet lui-même n'a pas changé de version depuis l'analyse qui l'avait signalé). Osmose est rapide : quelques minutes après la modif (avec les minute diffs quand elles sont actives), l'objet est à nouveau analysé (mais les erreurs non marquées corrigées dessus persistent toutes car la modif peut avoir été faite sans tenir compte de l'anomalie précédente, ce qui peut là encore induire en erreur les modificateurs (qui vont alors aggraver le problème en supposant que c'était correct avant leur passage et que si erreurs ils font ce n'est pas de leur faute). si on a corrigé comme il fallait, il ne signalera rien derrière la modif. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Suppression des tirets cadratins
Bonjour tout le monde, Ouf, quel thread. Au risque de répéter ce qui a était dit (j'ai pas pu tout lire), de ma lorgnette l'erreur pointée est surtout dans le schéma de l'information. Pourquoi mettre un nom à une frontière ? Ah Guilem, il fallait lire un peu mieux :) Le sujet principal est encore dans le titre, Suppression des tirets cadratins (remplacer tirets cadratins par tout caractère ou toute formulation spécifique à une langue donnée). Je ne suis pas mécontent d'avoir tilté sur le sujet, au vu des réactions de chacun... Je vais tenter un résumé sur le fond, peut-être devrait-on créer une page sur un wiki :D POUR LA SIMPLICITÉ + Des outils faciles à développer et à maintenir à l'international. + Une approche évidente pour la majorité des participants. - On impose (et on s'impose) des limites qui n'existent pas réellement dans la base de données. - On perd des informations utiles (ON NE PEUT PAS remplacer espace-tiret-espace par un tiret long) voire importantes (exemple du œ ou de tous les caractères sortant du domaine de l'ASCII). - Sur ce principe, on entre du contenu essentiellement en pensant à son traitement (données) plutôt qu'à sa finalité (information). POUR LA RICHESSE DES DONNÉES + Des informations plus précises. + On n'empêche pas d'enrichir le contenu, toute participation peut toujours être améliorée. + On ne considère pas le contenu comme uniquement destiné à un rendu sur une carte. - On contraint les outils à plus de complexité (au développement, pas à l'usage). - On risque une diversité entre les contenus pointilleux et les contenus basiques (mais cela est le propre d'une base de données ouverte, voir la diversité des tags existants). - On fait peur aux nouveaux contributeurs qui n'ont pas le même niveau de maturité (mais cela est valable également pour d'autres sujets sur OSM, et ça n'a empêché personne de contribuer, au contraire c'est en général constructif). Si des arguments en faveur ou contre ces points de vue ont été abordés mais pas cités ci-dessus (sans recoupement des idées), je vous invite à compléter. Je manque de neutralité pour arbitrer le sujet : qui n'a pas de parti-pris ? Teuxe PS. Ce débat n'a-t-il lieu que pour le tag name=* ? ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Suppression des tirets cadratins
Une frontière ça sépare deux pays, à priori sur un pied d'égalité. Il faudrait donc surtout stocker les deux informations et puis c'est le rendu qui décide comment nommer la frontière. À ce sujet, tout à fait d'accord. - Faut-il donner un nom à une frontière ? - Si oui, alors s'il y a un nom différent de chaque côté (c'est-à-dire qu'il n'y a pas consensus), alors pas de name=* mais un name:LANG=* pour toutes les langues LANG qu'on veut, et écrit de la façon la plus appropriée qui soit (selon le niveau des contributeurs). Au passage, je ne sais pas si la règle est édictée quelque part, mais il semble logique pour un système géographique de privilégier l'usage local dans le remplissage du champ name=* et d'indiquer les spécificités dans les langues étrangères si elles existent dans le champ name:LANG=*. Par exemple : http://www.openstreetmap.org/browse/node/26686563 (name:fr=* n'a pas besoin d'être précisé) Bien sûr pour les entités partagées entre pays, comme les frontières, cette règle n'a pas lieu d'être, et donc le tag name=* indépendant de la langue ne devrait pas être présent – sauf si on parle la même langue de chaque côté ou qu'on a le même nom :D Teuxe - Mail original - De: Guilhem Bonnefille guilhem.bonnefi...@gmail.com À: Discussions sur OSM en français talk-fr@openstreetmap.org Envoyé: Vendredi 30 Novembre 2012 15:21:43 Objet: Re: [OSM-talk-fr] Suppression des tirets cadratins Le 27 novembre 2012 17:51, Pieren pier...@gmail.com a écrit : Petit rappel : OSM est une base de données, pas une société d'édition de beaux livres ou de belles cartes avec de beaux tirets longs, moyens ou carrés pour faire joli. Les caractères de ponctuation doivent pouvoir être saisis par n'importe quel quidam sur n'importe quel clavier et être reconnus par n'importe quel logiciel. [...] Ouf, quel thread. Au risque de répéter ce qui a était dit (j'ai pas pu tout lire), de ma lorgnette l'erreur pointée est surtout dans le schéma de l'information. Pourquoi mettre un nom à une frontière ? Une frontière ça sépare deux pays, à priori sur un pied d'égalité. Il faudrait donc surtout stocker les deux informations et puis c'est le rendu qui décide comment nommer la frontière. -- Guilhem BONNEFILLE -=- JID: gu...@im.apinc.org MSN: guilhem_bonnefi...@hotmail.com -=- mailto:guilhem.bonnefi...@gmail.com -=- http://nathguil.free.fr/ ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Suppression des tirets cadratins
teuxe a écrit : Au passage, je ne sais pas si la règle est édictée quelque part, mais il semble logique pour un système géographique de privilégier l'usage local dans le remplissage du champ name=* et d'indiquer les spécificités dans les langues étrangères si elles existent dans le champ name:LANG=*. Par exemple : http://www.openstreetmap.org/browse/node/26686563 (name:fr=* n'a pas besoin d'être précisé) Effectivement, l'attribut name indique habituellement la langue locale. Par contre, cette langue locale n'est pas précisée. Aussi, il n'est pas clair si l'on devrait systématiquement ajouter un attribut name:fr=. Idéalement, on devrait indiquer la langue locale avec un attribut du type lang=fr. Mais à répéter à chaque fois qu'il y a un nom? Pierre De : te...@free.fr te...@free.fr À : Discussions sur OSM en français talk-fr@openstreetmap.org Envoyé le : Lundi 3 décembre 2012 13h40 Objet : Re: [OSM-talk-fr] Suppression des tirets cadratins Une frontière ça sépare deux pays, à priori sur un pied d'égalité. Il faudrait donc surtout stocker les deux informations et puis c'est le rendu qui décide comment nommer la frontière. À ce sujet, tout à fait d'accord. - Faut-il donner un nom à une frontière ? - Si oui, alors s'il y a un nom différent de chaque côté (c'est-à-dire qu'il n'y a pas consensus), alors pas de name=* mais un name:LANG=* pour toutes les langues LANG qu'on veut, et écrit de la façon la plus appropriée qui soit (selon le niveau des contributeurs). Au passage, je ne sais pas si la règle est édictée quelque part, mais il semble logique pour un système géographique de privilégier l'usage local dans le remplissage du champ name=* et d'indiquer les spécificités dans les langues étrangères si elles existent dans le champ name:LANG=*. Par exemple : http://www.openstreetmap.org/browse/node/26686563 (name:fr=* n'a pas besoin d'être précisé) Bien sûr pour les entités partagées entre pays, comme les frontières, cette règle n'a pas lieu d'être, et donc le tag name=* indépendant de la langue ne devrait pas être présent – sauf si on parle la même langue de chaque côté ou qu'on a le même nom :D Teuxe - Mail original - De: Guilhem Bonnefille guilhem.bonnefi...@gmail.com À: Discussions sur OSM en français talk-fr@openstreetmap.org Envoyé: Vendredi 30 Novembre 2012 15:21:43 Objet: Re: [OSM-talk-fr] Suppression des tirets cadratins Le 27 novembre 2012 17:51, Pieren pier...@gmail.com a écrit : Petit rappel : OSM est une base de données, pas une société d'édition de beaux livres ou de belles cartes avec de beaux tirets longs, moyens ou carrés pour faire joli. Les caractères de ponctuation doivent pouvoir être saisis par n'importe quel quidam sur n'importe quel clavier et être reconnus par n'importe quel logiciel. [...] Ouf, quel thread. Au risque de répéter ce qui a était dit (j'ai pas pu tout lire), de ma lorgnette l'erreur pointée est surtout dans le schéma de l'information. Pourquoi mettre un nom à une frontière ? Une frontière ça sépare deux pays, à priori sur un pied d'égalité. Il faudrait donc surtout stocker les deux informations et puis c'est le rendu qui décide comment nommer la frontière. -- Guilhem BONNEFILLE -=- JID: gu...@im.apinc.org MSN: guilhem_bonnefi...@hotmail.com -=- mailto:guilhem.bonnefi...@gmail.com -=- http://nathguil.free.fr/ ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Suppression des tirets cadratins
Et moi qui pensais qu'une frontière pouvait séparer deux continents, deux pays, deux états, deux provinces, deux cantons, deux villages. Pour chaque niveau nous faisons une relation et dans la relation il y l'indication des deux entités géographiques qui sont séparées par cette frontière. Donc pas besoin de name et encore moins de name:xx. Quant au sujet des caractères spéciaux et spécifiques à certaines langues: c'est pour cette raison-là que unicode a été développé; profitons-en. Polyglot 2012/12/3 Pierre Béland infosbelas-...@yahoo.fr teuxe a écrit : Au passage, je ne sais pas si la règle est édictée quelque part, mais il semble logique pour un système géographique de privilégier l'usage local dans le remplissage du champ name=* et d'indiquer les spécificités dans les langues étrangères si elles existent dans le champ name:LANG=*. Par exemple : http://www.openstreetmap.org/browse/node/26686563(name:fr=* n'a pas besoin d'être précisé) Effectivement, l'attribut name indique habituellement la langue locale. Par contre, cette langue locale n'est pas précisée. Aussi, il n'est pas clair si l'on devrait systématiquement ajouter un attribut name:fr=. Idéalement, on devrait indiquer la langue locale avec un attribut du type lang=fr. Mais à répéter à chaque fois qu'il y a un nom? Pierre -- *De :* te...@free.fr te...@free.fr *À :* Discussions sur OSM en français talk-fr@openstreetmap.org *Envoyé le :* Lundi 3 décembre 2012 13h40 *Objet :* Re: [OSM-talk-fr] Suppression des tirets cadratins Une frontière ça sépare deux pays, à priori sur un pied d'égalité. Il faudrait donc surtout stocker les deux informations et puis c'est le rendu qui décide comment nommer la frontière. À ce sujet, tout à fait d'accord. - Faut-il donner un nom à une frontière ? - Si oui, alors s'il y a un nom différent de chaque côté (c'est-à-dire qu'il n'y a pas consensus), alors pas de name=* mais un name:LANG=* pour toutes les langues LANG qu'on veut, et écrit de la façon la plus appropriée qui soit (selon le niveau des contributeurs). Au passage, je ne sais pas si la règle est édictée quelque part, mais il semble logique pour un système géographique de privilégier l'usage local dans le remplissage du champ name=* et d'indiquer les spécificités dans les langues étrangères si elles existent dans le champ name:LANG=*. Par exemple : http://www.openstreetmap.org/browse/node/26686563(name:fr=* n'a pas besoin d'être précisé) Bien sûr pour les entités partagées entre pays, comme les frontières, cette règle n'a pas lieu d'être, et donc le tag name=* indépendant de la langue ne devrait pas être présent – sauf si on parle la même langue de chaque côté ou qu'on a le même nom :D Teuxe - Mail original - De: Guilhem Bonnefille guilhem.bonnefi...@gmail.com À: Discussions sur OSM en français talk-fr@openstreetmap.org Envoyé: Vendredi 30 Novembre 2012 15:21:43 Objet: Re: [OSM-talk-fr] Suppression des tirets cadratins Le 27 novembre 2012 17:51, Pieren pier...@gmail.com a écrit : Petit rappel : OSM est une base de données, pas une société d'édition de beaux livres ou de belles cartes avec de beaux tirets longs, moyens ou carrés pour faire joli. Les caractères de ponctuation doivent pouvoir être saisis par n'importe quel quidam sur n'importe quel clavier et être reconnus par n'importe quel logiciel. [...] Ouf, quel thread. Au risque de répéter ce qui a était dit (j'ai pas pu tout lire), de ma lorgnette l'erreur pointée est surtout dans le schéma de l'information. Pourquoi mettre un nom à une frontière ? Une frontière ça sépare deux pays, à priori sur un pied d'égalité. Il faudrait donc surtout stocker les deux informations et puis c'est le rendu qui décide comment nommer la frontière. -- Guilhem BONNEFILLE -=- JID: gu...@im.apinc.org MSN: guilhem_bonnefi...@hotmail.com -=- mailto:guilhem.bonnefi...@gmail.com -=- http://nathguil.free.fr/ ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Suppression des tirets cadratins
Le 3 décembre 2012 19:40, te...@free.fr a écrit : Au passage, je ne sais pas si la règle est édictée quelque part, mais il semble logique pour un système géographique de privilégier l'usage local dans le remplissage du champ name=* et d'indiquer les spécificités dans les langues étrangères si elles existent dans le champ name:LANG=*. Par exemple : http://www.openstreetmap.org/browse/node/26686563(name:fr=* n'a pas besoin d'être précisé) Pourquoi pas besoin ? Note mon précédent message qui indique qu'il peut être nécessaire d'indiquer justement dans quelle langue la valeur d'un name= est écrit, (ne serait-ce que pour autoriser ou non des substitutions automatique dedans dans un rendu, par exemple pour générer des abréviations qui ont un sens dans la langue source, ou justement pour des corrections typographiques, mais aussi pour des adaptations — y compris la génération automatique des translittérations pour les écritures non précisées dans la base : Par exemple on trouve en France plein de pseudo-noms russes alors que ce ne sont QUE des translitérations et PAS des traductions réelles (la présence de ces translittérations dans la base est à mon avis inutile, d'autant plus qu'il existe diverses méthodes de translittération, notamment arabe-latin, cyrillique-latin, sinogrammes-latin, et même hangûl-latin, même pour un même couple de langues, et même si certaines sont normalisées internationalement pour la toponymie et ont encore moins besoin d'être stockées dans la base — Un exemple : la Wikipédia russe, est pleine de translittérations fantaisistes, qui sont même incohérentes dans les toponymes composés dont les composant signifiants sont pourtant individuellement traduits et non translitérés: un exemple cocasse est la Seine-Saint-Denis qui est entièrement translitérée sous une forme pseudo-phonétique qu'on lirait en latin comme Cène-Cène-Dénisse (sic !), alors que Seine est traduite sous une forme qu'on peut lire Céna et Saint-Denis est traduit sous une forme similaire à Sinkt-Denis avec le mot russe pour Saint, ce qui veut dire que la traduction devrait être similaire à Céna–Sinkt-Denis sans répétition apparente. Mais rapidement la base OSM se remplit de ces translitérations fantaisistes, Wikipédia ayant tendance à présenter ces translitérations comme si c'était des traductions, il suscite des modifications à la langue russe elle-même et développe l'incompréhension, et multiplie les homonymies en russe, là où le nom initial en français ne souffrait d'aucune ambiguïté et que cette distinction aurait pu être gardée aussi en russe, en utilisant sa langue et non des translittérations souvent hasardeuses. — Tant qu'on ne précise pas au moins quelle est la langue par défaut dans une zone géographique donnée, c'est difficile de savoir quoi faire de la valeur name= à laquelle on ne peut donc pas toucher. Je veux bien qu'on ne répète pas la valeur de name=* (dans une langue par défaut non précisée dans cette clé) dans name:fr=, à condition qu'on ait quelquepart l'information comme quoi cette langue par défaut est bien le français, ou qu'elle peut s'appliquer au français — ce qui suppose une clé du genre name:langs=fr. Si on était vraiment rigoureux, on devrait toujours mentionner la (ou les) langue(s) pour laquelle une même valeur donnée s'applique, et on éviterait de répéter aussi la même valeur dans plusieurs name:LANG=, en utilisant une syntaxe de clé comme name:LANG1,LANG2,LANG3= (mais cela au prix d'une modification des outils cherchant à internationaliser un nom dans une langue donnée) Et de fait il n'y aurait plus aucune clé name=, mais on pourrait avoir encore une clé comme name:LANG1,LANG2,*= pour indiquer (avec une * ici) dans la liste des langues mises dans une clé, laquelle des clés contient la valeur par défaut pour les langues qu'on ne trouve pas listées dans les autres clés e la forme name:LANG1,...,LANGn=. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Suppression des tirets cadratins
si je suis d'accord sur le principe, il reste possible aux tenants de la simplicité (et ça aussi c'est bien, mangez-en) d'utiliser des tirets simples partout, à condition de les encadrer d'espaces -- ou non -- selon le cas. On peut donc se contenter de : Champs-Élysées - Clemenceau Évidemment ! Il n’a jamais été question de contraindre ceux qui ne veulent ou ne peuvent pas à utiliser une typographie avancée. Mais, comme on est d’accord qu’une typographie avancée enrichi les données, il ne faut pas contraindre ceux qui le veulent et le peuvent à ne pas l’utiliser. Cordialement, -- Mikaël Cordon, mickey86 Le 29 novembre 2012 22:08, Jean-Francois Nifenecker jean-francois.nifenec...@laposte.net a écrit : Bonjour, Le 28/11/2012 18:29, te...@free.fr a écrit : Champs-Élysées — Clemenceau (avenue des Champs-Élysées, place Clemenceau) si je suis d'accord sur le principe, il reste possible aux tenants de la simplicité (et ça aussi c'est bien, mangez-en) d'utiliser des tirets simples partout, à condition de les encadrer d'espaces -- ou non -- selon le cas. On peut donc se contenter de : Champs-Élysées - Clemenceau A+ -- Jean-Francois Nifenecker, Bordeaux __**_ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.**org/listinfo/talk-frhttp://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Suppression des tirets cadratins
2012/11/30 Mikaël Cordon mikael.cor...@gmail.com: Mais, comme on est d’accord qu’une typographie avancée enrichi les données, Bin non, il n'y a qu'un petit groupe qui tente de faire croire que c'est mieux avec que sans... Même les étrangers s'étonnent de la présence de ce caractère chez-nous (cf la mention de Sly). Si j'ai lancé la discussion, c'est parce que la solution préférée d'une infime minorité s'impose lentement et en silence à la majorité. Pieren ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Suppression des tirets cadratins
Bonjour, Je fais parti des silencieux. J'ai suivi ce fil de discussion. On ne peut pas forcer les gens à utiliser ce tiret, mais je ne comprends pas pourquoi on empêcherait leur utilisation, et je ne comprends pas du tout, mais alors vraiment pas du tout, pourquoi on les supprimerait. Stéphane ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Suppression des tirets cadratins
H tu te prends donc à utiliser la notation ASCII avec un double signe moins (même encadrés d'espaces). C'est une vieille notation anglophone qui effectivement remplace un unique tiret demi-cadratin. Le cadratin utilisant une succession de 3 ou 4 tirets ASCII. Et tu crois que c'est simple ? On a une base Unicode, et ces vieilles notations de l'ASCII (y compris - pour remplacer une vraie flèche) c'est du passé. Mais tu noteras quand même que tu as eu besoin de distinguer les tirets en les multipliant. On trouve depuis peu cette notation (avec des tirets simples réitérés comme dans nom1--nom2 pour distinguer de nom1-nom2 utilisé dans les noms composés inséparables) dans les fichiers INSEE de l'état-civil pour les noms de familles associant deux noms patronymiques avant mariage, uniquement parce que ces fichiers ne supportent pas Unicode encore aujourd'hui (ce qui ensuite se retrouve sur les passeports imprimés), ni même Windows-1252, mais juste ISO 8859-1 (pour garder les accents). L'INSEE a été critiquée pour cette décision (on peut comprendre qu'elle ait besoin d'enregistrer les romanisations pour un usage français, mais elle doit encore être capable de garder les orthographes originales (même si c'est du chinois, du grec, du cyrillique ou de l'arabe, car seuls ces noms sont non ambigus et réellement officiels) dans des champs séparés de celui consacré à la romanisation (mais tant qu'à faire, améliorer les outils pour que ces romanisations soient automatisées selon des règles émanant du pays d'origine et non selon ses propres règles, et de ne réserver les autres romanisations qu'aux seuls noms d'usage choisis et réellement enregistrés officiellement par le demandeur à l'INSEE). Mais on n'a aucune raison d'utiliser ces vieilles notations. La base Unicode est en Unicode pour supporter d'autres alphabets. Les outils qui ne savent ps lire l'Unicode ne pourront pas travailler sur les libellés en cyrillique ou en grec par exemple (ils devront utiliser de coûteuses et instables romanisations). Il n'y a aucun intérêt dans le cas de la base OSM. Les outils doivent s'adapter à l'Unicode pour gagner en stabilité. Ce n'est pas à a basse OSM de s'adapter à ces outils. Mais si ces outils confondent tous les tirets (simples, multiples, demi-cadratin, cadratin, voire aussi les flèches unidirectionnelles ou bidirectionelles) comme un seul tiret simple, ils génèrent des ambiguïtés et en prennent le risque. Mais doit-on aussi les confondre en introduisant volontairement ces ambiguités ? Les tirets simples de l'ASCII ont toujours été ambigus dans leur signification. OK si certains ne font pas la distinction ils peuvent saisir des tirets simples, ou des successions de tirets simples (et autres polygrammes pour les flèches), mais on ne doit pas interdire aux autres de corriger avec les bons caractères signifiants et non ambigus. Le 30 novembre 2012 09:30, Mikaël Cordon mikael.cor...@gmail.com a écrit : si je suis d'accord sur le principe, il reste possible aux tenants de la simplicité (et ça aussi c'est bien, mangez-en) d'utiliser des tirets simples partout, à condition de les encadrer d'espaces -- ou non -- selon le cas. On peut donc se contenter de : Champs-Élysées - Clemenceau Évidemment ! Il n’a jamais été question de contraindre ceux qui ne veulent ou ne peuvent pas à utiliser une typographie avancée. Mais, comme on est d’accord qu’une typographie avancée enrichi les données, il ne faut pas contraindre ceux qui le veulent et le peuvent à ne pas l’utiliser. Cordialement, -- Mikaël Cordon, mickey86 Le 29 novembre 2012 22:08, Jean-Francois Nifenecker jean-francois.nifenec...@laposte.net a écrit : Bonjour, Le 28/11/2012 18:29, te...@free.fr a écrit : Champs-Élysées — Clemenceau (avenue des Champs-Élysées, place Clemenceau) si je suis d'accord sur le principe, il reste possible aux tenants de la simplicité (et ça aussi c'est bien, mangez-en) d'utiliser des tirets simples partout, à condition de les encadrer d'espaces -- ou non -- selon le cas. On peut donc se contenter de : Champs-Élysées - Clemenceau A+ -- Jean-Francois Nifenecker, Bordeaux __**_ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.**org/listinfo/talk-frhttp://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Suppression des tirets cadratins
Le 30 novembre 2012 10:55, Stéphane Péneau stephane.pen...@wanadoo.fr a écrit : Bonjour, Je fais parti des silencieux. J'ai suivi ce fil de discussion. On ne peut pas forcer les gens à utiliser ce tiret, mais je ne comprends pas pourquoi on empêcherait leur utilisation, et je ne comprends pas du tout, mais alors vraiment pas du tout, pourquoi on les supprimerait. Cela permet d'avoir dans OSM des données homogènes. C'est pour cela qu'un choix a été fait sur les noms de rue, même si celui-ci ne respect pas les canons de telle ou telle académie, ils ont l'avantage d'être homogènes. Je pense qu'une même règle devrait être suivie sur les séparateurs, en indiquant clairement la règle du tiret seul (trait d'union) et du tiret avec espace (séparateur). Une minorité de contributeur maitrise les subtilités des tirets, cadratins et traits d'union pendant qu'une majorité de maitrise pas ces subtilités et contribuera avec de simples tirets du 6. Plus on a de mélange plus on doit adapter les algorithmes traitant les noms pour gérer ces subtilités, alors qu'à l'inverse, la mise en forme typographique peut se faire simplement en partant de tiret simples ou avec espaces. Voilà pourquoi je pense que l'on devrait en rester aux tirets avec ou sans espace et uniformiser dans ce sens pour favoriser l'homogénéité des données au détriment des subtilités typographiques plus ou moins franco-françaises (OSM est un projet international). -- Christian Quest - OpenStreetMap France - http://openstreetmap.fr/u/cquest ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Suppression des tirets cadratins
On 30/11/2012 10:57, Philippe Verdy wrote: [..] Les tirets simples de l'ASCII ont toujours été ambigus dans leur signification. La liste des signes qu'ils remplacent est impressionnante : * Trait d'union/signe moins : - * Trait d'union conditionnel : - * Trait d'union : - * Trait d'union insécable : - * Tiret numérique : - * Tiret demi-cadratin : -- * Tiret cadratin : --- * Barre horizontale : -- * Puce trait d'union : ? * Signe moins : - * Signe moins minuscule : - Source : http://fr.wikipedia.org/wiki/Tiret L'embarras du choix - un vrai problème de riche. Et j'ai utilisé un tiret ASCII dans ma phrase précédente... Malédiction ! ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Suppression des tirets cadratins
2012/11/30 Jean-Marc Liotier j...@liotier.org: Et je tiens à souligner encore une fois que dans les fichiers fournis par la RATP elle-même, ils ne s'embarrassent pas de tels caractères spéciaux ! +1 avec Christian sur l'homogénéité. On ne peut pas empêcher les gens de mettre le tiret qu'ils souhaitent. Mais il faut se mettre d'accord sur une règle commune, celle qui serait, par exemple, documentée dans le wiki. Ou, autre exemple, signalée comme erronée dans osmose si elle n'était pas respectée. Pieren ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Suppression des tirets cadratins
Salut, Et je tiens à souligner encore une fois que dans les fichiers fournis par la RATP elle-même, ils ne s'embarrassent pas de tels caractères spéciaux ! pour ma part ça n'est pas une excuse : je ne pense pas qu'on puisse s'appuyer sur un seul mauvais exemple pour en tirer des généralités. C'est comme de dire que si certains écrivent en langage sms, alors on a pas de raison de mettre des mots entiers ... +1 avec Christian sur l'homogénéité. On ne peut pas empêcher les gens de mettre le tiret qu'ils souhaitent. Mais il faut se mettre d'accord sur une règle commune, celle qui serait, par exemple, documentée dans le wiki. Ou, autre exemple, signalée comme erronée dans osmose si elle n'était pas respectée. totalement d'accord sur l'homogénéité, notamment sur le tag name, encore que si on travaille bien en unicode il n'y a normalement pas de problèmes. Par contre je rejoins la proposition qui a été faite de ne pas se restreindre aux caractères ascii dans le tag name:fr ! Est-ce que quelqu'un sais quel est le consensus officiel pour les autres pays avec des particularités de caractères/typologie, notamment les alphabets différents ? Sylvain ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Suppression des tirets cadratins
Encore une fois la question de lhomogénéité ne se pose pas ici sur les tirets et surtout pas dans les noms. Contrairement à la casse des lettres qui est un critère discriminant dans les recherches, il n'est pas discriminant dans les recherches. Quant au rendu je ne vois pas ce qui te choque, ton critère est uniquement basé sur un apriori de rendu homogène qui en l'occurence ici n'est même pas gênant. Ton argument c'est de taguer pour les rendu (pour le rendre homogène). En plus tu continues à perpétuer l'idée (fausse) que ce n'est QUE de la typographie de présentation alors que la distinction est sémantique et qu'il n'y a PAS de règle typographique autorisant de changer les tirets automatiquement de l'un à l'autre (et j'ai donné des exemples). En revanche un même moteur de rendu pourra toujours, s'il ne sait pas les afficher pour les distinguer, les uniformiser, mais l'inverse, NON, il ne le fera JAMAIS car il ne saura PAS le faire correctement (ce ne sera qu'une heuristique). Si je suis ton idée, ce moteur qui tenterait ce type de rendu heuristique remplacera Bruxelles - Brussels par Bruxelles — Brussels et ce sera faux ! C'est la même ville, pas deux. Ton idée est du même ordre que l'idée de corriger automatiquement l'orthographe au rendu, et donc de remplacer lors du rendu tous les saint par des Saint, toutes les rue par des Rue, tous les St par des Saint (ou des Street). Aucun moteur de rendu ne doit faire ce genre d'approximation. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Suppression des tirets cadratins
Le 30 novembre 2012 12:17, Sylvain Maillard sylvain.maill...@gmail.com a écrit : Salut, Et je tiens à souligner encore une fois que dans les fichiers fournis par la RATP elle-même, ils ne s'embarrassent pas de tels caractères spéciaux ! pour ma part ça n'est pas une excuse : je ne pense pas qu'on puisse s'appuyer sur un seul mauvais exemple pour en tirer des généralités. C'est comme de dire que si certains écrivent en langage sms, alors on a pas de raison de mettre des mots entiers ... Oui, c'est sûrement pas un exemple... surtout quand une partie des libellés ne sont qu'en majuscule, on retourne aux limbes de l'ASCII 7bits... +1 avec Christian sur l'homogénéité. On ne peut pas empêcher les gens de mettre le tiret qu'ils souhaitent. Mais il faut se mettre d'accord sur une règle commune, celle qui serait, par exemple, documentée dans le wiki. Ou, autre exemple, signalée comme erronée dans osmose si elle n'était pas respectée. Je précise au sujet de l'homogénéité, c'est d'homogénéité des données dont je parle. Pour le rendu, on peut retraiter si l'on veut remplacer ces espace-tiret-espace par le cadratin de son choix bien plus facilement que l'inverse vu la liste impressionnante des différents tirets donnée par Jean-Marc (qui les connaisait tous ?). Sur le fait que ces caractères pourraient servir à décrire le lien entre les différentes parties composant le libellé, je pense que c'est une erreur. Si il y a un lien logique entre des noms, il devrait provenir de données structurées et pas de l'analyse d'un texte. C'est d'ailleurs pour ça que je trouve sans intérêt les name mis sur les limites administratives car tout ceci se trouve dans la structure des données (le seul intérêt est le confort dans l'éditeur... éditeur qu'il suffirait d'améliorer sur ce point, parce que là on est le tagguer pour le confort dans l'éditeur). totalement d'accord sur l'homogénéité, notamment sur le tag name, encore que si on travaille bien en unicode il n'y a normalement pas de problèmes. Par contre je rejoins la proposition qui a été faite de ne pas se restreindre aux caractères ascii dans le tag name:fr ! Est-ce que quelqu'un sais quel est le consensus officiel pour les autres pays avec des particularités de caractères/typologie, notamment les alphabets différents ? Il n'y a rien de précisé dans le wiki. http://wiki.openstreetmap.org/wiki/Names -- Christian Quest - OpenStreetMap France - http://openstreetmap.fr/u/cquest ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Suppression des tirets cadratins
Le 30/11/2012 11:11, Christian Quest a écrit : Cela permet d'avoir dans OSM des données homogènes. C'est pour cela qu'un choix a été fait sur les noms de rue, même si celui-ci ne respect pas les canons de telle ou telle académie, ils ont l'avantage d'être homogènes. Mouais... le choix sur les noms de rue est typographique, ce qui n'est pas le cas ici. Enfin bon, je ne vais pas m'impliquer dans cette discussion, ça me passe largement au-dessus, j'ai juste répondu en tant que silencieux et fervent utilisateur des É, È etc.. ce dont ne s’embarrassent pas de nombreux services administratifs qui écorchent donc mon nom de famille. Stéphane PÉNEAU Je pense qu'une même règle devrait être suivie sur les séparateurs, en indiquant clairement la règle du tiret seul (trait d'union) et du tiret avec espace (séparateur). Une minorité de contributeur maitrise les subtilités des tirets, cadratins et traits d'union pendant qu'une majorité de maitrise pas ces subtilités et contribuera avec de simples tirets du 6. Plus on a de mélange plus on doit adapter les algorithmes traitant les noms pour gérer ces subtilités, alors qu'à l'inverse, la mise en forme typographique peut se faire simplement en partant de tiret simples ou avec espaces. Voilà pourquoi je pense que l'on devrait en rester aux tirets avec ou sans espace et uniformiser dans ce sens pour favoriser l'homogénéité des données au détriment des subtilités typographiques plus ou moins franco-françaises (OSM est un projet international). ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Suppression des tirets cadratins
On 30/11/2012 12:32, Christian Quest wrote: Je précise au sujet de l'homogénéité, c'est d'homogénéité des données dont je parle. Pour le rendu, on peut retraiter si l'on veut remplacer ces espace-tiret-espace par le cadratin de son choix bien plus facilement que l'inverse vu la liste impressionnante des différents tirets donnée par Jean-Marc (qui les connaisait tous ?). Je n'en connaissais pas la moitié... Mais ne prenons pas mon ignorance comme référence - tirons plutôt le niveau vers le haut ! Sur le fait que ces caractères pourraient servir à décrire le lien entre les différentes parties composant le libellé, je pense que c'est une erreur. Si il y a un lien logique entre des noms, il devrait provenir de données structurées et pas de l'analyse d'un texte. C'est d'ailleurs pour ça que je trouve sans intérêt les name mis sur les limites administratives car tout ceci se trouve dans la structure des données (le seul intérêt est le confort dans l'éditeur... éditeur qu'il suffirait d'améliorer sur ce point, parce que là on est le tagguer pour le confort dans l'éditeur) Je suis d'accord sur ce point. Je vois régulièrement des référentiels où des attributs contiennent des valeurs concaténées... Ca se termine toujours dans les larmes : s'il y a plusieurs valeurs alors il doit y avoir plusieurs attributs et non pas un attribut composite dont la structure ne sera pas universellement respectée et donc les valeur ne répercuteront pas les modifications des attributs qu'elles ont copié lors de la création. Mais ça n'est néanmoins pas un argument contre l'usage sémantique des ponctuations - juste un argument contre l'extension anarchique des modèles par l'usage des ponctuations comme séparateurs internes aux attributs. Je persiste à penser que name pourrait être le plus petit dénominateur commun technique et que name:fr pourrait être le champ libre à l'expression de nos particularismes linguistiques... Mais c'est probablement aussi parce que ce n'est pas moi qui écrit les analyseurs syntaxiques... ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Suppression des tirets cadratins
On a des aberrations similaires dans OSM concernant les articles définis quand c'est la première lettre : normalement il n'y a aucune majuscule, juste une capitale conditionnelle qui n'apparait qu'en début de phrase, ces articles définis restant remplaçables/contractables grammaticalement comme pour le Mans et non Le Mans) car on écrit «Aller de Paris au Mans » (disparition du mot Le qui ne fait pas partie du nom propre, c'est un article défini commun). L'IGN fait attention à ça, regardez ses cartes, notamment pour les nombreux lieux-dits, et même l'INSEE dans sa base des noms de communes où les articles communs sont spécifiés à part et même codifiés), mais OSM s'en fout et confond tout. Si vous supposez qu'on peut librement rétablir les minuscules ou faire des contractions contextuellement chaque fois qu'on veut insérer dans une phrase un toponyme mal écrit dans OSM et commençant par « Le », « La », « Les », « L’ », « Els », « Los », etc. vous vous trompez car ce sont aussi des noms propres utilisés comme toponymes ou odonymes invariables (le Le est une rivière) ! Regardez le fichier de définition de l'INSEE pour la liste des articles codés à part pour les noms de collectivités locales et divisions administratives. On a même Osmose qui prétend (complètement à tord) que c'est « mieux » de faire cette confusion des majuscules et des capitales, et indique une prétendue « erreur » : - la majuscule est lexicale et invariable typographiquement, - la capitale est typographique mais imposée seulement par convention typographique et orthographique et uniquement de façon conditionnelle en début de phrase, la lettre restant lexicalement une minuscule même si elle est transcrite par une capitale). Oui mais là encore Osmose se base sur un prétendu critère d'homogénéité (taguer pour le rendu) parce beaucoup ne connaissent pas la différence entre une majuscule et une capitale et se trompent sans arrêt. On perd tout l'intérêt d'une base de données, et on se retrouve à insérer dans des documents des aberrations orthographiques comme « Ce train part **de Le** Mans et va à Paris » (incorrect) au lieu de « Ce train part **du** Mans et va à Paris » (correct), puisqu'on ne sait pas ce qui fait partie du nom propre ou pas. Si Osmose devait dire quelque chose, ce serait signaler que le premier mot « Le » dans le nom français (ou dans un name par défaut situé dans un pays ou une région officiellement francophone) est très probablement un article défini qui s'écrit en minuscule (ce serait vrai la plupart du temps, mais avec quelques exceptions dont il doit aussi tenir compte même s'il les signale une fois) et non raconter n'importe quoi en affirmant l'inverse. (Beaucoup aussi ne connaissent pas la différence entre une majuscule et une minuscule, et les mélange sans sourciller; beaucoup ne connaissent pas non plus la règle orthographique des toponymes français avec des traits d'union et non des espaces, sauf quelques exceptions de toponymes bien connus comme les Pays de la Loire ou le Territoire de Belfort, qui en fait ne sont pas réellement des toponymes au sens géographique, mais des noms administratifs officiels de collectivités locales, compétentes sur un territoire donné). Pourtant la mission d'OSM est aussi éducative et doit promouvoir les usages corrects les plus précis, et non pas entretenir les imprécisions et approximations (même si elles sont courantes). Le 30 novembre 2012 12:42, Stéphane Péneau stephane.pen...@wanadoo.fr a écrit : Le 30/11/2012 11:11, Christian Quest a écrit : Cela permet d'avoir dans OSM des données homogènes. C'est pour cela qu'un choix a été fait sur les noms de rue, même si celui-ci ne respect pas les canons de telle ou telle académie, ils ont l'avantage d'être homogènes. Mouais... le choix sur les noms de rue est typographique, ce qui n'est pas le cas ici. Enfin bon, je ne vais pas m'impliquer dans cette discussion, ça me passe largement au-dessus, j'ai juste répondu en tant que silencieux et fervent utilisateur des É, È etc.. ce dont ne s’embarrassent pas de nombreux services administratifs qui écorchent donc mon nom de famille. Stéphane PÉNEAU Je pense qu'une même règle devrait être suivie sur les séparateurs, en indiquant clairement la règle du tiret seul (trait d'union) et du tiret avec espace (séparateur). Une minorité de contributeur maitrise les subtilités des tirets, cadratins et traits d'union pendant qu'une majorité de maitrise pas ces subtilités et contribuera avec de simples tirets du 6. Plus on a de mélange plus on doit adapter les algorithmes traitant les noms pour gérer ces subtilités, alors qu'à l'inverse, la mise en forme typographique peut se faire simplement en partant de tiret simples ou avec espaces. Voilà pourquoi je pense que l'on devrait en rester aux tirets avec ou sans espace et uniformiser dans ce sens pour favoriser l'homogénéité des données au détriment des subtilités typographiques plus ou moins franco-françaises (OSM
Re: [OSM-talk-fr] Suppression des tirets cadratins
Le 30 novembre 2012 12:48, Jean-Marc Liotier j...@liotier.org a écrit : Je persiste à penser que name pourrait être le plus petit dénominateur commun technique et que name:fr pourrait être le champ libre à l'expression de nos particularismes linguistiques... Mais c'est probablement aussi parce que ce n'est pas moi qui écrit les analyseurs syntaxiques... Est-ce que ça vaut vraiment le coup/coût de renseigner deux noms, un name=* technique qui n'a PAS cette vocation, et un name:fr juste parce que le name:fr aurait un tiret cadratin (d'autres langues aussi en font usage largement, ce n'est pas un particularisme linguistique franco-français). Je ne vois pas de plut petit dénominateur commun technique justifié même pour ce caractère qui ne pose aucun problème technique, ce qui ne justifie donc pas de définir les deux name=* et name:fr;* différemment alors qu'ils sont de toute façon tous les deux en français et n'ont aucune raison linguistique d'être différents. Si name=* existe c'est pour offrir aux autres langues aussi un nom qu'ils peuvent utiliser, à défaut pour ces langues de définir leur propre nom différent. Cela permet donc à des centaines de langues d'utiliser le nom français tel qu'il est sans avoir à surcharger OSM de centaines de copies identiques du nom français en valeur des centaines de name:code-langue=* possibles. Maintenant name=* n'indique pas de quelle(s) langue(s) vient ce nom, à moins qu'on le copie à **l'identique** dans name:fr (et dans les name:langue=* qui effectivement ont un usage avéré de ce nom dans la même orthographe). Ce qui voudra alors dire qu'on devra renseigner TOUTES les langues possibles dans OSM pour TOUS les noms, et alors se passer totalement de name=*; si une langue manque, on aura une erreur et plus rien à afficher du tout (ou pire on affichera le nom défini dans une seule langue arbitraire : l'anglais (britannique), ce qui voudra dire que name:en=* ne sert plus à rien et que name=* veut dire le nom en anglais). Le choix d'OSM a été de permettre justement de ne pas utiliser l'anglais partout dans le monde comme seule langue apparaissant par défaut sur les cartes, pour que justement name=* puisse être un nom exprimé dans une **ou plusieurs** des langues officielles parlées dan un lieu donné. Moi je veux bien alors qu'on supprime les tirets simples utilisés dans ce cas (name=Bruxelles - Brussels) mais alors il FAUT aussi éliminer name=* et le remplacer par name:local_langs=* prenant en valeur une liste de code langues (qui devraient donc être tous définis)... Alors au lieu de renseigner seulement un seul name=Xxxx avec un nom en français , on devra renseigner systématiquement name:local_langs=fr et name:fr=X. Pour Bruxelles (c'est un exxemple), cela donnera name:local_langs=fr;nl (mais aucune autre langue!), name:fr=Bruxelles, name.nl=Brussels, auxquels on pourra encore avoir d'autres name:code=* pour les autres traductions hors du français et du néerlandais. Alors si on affiche une carte en français, on n'affichera QUE le nom français, si on affiche une carte en néerlandais, on n'affichera QUE le nom néerlandais, et pour les cartes dans toutes les autres langues on affichera les deux noms français et néerlandais (sans choisir), SAUF si une langue a fait un choix explicite ou mentionné une orthographe ou translitération qui lui est propre (name:en=Brussels affiche bien le nom anglais qui est le même que le nom néerlandais, name:ru= affichera un nom translitéré en cyrcillique propre aux conventions russes de translitération, ou bien un autre nom russe consacré mais dans les deux cas russes ce ne seront pas des noms officiels, les seuls noms officiels étant ceux renseignés dans les langues indiquées par name:local_lanfs=fr;nl, donc les noms en français ou néerlandais) SI ET SEULEMENT SI une proposition similaire devenait la norme partout dans OSM, (je pense qu'un tel changement massif n'aura jamais lieu dans OSM, d'autant plus que cela oblige à modifier TOUS les outils pour changer leur logique de sélection des langues à saisir ou à afficher) ALORS SEULEMENT, il n'y a plus d'ambiguïté avec l'autre signification de - comme séparateur de noms (entre deux entités différentes de même nature liées ou séparés par l'objet tagué), ce que voulait justement marquer le tiret cadratin. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Suppression des tirets cadratins
Pourquoi veux-tu que OSM se limite aux cartes ? OSM c'est une base de données, pas une carte. Les cartes c'est du domaine du rendu. OSM a bien d'autres usages comme la possibilité d'utiliser la base comme source d'informations pour composer toutes sortes de documents avec des inclusions dans le texte d'une partie de ces données, avec des liens hypertextes possibles vers des rendus cartographiques très divers, ou pas de carte du tout, par exemple dans des tableaux de données, où le nom ne sera pas non plus nécessairement le premier élément affiché dans une cellule). Bref le CNIG ne touche qu'au rendu des cartes, rien d'autre. Le 30 novembre 2012 14:05, Plop76 vaujani...@free.fr a écrit : Philippe Verdy a écrit : On a des aberrations similaires dans OSM concernant les articles définis quand c'est la première lettre : normalement il n'y a aucune majuscule, juste une capitale conditionnelle qui n'apparait qu'en début de phrase, ces articles définis restant remplaçables/contractables grammaticalement comme pour le Mans et non Le Mans) car on écrit «Aller de Paris au Mans » (disparition du mot Le qui ne fait pas partie du nom propre, c'est un article défini commun). Sur les cartes, il s'agit pourtant bien de débuts de phrases (nominales), comme l'indique la charte du CNIG : «en application de l’observation générale introductive, la question de la majuscule du premier élément d’un toponyme ne se pose pas pour une inscription toponymique sur une carte ou sur un panneau indicateur, où elle est occultée par la majuscule de début de phrase (phrases nominales dans ces cas).» Et même hors le cas des début de phrase, le CNIG recommande la majuscule à l'article initial. __**_ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.**org/listinfo/talk-frhttp://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Suppression des tirets cadratins
Ce qui veut dire que le CNIG ne dit PAS que ces articles prennent la majuscule (c'est faux), mais la capitale initiale, Tu confond toi aussi majuscule (sémantique et lexicale) et capitale (typographique et contextuelle). ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Suppression des tirets cadratins
En français, et même d'une façon générale dans TOUTES les langues à écriture bicamérale comme l'alphabet latin, les minuscules et majuscules sont TOUTES invariables. En revanche il y a plusieurs casses typographiques: minuscules, capitales, petites capitales, grandes minuscules, et grandes capitales (et quelques autres dans d'autres écritures multicamérales voir même monocamérales, un cas particulier étant les styles d'écriture géorgiens mkedruouli, mtassotavoulo, tassotavrouli, mélangeant en fait plusieurs alphabets *distincts* monocaméraux...). - la minuscule (lexicale et invariable) peut alors devenir typographiquement : une minuscule (typographique), une petite capitale ; ou encore une capitale ou une grande capitale (autorisés seulement en début de phrase en français, ou pour certains mots des titres en anglais) ; mais jamais une grande minuscule - la majuscule (lexicale et invariable) peut alors devenir typographiquement : uniquement une majuscule, ou une grande minuscule (ce style est désuet, il est encore utilisé dans d'autres écritures que l'écriture latine), ou une grande capitale (utilisé uniquement dans le style petite capitales pour les minuscules lexicales) A cela s'ajoutent encore divers autres styles typographiques qui complètent les styles de casse précédents : ancien style pour les nombres, chasse fixe ou variable, italiques, exposants et indices. Le 30 novembre 2012 14:14, Philippe Verdy verd...@wanadoo.fr a écrit : Ce qui veut dire que le CNIG ne dit PAS que ces articles prennent la majuscule (c'est faux), mais la capitale initiale, Tu confond toi aussi majuscule (sémantique et lexicale) et capitale (typographique et contextuelle). ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Suppression des tirets cadratins
Je me suis planté en tapant les noms des alphabets géorgiens mais peu importe ici. Le 30 novembre 2012 14:29, Philippe Verdy verd...@wanadoo.fr a écrit : En français, et même d'une façon générale dans TOUTES les langues à écriture bicamérale comme l'alphabet latin, les minuscules et majuscules sont TOUTES invariables. En revanche il y a plusieurs casses typographiques: minuscules, capitales, petites capitales, grandes minuscules, et grandes capitales (et quelques autres dans d'autres écritures multicamérales voir même monocamérales, un cas particulier étant les styles d'écriture géorgiens mkedruouli, mtassotavoulo, tassotavrouli, mélangeant en fait plusieurs alphabets *distincts* monocaméraux...). - la minuscule (lexicale et invariable) peut alors devenir typographiquement : une minuscule (typographique), une petite capitale ; ou encore une capitale ou une grande capitale (autorisés seulement en début de phrase en français, ou pour certains mots des titres en anglais) ; mais jamais une grande minuscule - la majuscule (lexicale et invariable) peut alors devenir typographiquement : uniquement une majuscule, ou une grande minuscule (ce style est désuet, il est encore utilisé dans d'autres écritures que l'écriture latine), ou une grande capitale (utilisé uniquement dans le style petite capitales pour les minuscules lexicales) A cela s'ajoutent encore divers autres styles typographiques qui complètent les styles de casse précédents : ancien style pour les nombres, chasse fixe ou variable, italiques, exposants et indices. Le 30 novembre 2012 14:14, Philippe Verdy verd...@wanadoo.fr a écrit : Ce qui veut dire que le CNIG ne dit PAS que ces articles prennent la majuscule (c'est faux), mais la capitale initiale, Tu confond toi aussi majuscule (sémantique et lexicale) et capitale (typographique et contextuelle). ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Suppression des tirets cadratins
Dans son message précédent, Philippe Verdy a écrit : Pourquoi veux-tu que OSM se limite aux cartes ? OSM c'est une base de données, pas une carte. Les cartes c'est du domaine du rendu. OSM a bien d'autres usages comme la possibilité d'utiliser la base comme source d'informations pour composer toutes sortes de documents avec des inclusions dans le texte d'une partie de ces données, avec des liens hypertextes possibles vers des rendus cartographiques très divers, ou pas de carte du tout, par exemple dans des tableaux de données, où le nom ne sera pas non plus nécessairement le premier élément affiché dans une cellule). Bref le CNIG ne touche qu'au rendu des cartes, rien d'autre. Ils s'occupent de l'information géographique :D Ils font justement la distinction entre les cartes (où la majuscule est de toute façon due au début de phrase) et le cas général. Pour le cas général, ils recommandent : «Dans un toponyme (quel que soit son mode de composition), ou dans un nom de territoire politique ou administratif composé par jonction par des traits d’union, prennent la majuscule : [...] - l’article initial s’il n’est pas contracté avec à ou de le précédant (La Rochelle, Le Puy, Le Havre, la municipalité du Touquet et non de Le Touquet, aller au Mans et non à Le Mans [DAF, « le »] au lieudit « La Fourche », « Le Cheval mort » [DAF, « lieudit »]). » Et concernant l'IGN : «Ainsi, dans les toponymes officieux, l’IGN et le SHOM omettent actuellement les traits d’union et l’IGN la majuscule à l’article initial. Cette exception s’apparente à l’usage de signes typographiques comme la couleur des caractères, la police italique ou le corps des caractères» ;-) ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Suppression des tirets cadratins
Très bien, il mentionne « l’article initial s’il n’est pas contracté avec à ou de » et suppose qu'on puisse reconnaitre qu'il s'agit d'un article (cela oblige à en garder la trace dans une base de données. Et le CNIG se place dans le cadre de la « composition », ce qui de fait exclue le cas « base de données » qui doit préserver cette différence d'une façon ou d'une autre. La base de données a bien vocation à garder les différences lexicales, ce n'est pas le contexte de la composition dont parle le CNIG. Le 30 novembre 2012 14:31, Plop76 vaujani...@free.fr a écrit : Dans son message précédent, Philippe Verdy a écrit : Pourquoi veux-tu que OSM se limite aux cartes ? OSM c'est une base de données, pas une carte. Les cartes c'est du domaine du rendu. OSM a bien d'autres usages comme la possibilité d'utiliser la base comme source d'informations pour composer toutes sortes de documents avec des inclusions dans le texte d'une partie de ces données, avec des liens hypertextes possibles vers des rendus cartographiques très divers, ou pas de carte du tout, par exemple dans des tableaux de données, où le nom ne sera pas non plus nécessairement le premier élément affiché dans une cellule). Bref le CNIG ne touche qu'au rendu des cartes, rien d'autre. Ils s'occupent de l'information géographique :D Ils font justement la distinction entre les cartes (où la majuscule est de toute façon due au début de phrase) et le cas général. Pour le cas général, ils recommandent : «Dans un toponyme (quel que soit son mode de composition), ou dans un nom de territoire politique ou administratif composé par jonction par des traits d’union, prennent la majuscule : [...] - l’article initial s’il n’est pas contracté avec à ou de le précédant (La Rochelle, Le Puy, Le Havre, la municipalité du Touquet et non de Le Touquet, aller au Mans et non à Le Mans [DAF, « le »] au lieudit « La Fourche », « Le Cheval mort » [DAF, « lieudit »]). » Et concernant l'IGN : «Ainsi, dans les toponymes officieux, l’IGN et le SHOM omettent actuellement les traits d’union et l’IGN la majuscule à l’article initial. Cette exception s’apparente à l’usage de signes typographiques comme la couleur des caractères, la police italique ou le corps des caractères» ;-) __**_ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.**org/listinfo/talk-frhttp://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Suppression des tirets cadratins
Il y a malgré tout moyen de faire un compromis si vous voulez garder la capitale dans la base partout: d'abord le problème ne français ne concerne que les mots « Le » ou « Les » écrits en tête. Dans la plupart des cas ce sont bien articles, ils sont donc contractables. Dans les autres cas rares, ce sont des exceptions qui peuvent être marqués spécialement pour dire que ce ne sont pas des articles mais des noms propres, donc que d'une part ce n'est pas une capitale typographique, mais bien une majuscule invariable (name:fr:invariable_case=yes). Cela pourrait concerner d'autres noms propres que les toponymes. Pour ne pas faire d'autres exceptions, on a choisi de garder les articles devant les noms de cours d'eau. Cependant ces articles ne font pas partie de l'odonyme lui-même : la minuscule s'impose. On reconnait alors ces articles à condition qu'on sache que c'est bien du français. D'autre part il faut savoir dans quelle langue est effectivement écrit le nom par défaut (name=*) : on n'est pas obligé de le dire dans tous les name=* si l'objet désigné est dans un pays ou une région dont on connait la langue officielle (ce name devrait être dans cette langue). Cela se complique dans les pays ou régions qui ont plusieurs langues co-officielles (par exemple les communautés autonomes espagnoles, ou la région de Bruxelles-Capitale, ou même la Région wallone où l'allemand est aussi coofficiel dans une partie, la distinction linguistique ne se faisant pas au niveau des régions administratives en Belgique, mais au niveau des communautés linguistiques). Pour indiquer la/les langues officielles dans une région (administrative ou autre entité politique dans OSM), on peut indiquer cette langue, ou ces langues dans un tag. Si un lieu fait partie de plusieurs régions adminsitratives ou autres entités poltiiques, toutes les langues indiquées sont coofficielles (ou ont un statut régional réconnu). A la suite de quoi on se retrouve avec un name=* qui peut n'être alors que dans l'une de ces langues ou plusieurs de celles-ci. Si les règles orthographiques, grammaticales, ou autres ne permettent pas de décider comment appliquer une règle, on n'a pas d'autre choix que de détailler les noms de ces langues avec leurs propres règles, et on ne dérivera pas le name=* par défaut qui reste dans une langue ambiguë.. Le 30 novembre 2012 14:37, Philippe Verdy verd...@wanadoo.fr a écrit : Très bien, il mentionne « l’article initial s’il n’est pas contracté avec à ou de » et suppose qu'on puisse reconnaitre qu'il s'agit d'un article (cela oblige à en garder la trace dans une base de données. Et le CNIG se place dans le cadre de la « composition », ce qui de fait exclue le cas « base de données » qui doit préserver cette différence d'une façon ou d'une autre. La base de données a bien vocation à garder les différences lexicales, ce n'est pas le contexte de la composition dont parle le CNIG. Le 30 novembre 2012 14:31, Plop76 vaujani...@free.fr a écrit : Dans son message précédent, Philippe Verdy a écrit : Pourquoi veux-tu que OSM se limite aux cartes ? OSM c'est une base de données, pas une carte. Les cartes c'est du domaine du rendu. OSM a bien d'autres usages comme la possibilité d'utiliser la base comme source d'informations pour composer toutes sortes de documents avec des inclusions dans le texte d'une partie de ces données, avec des liens hypertextes possibles vers des rendus cartographiques très divers, ou pas de carte du tout, par exemple dans des tableaux de données, où le nom ne sera pas non plus nécessairement le premier élément affiché dans une cellule). Bref le CNIG ne touche qu'au rendu des cartes, rien d'autre. Ils s'occupent de l'information géographique :D Ils font justement la distinction entre les cartes (où la majuscule est de toute façon due au début de phrase) et le cas général. Pour le cas général, ils recommandent : «Dans un toponyme (quel que soit son mode de composition), ou dans un nom de territoire politique ou administratif composé par jonction par des traits d’union, prennent la majuscule : [...] - l’article initial s’il n’est pas contracté avec à ou de le précédant (La Rochelle, Le Puy, Le Havre, la municipalité du Touquet et non de Le Touquet, aller au Mans et non à Le Mans [DAF, « le »] au lieudit « La Fourche », « Le Cheval mort » [DAF, « lieudit »]). » Et concernant l'IGN : «Ainsi, dans les toponymes officieux, l’IGN et le SHOM omettent actuellement les traits d’union et l’IGN la majuscule à l’article initial. Cette exception s’apparente à l’usage de signes typographiques comme la couleur des caractères, la police italique ou le corps des caractères» ;-) __**_ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.**org/listinfo/talk-frhttp://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list
Re: [OSM-talk-fr] Suppression des tirets cadratins
Pour continuer le sujet de la variabilité des noms selon le contexte, le français (ou les langues romanes et germaniques) restent (en apparence seulement) encore des cas simples. Mais si vous regardez les autres langues cela se complique sérieusement : - les langues slaves déclinent tous les nom propres - les langues celtiques (breton ou irlandais par exemple) et sémitiques (arabe par exemple) pratiquent *aussi* la mutation des initiales selon les mots qui les précèdent et des règles complexes de phonologie. - les langues sémitiques (arabe ou hébreu) ne notent pas toujours les voyelles (points diacritiques) n'importe où dans les mots, ou peuvent n'en écrire qu'une partie ou bien toutes (ce n'est pas le cas de toutes les langues en écriture arabe, qui ont introduit des lettres à part entière pour les voyelles en systématisant ces voyelles et en ajoutant quelques lettres au besoin) - ces mêmes langues peuvent noter aussi la cantillation (optionnelle, comme si on pouvait noter en français contextuellement avec un accent particulier les voyelles longues, ou les syllabes emphasées d'un stress, ou d'une intonation particulière, marquant l'intention de l'auteur selon le contexte, au lieu d'utiliser des termes supplémentaires). - les langues asiatiques ne marquent pas systématiquement le genre, le nombre, la déclinaison, le temps ou la fonction, que ce soit par des adverbes, articles, déclinaisons, mais par agglutination de morphèmes, qui se contractent souvent par mutation aussi dans la racine ! Un exemple européen est la langue finnoise. - les mutations ne concernent pas toujours uniquement l'initiale mais aussi phonologiquement (selon des règles parfois complexes) des éléments au milieu de la racine (un exemple existe en français dans les mutations internes des racines des verbes du fait de la conjugaison : des accents ou lettres apparaissent ou disparaissent selon le temps, le mode, ou la personne, mais aussi dans les termes dérivés des noms propres comme les gentilés qui sont bourrés souvent de mutations, quand ils ne vont pas chercher leur racine dans un autre terme ou dans une autre langue!). On peut croire qu'on peut laisser de côte les gentilés (dont la séparation est claire dans les langues romanes ou germaniques) mais c'est souvent difficile dans les autres langues où ils sont formés par les types de dérivation précédents (par exemple par agglutination et mutations). De fait, il est important dans OSM de pouvoir savoir dans quelle langue les name=* sont écrits, et aussi avoir une idée de ce qui constitue dedans des termes ou morphèmes génériques (communs) ou propres (car les règles de dérivation sont alors très différentes et propres à chaque langue identifiée). Le 30 novembre 2012 15:26, Philippe Verdy verd...@wanadoo.fr a écrit : Il y a malgré tout moyen de faire un compromis si vous voulez garder la capitale dans la base partout: d'abord le problème ne français ne concerne que les mots « Le » ou « Les » écrits en tête. Dans la plupart des cas ce sont bien articles, ils sont donc contractables. Dans les autres cas rares, ce sont des exceptions qui peuvent être marqués spécialement pour dire que ce ne sont pas des articles mais des noms propres, donc que d'une part ce n'est pas une capitale typographique, mais bien une majuscule invariable (name:fr:invariable_case=yes). Cela pourrait concerner d'autres noms propres que les toponymes. Pour ne pas faire d'autres exceptions, on a choisi de garder les articles devant les noms de cours d'eau. Cependant ces articles ne font pas partie de l'odonyme lui-même : la minuscule s'impose. On reconnait alors ces articles à condition qu'on sache que c'est bien du français. D'autre part il faut savoir dans quelle langue est effectivement écrit le nom par défaut (name=*) : on n'est pas obligé de le dire dans tous les name=* si l'objet désigné est dans un pays ou une région dont on connait la langue officielle (ce name devrait être dans cette langue). Cela se complique dans les pays ou régions qui ont plusieurs langues co-officielles (par exemple les communautés autonomes espagnoles, ou la région de Bruxelles-Capitale, ou même la Région wallone où l'allemand est aussi coofficiel dans une partie, la distinction linguistique ne se faisant pas au niveau des régions administratives en Belgique, mais au niveau des communautés linguistiques). Pour indiquer la/les langues officielles dans une région (administrative ou autre entité politique dans OSM), on peut indiquer cette langue, ou ces langues dans un tag. Si un lieu fait partie de plusieurs régions adminsitratives ou autres entités poltiiques, toutes les langues indiquées sont coofficielles (ou ont un statut régional réconnu). A la suite de quoi on se retrouve avec un name=* qui peut n'être alors que dans l'une de ces langues ou plusieurs de celles-ci. Si les règles orthographiques, grammaticales, ou autres ne permettent pas de décider comment appliquer une règle, on n'a pas d'autre
Re: [OSM-talk-fr] Suppression des tirets cadratins
Rester simple pour le plus grand nombre ne veut pas dire qu'ils *doivent* saisir les bons caractères sémantiques (le tiret cadratin est sémantique, et PAS typographique, il sépare deux entités complètement différentes et non liées, il résoud des ambiguités dans le cas où un des noms séparés de la même entité est figuré dans plusieurs langues et doit être mentionné à côté du nom d'une toute autre entité). Il sert aussi à éviter toutes sortes d'expressions basées sur des adverbes (comme de ... à , vers, entre, etc. qu'on ne peut pas distiguer des noms pour savoir s'ils s'attachent ensemble en un seul ou pas). Son rôle est pourtant différent du point-virgule qui signale des valeurs multiples dans une liste. Le tiret cadratin ne gêne absolument personne : il n'empêche pas du tout les utilisateurs qui ne savent pas l'entrer de saisir d'autres noms ailleurs avec un tiret simple. Prétendre que ce n'est que de la typographie est faux. Et puisque tu prends Wikipédia pour exemple, justement c'est pareil ! Les ponctuations correctes sont corrigées par d'autres et conservées. Et même leur utilisation ne bloque absolument pas les moteurs de recherche (par exemple Nominatim) ou n'importe quel moteur de recherche qui analyserait un rapport HTML sur le contenu de la base. Ces caractères sont présents depuis longtemps et il y a une très longue tradition dans toutes les entreprises d'édition de documents (dans les livres comme dans la presse) non pas parce qu'ils seraient plus jolis mais parce qu'ils sont plus exacts et plus précis sur ce qu'ils signifient (ils ne sont en particulier jamais utilisés dans aucun toponyme officiel, contrairement aux tirets simples, et pas mal d'autres signes de ponctuation, ce qui les qualifie aussi comme excellent séparateur entre deux entités différentes). Sa compréhension est immédiate et non ambiguë, il n'y a pas lieu de remettre un trait d'union simple mais ambigu. Et c'est facile à uniformiser. En plus ce tiret cadratin (—) est bel et bien sur de nombreux claviers comme l'est aussi le tiret demi-cadratin (–) qui sert à autre chose, surtout comme tiret d'introduction dans une liste énumérée de valeurs présentée dans des paragraphes séparés, ou comme séparateur indiquant une plage de valeur (signification plus précise que les points de suspension). Sa lecture est simple aussi, sur tous les supports. Leur rendu est impeccable aussi si c'est ça qui te gêne, car on ne voit jamais nulle part apparaître un rectangle ou un point d'interrogation ou quelque signe hiéroglyphique. La raison en est simple: ils sont présents dans windows-1252 (le remplaçant de l'ISO 8859-1 en HTML5) et dans pratiquement toutes les polices latines utilisables pour l'écriture complète du français (et pas seulement d'un sous-ensemble de l'anglais), et de non nombre de langues à écriture latine, cyrillique, grecque, ... et même encore arabe, hébreu, thaïe, laotienne (la seule exception c'est l'écriture sinographique où on peut le confondre avec le signe de répétition, mais ce signe traditionnel n'est pas réellement un long tiret mais un stroke qui est orienté, non symétrique, codé différemment dans le carré de composition synographique, et encore utilisé non encadré d'espaces car toujours en association dans un même mot ou une même phrase, ce qui là aussi évite la confusion si l'écriture sinographique est ultra simplifiée pour une représentation en petits caractères). De plus il fonctionne sans problème entre deux noms d'entités différentes qui sont dans des langues différentes. On n'a pas la même lisibilité et des confusions de sens avec le trait d'union (surtout quand de nombreux noms sont des noms composés, particulièrement les toponymes en français ! Il n'a pas d'équivalent clair (le trait d'union on l'a vu ou tiret servant à juxtaposer deux noms dans un seule et même nom officiel, la virgule qui sert aussi à ajouter une précision, le point-virgule qui sert de séparateur entre des valeurs multiples dans une même clé où chacune est applicable séparément à l'objet). Pourquoi ils te gênent, franchement on se le demande. Si le soucis c'est juste l'uniformité, c'est un non-roblème ici car les names=* ne sont pas sensés être analysés comme des codes, mais à donner du sens pour un lecteur humain et pas pour un robot (qui ne sait de toute façon pas quoi faire des name=* homonymes, les name=* n'étant PAS des identifiants, contrairement aux ref=* où l'uniformisation et la normalisation est bel et bien nécessaire). Si un robot veut les lire, il doit comprendre les langues humaines et accepter ses usages, mais pas imposer des trucs comme: supprimer toute ponctuation, tout écrite en capitales, supprimer les accents. Alors oui le robot doit s'adapter aux langues humaines, et pas l'inverse (et ils le font bien en plus concernant ce tiret cadratin car il existe des normes stables à leur sujet : tu ne connais pas UCA ?) Le 28 novembre 2012 20:15, Christian Quest cqu...@openstreetmap.fr a écrit : Pour les noms des stations
Re: [OSM-talk-fr] Suppression des tirets cadratins
La pseudo-règle typographique que tu propose n'est qu'une heuristique, elle s'avère fausse dans de trop nombreux cas. Ne parle pas de typographie quand tu ne sais pas ce que c'est et que tu généralise beaucoup trop vite ce qui te semble simple dans ton petit monde. Ton point de vue simple est celui technique d'un programmeur trop habitué à l'ASCII. Appliquer une telle règle par un robot est carrément stupide quand on sait le nombre d'usages distincts qui sont faits de ce tiret simple extrêmement ambigu hérité du très pauvre ASCII (qui déjà n'avait aucun accent) ou même encore bien avant du code télégraphique Baudot (qui n'avait même pas les minuscules et pas plus de guillemets puisqu'on répétait les apostrophes simples). Et puisque tu cites l'article Wikipédia en question, tu ferais bien de le lire (et même aussi la page consacrée sur Wikipédia sur les recommandations typographiques). Le 28 novembre 2012 20:15, Christian Quest cqu...@openstreetmap.fr a écrit : Il est toujours possible si l'on souhaite suivre les subtilités des règles de typographie de remplacer ces espace-tiret-espace par espace fine insécable-tiret demi cadratin-espace-espace fine insécable. On pourra aussi revoir la capitalisation des noms qui ne respecte sûrement par les règles de telle ou telle académie. * voir: http://fr.wikipedia.org/wiki/Tiret ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Suppression des tirets cadratins
On 28 nov. 2012, at 19:20, Pieren pier...@gmail.com wrote: Si on veut distinguer deux entités, on peut aussi bien mettre des espaces avant et après le tiret pour lever toute ambiguité (Maisons-Alfort - Stade est assez clair). Ce compromis me semble tout à fait acceptable car il résout à la fois le problème sémantique et l'utilisation de caractères typographique ésotériques pour 99.5% des contributeurs. Vlad. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Suppression des tirets cadratins
Pas pour Paris - Bruxelles - Brussels... Le tiret n'a pas le même sens, il n'y a pas 3 entités mais 2 : Est-ce 'Paris - Bruxelles et Brussels, ou bien Paris et Bruxelles - Brussels. Faut-il alors écrire Bruxelles / Brussels pour avoir Paris - Bruxelles / Brussels et est-ce moins ambigu ? Faut-il alors écrire (et alors traduire...) De Paris à Bruxelles - Brussels, à traduire ensuite dans toutes les langues ? Maintenant compare à Paris – Bruxelles - Brussels : il n'y a plus aucune ambiguïté on voit bien 2 entités, l'une ayant 2 noms officiels juxtaposés et utilisés ensemble par défaut dans toutes les langues (même si on peut traduire dans une langue particulière pour en éliminer un, mais ce n'est pas toujours vrai car on a aussi les cas où deux graphies sont co-officielles dans la même langue, par exemple en écriture latine et en écriture cyrillique, et même co-officielles dans la même écriture et la même langue sans qu'on ait à choisir laquelle pour n'en afficher qu'une seule). ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Suppression des tirets cadratins
Bof, est-ce qu'un néophyte de la typo aura plus tendance à écrire « Maisons-Alfort - Stade » que « Maisons-Alfort--Stade » ou « Maisons-Alfort-Stade » ? Il ne comprendra pas plus la différence entre « Maisons-Alfort - Stade » et « Maisons-Alfort-Stade » qu'entre « Maisons-Alfort - Stade » et « Maisons-Alfort--Stade ». Et je ne vois pas le problème à avoir une typo première version avec les caractères les plus accessibles à tous (-) et un maniaque derrière qui remettra une couche avec le beau tiret cadratin. On répète à qui veut l'entendre d'utiliser les bons tags et que c'est aux moteurs de rendus de s'adapter, je ne vois pas pourquoi on changerait cette règle quand on passe à la typographie. JB Le 29.11.2012 09:19, Vladimir Vyskocil a écrit : On 28 nov. 2012, at 19:20, Pieren pier...@gmail.com wrote: Si on veut distinguer deux entités, on peut aussi bien mettre des espaces avant et après le tiret pour lever toute ambiguité (Maisons-Alfort - Stade est assez clair). Ce compromis me semble tout à fait acceptable car il résout à la fois le problème sémantique et l'utilisation de caractères typographique ésotériques pour 99.5% des contributeurs. Vlad. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr [1] Links: -- [1] http://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Suppression des tirets cadratins
On 29 nov. 2012, at 09:56, JB jb...@mailoo.org wrote: Bof, est-ce qu'un néophyte de la typo aura plus tendance à écrire « Maisons-Alfort - Stade » que « Maisons-Alfort—Stade » ou « Maisons-Alfort-Stade » ? Il ne comprendra pas plus la différence entre « Maisons-Alfort - Stade » et « Maisons-Alfort-Stade » qu'entre « Maisons-Alfort - Stade » et « Maisons-Alfort—Stade ». Et je ne vois pas le problème à avoir une typo première version avec les caractères les plus accessibles à tous (-) et un maniaque derrière qui remettra une couche avec le beau tiret cadratin. On répète à qui veut l'entendre d'utiliser les bons tags et que c'est aux moteurs de rendus de s'adapter, je ne vois pas pourquoi on changerait cette règle quand on passe à la typographie. Justement parce que la typographie c'est du rendu. On peut supposer qu'un moteur de rendu intelligent pourrait avoir des règles pour afficher un — lorsqu'il rencontre un - . JB ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Suppression des tirets cadratins
On 29 nov. 2012, at 09:47, Philippe Verdy verd...@wanadoo.fr wrote: Pas pour Paris - Bruxelles - Brussels... Le tiret n'a pas le même sens, il n'y a pas 3 entités mais 2 : Est-ce 'Paris - Bruxelles et Brussels, ou bien Paris et Bruxelles - Brussels. Faut-il alors écrire Bruxelles / Brussels pour avoir Paris - Bruxelles / Brussels et est-ce moins ambigu ? Oui cela pourrait être une bonne façon d'entrer les données dans la base, le / serait alors un séparateur de liste et - représenterait l'union. Ensuite libre au moteur de rendu d'afficher ça de la bonne manière. Faut-il alors écrire (et alors traduire...) De Paris à Bruxelles - Brussels, à traduire ensuite dans toutes les langues ? Vladimir ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Suppression des tirets cadratins
Je n’ai pas l’habitude de rentrer dans des sujets chauds aussi tôt dans la conversation… Mais comme je me sens un peu visé par le sujet — en effet, j’utilise la typographie française aussi précisément que je peux — je me permets d’intervenir en faveur du cadratin. Et je ne vois pas le problème à avoir une typo première version avec les caractères les plus accessibles à tous (-) et un maniaque derrière qui remettra une couche avec le beau tiret cadratin. +1, sachant que ce caractère n’est pas que « beau », mais surtout sémantique (terme souvent repris dans la base OSM). De plus, lors d’un traitement automatique de la typographie — qui est inévitable pour un rendu homogène —, j’imagine tout à fait que l’algorithme gère les espaces multiples, ou les manques d’espaces ; et dans le cas « Maisons-Alfort - Stade » il me semble bien plus compliqué de savoir si les espaces sont trop nombreux ou qu’ils manquent ; alors qu’avec « Maisons-Alfort — Stade » l’ambiguïté est levée et le traitement des espaces est trivial. D’autre part, on a souvent entendu à propos de la base OSM qu’elle doit être, d’une part uniforme, mais aussi préserver les spécificités ; et là, il s’agit clairement d’une spécificité de la langue française (je ne saurais dire si ce caractère a cours dans d’autres langues). Comme l’a justement fait remarqué Philippe, les balises name=* sont les noms locaux/officiels (rayez la mention que vous voulez) des objets auxquels ils sont attachés ; et en tant qu’objets français, ils se doivent être écrits en français. Et même si ce ne sont pas des « codes », avec la typographie qui va bien, leur décodage selon les règles de la langue locale (ici le français) peut tout à fait être systématisé et automatique. Enfin, je rajouterai que je suis également adepte de l’utilisation des différentes espaces (fines, insécables, etc…), l’apostrophe française et des guillemets français. Ceci dit, je n’imposerai jamais à notre communauté française de cartographieurs OSM ces subtilités ; mais de l’autre côté, je ne souhaite pas me voir imposer la non utilisation de ces subtilités, qui, je le rappelle, lèvent bon nombre d’ambiguïtés ! Cordialement, -- Mikaël Cordon, mickey86 Le 29 novembre 2012 09:56, JB jb...@mailoo.org a écrit : ** Bof, est-ce qu'un néophyte de la typo aura plus tendance à écrire « Maisons-Alfort - Stade » que « Maisons-Alfort—Stade » ou « Maisons-Alfort-Stade » ? Il ne comprendra pas plus la différence entre « Maisons-Alfort - Stade » et « Maisons-Alfort-Stade » qu'entre « Maisons-Alfort - Stade » et « Maisons-Alfort—Stade ». Et je ne vois pas le problème à avoir une typo première version avec les caractères les plus accessibles à tous (-) et un maniaque derrière qui remettra une couche avec le beau tiret cadratin. On répète à qui veut l'entendre d'utiliser les bons tags et que c'est aux moteurs de rendus de s'adapter, je ne vois pas pourquoi on changerait cette règle quand on passe à la typographie. JB Le 29.11.2012 09:19, Vladimir Vyskocil a écrit : On 28 nov. 2012, at 19:20, Pieren pier...@gmail.com wrote: Si on veut distinguer deux entités, on peut aussi bien mettre des espaces avant et après le tiret pour lever toute ambiguité (Maisons-Alfort - Stade est assez clair). Ce compromis me semble tout à fait acceptable car il résout à la fois le problème sémantique et l'utilisation de caractères typographique ésotériques pour 99.5% des contributeurs. Vlad. ___ Talk-fr mailing listTalk-fr@openstreetmap.orghttp://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Suppression des tirets cadratins
Oui cela pourrait être une bonne façon d'entrer les données dans la base, le / serait alors un séparateur de liste et - représenterait l'union. Ensuite libre au moteur de rendu d'afficher ça de la bonne manière. Attention, le caractère « / » a sa propre signification. Et pour les cartographieurs qui reproduisent scrupuleusement les panneaux, « / » a pour signification dans des version abrégées de « sur ». Exemple : « Argenton / Creuse » ou « Argenton s/ Creuse », signifiant « Argenton sur Creuse » ; qui deviendrait alors « Argenton — Creuse » ayant une toute autre signification. Cordialement, -- Mikaël Cordon, mickey86 Le 29 novembre 2012 11:09, Mikaël Cordon mikael.cor...@gmail.com a écrit : Je n’ai pas l’habitude de rentrer dans des sujets chauds aussi tôt dans la conversation… Mais comme je me sens un peu visé par le sujet — en effet, j’utilise la typographie française aussi précisément que je peux — je me permets d’intervenir en faveur du cadratin. Et je ne vois pas le problème à avoir une typo première version avec les caractères les plus accessibles à tous (-) et un maniaque derrière qui remettra une couche avec le beau tiret cadratin. +1, sachant que ce caractère n’est pas que « beau », mais surtout sémantique (terme souvent repris dans la base OSM). De plus, lors d’un traitement automatique de la typographie — qui est inévitable pour un rendu homogène —, j’imagine tout à fait que l’algorithme gère les espaces multiples, ou les manques d’espaces ; et dans le cas « Maisons-Alfort - Stade » il me semble bien plus compliqué de savoir si les espaces sont trop nombreux ou qu’ils manquent ; alors qu’avec « Maisons-Alfort — Stade » l’ambiguïté est levée et le traitement des espaces est trivial. D’autre part, on a souvent entendu à propos de la base OSM qu’elle doit être, d’une part uniforme, mais aussi préserver les spécificités ; et là, il s’agit clairement d’une spécificité de la langue française (je ne saurais dire si ce caractère a cours dans d’autres langues). Comme l’a justement fait remarqué Philippe, les balises name=* sont les noms locaux/officiels (rayez la mention que vous voulez) des objets auxquels ils sont attachés ; et en tant qu’objets français, ils se doivent être écrits en français. Et même si ce ne sont pas des « codes », avec la typographie qui va bien, leur décodage selon les règles de la langue locale (ici le français) peut tout à fait être systématisé et automatique. Enfin, je rajouterai que je suis également adepte de l’utilisation des différentes espaces (fines, insécables, etc…), l’apostrophe française et des guillemets français. Ceci dit, je n’imposerai jamais à notre communauté française de cartographieurs OSM ces subtilités ; mais de l’autre côté, je ne souhaite pas me voir imposer la non utilisation de ces subtilités, qui, je le rappelle, lèvent bon nombre d’ambiguïtés ! Cordialement, -- Mikaël Cordon, mickey86 Le 29 novembre 2012 09:56, JB jb...@mailoo.org a écrit : ** Bof, est-ce qu'un néophyte de la typo aura plus tendance à écrire « Maisons-Alfort - Stade » que « Maisons-Alfort—Stade » ou « Maisons-Alfort-Stade » ? Il ne comprendra pas plus la différence entre « Maisons-Alfort - Stade » et « Maisons-Alfort-Stade » qu'entre « Maisons-Alfort - Stade » et « Maisons-Alfort—Stade ». Et je ne vois pas le problème à avoir une typo première version avec les caractères les plus accessibles à tous (-) et un maniaque derrière qui remettra une couche avec le beau tiret cadratin. On répète à qui veut l'entendre d'utiliser les bons tags et que c'est aux moteurs de rendus de s'adapter, je ne vois pas pourquoi on changerait cette règle quand on passe à la typographie. JB Le 29.11.2012 09:19, Vladimir Vyskocil a écrit : On 28 nov. 2012, at 19:20, Pieren pier...@gmail.com wrote: Si on veut distinguer deux entités, on peut aussi bien mettre des espaces avant et après le tiret pour lever toute ambiguité (Maisons-Alfort - Stade est assez clair). Ce compromis me semble tout à fait acceptable car il résout à la fois le problème sémantique et l'utilisation de caractères typographique ésotériques pour 99.5% des contributeurs. Vlad. ___ Talk-fr mailing listTalk-fr@openstreetmap.orghttp://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Suppression des tirets cadratins
On Thu, 29 Nov 2012 11:09:38 +0100 Mikaël Cordon mikael.cor...@gmail.com wrote: Je n’ai pas l’habitude de rentrer dans des sujets chauds aussi tôt dans la conversation… Mais comme je me sens un peu visé par le sujet — en effet, j’utilise la typographie française aussi précisément que je peux — je me permets d’intervenir en faveur du cadratin. Et je ne vois pas le problème à avoir une typo première version avec les caractères les plus accessibles à tous (-) et un maniaque derrière qui remettra une couche avec le beau tiret cadratin. +1, sachant que ce caractère n’est pas que « beau », mais surtout sémantique (terme souvent repris dans la base OSM). +1 -- Frédéric Falsetti http://clansco.org ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Suppression des tirets cadratins
On 29 nov. 2012, at 11:15, Mikaël Cordon mikael.cor...@gmail.com wrote: Oui cela pourrait être une bonne façon d'entrer les données dans la base, le / serait alors un séparateur de liste et - représenterait l'union. Ensuite libre au moteur de rendu d'afficher ça de la bonne manière. Attention, le caractère « / » a sa propre signification. Et pour les cartographieurs qui reproduisent scrupuleusement les panneaux, « / » a pour signification dans des version abrégées de « sur ». Exemple : « Argenton / Creuse » ou « Argenton s/ Creuse », signifiant « Argenton sur Creuse » ; qui deviendrait alors « Argenton — Creuse » ayant une toute autre signification. Ok, une autre convention pourrait être trouvée mais l'exemple cité n'est pas bon car il ne faudrait pas entrer de versions abrégées des noms dans la base car la aussi c'est au moteur de rendu ou de recherche dans les données de faire les abréviations à la volée si besoin (autre débat, assez chaud chez les américains par exemple...) Cordialement, -- Mikaël Cordon, mickey86 cordialement, Vladimir. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Suppression des tirets cadratins
@Vladimir : je suis d’accord que mon exemple n’était pas le plus réfléchi, il est limite puisqu’effectivement les abréviations ne sont pas souhaitées. Ceci dit, il y a beaucoup de choses non souhaitées dans la base OSM :). Surtout ce que je voulais soulever, c’est que les caractères ont une signification bien établie ; et qu’il est dommage et risqué quant à en changer le sens localement. Pourquoi ne pas utiliser directement le bon caractère ? J’ai pour habitude, en cas de doute, d’appauvrir l’information plutôt que mettre une information ambiguë, ou pire, fausse. Cordialement, -- Mikaël Cordon, mickey86 Le 29 novembre 2012 11:24, Vladimir Vyskocil vladimir.vysko...@gmail.coma écrit : On 29 nov. 2012, at 11:15, Mikaël Cordon mikael.cor...@gmail.com wrote: Oui cela pourrait être une bonne façon d'entrer les données dans la base, le / serait alors un séparateur de liste et - représenterait l'union. Ensuite libre au moteur de rendu d'afficher ça de la bonne manière. Attention, le caractère « / » a sa propre signification. Et pour les cartographieurs qui reproduisent scrupuleusement les panneaux, « / » a pour signification dans des version abrégées de « sur ». Exemple : « Argenton / Creuse » ou « Argenton s/ Creuse », signifiant « Argenton sur Creuse » ; qui deviendrait alors « Argenton — Creuse » ayant une toute autre signification. Ok, une autre convention pourrait être trouvée mais l'exemple cité n'est pas bon car il ne faudrait pas entrer de versions abrégées des noms dans la base car la aussi c'est au moteur de rendu ou de recherche dans les données de faire les abréviations à la volée si besoin (autre débat, assez chaud chez les américains par exemple...) Cordialement, -- Mikaël Cordon, mickey86 cordialement, Vladimir. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Suppression des tirets cadratins
On 29/11/2012 11:09, Mikaël Cordon wrote: Je n’ai pas l’habitude de rentrer dans des sujets chauds aussi tôt dans la conversation… Pourquoi se priver d'alimenter une si jolie polémique ? [..] D’autre part, on a souvent entendu à propos de la base OSM qu’elle doit être, d’une part uniforme, mais aussi préserver les spécificités ; et là, il s’agit clairement d’une spécificité de la langue française (je ne saurais dire si ce caractère a cours dans d’autres langues). Comme l’a justement fait remarqué Philippe, les balises name=* sont les noms locaux/officiels (rayez la mention que vous voulez) des objets auxquels ils sont attachés ; et en tant qu’objets français, ils se doivent être écrits en français. Et même si ce ne sont pas des « codes », avec la typographie qui va bien, leur décodage selon les règles de la langue locale (ici le français) peut tout à fait être systématisé et automatique. Enfin, je rajouterai que je suis également adepte de l’utilisation des différentes espaces (fines, insécables, etc…), l’apostrophe française et des guillemets français. Ceci dit, je n’imposerai jamais à notre communauté française de cartographieurs OSM ces subtilités ; mais de l’autre côté, je ne souhaite pas me voir imposer la non utilisation de ces subtilités, qui, je le rappelle, lèvent bon nombre d’ambiguïtés ! La question n'a-t-elle pas des réponses différentes pour name et name:fr ? Pour name:fr il me semble naturel de normaliser selon la typographie Française, même si les outils, et notamment les outils de saisie, freinent encore la sophistication typographique en imposant des efforts supplémentaires, et que l'enrichissement sémantique n'est pas encore pleinement exploité par la plupart des outils. Pour name le problème est différent : nous devons concilier la raison locale avec la compatibilité mondiale par le plus petit dénominateur commun. C'est à mon avis là que se situe le débat. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Suppression des tirets cadratins
2012/11/29 Jean-Marc Liotier j...@liotier.org: Pour name le problème est différent : nous devons concilier la raison locale avec la compatibilité mondiale par le plus petit dénominateur commun. C'est à mon avis là que se situe le débat. +1 N'adopter les pratiques locales dans le global que lorsqu'on n'a pas d'alternative. Par exemple le œ ou des tags spécifiques comme amenity=lavoir ;-) Pieren ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Suppression des tirets cadratins
On 29/11/2012 11:40, Mikaël Cordon wrote: Surtout ce que je voulais soulever, c’est que les caractères ont une signification bien établie ; et qu’il est dommage et risqué quant à en changer le sens localement. Pourquoi ne pas utiliser directement le bon caractère ? Il y a presque vingt ans, j'écrivais le Français sans accents - sur les systèmes de l'époque ça passait mieux avec toutes les antiquités qui s'attendaient à lire de l'ASCII 7 bits et qui se perdaient dans la jungle des pages de code de l'ASCII étendu. Je laissais donc la technologie et la culture Américaine diriger mes usages, pour ne pas choquer des interlocuteurs et des outils déroutés par l'exotisme profond d'un accent aigu. L'ère de l'ignorance de la diversité linguistique a durablement formaté une génération à choisir l’appauvrissement au nom de la compatibilité, canalisée en cela par les outils qui ont formé nos habitudes. Il est plus que temps de ré-apprendre et de se ré-approprier la richesse typographique de notre propre langue - fut-ce au prix de frictions avec nos habitudes et nos outils. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Suppression des tirets cadratins
On 29/11/2012 11:59, Jean-Marc Liotier wrote: L'ère de l'ignorance de la diversité linguistique a durablement formaté une génération à choisir l’appauvrissement au nom de la compatibilité, canalisée en cela par les outils qui ont formé nos habitudes. Il est plus que temps de ré-apprendre et de se ré-approprier la richesse typographique de notre propre langue - fut-ce au prix de frictions avec nos habitudes et nos outils. Et comme je le mentionne ailleurs dans ce fil, c'est une volonté légitime pour name:fr mais sujette à débat pour name où la légitimité dominante est plutôt la compatibilité mondial. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Suppression des tirets cadratins
Je suis entièrement d’accord du point de la séparation donnée/rendu. Le but du jeu c’est de pouvoir comprendre la donnée de façon univoque ! On sait que tant que ce seront des humains qui saisiront des données dans la base, il y aura des erreurs. Et les erreurs sont d’autant plus nombreuses qu’elles ne sont pas clairement visibles (je parle ici des espaces) ; ou que les règles sont méconnues. Beaucoup d’algorithmes automatiques sont justement là pour corriger ou pallier à ces erreurs. Ils font des merveilles pour rajouter ou supprimer des espaces ou de la ponctuation devant tel ou tel caractère, changer la casse (Rue saint-Antoine), même reconnaître des erreurs évidentes telles que « aveneu » à la place de « avenue ». Seulement voilà, ces algorithmes ont leurs limites devant une ambiguïté telle que « Maisons-Alfort - Stade » ; je trouve que tenter de lever une ambiguïté à l’aide de l’espace qui est un caractère particulièrement enclin à générer des erreurs n’est pas du tout judicieux. Les lettres, les articles de journaux, et autres éditions françaises ne sont pas traités automatiquement comme le sont les données d’OSM ; dans les journaux, c’est l’humain au final qui lève les ambiguïtés grâce à sa mémoire colossale et sa capacité de reconnaissance à la volée ; les algorithmes automatiques d’aujourd’hui ne sont pas capable d’un tel prodige à moins d’efforts démesurés pour les concevoir (parole de développeur). La base OSM est tellement grosse, que malgré la puissance du cerveau humain personne ne peut corriger la base. Et quand bien même il le pourrait, vu que c’est un humain, il fera des erreurs. Donc, c’est bien un algorithme qui traitera toutes ces données si on veut supprimer les erreurs. Je pense qu’on ne peut pas demander aux contributeurs bienveillant d’appauvrir leurs données sous prétexte que la majorité ne peuvent pas atteindre cette précision ; d’autant que cette précision est bénéfique et utilisable. Et là, je ne parle pas que de typographie ! Je pense qu’utiliser les bons caractères au bon endroit est un bonus ! Cordialement, -- Mikaël Cordon, mickey86 Le 29 novembre 2012 11:53, Pieren pier...@gmail.com a écrit : 2012/11/29 Mikaël Cordon mikael.cor...@gmail.com: Enfin, je rajouterai que je suis également adepte de l’utilisation des différentes espaces (fines, insécables, etc…), l’apostrophe française et des guillemets français. Ceci explique cela ;-) Je remarque qu'il y a parmi le public des contributeurs français une très petite minorité d'adeptes de la belle typographie française, qui en connaissent les règles et les moyens de saisie. D'ailleurs, ils viennent souvent de wikipedia. Mais le tag name n'est pas un article wikipedia, le tag name ne sert pas à imprimer les panneaux de signalisation, le tag name n'a pas à respecter les règles typographiques des imprimeurs. Parce que dans OSM, on sépare donnée factuelle et rendu. OSM, c'est de la donnée brute pour le monde entier. Et il n'y a qu'en France que je vois autant de tirets longs pour faire de la sémantique. Alors que oui, ce caractère existe dans tous les pays, même en chinois (—— 破折号) mais il risque de ne pas avoir le même emploi ! On a déjà discuté règles typographiques ici et on a constaté que 1. elles étaient en contradiction avec les règles de toponymie (Rue Saint-Antoine devrait s'écrire Rue saint-Antoine) 2. qu'il n'y avait pas de standard universel même en France puisque l'académie a ses règles, les grands journaux ont les leurs, les éditeurs/imprimeurs aussi, etc- Pieren ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Suppression des tirets cadratins
Ce qui se complique encore quand les toponymes ***officiels*** espagnols utilisent le / pour séparer les noms ***co-officiels*** issus de plusieurs langues, ces deux langues ***devant*** toujours être citées ensembles et dans l'ordre indiqué sans qu'on puisse en supprimer un ! C'est alors le même toponyme dans les langues d'origine, les différences linguistiques étant alors abolies dans la dénomination officielle pour la même entité (regardez le Pays Basque espagnol par exemple). Dans ce cas le / ne signifie pas non plus sur, ***même*** en Français. Comment alors faire un traitement automatique de substitution pour faire joli ? Oui effectivement le / a sa propre sémantique dans ce cas, mais on ne doit PAS l'utiliser comme s'il s'agissait d'une abréviation, même en français. Bref en aucun cas Argenton / Creuse ne signifie la même chose que Argenton-sur-Creuse (ne pas oublier non plus les traits d'union ici !) Car en Espagne et même en français, ce / est un séparateur, distingué de l'autre séparateur trait d'union qui est aussi utilisé pour juxtaposer deux termes mais avec une autre signification. L'idée qu'un moteur de rendu peut librement remplacer la ponctuation est totalement erronée, chacune a sa signification propre mais on ne peut pas la déduire de la seule façon dont cette ponctuation est codée puisque pour cela il faudrait coder ***aussi*** la sémantique. Bref apprenons à utiliser la bonne ponctuation dès le départ, ou corrigeons pour la rendre la plus précise possible si une version ambiguë a été utilisée (ce qu'on n'interdit pas, pas plus qu'on interdit de cartographier la géométrie avec une résolution faible pour ensuite l'améliorer plus tard. Mais enlever des précisions ç la géométrie est bien une destruction d'information pertinente. Dans le même principe remplacer tous les tirets distingués par un seul sera aussi destructeur de distinctions (et tant pis si le lecteur lambda ne saisit pas bien la différence, celle-ci existe, de même tant pis si un utilisateur lambda n'a pas besoin d'une géométrie détaillée, il y en a aussi qui voudront ces détails pertinents). De même si un utilisateur ne voit pas l'intérêt d'un tag qu'il ne comprend pas, il ne doit pas l'enlever sans avoir compris ce qu'il servait à distinguer. On peut admettre aussi temporairement des abréviations, pour qu'ensuite quelqu'un les remplace par la forme non abrégée, mais en aucun cas on ne vas revenir en remplaçant à nouveau le nom correct par des abréviations. Dans tous ces cas, on n'interdit pas de commencer par des versions simples qui sont ensuite précisés par d'autres. Mais faire une règle pour dire qu'on interdit de préciser les choses, c'est du même ordre que l'idée de dire que la base OSM est suffisante et qu'il n'y a plus rien à y ajouter ou préciser. L'envie d'uniformiser les choses ne justifie rien ici, car il n'y a même aucun besoin technique de cette uniformisation dans des champs exprimés dans une langue humaine, non destinés à être lus par des machines. Mais si les machines veulent le faire (en simplifant les choses pour leur propre usage), les solutions existent, et cela s'appelle UCA (Unicode Collation Algorithm). C'est tout à fait ce qu'utilisent n'importe quel moteur de recherche en plein texte (aucun n'est bloqué par la ponctuation). La situation est très différente pour ce qui est des identificateurs ou codes, destinés à servir de point d'entrée fixes dans un index pour un accès rapide et non ambigu (les ref:* par exemple, mais aussi les URL) sans que la machine ait à gérer des ambiguïtés : il faut un identifiant UNIQUE, stable et le plus universel possible, qualifié si nécessaire (ce qu'on suffixe à la clé ref: par exemple), et pour cela aussi on adopte des conventions les plus strictes possibles (comme un jeu de caractères réduit, une uniformisation de la casse, la suppression des caractères redondants...) La contrainte pour les *identifiants* (les attributs name=* ne sont pas des identifiants, mais les ref:INSEE=* ou les codes postaux en sont, de même que nombre de valeurs codifiées dans OSM utilisant des _ au lieu des espaces, plus ou moins abrégés et uniquement en anglais quand leur usage n'est pas spécifique à un seul pays dans une norme nationale exprimée dans une seule langue) est complètement différente de celle pour les textes destinés aux humains et exprimés dans les langues humaines. Car si on peut (parfois, pas toujours) automatiquement les abréger pour en réduire la précision (à condition de connaitre la langue dans laquelle ces libellés sont écrits, ce qui n'est pas le cas de name=* mais peut l'être pour name:fr=*), le contraire est totalement impossible sans se tromper, toutes les heuristiques pour le faire ne sont QUE des heuristiques et vont se tromper. Les moteurs de rendus évitent de telles approximations, et ne vont tout bonnement pas préciser les choses, mais s'arrangeront pour afficher au mieux les précisions et auront le droit alors de supprimer des éléments et d'abréger,
Re: [OSM-talk-fr] Suppression des tirets cadratins
Le problème est le même : le name=* est, tout comme le name:fr=* un nom destiné à être lu par des humains, il a une langue (parfois plusieurs dans le même nom quand elles sont co-officielles). On ne peut pas deviner cette langue ici et ce peut tout autant être le français. Ce qu'on ne peut pas savoir tant que name:fr=* n'est pas précisé et ne contient pas la *même* valeur. Mais on a choisi dans ce cas de ne pas préciser name:fr=*. De fait, name=* s'applique à toutes les autres langues pour lesquelles on n'a pas un champ name:codelangue=* mais il va plus loin car c'est le nom officiel si c'est un toponyme, ou la juxtaposition de plusieurs noms officiels, qu'on ne peut pas changer. Cependant si le nom officiel n'est pas le plus courant, on accepte de garder name=* pour le nom courant et on précise à part official_name=* pour le nom formel (lui non plus non-abrégé !). Le 29 novembre 2012 11:47, Jean-Marc Liotier j...@liotier.org a écrit : Pour name le problème est différent : nous devons concilier la raison locale avec la compatibilité mondiale par le plus petit dénominateur commun. C'est à mon avis là que se situe le débat. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Suppression des tirets cadratins
+1000. D'autant plus qu'aujourd'hui il n'y a plus aucun problème technique lié aussi bien à leur rendu qu'à leur exploitation par des outils automatiques qui *peuvent* simplifier à la volée quand ils le souhaitent mais *pas* rétablir une précision perdue ou oubliée (là il n'y a qu'un humain qui le fera, même s'il n'est pas obligé de le faire tout de suite, soit parce qu'il ne sait pas comment faire, soit parce qu'on ne lui a pas démontré l'intérêt de le faire, soit parce qu'il méconnait la bonne façon de le faire). Ces quelques caractères sont très bien supportés partout et n'empêchent aucune recherche dans la base (sauf pour les techniciens qui feraient mieux d'apprendre comment faire, ne serait-ce déjà que pour ne pas dégrader des caractères d'autres langues qu'il ne comprend pas : UCA a été développé pour eux, mais même sans aller jusqu'à implémenter UCA, ce qui est assez complexe malgré les bibliothèques existantes déjà écrites comme ICU4C et ICU4J, et qui sont utilisables dans pratiquement tous les langages de programmation sachant gérer l'Unicode, cette dernière exigence étant déjà indispensable pour toutes les données OSM et n'importe quel protocole Internet). Je ne connais aucun système qui ne sachent pas simplement les afficher en sortie, même s'ils ne proposent pas toujours de moyens faciles pour les entrer (mais en tout cas il n'y a aucun problème avec nos outils actuels comme Potlatch et JOSM utilisés par la plupart des utilisateurs les plus lambda). La situation est plus délicate pour certaines écritures (par exemple pour les toponymes écrits en Tifinaghe au Maroc : il faut installer une police spécifique et utiliser un navigateur capable de rendre ces polices, ou configurer l'environnement Java pour JOSM). Et pourtant il y a bien des toponymes marocains en Tifinaghe dans la base OSM. L'argument je n'ai pas ce caractère sur mon clavier ne tient pas non plus: tous les OS actuels ont ce qu'il faut pour charger un clavier adapté qui aura ces caractères, même maintenant aussi les smartphones et tablettes (il n'y a guère que les télécommandes des téléviseurs, dont l'OS interne n'est pas configurable — mais qui cartographie sur un téléviseur avec une fonction Internet sans avoir aussi un PC, une tablette, un smartphone bien plus pratique pour faire de la saisie qu'une pauvre télécommande de téléviseur ?). Ces quelques caractères de ponctuation sont même *obligatoirement* supportés pour HTML5 (windows-1252 est le seul jeu réduit de caractères codés à supporter en plus de l'encodage UTF-8). Il n'y a aucune raison de se retrouver dans l'impossibilité de les saisir (sauf la seule paresse pour ne pas le faire, comme si c'était plus compliqué et plus long que d'apprendre à maîtriser la saisie cartographique avec les outils pour OSM). Même pour les navigateurs GPS vers lesquels on exporte des données, et dont les capacités d'affichage sont très limitées, il faut un outil de conversion, c'est à lui d'adapter les contenus de la base OSM aux capacités matérielles ou logicielles et les formats de données supportés par ces navigateurs. Le temps de l'ASCII c'est fini (sauf encore pour les langages techniques qui nécessitent des apprentissages importants, et il est alors impardonnable pour les programmeurs d'aujourd'hui de ne pas savoir ce qu'est l'Unicode ni comment ils peuvent configurer leur clavier). Et il faut réapprendre à tout le monde à accepter la richesse de nos langues. Sinon passons tous à l'anglais et ne parlons plus d'UTF-8 et des accents en français (attitude paresseuse et pas très glorieuse). Ce qui mettra aussi alors plein de gens dans le monde dans l'incapacité de contribuer ou de comprendre le projet et son intérêt. Le 29 novembre 2012 11:59, Jean-Marc Liotier j...@liotier.org a écrit : On 29/11/2012 11:40, Mikaël Cordon wrote: Surtout ce que je voulais soulever, c’est que les caractères ont une signification bien établie ; et qu’il est dommage et risqué quant à en changer le sens localement. Pourquoi ne pas utiliser directement le bon caractère ? Il y a presque vingt ans, j'écrivais le Français sans accents - sur les systèmes de l'époque ça passait mieux avec toutes les antiquités qui s'attendaient à lire de l'ASCII 7 bits et qui se perdaient dans la jungle des pages de code de l'ASCII étendu. Je laissais donc la technologie et la culture Américaine diriger mes usages, pour ne pas choquer des interlocuteurs et des outils déroutés par l'exotisme profond d'un accent aigu. L'ère de l'ignorance de la diversité linguistique a durablement formaté une génération à choisir l’appauvrissement au nom de la compatibilité, canalisée en cela par les outils qui ont formé nos habitudes. Il est plus que temps de ré-apprendre et de se ré-approprier la richesse typographique de notre propre langue - fut-ce au prix de frictions avec nos habitudes et nos outils. __**_ Talk-fr mailing list Talk-fr@openstreetmap.org
Re: [OSM-talk-fr] Suppression des tirets cadratins
Je serai bref. Il serait intéressant de partir plutôt un débat sur l'utilisation intensive de mots anglais, de développer les logiciels uniquement en anglais et leur donner des noms anglais. Soudain les français veulent passer inaperçus. C'est Paris qui rêve d'être New-York ou San-Francisco. Pierre De : Mikaël Cordon mikael.cor...@gmail.com À : Discussions sur OSM en français talk-fr@openstreetmap.org Envoyé le : Jeudi 29 novembre 2012 6h45 Objet : Re: [OSM-talk-fr] Suppression des tirets cadratins Je suis entièrement d’accord du point de la séparation donnée/rendu. Le but du jeu c’est de pouvoir comprendre la donnée de façon univoque ! On sait que tant que ce seront des humains qui saisiront des données dans la base, il y aura des erreurs. Et les erreurs sont d’autant plus nombreuses qu’elles ne sont pas clairement visibles (je parle ici des espaces) ; ou que les règles sont méconnues. Beaucoup d’algorithmes automatiques sont justement là pour corriger ou pallier à ces erreurs. Ils font des merveilles pour rajouter ou supprimer des espaces ou de la ponctuation devant tel ou tel caractère, changer la casse (Rue saint-Antoine), même reconnaître des erreurs évidentes telles que « aveneu » à la place de « avenue ». Seulement voilà, ces algorithmes ont leurs limites devant une ambiguïté telle que « Maisons-Alfort - Stade » ; je trouve que tenter de lever une ambiguïté à l’aide de l’espace qui est un caractère particulièrement enclin à générer des erreurs n’est pas du tout judicieux. Les lettres, les articles de journaux, et autres éditions françaises ne sont pas traités automatiquement comme le sont les données d’OSM ; dans les journaux, c’est l’humain au final qui lève les ambiguïtés grâce à sa mémoire colossale et sa capacité de reconnaissance à la volée ; les algorithmes automatiques d’aujourd’hui ne sont pas capable d’un tel prodige à moins d’efforts démesurés pour les concevoir (parole de développeur). La base OSM est tellement grosse, que malgré la puissance du cerveau humain personne ne peut corriger la base. Et quand bien même il le pourrait, vu que c’est un humain, il fera des erreurs. Donc, c’est bien un algorithme qui traitera toutes ces données si on veut supprimer les erreurs. Je pense qu’on ne peut pas demander aux contributeurs bienveillant d’appauvrir leurs données sous prétexte que la majorité ne peuvent pas atteindre cette précision ; d’autant que cette précision est bénéfique et utilisable. Et là, je ne parle pas que de typographie ! Je pense qu’utiliser les bons caractères au bon endroit est un bonus ! Cordialement, -- Mikaël Cordon, mickey86 Le 29 novembre 2012 11:53, Pieren pier...@gmail.com a écrit : 2012/11/29 Mikaël Cordon mikael.cor...@gmail.com: Enfin, je rajouterai que je suis également adepte de l’utilisation des différentes espaces (fines, insécables, etc…), l’apostrophe française et des guillemets français. Ceci explique cela ;-) Je remarque qu'il y a parmi le public des contributeurs français une très petite minorité d'adeptes de la belle typographie française, qui en connaissent les règles et les moyens de saisie. D'ailleurs, ils viennent souvent de wikipedia. Mais le tag name n'est pas un article wikipedia, le tag name ne sert pas à imprimer les panneaux de signalisation, le tag name n'a pas à respecter les règles typographiques des imprimeurs. Parce que dans OSM, on sépare donnée factuelle et rendu. OSM, c'est de la donnée brute pour le monde entier. Et il n'y a qu'en France que je vois autant de tirets longs pour faire de la sémantique. Alors que oui, ce caractère existe dans tous les pays, même en chinois (—— 破折号) mais il risque de ne pas avoir le même emploi ! On a déjà discuté règles typographiques ici et on a constaté que 1. elles étaient en contradiction avec les règles de toponymie (Rue Saint-Antoine devrait s'écrire Rue saint-Antoine) 2. qu'il n'y avait pas de standard universel même en France puisque l'académie a ses règles, les grands journaux ont les leurs, les éditeurs/imprimeurs aussi, etc- Pieren ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Suppression des tirets cadratins
Drôle de position quand même les américains ont compris l'intérêt de l'Unicode et le soutiennent maintenant massivement (au point même d'avoir réussi à l'imposer même à la Chine qui voulait GB18030 à la place mais ne l'a imposé en plus d'Unicode que chez elle). Les américains d'ailleurs ne parlent pas que l'anglais, l'espagnol aussi s'impose de plus en plus. Et comme nous ils tiennent aussi à la ponctuation correcte et la préservation de la sémantique. Ce n'est pas qu'une question de langue. Les seuls paresseux sont les programmeurs alors qu'ils ont tous les outils et doivent savoir s'en servir mieux même que les utilisateurs lambdas qui s'en servent tous les jours s'en même souvent s'en rendre compte. L'ASCII c'est fini pour représenter les langues humaines, même pour l'anglais, il ne subsiste encore que pour les usages techniques (identificateurs). Même plus pour les publications techniques en anglais, il y a un usage massif de tonnes d'autres caractères. Même pour les communications au grand public l'ASCII est fini (il suffit de voir la Wikipédie anglophone, ça ne manque pas, il n'y a plus une seule page qui n'affiche QUE des caractères ASCII, ne serait-ce que dans les liens Interwiki et dans presque toutes les boites de navigations et infoboxes ou encore dans la page d'accueil). Il y a des groupes entiers qui se consacrent à corriger les orthographes et ponctuations approximatives tapées en ASCII seulement. Qui a dit que cela réduisait l'accessibilité? C'est plutôt le contraire qui se produit, car les utilisateurs lambdas ne sont pas aussi bornés que bon nombre de programmeurs (ou des écoliers paresseux) qui n'ouvrent jamais un livre et méprisent leur propre langue et se réduisent à reproduire le langage SMS sur les chats ou les annonces Facebook et Twitter (quand ils savent seulement écrire ne serait-ce qu'un seul mot entier au lieu de poster ok, lol, +1, et quand ils ont oublié à quoi servait la touche majuscule). Le 29 novembre 2012 13:25, Pierre Béland infosbelas-...@yahoo.fr a écrit : Je serai bref. Il serait intéressant de partir plutôt un débat sur l'utilisation intensive de mots anglais, de développer les logiciels uniquement en anglais et leur donner des noms anglais. Soudain les français veulent passer inaperçus. C'est Paris qui rêve d'être New-York ou San-Francisco. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Suppression des tirets cadratins
On 29 nov. 2012, at 12:45, Philippe Verdy verd...@wanadoo.fr wrote: Ce qui se complique encore quand les toponymes ***officiels*** espagnols utilisent le / pour séparer les noms ***co-officiels*** issus de plusieurs langues, ces deux langues ***devant*** toujours être citées ensembles et dans l'ordre indiqué sans qu'on puisse en supprimer un ! C'est alors le même toponyme dans les langues d'origine, les différences linguistiques étant alors abolies dans la dénomination officielle pour la même entité (regardez le Pays Basque espagnol par exemple). Dans ce cas le / ne signifie pas non plus sur, ***même*** en Français. Comment alors faire un traitement automatique de substitution pour faire joli ? Oui effectivement le / a sa propre sémantique dans ce cas, mais on ne doit PAS l'utiliser comme s'il s'agissait d'une abréviation, même en français. Bref en aucun cas Argenton / Creuse ne signifie la même chose que Argenton-sur-Creuse (ne pas oublier non plus les traits d'union ici !) Car en Espagne et même en français, ce / est un séparateur, distingué de l'autre séparateur trait d'union qui est aussi utilisé pour juxtaposer deux termes mais avec une autre signification. L'idée qu'un moteur de rendu peut librement remplacer la ponctuation est totalement erronée, chacune a sa signification propre mais on ne peut pas la déduire de la seule façon dont cette ponctuation est codée puisque pour cela il faudrait coder ***aussi*** la sémantique. Dans ce cas c'est le schema qui n'est pas bon et on aurait du partir par exemple sur un tag name multi-valué alors que l'on est clairement parti sur une solution simpliste qui revient a tagguer pour le rendu : on veut que les 2 noms s'affichent côte à côte séparés par un caractère lambda sans rien a avoir a changer aux moteurs de rendu actuels... Il faut également prendre en compte tous les outils de recherche qui vont faire comment pour se dépatouiller avec des données formatés avec des demi-espaces insécables ou je ne sais quelle curiosité de la langue française ? Vladimir ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Suppression des tirets cadratins
Bonjour, Supprimer les tirets, et même le reste des caractères, des limites territoriales ne me dérange pas, pour la simple raison que les enchevêtrements de niveaux rendent trop compliqué la possibilité d'un nommage clair. (Comment nommer un bout de frontière de niveaux 2, 4, 6 et 8 à la fois par exemple ?) Donc autant pas mettre de champ name et si une application veut mettre des noms, elle peut travailler avec les relations de la manière qui lui convient. Pour ce qui est de retirer certains caractères parce que malheureusement tout le monde n'a pas les outils pour les rentrer, ou n'en voit pas l'intérêt, c'est autre chose. Comme pour n'importe quel autre domaine du projet, chacun contribue de par ses moyen, ses intérêts et ses envies. Et avec les contributions successives on arrive à quelque chose qui tend vers la complétude et l'exactitude. Toute contribution qui va dans le bon sens est la bienvenue, même si l'ortho, la typo ou autre n'est pas parfaite. Du moment que l'information est sémantiquement correcte, même si elle est difficile à reproduire pour beaucoup de monde, gardons-la. J'ai pas l'impression qu'il y ait un besoin de pouvoir retaper les informations du champ name une fois qu'elles ont été entrées. (Par exemple je serais bien en peine de reproduire les noms en arabe, mais je suis bien content qu'ils aient étés entrés.) Les moteurs de recherchent sont obligés de faire des recherches approchées, et on ne taggue pas plus pour eux que pour les renderers ! ;) Le but du champ name n'est pas de fournir un panneau de signalisation tout fait, c'est sûr. Mais pour ce qui est de fournir une chaîne de caractères qu'il n'y a pas à corriger (on peut vouloir passer tout en majuscule, mettre des abréviations ou que sais-je encore, mais pas par exemple à remplacer des E par des É ou des oe par des œ), qui elle peut être utilisée pour n'importe quoi, comme un panneau, je pense que si. TL;DR : Pour ce qui est des tirets cadratins en particulier, j'en sais rien, je ne m'étais jamais posé la question en fait. Mais c'est l'aspect « c'est dur et chiant de s'occuper de ces trucs-là, alors tendons vers le plus petit dénominateur commun et réfrénons-nous d'en utiliser » qui m'embête. 2012/11/29 Pierre Béland infosbelas-...@yahoo.fr Je serai bref. Il serait intéressant de partir plutôt un débat sur l'utilisation intensive de mots anglais, de développer les logiciels uniquement en anglais et leur donner des noms anglais. Soudain les français veulent passer inaperçus. C'est Paris qui rêve d'être New-York ou San-Francisco. Pierre -- *De :* Mikaël Cordon mikael.cor...@gmail.com *À :* Discussions sur OSM en français talk-fr@openstreetmap.org *Envoyé le :* Jeudi 29 novembre 2012 6h45 *Objet :* Re: [OSM-talk-fr] Suppression des tirets cadratins Je suis entièrement d’accord du point de la séparation donnée/rendu. Le but du jeu c’est de pouvoir comprendre la donnée de façon univoque ! On sait que tant que ce seront des humains qui saisiront des données dans la base, il y aura des erreurs. Et les erreurs sont d’autant plus nombreuses qu’elles ne sont pas clairement visibles (je parle ici des espaces) ; ou que les règles sont méconnues. Beaucoup d’algorithmes automatiques sont justement là pour corriger ou pallier à ces erreurs. Ils font des merveilles pour rajouter ou supprimer des espaces ou de la ponctuation devant tel ou tel caractère, changer la casse (Rue saint-Antoine), même reconnaître des erreurs évidentes telles que « aveneu » à la place de « avenue ». Seulement voilà, ces algorithmes ont leurs limites devant une ambiguïté telle que « Maisons-Alfort - Stade » ; je trouve que tenter de lever une ambiguïté à l’aide de l’espace qui est un caractère particulièrement enclin à générer des erreurs n’est pas du tout judicieux. Les lettres, les articles de journaux, et autres éditions françaises ne sont pas traités automatiquement comme le sont les données d’OSM ; dans les journaux, c’est l’humain au final qui lève les ambiguïtés grâce à sa mémoire colossale et sa capacité de reconnaissance à la volée ; les algorithmes automatiques d’aujourd’hui ne sont pas capable d’un tel prodige à moins d’efforts démesurés pour les concevoir (parole de développeur). La base OSM est tellement grosse, que malgré la puissance du cerveau humain personne ne peut corriger la base. Et quand bien même il le pourrait, vu que c’est un humain, il fera des erreurs. Donc, c’est bien un algorithme qui traitera toutes ces données si on veut supprimer les erreurs. Je pense qu’on ne peut pas demander aux contributeurs bienveillant d’appauvrir leurs données sous prétexte que la majorité ne peuvent pas atteindre cette précision ; d’autant que cette précision est bénéfique et utilisable. Et là, je ne parle pas que de typographie ! Je pense qu’utiliser les bons caractères au bon endroit est un bonus ! Cordialement, -- Mikaël Cordon, mickey86 Le 29 novembre 2012
Re: [OSM-talk-fr] Suppression des tirets cadratins
On 29 nov. 2012, at 15:30, JB jb...@mailoo.org wrote: Le 29.11.2012 15:13, Vladimir Vyskocil a écrit : Il faut également prendre en compte tous les outils de recherche qui vont faire comment pour se dépatouiller avec des données formatés avec des demi-espaces insécables ou je ne sais quelle curiosité de la langue française ? Euh, si un moteur sait trouver un « é » à partir d'un e, un « î » ou un « ï » à partir d'un i, pourquoi ne trouverait-il pas un espace insécable, une fine ou une autre curiosité à partir d'un espace ? Ou un tiret demi ou cadratin entier à partir d'un trait d'union ? D'ailleurs, prennent-ils seulement en compte ces caractères autres que les lettres dans leurs recherches ? Dans ce cas que l'on ne parle pas de sémantique attachée à ces caractères si l'on ne doit pas en tenir compte... Et il faut garder les pieds sur terre et ne pas trop espérer que d'ici peu les outils, les langages de programmation, les libs sachent gérer le fait qu'un caractère comme l'espace insécable ou le demi-espace doivent dans certains cas etre traités comme un simple espace, dans d'autre non, que les différents tirés matchent le -,... surtout quand ces outils sont développés internationalement et que toutes ces subtilités de la langue française ne vont parler en aucune façon à un développeur suédois (bien qu'il sera surement sensibilisé aux accents). Vladimir JB ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Suppression des tirets cadratins
Se dépatouiller avec des bizarreries… On se demande ce qui est bizarre ou ce qui est normal. Il faut savoir que certaines (un certain nombre) implémentations de la reconnaissance de motifs par expressions régulières dans le monde UTF-8 (en perl, php, extension SQL et sûrement d’autres langages) permettent de reconnaître des classes de caractères : les espaces, les séparateurs, caractères de groupement (parenthèses, crochets, etc…), ponctuations, chiffres, caractères de citation, les caractères accentués, les caractères en haut de casse, etc… indépendamment de la langue ; ce sont des propriétés des caractères. Et j’insiste sur le fait qu’il serait une erreur d’imposer l’utilisation de ces fameux caractères, puisque tout le monde ne les connaissent pas, et ne peuvent les saisir ! Mais dès lors qu’ils enrichissent les données et qu’ils peuvent être exploités, ils ne doivent pas être bannis. Cordialement, -- Le 29 novembre 2012 15:13, Vladimir Vyskocil vladimir.vysko...@gmail.coma écrit : On 29 nov. 2012, at 12:45, Philippe Verdy verd...@wanadoo.fr wrote: Ce qui se complique encore quand les toponymes ***officiels*** espagnols utilisent le / pour séparer les noms ***co-officiels*** issus de plusieurs langues, ces deux langues ***devant*** toujours être citées ensembles et dans l'ordre indiqué sans qu'on puisse en supprimer un ! C'est alors le même toponyme dans les langues d'origine, les différences linguistiques étant alors abolies dans la dénomination officielle pour la même entité (regardez le Pays Basque espagnol par exemple). Dans ce cas le / ne signifie pas non plus sur, ***même*** en Français. Comment alors faire un traitement automatique de substitution pour faire joli ? Oui effectivement le / a sa propre sémantique dans ce cas, mais on ne doit PAS l'utiliser comme s'il s'agissait d'une abréviation, même en français. Bref en aucun cas Argenton / Creuse ne signifie la même chose que Argenton-sur-Creuse (ne pas oublier non plus les traits d'union ici !) Car en Espagne et même en français, ce / est un séparateur, distingué de l'autre séparateur trait d'union qui est aussi utilisé pour juxtaposer deux termes mais avec une autre signification. L'idée qu'un moteur de rendu peut librement remplacer la ponctuation est totalement erronée, chacune a sa signification propre mais on ne peut pas la déduire de la seule façon dont cette ponctuation est codée puisque pour cela il faudrait coder ***aussi*** la sémantique. Dans ce cas c'est le schema qui n'est pas bon et on aurait du partir par exemple sur un tag name multi-valué alors que l'on est clairement parti sur une solution simpliste qui revient a tagguer pour le rendu : on veut que les 2 noms s'affichent côte à côte séparés par un caractère lambda sans rien a avoir a changer aux moteurs de rendu actuels... Il faut également prendre en compte tous les outils de recherche qui vont faire comment pour se dépatouiller avec des données formatés avec des demi-espaces insécables ou je ne sais quelle curiosité de la langue française ? Vladimir ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Suppression des tirets cadratins
2012/11/29 Mikaël Cordon mikael.cor...@gmail.com: Et j’insiste sur le fait qu’il serait une erreur d’imposer l’utilisation de ces fameux caractères, puisque tout le monde ne les connaissent pas, et ne peuvent les saisir ! Mais dès lors qu’ils enrichissent les données et qu’ils peuvent être exploités, ils ne doivent pas être bannis. Non, ils n'enrichissent pas la base. C'est différent mais ça n'apporte pas plus d'information qu'un - . Le problème d'interprétation existe dans les deux versions (si tant est que ce soit interprété un jour). D'ailleurs, je viens de regarder dans les fichiers opendata de la RATP et je n'ai pas trouvé de tiret long dans leurs listes de stations. Moi, je suis pour la cohérence. Soit on les met partout, soit nul part. Pieren ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Suppression des tirets cadratins
Non on ne veut pas 2 noms séparés, c'est un seul et même nom contenant deux éléments. Et les moteurs de recherche n'ont strictement aucun problème avec ces caractères qui ne sont pas des curiosités françaises mais présents par défaut dans de nombreux protocoles, supportés par des encodages essentiels (dont windows-1252 qui est le seul encodage par défaut d'HTML5, et UTF-8 qui est le seul encodage par défaut d'XML et XHTML), présents dans toutes les polices latines non restreintes à l'ASCII (et un très grand nombre de polices d'autres écritures). Ils ont d'autant moins de problème que les moteurs de recherche ont des standards pour ça, je le répète: UCA et une norme ISO équivalente. Ils ont été dans toutes les versions de CLDR, et même indiqués comme partie prenante des ponctuations essentielles non seulement au français mais aussi à l'anglais (même si les anciens claviers ne peuvent pas toujours les saisir, il a toujours existé d'autres moyens que la saisie directe au clavier, même pour ceux qui travaillent les fichiers XML pour OSM dans un éditeur de texte basique, avec des entités de caractères mdash; ou entités numériques Unicode). Il y a même moins de complication à les utiliser que les caractères accentués français pour les recherches ou le tri (là encore lire ce qu'en dit le standard de collation UCA, ou la norme ISO équivalente ou la norme française NF). Même avec une collation la plus basique (à un seul niveau, c'est plus simple que les lettres accentuées françaises), la complication est en faitdu même ordre quand on se reporte uniquement à la ponctuation ASCII. Le 29 novembre 2012 15:13, Vladimir Vyskocil vladimir.vysko...@gmail.coma écrit : On 29 nov. 2012, at 12:45, Philippe Verdy verd...@wanadoo.fr wrote: Ce qui se complique encore quand les toponymes ***officiels*** espagnols utilisent le / pour séparer les noms ***co-officiels*** issus de plusieurs langues, ces deux langues ***devant*** toujours être citées ensembles et dans l'ordre indiqué sans qu'on puisse en supprimer un ! C'est alors le même toponyme dans les langues d'origine, les différences linguistiques étant alors abolies dans la dénomination officielle pour la même entité (regardez le Pays Basque espagnol par exemple). Dans ce cas le / ne signifie pas non plus sur, ***même*** en Français. Comment alors faire un traitement automatique de substitution pour faire joli ? Oui effectivement le / a sa propre sémantique dans ce cas, mais on ne doit PAS l'utiliser comme s'il s'agissait d'une abréviation, même en français. Bref en aucun cas Argenton / Creuse ne signifie la même chose que Argenton-sur-Creuse (ne pas oublier non plus les traits d'union ici !) Car en Espagne et même en français, ce / est un séparateur, distingué de l'autre séparateur trait d'union qui est aussi utilisé pour juxtaposer deux termes mais avec une autre signification. L'idée qu'un moteur de rendu peut librement remplacer la ponctuation est totalement erronée, chacune a sa signification propre mais on ne peut pas la déduire de la seule façon dont cette ponctuation est codée puisque pour cela il faudrait coder ***aussi*** la sémantique. Dans ce cas c'est le schema qui n'est pas bon et on aurait du partir par exemple sur un tag name multi-valué alors que l'on est clairement parti sur une solution simpliste qui revient a tagguer pour le rendu : on veut que les 2 noms s'affichent côte à côte séparés par un caractère lambda sans rien a avoir a changer aux moteurs de rendu actuels... Il faut également prendre en compte tous les outils de recherche qui vont faire comment pour se dépatouiller avec des données formatés avec des demi-espaces insécables ou je ne sais quelle curiosité de la langue française ? Vladimir ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Suppression des tirets cadratins
Parce que ces fichiers RATP sont anciens et ont été développés en un temps où on ne prenait même pas garde de préserver les accents sur les majuscules. Et ce n'est pas non plus parce que certains ne savent pas taper un É ou un œ qu'on ne va s'interdire d'en mettre, et encore moins les remplacer par E et oe (mais les moteurs de recherche dont ça très bien tout seuls pour ceux qui cherchent Saint-Etienne sans accents ou Mons-en Baroeul sans ligature alors que la base OSM en contient avec Saint-Étienne et Mons-en-Barœul). ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Suppression des tirets cadratins
Envoyé de mon iPad Le 29 nov. 2012 à 16:57, Philippe Verdy verd...@wanadoo.fr a écrit : Non on ne veut pas 2 noms séparés, c'est un seul et même nom contenant deux éléments. Oui c'est ce que j'ai dit un nom multi-valué que le moteur de rendu pourra très bien afficher nom1 – nom2 par exemple. Et les moteurs de recherche n'ont strictement aucun problème avec ces caractères qui ne sont pas des curiosités françaises mais présents par défaut dans de nombreux protocoles, supportés par des encodages essentiels (dont windows-1252 qui est le seul encodage par défaut d'HTML5, et UTF-8 qui est le seul encodage par défaut d'XML et XHTML), présents dans toutes les polices latines non restreintes à l'ASCII (et un très grand nombre de polices d'autres écritures). C'est surtout ceux qui cherchent qui peuvent avoir des soucis s'ils doivent utiliser le bon tiret ou le bon espace. Ils ont d'autant moins de problème que les moteurs de recherche ont des standards pour ça, je le répète: UCA et une norme ISO équivalente. Ils ont été dans toutes les versions de CLDR, et même indiqués comme partie prenante des ponctuations essentielles non seulement au français mais aussi à l'anglais (même si les anciens claviers ne peuvent pas toujours les saisir, il a toujours existé d'autres moyens que la saisie directe au clavier, même pour ceux qui travaillent les fichiers XML pour OSM dans un éditeur de texte basique, avec des entités de caractères mdash; ou entités numériques Unicode). Oui sûrement, mais on parle de gens qui ne savent même pas que ceci existe. Il y a même moins de complication à les utiliser que les caractères accentués français pour les recherches ou le tri (là encore lire ce qu'en dit le standard de collation UCA, ou la norme ISO équivalente ou la norme française NF). Même avec une collation la plus basique (à un seul niveau, c'est plus simple que les lettres accentuées françaises), la complication est en faitdu même ordre quand on se reporte uniquement à la ponctuation ASCII. Le 29 novembre 2012 15:13, Vladimir Vyskocil vladimir.vysko...@gmail.com a écrit : On 29 nov. 2012, at 12:45, Philippe Verdy verd...@wanadoo.fr wrote: Ce qui se complique encore quand les toponymes ***officiels*** espagnols utilisent le / pour séparer les noms ***co-officiels*** issus de plusieurs langues, ces deux langues ***devant*** toujours être citées ensembles et dans l'ordre indiqué sans qu'on puisse en supprimer un ! C'est alors le même toponyme dans les langues d'origine, les différences linguistiques étant alors abolies dans la dénomination officielle pour la même entité (regardez le Pays Basque espagnol par exemple). Dans ce cas le / ne signifie pas non plus sur, ***même*** en Français. Comment alors faire un traitement automatique de substitution pour faire joli ? Oui effectivement le / a sa propre sémantique dans ce cas, mais on ne doit PAS l'utiliser comme s'il s'agissait d'une abréviation, même en français. Bref en aucun cas Argenton / Creuse ne signifie la même chose que Argenton-sur-Creuse (ne pas oublier non plus les traits d'union ici !) Car en Espagne et même en français, ce / est un séparateur, distingué de l'autre séparateur trait d'union qui est aussi utilisé pour juxtaposer deux termes mais avec une autre signification. L'idée qu'un moteur de rendu peut librement remplacer la ponctuation est totalement erronée, chacune a sa signification propre mais on ne peut pas la déduire de la seule façon dont cette ponctuation est codée puisque pour cela il faudrait coder ***aussi*** la sémantique. Dans ce cas c'est le schema qui n'est pas bon et on aurait du partir par exemple sur un tag name multi-valué alors que l'on est clairement parti sur une solution simpliste qui revient a tagguer pour le rendu : on veut que les 2 noms s'affichent côte à côte séparés par un caractère lambda sans rien a avoir a changer aux moteurs de rendu actuels... Il faut également prendre en compte tous les outils de recherche qui vont faire comment pour se dépatouiller avec des données formatés avec des demi-espaces insécables ou je ne sais quelle curiosité de la langue française ? Vladimir ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Suppression des tirets cadratins
Le 29 novembre 2012 19:25, Vladimir Vyskocil vladimir.vysko...@gmail.coma écrit : Le 29 nov. 2012 à 16:57, Philippe Verdy verd...@wanadoo.fr a écrit : Non on ne veut pas 2 noms séparés, c'est un seul et même nom contenant deux éléments. Oui c'est ce que j'ai dit un nom multi-valué que le moteur de rendu pourra très bien afficher nom1 – nom2 par exemple. Non il n'est pas multi-valué (dans le même sens des valeurs séparés par des point-virgules dans la même clé, ou des valeurs stockées dans des clés différentes comme les différentes langues de plusieurs name:lang=* (dont on n'affiche normalement qu'une seule). C'est un seul et même nom, avec même souvent un ordre signifiant (pas toujours, cela dépend du type d'objet : pour un chemin frontière, l'ordre n'a pas d'importance, pour une route indiquant une direction, l'ordre est signifiant et correspond à l'orientation de la route), mais que le moteur de rendu ne doit pas se contenter de pouvoir afficher, mais il doit afficher les deux simultanément, la combinaison ne supportant pas d'abréviation à un seul (ce qui créerait une ambiguité évidente entre nom1 – nom2 et nom1 – nom3 si on l'abrège à seulement nom1 (qui perd tout son sens distinctif). Il ne signifie donc pas et (intersection), ni ouest (choix/disjonction), mais une combinaison des deux (formation d'une paire disjonctive, l'objet n'étant distinctif que dans cette combinaison qui peut être orientée au sens de 1 vers 2, ou non orientée au sens de entre 1 et 2). Cependant pour le sens orienté, un autre séparateur serait plus précis en utilisant une flèche horizontale (voire - ou juste ) au lieu du tiret cadratin qui à priori n'implique pas une relation d'ordre. Il y a encore un autre sens que le tiret exclue : l'inclusion de l'un dans l'autre, par exemple pour apporter une précision supplémentaire à une première désignation générique. Le tiret cadratin sert la même chose qu'un lien dans un graphe non orienté entre deux sommets du graphe : ce que désigne le nom formé est le lien entre les deux, pas les sommets de chaque côté, ni seulement eux, ni le lien + les 2 ; il désigne donc une seule et même entité indépendante formée par le lien et non deux, ni même les deux, mais autre chose encore qui ne contient pas nécessairement et n'est ni l'un ni l'autre. On ne sait pas en revanche par le seul nom formé si l'objet est orienté, ce sont les autres propriétés de l'objet qui le disent (puisque tous les chemins, par exemple, sont orientés par défaut dans OSM, même les chemins fermés, à moins que le chemin désigne une surface, avec ou sans sa bordure). Ce qui est en revanche précisé c'est que l'objet peut être mis en relation avec deux autres objets de même nature mais indépendants l'un de l'autre. Ce tiret cependant établit une priorité d'association moins grande que celle du tiret simple ou du trait d'union qui indique une association serrée : trait d'union tiret separateur (ou demi-cadratin) tiret cadratin Les rôles de la virgule ou du point-virgule sont différents : il créent, eux, des listes de valeurs distinctes, et seulement eux, sans les associer. mais eux aussi ont une hiérarchie de formation des listes : virgule point-virgule Mais eux aussi n'impliquent pas non plus nécessairement une relation d'ordre entre les items listés qu'il séparent. Sans ordre, c'est une relation de type ensembliste, avec un ordre cela crée une relation une relation de dépendance ou d'inclusion. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Suppression des tirets cadratins
Bonjour, Le 28/11/2012 18:29, te...@free.fr a écrit : Champs-Élysées — Clemenceau (avenue des Champs-Élysées, place Clemenceau) si je suis d'accord sur le principe, il reste possible aux tenants de la simplicité (et ça aussi c'est bien, mangez-en) d'utiliser des tirets simples partout, à condition de les encadrer d'espaces -- ou non -- selon le cas. On peut donc se contenter de : Champs-Élysées - Clemenceau A+ -- Jean-Francois Nifenecker, Bordeaux ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Suppression des tirets cadratins
Bonjour, S'il existe des débats inter-frontaliers sur l'utilisation ou non des tirets cadratins ou semi-cadratins (et à mon avis le débat s'arrête quand on se rend compte que la désignation dépend de la langue), je suis contre l'idée de supprimer ces caractères typographiques français là où en France ils ont toute leur place, car ils ont un sens. Laissez-moi citer ces exemples de stations de métro, de gares ou d'arrêts de bus, où ce caractère désigne l'union de deux entités qui n'ont pas d'autre raison d'être liés autrement que par leur rapprochement géographique ou pour préciser une position : Sèvres — Babylone (rue de Sèvres, rue de Babylone) Réaumur — Sébastopol (rue Réaumur, boulevard de Sébastopol) Marcadet — Poissonniers (rue Marcadet, rue des Poissonniers) Palais Royal — Musée du Louvre (deux bâtiments distincts) Pierrefitte — Stains (villes proches) Le Raincy — Villemomble — Montfermeil (villes proches pouvant être rejointes par cet arrêt SNCF) Aubervilliers — Pantin — Quatre Chemins (villes proches et lieu-dit) Maisons-Alfort — Stade (dans cette ville, plus précisément près du stade) Charenton — Écoles (à Charenton-le-Pont, à proximité de l'école Aristide Briand et sans doute d'autres) alors que le trait d'union, comme son nom l'indique, unit ; notez la différence dans la lecture de ces stations : Haussmann — Saint-Lazare (boulevard Haussmann, gare Saint-Lazare) Champs-Élysées — Clemenceau (avenue des Champs-Élysées, place Clemenceau) Ce sont les règles édictées par l'Académie française, et reprises sur le terrain par les opérateurs dont la RATP. Et il me semble que ce qui se trouve sur le terrain fait foi dans OpenStreetMap (que l'on n'écrit pas Open Street Map ou Open-Street-Map). Si la raison de supprimer ce caractère se trouve dans un outil de recherche, alors non ! Comme dans d'autres situations, c'est à l'outil de s'adapter et de savoir remplacer un tiret par un autre pour trouver des résultats, tout comme il doit savoir remplacer un e minuscule ou majuscule par un é ou un è. Je ne suis pas favorable à cette suppression, tout comme vous n'accepteriez pas de supprimer les accents. Teuxe PS. Pour les sous-titres (Parc de la Villette, Tour Eiffel, Place Aristide Briand, etc.), j'imagine que alt_name=* fait l'affaire ? - Mail original - De: sly (sylvain letuffe) li...@letuffe.org À: Discussions sur OSM en français talk-fr@openstreetmap.org Envoyé: Mardi 27 Novembre 2012 22:20:29 Objet: Re: [OSM-talk-fr] Suppression des tirets cadratins On mardi 27 novembre 2012, Vincent de Chateau-Thierry wrote: En revanche, je suis tout à fait contre l'idée de coller un tag name à des limites administratives qui ne sont que des limites (et pas une route, ou une rivière par ex.) Pareil. Toutefois, j'entends les arguments que tu as indiqué connaître, et si je ne mettrais pas de nom, je m'abstiendrais de changer le choix des autres en l'état des outils/éditeurs. -- sly qui suis-je : http://sly.letuffe.org email perso : sylvain chez letuffe un point org ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Suppression des tirets cadratins
Les caractères de ponctuation doivent pouvoir être saisis par n'importe quel quidam sur n'importe quel clavier et être reconnus par n'importe quel logiciel. A ce propos, as-tu des caractères chinois ou arabes sur ton clavier ? Dans ce cas ils n'auraient pas droit de cité dans OSM ? Teuxe ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Suppression des tirets cadratins
2012/11/28 te...@free.fr: Tu es sûr de ne pas confondre information et mise en page ? La plupart des panneaux de rues sont écrits avec des caractères en majuscule. Ca n'est pas pour autant qu'on recopie bêtement les noms de rues en majuscule (quoique, certains le font...). L'assertion le terrain fait foi a été plusieurs fois corrigé. C'est en cas de doute, le terrain fait foi. Il arrive aussi que le terrain se trompe, on en a de nombreux exemples dans les archives de cette liste (Clémenceau, par exemple, avec un é sur des arrêts de bus ou même de panneaux de rues). On a eu une discussion similaire sur l'espace dans les ref de routes. Espace, demi-espace, espace insécable, demi-insécable, pas d'espace ? Les subtilités de ces caractères typographiques spéciaux échappent à 99% des contributeurs et utilisateurs de base. Alors je sais bien qu'on peut se la jouer expert en typographie (on a même le droit d'en être un) mais OSM se construit par ou pour un public le plus large et international possible, celui qui n'a jamais entendu parlé de tiret cadratin. Si on veut distinguer deux entités, on peut aussi bien mettre des espaces avant et après le tiret pour lever toute ambiguité (Maisons-Alfort - Stade est assez clair). Pieren ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Suppression des tirets cadratins
Il ne s'agit pas que d'une mise en page, j'ai précisé qu'il y a une sémantique dans le fait d'utiliser un tiret plutôt qu'un trait d'union. Les exemples me semblaient parlants. La mise en page consisterait au contraire de décider de remplacer ce tiret par un trait d'union par souci de simplicité ou de compatibilité, tout comme par simplicité dans nos e-mails on place des guillemets à l'américaine plutôt que des guillemets à la française. Il est clair que chaque contributeur apporte sa pierre à l'édifice dans la mesure de ses connaissances et de ses moyens. Mais cela ne doit pas pousser la totalité des contributeurs à se limiter au strict minimum, sous prétexte qu'une bonne partie ne soit pas en mesure de faire mieux. Il y a aussi de nombreux exemples à ça : - tous les contributeurs ne savent pas forcément s'il faut écrire D 123 ou D123 et sans doute peu y portent une réelle attention, et pourtant on ne leur interdit pas de participer, on s'arrange pour corriger ; - tous les contributeurs ne savent pas être précis dans leurs tracés, pourtant d'autres corrigent derrière ; - tous les contributeurs ne savent pas importer de cadastre, pourtant certains s'y risquent et d'autres corrigent ; - tous les contributeurs ne sont pas en mesure de faire tourner des scripts de vérifications ou de corrections par des bots (peu sont au courant que des robots font des modifications), et pourtant ces robots et ces scripts existent et sont utilisés par une minorité ; - etc. Suivant cette logique : - Placer un trait d'union est à la portée de tous, et on a le droit d'améliorer. - Placer un tiret pour améliorer le trait d'union est peut-être plus sioux et l'édition sera à la portée d'une minorité, mais volontairement le remplacer par un trait d'union serait une régression. Si on écrit Clemenceau dans la base, c'est qu'une source vérifiable (l'origine du nom propre) nous prouve cette écriture et qu'on a croisé les informations justement parce qu'on a douté. Si on n'a pas d'autre source, alors on se réfère au terrain qui est la seule preuve. Et si quelqu'un passe derrière ce premier contributeur et se rend compte de l'inexactitude, il est en droit de corriger selon ses connaissances et ses références, sans jugement légitime sur les compétences du premier. Teuxe - Mail original - De: Pieren pier...@gmail.com À: Discussions sur OSM en français talk-fr@openstreetmap.org Envoyé: Mercredi 28 Novembre 2012 19:20:21 Objet: Re: [OSM-talk-fr] Suppression des tirets cadratins 2012/11/28 te...@free.fr: Tu es sûr de ne pas confondre information et mise en page ? La plupart des panneaux de rues sont écrits avec des caractères en majuscule. Ca n'est pas pour autant qu'on recopie bêtement les noms de rues en majuscule (quoique, certains le font...). L'assertion le terrain fait foi a été plusieurs fois corrigé. C'est en cas de doute, le terrain fait foi. Il arrive aussi que le terrain se trompe, on en a de nombreux exemples dans les archives de cette liste (Clémenceau, par exemple, avec un é sur des arrêts de bus ou même de panneaux de rues). On a eu une discussion similaire sur l'espace dans les ref de routes. Espace, demi-espace, espace insécable, demi-insécable, pas d'espace ? Les subtilités de ces caractères typographiques spéciaux échappent à 99% des contributeurs et utilisateurs de base. Alors je sais bien qu'on peut se la jouer expert en typographie (on a même le droit d'en être un) mais OSM se construit par ou pour un public le plus large et international possible, celui qui n'a jamais entendu parlé de tiret cadratin. Si on veut distinguer deux entités, on peut aussi bien mettre des espaces avant et après le tiret pour lever toute ambiguité (Maisons-Alfort - Stade est assez clair). Pieren ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Suppression des tirets cadratins
Pour les noms des stations de métro, je peux vous dire qu'il n'y a aucune cohérence dans les données officielles de la RATP. Les noms entre les fichiers publiés et les plans ne sont même pas cohérents alors pour la typographie je crois que c'est pas pour demain ! Lors de l'intégration du fichier opendata de la RATP, j'ai tout remis en cohérence avec espace-trait d'union-espace pour justement différencier ces rapprochements des véritables traits d'union (leur véritable nom*). Ceci a l'avantage d'être cohérent avec ce qui a été fait sur wikipédia. +1 avec Pieren sur la nécessité de rester simple et accessible au plus grand nombre de contributeurs. Il est toujours possible si l'on souhaite suivre les subtilités des règles de typographie de remplacer ces espace-tiret-espace par espace fine insécable-tiret demi cadratin-espace-espace fine insécable. On pourra aussi revoir la capitalisation des noms qui ne respecte sûrement par les règles de telle ou telle académie. * voir: http://fr.wikipedia.org/wiki/Tiret -- Christian Quest - OpenStreetMap France - http://openstreetmap.fr/u/cquesthttp://openstreetmap.fr/u/christian-quest ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
[OSM-talk-fr] Suppression des tirets cadratins
Bonjour, Je constate une lente (mais certaine) progression de l'usage d'un caractère typographique qui, amha, n'a rien à faire dans les tags name d'OSM. Je parle du tiret cadratin ou tiret long, unicode 0x2014. Exemples: http://www.openstreetmap.org/browse/relation/90341 Petit rappel : OSM est une base de données, pas une société d'édition de beaux livres ou de belles cartes avec de beaux tirets longs, moyens ou carrés pour faire joli. Les caractères de ponctuation doivent pouvoir être saisis par n'importe quel quidam sur n'importe quel clavier et être reconnus par n'importe quel logiciel. Alors, lorsque je rencontrerais ce genre de caractère exotique, je les remplacerais par le bon vieux tiret, unicode 0x002D, code ASCII 0x2D, touche clavier '-'. Et je répéterais ce que disait un de nos anciens premiers ministres à ceux qui insisteraient: je vous demande de vous arrêter. Je connais les auteurs de ces mauvaises habitudes (toujours les mêmes) mais je ne dénonce pas en public. Ils se reconnaîtront. Pieren ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Suppression des tirets cadratins
yo, HS(running gag :) je sens qu'on va encore être d'accord, ça devient pénible à force, heureusement qu'on a le wiki pour s'étriper/HS On mardi 27 novembre 2012, Pieren wrote: Je constate une lente (mais certaine) progression de l'usage d'un caractère typographique qui, amha, n'a rien à faire dans les tags name d'OSM. Je parle du tiret cadratin ou tiret long, unicode 0x2014. Exemples: http://www.openstreetmap.org/browse/relation/90341 Put... j'avais peur de re-re-passer pour un chieur à lancer le sujet, mais ce tiret m'a valu un échange vif (et bizarrement sans intérêt et trop long avec l'unique auteur de tous ces tirets) J'ai laissé tombé car ça me semblait futile. Mais c'est revenu sur la liste tagging : http://gis.19327.n5.nabble.com/Naming-boundary-ways-td5728863.html#a5729805 Où l'on m'a presque reproché que ça soit un français qui propage ça à toute l'europe. Donc : +1 Petit rappel : OSM est une base de données, pas une société d'édition de beaux livres ou de belles cartes avec de beaux tirets longs +1 , moyens ou carrés pour faire joli. Les caractères de ponctuation doivent pouvoir être saisis par n'importe quel quidam sur n'importe quel clavier et être reconnus par n'importe quel logiciel. +1 : Les mappeurs devraient avoir la priorité et de la simplicité dès que c'est possible sans que ça n'impacte négativement les autres mappeurs (si si ,les relations c'est bien) Alors, lorsque je rencontrerais ce genre de caractère exotique, je les remplacerais par le bon vieux tiret, unicode 0x002D, code ASCII 0x2D, touche clavier '-'. +1 ou ; ou , ou / ou j'en sais rien mais un truc qui se trouve sur le clavier des gens Et je répéterais ce que disait un de nos anciens premiers ministres à ceux qui insisteraient: je vous demande de vous arrêter. +1 Je connais les auteurs de ces mauvaises habitudes (toujours les mêmes) mais je ne dénonce pas en public. Ils se reconnaîtront. Là, j'en ai marre des +1, on dirait une république bananière : -1 D'abord, c'est toujours le même et pas les, et c'est celui qui explique (avec des messages trop longs) aux autres sans écouter leurs arguments et qui n'écoute la démocratie que sous la menace et tente trop souvent d'imposer son point de vue plutôt qu'opter pour la prudence du statu quo. Après ils se reconnaîtront, je viens de passer à ils le reconnaîtront -- sly qui suis-je : http://sly.letuffe.org email perso : sylvain chez letuffe un point org ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Suppression des tirets cadratins
Bonsoir, Le 27/11/2012 18:21, sly (sylvain letuffe) a écrit : yo, HS(running gag :) je sens qu'on va encore être d'accord, ça devient pénible à force, heureusement qu'on a le wiki pour s'étriper/HS On mardi 27 novembre 2012, Pieren wrote: Je constate une lente (mais certaine) progression de l'usage d'un caractère typographique qui, amha, n'a rien à faire dans les tags name d'OSM. Je parle du tiret cadratin ou tiret long, unicode 0x2014. Exemples: http://www.openstreetmap.org/browse/relation/90341 Put... j'avais peur de re-re-passer pour un chieur à lancer le sujet, mais ce tiret m'a valu un échange vif (et bizarrement sans intérêt et trop long avec l'unique auteur de tous ces tirets) J'ai laissé tombé car ça me semblait futile. Mais c'est revenu sur la liste tagging : http://gis.19327.n5.nabble.com/Naming-boundary-ways-td5728863.html#a5729805 D'accord avec vous 2 sur le besoin de faire simple, et donc de propager des caractères disponibles simplement. HS ou presque En revanche, je suis tout à fait contre l'idée de coller un tag name à des limites administratives qui ne sont que des limites (et pas une route, ou une rivière par ex.). C'est essentiellement sur ces objets qu'on trouve les tirets cadratins, il ne faudra pas compter sur moi pour les remplacer par des tirets courts. Le seul sort que j'ai envie de réserver à ces tags, c'est la suppression. Je partage plusieurs points de vue exprimés sur tagging (merci Sly pour le lien vers ce fil). En substance : ne pas nommer ce qui ne porte pas de nom, quitte, à la rigueur, à placer sur un tag note=* la mention actuellement portée par name=*. Je connais les arguments sur le confort d'édition que ces noms apportent, mais je ne m'y range pas. / vincent ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Suppression des tirets cadratins
On mardi 27 novembre 2012, Vincent de Chateau-Thierry wrote: En revanche, je suis tout à fait contre l'idée de coller un tag name à des limites administratives qui ne sont que des limites (et pas une route, ou une rivière par ex.) Pareil. Toutefois, j'entends les arguments que tu as indiqué connaître, et si je ne mettrais pas de nom, je m'abstiendrais de changer le choix des autres en l'état des outils/éditeurs. -- sly qui suis-je : http://sly.letuffe.org email perso : sylvain chez letuffe un point org ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
