Re: [OSM-talk-fr] Suppression des tirets cadratins
si je suis d'accord sur le principe, il reste possible aux tenants de la simplicité (et ça aussi c'est bien, mangez-en) d'utiliser des tirets simples partout, à condition de les encadrer d'espaces -- ou non -- selon le cas. On peut donc se contenter de : Champs-Élysées - Clemenceau Évidemment ! Il n’a jamais été question de contraindre ceux qui ne veulent ou ne peuvent pas à utiliser une typographie avancée. Mais, comme on est d’accord qu’une typographie avancée enrichi les données, il ne faut pas contraindre ceux qui le veulent et le peuvent à ne pas l’utiliser. Cordialement, -- Mikaël Cordon, mickey86 Le 29 novembre 2012 22:08, Jean-Francois Nifenecker jean-francois.nifenec...@laposte.net a écrit : Bonjour, Le 28/11/2012 18:29, te...@free.fr a écrit : Champs-Élysées — Clemenceau (avenue des Champs-Élysées, place Clemenceau) si je suis d'accord sur le principe, il reste possible aux tenants de la simplicité (et ça aussi c'est bien, mangez-en) d'utiliser des tirets simples partout, à condition de les encadrer d'espaces -- ou non -- selon le cas. On peut donc se contenter de : Champs-Élysées - Clemenceau A+ -- Jean-Francois Nifenecker, Bordeaux __**_ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.**org/listinfo/talk-frhttp://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Eurosha en République Centrafricaine, une premiere evaluation par les tuteurs souhaitee / Eurosha in CAR, hope for a first evaluation by the tutors
Salut, je viens de rentrer un ticket: http://trac.openstreetmap.fr/ticket/160 /Seb. 2012/11/20 Jocelyn Jaubert jocelyn.jaub...@gmail.com Le 19/11/2012 22:36, Sébastien Pierrel a écrit : Est-ce que du coup vous pourriez ajouter les pays où HOT est actif? Burundi, Tchad, CAR, Senegal, Haiti... Oui, c'est possible. Le plus rapide serait de me fournir la liste des pays, avec pour chaque pays: - le nom en anglais - si il y a un extract existant, son URL - sinon, l'ID d'une relation engloblante, et le continent où il se trouve (ou encore mieux, le région de premier niveau des extracts de Geofabrik) - c'est pour pouvoir générer les diffs et l'extract directement sur download.openstreetmap.fr - si possible, une estimation de la taille du .pbf. Après, le mieux serait que ça soit dans un ticket sur trac.openstreetmap.fr, pour faciliter le suivi :) -- Jocelyn ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr -- Cheers, /Seb. ___ 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
Merci à tous ! Merci pour les test, Merci pour les saisies de réseaux de Transport en Commun, Merci pour les retours, Merci à vous! Le 29/11/2012 23:15, Sylvain Maillard a écrit : bravo à l'équipe de 3Liz ! Le 29 novembre 2012 20:02, THEVENON Julien julien_theve...@yahoo.fr mailto: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 mailto:winner...@free.fr *À :* Discussions sur OSM en français talk-fr@openstreetmap.org mailto: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 http://www.nouslesgeeks.fr/ ___ Talk-fr mailing list Talk-fr@openstreetmap.org mailto:Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org mailto: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
2012/11/30 Mikaël Cordon mikael.cor...@gmail.com: Mais, comme on est d’accord qu’une typographie avancée enrichi les données, Bin non, il n'y a qu'un petit groupe qui tente de faire croire que c'est mieux avec que sans... Même les étrangers s'étonnent de la présence de ce caractère chez-nous (cf la mention de Sly). Si j'ai lancé la discussion, c'est parce que la solution préférée d'une infime minorité s'impose lentement et en silence à la majorité. Pieren ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Suppression des tirets cadratins
Bonjour, Je fais parti des silencieux. J'ai suivi ce fil de discussion. On ne peut pas forcer les gens à utiliser ce tiret, mais je ne comprends pas pourquoi on empêcherait leur utilisation, et je ne comprends pas du tout, mais alors vraiment pas du tout, pourquoi on les supprimerait. Stéphane ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Accès aux données eau du cadastre vectoriel
C'est quoi battle et wraith ? Je lis, mais je ne maitrise pas cette langue ! -- Marc Sibert m...@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
H tu te prends donc à utiliser la notation ASCII avec un double signe moins (même encadrés d'espaces). C'est une vieille notation anglophone qui effectivement remplace un unique tiret demi-cadratin. Le cadratin utilisant une succession de 3 ou 4 tirets ASCII. Et tu crois que c'est simple ? On a une base Unicode, et ces vieilles notations de l'ASCII (y compris - pour remplacer une vraie flèche) c'est du passé. Mais tu noteras quand même que tu as eu besoin de distinguer les tirets en les multipliant. On trouve depuis peu cette notation (avec des tirets simples réitérés comme dans nom1--nom2 pour distinguer de nom1-nom2 utilisé dans les noms composés inséparables) dans les fichiers INSEE de l'état-civil pour les noms de familles associant deux noms patronymiques avant mariage, uniquement parce que ces fichiers ne supportent pas Unicode encore aujourd'hui (ce qui ensuite se retrouve sur les passeports imprimés), ni même Windows-1252, mais juste ISO 8859-1 (pour garder les accents). L'INSEE a été critiquée pour cette décision (on peut comprendre qu'elle ait besoin d'enregistrer les romanisations pour un usage français, mais elle doit encore être capable de garder les orthographes originales (même si c'est du chinois, du grec, du cyrillique ou de l'arabe, car seuls ces noms sont non ambigus et réellement officiels) dans des champs séparés de celui consacré à la romanisation (mais tant qu'à faire, améliorer les outils pour que ces romanisations soient automatisées selon des règles émanant du pays d'origine et non selon ses propres règles, et de ne réserver les autres romanisations qu'aux seuls noms d'usage choisis et réellement enregistrés officiellement par le demandeur à l'INSEE). Mais on n'a aucune raison d'utiliser ces vieilles notations. La base Unicode est en Unicode pour supporter d'autres alphabets. Les outils qui ne savent ps lire l'Unicode ne pourront pas travailler sur les libellés en cyrillique ou en grec par exemple (ils devront utiliser de coûteuses et instables romanisations). Il n'y a aucun intérêt dans le cas de la base OSM. Les outils doivent s'adapter à l'Unicode pour gagner en stabilité. Ce n'est pas à a basse OSM de s'adapter à ces outils. Mais si ces outils confondent tous les tirets (simples, multiples, demi-cadratin, cadratin, voire aussi les flèches unidirectionnelles ou bidirectionelles) comme un seul tiret simple, ils génèrent des ambiguïtés et en prennent le risque. Mais doit-on aussi les confondre en introduisant volontairement ces ambiguités ? Les tirets simples de l'ASCII ont toujours été ambigus dans leur signification. OK si certains ne font pas la distinction ils peuvent saisir des tirets simples, ou des successions de tirets simples (et autres polygrammes pour les flèches), mais on ne doit pas interdire aux autres de corriger avec les bons caractères signifiants et non ambigus. Le 30 novembre 2012 09:30, Mikaël Cordon mikael.cor...@gmail.com a écrit : si je suis d'accord sur le principe, il reste possible aux tenants de la simplicité (et ça aussi c'est bien, mangez-en) d'utiliser des tirets simples partout, à condition de les encadrer d'espaces -- ou non -- selon le cas. On peut donc se contenter de : Champs-Élysées - Clemenceau Évidemment ! Il n’a jamais été question de contraindre ceux qui ne veulent ou ne peuvent pas à utiliser une typographie avancée. Mais, comme on est d’accord qu’une typographie avancée enrichi les données, il ne faut pas contraindre ceux qui le veulent et le peuvent à ne pas l’utiliser. Cordialement, -- Mikaël Cordon, mickey86 Le 29 novembre 2012 22:08, Jean-Francois Nifenecker jean-francois.nifenec...@laposte.net a écrit : Bonjour, Le 28/11/2012 18:29, te...@free.fr a écrit : Champs-Élysées — Clemenceau (avenue des Champs-Élysées, place Clemenceau) si je suis d'accord sur le principe, il reste possible aux tenants de la simplicité (et ça aussi c'est bien, mangez-en) d'utiliser des tirets simples partout, à condition de les encadrer d'espaces -- ou non -- selon le cas. On peut donc se contenter de : Champs-Élysées - Clemenceau A+ -- Jean-Francois Nifenecker, Bordeaux __**_ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.**org/listinfo/talk-frhttp://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Suppression des tirets cadratins
Le 30 novembre 2012 10:55, Stéphane Péneau stephane.pen...@wanadoo.fr a écrit : Bonjour, Je fais parti des silencieux. J'ai suivi ce fil de discussion. On ne peut pas forcer les gens à utiliser ce tiret, mais je ne comprends pas pourquoi on empêcherait leur utilisation, et je ne comprends pas du tout, mais alors vraiment pas du tout, pourquoi on les supprimerait. Cela permet d'avoir dans OSM des données homogènes. C'est pour cela qu'un choix a été fait sur les noms de rue, même si celui-ci ne respect pas les canons de telle ou telle académie, ils ont l'avantage d'être homogènes. Je pense qu'une même règle devrait être suivie sur les séparateurs, en indiquant clairement la règle du tiret seul (trait d'union) et du tiret avec espace (séparateur). Une minorité de contributeur maitrise les subtilités des tirets, cadratins et traits d'union pendant qu'une majorité de maitrise pas ces subtilités et contribuera avec de simples tirets du 6. Plus on a de mélange plus on doit adapter les algorithmes traitant les noms pour gérer ces subtilités, alors qu'à l'inverse, la mise en forme typographique peut se faire simplement en partant de tiret simples ou avec espaces. Voilà pourquoi je pense que l'on devrait en rester aux tirets avec ou sans espace et uniformiser dans ce sens pour favoriser l'homogénéité des données au détriment des subtilités typographiques plus ou moins franco-françaises (OSM est un projet international). -- Christian Quest - OpenStreetMap France - http://openstreetmap.fr/u/cquest ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
[OSM-talk-fr] Problème bâti ds lotissement
Bonjour à tous, Je rencontre un problème assez délicat ici http://www.openstreetmap.org/?lat=44.11903381347656lon=4.799241721630096zoom=18 J'ai demandé à ma collègue d'ajouter les numéros de voie à partir d'un plan qu'on avait et elle a malencontreusement déplacé des points correspondant au bâti. Est-il possible de corriger ces erreurs sans supprimer la création des points d'adresse ? Bonne journée à tous, -- View this message in context: http://gis.19327.n5.nabble.com/Probleme-bati-ds-lotissement-tp5738380.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] Suppression des tirets cadratins
On 30/11/2012 10:57, Philippe Verdy wrote: [..] Les tirets simples de l'ASCII ont toujours été ambigus dans leur signification. La liste des signes qu'ils remplacent est impressionnante : * Trait d'union/signe moins : - * Trait d'union conditionnel : - * Trait d'union : - * Trait d'union insécable : - * Tiret numérique : - * Tiret demi-cadratin : -- * Tiret cadratin : --- * Barre horizontale : -- * Puce trait d'union : ? * Signe moins : - * Signe moins minuscule : - Source : http://fr.wikipedia.org/wiki/Tiret L'embarras du choix - un vrai problème de riche. Et j'ai utilisé un tiret ASCII dans ma phrase précédente... Malédiction ! ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Nouvel éditeur spécialisé traduction
Le 30 novembre 2012 00:19, Emmanel Dewaele emmanuel.dewa...@gmail.com a écrit : 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. Cool ! Etant au niveau zéro sur git, il faudra me tenir la main pour mon premier push... Est-ce qu'il est raisonnable de créer les fichiers pour d'autres langues avec une traduction approximative ? BrunoC ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Problème bâti ds lotissement
peut-être bien en récupérant la liste de tous les points qui ont été modifiés, et en les restaurant dans leur version précédente ... qu'est-ce qui a été bougé exactement ? d'après http://www.openstreetmap.org/browse/node/2036324586/history je vois qu'elle a fait 2 changset sur les points adresse: un premier à leur création le 27, puis un 2ème le 30 qui a modifié la position de ce point ... donc un revert du changset du 30 (http://www.openstreetmap.org/browse/changeset/14095871) devrait remettre tous ces points à leur emplacement d'origine ! Sylvain Le 30 novembre 2012 11:13, Tony Emery tony.em...@yahoo.fr a écrit : Bonjour à tous, Je rencontre un problème assez délicat ici http://www.openstreetmap.org/?lat=44.11903381347656lon=4.799241721630096zoom=18 J'ai demandé à ma collègue d'ajouter les numéros de voie à partir d'un plan qu'on avait et elle a malencontreusement déplacé des points correspondant au bâti. Est-il possible de corriger ces erreurs sans supprimer la création des points d'adresse ? Bonne journée à tous, -- View this message in context: http://gis.19327.n5.nabble.com/Probleme-bati-ds-lotissement-tp5738380.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] Suppression des tirets cadratins
2012/11/30 Jean-Marc Liotier j...@liotier.org: Et je tiens à souligner encore une fois que dans les fichiers fournis par la RATP elle-même, ils ne s'embarrassent pas de tels caractères spéciaux ! +1 avec Christian sur l'homogénéité. On ne peut pas empêcher les gens de mettre le tiret qu'ils souhaitent. Mais il faut se mettre d'accord sur une règle commune, celle qui serait, par exemple, documentée dans le wiki. Ou, autre exemple, signalée comme erronée dans osmose si elle n'était pas respectée. Pieren ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Nouvel éditeur spécialisé traduction
Le jeudi 29 novembre 2012 15:19:31 Emmanel Dewaele a écrit : 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_MESSA GES/default.po L'outil Poedit peut aider pour cela. Bon j'ai devancé Bruno et un coup de Qt linguist plus loin voici le travail en pièce-jointe. Il y a un ou deux champs que je n'ai pas traduit et ya certainement quelques améliorations à faire. Ah oui, j'ai traduit way par chemin, j'aurai pu mettre polyligne ou je ne sais plus quoi !# SOME DESCRIPTIVE TITLE. # Copyright (C) YEAR THE PACKAGE'S COPYRIGHT HOLDER # This file is distributed under the same license as the PACKAGE package. # FIRST AUTHOR EMAIL@ADDRESS, YEAR. # msgid msgstr Project-Id-Version: PACKAGE VERSION\n Report-Msgid-Bugs-To: \n POT-Creation-Date: 2012-11-30 00:00+0100\n PO-Revision-Date: 2012-11-30 00:02+0100\n Last-Translator: Emmanuel Dewaele emmanuel.dewa...@gmail.com\n Language-Team: \n Language: \n MIME-Version: 1.0\n Content-Type: text/plain; charset=UTF-8\n Content-Transfer-Encoding: 8bit\n X-Poedit-Language: French\n Plural-Forms: nplurals=2; plural=(n 1);\n X-Language: fr_FR\n X-Source-Language: C\n #: index.php:94 #, fuzzy msgid To save changes in OSM database you have to be authenticated at osm.org. msgstr Pour sauvegarder les modifications dans la base de données OSM vous devez vous authentifier. #: index.php:95 #, fuzzy msgid After authentification you'll be redirected back here. msgstr Après l'authentification vous serez redirigé ici. #: index.php:97 #, fuzzy msgid Choose a place msgstr Choisir un lieu #: index.php:98 index.php:127 msgid Preferences msgstr Préférences #: index.php:100 #, fuzzy msgid Map msgstr Lieu #: index.php:101 #, fuzzy msgid Choose the map layer msgstr Choisir la couche #: index.php:104 msgid Toolserver localised maps msgstr #: index.php:112 #, fuzzy msgid Preferred language msgstr Langue préférée #: index.php:114 #, fuzzy msgid When editing a place, add automically a field for translating into this language msgstr Lors de l'édition d'un lieu, ajouter automatiquement un champ pour traduire dans cette langue #: index.php:122 #, fuzzy msgid Login with OSM msgstr Connecté à OSM #: index.php:132 msgid (verb, latin) msgstr (verbe, latin) #: index.php:132 #, fuzzy msgid I name msgstr ! nom #: index.php:135 #, fuzzy msgid Find Places msgstr Trouver un lieu #: index.php:136 #, fuzzy msgid Translate msgstr Traduire #: index.php:137 #, fuzzy msgid View changes msgstr Voir les modifications #: index.php:138 #, fuzzy msgid Documentation msgstr Documentation #: index.php:142 #, fuzzy msgid Find by name msgstr Trouver un nom #: index.php:143 #, fuzzy msgid OSM Object msgstr Objet OSM #: index.php:148 index.php:162 #, fuzzy msgid Search msgstr Chercher #: index.php:152 #, fuzzy msgid Right-click the map to select places msgstr Clic-droit sur la carte pour selectionner un lieu #: index.php:157 #, fuzzy msgid Node msgstr Nœud #: index.php:158 #, fuzzy msgid Way msgstr Chemin #: index.php:159 #, fuzzy msgid Relation msgstr Relation #: index.php:168 #, fuzzy msgid Names msgstr Noms #: index.php:168 jsstrings.php:18 #, fuzzy msgid Save msgstr Enregistrer #: index.php:171 #, fuzzy msgid Name msgstr Nom #: index.php:184 #, fuzzy msgid Add translation msgstr Ajouter traduction #: index.php:185 index.php:188 #, fuzzy msgid Set old name msgstr Définir l'ancien nom #: index.php:186 #, fuzzy msgid Set alternative name msgstr Définir un nom alternatif #: index.php:187 #, fuzzy msgid Set official name msgstr Définir le nom officiel #: index.php:190 #, fuzzy msgid Other tags msgstr Autres informations #: index.php:190 #, fuzzy msgid (View OSM Object) msgstr (Voir l'objet OSM) #: index.php:196 #, fuzzy msgid Changes msgstr Modifications #: index.php:197 #, fuzzy msgid Submit changes msgstr Publier les modifications #: index.php:198 #, fuzzy msgid Download OSM file msgstr Télécharger le fichier OSM #: jsstrings.php:8 msgid Authenticate msgstr S'authentifier #: jsstrings.php:9 msgid Cancel msgstr Annuler #: jsstrings.php:10 #, fuzzy msgid Choose msgstr Choisir #: jsstrings.php:11 #, fuzzy msgid This language is already in use msgstr Cette langue est déjà définie #: jsstrings.php:12 #, fuzzy msgid Error while loading places msgstr Erreur lors du chargement du lieu #: jsstrings.php:13 #, fuzzy msgid Error saving user preferences msgstr Erreur lors de l'enregistrement des préférences de l'utilisateur #: jsstrings.php:14 #, fuzzy msgid Error while retrieving OSM object msgstr Erreur lors de la récupération de l'objet OSM #: jsstrings.php:15 #, fuzzy msgid Error while saving object msgstr Erreur lors de l'enregistrement de l'objet #: jsstrings.php:16 #, fuzzy msgid Error while submitting changes msgstr Erreur lors de l'envoi des modifications #: jsstrings.php:17 msgid Revert msgstr #:
Re: [OSM-talk-fr] Problème bâti ds lotissement
pour moi, il y en a d'autres : http://www.openstreetmap.org/browse/changeset/14095871 http://www.openstreetmap.org/browse/changeset/14084389 http://www.openstreetmap.org/browse/changeset/14057308 http://www.openstreetmap.org/browse/changeset/14060719 http://www.openstreetmap.org/browse/changeset/14075135 http://www.openstreetmap.org/browse/changeset/14073401 http://www.openstreetmap.org/browse/changeset/14058896 -- View this message in context: http://gis.19327.n5.nabble.com/Probleme-bati-ds-lotissement-tp5738380p5738397.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] Accès aux données eau du cadastre vectoriel
Il est possible d'utiliser l'outil de conversion depuis le cadastre à la maison également. Voir le wiki. Frédéric. Le 30 novembre 2012 10:57, Marc SIBERT m...@sibert.fr a écrit : C'est quoi battle et wraith ? Je lis, mais je ne maitrise pas cette langue ! -- Marc Sibert m...@sibert.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
Salut, Et je tiens à souligner encore une fois que dans les fichiers fournis par la RATP elle-même, ils ne s'embarrassent pas de tels caractères spéciaux ! pour ma part ça n'est pas une excuse : je ne pense pas qu'on puisse s'appuyer sur un seul mauvais exemple pour en tirer des généralités. C'est comme de dire que si certains écrivent en langage sms, alors on a pas de raison de mettre des mots entiers ... +1 avec Christian sur l'homogénéité. On ne peut pas empêcher les gens de mettre le tiret qu'ils souhaitent. Mais il faut se mettre d'accord sur une règle commune, celle qui serait, par exemple, documentée dans le wiki. Ou, autre exemple, signalée comme erronée dans osmose si elle n'était pas respectée. totalement d'accord sur l'homogénéité, notamment sur le tag name, encore que si on travaille bien en unicode il n'y a normalement pas de problèmes. Par contre je rejoins la proposition qui a été faite de ne pas se restreindre aux caractères ascii dans le tag name:fr ! Est-ce que quelqu'un sais quel est le consensus officiel pour les autres pays avec des particularités de caractères/typologie, notamment les alphabets différents ? Sylvain ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Suppression des tirets cadratins
Encore une fois la question de lhomogénéité ne se pose pas ici sur les tirets et surtout pas dans les noms. Contrairement à la casse des lettres qui est un critère discriminant dans les recherches, il n'est pas discriminant dans les recherches. Quant au rendu je ne vois pas ce qui te choque, ton critère est uniquement basé sur un apriori de rendu homogène qui en l'occurence ici n'est même pas gênant. Ton argument c'est de taguer pour les rendu (pour le rendre homogène). En plus tu continues à perpétuer l'idée (fausse) que ce n'est QUE de la typographie de présentation alors que la distinction est sémantique et qu'il n'y a PAS de règle typographique autorisant de changer les tirets automatiquement de l'un à l'autre (et j'ai donné des exemples). En revanche un même moteur de rendu pourra toujours, s'il ne sait pas les afficher pour les distinguer, les uniformiser, mais l'inverse, NON, il ne le fera JAMAIS car il ne saura PAS le faire correctement (ce ne sera qu'une heuristique). Si je suis ton idée, ce moteur qui tenterait ce type de rendu heuristique remplacera Bruxelles - Brussels par Bruxelles — Brussels et ce sera faux ! C'est la même ville, pas deux. Ton idée est du même ordre que l'idée de corriger automatiquement l'orthographe au rendu, et donc de remplacer lors du rendu tous les saint par des Saint, toutes les rue par des Rue, tous les St par des Saint (ou des Street). Aucun moteur de rendu ne doit faire ce genre d'approximation. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Suppression des tirets cadratins
Le 30 novembre 2012 12:17, Sylvain Maillard sylvain.maill...@gmail.com a écrit : Salut, Et je tiens à souligner encore une fois que dans les fichiers fournis par la RATP elle-même, ils ne s'embarrassent pas de tels caractères spéciaux ! pour ma part ça n'est pas une excuse : je ne pense pas qu'on puisse s'appuyer sur un seul mauvais exemple pour en tirer des généralités. C'est comme de dire que si certains écrivent en langage sms, alors on a pas de raison de mettre des mots entiers ... Oui, c'est sûrement pas un exemple... surtout quand une partie des libellés ne sont qu'en majuscule, on retourne aux limbes de l'ASCII 7bits... +1 avec Christian sur l'homogénéité. On ne peut pas empêcher les gens de mettre le tiret qu'ils souhaitent. Mais il faut se mettre d'accord sur une règle commune, celle qui serait, par exemple, documentée dans le wiki. Ou, autre exemple, signalée comme erronée dans osmose si elle n'était pas respectée. Je précise au sujet de l'homogénéité, c'est d'homogénéité des données dont je parle. Pour le rendu, on peut retraiter si l'on veut remplacer ces espace-tiret-espace par le cadratin de son choix bien plus facilement que l'inverse vu la liste impressionnante des différents tirets donnée par Jean-Marc (qui les connaisait tous ?). Sur le fait que ces caractères pourraient servir à décrire le lien entre les différentes parties composant le libellé, je pense que c'est une erreur. Si il y a un lien logique entre des noms, il devrait provenir de données structurées et pas de l'analyse d'un texte. C'est d'ailleurs pour ça que je trouve sans intérêt les name mis sur les limites administratives car tout ceci se trouve dans la structure des données (le seul intérêt est le confort dans l'éditeur... éditeur qu'il suffirait d'améliorer sur ce point, parce que là on est le tagguer pour le confort dans l'éditeur). totalement d'accord sur l'homogénéité, notamment sur le tag name, encore que si on travaille bien en unicode il n'y a normalement pas de problèmes. Par contre je rejoins la proposition qui a été faite de ne pas se restreindre aux caractères ascii dans le tag name:fr ! Est-ce que quelqu'un sais quel est le consensus officiel pour les autres pays avec des particularités de caractères/typologie, notamment les alphabets différents ? Il n'y a rien de précisé dans le wiki. http://wiki.openstreetmap.org/wiki/Names -- Christian Quest - OpenStreetMap France - http://openstreetmap.fr/u/cquest ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Suppression des tirets cadratins
Le 30/11/2012 11:11, Christian Quest a écrit : Cela permet d'avoir dans OSM des données homogènes. C'est pour cela qu'un choix a été fait sur les noms de rue, même si celui-ci ne respect pas les canons de telle ou telle académie, ils ont l'avantage d'être homogènes. Mouais... le choix sur les noms de rue est typographique, ce qui n'est pas le cas ici. Enfin bon, je ne vais pas m'impliquer dans cette discussion, ça me passe largement au-dessus, j'ai juste répondu en tant que silencieux et fervent utilisateur des É, È etc.. ce dont ne s’embarrassent pas de nombreux services administratifs qui écorchent donc mon nom de famille. Stéphane PÉNEAU Je pense qu'une même règle devrait être suivie sur les séparateurs, en indiquant clairement la règle du tiret seul (trait d'union) et du tiret avec espace (séparateur). Une minorité de contributeur maitrise les subtilités des tirets, cadratins et traits d'union pendant qu'une majorité de maitrise pas ces subtilités et contribuera avec de simples tirets du 6. Plus on a de mélange plus on doit adapter les algorithmes traitant les noms pour gérer ces subtilités, alors qu'à l'inverse, la mise en forme typographique peut se faire simplement en partant de tiret simples ou avec espaces. Voilà pourquoi je pense que l'on devrait en rester aux tirets avec ou sans espace et uniformiser dans ce sens pour favoriser l'homogénéité des données au détriment des subtilités typographiques plus ou moins franco-françaises (OSM est un projet international). ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Suppression des tirets cadratins
On 30/11/2012 12:32, Christian Quest wrote: Je précise au sujet de l'homogénéité, c'est d'homogénéité des données dont je parle. Pour le rendu, on peut retraiter si l'on veut remplacer ces espace-tiret-espace par le cadratin de son choix bien plus facilement que l'inverse vu la liste impressionnante des différents tirets donnée par Jean-Marc (qui les connaisait tous ?). Je n'en connaissais pas la moitié... Mais ne prenons pas mon ignorance comme référence - tirons plutôt le niveau vers le haut ! Sur le fait que ces caractères pourraient servir à décrire le lien entre les différentes parties composant le libellé, je pense que c'est une erreur. Si il y a un lien logique entre des noms, il devrait provenir de données structurées et pas de l'analyse d'un texte. C'est d'ailleurs pour ça que je trouve sans intérêt les name mis sur les limites administratives car tout ceci se trouve dans la structure des données (le seul intérêt est le confort dans l'éditeur... éditeur qu'il suffirait d'améliorer sur ce point, parce que là on est le tagguer pour le confort dans l'éditeur) Je suis d'accord sur ce point. Je vois régulièrement des référentiels où des attributs contiennent des valeurs concaténées... Ca se termine toujours dans les larmes : s'il y a plusieurs valeurs alors il doit y avoir plusieurs attributs et non pas un attribut composite dont la structure ne sera pas universellement respectée et donc les valeur ne répercuteront pas les modifications des attributs qu'elles ont copié lors de la création. Mais ça n'est néanmoins pas un argument contre l'usage sémantique des ponctuations - juste un argument contre l'extension anarchique des modèles par l'usage des ponctuations comme séparateurs internes aux attributs. Je persiste à penser que name pourrait être le plus petit dénominateur commun technique et que name:fr pourrait être le champ libre à l'expression de nos particularismes linguistiques... Mais c'est probablement aussi parce que ce n'est pas moi qui écrit les analyseurs syntaxiques... ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Nouvel éditeur spécialisé traduction
Le 27 nov. 2012 à 22:04, Emmanel Dewaele a écrit : Je vous présente Nomino, un modeste éditeur de données OpenStreetMap, dédié à la traduction des noms de lieux en différentes langues. Nomino en quelques points: - Une application web, sans installation et utilisable sur toutes plateformes (même si pour l'heure ça donne moyen sur téléphone et tablette) - Une application simple: l'interface se veut dépouillée et utilisable par des contributeurs débutants sans lecture de documentation préalable - Une application efficace: au lieu d'ouvrir toutes les données sur une zone, comme le font classiquement JOSM et Potlatch, on ne charge que certains objets individuellement pour éditer les tags de type name:**. Même on peut déjà s'identifier sur osm.org et d'enregistrer les modifications, l'éditeur est en version alpha, testez le à vos risques et périls. Un scénario de test: dans la boite Preferences, cliquer sur Toolserver localised maps puis choisir fr (French) dans le menu. La carte s'affiche avec les noms de lieux traduits en français, et donc des noms de lieux non traduits. Si on va par exemple en Russie ou en Ukraine, on trouve beaucoup de villes dont la forme française n'est pas renseignée, il suffit d'ouvrir l'objet et d'entrer le nom de la ville en français. On peut le trouver assez facilement par Wikipédia, en cherchant le nom de la ville dans la langue locale. L'application: http://nomino.comptoir.net Le code source: http://gitorious.org/nomino/nomino Merci beaucoup à Cyrille Giquello et sa superbe bibliothèque pour l'accès à l'API OpenStreetmap: https://github.com/Cyrille37/yapafo Je mets en copie sur la liste Bretagne. J'ai essayé Nomino pour insérer le nom en breton de quelques Etats . C'est facile à faire. L'application est intéressante pour ceux qui souhaitent mettre des toponymes en langue régionale, mais, elle ne concerne apparemment que le niveau des communes et au-dessus. Les hameaux sont affichés sur la carte et ils sont listés, mais, on a un message invalid object quand on clique sur le nom. Petite déception, car, je n'ai pu mettre les adaptations/traductions normalisées en breton de l'Office public de la langue bretonne. Est-ce que c'est prévu? Christian Rogel ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Nouvel éditeur spécialisé traduction
Nolwenn DOUCET wrote Le jeudi 29 novembre 2012 15:19:31 Emmanel Dewaele a écrit : 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_MESSA GES/default.po L'outil Poedit peut aider pour cela. Bon j'ai devancé Bruno et un coup de Qt linguist plus loin voici le travail en pièce-jointe. Il y a un ou deux champs que je n'ai pas traduit et ya certainement quelques améliorations à faire. Ah oui, j'ai traduit way par chemin, j'aurai pu mettre polyligne ou je ne sais plus quoi ! ___ Talk-fr mailing list Talk-fr@ http://lists.openstreetmap.org/listinfo/talk-fr locale_fr_FR.utf8_LC_MESSAGES_default.po (5K) lt;http://gis.19327.n5.nabble.com/attachment/5738396/0/locale_fr_FR.utf8_LC_MESSAGES_default.pogt; Bonjour, Merci beaucoup. Je viens de relire le fichier, ça a l'air très bien. La traduction sera mise en place ce soir. Pour répondre à la question de BrunoC, c'est une bonne idée, mais c'est bien de faire relire par un natif ensuite. -- View this message in context: http://gis.19327.n5.nabble.com/Nouvel-editeur-specialise-traduction-tp5737914p5738415.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
Merci, cela a bien marché avec 2310565 ! Et merci aussi de m'avoir fait découvrir la relation route_master :-) Maintenant, peut être, une... GUI ? Ça serait pas mal, ou alors préférez-vous vous spécialiser dans la ligne de commande ? Ou comme plug-in de Josm ? Ou comme règle d'osmose ? Ou rien ? Ou tout ? Le 30 novembre 2012 08:26, Francescu GAROBY windu...@gmail.com a écrit : 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 ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Suppression des tirets cadratins
On a des aberrations similaires dans OSM concernant les articles définis quand c'est la première lettre : normalement il n'y a aucune majuscule, juste une capitale conditionnelle qui n'apparait qu'en début de phrase, ces articles définis restant remplaçables/contractables grammaticalement comme pour le Mans et non Le Mans) car on écrit «Aller de Paris au Mans » (disparition du mot Le qui ne fait pas partie du nom propre, c'est un article défini commun). L'IGN fait attention à ça, regardez ses cartes, notamment pour les nombreux lieux-dits, et même l'INSEE dans sa base des noms de communes où les articles communs sont spécifiés à part et même codifiés), mais OSM s'en fout et confond tout. Si vous supposez qu'on peut librement rétablir les minuscules ou faire des contractions contextuellement chaque fois qu'on veut insérer dans une phrase un toponyme mal écrit dans OSM et commençant par « Le », « La », « Les », « L’ », « Els », « Los », etc. vous vous trompez car ce sont aussi des noms propres utilisés comme toponymes ou odonymes invariables (le Le est une rivière) ! Regardez le fichier de définition de l'INSEE pour la liste des articles codés à part pour les noms de collectivités locales et divisions administratives. On a même Osmose qui prétend (complètement à tord) que c'est « mieux » de faire cette confusion des majuscules et des capitales, et indique une prétendue « erreur » : - la majuscule est lexicale et invariable typographiquement, - la capitale est typographique mais imposée seulement par convention typographique et orthographique et uniquement de façon conditionnelle en début de phrase, la lettre restant lexicalement une minuscule même si elle est transcrite par une capitale). Oui mais là encore Osmose se base sur un prétendu critère d'homogénéité (taguer pour le rendu) parce beaucoup ne connaissent pas la différence entre une majuscule et une capitale et se trompent sans arrêt. On perd tout l'intérêt d'une base de données, et on se retrouve à insérer dans des documents des aberrations orthographiques comme « Ce train part **de Le** Mans et va à Paris » (incorrect) au lieu de « Ce train part **du** Mans et va à Paris » (correct), puisqu'on ne sait pas ce qui fait partie du nom propre ou pas. Si Osmose devait dire quelque chose, ce serait signaler que le premier mot « Le » dans le nom français (ou dans un name par défaut situé dans un pays ou une région officiellement francophone) est très probablement un article défini qui s'écrit en minuscule (ce serait vrai la plupart du temps, mais avec quelques exceptions dont il doit aussi tenir compte même s'il les signale une fois) et non raconter n'importe quoi en affirmant l'inverse. (Beaucoup aussi ne connaissent pas la différence entre une majuscule et une minuscule, et les mélange sans sourciller; beaucoup ne connaissent pas non plus la règle orthographique des toponymes français avec des traits d'union et non des espaces, sauf quelques exceptions de toponymes bien connus comme les Pays de la Loire ou le Territoire de Belfort, qui en fait ne sont pas réellement des toponymes au sens géographique, mais des noms administratifs officiels de collectivités locales, compétentes sur un territoire donné). Pourtant la mission d'OSM est aussi éducative et doit promouvoir les usages corrects les plus précis, et non pas entretenir les imprécisions et approximations (même si elles sont courantes). Le 30 novembre 2012 12:42, Stéphane Péneau stephane.pen...@wanadoo.fr a écrit : Le 30/11/2012 11:11, Christian Quest a écrit : Cela permet d'avoir dans OSM des données homogènes. C'est pour cela qu'un choix a été fait sur les noms de rue, même si celui-ci ne respect pas les canons de telle ou telle académie, ils ont l'avantage d'être homogènes. Mouais... le choix sur les noms de rue est typographique, ce qui n'est pas le cas ici. Enfin bon, je ne vais pas m'impliquer dans cette discussion, ça me passe largement au-dessus, j'ai juste répondu en tant que silencieux et fervent utilisateur des É, È etc.. ce dont ne s’embarrassent pas de nombreux services administratifs qui écorchent donc mon nom de famille. Stéphane PÉNEAU Je pense qu'une même règle devrait être suivie sur les séparateurs, en indiquant clairement la règle du tiret seul (trait d'union) et du tiret avec espace (séparateur). Une minorité de contributeur maitrise les subtilités des tirets, cadratins et traits d'union pendant qu'une majorité de maitrise pas ces subtilités et contribuera avec de simples tirets du 6. Plus on a de mélange plus on doit adapter les algorithmes traitant les noms pour gérer ces subtilités, alors qu'à l'inverse, la mise en forme typographique peut se faire simplement en partant de tiret simples ou avec espaces. Voilà pourquoi je pense que l'on devrait en rester aux tirets avec ou sans espace et uniformiser dans ce sens pour favoriser l'homogénéité des données au détriment des subtilités typographiques plus ou moins franco-françaises (OSM
Re: [OSM-talk-fr] Outil de vérification des relations de type transports publics
Le 30 novembre 2012 13:26, Ista Pouss ista...@gmail.com a écrit : Merci, cela a bien marché avec 2310565 ! Et merci aussi de m'avoir fait découvrir la relation route_master :-) De rien :-) Maintenant, peut être, une... GUI ? Ça serait pas mal, ou alors préférez-vous vous spécialiser dans la ligne de commande ? Ou comme plug-in de Josm ? Ou comme règle d'osmose ? Ou rien ? Ou tout ? Ou... je sais pas encore ? Dans l'immédiat, je vais me concentrer sur le mode ligne de commandes, car c'est le plus simple, préférant me concentrer sur le code de validation proprement dit. Francescu Le 30 novembre 2012 08:26, Francescu GAROBY windu...@gmail.com a écrit : 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 ___ 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
Le 30 novembre 2012 12:48, Jean-Marc Liotier j...@liotier.org a écrit : Je persiste à penser que name pourrait être le plus petit dénominateur commun technique et que name:fr pourrait être le champ libre à l'expression de nos particularismes linguistiques... Mais c'est probablement aussi parce que ce n'est pas moi qui écrit les analyseurs syntaxiques... Est-ce que ça vaut vraiment le coup/coût de renseigner deux noms, un name=* technique qui n'a PAS cette vocation, et un name:fr juste parce que le name:fr aurait un tiret cadratin (d'autres langues aussi en font usage largement, ce n'est pas un particularisme linguistique franco-français). Je ne vois pas de plut petit dénominateur commun technique justifié même pour ce caractère qui ne pose aucun problème technique, ce qui ne justifie donc pas de définir les deux name=* et name:fr;* différemment alors qu'ils sont de toute façon tous les deux en français et n'ont aucune raison linguistique d'être différents. Si name=* existe c'est pour offrir aux autres langues aussi un nom qu'ils peuvent utiliser, à défaut pour ces langues de définir leur propre nom différent. Cela permet donc à des centaines de langues d'utiliser le nom français tel qu'il est sans avoir à surcharger OSM de centaines de copies identiques du nom français en valeur des centaines de name:code-langue=* possibles. Maintenant name=* n'indique pas de quelle(s) langue(s) vient ce nom, à moins qu'on le copie à **l'identique** dans name:fr (et dans les name:langue=* qui effectivement ont un usage avéré de ce nom dans la même orthographe). Ce qui voudra alors dire qu'on devra renseigner TOUTES les langues possibles dans OSM pour TOUS les noms, et alors se passer totalement de name=*; si une langue manque, on aura une erreur et plus rien à afficher du tout (ou pire on affichera le nom défini dans une seule langue arbitraire : l'anglais (britannique), ce qui voudra dire que name:en=* ne sert plus à rien et que name=* veut dire le nom en anglais). Le choix d'OSM a été de permettre justement de ne pas utiliser l'anglais partout dans le monde comme seule langue apparaissant par défaut sur les cartes, pour que justement name=* puisse être un nom exprimé dans une **ou plusieurs** des langues officielles parlées dan un lieu donné. Moi je veux bien alors qu'on supprime les tirets simples utilisés dans ce cas (name=Bruxelles - Brussels) mais alors il FAUT aussi éliminer name=* et le remplacer par name:local_langs=* prenant en valeur une liste de code langues (qui devraient donc être tous définis)... Alors au lieu de renseigner seulement un seul name=Xxxx avec un nom en français , on devra renseigner systématiquement name:local_langs=fr et name:fr=X. Pour Bruxelles (c'est un exxemple), cela donnera name:local_langs=fr;nl (mais aucune autre langue!), name:fr=Bruxelles, name.nl=Brussels, auxquels on pourra encore avoir d'autres name:code=* pour les autres traductions hors du français et du néerlandais. Alors si on affiche une carte en français, on n'affichera QUE le nom français, si on affiche une carte en néerlandais, on n'affichera QUE le nom néerlandais, et pour les cartes dans toutes les autres langues on affichera les deux noms français et néerlandais (sans choisir), SAUF si une langue a fait un choix explicite ou mentionné une orthographe ou translitération qui lui est propre (name:en=Brussels affiche bien le nom anglais qui est le même que le nom néerlandais, name:ru= affichera un nom translitéré en cyrcillique propre aux conventions russes de translitération, ou bien un autre nom russe consacré mais dans les deux cas russes ce ne seront pas des noms officiels, les seuls noms officiels étant ceux renseignés dans les langues indiquées par name:local_lanfs=fr;nl, donc les noms en français ou néerlandais) SI ET SEULEMENT SI une proposition similaire devenait la norme partout dans OSM, (je pense qu'un tel changement massif n'aura jamais lieu dans OSM, d'autant plus que cela oblige à modifier TOUS les outils pour changer leur logique de sélection des langues à saisir ou à afficher) ALORS SEULEMENT, il n'y a plus d'ambiguïté avec l'autre signification de - comme séparateur de noms (entre deux entités différentes de même nature liées ou séparés par l'objet tagué), ce que voulait justement marquer le tiret cadratin. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Suppression des tirets cadratins
Pourquoi veux-tu que OSM se limite aux cartes ? OSM c'est une base de données, pas une carte. Les cartes c'est du domaine du rendu. OSM a bien d'autres usages comme la possibilité d'utiliser la base comme source d'informations pour composer toutes sortes de documents avec des inclusions dans le texte d'une partie de ces données, avec des liens hypertextes possibles vers des rendus cartographiques très divers, ou pas de carte du tout, par exemple dans des tableaux de données, où le nom ne sera pas non plus nécessairement le premier élément affiché dans une cellule). Bref le CNIG ne touche qu'au rendu des cartes, rien d'autre. Le 30 novembre 2012 14:05, Plop76 vaujani...@free.fr a écrit : Philippe Verdy a écrit : On a des aberrations similaires dans OSM concernant les articles définis quand c'est la première lettre : normalement il n'y a aucune majuscule, juste une capitale conditionnelle qui n'apparait qu'en début de phrase, ces articles définis restant remplaçables/contractables grammaticalement comme pour le Mans et non Le Mans) car on écrit «Aller de Paris au Mans » (disparition du mot Le qui ne fait pas partie du nom propre, c'est un article défini commun). Sur les cartes, il s'agit pourtant bien de débuts de phrases (nominales), comme l'indique la charte du CNIG : «en application de l’observation générale introductive, la question de la majuscule du premier élément d’un toponyme ne se pose pas pour une inscription toponymique sur une carte ou sur un panneau indicateur, où elle est occultée par la majuscule de début de phrase (phrases nominales dans ces cas).» Et même hors le cas des début de phrase, le CNIG recommande la majuscule à l'article initial. __**_ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.**org/listinfo/talk-frhttp://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Suppression des tirets cadratins
Ce qui veut dire que le CNIG ne dit PAS que ces articles prennent la majuscule (c'est faux), mais la capitale initiale, Tu confond toi aussi majuscule (sémantique et lexicale) et capitale (typographique et contextuelle). ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Suppression des tirets cadratins
En français, et même d'une façon générale dans TOUTES les langues à écriture bicamérale comme l'alphabet latin, les minuscules et majuscules sont TOUTES invariables. En revanche il y a plusieurs casses typographiques: minuscules, capitales, petites capitales, grandes minuscules, et grandes capitales (et quelques autres dans d'autres écritures multicamérales voir même monocamérales, un cas particulier étant les styles d'écriture géorgiens mkedruouli, mtassotavoulo, tassotavrouli, mélangeant en fait plusieurs alphabets *distincts* monocaméraux...). - la minuscule (lexicale et invariable) peut alors devenir typographiquement : une minuscule (typographique), une petite capitale ; ou encore une capitale ou une grande capitale (autorisés seulement en début de phrase en français, ou pour certains mots des titres en anglais) ; mais jamais une grande minuscule - la majuscule (lexicale et invariable) peut alors devenir typographiquement : uniquement une majuscule, ou une grande minuscule (ce style est désuet, il est encore utilisé dans d'autres écritures que l'écriture latine), ou une grande capitale (utilisé uniquement dans le style petite capitales pour les minuscules lexicales) A cela s'ajoutent encore divers autres styles typographiques qui complètent les styles de casse précédents : ancien style pour les nombres, chasse fixe ou variable, italiques, exposants et indices. Le 30 novembre 2012 14:14, Philippe Verdy verd...@wanadoo.fr a écrit : Ce qui veut dire que le CNIG ne dit PAS que ces articles prennent la majuscule (c'est faux), mais la capitale initiale, Tu confond toi aussi majuscule (sémantique et lexicale) et capitale (typographique et contextuelle). ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Suppression des tirets cadratins
Je me suis planté en tapant les noms des alphabets géorgiens mais peu importe ici. Le 30 novembre 2012 14:29, Philippe Verdy verd...@wanadoo.fr a écrit : En français, et même d'une façon générale dans TOUTES les langues à écriture bicamérale comme l'alphabet latin, les minuscules et majuscules sont TOUTES invariables. En revanche il y a plusieurs casses typographiques: minuscules, capitales, petites capitales, grandes minuscules, et grandes capitales (et quelques autres dans d'autres écritures multicamérales voir même monocamérales, un cas particulier étant les styles d'écriture géorgiens mkedruouli, mtassotavoulo, tassotavrouli, mélangeant en fait plusieurs alphabets *distincts* monocaméraux...). - la minuscule (lexicale et invariable) peut alors devenir typographiquement : une minuscule (typographique), une petite capitale ; ou encore une capitale ou une grande capitale (autorisés seulement en début de phrase en français, ou pour certains mots des titres en anglais) ; mais jamais une grande minuscule - la majuscule (lexicale et invariable) peut alors devenir typographiquement : uniquement une majuscule, ou une grande minuscule (ce style est désuet, il est encore utilisé dans d'autres écritures que l'écriture latine), ou une grande capitale (utilisé uniquement dans le style petite capitales pour les minuscules lexicales) A cela s'ajoutent encore divers autres styles typographiques qui complètent les styles de casse précédents : ancien style pour les nombres, chasse fixe ou variable, italiques, exposants et indices. Le 30 novembre 2012 14:14, Philippe Verdy verd...@wanadoo.fr a écrit : Ce qui veut dire que le CNIG ne dit PAS que ces articles prennent la majuscule (c'est faux), mais la capitale initiale, Tu confond toi aussi majuscule (sémantique et lexicale) et capitale (typographique et contextuelle). ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Suppression des tirets cadratins
Dans son message précédent, Philippe Verdy a écrit : Pourquoi veux-tu que OSM se limite aux cartes ? OSM c'est une base de données, pas une carte. Les cartes c'est du domaine du rendu. OSM a bien d'autres usages comme la possibilité d'utiliser la base comme source d'informations pour composer toutes sortes de documents avec des inclusions dans le texte d'une partie de ces données, avec des liens hypertextes possibles vers des rendus cartographiques très divers, ou pas de carte du tout, par exemple dans des tableaux de données, où le nom ne sera pas non plus nécessairement le premier élément affiché dans une cellule). Bref le CNIG ne touche qu'au rendu des cartes, rien d'autre. Ils s'occupent de l'information géographique :D Ils font justement la distinction entre les cartes (où la majuscule est de toute façon due au début de phrase) et le cas général. Pour le cas général, ils recommandent : «Dans un toponyme (quel que soit son mode de composition), ou dans un nom de territoire politique ou administratif composé par jonction par des traits d’union, prennent la majuscule : [...] - l’article initial s’il n’est pas contracté avec à ou de le précédant (La Rochelle, Le Puy, Le Havre, la municipalité du Touquet et non de Le Touquet, aller au Mans et non à Le Mans [DAF, « le »] au lieudit « La Fourche », « Le Cheval mort » [DAF, « lieudit »]). » Et concernant l'IGN : «Ainsi, dans les toponymes officieux, l’IGN et le SHOM omettent actuellement les traits d’union et l’IGN la majuscule à l’article initial. Cette exception s’apparente à l’usage de signes typographiques comme la couleur des caractères, la police italique ou le corps des caractères» ;-) ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Suppression des tirets cadratins
Très bien, il mentionne « l’article initial s’il n’est pas contracté avec à ou de » et suppose qu'on puisse reconnaitre qu'il s'agit d'un article (cela oblige à en garder la trace dans une base de données. Et le CNIG se place dans le cadre de la « composition », ce qui de fait exclue le cas « base de données » qui doit préserver cette différence d'une façon ou d'une autre. La base de données a bien vocation à garder les différences lexicales, ce n'est pas le contexte de la composition dont parle le CNIG. Le 30 novembre 2012 14:31, Plop76 vaujani...@free.fr a écrit : Dans son message précédent, Philippe Verdy a écrit : Pourquoi veux-tu que OSM se limite aux cartes ? OSM c'est une base de données, pas une carte. Les cartes c'est du domaine du rendu. OSM a bien d'autres usages comme la possibilité d'utiliser la base comme source d'informations pour composer toutes sortes de documents avec des inclusions dans le texte d'une partie de ces données, avec des liens hypertextes possibles vers des rendus cartographiques très divers, ou pas de carte du tout, par exemple dans des tableaux de données, où le nom ne sera pas non plus nécessairement le premier élément affiché dans une cellule). Bref le CNIG ne touche qu'au rendu des cartes, rien d'autre. Ils s'occupent de l'information géographique :D Ils font justement la distinction entre les cartes (où la majuscule est de toute façon due au début de phrase) et le cas général. Pour le cas général, ils recommandent : «Dans un toponyme (quel que soit son mode de composition), ou dans un nom de territoire politique ou administratif composé par jonction par des traits d’union, prennent la majuscule : [...] - l’article initial s’il n’est pas contracté avec à ou de le précédant (La Rochelle, Le Puy, Le Havre, la municipalité du Touquet et non de Le Touquet, aller au Mans et non à Le Mans [DAF, « le »] au lieudit « La Fourche », « Le Cheval mort » [DAF, « lieudit »]). » Et concernant l'IGN : «Ainsi, dans les toponymes officieux, l’IGN et le SHOM omettent actuellement les traits d’union et l’IGN la majuscule à l’article initial. Cette exception s’apparente à l’usage de signes typographiques comme la couleur des caractères, la police italique ou le corps des caractères» ;-) __**_ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.**org/listinfo/talk-frhttp://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Nouvel éditeur spécialisé traduction
Je viens de relancer l'application et maintenant, cela marche pour tous les toponymes. Y-aurait-il un peu d'instabilité? Donc, c'est super. Avec la BDD de l'Office public, cela va être un jeu d'enfant de renseigner les formes bretonnes des noms de hameau. Yapuka et au bout de dizaines de milliers de saisies, on aura une belle base pour les études linguistiques : répartition géographiques des toponymes rendue plus claire par la normalisation. Christian Rogel ___ 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
De : Eric SIBERT courr...@eric.sibert.fr 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. Oui je veux bien, il est encore en train de faire plein de modifs sur tous ces objets et ca risque d etre perdu. Julien___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Suppression des tirets cadratins
Il y a malgré tout moyen de faire un compromis si vous voulez garder la capitale dans la base partout: d'abord le problème ne français ne concerne que les mots « Le » ou « Les » écrits en tête. Dans la plupart des cas ce sont bien articles, ils sont donc contractables. Dans les autres cas rares, ce sont des exceptions qui peuvent être marqués spécialement pour dire que ce ne sont pas des articles mais des noms propres, donc que d'une part ce n'est pas une capitale typographique, mais bien une majuscule invariable (name:fr:invariable_case=yes). Cela pourrait concerner d'autres noms propres que les toponymes. Pour ne pas faire d'autres exceptions, on a choisi de garder les articles devant les noms de cours d'eau. Cependant ces articles ne font pas partie de l'odonyme lui-même : la minuscule s'impose. On reconnait alors ces articles à condition qu'on sache que c'est bien du français. D'autre part il faut savoir dans quelle langue est effectivement écrit le nom par défaut (name=*) : on n'est pas obligé de le dire dans tous les name=* si l'objet désigné est dans un pays ou une région dont on connait la langue officielle (ce name devrait être dans cette langue). Cela se complique dans les pays ou régions qui ont plusieurs langues co-officielles (par exemple les communautés autonomes espagnoles, ou la région de Bruxelles-Capitale, ou même la Région wallone où l'allemand est aussi coofficiel dans une partie, la distinction linguistique ne se faisant pas au niveau des régions administratives en Belgique, mais au niveau des communautés linguistiques). Pour indiquer la/les langues officielles dans une région (administrative ou autre entité politique dans OSM), on peut indiquer cette langue, ou ces langues dans un tag. Si un lieu fait partie de plusieurs régions adminsitratives ou autres entités poltiiques, toutes les langues indiquées sont coofficielles (ou ont un statut régional réconnu). A la suite de quoi on se retrouve avec un name=* qui peut n'être alors que dans l'une de ces langues ou plusieurs de celles-ci. Si les règles orthographiques, grammaticales, ou autres ne permettent pas de décider comment appliquer une règle, on n'a pas d'autre choix que de détailler les noms de ces langues avec leurs propres règles, et on ne dérivera pas le name=* par défaut qui reste dans une langue ambiguë.. Le 30 novembre 2012 14:37, Philippe Verdy verd...@wanadoo.fr a écrit : Très bien, il mentionne « l’article initial s’il n’est pas contracté avec à ou de » et suppose qu'on puisse reconnaitre qu'il s'agit d'un article (cela oblige à en garder la trace dans une base de données. Et le CNIG se place dans le cadre de la « composition », ce qui de fait exclue le cas « base de données » qui doit préserver cette différence d'une façon ou d'une autre. La base de données a bien vocation à garder les différences lexicales, ce n'est pas le contexte de la composition dont parle le CNIG. Le 30 novembre 2012 14:31, Plop76 vaujani...@free.fr a écrit : Dans son message précédent, Philippe Verdy a écrit : Pourquoi veux-tu que OSM se limite aux cartes ? OSM c'est une base de données, pas une carte. Les cartes c'est du domaine du rendu. OSM a bien d'autres usages comme la possibilité d'utiliser la base comme source d'informations pour composer toutes sortes de documents avec des inclusions dans le texte d'une partie de ces données, avec des liens hypertextes possibles vers des rendus cartographiques très divers, ou pas de carte du tout, par exemple dans des tableaux de données, où le nom ne sera pas non plus nécessairement le premier élément affiché dans une cellule). Bref le CNIG ne touche qu'au rendu des cartes, rien d'autre. Ils s'occupent de l'information géographique :D Ils font justement la distinction entre les cartes (où la majuscule est de toute façon due au début de phrase) et le cas général. Pour le cas général, ils recommandent : «Dans un toponyme (quel que soit son mode de composition), ou dans un nom de territoire politique ou administratif composé par jonction par des traits d’union, prennent la majuscule : [...] - l’article initial s’il n’est pas contracté avec à ou de le précédant (La Rochelle, Le Puy, Le Havre, la municipalité du Touquet et non de Le Touquet, aller au Mans et non à Le Mans [DAF, « le »] au lieudit « La Fourche », « Le Cheval mort » [DAF, « lieudit »]). » Et concernant l'IGN : «Ainsi, dans les toponymes officieux, l’IGN et le SHOM omettent actuellement les traits d’union et l’IGN la majuscule à l’article initial. Cette exception s’apparente à l’usage de signes typographiques comme la couleur des caractères, la police italique ou le corps des caractères» ;-) __**_ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.**org/listinfo/talk-frhttp://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list
Re: [OSM-talk-fr] Accès aux données eau du cadastre vectoriel
je ne suis pas capable de donner le nom de cette unité, mais oui ça rappelle des choses :D 2012/11/30 sly (sylvain letuffe) li...@letuffe.org On vendredi 30 novembre 2012, Marc SIBERT wrote: C'est quoi battle et wraith ? Je lis, mais je ne maitrise pas cette langue ! Laisse tomber ;-) Tu n'as pas été geek à cette période ! -- sly qui suis-je : http://sly.letuffe.org email perso : sylvain chez letuffe un point org ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Accès aux données eau du cadastre vectoriel
On vendredi 30 novembre 2012, Frédéric Rodrigo wrote: Il est possible d'utiliser l'outil de conversion depuis le cadastre à la maison également. Voir le wiki. Cette méthode a comme défaut de sélectionner par la technique, certains n'ont pas les moyens de faire l'installation eux même et pour autant intégreraient l'eau du cadastre proprement. Je peux proposer une solution simple : les rendre accessibles sur une zone protégée par un mot de passe que l'on peut distribuer par un mécanisme de réseau de confiance. La question c'est de déterminer qui fait la distribution de ce mot de passe. Je peux toutefois m'en occuper, mais j'ai peur que je finisse par être vu comme un méchant : Pourquoi tu lui donnes à lui et pas à moi ? Donc si quelqu'un veut gérer la distribution de l'accès ça me va aussi bien. En attendant, merci de me demander en privé les accès si vous comptez importer proprement les fichiers du cadastre liés à l'eau. -- 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] Réf.: Re: Grosse suppression de données autour de valenciennes
Bonjour, De mon coté je le fais en connaissance de cause, même si parfois j'oublie de remplacer aussi les noeuds extrêmes des ways -- Marc Sibert m...@sibert.fr Le 29 nov. 2012 19:59, THEVENON Julien julien_theve...@yahoo.fr a écrit : * De :* sly (sylvain letuffe) li...@letuffe.org * *Oulla, on est plus à ça prèt ! * *C'est juste histoire de battre le fer quand il est chaud, ma hantise étant de * *voir l'effort, la motiv ou que sais-je s'éssoufler et retourner dans un état * *létargique. J ai refait le run et envoye les resultats a Marc. ( Pas besoin de te les renvoyer a Vincent les rapports HTML n ont pas change ). Pour savoir dans quelle mesure des personnes font des modifs sur les objets teintes par CEDRIC007 j ai fait tourner mon outil de surveillance des objets sur tous les objets touches par Cedric. 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 olcomm_ild_inr a ete le plus actif. Marc Eric vous avez commence le remapping ? Il y a donc un certains nombre d edits qui sont faits sur ces objets avec le risque que ces modifs soient plus ou moins perdues lors de la redaction etant donne que certains objets ont ete crees par Cedric Julien ___ 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] Accès aux données eau du cadastre vectoriel
On vendredi 30 novembre 2012, Sylvain Maillard wrote: de toute manière tu passes déjà pour le grand méchant du DWG ... être un peu plus méchant ne devrais pas changer grand chose :D Devise shadok ? Quitte à taper sur quelqu'un, autant taper toujours sur le même, ça fera moins de gens mécontent ça m'emballe pas des masse d'avoir l'étiquette méchant du DWG, sutout dans cette communauté où dès que le mot privé est annoncé (peut en importe la raison) la pendaison publique est toute proche. Mais comme disent nos voisins anglais But it can't be help Va pour le méchant bis par intérim, mais je cède ce rôle pour les eaux du cadastre dès que quelqu'un me le demande ! -- sly qui suis-je : http://sly.letuffe.org email perso : sylvain chez letuffe un point org ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Suppression des tirets cadratins
Pour continuer le sujet de la variabilité des noms selon le contexte, le français (ou les langues romanes et germaniques) restent (en apparence seulement) encore des cas simples. Mais si vous regardez les autres langues cela se complique sérieusement : - les langues slaves déclinent tous les nom propres - les langues celtiques (breton ou irlandais par exemple) et sémitiques (arabe par exemple) pratiquent *aussi* la mutation des initiales selon les mots qui les précèdent et des règles complexes de phonologie. - les langues sémitiques (arabe ou hébreu) ne notent pas toujours les voyelles (points diacritiques) n'importe où dans les mots, ou peuvent n'en écrire qu'une partie ou bien toutes (ce n'est pas le cas de toutes les langues en écriture arabe, qui ont introduit des lettres à part entière pour les voyelles en systématisant ces voyelles et en ajoutant quelques lettres au besoin) - ces mêmes langues peuvent noter aussi la cantillation (optionnelle, comme si on pouvait noter en français contextuellement avec un accent particulier les voyelles longues, ou les syllabes emphasées d'un stress, ou d'une intonation particulière, marquant l'intention de l'auteur selon le contexte, au lieu d'utiliser des termes supplémentaires). - les langues asiatiques ne marquent pas systématiquement le genre, le nombre, la déclinaison, le temps ou la fonction, que ce soit par des adverbes, articles, déclinaisons, mais par agglutination de morphèmes, qui se contractent souvent par mutation aussi dans la racine ! Un exemple européen est la langue finnoise. - les mutations ne concernent pas toujours uniquement l'initiale mais aussi phonologiquement (selon des règles parfois complexes) des éléments au milieu de la racine (un exemple existe en français dans les mutations internes des racines des verbes du fait de la conjugaison : des accents ou lettres apparaissent ou disparaissent selon le temps, le mode, ou la personne, mais aussi dans les termes dérivés des noms propres comme les gentilés qui sont bourrés souvent de mutations, quand ils ne vont pas chercher leur racine dans un autre terme ou dans une autre langue!). On peut croire qu'on peut laisser de côte les gentilés (dont la séparation est claire dans les langues romanes ou germaniques) mais c'est souvent difficile dans les autres langues où ils sont formés par les types de dérivation précédents (par exemple par agglutination et mutations). De fait, il est important dans OSM de pouvoir savoir dans quelle langue les name=* sont écrits, et aussi avoir une idée de ce qui constitue dedans des termes ou morphèmes génériques (communs) ou propres (car les règles de dérivation sont alors très différentes et propres à chaque langue identifiée). Le 30 novembre 2012 15:26, Philippe Verdy verd...@wanadoo.fr a écrit : Il y a malgré tout moyen de faire un compromis si vous voulez garder la capitale dans la base partout: d'abord le problème ne français ne concerne que les mots « Le » ou « Les » écrits en tête. Dans la plupart des cas ce sont bien articles, ils sont donc contractables. Dans les autres cas rares, ce sont des exceptions qui peuvent être marqués spécialement pour dire que ce ne sont pas des articles mais des noms propres, donc que d'une part ce n'est pas une capitale typographique, mais bien une majuscule invariable (name:fr:invariable_case=yes). Cela pourrait concerner d'autres noms propres que les toponymes. Pour ne pas faire d'autres exceptions, on a choisi de garder les articles devant les noms de cours d'eau. Cependant ces articles ne font pas partie de l'odonyme lui-même : la minuscule s'impose. On reconnait alors ces articles à condition qu'on sache que c'est bien du français. D'autre part il faut savoir dans quelle langue est effectivement écrit le nom par défaut (name=*) : on n'est pas obligé de le dire dans tous les name=* si l'objet désigné est dans un pays ou une région dont on connait la langue officielle (ce name devrait être dans cette langue). Cela se complique dans les pays ou régions qui ont plusieurs langues co-officielles (par exemple les communautés autonomes espagnoles, ou la région de Bruxelles-Capitale, ou même la Région wallone où l'allemand est aussi coofficiel dans une partie, la distinction linguistique ne se faisant pas au niveau des régions administratives en Belgique, mais au niveau des communautés linguistiques). Pour indiquer la/les langues officielles dans une région (administrative ou autre entité politique dans OSM), on peut indiquer cette langue, ou ces langues dans un tag. Si un lieu fait partie de plusieurs régions adminsitratives ou autres entités poltiiques, toutes les langues indiquées sont coofficielles (ou ont un statut régional réconnu). A la suite de quoi on se retrouve avec un name=* qui peut n'être alors que dans l'une de ces langues ou plusieurs de celles-ci. Si les règles orthographiques, grammaticales, ou autres ne permettent pas de décider comment appliquer une règle, on n'a pas d'autre
Re: [OSM-talk-fr] Accès aux données eau du cadastre vectoriel
On vendredi 30 novembre 2012, Sylvain Maillard wrote: je ne suis pas capable de donner le nom de cette unité, mais oui ça rappelle des choses :D Ha ! ça fait plaisir de voir que je ne suis pas le seul geek à avoir beaucoup joué dans son enfance ;-) Mais pas tu ne m'as pour autant pas repris sur ma faute volontaire que j'avais piégée exprès ;-) -- 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] Problème bâti ds lotissement
en effet, c'est le bordel ! Comment elle a pu faire ça ? A mon avis, c'est sûrement plus vite fait de replacer les points qui ont bougé... De plus il faut revoir les tags : addr:housename n'est pas correctement utilisé ici. C'est plutôt addr:street je pense Cordialement, Mika_Gueret Le vendredi 30 novembre 2012 à 02:13 -0800, Tony Emery a écrit : Bonjour à tous, Je rencontre un problème assez délicat ici http://www.openstreetmap.org/?lat=44.11903381347656lon=4.799241721630096zoom=18 J'ai demandé à ma collègue d'ajouter les numéros de voie à partir d'un plan qu'on avait et elle a malencontreusement déplacé des points correspondant au bâti. Est-il possible de corriger ces erreurs sans supprimer la création des points d'adresse ? Bonne journée à tous, -- View this message in context: http://gis.19327.n5.nabble.com/Probleme-bati-ds-lotissement-tp5738380.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] Problème bâti ds lotissement
2012/11/30 Mickaël Guéret m.gue...@free.fr: A mon avis, c'est sûrement plus vite fait de replacer les points qui ont bougé... De plus il faut revoir les tags : addr:housename n'est pas correctement utilisé ici. C'est plutôt addr:street je pense Il existe un script perl qui permet de revenir en arrière sur un élément particulier: http://wiki.openstreetmap.org/wiki/Revert_scripts Pieren ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Problème bâti ds lotissement
J'avais donné un exemple juste sur 1 noeud et 1 changeset, il y en a sans doute d'autre squi sont concernés. en tout cas j'ai vu que pour la quasi totalité des noeud qui sont passés en version 2 (ou +), la dernière modification n'a affecté que la position du noeud. Donc un parcours des changesets, identification de tous les noeuds = V2, (petit contrôle rapide), devrait donner la liste des points qui retrouveront leur position d'origine, sans perdre les tag adresse ... Sylvain Le 30 novembre 2012 16:39, Pieren pier...@gmail.com a écrit : 2012/11/30 Mickaël Guéret m.gue...@free.fr: A mon avis, c'est sûrement plus vite fait de replacer les points qui ont bougé... De plus il faut revoir les tags : addr:housename n'est pas correctement utilisé ici. C'est plutôt addr:street je pense Il existe un script perl qui permet de revenir en arrière sur un élément particulier: http://wiki.openstreetmap.org/wiki/Revert_scripts 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
[OSM-talk-fr] [forum-osm-fr] Importation données osm postgreSQL - Nominatim-2.0.0
Le message suivant de :
##
Bonjour,
J'essaye d'importer mes données osm dans ma base postgreSQL à l'aide de
Nominatim. J'ai lu qu'il fallait se servir du fichier setup.php, j'essaye donc
d'importer avec la requête suivante:
root@obennegent-virtual-machine:/home/obennegent/OSM/Nominatim-2.0.0# sudo -u
obennegent ./utils/setup.php --osm-file
/home/obennegent/OSM/rhone-alpes.osm.pbf --all
J'ai installé tout les paquets cités sur le lien d'installation/Nominatim
suivant pour que cela fonctionne:
http://wiki.openstreetmap.org/wiki/Nominatim/Installation
Et voici le résultat que j'ai du mal à comprendre à vrai dire (même après avoir
regarder le code de setup.php)
root@obennegent-virtual-machine:/home/obennegent/OSM/Nominatim-2.0.0# sudo -u
obennegent ./utils/setup.php --osm-file
/home/obennegent/OSM/rhone-alpes.osm.pbf --all
WARNING: resetting threads to 1
Create DB
Setup DB
string(21) pgsql:/ /@/ gazetteer
object(DB_Error)#2 (8) {
[error_message_prefix]=
string(0)
[mode]=
int(1)
[level]=
int(1024)
[code]=
int(-4)
[message]=
string(19) DB Error: not found
[userinfo]=
string(83) Unable to include the DB/pgsql:/ /@/ gazetteer.php file for
'pgsql:/ /@/ gazetteer'
[backtrace]=
array(5) {
[0]=
array(6) {
[file]=
string(21) /usr/share/php/DB.php
[line]=
int(966)
[function]=
string(10) PEAR_Error
[class]=
string(10) PEAR_Error
[type]=
string(2) -
[args]=
array(5) {
[0]=
string(19) DB Error: not found
[1]=
int(-4)
[2]=
int(1)
[3]=
int(1024)
[4]=
string(83) Unable to include the DB/pgsql:/ /@/ gazetteer.php file for
'pgsql:/ /@/ gazetteer'
}
}
[1]=
array(7) {
[file]=
string(23) /usr/share/php/PEAR.php
[line]=
int(531)
[function]=
string(8) DB_Error
[class]=
string(8) DB_Error
[object]=
*RECURSION*
[type]=
string(2) -
[args]=
array(4) {
[0]=
int(-4)
[1]=
int(1)
[2]=
int(1024)
[3]=
string(83) Unable to include the DB/pgsql:/ /@/ gazetteer.php file for
'pgsql:/ /@/ gazetteer'
}
}
[2]=
array(6) {
[file]=
string(21) /usr/share/php/DB.php
[line]=
int(543)
[function]=
string(10) raiseError
[class]=
string(4) PEAR
[type]=
string(2) ::
[args]=
array(7) {
[0]=
NULL
[1]=
int(-4)
[2]=
NULL
[3]=
NULL
[4]=
string(83) Unable to include the DB/pgsql:/ /@/ gazetteer.php file for
'pgsql:/ /@/ gazetteer'
[5]=
string(8) DB_Error
[6]=
bool(true)
}
}
[3]=
array(6) {
[file]=
string(47) /home/obennegent/OSM/Nominatim-2.0.0/lib/db.php
[line]=
int(7)
[function]=
string(7) connect
[class]=
string(2) DB
[type]=
string(2) ::
[args]=
array(2) {
[0]=
string(21) pgsql:/ /@/ gazetteer
[1]=
bool(false)
}
}
[4]=
array(4) {
[file]=
string(52) /home/obennegent/OSM/Nominatim-2.0.0/utils/setup.php
[line]=
int(107)
[function]=
string(5) getDB
[args]=
array(0) {
}
}
}
[callback]=
NULL
}
ERROR: DB Error: not found
DB Error: not found
J'arrive sans problème à importer des données osm avec l'outil osm2pgsql sans
passé par Nominatim mais en ce qui concerne cette outil, je suis un peu perdu :S
Si quelqu'un pourrait t-il m'éclairer svp.
Merci par avance,
Olivier.
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] L'île d'Amsterdam a été engloutie sous les flots !
Je sais que l'époque est au réchauffement climatique et à la montée des eaux, mais bon... Dans OSM l'île d'Amsterdam (dans les terres australes françaises) a déjà disparu sous les flots ! http://www.openstreetmap.org/?lat=-37.8462lon=77.5712zoom=13layers=M Encore un problème de trait de côte ? Nicolas ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] L'île d'Amsterdam a été engloutie sous les flots !
Non c'est autre chose, cela vient de la relation de niveau 7 (le district des îles Amsterdam et Saint-Paul, dans les TAAF) qui mentionne l'île deux fois (et sans rôle). En revanche je ne comprend pas pourquoi elle n'est pas incluse dans les TAAF (comme les autres districts) Le 30 novembre 2012 18:02, Nicolas Moyroud nmoyr...@free.fr a écrit : Je sais que l'époque est au réchauffement climatique et à la montée des eaux, mais bon... Dans OSM l'île d'Amsterdam (dans les terres australes françaises) a déjà disparu sous les flots ! http://www.openstreetmap.org/?**lat=-37.8462lon=77.5712zoom=** 13layers=Mhttp://www.openstreetmap.org/?lat=-37.8462lon=77.5712zoom=13layers=M Encore un problème de trait de côte ? 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] L'île d'Amsterdam a été engloutie sous les flots !
Le 30/11/2012 19:01, Philippe Verdy a écrit : Non c'est autre chose, cela vient de la relation de niveau 7 (le district des îles Amsterdam et Saint-Paul, dans les TAAF) qui mentionne l'île deux fois (et sans rôle). En revanche je ne comprend pas pourquoi elle n'est pas incluse dans les TAAF (comme les autres districts) Je ne comprends pas le problème: ça avait l'air très bien avant ta suppression de le relation 1401924. http://www.openstreetmap.org/browse/relation/1401924/history - elle contenait les deux îles de Saint-Paul et d'Amsterdam http://www.openstreetmap.org/browse/relation/1401925/history - relation qui était bien incluse dans la relation des TAAF. En tout cas, je ne vois pas comme une relation peut impacter le rendu de Mapnik, qui ne prend en compte que les natural=coastline pour les côtes, du moins à ce qu'il me semble. Merci, Jocelyn ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] L'île d'Amsterdam a été engloutie sous les flots !
De même Saint-Paul ne fait partie d'aucune relation alors qu'elle devrait être dans le district et dans les TAAF aussi. Les TAAF devraient aussi être en dans une relation France (de type frontières territoriales) qui regroupe au moins par référence même si on ne détaille pas toutes les frontières, les relations suivantes : - la France métropolitaine (Corse incluse). - ses DOM (les codes INSEE 97n, y compris maintenant Mayotte, mais plus Saint-Barthélemy, Saint-Martin et Saint-Pierre-et-Miquelon) - chacune des COM (les codes INSEE 98n, sauf la Nouvelle-Calédonie) : Saint-Barthélemy, Saint-Martin et Saint-Pierre-et-Miquelon, Wallis-et-Futuna, Polynésie française, les TAAF - et la Nouvelle-Calédonie à part (le seul territoire français en outre-mer qui ne soit ni un DOM ni une COM). Les TAAF et Clipperton font partie maintenant des COM, même si les statuts d'inclusion ou d'exclusion législative sont différents, car il y a bien des collectivités avec pour chacune leur budget, avec une petite fiscalité spécifique pour certains droits territoriaux, quelques ressources comme le registre maritime et les droits de pêche ou d'exploration et l'émission de timbres; ils ont même leur conseil local pour les TAAF tout entiers mais qui ne siège pas sur place; il n'y a pas d'élu local car pas d'électeurs locaux, ce conseil territorial étant avant tout administratif, l'aspect réglementaire relevant du ministère de l'outre-mer dirigé par le premier ministre, et l'aspect législatif de l'assemblée nationale, au plan exécutif il y a encore et un préfet compétent pour représenter l'Etat, et présent à ce conseil, à la Réunion pour les TAAF, à Papeete pour Clipperton). Le 30 novembre 2012 19:01, Philippe Verdy verd...@wanadoo.fr a écrit : Non c'est autre chose, cela vient de la relation de niveau 7 (le district des îles Amsterdam et Saint-Paul, dans les TAAF) qui mentionne l'île deux fois (et sans rôle). En revanche je ne comprend pas pourquoi elle n'est pas incluse dans les TAAF (comme les autres districts) Le 30 novembre 2012 18:02, Nicolas Moyroud nmoyr...@free.fr a écrit : Je sais que l'époque est au réchauffement climatique et à la montée des eaux, mais bon... Dans OSM l'île d'Amsterdam (dans les terres australes françaises) a déjà disparu sous les flots ! http://www.openstreetmap.org/?**lat=-37.8462lon=77.5712zoom=** 13layers=Mhttp://www.openstreetmap.org/?lat=-37.8462lon=77.5712zoom=13layers=M Encore un problème de trait de côte ? 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] L'île d'Amsterdam a été engloutie sous les flots !
En principe oui, mais la façon dont c'est extrait, il semble qu'il y a toujours eu l'idée de mélanger les choux et les carottes dans les rendus actuels, car il y a beaucoup d'incohérences dans OSM : on regroupe tout, on compte les inclusions, on enlève les paires, on ferme les chemins pour former des anneaux, et s'il reste encore un anneau, on le garde en frontière interne ou externe, déterminé automatiquement (les rôles inner et outer précisés dans les relations semblent aussi totalement ignorés, sauf pour émettre un warning sur une liste de suivi d'anomalies, au cas où ce calcul diffère de ce qui est renseigné dans la base, afin de permettre des vérifications de cohérence). Les moteurs de rendus ont beaucoup de mal à gérer les incohérences, ils font des heuristiques qui corrigent certains problèmes mais pas tous. Le 30 novembre 2012 19:22, Jocelyn Jaubert jocelyn.jaub...@gmail.com a écrit : Le 30/11/2012 19:01, Philippe Verdy a écrit : Non c'est autre chose, cela vient de la relation de niveau 7 (le district des îles Amsterdam et Saint-Paul, dans les TAAF) qui mentionne l'île deux fois (et sans rôle). En revanche je ne comprend pas pourquoi elle n'est pas incluse dans les TAAF (comme les autres districts) Je ne comprends pas le problème: ça avait l'air très bien avant ta suppression de le relation 1401924. http://www.openstreetmap.org/browse/relation/1401924/history - elle contenait les deux îles de Saint-Paul et d'Amsterdam http://www.openstreetmap.org/browse/relation/1401925/history - relation qui était bien incluse dans la relation des TAAF. En tout cas, je ne vois pas comme une relation peut impacter le rendu de Mapnik, qui ne prend en compte que les natural=coastline pour les côtes, du moins à ce qu'il me semble. Merci, Jocelyn ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] L'île d'Amsterdam a été engloutie sous les flots !
Note j'ai fait la modif rapridement dans Potlatch qui affichait bien le chemin DEUX fois dans la même relation. H... peut-être une anomalie dans la base OSM elle-même ou un index. Il va falloir recharger dans JOSM pour comprendre car PotLatch2 ne sait pas gérer une zone aussi étendue que les TAAF et c'est sans doute lui qui se plante. Le 30 novembre 2012 19:22, Jocelyn Jaubert jocelyn.jaub...@gmail.com a écrit : Le 30/11/2012 19:01, Philippe Verdy a écrit : Non c'est autre chose, cela vient de la relation de niveau 7 (le district des îles Amsterdam et Saint-Paul, dans les TAAF) qui mentionne l'île deux fois (et sans rôle). En revanche je ne comprend pas pourquoi elle n'est pas incluse dans les TAAF (comme les autres districts) Je ne comprends pas le problème: ça avait l'air très bien avant ta suppression de le relation 1401924. http://www.openstreetmap.org/browse/relation/1401924/history - elle contenait les deux îles de Saint-Paul et d'Amsterdam http://www.openstreetmap.org/browse/relation/1401925/history - relation qui était bien incluse dans la relation des TAAF. En tout cas, je ne vois pas comme une relation peut impacter le rendu de Mapnik, qui ne prend en compte que les natural=coastline pour les côtes, du moins à ce qu'il me semble. Merci, Jocelyn ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] L'île d'Amsterdam a été engloutie sous les flots !
En plus je n'ai strictement rien modifié pour Saint-Paul dans Potlatch mais uniquement à Amsterdam. Bref un bogue dans Potlatch. Le 30 novembre 2012 19:22, Jocelyn Jaubert jocelyn.jaub...@gmail.com a écrit : Le 30/11/2012 19:01, Philippe Verdy a écrit : Non c'est autre chose, cela vient de la relation de niveau 7 (le district des îles Amsterdam et Saint-Paul, dans les TAAF) qui mentionne l'île deux fois (et sans rôle). En revanche je ne comprend pas pourquoi elle n'est pas incluse dans les TAAF (comme les autres districts) Je ne comprends pas le problème: ça avait l'air très bien avant ta suppression de le relation 1401924. http://www.openstreetmap.org/browse/relation/1401924/history - elle contenait les deux îles de Saint-Paul et d'Amsterdam http://www.openstreetmap.org/browse/relation/1401925/history - relation qui était bien incluse dans la relation des TAAF. En tout cas, je ne vois pas comme une relation peut impacter le rendu de Mapnik, qui ne prend en compte que les natural=coastline pour les côtes, du moins à ce qu'il me semble. Merci, Jocelyn ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] L'île d'Amsterdam a été engloutie sous les flots !
Visiblement, jocelyn a cherché à être trop diplomate et n'a pas été assez clair pour traiter ton cas. On va la refaire : ne touches PAS Peut-être qu'il y a un problème, peut-être qu'il n'y en a pas ou peut-être qu'il est ailleurs, mais en attendant, avant de tout changer à la va vite, on va prendre le temps de discuter et on va éviter de casser des relations pour créer de nouveaux problèmes que l'on ne maîtrise pas, ou, en tout cas, que tu ne semble pas maîtriser. Je m'occupe du revert On vendredi 30 novembre 2012, Philippe Verdy wrote: En principe oui, mais la façon dont c'est extrait, il semble qu'il y a toujours eu l'idée de mélanger les choux et les carottes dans les rendus actuels, car il y a beaucoup d'incohérences dans OSM : on regroupe tout, on compte les inclusions, on enlève les paires, on ferme les chemins pour former des anneaux, et s'il reste encore un anneau, on le garde en frontière interne ou externe, déterminé automatiquement (les rôles inner et outer précisés dans les relations semblent aussi totalement ignorés, sauf pour émettre un warning sur une liste de suivi d'anomalies, au cas où ce calcul diffère de ce qui est renseigné dans la base, afin de permettre des vérifications de cohérence). Les moteurs de rendus ont beaucoup de mal à gérer les incohérences, ils font des heuristiques qui corrigent certains problèmes mais pas tous. Le 30 novembre 2012 19:22, Jocelyn Jaubert jocelyn.jaub...@gmail.com a écrit : Le 30/11/2012 19:01, Philippe Verdy a écrit : Non c'est autre chose, cela vient de la relation de niveau 7 (le district des îles Amsterdam et Saint-Paul, dans les TAAF) qui mentionne l'île deux fois (et sans rôle). En revanche je ne comprend pas pourquoi elle n'est pas incluse dans les TAAF (comme les autres districts) Je ne comprends pas le problème: ça avait l'air très bien avant ta suppression de le relation 1401924. http://www.openstreetmap.org/browse/relation/1401924/history - elle contenait les deux îles de Saint-Paul et d'Amsterdam http://www.openstreetmap.org/browse/relation/1401925/history - relation qui était bien incluse dans la relation des TAAF. En tout cas, je ne vois pas comme une relation peut impacter le rendu de Mapnik, qui ne prend en compte que les natural=coastline pour les côtes, du moins à ce qu'il me semble. Merci, Jocelyn -- 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] L'île d'Amsterdam a été engloutie sous les flots !
Je ne comprend d'ailleurs pas pourquoi Potlatch a supprimé les 3 éléments qu'il affichait bien dans la relation, alors que je n'ai fait QUE supprimer UN seul des éléments un double, et c'était Amsterdam, je n'ai rien touché concernant Saint-Paul, il y avait bien 2 éléments affichés quand j'ai soumis les données, il n'en reste aucun. Bref il y avait bien Amsterdam deux fois dans cette relation, la seule et unique chose que j'ai touché, et Potlatch n'aime pas ça du tout et fait n'import quoi dans ce cas-là si on ôte un des membres en doublon : il ôte le mauvais membre (problème d'indexation unique), puis il constate que l'autre à été supprimé en théorie, donc ne l'envoie pas, et il ignore le 3ème puisqu'en principe les 2 membres sont déjà pris en compte dans sa boucle d'envoi des données. J'aurais du utiliser JOSM comme d'habitude : il gère bien ces cas là de doublons dans les relations. Pourquoi ces doublons : sans doûte depuis le passage de Redaction Bot qui a fait des reverts Le 30 novembre 2012 19:32, Philippe Verdy verd...@wanadoo.fr a écrit : En plus je n'ai strictement rien modifié pour Saint-Paul dans Potlatch mais uniquement à Amsterdam. Bref un bogue dans Potlatch. Le 30 novembre 2012 19:22, Jocelyn Jaubert jocelyn.jaub...@gmail.com a écrit : Le 30/11/2012 19:01, Philippe Verdy a écrit : Non c'est autre chose, cela vient de la relation de niveau 7 (le district des îles Amsterdam et Saint-Paul, dans les TAAF) qui mentionne l'île deux fois (et sans rôle). En revanche je ne comprend pas pourquoi elle n'est pas incluse dans les TAAF (comme les autres districts) Je ne comprends pas le problème: ça avait l'air très bien avant ta suppression de le relation 1401924. http://www.openstreetmap.org/browse/relation/1401924/history - elle contenait les deux îles de Saint-Paul et d'Amsterdam http://www.openstreetmap.org/browse/relation/1401925/history - relation qui était bien incluse dans la relation des TAAF. En tout cas, je ne vois pas comme une relation peut impacter le rendu de Mapnik, qui ne prend en compte que les natural=coastline pour les côtes, du moins à ce qu'il me semble. Merci, Jocelyn ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] L'île d'Amsterdam a été engloutie sous les flots !
Trop facile ! C'est pas toi, c'est un bug ! Ne peux-tu pas simplement annuler tes modifications ? -- Marc Sibert m...@sibert.fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] L'île d'Amsterdam a été engloutie sous les flots !
Ce ne serait pas du au changement de direction de la ligne de côte d'Amsterdam ? Elle devait être en sens horaire au lieu du sens trigonométrique. En tout cas après ton revert Potlatch n'affiche plus Amsterdam 2 fois dans sa relation parente. Le 30 novembre 2012 19:38, sly (sylvain letuffe) li...@letuffe.org a écrit : Visiblement, jocelyn a cherché à être trop diplomate et n'a pas été assez clair pour traiter ton cas. On va la refaire : ne touches PAS Peut-être qu'il y a un problème, peut-être qu'il n'y en a pas ou peut-être qu'il est ailleurs, mais en attendant, avant de tout changer à la va vite, on va prendre le temps de discuter et on va éviter de casser des relations pour créer de nouveaux problèmes que l'on ne maîtrise pas, ou, en tout cas, que tu ne semble pas maîtriser. Je m'occupe du revert On vendredi 30 novembre 2012, Philippe Verdy wrote: En principe oui, mais la façon dont c'est extrait, il semble qu'il y a toujours eu l'idée de mélanger les choux et les carottes dans les rendus actuels, car il y a beaucoup d'incohérences dans OSM : on regroupe tout, on compte les inclusions, on enlève les paires, on ferme les chemins pour former des anneaux, et s'il reste encore un anneau, on le garde en frontière interne ou externe, déterminé automatiquement (les rôles inner et outer précisés dans les relations semblent aussi totalement ignorés, sauf pour émettre un warning sur une liste de suivi d'anomalies, au cas où ce calcul diffère de ce qui est renseigné dans la base, afin de permettre des vérifications de cohérence). Les moteurs de rendus ont beaucoup de mal à gérer les incohérences, ils font des heuristiques qui corrigent certains problèmes mais pas tous. Le 30 novembre 2012 19:22, Jocelyn Jaubert jocelyn.jaub...@gmail.com a écrit : Le 30/11/2012 19:01, Philippe Verdy a écrit : Non c'est autre chose, cela vient de la relation de niveau 7 (le district des îles Amsterdam et Saint-Paul, dans les TAAF) qui mentionne l'île deux fois (et sans rôle). En revanche je ne comprend pas pourquoi elle n'est pas incluse dans les TAAF (comme les autres districts) Je ne comprends pas le problème: ça avait l'air très bien avant ta suppression de le relation 1401924. http://www.openstreetmap.org/browse/relation/1401924/history - elle contenait les deux îles de Saint-Paul et d'Amsterdam http://www.openstreetmap.org/browse/relation/1401925/history - relation qui était bien incluse dans la relation des TAAF. En tout cas, je ne vois pas comme une relation peut impacter le rendu de Mapnik, qui ne prend en compte que les natural=coastline pour les côtes, du moins à ce qu'il me semble. Merci, Jocelyn -- sly qui suis-je : http://sly.letuffe.org email perso : sylvain chez letuffe un point org ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] L'île d'Amsterdam a été engloutie sous les flots !
Si j'aurais pu, mais JOSM est occupé et j'ai pas de quoi lancer une seconde instance, en plus je l'ai signalé et Sly a déjà fait le revert immédiatement. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] L'île d'Amsterdam a été engloutie sous les flots !
Dommage que Potlatch ne permette pas de voir dans quel sens est tracé une ligne fermée, il ne le fait que pour les routes oneway=yes, pas pour les lignes de côtes. Pour bien expliquer ce que je voyais dans Potlatch en clliquant UNIQUEMENT le chemin d'Amsterdam, c'était le MÊME id (celui de la relation du district puis un slash, puis les numéros d'ordre 0 et 2 dans cette relation. Le membre /1 c'était l'autre île de Saint-Paul, que je n'ai même pas chargée ni touchée. Et dans les infos détaillées par Potlatch, je voyais bel et bien 3 membres : Amsterdam en membres 0 et 2, Saint-Paul en membres 1. J'ai supprimé uniquement le membre numéro 2. Et sinon j'avais ajouté les rôles outer pour les 2 autres membres /0 et /1 que j'avais bien laissés. Et j'ai envoyé. Si ça peut aider à localiser l'anomalie de Potlatch en cas de membres en doublon... Le 30 novembre 2012 19:46, Philippe Verdy verd...@wanadoo.fr a écrit : Si j'aurais pu, mais JOSM est occupé et j'ai pas de quoi lancer une seconde instance, en plus je l'ai signalé et Sly a déjà fait le revert immédiatement. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] L'île d'Amsterdam a été engloutie sous les flots !
Ces doublons ont du gêner la dernière mise à jour des lignes de côte (maintenant il va falloir attendre peut entre encore 2 semaines en gros,pour qu'elle ne soit pas noyée par la mer, car si c'est bon dans la base, le rendu se sert encore des anciennes lignes de côte d'avant la correction du sens horaire de la ligne de côte). Le 30 novembre 2012 20:01, Philippe Verdy verd...@wanadoo.fr a écrit : Dommage que Potlatch ne permette pas de voir dans quel sens est tracé une ligne fermée, il ne le fait que pour les routes oneway=yes, pas pour les lignes de côtes. Pour bien expliquer ce que je voyais dans Potlatch en clliquant UNIQUEMENT le chemin d'Amsterdam, c'était le MÊME id (celui de la relation du district puis un slash, puis les numéros d'ordre 0 et 2 dans cette relation. Le membre /1 c'était l'autre île de Saint-Paul, que je n'ai même pas chargée ni touchée. Et dans les infos détaillées par Potlatch, je voyais bel et bien 3 membres : Amsterdam en membres 0 et 2, Saint-Paul en membres 1. J'ai supprimé uniquement le membre numéro 2. Et sinon j'avais ajouté les rôles outer pour les 2 autres membres /0 et /1 que j'avais bien laissés. Et j'ai envoyé. Si ça peut aider à localiser l'anomalie de Potlatch en cas de membres en doublon... Le 30 novembre 2012 19:46, Philippe Verdy verd...@wanadoo.fr a écrit : Si j'aurais pu, mais JOSM est occupé et j'ai pas de quoi lancer une seconde instance, en plus je l'ai signalé et Sly a déjà fait le revert immédiatement. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] L'île d'Amsterdam a été engloutie sous les flots !
Notez aussi que le redaction Bot a supprimé 2 îles le 20 juillet dans ce district et qu'elles n'ont pas été retracées: visiblement c'est lui qui a créé le doublon dans les relations, ou laissé ce que Potlatch prend pour un doublon ou un élément incomplet. Ensuite les 2 îles restantes ont été retracées par Peter14 (avec Amsterdam dans le mauvais sens, horaire.) Chemin Saint-Paul (187776774)http://www.openstreetmap.org/browse/way/187776774 Chemin Amsterdam (187776599)http://www.openstreetmap.org/browse/way/187776599 Les 2 autres îles les plus grandes ont été laissées en l'état par le Redaction Bot ont été supprimées (par Peter14 qui a retracé ces 2 îles le 26 octobre, mais qui n'a pas retracé les plus petits îlots à coté qui ont été masqués par le Redaction Bot). Ensuite les lignes de côtes ont été recalculées et rechargées pour le rendu Mapnik entre le 26 octobre, date du retracé à l'envers d'Amsterdam et aujourd'hui, mais en ignorant Amsterdam qui était dans le mauvais sens (sens corrigé uniquement le 31 octobre à 6h06 par Peter14, et toujours pas pris en compte par Mapnik aujourdhui dans ses vieilles lignes de côte, un mois après cette correction de sens. Il est temps aussi de signaler à OSM que ses lignes de côte pour Mapnik sont obsolètes depuis trop longtemps (plus d'un mois, c'est trop) : cela corrigerait aussi le rendu de la côte sur la pointe du Finistère en rade de Brest et autour. Modifié le : 20 juillet 2012 15:06:40Modifié par :OSMF Redaction Accounthttp://www.openstreetmap.org/user/OSMF%20Redaction%20Account Version :2Dans le groupe de modifications :12380704http://www.openstreetmap.org/browse/changeset/12380704 Commentaire :Updates based on the redaction processBalises :admin_level = 7 boundaryhttp://wiki.openstreetmap.org/wiki/FR:Key:boundary?uselang=fr = administrativehttp://wiki.openstreetmap.org/wiki/Tag:boundary=administrative?uselang=fr name http://wiki.openstreetmap.org/wiki/FR:Key:name?uselang=fr = Saint-Paul-et-Amsterdam typehttp://wiki.openstreetmap.org/wiki/Key:type?uselang=fr = boundary Membres :Chemin 30689180http://www.openstreetmap.org/browse/way/30689180 Chemin 30689239 http://www.openstreetmap.org/browse/way/30689239 -- Modifié le :31 janvier 2011 21:40:41 Modifié par :Jocelynhttp://www.openstreetmap.org/user/JocelynVersion : 1Dans le groupe de modifications :7149507http://www.openstreetmap.org/browse/changeset/7149507 Commentaire :ajout d'une relation pour les TAAFBalises :admin_level = 7 boundaryhttp://wiki.openstreetmap.org/wiki/FR:Key:boundary?uselang=fr = administrativehttp://wiki.openstreetmap.org/wiki/Tag:boundary=administrative?uselang=fr name http://wiki.openstreetmap.org/wiki/FR:Key:name?uselang=fr = Saint-Paul-et-Amsterdam typehttp://wiki.openstreetmap.org/wiki/Key:type?uselang=fr = boundary Membres :Chemin 30689180http://www.openstreetmap.org/browse/way/30689180 Chemin 55015115 http://www.openstreetmap.org/browse/way/55015115Chemin 55015116 http://www.openstreetmap.org/browse/way/55015116 Chemin 30689239http://www.openstreetmap.org/browse/way/30689239 Le 30 novembre 2012 20:04, Philippe Verdy verd...@wanadoo.fr a écrit : Ces doublons ont du gêner la dernière mise à jour des lignes de côte (maintenant il va falloir attendre peut entre encore 2 semaines en gros,pour qu'elle ne soit pas noyée par la mer, car si c'est bon dans la base, le rendu se sert encore des anciennes lignes de côte d'avant la correction du sens horaire de la ligne de côte). Le 30 novembre 2012 20:01, Philippe Verdy verd...@wanadoo.fr a écrit : Dommage que Potlatch ne permette pas de voir dans quel sens est tracé une ligne fermée, il ne le fait que pour les routes oneway=yes, pas pour les lignes de côtes. Pour bien expliquer ce que je voyais dans Potlatch en clliquant UNIQUEMENT le chemin d'Amsterdam, c'était le MÊME id (celui de la relation du district puis un slash, puis les numéros d'ordre 0 et 2 dans cette relation. Le membre /1 c'était l'autre île de Saint-Paul, que je n'ai même pas chargée ni touchée. Et dans les infos détaillées par Potlatch, je voyais bel et bien 3 membres : Amsterdam en membres 0 et 2, Saint-Paul en membres 1. J'ai supprimé uniquement le membre numéro 2. Et sinon j'avais ajouté les rôles outer pour les 2 autres membres /0 et /1 que j'avais bien laissés. Et j'ai envoyé. Si ça peut aider à localiser l'anomalie de Potlatch en cas de membres en doublon... Le 30 novembre 2012 19:46, Philippe Verdy verd...@wanadoo.fr a écrit : Si j'aurais pu, mais JOSM est occupé et j'ai pas de quoi lancer une seconde instance, en plus je l'ai signalé et Sly a déjà fait le revert immédiatement. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
[OSM-talk-fr] com de com au 01/01/2013
bonjour le schema départemental de l'intercommunalité va modifier cette liste au premier janvier est-ce qu'un bot se chargera de récuperer les nouveaux périmetres des comcom restantes après le 1 janvier ou faut-il prévoir d'agir à la main. peut-on prévoir un tag pour les anciennes comcom ? les anciens périmètres. avis ? merci jeff Une messagerie gratuite, garantie à vie et des services en plus, ça vous tente ? Je crée ma boîte mail www.laposte.net ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
[OSM-talk-fr] com de com au 01/01/2013
oups la page http://wiki.openstreetmap.org/wiki/Communes_de_la_Haute-Saône Une messagerie gratuite, garantie à vie et des services en plus, ça vous tente ? Je crée ma boîte mail www.laposte.net ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] com de com au 01/01/2013
Bonsoir, bonjour le schema départemental de l'intercommunalité va modifier cette liste au premier janvier est-ce qu'un bot se chargera de récuperer les nouveaux périmetres des comcom restantes après le 1 janvier ou faut-il prévoir d'agir à la main. peut-on prévoir un tag pour les anciennes comcom ? les anciens périmètres. avis ? merci jeff oups la page http://wiki.openstreetmap.org/wiki/Communes_de_la_Haute-Saône On pourrait imaginer le recours à un bot, si par exemple tu disposes de la liste des codes INSEE des communes composant chaque interco. Mais sinon, un bot pour mettre à jour quelques (gros) polygones, pas sûr que ce soit très rentable. C'est l'occasion peut-être de rappeler qu'un outil existe déjà, qui facilite beaucoup la saisie des communautés de communes : ComCom Maker, par ici : http://osm7.openstreetmap.fr/~vincentpottier/comcom/ Pour ce qui est du périmètre des comcom avant mise à jour (donc obsolète en 2013), je ne sais pas quel usage tu souhaiterais en faire, mais de mon côté je trouverais préférable de ne pas laisser ces définitions dans la base, même avec des tags spécifiant que ces limites n'ont plus cours. Ça reviendrait, quoi qu'on dise, à gérer côte à côte plusieurs versions d'un même objet en concurrence. Je ne dis pas que ça n'a pas d'intérêt, mais à mon avis ça devrait se faire en dehors de la base, via un stockage en propre (en fichiers .osm, en fichiers SIG, etc.). vincent ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Arrêt de bus de Paris...
On dirait que tes imports d'abris-bus sont en double sur ta carte (qui affiche deux onglets homonymes pour chacun, avec quelques attributs différents, quand on en sélectionne un). Tu peux confirmer, ou est-ce un bogue de la carte ? Le 30 novembre 2012 19:20, Christian Quest cqu...@openstreetmap.fr a écrit : Sacré chantier vu qu'il y en a plus de 11000, mais bon, petit à petit... Les données publiées dernièrement par la RATP n'étant pas directement exploitables, je me suis tourné vers une autre source, celles de la Ville de Paris qui publie l'emplacement des abribus. Partant de ces données, je les ai croisées à l'aide du plugin conflation avec les arrêts de bus déjà présents dans OSM et j'ai fait la fusion par étape (10m, 20m puis 50m maxi pour la conflation). A 10 et 20m, j'ai fait un contrôle aléatoire avec Bing qui m'a confirmé que les données de la ville de Paris sont précises (on a même la forme de l'abribus, mais je n'ai gardé qu'un noeud). A 50m, j'ai vérifié un à un. Ensuite j'ai repris le fichier RATP et je l'ai croisé avec les abribus restants en vérifiant cette fois-ci un à un. Résultat, 1212 abribus intégrés, visible ici: http://bit.ly/abribus-paris -- Christian Quest - OpenStreetMap France - http://openstreetmap.fr/u/cquest ___ 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] Arrêt de bus de Paris...
Note: ce n'est pas sur tous, mais un grand nombre d'entre eux. Par exemple l'arrêt Palais-Royal - Comédie Française. Le 30 novembre 2012 23:36, Philippe Verdy verd...@wanadoo.fr a écrit : On dirait que tes imports d'abris-bus sont en double sur ta carte (qui affiche deux onglets homonymes pour chacun, avec quelques attributs différents, quand on en sélectionne un). Tu peux confirmer, ou est-ce un bogue de la carte ? Le 30 novembre 2012 19:20, Christian Quest cqu...@openstreetmap.fr a écrit : Sacré chantier vu qu'il y en a plus de 11000, mais bon, petit à petit... Les données publiées dernièrement par la RATP n'étant pas directement exploitables, je me suis tourné vers une autre source, celles de la Ville de Paris qui publie l'emplacement des abribus. Partant de ces données, je les ai croisées à l'aide du plugin conflation avec les arrêts de bus déjà présents dans OSM et j'ai fait la fusion par étape (10m, 20m puis 50m maxi pour la conflation). A 10 et 20m, j'ai fait un contrôle aléatoire avec Bing qui m'a confirmé que les données de la ville de Paris sont précises (on a même la forme de l'abribus, mais je n'ai gardé qu'un noeud). A 50m, j'ai vérifié un à un. Ensuite j'ai repris le fichier RATP et je l'ai croisé avec les abribus restants en vérifiant cette fois-ci un à un. Résultat, 1212 abribus intégrés, visible ici: http://bit.ly/abribus-paris -- Christian Quest - OpenStreetMap France - http://openstreetmap.fr/u/cquest ___ 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] Arrêt de bus de Paris...
N'est-ce pas qu'il y a un arrêt de chaque coté de la rue? Jo 2012/11/30 Philippe Verdy verd...@wanadoo.fr Note: ce n'est pas sur tous, mais un grand nombre d'entre eux. Par exemple l'arrêt Palais-Royal - Comédie Française. Le 30 novembre 2012 23:36, Philippe Verdy verd...@wanadoo.fr a écrit : On dirait que tes imports d'abris-bus sont en double sur ta carte (qui affiche deux onglets homonymes pour chacun, avec quelques attributs différents, quand on en sélectionne un). Tu peux confirmer, ou est-ce un bogue de la carte ? Le 30 novembre 2012 19:20, Christian Quest cqu...@openstreetmap.fr a écrit : Sacré chantier vu qu'il y en a plus de 11000, mais bon, petit à petit... Les données publiées dernièrement par la RATP n'étant pas directement exploitables, je me suis tourné vers une autre source, celles de la Ville de Paris qui publie l'emplacement des abribus. Partant de ces données, je les ai croisées à l'aide du plugin conflation avec les arrêts de bus déjà présents dans OSM et j'ai fait la fusion par étape (10m, 20m puis 50m maxi pour la conflation). A 10 et 20m, j'ai fait un contrôle aléatoire avec Bing qui m'a confirmé que les données de la ville de Paris sont précises (on a même la forme de l'abribus, mais je n'ai gardé qu'un noeud). A 50m, j'ai vérifié un à un. Ensuite j'ai repris le fichier RATP et je l'ai croisé avec les abribus restants en vérifiant cette fois-ci un à un. Résultat, 1212 abribus intégrés, visible ici: http://bit.ly/abribus-paris -- Christian Quest - OpenStreetMap France - http://openstreetmap.fr/u/cquest ___ 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] Arrêt de bus de Paris...
Peut-être effectivement. Je me demandais pourquoi je voyais shelter=yes;no. La carte superpose les icônes et un clic sur une affiche un onglet pour chacune mais semble mélanger malgré tout certains attributs dans les onglets affichés. Je pensais qu'un clic sur une icône n'en affichait le détail que d'un seul, comme sur Osmose ou ailleurs. Le 30 novembre 2012 23:39, Jo winfi...@gmail.com a écrit : N'est-ce pas qu'il y a un arrêt de chaque coté de la rue? Jo 2012/11/30 Philippe Verdy verd...@wanadoo.fr Note: ce n'est pas sur tous, mais un grand nombre d'entre eux. Par exemple l'arrêt Palais-Royal - Comédie Française. Le 30 novembre 2012 23:36, Philippe Verdy verd...@wanadoo.fr a écrit : On dirait que tes imports d'abris-bus sont en double sur ta carte (qui affiche deux onglets homonymes pour chacun, avec quelques attributs différents, quand on en sélectionne un). Tu peux confirmer, ou est-ce un bogue de la carte ? Le 30 novembre 2012 19:20, Christian Quest cqu...@openstreetmap.fr a écrit : Sacré chantier vu qu'il y en a plus de 11000, mais bon, petit à petit... Les données publiées dernièrement par la RATP n'étant pas directement exploitables, je me suis tourné vers une autre source, celles de la Ville de Paris qui publie l'emplacement des abribus. Partant de ces données, je les ai croisées à l'aide du plugin conflation avec les arrêts de bus déjà présents dans OSM et j'ai fait la fusion par étape (10m, 20m puis 50m maxi pour la conflation). A 10 et 20m, j'ai fait un contrôle aléatoire avec Bing qui m'a confirmé que les données de la ville de Paris sont précises (on a même la forme de l'abribus, mais je n'ai gardé qu'un noeud). A 50m, j'ai vérifié un à un. Ensuite j'ai repris le fichier RATP et je l'ai croisé avec les abribus restants en vérifiant cette fois-ci un à un. Résultat, 1212 abribus intégrés, visible ici: http://bit.ly/abribus-paris -- Christian Quest - OpenStreetMap France - http://openstreetmap.fr/u/cquest ___ 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] Arrêt de bus de Paris...
Oui, il y a bien 2 abribus, un de chaque côté de l'Avenue de l'Opéra... comme dans la très grande majorité des cas. Le ref:FR:RATP est d'ailleurs différent. Je n'ai pas encore attaqué le niveau suivant, c'est à dire les relations public_transport pour décrire les stop_area, cela ne vaudra le coup je pense que lorsqu'il y aura nettement pus d'arrêt qu'actuellement. Pour les shelter=yes;no, il faut que je vérifie... le yes provient de mes abribus, et le no étaient là avant... donc il y a une incohérence à vérifier que je noterai dans un FIXME plutôt que cet étrange yes;no ! Je ne sais pas comment xapiviewer se comporte pour afficher les détails des objets. Cette visualisation est brute de décoffrage juste pour donner une idée de l'étendue de cette intégration. -- 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?
2012/11/29 Christian Quest cqu...@openstreetmap.fr 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. Sauf que dans le wiki on lit ca : * * *The landuse tag is mostly used for larger areas and not at parcel granularity; as described above, a single shop in a residential area does not warrant an extra commercial landuse.* Il se trouve que pour une résidence avec deux ou trois petit immeuble inclus dans un quartier résidentiel, superposer une micro landuse juste pour le nom ne me semble pas plus pertinent que ça ... c'est a mon avis encore pire que pour les landuse=school. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
