Re: [OSM-talk-fr] Suppression d'éléments dupliqués
Désolé, c'est tellement facile que je n'ai pas pu résister. C'est corrigé. Une requete Turbo Overpass en utilisant le wisard natural=tree in Nice puis un export sous josm. Passage du validator, réparation (automatique) des erreurs (1000 effectivement) et upload. Note : josm me dit que type=conifer est obsolète ; je dis ça, je dis rien... A+ Marc Sibert m...@sibert.fr Le 7 août 2015 23:38, sebastien.bugzi...@gmail.com sebastien.bugzi...@gmail.com a écrit : Salut Il me semble que josm permet de corriger les noeuds confondus. Il suffit d'importer la zone, puis de faire une validation. Il devrait détecter les noeuds dupliqués. Et tu as juste à cliquer sur réparer pour qu'il corrige le problème. Puis renvoyer évidemment. Sébastien On 07/08/2015 23:06, Vincent Frison wrote: Hello, J'ai fait l'import des arbres municipaux de Nice: l'import pour modifier les éléments existants s'est bien passé (835 éléments) mais manque de bol il y a eu un problème (réseau à priori) pour l'import des nouveaux arbres (29 411 éléments). JOSM a arrêté l'upload en plein milieu du transfert avec un message ressemblant à premature end of file :( En tentant d'uploader à nouveau JOSM a pu finir l'upload, visiblement sans souci.. sauf qu'en regardant de plus près le changeset ( https://www.openstreetmap.org/changeset/33108671) on peut voir qu'il y a eu 30 411 éléments, soit 1000 de plus que prévu ! Or j'avais justement configuré JOSM pour faire des blocs de 1000 requêtes, il est donc à peu près clair que suite à un problème réseau JOSM a cru qu'un bloc n'avait pas été uploadé alors qu'en fait si.. et du coup il a uploadé à nouveau ce bloc en créant 1000 doublons. J'ai pas mal galéré avec Overpass pour trouver ces élément dupliqués, j'en ai retrouvé environ 200 pour l'instant. En fait j'ai trouvé sur le net une requête qui marche bien mais elle prend un temps fou, impossible de la faire sur l'ensemble de Nice (à priori c'est un bug d'Overpass). Sinon il y a aussi le site keepright.at qui permet d'afficher les doublons mais leur données ne sont pas encore à jour. Peut-être qu'Osmose pourrait m'aider ? Bon ceci dit même avec la liste exhaustive des éléments dupliqués il resterait quand même le boulot d'effacement à faire. Je pourrais faire un petit script pour cela mais peut-etre que dans mon cas la solution la plus efficace et surtout la plus simple serait de simplement faire un revert pour pouvoir ensuite refaire l'import proprement (en partant du principe que je n'aurais plus de problème réseau) ? Après je suis pas sûr de bien comprendre ce que fait un revert, dans mon cas les nouveaux arbres créés seront supprimés, mais quelque part ils existeront toujours dans l'historique ? L'idéal serait de vraiment annuler comme si rien ne s'était passé mais je sais pas si c'est possible... Merci pour votre aide, Vincent. ___ Talk-fr mailing listTalk-fr@openstreetmap.orghttps://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] YoHours (était: outil user-friendly pour taguer les horaires opening_hours)
Le 8 août 2015 01:58, Sébastien Dinot sebastien.di...@free.fr a écrit : Bonsoir, PanierAvide a écrit : N'hésitez pas à faire des retours ;) Application fort utile et sympathique. Merci beaucoup ! En plus, il m'a amené à découvrir que je n'avais pas pleinement compris la spécification des heures d'ouverture. :) Par exemple, dans le cas suivant : Lundide 7h à 10h et de 12h à 14h Mardide 7h à 10h et de 12h à 14h Mercredi de 7h à 10h Jeudide 7h à 10h et de 12h à 14h Vendredi de 7h à 10h et de 12h à 14h J'aurais déclaré ainsi les plages d'ouverture : Mo-Tu 07:00-10:00,12:00-14:00; We 07:00-10:00; Th-Fr 07:00-10:00,12:00-14:00 Et j'aurais juré que c'était la seule façon de faire. Mais je viens de découvrir en testant YoHours que l'on peut aussi procéder ainsi : Mo-Fr 07:00-10:00,12:00-14:00; We 07:00-10:00 = Des plages horaires spécifiques étant déclarées pour le mercredi, elles font exception à la première règle qui, prise isolément, englobe le mercredi. Je vais me coucher un peu moins ignare. ;) Sébastien Je trouve cette syntaxe avec les exceptions un peu ambigüe car nécessitant un surplus d'interprétation par un algorithme. J'écrirais : Mo-Fr,Tu-Fr 07:00-10:00,12:00-14:00; We 07:00-10:00 qui est à peine plus long, et surtout sans équivoque (pas de plages qui se recoupent). PY ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] YoHours (était: outil user-friendly pour taguer les horaires opening_hours)
Lire Mo-Tu,Th-Fr 07:00-10:00,12:00-14:00; We 07:00-10:00 dans mon précédent message * ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] YoHours (était: outil user-friendly pour taguer les horaires opening_hours)
Après le surplus d'interprétation n'est pas énorme, tant que c'est bien spécifié on s'en sort ;) Puis autant côté saisie utilisateur on a un petit manque d'outils (un peu moins j'espère avec YoHours), autant côté lecture de la syntaxe pour affichage on a pas mal de bibliothèques dont opening_hours.js qui fait très bien le boulot et qui gère de nombreuses cas complexes de la syntaxe (elle sert dans YoHours à interpréter les saisies utilisateurs pour afficher sur le calendrier). On peut féliciter ses auteurs ;) Le 08/08/2015 09:40, Pierre-Yves Berrard a écrit : Lire Mo-Tu,Th-Fr 07:00-10:00,12:00-14:00; We 07:00-10:00 dans mon précédent message * ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] osmose: analyse croisement BANO/OSM à tester...
Le 05/08/2015 21:17, Christian Quest a écrit : Le 5 août 2015 20:26, lenny.libre lenny.li...@orange.fr mailto:lenny.li...@orange.fr a écrit : Sacré bon travail. faux positif pour cas ambigus : http://dev.osmose.openstreetmap.fr/fr/map/#item=7170class=30zoom=18lat=44.045364lon=-0.536378layer=Mapnikoverlays=FFFT Dans ce cas, l'erreur name=* ou route potentiellement manquante à proximité : Rue des Forgerons (400560085U) alors que le name et le FANTOIR sont corrects présents sur la relation http://www.openstreetmap.org/relation/2857909 Le name n'est que sur la relation d'où le signalement... il devrait aussi être sur le way. Il me semblait que les relations évitaient de dupliquer les attributs (sur les membres de la relation) https://www.mail-archive.com/talk-fr@openstreetmap.org/msg19866.html En général (je n'ai créé que des relations associatedStreet et waterway) je n'ai pas dupliqué les names et ref (sauf s'ils y étaient déjà, dans ce cas, je ne les supprime pas). ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Suppression d'éléments dupliqués
Super, merci Marc ! Je savais pas qu'on pouvait exporter directement depuis Turbo Overpass vers JOSM, c'est bien pratique... Et effectivement pas besoin de récupérer uniquement les arbres dupliqués (la requête fait énormément ramer Overpass), autant récupérer TOUS les arbres (dupliqués ou non) puis laisser JOSM faire le ménage. PS: pour les arbres qui ont le tag type=conifer (ou palm) ce sont des arbres existants qui avaient déjà ce tag obsolète, je vais essayer d'en corriger à la main.. Le 8 août 2015 08:25, Marc SIBERT m...@sibert.fr a écrit : Désolé, c'est tellement facile que je n'ai pas pu résister. C'est corrigé. Une requete Turbo Overpass en utilisant le wisard natural=tree in Nice puis un export sous josm. Passage du validator, réparation (automatique) des erreurs (1000 effectivement) et upload. Note : josm me dit que type=conifer est obsolète ; je dis ça, je dis rien... A+ Marc Sibert m...@sibert.fr Le 7 août 2015 23:38, sebastien.bugzi...@gmail.com sebastien.bugzi...@gmail.com a écrit : Salut Il me semble que josm permet de corriger les noeuds confondus. Il suffit d'importer la zone, puis de faire une validation. Il devrait détecter les noeuds dupliqués. Et tu as juste à cliquer sur réparer pour qu'il corrige le problème. Puis renvoyer évidemment. Sébastien On 07/08/2015 23:06, Vincent Frison wrote: Hello, J'ai fait l'import des arbres municipaux de Nice: l'import pour modifier les éléments existants s'est bien passé (835 éléments) mais manque de bol il y a eu un problème (réseau à priori) pour l'import des nouveaux arbres (29 411 éléments). JOSM a arrêté l'upload en plein milieu du transfert avec un message ressemblant à premature end of file :( En tentant d'uploader à nouveau JOSM a pu finir l'upload, visiblement sans souci.. sauf qu'en regardant de plus près le changeset ( https://www.openstreetmap.org/changeset/33108671) on peut voir qu'il y a eu 30 411 éléments, soit 1000 de plus que prévu ! Or j'avais justement configuré JOSM pour faire des blocs de 1000 requêtes, il est donc à peu près clair que suite à un problème réseau JOSM a cru qu'un bloc n'avait pas été uploadé alors qu'en fait si.. et du coup il a uploadé à nouveau ce bloc en créant 1000 doublons. J'ai pas mal galéré avec Overpass pour trouver ces élément dupliqués, j'en ai retrouvé environ 200 pour l'instant. En fait j'ai trouvé sur le net une requête qui marche bien mais elle prend un temps fou, impossible de la faire sur l'ensemble de Nice (à priori c'est un bug d'Overpass). Sinon il y a aussi le site keepright.at qui permet d'afficher les doublons mais leur données ne sont pas encore à jour. Peut-être qu'Osmose pourrait m'aider ? Bon ceci dit même avec la liste exhaustive des éléments dupliqués il resterait quand même le boulot d'effacement à faire. Je pourrais faire un petit script pour cela mais peut-etre que dans mon cas la solution la plus efficace et surtout la plus simple serait de simplement faire un revert pour pouvoir ensuite refaire l'import proprement (en partant du principe que je n'aurais plus de problème réseau) ? Après je suis pas sûr de bien comprendre ce que fait un revert, dans mon cas les nouveaux arbres créés seront supprimés, mais quelque part ils existeront toujours dans l'historique ? L'idéal serait de vraiment annuler comme si rien ne s'était passé mais je sais pas si c'est possible... Merci pour votre aide, Vincent. ___ Talk-fr mailing listTalk-fr@openstreetmap.orghttps://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Nettoyage en lot
Je te sens motivé pour un script modifiant et notifiant le dernier modificateur (ou celui qui a introduit le name=) en lui expliquant le pourquoi du comment ;-). Prévoir la possibilité de nous contacter si l'édition ne plait pas. Eric, tu voulais dire : name~^arbre$ je suppose. S'il y a quelque chose devant, ce serait dommage de supprimer. D'une manière générale un name= ou name:*= dont la valeur est le nom d'un attribut est un cas à traiter. Jean-Yvon Le 07/08/2015 19:02, Christian Quest - cqu...@openstreetmap.fr a écrit : Rien que sur natural=tree, on trouve des name=Arbre, arbre, Tree, tree.. overpass en trouve environ 1400. Tout ça mériterai un mechanical edit ;) Le 07/08/2015 18:47, Éric Gillet a écrit : 2015-08-07 15:04 GMT+02:00 David Crochet david.croc...@free.fr mailto:david.croc...@free.fr: Je crois qu'il y a du nettoyage à faire dans ce coin (usage immodéré de name=) http://www.openstreetmap.org/node/2939695883 Un autre cas plus réduit ici http://www.openstreetmap.org/node/3499050736 (Merci Overpass http://overpass-turbo.eu/s/aPo) -- Christian Quest - OpenStreetMap France ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] osmose: analyse croisement BANO/OSM à tester...
Le 8 août 2015 11:08, lenny.libre lenny.li...@orange.fr a écrit : Le 05/08/2015 21:17, Christian Quest a écrit : Le 5 août 2015 20:26, lenny.libre lenny.li...@orange.fr a écrit : Sacré bon travail. faux positif pour cas ambigus : http://dev.osmose.openstreetmap.fr/fr/map/#item=7170class=30zoom=18lat=44.045364lon=-0.536378layer=Mapnikoverlays=FFFT http://dev.osmose.openstreetmap.fr/fr/map/#item=7170class=30zoom=18lat=44.045364lon=-0.536378layer=Mapnikoverlays=FFFT Dans ce cas, l'erreur name=* ou route potentiellement manquante à proximité : Rue des Forgerons (400560085U) alors que le name et le FANTOIR sont corrects présents sur la relation http://www.openstreetmap.org/relation/2857909 Le name n'est que sur la relation d'où le signalement... il devrait aussi être sur le way. Il me semblait que les relations évitaient de dupliquer les attributs (sur les membres de la relation) https://www.mail-archive.com/talk-fr@openstreetmap.org/msg19866.html https://www.mail-archive.com/talk-fr@openstreetmap.org/msg19866.html Pas tout à fait si on y réfléchit bien. name=* ici s'applique bien à la voie, et la relation ne fait qu'associer des adresses à cette voie, pas à leur donner aussi un name=* et donc pas plus pour les autres membres de la relation que sont les morceaux de voirie. Une relation associatedStreet permet de ne pas remettre un addr:street sur chaque adresse, ce qui n'est pas négligeable en terme de volume de données vu la quantité d'adresses. En général (je n'ai créé que des relations associatedStreet et waterway) je n'ai pas dupliqué les names et ref (sauf s'ils y étaient déjà, dans ce cas, je ne les supprime pas). Le wiki est il me semble clair, les name et ref sont bien à mettre sur les way de voirie, pas sur les relations qui établissent le lien adresse/voie. -- Christian Quest - OpenStreetMap France ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Réseau de point d'accès d'urgence sur site difficile de localisation aux secours
En cherchant un peu je suis tombé sur emergency=sos_point. Utilisé sur le Parc de Sceaux : http://overpass-turbo.eu/s/aLC En Europe sinon il y a Borkum à avoir ce tag, qui lui a aussi les tags highway=emergency_access_point Est-ce que sur le Parc de Sceaux il ne s'agit pas de highway=emergency_access_point ? Avez-vous des infos complémentaires ? Jean-Yvon (pas local de l'étape ;-), je m'y suis collé pour les défibrillateurs). ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Nettoyage en lot
J'avais bien mis name=arbre (égalité stricte) et pas name~arbre (expression régulière contient). Un script qui envoie des mail... mouais, ou alors plutôt sortir juste la liste des derniers contributeurs les plus fréquents et récemment... Le 8 août 2015 17:49, osm.sanspourr...@spamgourmet.com a écrit : Je te sens motivé pour un script modifiant et notifiant le dernier modificateur (ou celui qui a introduit le name=) en lui expliquant le pourquoi du comment ;-). Prévoir la possibilité de nous contacter si l'édition ne plait pas. Eric, tu voulais dire : name~^arbre$ je suppose. S'il y a quelque chose devant, ce serait dommage de supprimer. D'une manière générale un name= ou name:*= dont la valeur est le nom d'un attribut est un cas à traiter. Jean-Yvon Le 07/08/2015 19:02, Christian Quest - cqu...@openstreetmap.fr a écrit : Rien que sur natural=tree, on trouve des name=Arbre, arbre, Tree, tree.. overpass en trouve environ 1400. Tout ça mériterai un mechanical edit ;) Le 07/08/2015 18:47, Éric Gillet a écrit : 2015-08-07 15:04 GMT+02:00 David Crochet david.croc...@free.fr: Je crois qu'il y a du nettoyage à faire dans ce coin (usage immodéré de name=) http://www.openstreetmap.org/node/2939695883 Un autre cas plus réduit ici http://www.openstreetmap.org/node/3499050736 (Merci Overpass http://overpass-turbo.eu/s/aPo) -- Christian Quest - OpenStreetMap France ___ Talk-fr mailing listTalk-fr@openstreetmap.orghttps://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr -- Christian Quest - OpenStreetMap France ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Nettoyage en lot
Je disais Eric, pas Christian, je suppose qu'Eric voulait trouver les arbre et les Arbre. Récemment ? Je ne suis pas affirmatif : ça peut montrer à d'anciens contributeurs que leurs données servent (même si on les corrige) et ça peut les motiver à continuer. Jean-Yvon Le 08/08/2015 17:55, Christian Quest - cqu...@openstreetmap.fr a écrit : J'avais bien mis name=arbre (égalité stricte) et pas name~arbre (expression régulière contient). Un script qui envoie des mail... mouais, ou alors plutôt sortir juste la liste des derniers contributeurs les plus fréquents et récemment... Le 8 août 2015 17:49, osm.sanspourr...@spamgourmet.com mailto:osm.sanspourr...@spamgourmet.com a écrit : Je te sens motivé pour un script modifiant et notifiant le dernier modificateur (ou celui qui a introduit le name=) en lui expliquant le pourquoi du comment ;-). Prévoir la possibilité de nous contacter si l'édition ne plait pas. Eric, tu voulais dire : name~^arbre$ je suppose. S'il y a quelque chose devant, ce serait dommage de supprimer. D'une manière générale un name= ou name:*= dont la valeur est le nom d'un attribut est un cas à traiter. Jean-Yvon Le 07/08/2015 19:02, Christian Quest - cqu...@openstreetmap.fr mailto:cqu...@openstreetmap.fr a écrit : Rien que sur natural=tree, on trouve des name=Arbre, arbre, Tree, tree.. overpass en trouve environ 1400. Tout ça mériterai un mechanical edit ;) Le 07/08/2015 18:47, Éric Gillet a écrit : 2015-08-07 15:04 GMT+02:00 David Crochet david.croc...@free.fr mailto:david.croc...@free.fr: Je crois qu'il y a du nettoyage à faire dans ce coin (usage immodéré de name=) http://www.openstreetmap.org/node/2939695883 Un autre cas plus réduit ici http://www.openstreetmap.org/node/3499050736 (Merci Overpass http://overpass-turbo.eu/s/aPo) -- Christian Quest - OpenStreetMap France ___ Talk-fr mailing list Talk-fr@openstreetmap.org mailto:Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org mailto:Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr -- Christian Quest - OpenStreetMap France ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Nettoyage en lot
Le 8 août 2015 18:04, osm.sanspourr...@spamgourmet.com a écrit : Je disais Eric, pas Christian, je suppose qu'Eric voulait trouver les arbre et les Arbre. Oups ! Récemment ? Je ne suis pas affirmatif : ça peut montrer à d'anciens contributeurs que leurs données servent (même si on les corrige) et ça peut les motiver à continuer. Jean-Yvon Contacter des contributeurs peu actif peut les réactiver, c'est vrai... il y a de quoi faire vu la quantité de choses qu'on a dans osmose. J'avais pensé il y a quelques années à scripter l'envoi d'un message interne OSM aux contributeurs pour leur leur faire connaitre osmose à travers les erreurs présentes sur les objets pour lesquels ils étaient le dernier éditeur. Mais je m'étais ravisé en pensant que c'était quand même une approche un peu trop négative... tout dépend finalement de la forme. -- Christian Quest - OpenStreetMap France ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Nettoyage en lot
Jusqu'à présent quand j'ai signalé à des contributeurs des problème ou que j'avais corrigé des problèmes, je n'ai eu aucun retour négatif. C'est bien essentiellement une question de forme (et de quantité : si le script envoie un message chaque fois qu'une personne fait une erreur, ça ne va pas le faire !). Oui on a d'excellents outils et on ne les promeut pas assez. Quand tu te connectes sur OSM, tu as le nombre de messages non lus. Tu pourrais avoir : - le nombre de suggestions d'amélioration sur tes entrées selon osmose (avec le lien qui va bien). - peut-être le nombre de suggestions pour ta zone (au risque de dégoûter). Au fait y-a-t-il possibilité d'utiliser les outils osmose dans JOSM ? Sinon c'est une idée de greffon de validation ;-). Jean-Yvon Le 08/08/2015 18:31, Christian Quest - cqu...@openstreetmap.fr a écrit : Contacter des contributeurs peu actif peut les réactiver, c'est vrai... il y a de quoi faire vu la quantité de choses qu'on a dans osmose. J'avais pensé il y a quelques années à scripter l'envoi d'un message interne OSM aux contributeurs pour leur leur faire connaitre osmose à travers les erreurs présentes sur les objets pour lesquels ils étaient le dernier éditeur. Mais je m'étais ravisé en pensant que c'était quand même une approche un peu trop négative... tout dépend finalement de la forme. -- Christian Quest - OpenStreetMap France ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Nettoyage en lot
Rions un peu : comme je voyais que notre tagueur name=arbre favori avait indique que le jardin devant l'Hôtel Gabriel s'appela jardin de l'hôtel gabriel j'ai demandé à un moteur de recherche s'il connaissait le jardin de l'Hôtel Gabriel. Si oui je ne voulais pas supprimer. Je suis tombé sur cette page, http://www.llegalemapas.com/information/fr/w290312480/jardin_de_l%27h%C3%B4tel_gabriel.html, regardez les lieux proches selon ce site ;-). Pendant le Festival Interceltique de Lorient http://www.festival-interceltique.bzh/actualite/index.cfm/le-jardin-des-luthiers.html allez constater qu'il y a beaucoup d'arbre à Lorient. Dépêchez vous, je fais le ménage. N. B. : le jardin est bien un lieu en tant que tel (comme le lien du FIL le montre). jardin de l'Hôtel Gabriel devant l'Hôtel Gabriel, ça fait un peu bizarre. Comme il y a l'attribut leisure=garden et que le jardin est proche de l'Hôtel, est-il nécessaire d'avoir le nom pour Nominatim ? Je suis pour garder le nom car il est à côté mais n'est pas contigu de l'Hôtel Gabriel. Actuellement il y a 4 polygones, j'ajoute une relation multi-polygone avec le nom dessus ? Jean-Yvon Le 08/08/2015 18:04, osm.sanspourr...@spamgourmet.com a écrit : Je disais Eric, pas Christian, je suppose qu'Eric voulait trouver les arbre et les Arbre. Récemment ? Je ne suis pas affirmatif : ça peut montrer à d'anciens contributeurs que leurs données servent (même si on les corrige) et ça peut les motiver à continuer. Jean-Yvon Le 08/08/2015 17:55, Christian Quest - cqu...@openstreetmap.fr a écrit : J'avais bien mis name=arbre (égalité stricte) et pas name~arbre (expression régulière contient). Un script qui envoie des mail... mouais, ou alors plutôt sortir juste la liste des derniers contributeurs les plus fréquents et récemment... Le 8 août 2015 17:49, osm.sanspourr...@spamgourmet.com a écrit : Je te sens motivé pour un script modifiant et notifiant le dernier modificateur (ou celui qui a introduit le name=) en lui expliquant le pourquoi du comment ;-). Prévoir la possibilité de nous contacter si l'édition ne plait pas. Eric, tu voulais dire : name~^arbre$ je suppose. S'il y a quelque chose devant, ce serait dommage de supprimer. D'une manière générale un name= ou name:*= dont la valeur est le nom d'un attribut est un cas à traiter. Jean-Yvon Le 07/08/2015 19:02, Christian Quest - cqu...@openstreetmap.fr a écrit : Rien que sur natural=tree, on trouve des name=Arbre, arbre, Tree, tree.. overpass en trouve environ 1400. Tout ça mériterai un mechanical edit ;) Le 07/08/2015 18:47, Éric Gillet a écrit : 2015-08-07 15:04 GMT+02:00 David Crochet david.croc...@free.fr: Je crois qu'il y a du nettoyage à faire dans ce coin (usage immodéré de name=) http://www.openstreetmap.org/node/2939695883 Un autre cas plus réduit ici http://www.openstreetmap.org/node/3499050736 (Merci Overpass http://overpass-turbo.eu/s/aPo) -- Christian Quest - OpenStreetMap France ___ Talk-fr mailing list Talk-fr@openstreetmap.org mailto:Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org mailto:Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr -- Christian Quest - OpenStreetMap France ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Nettoyage en lot
Le 08/08/2015 20:09, osm.sanspourr...@spamgourmet.com a écrit : Jusqu'à présent quand j'ai signalé à des contributeurs des problème ou que j'avais corrigé des problèmes, je n'ai eu aucun retour négatif. C'est bien essentiellement une question de forme Oui. Et le fait que le message soit « automatique » fait que la forme n'y est pas. Et même lors (de tentative) de sondage auprès des contributeurs, l'utilisation des messageries OSM est mal vue. (et de quantité : si le script envoie un message chaque fois qu'une personne fait une erreur, ça ne va pas le faire !). Oui on a d'excellents outils et on ne les promeut pas assez. Quand tu te connectes sur OSM, tu as le nombre de messages non lus. Tu pourrais avoir : - le nombre de suggestions d'amélioration sur tes entrées selon osmose (avec le lien qui va bien). - peut-être le nombre de suggestions pour ta zone (au risque de dégoûter). Au fait y-a-t-il possibilité d'utiliser les outils osmose dans JOSM ? Sinon c'est une idée de greffon de validation ;-). Voir qat_script avec le plugin scripting : http://wiki.openstreetmap.org/wiki/Quality_Assurance_Tools_script/Installation Jean-Yvon Le 08/08/2015 18:31, Christian Quest - cqu...@openstreetmap.fr a écrit : Contacter des contributeurs peu actif peut les réactiver, c'est vrai... il y a de quoi faire vu la quantité de choses qu'on a dans osmose. J'avais pensé il y a quelques années à scripter l'envoi d'un message interne OSM aux contributeurs pour leur leur faire connaitre osmose à travers les erreurs présentes sur les objets pour lesquels ils étaient le dernier éditeur. Mais je m'étais ravisé en pensant que c'était quand même une approche un peu trop négative... tout dépend finalement de la forme. -- Christian Quest - OpenStreetMap France ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Nettoyage en lot
Le 08/08/2015 20:50, JB - jb...@mailoo.org a écrit : Le 08/08/2015 20:09, osm.sanspourr...@spamgourmet.com a écrit : Au fait y-a-t-il possibilité d'utiliser les outils osmose dans JOSM ? Sinon c'est une idée de greffon de validation ;-). Voir qat_script avec le plugin scripting : http://wiki.openstreetmap.org/wiki/Quality_Assurance_Tools_script/Installation Merci, j'ai profité pour faire une version française. http://wiki.openstreetmap.org/wiki/FR:Quality_Assurance_Tools_script/Installation Ça reste bien compliqué pour l'utilisateur lambda, idéalement il faudrait arriver à guider l'utilisateur lors des premières utilisations (avec des notions de niveau ou/et de contexte). Effectivement il ne faut pas trop utiliser la messagerie. Si dans les préférences on peut indiquer que l'on veut des compteurs Osmose (et que ça le soit par défaut), rapidement on devrait inciter les utilisateurs à l'utiliser. On peut imaginer que ce nombre pointe sur une page : - vers Osmose (sur la zone qui va bien) - vers le guide d'installation d'Osmose sous JOSM - si possible vers un téléchargement de ces erreurs sous JOSM. Jean-Yvon ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
