Re: [OSM-talk-fr] Outil de vérification des relations de type transports publics
Le 29 novembre 2012 00:24, Jo winfi...@gmail.com a écrit : J'utilise également le tag route_ref, car il est facile à remplir quand on est sur place et il aide à faire un contrôle de qualité. J'utilise aussi le tag route_ref pour noter lors de relevé sur le terrain les lignes qui passent par un arrêt. Cela permet ensuite de retrouver/relier les arrêt dans la relation si elle existe ou quand on la crée. J'ai tendance à les laisser, cela apporte un peu de redondance et permet de faire des contrôles croisés. -- 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
Re: [OSM-talk-fr] Comment nommer simplement un groupe d'objet?
Nommer un landuse me semble la moins mauvaise solution si j'ai bien compris le besoin (une résidence). Pour une résidence, un landuse=residential + name=* Même principe pour une zone industrielle, zone commerciale, etc. Les relations c'est bien mais il ne faut pas en abuser... si l'on peut définir l'emprise de cette zone, un polygone suffit à indiquer que tout ce qui est à l'intérieur en fait partie. Le 29 novembre 2012 02:53, Tetsuo Shima tets...@gmail.com a écrit : Bonjour, Voilà mon petit souci, nommer un groupe de building/parking/voie accès qui forme une résidence machin ou un groupe truc, sans qu'il y ait particulièrement d'objet englobant le tout comme un amenity=*. Pour les groupes scolaire je trouve déjà la solution du landuse pas très élégante, donc je l'exclue ici, sauf que je ne vois pas d'alternative très pertinente ... a part une relation site=housing . Cordialement ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr -- 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
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] Outil de vérification des relations de type transports publics
Roland à déjà mentionné qu'il serait très content si quelqu'un étend le plugin public_transport sur la liste josm-dev. L'avantage supplémentaire est que l'on peut utiliser les autres classes disponibles en JOSM pour travailler avec les données OSM, ce qui devrait rendre le travail plus facile. Peut-être je devrais me lancer dans l'apprentissage de JAVA, mais je préfère largement la simplicité et l'élégance de Python... Polyglot 2012/11/29 Vincent Privat vincent.pri...@gmail.com Sympa comme initiative, mais pourquoi en faire forcément une application autonome ? J'aurais bien vu un plugin JOSM qui rajoute ces règles au validateur natif de JOSM. Cerise sur le gâteau, ça pourrait même être incorporé au plugin public_transport de Roland Obricht. En plus vu que Roland passe plus de temps sur l'Overpass API que sur ce plugin, je pense qu'il serait ravi de trouver un co-mainteneur du plugin :) Le 29 novembre 2012 00:24, Jo winfi...@gmail.com a écrit : J'étais en train de commencer le développement de quelque chose de comparable. En outre de détecter des erreurs, moi j'envisageais de faire une détection automatiques d'arrêts. Pour cela je voulais répérer tous les arrêts dans les 5-15m (configurable) à droite (gauche) du bout de chemin. (A l'aide du code des parallel ways pour déterminer une surface). Cela devrait également aider à les mettre dans l'ordre parcourue. Chez nous, nous avons des bus express qui ne desservent pas tous les arrêts qu'ils passent. Pour cela j'ai 'inventé' le tag not_served_by pour les exclure. J'utilise également le tag route_ref, car il est facile à remplir quand on est sur place et il aide à faire un contrôle de qualité. Nous avons également des bus qui ne font pas de trajet fixe, pour lesquels il n'existe pas de relation type=route. Ils ne desservent que les arrêts pour lesquels ils ont été réservés. Il pourrait être intéressant d'ajouter le banc, l'abribus et la poubelle à la relation stop_area, comme la plateforme et l'indicateur des bus à l'arrivé. Dès qu'un fichier .jar sera disponible, je serai ravi de tester ton application. Polyglot * * ___ 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] Comment nommer simplement un groupe d'objet?
Oui mais la question n'est pas celle des zones résidentielles ou commerciales ou industrielles : elles incluent par définition tout ce qui est dedans (même s'il y a des bois, jardins, constructions, routes, cours d'eau, voies ferrées, parkings...). Ce n'est pas le cas des autres landuse=* (et autres natural=*), comme la forêt qui n'inclue pas les cours d'eau (hormi les fossés et petits ruisseaux qui peuvent être sous la couverture des arbres), les constructions, les routes (sauf les chemins forestiers), les morceaux de mer ou les plages... Le problème c'est que là les règles d'inclusion ou non sont très floues, et qu'un moteur de rendu ou de recherche à du mal à choisir s'il faut ou non y inclure ces éléments. On doit l'aider en étant plus précis. Et on doit découper quand il y a des superpositions entre plusieurs landuse=* de types différents. ou plusieurs natural=* de types différents. De la même façon qu'on doit tronçonne aussi des routes ayant des attributs différents sur des sections distinctes, sans les superposer. Le problème c'est de résoudre les ambiguités. A la limite on a admis que les routes et batiments forment des ilots dans les zones où on les inclue, mais uniquement pour le rendu (qui les tracera par dessus sans les recouvrir). Mais en terme topologique, même les routes et bâtiments restent dans la zone landuse=* où ils sont situés, ce qui veut dire qu'on n'a pas à surdécouper la zone si tout autour de l'élément inclus c'est la même zone landuse=*. Dans un tel cas en effet il n'y a pas ambiguité (même si pour le rendu il faut ajouter une règle pour que ces éléments enclavés dans la zone ne soient pas recouverts, et parfois il faut même l'aider avec layer=* si la seule règle de priorité de superposition ne suffit pas). Le 29 novembre 2012 09:03, Christian Quest cqu...@openstreetmap.fr a écrit : Nommer un landuse me semble la moins mauvaise solution si j'ai bien compris le besoin (une résidence). Pour une résidence, un landuse=residential + name=* Même principe pour une zone industrielle, zone commerciale, etc. Les relations c'est bien mais il ne faut pas en abuser... si l'on peut définir l'emprise de cette zone, un polygone suffit à indiquer que tout ce qui est à l'intérieur en fait partie. Le 29 novembre 2012 02:53, Tetsuo Shima tets...@gmail.com a écrit : Bonjour, Voilà mon petit souci, nommer un groupe de building/parking/voie accès qui forme une résidence machin ou un groupe truc, sans qu'il y ait particulièrement d'objet englobant le tout comme un amenity=*. Pour les groupes scolaire je trouve déjà la solution du landuse pas très élégante, donc je l'exclue ici, sauf que je ne vois pas d'alternative très pertinente ... a part une relation site=housing . Cordialement ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr -- 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 ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Outil de vérification des relations de type transports publics
Salut, Le 29 novembre 2012 00:24, Jo winfi...@gmail.com a écrit : J'étais en train de commencer le développement de quelque chose de comparable. En outre de détecter des erreurs, moi j'envisageais de faire une détection automatiques d'arrêts. Pour cela je voulais répérer tous les arrêts dans les 5-15m (configurable) à droite (gauche) du bout de chemin. (A l'aide du code des parallel ways pour déterminer une surface). J'y avais pensé... Jusqu'à tomber sur des lignes de bus qui passent devant des arrêts mais ne s'y arrêtent pas (y en a qu'ont essayé, ils ont eu des problèmes...). Du coup, le risque est grand de lever des faux-positifs. Cela devrait également aider à les mettre dans l'ordre parcourue. Chez nous, nous avons des bus express qui ne desservent pas tous les arrêts qu'ils passent. Pour cela j'ai 'inventé' le tag not_served_by pour les exclure. J'utilise également le tag route_ref, car il est facile à remplir quand on est sur place et il aide à faire un contrôle de qualité. Nous avons également des bus qui ne font pas de trajet fixe, pour lesquels il n'existe pas de relation type=route. Ils ne desservent que les arrêts pour lesquels ils ont été réservés. Pour ces cas-là, je ne vois pas trop comment les gérer, et encore moins comment les tester... Il pourrait être intéressant d'ajouter le banc, l'abribus et la poubelle à la relation stop_area, comme la plateforme et l'indicateur des bus à l'arrivé. Pour les bancs et Abribus, j'ai plutôt tendance à indiquer cette info directement sur le platform, car il arrive qu'un arrêt ait un banc et/ou un Abribus dans un sens mais pas dans l'autre (ce dernier correspond au cas où l'arrêt est vers la fin de la ligne, et que donc personne n'y monte). Dès qu'un fichier .jar sera disponible, je serai ravi de tester ton application. C'est en cours : j'ai déjà ajouté ce matin la prise en compte de Maven, et revu en conséquence la hiérarchie des fichiers. Polyglot * * Francescu ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr -- Cordialement, Francescu GAROBY ___ 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] Outil de vérification des relations de type transports publics
Ah, la question qui tue, et que je craignais de voir arriver ! :-) Petite histoire : Lorsque je me suis lancé dans ce projet, c'est parce que je déclarais les lignes de bus Twisto, dans l'agglomération caennaise. Le nombre de lignes augmentant, j'ai vite réalisé à quel point ça allait devenir long et fastidieux de les vérifier toutes et de m'assurer qu'une modification à un endroit (un bout de route scindé en 2, des routes fusionnées, ...) pouvait avoir des répercussions sur mes relations. Bref, je me suis donc lancé dans l'écriture de cette appli, après avoir testé le plug-in en question, que je n'ai pas du tout trouvé pratique à manipuler ! Mais j'avais conscience dès le début que j'allais avoir à faire un choix : en faire un plug-in JOSM ? Une appli Web comme analyser ? De nouveaux tests pour Osmose ? Autre chose ? Maintenant, je reste ouvert aux idées, et inclure mon travail dans ledit plug-in, voire le reprendre pour l'améliorer n'est pas inenvisageable du tout. Le 29 novembre 2012 01:43, Vincent Privat vincent.pri...@gmail.com a écrit : Sympa comme initiative, mais pourquoi en faire forcément une application autonome ? J'aurais bien vu un plugin JOSM qui rajoute ces règles au validateur natif de JOSM. Cerise sur le gâteau, ça pourrait même être incorporé au plugin public_transport de Roland Obricht. En plus vu que Roland passe plus de temps sur l'Overpass API que sur ce plugin, je pense qu'il serait ravi de trouver un co-mainteneur du plugin :) Le 29 novembre 2012 00:24, Jo winfi...@gmail.com a écrit : J'étais en train de commencer le développement de quelque chose de comparable. En outre de détecter des erreurs, moi j'envisageais de faire une détection automatiques d'arrêts. Pour cela je voulais répérer tous les arrêts dans les 5-15m (configurable) à droite (gauche) du bout de chemin. (A l'aide du code des parallel ways pour déterminer une surface). Cela devrait également aider à les mettre dans l'ordre parcourue. Chez nous, nous avons des bus express qui ne desservent pas tous les arrêts qu'ils passent. Pour cela j'ai 'inventé' le tag not_served_by pour les exclure. J'utilise également le tag route_ref, car il est facile à remplir quand on est sur place et il aide à faire un contrôle de qualité. Nous avons également des bus qui ne font pas de trajet fixe, pour lesquels il n'existe pas de relation type=route. Ils ne desservent que les arrêts pour lesquels ils ont été réservés. Il pourrait être intéressant d'ajouter le banc, l'abribus et la poubelle à la relation stop_area, comme la plateforme et l'indicateur des bus à l'arrivé. Dès qu'un fichier .jar sera disponible, je serai ravi de tester ton application. Polyglot * * ___ 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 -- Cordialement, Francescu GAROBY ___ 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] Outil de vérification des relations de type transports publics
Il ne faut peut-être pas forcément l'ajouter à ce plugin. Peut-être c'est mieux de l'ajouter aux tests du validateur? Si ce que tu envisages c'est simplement un contrôle de qualité (comme c'est conçu maintenant) c'est l'endroit indiqué. Si tu l'envisages comme 'assistant' pour améliorer/créer les relations route=bus/tram, un plugin est peut-être mieux. Si l'interface graphique de l'existant ne convient pas, je ne pense pas que Roland serait très faché si celle-là est remplacée. Je me débrouille avec, mais dire qu'elle n'est pas très intuïtive c'est être gentil... Cependant, tout ce que je fait avec, c'est ajouter des arrêts, pour éliminer les faux-positifs par après. De toute façon, ça m'intéresse, je viens d'écrire quelque chose de comparable pour les relations d'itinéraire cycliste/randonnée avec des noeuds numérotés à l'aide du plugin scripting en JOSM: https://josm.openstreetmap.de/wiki/Help/Plugin/Scripting/Python/RCN_Route_Validator C'est du code Python (pour que je me sente à l'aise), mais il utilise les classes Java de JOSM. Je ne peut pas promettre que je serai très util, mais peut-être on peut travailler là-dessus ensemble. Polyglot 2012/11/29 Francescu GAROBY windu...@gmail.com Ah, la question qui tue, et que je craignais de voir arriver ! :-) Petite histoire : Lorsque je me suis lancé dans ce projet, c'est parce que je déclarais les lignes de bus Twisto, dans l'agglomération caennaise. Le nombre de lignes augmentant, j'ai vite réalisé à quel point ça allait devenir long et fastidieux de les vérifier toutes et de m'assurer qu'une modification à un endroit (un bout de route scindé en 2, des routes fusionnées, ...) pouvait avoir des répercussions sur mes relations. Bref, je me suis donc lancé dans l'écriture de cette appli, après avoir testé le plug-in en question, que je n'ai pas du tout trouvé pratique à manipuler ! Mais j'avais conscience dès le début que j'allais avoir à faire un choix : en faire un plug-in JOSM ? Une appli Web comme analyser ? De nouveaux tests pour Osmose ? Autre chose ? Maintenant, je reste ouvert aux idées, et inclure mon travail dans ledit plug-in, voire le reprendre pour l'améliorer n'est pas inenvisageable du tout. Le 29 novembre 2012 01:43, Vincent Privat vincent.pri...@gmail.com a écrit : Sympa comme initiative, mais pourquoi en faire forcément une application autonome ? J'aurais bien vu un plugin JOSM qui rajoute ces règles au validateur natif de JOSM. Cerise sur le gâteau, ça pourrait même être incorporé au plugin public_transport de Roland Obricht. En plus vu que Roland passe plus de temps sur l'Overpass API que sur ce plugin, je pense qu'il serait ravi de trouver un co-mainteneur du plugin :) Le 29 novembre 2012 00:24, Jo winfi...@gmail.com a écrit : J'étais en train de commencer le développement de quelque chose de comparable. En outre de détecter des erreurs, moi j'envisageais de faire une détection automatiques d'arrêts. Pour cela je voulais répérer tous les arrêts dans les 5-15m (configurable) à droite (gauche) du bout de chemin. (A l'aide du code des parallel ways pour déterminer une surface). Cela devrait également aider à les mettre dans l'ordre parcourue. Chez nous, nous avons des bus express qui ne desservent pas tous les arrêts qu'ils passent. Pour cela j'ai 'inventé' le tag not_served_by pour les exclure. J'utilise également le tag route_ref, car il est facile à remplir quand on est sur place et il aide à faire un contrôle de qualité. Nous avons également des bus qui ne font pas de trajet fixe, pour lesquels il n'existe pas de relation type=route. Ils ne desservent que les arrêts pour lesquels ils ont été réservés. Il pourrait être intéressant d'ajouter le banc, l'abribus et la poubelle à la relation stop_area, comme la plateforme et l'indicateur des bus à l'arrivé. Dès qu'un fichier .jar sera disponible, je serai ravi de tester ton application. Polyglot * * ___ 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 -- Cordialement, Francescu GAROBY ___ 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 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
[OSM-talk-fr] [forum-osm-fr] demo lizpoi
Le message suivant de yaga37: ## Bonjour, J'aimerais savoir si je peux utiliser pour un site cette petite application et si c'est possible de la lancer à partir d'une autre ville que Paris http://lizpoi.3liz.com/demo/index.php/lizpoi/map/?tree_id=1 Merci a été posté sur le forum http://forum.openstreetmap.fr/viewforum.php?f=5 Une réponse par mail sur l'adresse d'expédition n'arrivera nulle part Une réponse à la liste ne sera pas transmise au forum, ce qui n'empêche pas une concertation sur la liste avant de recopier la/les meilleurs réponses sur le forum. Notez qu'il n'est pas necessaire d'avoir un compte sur le forum pour répondre. -- Les questions sur ce robot de transfert forum-liste peuvent être posées à sylvainaletuffe.org ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
[OSM-talk-fr] [forum-osm-fr] Nouveau à Corsegoules
Le message suivant de JP Guido: ## Bonjour, J’ai découvert OSM grâce au conseil de développement du nouveau PNR de pré-alpes d’azur Lors d’une réunion à La Penne. Je me suis mis au travail dans mon village : ajout de sentiers, escaliers, routes restaurants etc. … J’ai un problème avec quelques points comme les « Town hall » et les « Confectionery » que j’ai ajoutés dans la partie « modifier » mais qui n’apparaissent pas sur la carte. JP G a été posté sur le forum http://forum.openstreetmap.fr/viewforum.php?f=10 Une réponse par mail sur l'adresse d'expédition n'arrivera nulle part Une réponse à la liste ne sera pas transmise au forum, ce qui n'empêche pas une concertation sur la liste avant de recopier la/les meilleurs réponses sur le forum. Notez qu'il n'est pas necessaire d'avoir un compte sur le forum pour répondre. -- Les questions sur ce robot de transfert forum-liste peuvent être posées à sylvainaletuffe.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 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] OSMTransport france au concours Géoportail de L'IGN
And the winner is OSMtransport, 1er pour la catégorie accessibilité. http://openstreetmap.fr/3liz-osmtransport -- 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] Bravo 3liz pour le prix accessibilité geoportail
J'ai vu sur cette news http://openstreetmap.fr/3liz-osmtransport que 3liz avait été primé pour son démonstrateur : bravo a vous ! Je suis allé voir sur le site et il est dit que le résultat définitif sera demain, on anticipe sur la délibération ? ^^ Christian par contre il manque l'URL dans la news http://concours-api.ign.fr/participez.html si tu veux bien la rajouter. ++ -- *Florian Lainez* http://twitter.com/overflorian http://www.nouslesgeeks.fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Bravo 3liz pour le prix accessibilité geoportail
Je viens de voir l'annonce au moment même où est arrivé ton mail Florian. :-) Félicitations à 3LIZ, vous le méritez plus que bien ! Nicolas ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
[OSM-talk-fr] Petite erreur de lien sur le site openstreetmap.fr
Je viens de voir qu'il y avait un petite erreur dans l'adresse du lien données brutes sur la page d'accueil du site openstreetmap.fr http://dev.www.openstreetmap.fr/donnees-brutes devrait être http://www.openstreetmap.fr/donnees-brutes Nicolas ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
[OSM-talk-fr] Accès aux données eau du cadastre vectoriel
Je sais que les données eau ont été retirées des exports vectoriels cadastre et je trouve ça très bien qu'on ne puisse pas accéder directement à ces données. Il y en a qui faisait vraiment n'importe quoi avec ça... Mais j'aimerai savoir quelle est la procédure à suivre pour pouvoir demander ces données. Je m'en servais beaucoup pour ajouter les nombreuses piscines que l'on trouve là où je contribue (avec un gros travail de tri visuel et en mettant les bons tags). Je ne souhaite pas ici relancer le débat sur le fait qu'on a le droit ou pas de mettre les piscines dans OSM, là n'est pas la question, merci de vous abstenir. :-) Nicolas ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Accès aux données eau du cadastre vectoriel
Oui, moi aussi ça me manque, aussi bien pour les piscines que pour les rivières et les plans d'eau. J'adaptais les tags mais au moins ça évitait de les tracer. Le 29 novembre 2012 18:31, Nicolas Moyroud nmoyr...@free.fr a écrit : Je sais que les données eau ont été retirées des exports vectoriels cadastre et je trouve ça très bien qu'on ne puisse pas accéder directement à ces données. Il y en a qui faisait vraiment n'importe quoi avec ça... Mais j'aimerai savoir quelle est la procédure à suivre pour pouvoir demander ces données. Je m'en servais beaucoup pour ajouter les nombreuses piscines que l'on trouve là où je contribue (avec un gros travail de tri visuel et en mettant les bons tags). Je ne souhaite pas ici relancer le débat sur le fait qu'on a le droit ou pas de mettre les piscines dans OSM, là n'est pas la question, merci de vous abstenir. :-) Nicolas __**_ 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
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] Accès aux données eau du cadastre vectoriel
On jeudi 29 novembre 2012, Cavok wrote: Oui, moi aussi ça me manque Le 29 novembre 2012 18:31, Nicolas Moyroud nmoyr...@free.fr a écrit : Mais j'aimerai savoir quelle est la procédure à suivre pour pouvoir demander ces données. Ces données ne sont pas dispo, mais tout peut changer. Comme dirait le pilote du battel cruiser dans starcraft 1 (pour ceux qui ont eu la chance d'être geek à cette période) : Awaiting orders keeg lues el sius ej is riov ruop tse'c siam ,htiarw el siam elttab el sap tse'n ec euq sias ej -- 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] Bravo 3liz pour le prix accessibilité geoportail
Le temps-réel n'est pas encore dans la culture de l'IGN ;) En direct depuis la remise des prix: un tweet avec photo, un article sur le site OSM-FR, une news sur la page FaceBook... j'ai même des vidéos que je vais partager si elles ne sont pas trop affreuses. On avait (heureusement) du wifi sur place. Le 29 novembre 2012 17:28, Florian LAINEZ winner...@free.fr a écrit : J'ai vu sur cette news http://openstreetmap.fr/3liz-osmtransport que 3liz avait été primé pour son démonstrateur : bravo a vous ! Je suis allé voir sur le site et il est dit que le résultat définitif sera demain, on anticipe sur la délibération ? ^^ Christian par contre il manque l'URL dans la news http://concours-api.ign.fr/participez.html si tu veux bien la rajouter. ++ -- *Florian Lainez* http://twitter.com/overflorian http://www.nouslesgeeks.fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr -- 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
Re: [OSM-talk-fr] Petite erreur de lien sur le site openstreetmap.fr
Merci ! Corrigé Le 29 novembre 2012 17:46, Nicolas Moyroud nmoyr...@free.fr a écrit : Je viens de voir qu'il y avait un petite erreur dans l'adresse du lien données brutes sur la page d'accueil du site openstreetmap.fr http://dev.www.openstreetmap.**fr/donnees-bruteshttp://dev.www.openstreetmap.fr/donnees-brutes devrait être http://www.openstreetmap.fr/**donnees-bruteshttp://www.openstreetmap.fr/donnees-brutes Nicolas __**_ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.**org/listinfo/talk-frhttp://lists.openstreetmap.org/listinfo/talk-fr -- 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
Re: [OSM-talk-fr] Bravo 3liz pour le prix accessibilité geoportail
Felicitation 3liz ! Vous le meritez bien, les gens a qui je montre OSMTransport trouvent souvent le concept tres sympa :-) Julien De : Florian LAINEZ winner...@free.fr À : Discussions sur OSM en français talk-fr@openstreetmap.org Envoyé le : Jeudi 29 novembre 2012 17h28 Objet : [OSM-talk-fr] Bravo 3liz pour le prix accessibilité geoportail J'ai vu sur cette news http://openstreetmap.fr/3liz-osmtransport que 3liz avait été primé pour son démonstrateur : bravo a vous ! Je suis allé voir sur le site et il est dit que le résultat définitif sera demain, on anticipe sur la délibération ? ^^ Christian par contre il manque l'URL dans la news http://concours-api.ign.fr/participez.html si tu veux bien la rajouter. ++ -- Florian Lainez http://twitter.com/overflorian http://www.nouslesgeeks.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 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] OSM présent dans l'Est Républicain
A priori on devrait avoir Saint-Médard-sur-Ille aussi, bizarrement pas associé avec Rennes Carte ou Verte quand les communautés de communes se touchent (Le site de Rennes pourtant mentionne les autres cartes des autres communautés d'Ille-et-Vilaine). Rien à voir avec Besançon (qui ne marche pas encore sur la liste des thèmes) ni Brest (pour son apport de l'édition des POIs et référencement thématique). Il n'y a pas moyen de relier les deux projets de Rennes et Saint-Médard-sur-Ille comme cela a été fait avec Vitré, afin d'aboutir à terme à un site pour toute l'Ille-et-Vilaine ? Voire plus tard encore pour toute la Bretagne en associant Brest et Rennes pour mobiliser les communautés voisines en allant chercher Saint-Malo-Dinard, Saint-Brieuc, Gingamp, Lannion, Quimper, Vannes, Auray, Lorient, ou les plus petites communautés du centre Bretagne comme Ploërmel, qui pourraient être aidées étant donné le faible nombre de contributeurs locaux et le peu de moyens des EPCI, avec l'aide de la région prenant exemple sur Rennes et Brest ? Comment s'est fait la collaboration autour de Chimère, les assos locales et l'intérêt des communes ? 2012/11/28 partir-en-vtt ad...@partir-en-vtt.com Super, Ils sont dynamiques ces hauts saônois ! Sympa au passage votre appli : http://carte.museum-gray.org/ well done -- View this message in context: http://gis.19327.n5.nabble.com/OSM-present-dans-l-Est-Republicain-tp5738014p5738036.html Sent from the France mailing list archive at Nabble.com. ___ 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] Fwd: [Maps-l] Wikimedia/mapping event in Europe early next year?
Bruxelles est en plus bien mieux desservi et sera aussi apprécié des Anglais qui ont des choses à montrer. C'est un bon nœud TGV et reste pratique aussi pour ceux de la Fondation Wikimedia qui viendraient des USA. Sinon pour les Français comme pour les Anglais c'est l'avion, et ce n'est pas le même prix, y compris le transfert aéroport qui n'est pas donné en Berlin, et ça prend aussi plus de temps (pour rejoindre les aéroports ou dans l'aéroport lui-même, le ciel européen est aussi imprévisible question horaires sur les lignes intérieures Alors que Berlin-Bruxelles (ou Francfort-Bruxelles) se fait facilement aussi en ICE à pas trop cher (Bruxelles a l'avantage d'être un hub aérien, bien plus pratique que Paris, ce qui limite les prix des billets pour ceux qui viennent de plus loin et garantit mieux les horaires en cas de déplacement de vols). Autre avantage, Bruxelles parle déjà plusieurs langues (français, néerlandais, allemand, et facilement aussi l'anglais, ce qui faciliterait les échanges). Attention en plus, il n'y a pas que l'Europe qui pourrait se porter candidate (le message indiquait qu'ils étaient ouverts à d'autres lieux, mais si ça se passe à Tokyo, Shangaï, Rio, Buenos Aires ou Mexico, ce sera une rencontre très nationale et pratiquement monolingue...) Le 28 novembre 2012 15:25, Jo winfi...@gmail.com a écrit : Je me suis inscrit sur la liste maps-I et il y a quelqu'un qui propose Berlin là-bas. Personnellement je préfèrerais que ce soit à Bruxelles. Comme ça je pourrai y aller! Polyglot 2012/11/28 Philippe Verdy verd...@wanadoo.fr Si c'est juste quelque part en Europe, ce sera dans un seule grande capitale accessible facilement depuis un autre pays voisin. Cela limite le choix à quelques grandes villes européennes bien desservies : Paris, Bruxelles, Francfort, Milan, voire même Londres (ils ont des tonnes de projets intéressants là-bas et depuis longtemps, et ils n'auront pas le soucis de la traduction immédiate et pourront même diffuser un live bien suivi par plein de monde). Sinon en France cela pourrait aussi être Nice si l'accent est mis sur WikiVoyage. L'Espagne est aussi une belle destination (Barcelone), mais elle est moins bien desservie sauf par l'avion, et moins centrale pour les voisins (hormi la France) et l'espagnol n'est pas aussi accessible et la communauté OSM espagnole n'est pas au top en ce moment. Je pense donc que ce sera plutôt Bruxelles si ce n'est pas Londres qui a tout ce qu'il faut pour organiser ça. 2012/11/28 Ab_fab gamma@gmail.com Bonjour, Wikimedia envisage de monter en début d'année prochaine un rassemblement relatif au développement de l'extension geodata quelque part en Europe ainsi que le mapping. ___ 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] Réf.: Re: Grosse suppression de données autour de valenciennes
L outil a travaille sur les diffs France du 26 Novembre 2012 14h38 jusqu a maintenant ( soit quasiment 3 jours )et il en ressort le rapport attache en piece jointe dont voici un petit resume : environ 130 modifications effectuees par 5 utilisateurs : olcomm_ild_inr, botdidier2020, kritic, Eric S, Marcussacapuces91 J'ai juste fait un essai pour évaluer l'ampleur des dégâts et en conclure que je ne ferai pas de remapping préventif ;-) Je veux bien essayer de contacter olcomm_ild_inr ou son chef. C'est un opérateur d'une entreprise malgache (ild) qui utilise OSM pour fabriquer des plans touristiques, professionnels et autres. Eric -- Éric SIBERT http://eric.sibert.fr ___ 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] OSM présent dans l'Est Républicain
Le 28/11/2012 15:47, partir-en-vtt a écrit : Ils sont dynamiques ces hauts saônois ! Oui. Ils ont la (haute-)patate ! -- Jean-Francois Nifenecker, Bordeaux ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Bravo 3liz pour le prix accessibilité geoportail
bravo à l'équipe de 3Liz ! Le 29 novembre 2012 20:02, THEVENON Julien julien_theve...@yahoo.fr a écrit : Felicitation 3liz ! Vous le meritez bien, les gens a qui je montre OSMTransport trouvent souvent le concept tres sympa :-) Julien -- *De :* Florian LAINEZ winner...@free.fr *À :* Discussions sur OSM en français talk-fr@openstreetmap.org *Envoyé le :* Jeudi 29 novembre 2012 17h28 *Objet :* [OSM-talk-fr] Bravo 3liz pour le prix accessibilité geoportail J'ai vu sur cette news http://openstreetmap.fr/3liz-osmtransport que 3liz avait été primé pour son démonstrateur : bravo a vous ! Je suis allé voir sur le site et il est dit que le résultat définitif sera demain, on anticipe sur la délibération ? ^^ Christian par contre il manque l'URL dans la news http://concours-api.ign.fr/participez.html si tu veux bien la rajouter. ++ -- *Florian Lainez* http://twitter.com/overflorian http://www.nouslesgeeks.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] Nouvel éditeur spécialisé traduction
Bonjour, BrunoC wrote Sinon faudrait internationaliser l'interface ;-) Chiche ! Maintenant il y a un fichier de traductions à éditer: https://gitorious.org/nomino/nomino/blobs/gettext/locale/fr_FR.utf8/LC_MESSAGES/default.po L'outil Poedit peut aider pour cela. -- View this message in context: http://gis.19327.n5.nabble.com/Nouvel-editeur-specialise-traduction-tp5737914p5738305.html Sent from the France mailing list archive at Nabble.com. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Outil de vérification des relations de type transports publics
À la demande générale, j'ai uploadé une version de mon appli, sous la forme d'un fichier .jarhttps://github.com/windu2b/OSM_checkTransportRelations/downloads Francescu Le 29 novembre 2012 10:12, Jo winfi...@gmail.com a écrit : Il ne faut peut-être pas forcément l'ajouter à ce plugin. Peut-être c'est mieux de l'ajouter aux tests du validateur? Si ce que tu envisages c'est simplement un contrôle de qualité (comme c'est conçu maintenant) c'est l'endroit indiqué. Si tu l'envisages comme 'assistant' pour améliorer/créer les relations route=bus/tram, un plugin est peut-être mieux. Si l'interface graphique de l'existant ne convient pas, je ne pense pas que Roland serait très faché si celle-là est remplacée. Je me débrouille avec, mais dire qu'elle n'est pas très intuïtive c'est être gentil... Cependant, tout ce que je fait avec, c'est ajouter des arrêts, pour éliminer les faux-positifs par après. De toute façon, ça m'intéresse, je viens d'écrire quelque chose de comparable pour les relations d'itinéraire cycliste/randonnée avec des noeuds numérotés à l'aide du plugin scripting en JOSM: https://josm.openstreetmap.de/wiki/Help/Plugin/Scripting/Python/RCN_Route_Validator C'est du code Python (pour que je me sente à l'aise), mais il utilise les classes Java de JOSM. Je ne peut pas promettre que je serai très util, mais peut-être on peut travailler là-dessus ensemble. Polyglot 2012/11/29 Francescu GAROBY windu...@gmail.com Ah, la question qui tue, et que je craignais de voir arriver ! :-) Petite histoire : Lorsque je me suis lancé dans ce projet, c'est parce que je déclarais les lignes de bus Twisto, dans l'agglomération caennaise. Le nombre de lignes augmentant, j'ai vite réalisé à quel point ça allait devenir long et fastidieux de les vérifier toutes et de m'assurer qu'une modification à un endroit (un bout de route scindé en 2, des routes fusionnées, ...) pouvait avoir des répercussions sur mes relations. Bref, je me suis donc lancé dans l'écriture de cette appli, après avoir testé le plug-in en question, que je n'ai pas du tout trouvé pratique à manipuler ! Mais j'avais conscience dès le début que j'allais avoir à faire un choix : en faire un plug-in JOSM ? Une appli Web comme analyser ? De nouveaux tests pour Osmose ? Autre chose ? Maintenant, je reste ouvert aux idées, et inclure mon travail dans ledit plug-in, voire le reprendre pour l'améliorer n'est pas inenvisageable du tout. Le 29 novembre 2012 01:43, Vincent Privat vincent.pri...@gmail.com a écrit : Sympa comme initiative, mais pourquoi en faire forcément une application autonome ? J'aurais bien vu un plugin JOSM qui rajoute ces règles au validateur natif de JOSM. Cerise sur le gâteau, ça pourrait même être incorporé au plugin public_transport de Roland Obricht. En plus vu que Roland passe plus de temps sur l'Overpass API que sur ce plugin, je pense qu'il serait ravi de trouver un co-mainteneur du plugin :) Le 29 novembre 2012 00:24, Jo winfi...@gmail.com a écrit : J'étais en train de commencer le développement de quelque chose de comparable. En outre de détecter des erreurs, moi j'envisageais de faire une détection automatiques d'arrêts. Pour cela je voulais répérer tous les arrêts dans les 5-15m (configurable) à droite (gauche) du bout de chemin. (A l'aide du code des parallel ways pour déterminer une surface). Cela devrait également aider à les mettre dans l'ordre parcourue. Chez nous, nous avons des bus express qui ne desservent pas tous les arrêts qu'ils passent. Pour cela j'ai 'inventé' le tag not_served_by pour les exclure. J'utilise également le tag route_ref, car il est facile à remplir quand on est sur place et il aide à faire un contrôle de qualité. Nous avons également des bus qui ne font pas de trajet fixe, pour lesquels il n'existe pas de relation type=route. Ils ne desservent que les arrêts pour lesquels ils ont été réservés. Il pourrait être intéressant d'ajouter le banc, l'abribus et la poubelle à la relation stop_area, comme la plateforme et l'indicateur des bus à l'arrivé. Dès qu'un fichier .jar sera disponible, je serai ravi de tester ton application. Polyglot * * ___ 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 -- Cordialement, Francescu GAROBY ___ 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 -- Cordialement, Francescu GAROBY ___ Talk-fr mailing list Talk-fr@openstreetmap.org
Re: [OSM-talk-fr] Outil de vérification des relations de type transports publics
Le 30 novembre 2012 02:04, Francescu GAROBY windu...@gmail.com a écrit : À la demande générale, j'ai uploadé une version de mon appli, sous la forme d'un fichier .jarhttps://github.com/windu2b/OSM_checkTransportRelations/downloads C'est beaucoup mieux ! Mais... /home/herve java -jar checkTransportRelations-0.3.jar 2589274 GET http://api.openstreetmap.org/api/0.6/relation/2589274/full route=bus [CheckStopPosition]}The node 1 678 136 471 is not a public_transport=stop_position [CheckPlatform]node 1 678 136 496 is neither a public_transport=station nor a public_transport=platform java.lang.ArrayIndexOutOfBoundsException: 0 at org.windu2b.osm.check_transport_relations.data.osm.Way.getNode(Way.java:174) at org.windu2b.osm.check_transport_relations.data.osm.Way.getFirstNode(Way.java:200) at org.windu2b.osm.check_transport_relations.check.CheckWay.areContiguousWays(CheckWay.java:73) at org.windu2b.osm.check_transport_relations.check.CheckWay.check(CheckWay.java:47) at org.windu2b.osm.check_transport_relations.check.AbstractCheck.check(AbstractCheck.java:80) at org.windu2b.osm.check_transport_relations.check.CheckPublicTransport.check(CheckPublicTransport.java:74) at org.windu2b.osm.check_transport_relations.check.Check.check(Check.java:102) at org.windu2b.osm.check_transport_relations.Main.main(Main.java:49) /home/herve Pour moi la difficulté est maintenant de trouver l'ID d'une ligne ; j'ai lu ta page http://wiki.openstreetmap.org/wiki/Caen/Transports_en_commun que tu as indiqué dans ton premier message, mais je n'ai pas compris comment je faisais pour trouver un ID avec ça. J'ai trouvé par chance une ligne de bus sur Caen, avec une relation route_master_bus et un ID de 2589274/1 (à http://osm.org/go/ervfqnf64-- ), mais ton logiciel a rouspété à cause du /1, je l'ai supprimé (vous voyez que je suis un vrai geek), et j'ai obtenu ce que je donne en intro de ce message. De plus, je tiens à dire qu'il me semble que le tiret quadratin pourrait être avantageusement remplacé par l'expression tiretQuadratin id=58901:AI97 class=onTiretQuadratin lang=FR-fr/ qui a l'avantage d'être compatible.. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Outil de vérification des relations de type transports publics
Heuuu... du XML au milieu des champs name ??? Franchement non (même si le shéma OSM peut être exporté en XML, ce n'est définitivement pas la seule option. Voire du XML natif importé dans une base OpenGIS et supposer que les moteurs de rendus ou d'analyse devront en plus réanalyser du XML n'est pas une bonne idée). Les champs name=* ne doivent contenir que du texte destiné à être lu par un humain (la seule exception étant pour les langues qui ne satisfont pas du seul jeu de caractère codé dans leur écriture, comme les hiéroglyphes, et qui nécessitent un protocole supplémentaire pour les afficher sous forme lisible par l'homme. Et pourquoi tu penses que le tiret cadratin est juste franco-français ? Là où il est il n'a pas de langue attachée. On précise la langue dans les suffixes de code langue des clés OSM pour la valeur entière. Bref rien à voir. Un seul caractère suffit par lui-même ici, sans aucun autre protocole et sans supposer qu'il désigne une quelconque langue ou une orthographe (pas plus que la lettre a ne désigne pas autre chose que cette lettre mais pas les langues ou orthographes qui en font usage). En plus techniquement c'est bien plus compliqué à supporter (alors qu'il n'y a aucun soucis pour le rendu ou l'analyse et les recherches avec le seul caractère codé) et ta solution obligerait à modifier TOUS les outils actuels en dégradant sévèrement en plus leurs performances (une couche de parseur XML en plus, pour la moindre chaîne de libellé localisable et plus moyen de faire fonctionner les outils sans aucun parseur XML difficilement intégrable par exemple dans un moteur SQL, alors que les moteurs SQL font parfaitement de la recherche plein texte avec leur support des collations, alias UCA). Bref tu dis compatible, mais avec qui ou quoi ? Si c'est pour une seule appli particulière, c'est contre les fondements de la base de données OSM. Le 30 novembre 2012 07:02, Ista Pouss ista...@gmail.com a écrit : Pour moi la difficulté est maintenant de trouver l'ID d'une ligne ; j'ai lu ta page http://wiki.openstreetmap.org/wiki/Caen/Transports_en_communque tu as indiqué dans ton premier message, mais je n'ai pas compris comment je faisais pour trouver un ID avec ça. J'ai trouvé par chance une ligne de bus sur Caen, avec une relation route_master_bus et un ID de 2589274/1 (à http://osm.org/go/ervfqnf64-- ), mais ton logiciel a rouspété à cause du /1, je l'ai supprimé (vous voyez que je suis un vrai geek), et j'ai obtenu ce que je donne en intro de ce message. De plus, je tiens à dire qu'il me semble que le tiret quadratin pourrait être avantageusement remplacé par l'expression tiretQuadratin id=58901:AI97 class=onTiretQuadratin lang=FR-fr/ qui a l'avantage d'être compatible.. ___ 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] Outil de vérification des relations de type transports publics
Même pour un export de données OSM en XML cela ne marche pas comme tu le crois, cela donnera un truc du genre: tag key=name value=nom1 lt;tiretQuadratin id=quot;58901:AI97quot; class=quot;onTiretQuadratinquot; lang=quot;FR-frquot;/gt; nom2 / au lieu de: tag key=name value=nom1 – nom2 / Mais pas non plus: tag key=namenom1 tiretQuadratin id=58901:AI97 class=onTiretQuadratin lang=FR-fr/ nom2/tag au lieu de tag key=namenom1 – nom2/tag car cela entraîne une modification substancielle du schéma XML défini pour les exports de données OSM (donc pas compatible non plus !) Le 30 novembre 2012 07:02, Ista Pouss ista...@gmail.com a écrit : tiretQuadratin id=58901:AI97 class=onTiretQuadratin lang=FR-fr/ ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Outil de vérification des relations de type transports publics
Heu... Philippe, je voulais surtout plaisanter avec cette histoire de tiret quadratin en XML, je m'excuse que ça n'ait pas été clair. C'était par rapport au flot de messages sur ce sujet, fort intéressant d'ailleurs, mais l'énormité des discussions pour un simple caractère me semblait propice à quelque humour ? Le mien semble maladroit, bon... Merci tout de même pour cette analyse critique du XML dans un champ name : comme je débute OSM, cela me permet de me faire une idée de ce qu'on peut faire et ne pas faire, ainsi que tout le débat sur le tiret quadratin d'ailleurs. Avec toutes mes excuses encore une fois. Le 30 novembre 2012 07:41, Philippe Verdy verd...@wanadoo.fr a écrit : Heuuu... du XML au milieu des champs name ??? Franchement non (même si le shéma OSM peut être exporté en XML, ce n'est définitivement pas la seule option. Voire du XML natif importé dans une base OpenGIS et supposer que les moteurs de rendus ou d'analyse devront en plus réanalyser du XML n'est pas une bonne idée). Les champs name=* ne doivent contenir que du texte destiné à être lu par un humain (la seule exception étant pour les langues qui ne satisfont pas du seul jeu de caractère codé dans leur écriture, comme les hiéroglyphes, et qui nécessitent un protocole supplémentaire pour les afficher sous forme lisible par l'homme. Et pourquoi tu penses que le tiret cadratin est juste franco-français ? Là où il est il n'a pas de langue attachée. On précise la langue dans les suffixes de code langue des clés OSM pour la valeur entière. Bref rien à voir. Un seul caractère suffit par lui-même ici, sans aucun autre protocole et sans supposer qu'il désigne une quelconque langue ou une orthographe (pas plus que la lettre a ne désigne pas autre chose que cette lettre mais pas les langues ou orthographes qui en font usage). En plus techniquement c'est bien plus compliqué à supporter (alors qu'il n'y a aucun soucis pour le rendu ou l'analyse et les recherches avec le seul caractère codé) et ta solution obligerait à modifier TOUS les outils actuels en dégradant sévèrement en plus leurs performances (une couche de parseur XML en plus, pour la moindre chaîne de libellé localisable et plus moyen de faire fonctionner les outils sans aucun parseur XML difficilement intégrable par exemple dans un moteur SQL, alors que les moteurs SQL font parfaitement de la recherche plein texte avec leur support des collations, alias UCA). Bref tu dis compatible, mais avec qui ou quoi ? Si c'est pour une seule appli particulière, c'est contre les fondements de la base de données OSM. Le 30 novembre 2012 07:02, Ista Pouss ista...@gmail.com a écrit : Pour moi la difficulté est maintenant de trouver l'ID d'une ligne ; j'ai lu ta page http://wiki.openstreetmap.org/wiki/Caen/Transports_en_communque tu as indiqué dans ton premier message, mais je n'ai pas compris comment je faisais pour trouver un ID avec ça. J'ai trouvé par chance une ligne de bus sur Caen, avec une relation route_master_bus et un ID de 2589274/1 (à http://osm.org/go/ervfqnf64-- ), mais ton logiciel a rouspété à cause du /1, je l'ai supprimé (vous voyez que je suis un vrai geek), et j'ai obtenu ce que je donne en intro de ce message. De plus, je tiens à dire qu'il me semble que le tiret quadratin pourrait être avantageusement remplacé par l'expression tiretQuadratin id=58901:AI97 class=onTiretQuadratin lang=FR-fr/ qui a l'avantage d'être compatible.. ___ 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] Outil de vérification des relations de type transports publics
Salut, Merci tout d'abord de bien vouloir tester. Pour la relation que tu as testée, c'est une 'route_master' : elles ne sont pas encore prises en compte, mais c'est prévuhttps://github.com/windu2b/OSM_checkTransportRelations/issues/3! :-) Si tu veux un numéro de relation à tester, sur la page que j'avais préalablement indiqué, clique sur n'importe quel lien dans la colonne direction des tableaux (la colonne ligne correspond au 'route_master' qui regroupe les différentes directions possibles, généralement les tracés aller et retour). Sinon, je n'utilise pas de tiret quadratin dans le nom des relations : c'est soit une flèche (U+2192) entre l'arrêt de départ et celui d'arrivée, pour les relations de 'type=route', soit une flèche à double-sens (U+2194) entre les 2 extrêmités de la ligne, pour les relations de 'type=route_master', comme c'est ton cas avec la relation que tu as testée. Francescu Le 30 novembre 2012 07:02, Ista Pouss ista...@gmail.com a écrit : Le 30 novembre 2012 02:04, Francescu GAROBY windu...@gmail.com a écrit : À la demande générale, j'ai uploadé une version de mon appli, sous la forme d'un fichier .jarhttps://github.com/windu2b/OSM_checkTransportRelations/downloads C'est beaucoup mieux ! Mais... /home/herve java -jar checkTransportRelations-0.3.jar 2589274 GET http://api.openstreetmap.org/api/0.6/relation/2589274/full route=bus [CheckStopPosition]}The node 1 678 136 471 is not a public_transport=stop_position [CheckPlatform]node 1 678 136 496 is neither a public_transport=station nor a public_transport=platform java.lang.ArrayIndexOutOfBoundsException: 0 at org.windu2b.osm.check_transport_relations.data.osm.Way.getNode(Way.java:174) at org.windu2b.osm.check_transport_relations.data.osm.Way.getFirstNode(Way.java:200) at org.windu2b.osm.check_transport_relations.check.CheckWay.areContiguousWays(CheckWay.java:73) at org.windu2b.osm.check_transport_relations.check.CheckWay.check(CheckWay.java:47) at org.windu2b.osm.check_transport_relations.check.AbstractCheck.check(AbstractCheck.java:80) at org.windu2b.osm.check_transport_relations.check.CheckPublicTransport.check(CheckPublicTransport.java:74) at org.windu2b.osm.check_transport_relations.check.Check.check(Check.java:102) at org.windu2b.osm.check_transport_relations.Main.main(Main.java:49) /home/herve Pour moi la difficulté est maintenant de trouver l'ID d'une ligne ; j'ai lu ta page http://wiki.openstreetmap.org/wiki/Caen/Transports_en_communque tu as indiqué dans ton premier message, mais je n'ai pas compris comment je faisais pour trouver un ID avec ça. J'ai trouvé par chance une ligne de bus sur Caen, avec une relation route_master_bus et un ID de 2589274/1 (à http://osm.org/go/ervfqnf64-- ), mais ton logiciel a rouspété à cause du /1, je l'ai supprimé (vous voyez que je suis un vrai geek), et j'ai obtenu ce que je donne en intro de ce message. De plus, je tiens à dire qu'il me semble que le tiret quadratin pourrait être avantageusement remplacé par l'expression tiretQuadratin id=58901:AI97 class=onTiretQuadratin lang=FR-fr/ qui a l'avantage d'être compatible.. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr -- Cordialement, Francescu GAROBY ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Outil de vérification des relations de type transports publics
Je goûte particulièrement cet humour, surtout quand il sert mes arguments (en faveur de la logique de la hache). Montre l'avion, l'imbécile regarde le doigt ! Ps : je laisse volontairement le message original -- Marc Sibert m...@sibert.fr Le 30 nov. 2012 08:15, Ista Pouss ista...@gmail.com a écrit : Heu... Philippe, je voulais surtout plaisanter avec cette histoire de tiret quadratin en XML, je m'excuse que ça n'ait pas été clair. C'était par rapport au flot de messages sur ce sujet, fort intéressant d'ailleurs, mais l'énormité des discussions pour un simple caractère me semblait propice à quelque humour ? Le mien semble maladroit, bon... Merci tout de même pour cette analyse critique du XML dans un champ name : comme je débute OSM, cela me permet de me faire une idée de ce qu'on peut faire et ne pas faire, ainsi que tout le débat sur le tiret quadratin d'ailleurs. Avec toutes mes excuses encore une fois. Le 30 novembre 2012 07:41, Philippe Verdy verd...@wanadoo.fr a écrit : Heuuu... du XML au milieu des champs name ??? Franchement non (même si le shéma OSM peut être exporté en XML, ce n'est définitivement pas la seule option. Voire du XML natif importé dans une base OpenGIS et supposer que les moteurs de rendus ou d'analyse devront en plus réanalyser du XML n'est pas une bonne idée). Les champs name=* ne doivent contenir que du texte destiné à être lu par un humain (la seule exception étant pour les langues qui ne satisfont pas du seul jeu de caractère codé dans leur écriture, comme les hiéroglyphes, et qui nécessitent un protocole supplémentaire pour les afficher sous forme lisible par l'homme. Et pourquoi tu penses que le tiret cadratin est juste franco-français ? Là où il est il n'a pas de langue attachée. On précise la langue dans les suffixes de code langue des clés OSM pour la valeur entière. Bref rien à voir. Un seul caractère suffit par lui-même ici, sans aucun autre protocole et sans supposer qu'il désigne une quelconque langue ou une orthographe (pas plus que la lettre a ne désigne pas autre chose que cette lettre mais pas les langues ou orthographes qui en font usage). En plus techniquement c'est bien plus compliqué à supporter (alors qu'il n'y a aucun soucis pour le rendu ou l'analyse et les recherches avec le seul caractère codé) et ta solution obligerait à modifier TOUS les outils actuels en dégradant sévèrement en plus leurs performances (une couche de parseur XML en plus, pour la moindre chaîne de libellé localisable et plus moyen de faire fonctionner les outils sans aucun parseur XML difficilement intégrable par exemple dans un moteur SQL, alors que les moteurs SQL font parfaitement de la recherche plein texte avec leur support des collations, alias UCA). Bref tu dis compatible, mais avec qui ou quoi ? Si c'est pour une seule appli particulière, c'est contre les fondements de la base de données OSM. Le 30 novembre 2012 07:02, Ista Pouss ista...@gmail.com a écrit : Pour moi la difficulté est maintenant de trouver l'ID d'une ligne ; j'ai lu ta page http://wiki.openstreetmap.org/wiki/Caen/Transports_en_communque tu as indiqué dans ton premier message, mais je n'ai pas compris comment je faisais pour trouver un ID avec ça. J'ai trouvé par chance une ligne de bus sur Caen, avec une relation route_master_bus et un ID de 2589274/1 (à http://osm.org/go/ervfqnf64-- ), mais ton logiciel a rouspété à cause du /1, je l'ai supprimé (vous voyez que je suis un vrai geek), et j'ai obtenu ce que je donne en intro de ce message. De plus, je tiens à dire qu'il me semble que le tiret quadratin pourrait être avantageusement remplacé par l'expression tiretQuadratin id=58901:AI97 class=onTiretQuadratin lang=FR-fr/ qui a l'avantage d'être compatible.. ___ 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
