Re: [OSM-talk-fr] Importation des arbres municipaux sur Nice
Bon à y regarder de plus prêt on dirait que ce sont les routes qui ont été malmenées dans ce coin et que les arbres sont plutôt aux bons emplacements ! On 03 Aug 2015, at 11:45, Vladimir Vyskocil vladimir.vysko...@gmail.com wrote: C’est dangereux de rouler sur le Boulevard René Cassin par exemple ;-) http://www.openstreetmap.org/?mlat=43.66954mlon=7.21884#map=19/43.66954/7.21884 http://www.openstreetmap.org/?mlat=43.66954mlon=7.21884#map=19/43.66954/7.21884 Je suppose que ce sont des arbres d’un import précédent ? Vlad. On 01 Aug 2015, at 19:02, Vincent Frison vincent.fri...@gmail.com mailto:vincent.fri...@gmail.com wrote: Alors j'ai rajouté la petite vérification pour savoir si l'arbre importé est à l'intérieur d'un bâtiment ou pas. Cela permet donc d'avoir un fichier à part avec les arbres posant problème. Voici les dernières stats: Total of makable imports: 30246 Total of non makable imports: 275 Matching area radius: 5.0 Total of created trees: 29430 Total of updated trees: 816 Total of created or updated trees: 30246 Total of multi matching trees: 306 Il y a donc 275 arbres posant problème qu'on peut en gros diviser en 2 catégories: - les arbres qui sont collés à un bâtiment mais qui se retrouvent à l'intérieur comme c'est le cas pour la basilique Notre Dame (difficile de dire qui a raison ou tort). Il y en a environ une bonne quarantaine comme ça... - les arbres qui sont à l'intérieur d'un bâtiment parce que celui ci est mal fait dans OSM (ex: bibliothèque bien plus grande que la réalité et qui englobe son parc, ou bâtiment d'école simplifié ne laisse plus de place à sa cour interne, etc.). C'est du coup un bon test pour voir des corrections à faire (une sorte de mini osmose ;p), je conserve donc ce fichier pour faire certaines corrections plus tard et pouvoir ensuite importer certains arbres normalement, merci Jérôme pour l'idée. En attendant je compte bien uploader les 30 246 autres arbres qui sont hors bâtiments.. sauf si évidemment vous me dites que cela entraînera forcement un revert et mon bannissement du forum sur les 3 prochaines générations.. Le 31 juillet 2015 00:00, Vincent Frison vincent.fri...@gmail.com mailto:vincent.fri...@gmail.com a écrit : Le 30 juillet 2015 23:24, Jérôme Seigneuret jseigneuret-...@yahoo.fr mailto:jseigneuret-...@yahoo.fr a écrit : Oui pour empêcher l'import mais on n'est pas à 15 cm sur le placement des bâtiments aussi donc qui a raison? Il faudrait genre un pré-filtre. Si tu fais ça sous JOSM il doit bien être possible de faire comme sous n'importe quel SIG un tag intermédiaire note=FIXME et tu n'intègres que ceux sans alerte. Les autres c'est à mettre dans un fichier *.osm et à retoucher au fur et à mesure pour faire l'intégration en semi-auto par exemple par type d'alerte. C'est plus simple et au moins il n'y a plus d’ambiguïté. Le plus simple c'est encore d'ignorer purement et simplement tous les éléments posant problème. Mais je trouve que c'est une bonne idée de garder ces éléments dans un fichier à part.. histoire de ne rien lâcher ! ;p Je ferai ça ce WE.. ___ 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 https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Importation des arbres municipaux sur Nice
C’est dangereux de rouler sur le Boulevard René Cassin par exemple ;-) http://www.openstreetmap.org/?mlat=43.66954mlon=7.21884#map=19/43.66954/7.21884 http://www.openstreetmap.org/?mlat=43.66954mlon=7.21884#map=19/43.66954/7.21884 Je suppose que ce sont des arbres d’un import précédent ? Vlad. On 01 Aug 2015, at 19:02, Vincent Frison vincent.fri...@gmail.com wrote: Alors j'ai rajouté la petite vérification pour savoir si l'arbre importé est à l'intérieur d'un bâtiment ou pas. Cela permet donc d'avoir un fichier à part avec les arbres posant problème. Voici les dernières stats: Total of makable imports: 30246 Total of non makable imports: 275 Matching area radius: 5.0 Total of created trees: 29430 Total of updated trees: 816 Total of created or updated trees: 30246 Total of multi matching trees: 306 Il y a donc 275 arbres posant problème qu'on peut en gros diviser en 2 catégories: - les arbres qui sont collés à un bâtiment mais qui se retrouvent à l'intérieur comme c'est le cas pour la basilique Notre Dame (difficile de dire qui a raison ou tort). Il y en a environ une bonne quarantaine comme ça... - les arbres qui sont à l'intérieur d'un bâtiment parce que celui ci est mal fait dans OSM (ex: bibliothèque bien plus grande que la réalité et qui englobe son parc, ou bâtiment d'école simplifié ne laisse plus de place à sa cour interne, etc.). C'est du coup un bon test pour voir des corrections à faire (une sorte de mini osmose ;p), je conserve donc ce fichier pour faire certaines corrections plus tard et pouvoir ensuite importer certains arbres normalement, merci Jérôme pour l'idée. En attendant je compte bien uploader les 30 246 autres arbres qui sont hors bâtiments.. sauf si évidemment vous me dites que cela entraînera forcement un revert et mon bannissement du forum sur les 3 prochaines générations.. Le 31 juillet 2015 00:00, Vincent Frison vincent.fri...@gmail.com mailto:vincent.fri...@gmail.com a écrit : Le 30 juillet 2015 23:24, Jérôme Seigneuret jseigneuret-...@yahoo.fr mailto:jseigneuret-...@yahoo.fr a écrit : Oui pour empêcher l'import mais on n'est pas à 15 cm sur le placement des bâtiments aussi donc qui a raison? Il faudrait genre un pré-filtre. Si tu fais ça sous JOSM il doit bien être possible de faire comme sous n'importe quel SIG un tag intermédiaire note=FIXME et tu n'intègres que ceux sans alerte. Les autres c'est à mettre dans un fichier *.osm et à retoucher au fur et à mesure pour faire l'intégration en semi-auto par exemple par type d'alerte. C'est plus simple et au moins il n'y a plus d’ambiguïté. Le plus simple c'est encore d'ignorer purement et simplement tous les éléments posant problème. Mais je trouve que c'est une bonne idée de garder ces éléments dans un fichier à part.. histoire de ne rien lâcher ! ;p Je ferai ça ce WE.. ___ 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] Importation des arbres municipaux sur Nice
Effectivement les positions des arbres sont plutôt bonnes et d'ailleurs mon import (que je n'ai pas encore appliqué !!) ne va les déplacer que sur quelques centimètres (1 mètre max). Ceci dit j'ai pas bien compris ce qui vous gêne actuellement car pour moi les arbres tout comme les routes (les 2 axes du boulevard + la voie de service au milieu) sont déjà assez bien placés... Le 3 août 2015 15:47, Jérôme Seigneuret jseigneuret-...@yahoo.fr a écrit : J'allais dire là même chose. La données à plutôt l'air de bonne qualité. Plus que celle du réseau. Je vais retoucher le réseau routier en conséquence. Le 3 août 2015 11:49, Vladimir Vyskocil vladimir.vysko...@gmail.com a écrit : Bon à y regarder de plus prêt on dirait que ce sont les routes qui ont été malmenées dans ce coin et que les arbres sont plutôt aux bons emplacements ! On 03 Aug 2015, at 11:45, Vladimir Vyskocil vladimir.vysko...@gmail.com wrote: C’est dangereux de rouler sur le Boulevard René Cassin par exemple ;-) http://www.openstreetmap.org/?mlat=43.66954mlon=7.21884#map=19/43.66954/7.21884 Je suppose que ce sont des arbres d’un import précédent ? Vlad. On 01 Aug 2015, at 19:02, Vincent Frison vincent.fri...@gmail.com wrote: Alors j'ai rajouté la petite vérification pour savoir si l'arbre importé est à l'intérieur d'un bâtiment ou pas. Cela permet donc d'avoir un fichier à part avec les arbres posant problème. Voici les dernières stats: Total of makable imports: 30246 Total of non makable imports: 275 Matching area radius: 5.0 Total of created trees: 29430 Total of updated trees: 816 Total of created or updated trees: 30246 Total of multi matching trees: 306 Il y a donc 275 arbres posant problème qu'on peut en gros diviser en 2 catégories: - les arbres qui sont collés à un bâtiment mais qui se retrouvent à l'intérieur comme c'est le cas pour la basilique Notre Dame (difficile de dire qui a raison ou tort). Il y en a environ une bonne quarantaine comme ça... - les arbres qui sont à l'intérieur d'un bâtiment parce que celui ci est mal fait dans OSM (ex: bibliothèque bien plus grande que la réalité et qui englobe son parc, ou bâtiment d'école simplifié ne laisse plus de place à sa cour interne, etc.). C'est du coup un bon test pour voir des corrections à faire (une sorte de mini osmose ;p), je conserve donc ce fichier pour faire certaines corrections plus tard et pouvoir ensuite importer certains arbres normalement, merci Jérôme pour l'idée. En attendant je compte bien uploader les 30 246 autres arbres qui sont hors bâtiments.. sauf si évidemment vous me dites que cela entraînera forcement un revert et mon bannissement du forum sur les 3 prochaines générations.. Le 31 juillet 2015 00:00, Vincent Frison vincent.fri...@gmail.com a écrit : Le 30 juillet 2015 23:24, Jérôme Seigneuret jseigneuret-...@yahoo.fr a écrit : Oui pour empêcher l'import mais on n'est pas à 15 cm sur le placement des bâtiments aussi donc qui a raison? Il faudrait genre un pré-filtre. Si tu fais ça sous JOSM il doit bien être possible de faire comme sous n'importe quel SIG un tag intermédiaire note=FIXME et tu n'intègres que ceux sans alerte. Les autres c'est à mettre dans un fichier *.osm et à retoucher au fur et à mesure pour faire l'intégration en semi-auto par exemple par type d'alerte. C'est plus simple et au moins il n'y a plus d’ambiguïté. Le plus simple c'est encore d'ignorer purement et simplement tous les éléments posant problème. Mais je trouve que c'est une bonne idée de garder ces éléments dans un fichier à part.. histoire de ne rien lâcher ! ;p Je ferai ça ce WE.. ___ 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 ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Importation des arbres municipaux sur Nice
J'ai déjà corrigé la route en question Le 3 août 2015 19:07, Vincent Frison vincent.fri...@gmail.com a écrit : Effectivement les positions des arbres sont plutôt bonnes et d'ailleurs mon import (que je n'ai pas encore appliqué !!) ne va les déplacer que sur quelques centimètres (1 mètre max). Ceci dit j'ai pas bien compris ce qui vous gêne actuellement car pour moi les arbres tout comme les routes (les 2 axes du boulevard + la voie de service au milieu) sont déjà assez bien placés... Le 3 août 2015 15:47, Jérôme Seigneuret jseigneuret-...@yahoo.fr a écrit : J'allais dire là même chose. La données à plutôt l'air de bonne qualité. Plus que celle du réseau. Je vais retoucher le réseau routier en conséquence. Le 3 août 2015 11:49, Vladimir Vyskocil vladimir.vysko...@gmail.com a écrit : Bon à y regarder de plus prêt on dirait que ce sont les routes qui ont été malmenées dans ce coin et que les arbres sont plutôt aux bons emplacements ! On 03 Aug 2015, at 11:45, Vladimir Vyskocil vladimir.vysko...@gmail.com wrote: C’est dangereux de rouler sur le Boulevard René Cassin par exemple ;-) http://www.openstreetmap.org/?mlat=43.66954mlon=7.21884#map=19/43.66954/7.21884 Je suppose que ce sont des arbres d’un import précédent ? Vlad. On 01 Aug 2015, at 19:02, Vincent Frison vincent.fri...@gmail.com wrote: Alors j'ai rajouté la petite vérification pour savoir si l'arbre importé est à l'intérieur d'un bâtiment ou pas. Cela permet donc d'avoir un fichier à part avec les arbres posant problème. Voici les dernières stats: Total of makable imports: 30246 Total of non makable imports: 275 Matching area radius: 5.0 Total of created trees: 29430 Total of updated trees: 816 Total of created or updated trees: 30246 Total of multi matching trees: 306 Il y a donc 275 arbres posant problème qu'on peut en gros diviser en 2 catégories: - les arbres qui sont collés à un bâtiment mais qui se retrouvent à l'intérieur comme c'est le cas pour la basilique Notre Dame (difficile de dire qui a raison ou tort). Il y en a environ une bonne quarantaine comme ça... - les arbres qui sont à l'intérieur d'un bâtiment parce que celui ci est mal fait dans OSM (ex: bibliothèque bien plus grande que la réalité et qui englobe son parc, ou bâtiment d'école simplifié ne laisse plus de place à sa cour interne, etc.). C'est du coup un bon test pour voir des corrections à faire (une sorte de mini osmose ;p), je conserve donc ce fichier pour faire certaines corrections plus tard et pouvoir ensuite importer certains arbres normalement, merci Jérôme pour l'idée. En attendant je compte bien uploader les 30 246 autres arbres qui sont hors bâtiments.. sauf si évidemment vous me dites que cela entraînera forcement un revert et mon bannissement du forum sur les 3 prochaines générations.. Le 31 juillet 2015 00:00, Vincent Frison vincent.fri...@gmail.com a écrit : Le 30 juillet 2015 23:24, Jérôme Seigneuret jseigneuret-...@yahoo.fr a écrit : Oui pour empêcher l'import mais on n'est pas à 15 cm sur le placement des bâtiments aussi donc qui a raison? Il faudrait genre un pré-filtre. Si tu fais ça sous JOSM il doit bien être possible de faire comme sous n'importe quel SIG un tag intermédiaire note=FIXME et tu n'intègres que ceux sans alerte. Les autres c'est à mettre dans un fichier *.osm et à retoucher au fur et à mesure pour faire l'intégration en semi-auto par exemple par type d'alerte. C'est plus simple et au moins il n'y a plus d’ambiguïté. Le plus simple c'est encore d'ignorer purement et simplement tous les éléments posant problème. Mais je trouve que c'est une bonne idée de garder ces éléments dans un fichier à part.. histoire de ne rien lâcher ! ;p Je ferai ça ce WE.. ___ 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 ___ 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] Importation des arbres municipaux sur Nice
J'allais dire là même chose. La données à plutôt l'air de bonne qualité. Plus que celle du réseau. Je vais retoucher le réseau routier en conséquence. Le 3 août 2015 11:49, Vladimir Vyskocil vladimir.vysko...@gmail.com a écrit : Bon à y regarder de plus prêt on dirait que ce sont les routes qui ont été malmenées dans ce coin et que les arbres sont plutôt aux bons emplacements ! On 03 Aug 2015, at 11:45, Vladimir Vyskocil vladimir.vysko...@gmail.com wrote: C’est dangereux de rouler sur le Boulevard René Cassin par exemple ;-) http://www.openstreetmap.org/?mlat=43.66954mlon=7.21884#map=19/43.66954/7.21884 Je suppose que ce sont des arbres d’un import précédent ? Vlad. On 01 Aug 2015, at 19:02, Vincent Frison vincent.fri...@gmail.com wrote: Alors j'ai rajouté la petite vérification pour savoir si l'arbre importé est à l'intérieur d'un bâtiment ou pas. Cela permet donc d'avoir un fichier à part avec les arbres posant problème. Voici les dernières stats: Total of makable imports: 30246 Total of non makable imports: 275 Matching area radius: 5.0 Total of created trees: 29430 Total of updated trees: 816 Total of created or updated trees: 30246 Total of multi matching trees: 306 Il y a donc 275 arbres posant problème qu'on peut en gros diviser en 2 catégories: - les arbres qui sont collés à un bâtiment mais qui se retrouvent à l'intérieur comme c'est le cas pour la basilique Notre Dame (difficile de dire qui a raison ou tort). Il y en a environ une bonne quarantaine comme ça... - les arbres qui sont à l'intérieur d'un bâtiment parce que celui ci est mal fait dans OSM (ex: bibliothèque bien plus grande que la réalité et qui englobe son parc, ou bâtiment d'école simplifié ne laisse plus de place à sa cour interne, etc.). C'est du coup un bon test pour voir des corrections à faire (une sorte de mini osmose ;p), je conserve donc ce fichier pour faire certaines corrections plus tard et pouvoir ensuite importer certains arbres normalement, merci Jérôme pour l'idée. En attendant je compte bien uploader les 30 246 autres arbres qui sont hors bâtiments.. sauf si évidemment vous me dites que cela entraînera forcement un revert et mon bannissement du forum sur les 3 prochaines générations.. Le 31 juillet 2015 00:00, Vincent Frison vincent.fri...@gmail.com a écrit : Le 30 juillet 2015 23:24, Jérôme Seigneuret jseigneuret-...@yahoo.fr a écrit : Oui pour empêcher l'import mais on n'est pas à 15 cm sur le placement des bâtiments aussi donc qui a raison? Il faudrait genre un pré-filtre. Si tu fais ça sous JOSM il doit bien être possible de faire comme sous n'importe quel SIG un tag intermédiaire note=FIXME et tu n'intègres que ceux sans alerte. Les autres c'est à mettre dans un fichier *.osm et à retoucher au fur et à mesure pour faire l'intégration en semi-auto par exemple par type d'alerte. C'est plus simple et au moins il n'y a plus d’ambiguïté. Le plus simple c'est encore d'ignorer purement et simplement tous les éléments posant problème. Mais je trouve que c'est une bonne idée de garder ces éléments dans un fichier à part.. histoire de ne rien lâcher ! ;p Je ferai ça ce WE.. ___ 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] Importation des arbres municipaux sur Nice
Il semble acquis mai tenant que Bing Maps disparaît avec la sortie aujourd'hui ou il y a peu de Here Maps par Nokia, que Google a décidé de céder à la découpe, la cartographie chez Uber, les appareils mobiles à part. Windows 10 sort de façon anticipée et un peu dans la précipitation. L'imagerie aérienne Bing ne sera sans doute plus mise à jour du tout car Uber à déjà des accords avec d'autres sites cartographiques non libres pour les POIs, et n'auras du tout la stratégie de microfilm en terme d'ubiquité de service uses mais une telle volonté d'expansion sur le terrain des déplacements et sans doute aussi des livraisons de produits ou en tant se concurrent voire partenaire des réseaux de transport urbains (comme vient de le faire la rate pour le RER A avec un concurrent d'uber), bientôt ce serint les services à la personne à domicile et le secteur postal. Sans doute le fin donc de l'imagerie Bing sous licence libre. D'ailleurs en coupant les ponts, on n'aura ème plus non plus leurs serveurs d'images. Bing va nous manquer après la disparition déjà avant de Yahoo Maps. Il va falloir gonfler un peu plus nos sources mais sans plus aucun service à l'échelle mondiale. Here Maps propose déjà son propre système de contribution à licence non libre, comme Google ou l'IGN en France. En France on s'en sortira mais pour les projets en Afrique issue et les régions s pauvres, espérons qu'une fera un geste en publiant de l'imagerie suffisante et à jour. Pour HOT on aura encore des sources Nasa et CNES/Arianespace pour les zones es de catastrophe, mais ce sera dur de combler le vide d Si Bing arrête ses services et Uber ne les reprends pas dans Here... Le 30 juil. 2015 23:09, Vincent Frison vincent.fri...@gmail.com a écrit : Le 30 juillet 2015 09:29, Christian Quest cqu...@openstreetmap.fr a écrit : On a un arbre dans la basilique Notre-Dame, des arbres à moins d'1m de certaines highway (non pedestrian). Des problèmes de calage ? De quel côté OSM ou opendata ? Place Masséna, il y a des différences avec Bing (qui date de 2012)... de nouveaux arbres y ont été plantés ou alors ils sont si petit qu'on ne les distingue pas sur l'ortho (ni sur Google Street View en septembre 2014) ? J'ai donc un doute sur la qualité des données en opendata. Sont-elles bien à jour ? Les algo de rapprochement semblent corrects, mais ne peuvent pas faire de miracle. C'est pas toujours évident à dire qui est en cause, par exemple pour la basilique cet élément correspond bien à un palmier réel collé à l'extérieur de l'église et ça se joue à quelques dizaines de centimètres. Mais ce que je vais faire c'est rajouter un filtre pour empêcher l'import d'un arbre localisé à l'intérieur d'élément ayant le tag building (ou autre chose?), c'est un truc j'aurais du penser dès le début. Il faut savoir que beaucoup d'axes dans Nice ont été refait ces dernières années et le mobilier urbain aussi forcément. Masséna a été en travaux jusqu'à récemment mais à priori les positions sont bonnes de ce que je vois, en tout cas d'après eux elles sont bonnes et à jour (je les ai questionné sur cette zone). StreetView fait un joli mix avec des prises de multiples époques mais justement je trouve que celles de 2014 correspondent pas mal (en sachant qu'ils ont encore rajouté des arbres depuis). Mais j'y irai faire un tour pour voir ça de plus près. Ceci dit ce genre de zone n'est clairement pas l'endroit le mieux pour l'import (il y a une grosse densité de végétaux et en plus souvent de petite taille) et sur ces zones là je pourrais effectivement supprimer les arbres importés et utiliser du tag landuse à la place, à voir... Globalement je trouve quand même le positionnement vraiment bon, sur des gros axes ensoleillés on peut voir que tout match parfaitement sous Bing. J'ai aussi remarqué une belle bizarrerie avec quelques arbres qui étaient sur l'emprunte du futur stade Allianz Arena, alors en travaux sous Bing mais qui a été fini depuis. Je leur ai notifié et ils m'ont répondu que les matricules de ces arbres correspondaient effectivement à des anciens arbres mais qu'ils ne les réaffecterait que lorsque les travaux pour le tram seront finis, faudra donc que je les supprime à la main.. Sinon ils n'ont apparemment pas d'informations sur la hauteur des arbres (car trop variable d'après eux, ce qui n'est pas faux mais bon..) et je les ai relancé encore une fois sur la possibilité d'avoir le type, c'est juste pas possible qu'ils ne l'aient pas ! ___ 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] Importation des arbres municipaux sur Nice
Alors j'ai rajouté la petite vérification pour savoir si l'arbre importé est à l'intérieur d'un bâtiment ou pas. Cela permet donc d'avoir un fichier à part avec les arbres posant problème. Voici les dernières stats: Total of makable imports: 30246 Total of non makable imports: 275 Matching area radius: 5.0 Total of created trees: 29430 Total of updated trees: 816 Total of created or updated trees: 30246 Total of multi matching trees: 306 Il y a donc 275 arbres posant problème qu'on peut en gros diviser en 2 catégories: - les arbres qui sont collés à un bâtiment mais qui se retrouvent à l'intérieur comme c'est le cas pour la basilique Notre Dame (difficile de dire qui a raison ou tort). Il y en a environ une bonne quarantaine comme ça... - les arbres qui sont à l'intérieur d'un bâtiment parce que celui ci est mal fait dans OSM (ex: bibliothèque bien plus grande que la réalité et qui englobe son parc, ou bâtiment d'école simplifié ne laisse plus de place à sa cour interne, etc.). C'est du coup un bon test pour voir des corrections à faire (une sorte de mini osmose ;p), je conserve donc ce fichier pour faire certaines corrections plus tard et pouvoir ensuite importer certains arbres normalement, merci Jérôme pour l'idée. En attendant je compte bien uploader les 30 246 autres arbres qui sont hors bâtiments.. sauf si évidemment vous me dites que cela entraînera forcement un revert et mon bannissement du forum sur les 3 prochaines générations.. Le 31 juillet 2015 00:00, Vincent Frison vincent.fri...@gmail.com a écrit : Le 30 juillet 2015 23:24, Jérôme Seigneuret jseigneuret-...@yahoo.fr a écrit : Oui pour empêcher l'import mais on n'est pas à 15 cm sur le placement des bâtiments aussi donc qui a raison? Il faudrait genre un pré-filtre. Si tu fais ça sous JOSM il doit bien être possible de faire comme sous n'importe quel SIG un tag intermédiaire note=FIXME et tu n'intègres que ceux sans alerte. Les autres c'est à mettre dans un fichier *.osm et à retoucher au fur et à mesure pour faire l'intégration en semi-auto par exemple par type d'alerte. C'est plus simple et au moins il n'y a plus d’ambiguïté. Le plus simple c'est encore d'ignorer purement et simplement tous les éléments posant problème. Mais je trouve que c'est une bonne idée de garder ces éléments dans un fichier à part.. histoire de ne rien lâcher ! ;p Je ferai ça ce WE.. ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Importation des arbres municipaux sur Nice
Oui pour empêcher l'import mais on n'est pas à 15 cm sur le placement des bâtiments aussi donc qui a raison? Il faudrait genre un pré-filtre. Si tu fais ça sous JOSM il doit bien être possible de faire comme sous n'importe quel SIG un tag intermédiaire note=FIXME et tu n'intègres que ceux sans alerte. Les autres c'est à mettre dans un fichier *.osm et à retoucher au fur et à mesure pour faire l'intégration en semi-auto par exemple par type d'alerte. C'est plus simple et au moins il n'y a plus d’ambiguïté. Le 30 juillet 2015 23:07, Vincent Frison vincent.fri...@gmail.com a écrit : Le 30 juillet 2015 09:29, Christian Quest cqu...@openstreetmap.fr a écrit : On a un arbre dans la basilique Notre-Dame, des arbres à moins d'1m de certaines highway (non pedestrian). Des problèmes de calage ? De quel côté OSM ou opendata ? Place Masséna, il y a des différences avec Bing (qui date de 2012)... de nouveaux arbres y ont été plantés ou alors ils sont si petit qu'on ne les distingue pas sur l'ortho (ni sur Google Street View en septembre 2014) ? J'ai donc un doute sur la qualité des données en opendata. Sont-elles bien à jour ? Les algo de rapprochement semblent corrects, mais ne peuvent pas faire de miracle. C'est pas toujours évident à dire qui est en cause, par exemple pour la basilique cet élément correspond bien à un palmier réel collé à l'extérieur de l'église et ça se joue à quelques dizaines de centimètres. Mais ce que je vais faire c'est rajouter un filtre pour empêcher l'import d'un arbre localisé à l'intérieur d'élément ayant le tag building (ou autre chose?), c'est un truc j'aurais du penser dès le début. Il faut savoir que beaucoup d'axes dans Nice ont été refait ces dernières années et le mobilier urbain aussi forcément. Masséna a été en travaux jusqu'à récemment mais à priori les positions sont bonnes de ce que je vois, en tout cas d'après eux elles sont bonnes et à jour (je les ai questionné sur cette zone). StreetView fait un joli mix avec des prises de multiples époques mais justement je trouve que celles de 2014 correspondent pas mal (en sachant qu'ils ont encore rajouté des arbres depuis). Mais j'y irai faire un tour pour voir ça de plus près. Ceci dit ce genre de zone n'est clairement pas l'endroit le mieux pour l'import (il y a une grosse densité de végétaux et en plus souvent de petite taille) et sur ces zones là je pourrais effectivement supprimer les arbres importés et utiliser du tag landuse à la place, à voir... Globalement je trouve quand même le positionnement vraiment bon, sur des gros axes ensoleillés on peut voir que tout match parfaitement sous Bing. J'ai aussi remarqué une belle bizarrerie avec quelques arbres qui étaient sur l'emprunte du futur stade Allianz Arena, alors en travaux sous Bing mais qui a été fini depuis. Je leur ai notifié et ils m'ont répondu que les matricules de ces arbres correspondaient effectivement à des anciens arbres mais qu'ils ne les réaffecterait que lorsque les travaux pour le tram seront finis, faudra donc que je les supprime à la main.. Sinon ils n'ont apparemment pas d'informations sur la hauteur des arbres (car trop variable d'après eux, ce qui n'est pas faux mais bon..) et je les ai relancé encore une fois sur la possibilité d'avoir le type, c'est juste pas possible qu'ils ne l'aient pas ! ___ 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] Importation des arbres municipaux sur Nice
Le 30 juillet 2015 09:29, Christian Quest cqu...@openstreetmap.fr a écrit : On a un arbre dans la basilique Notre-Dame, des arbres à moins d'1m de certaines highway (non pedestrian). Des problèmes de calage ? De quel côté OSM ou opendata ? Place Masséna, il y a des différences avec Bing (qui date de 2012)... de nouveaux arbres y ont été plantés ou alors ils sont si petit qu'on ne les distingue pas sur l'ortho (ni sur Google Street View en septembre 2014) ? J'ai donc un doute sur la qualité des données en opendata. Sont-elles bien à jour ? Les algo de rapprochement semblent corrects, mais ne peuvent pas faire de miracle. C'est pas toujours évident à dire qui est en cause, par exemple pour la basilique cet élément correspond bien à un palmier réel collé à l'extérieur de l'église et ça se joue à quelques dizaines de centimètres. Mais ce que je vais faire c'est rajouter un filtre pour empêcher l'import d'un arbre localisé à l'intérieur d'élément ayant le tag building (ou autre chose?), c'est un truc j'aurais du penser dès le début. Il faut savoir que beaucoup d'axes dans Nice ont été refait ces dernières années et le mobilier urbain aussi forcément. Masséna a été en travaux jusqu'à récemment mais à priori les positions sont bonnes de ce que je vois, en tout cas d'après eux elles sont bonnes et à jour (je les ai questionné sur cette zone). StreetView fait un joli mix avec des prises de multiples époques mais justement je trouve que celles de 2014 correspondent pas mal (en sachant qu'ils ont encore rajouté des arbres depuis). Mais j'y irai faire un tour pour voir ça de plus près. Ceci dit ce genre de zone n'est clairement pas l'endroit le mieux pour l'import (il y a une grosse densité de végétaux et en plus souvent de petite taille) et sur ces zones là je pourrais effectivement supprimer les arbres importés et utiliser du tag landuse à la place, à voir... Globalement je trouve quand même le positionnement vraiment bon, sur des gros axes ensoleillés on peut voir que tout match parfaitement sous Bing. J'ai aussi remarqué une belle bizarrerie avec quelques arbres qui étaient sur l'emprunte du futur stade Allianz Arena, alors en travaux sous Bing mais qui a été fini depuis. Je leur ai notifié et ils m'ont répondu que les matricules de ces arbres correspondaient effectivement à des anciens arbres mais qu'ils ne les réaffecterait que lorsque les travaux pour le tram seront finis, faudra donc que je les supprime à la main.. Sinon ils n'ont apparemment pas d'informations sur la hauteur des arbres (car trop variable d'après eux, ce qui n'est pas faux mais bon..) et je les ai relancé encore une fois sur la possibilité d'avoir le type, c'est juste pas possible qu'ils ne l'aient pas ! ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Importation des arbres municipaux sur Nice
Le 30 juillet 2015 23:24, Jérôme Seigneuret jseigneuret-...@yahoo.fr a écrit : Oui pour empêcher l'import mais on n'est pas à 15 cm sur le placement des bâtiments aussi donc qui a raison? Il faudrait genre un pré-filtre. Si tu fais ça sous JOSM il doit bien être possible de faire comme sous n'importe quel SIG un tag intermédiaire note=FIXME et tu n'intègres que ceux sans alerte. Les autres c'est à mettre dans un fichier *.osm et à retoucher au fur et à mesure pour faire l'intégration en semi-auto par exemple par type d'alerte. C'est plus simple et au moins il n'y a plus d’ambiguïté. Le plus simple c'est encore d'ignorer purement et simplement tous les éléments posant problème. Mais je trouve que c'est une bonne idée de garder ces éléments dans un fichier à part.. histoire de ne rien lâcher ! ;p Je ferai ça ce WE.. ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Importation des arbres municipaux sur Nice
J'ai très rapidement regardé les fichiers proposés à l'import sur les abord de l'avenue Jean Médecin. On a un arbre dans la basilique Notre-Dame, des arbres à moins d'1m de certaines highway (non pedestrian). Des problèmes de calage ? De quel côté OSM ou opendata ? Place Masséna, il y a des différences avec Bing (qui date de 2012)... de nouveaux arbres y ont été plantés ou alors ils sont si petit qu'on ne les distingue pas sur l'ortho (ni sur Google Street View en septembre 2014) ? J'ai donc un doute sur la qualité des données en opendata. Sont-elles bien à jour ? Les algo de rapprochement semblent corrects, mais ne peuvent pas faire de miracle. -- Christian Quest - OpenStreetMap France ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Importation des arbres municipaux sur Nice
Le 27/07/2015 12:14, Christian Rogel a écrit : Je trouve qu’il a beaucoup trop de de morale et pas assez d’esprit de partage, vis-à-viis du projet de Vincent Frison sur l’import des arbres de Nice. Les remarques sur ce qu’il devrait faire (compléter les noms de voie) sont totalement hors-sujet et frisent la condescendance. Il a souvent été été dit ici que les suggestions de se focaliser sur tel ou tel territoire n’engagent que ceux qui les font. Chacun est libre de rajouter une information pertinente et l’incomplétude n’est pas un frein. La limite est le danger de détruire des objets pertinents, sûrement pas les pronostics invérifiables. Il est souvent rappelé qu’OSM est un projet itératif et personne ne peut prétendre prévoir ce qui sera fait des objets recensés (complétion à des fins de recherches ou de statistiques). Christian R. +1 La présence des arbres peut même être utile au contributeur occasionnel de passage. J'en suis un exemple (pas avec les arbres), il m'est arrivé de repérer le lieu où était telle boutique parce que la borne récup-verre à côté était cartographiée. L'ensemble des informations présentes dans OSM me permettait de préciser mon souvenir. La présence des arbres peut procéder du même ordre : d'après mes souvenirs, la boulangerie, elle était en face de l'arbre. Ou après une visite chez quelqu'un au numéro N de la rue : bizarre, l'arbre n'est pas devant la maison, mais devant celle du voisin. Soit erreur dans le positionnement de l'arbre, soit erreur dans la numérotation. Toute information présente permet de situer ou de vérifier l'information suivante. C'est itératif, disait-il... Et il n'y a ni hiérarchie, ni priorité. -- FrViPofm ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Importation des arbres municipaux sur Nice
J'ai reçu une réponse de la part du service, je rappelle que je leur avais posé la question pour savoir s'il prévoyait à terme de rajouter d'autres infos que la position comme le type ou la hauteur. La réponse, qui tien en une ligne et qui est assez surprenante (je me permet de la c/c ici puisque rien de privé ou sensible): La base de données intègre de multiples critères qui servent à gérer le patrimoine arboré de la ville de Nice. Ces critères ne sont pas partagés ou disponibles sur les plateformes informatiques publiques et n’ont pas vocation à l’être. Donc il semblerait bien que ces infos existent dans leurs bases sauf qu'ils n'ont pas prévu de les intégrer dans leur jeu de données ouvertes :( Je leur ai demandé s'il y avait une raison particulière pour cela... ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Importation des arbres municipaux sur Nice
Bonjour ! Je suis un contributeur de la région, j’ai par exemple intégré le bâti du cadastre sur Nice et pas mal de communes alentours,... Mon opinion sur l’import massif d’arbres “quelconques” est assez négatifs pour plusieurs raisons : - quid de la maintenance a long terme car le sujet ne semble pas passionner beaucoup de monde - le rendu OSM “standard” n’est pas bon a mon avis, c’est trop chargé, on dirait que la carte a chopé la varicelle ;-) - je comprend l’intérêt que cela peut avoir pour certains domaine d’activité d’avoir ces données mais pour la grande majorité je ne vois pas… - cela dilue et cache l’information sur les arbres “remarquables” qui eux méritent d’apparaitre sur le rendu généraliste - quand j’importe les données OSM pour la France entière dans mon logiciel utilisant libosmscout qui compile tout ça dans une base binaire de 4.5Go (avec les lignes de niveau à intervalle de 10m) je dois filtrer les arbres car sinon l’import explose à cause d’une trop forte concentration d’un même type de noeud (les arbres) dans certaines zones ! Cordialement, Vlad (https://www.openstreetmap.org/user/Vlad https://www.openstreetmap.org/user/Vlad) On 28 Jul 2015, at 00:17, Vincent Frison vincent.fri...@gmail.com wrote: Le 27 juillet 2015 22:46, Christian Quest cqu...@openstreetmap.fr mailto:cqu...@openstreetmap.fr a écrit : Le 27/07/2015 01:01, osm.sanspourr...@spamgourmet.com mailto:osm.sanspourr...@spamgourmet.com a écrit : Mais c'est l'arbre qui cache la forêt : je vois que des rues de Nice n'ont pas de nom (http://www.openstreetmap.org/way/156776064 http://www.openstreetmap.org/way/156776064). Il semble pourtant y avoir des habitants, il y a même des numéros sur les bâtiments (http://tile.openstreetmap.fr/~cquest/leaflet/bano.html#19/43.71235/7.27541 http://tile.openstreetmap.fr/%7Ecquest/leaflet/bano.html#19/43.71235/7.27541). Alors un nom de rue, de résidence ? Non, pas de numéros sur les bâtiments dans OSM... ils seraient en vert sur le rendu BANO. Ce qui est en bleu c'est le cadastre (avec rapprochement OSM), en jaune c'est l'opendata et en gris la BAN. Oui des noms de rues manquent encore sur Nice... et bien qu'il n'y ait pas de priorité à mapper tel ou tel type d'info avant une autre, c'est quand même symptomatique d'une zone avec une communauté pas très active surtout par rapport à la densité de population. Si je veux aller à Nice, la carte me sert avant tout à trouver les rues. Les arbres, ça vient après, seulement après. PSS donne des infos pertinentes sur des lieux remarquables, comme http://structurae.net/ http://structurae.net/. Relier ces données à OSM me semble bien plus intéressant, pertinent. La notion de valeur ajoutée me semble très importante. Bien sûr les arbres importés ne vont pas décourager une communauté locale, mais importer ces données sans se mettre en relation avec cette communauté ne va pas dans le bon sens pour la développer. Je suis bien d'accord mais à vrai dire c'est un peu ce que je pensais faire en créant ce thread au titre plutôt évocateur. Malheureusement pas beaucoup de niçois se sont manifestés... En tout cas j'ai essayé de contacter les 3 contributeurs qui avaient déjà rajoutés des arbres sur Nice: - un seul m'a répondu pour l'instant et il n'est plus sur la région (tiens ça me rappelle mon exemple, qui va maintenant s'occuper des arbres qu'il a créé ? :p) - un autre ne m'a pas répondu mais au vu de ses contributions il n'est plus sur la région non plus ! - l'autre par contre est encore dans les parages, j'ai donc encore un peu d'espoir de pas être tout à fait seul Après c'est sûr que c'est pas les seuls (j'essayerai d'autres contributeurs récemment actifs) mais ça montre qu'effectivement il n'y a pas une énorme activité sur la région, ce qui est effectivement surprenant vu la densité de population.. OSM est aussi un projet très social... il faut un petit peu de temps pour intégrer aussi cet aspect. Il m'a fallu du temps pour prendre du recul avec la technique et pour comprendre cette dimension... je ne pense pas être le seul. Relire nos premières interventions sur talk-fr est assez instructif de ce point de vue ! Personnellement ça m'a semblé assez clair dès le début et c'est d'ailleurs pour ça que je n'ai pas hésité dès le début à communiquer et demander de l'aide sur mes imports.. Il y a plein de dev à faire, mais surtout pour mettre à disposition des non-dev des outils de plus en plus pratiques, ergonomiques, rapides, efficaces pour viser le meilleur rapport temps passé/valeur ajoutée et utilisables par le public le plus large. C'est sur que c'est primordiale, je trouve d'ailleurs que l'éditeur iD est assez génial de ce point de vue là.. Bon en tout cas ça ne résout pas vraiment mon problème pour savoir si je peux ou pas envoyer mon import sur le serveur.. en tant que chef tu ne pourrais pas me donner un
Re: [OSM-talk-fr] Importation des arbres municipaux sur Nice
Bonjour Le 28/07/2015 09:53, Vladimir Vyskocil a écrit : - quid de la maintenance a long terme car le sujet ne semble pas passionner beaucoup de monde Il en est de même que pour le bâti, comment faire dans des communes ou il n'y a jamais de contributeurs et il y en aura jamais avant 2125 ? Pour cela la base national de la DGFIP est un bonne base car mis à jour au moins 1 fois par an et que derrière on peut trouver un script qui peut mettre à jour. Ici, on a un base communale qui permet de gérer cela en annexe d'OSM qui permet de mettre à jour de façon semi-automatique de jour en jour - le rendu OSM “standard” n’est pas bon a mon avis, c’est trop chargé, on dirait que la carte a chopé la varicelle ;-) - cela dilue et cache l’information sur les arbres “remarquables” qui eux méritent d’apparaitre sur le rendu généraliste On n'étiquette pas pour le rendu, mais pour le contenu, le rendu n'est que la partie visible de l'iceberg, la majorité des données ne sont pas rendu - quand j’importe les données OSM pour la France entière dans mon logiciel utilisant libosmscout qui compile tout ça dans une base binaire de 4.5Go (avec les lignes de niveau à intervalle de 10m) je dois filtrer les arbres car sinon l’import explose à cause d’une trop forte concentration d’un même type de noeud (les arbres) dans certaines zones ! Tu veux pire que les arbres dans la base OSM ? Alors ne t'en fait pas car dans quelques années il y aura tous les accès depuis la surface de la route vers les éléments en derme de la surface terrestre: bouche d'homme pour les égouts, vannes de sectionnement des canalisations d'eau, de gaz, boite de raccordement de réseau en réseau souterrain (électrique, télématique, optique, etc.) En parallèle, ce sera aussi du indoor, avec le multiniveau en plus. Openstreetmap ne s'adapte pas pour un besoin particulier. Tout ceux qui veulent du contenu spécifique sont obliger de faire cela. Il n'y a qu'à voir les rendus d'ITO World pour cela. Cordialement -- David Crochet ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Importation des arbres municipaux sur Nice
Bonjour Vlad, Content de voir un local rejoindre la discussion :) - quid de la maintenance a long terme car le sujet ne semble pas passionner beaucoup de monde Ce sujet a déjà été évoqué, je m'occuperai de la maintenance et à priori sur plus long terme que les arbres rajoutés manuellement (pour info une grosse partie de ceux qui ont été déjà rajouté manuellement sur Nice n'ont plus leur père car il a quitté la région). - le rendu OSM “standard” n’est pas bon a mon avis, c’est trop chargé, on dirait que la carte a chopé la varicelle ;-) - je comprend l’intérêt que cela peut avoir pour certains domaine d’activité d’avoir ces données mais pour la grande majorité je ne vois pas… Moi j'y vois un intérêt visuel indéniable mais que tu dois pouvoir dénier puisque tu trouves que ça ressemble à de la varicelle ! ;p Perso je ne vois pas du tout ce côté là, au contraire.. et surtout il me tarde de voir le rendu avec F4map ! - cela dilue et cache l’information sur les arbres “remarquables” qui eux méritent apparaître sur le rendu généraliste Il n'y a que sur la Prom' où je peux imaginer ce genre de problème car il y a effectivement des arbres existants correspondants à des très grands palmier qui sont à côté de petits arbres de moins de 3 mètres. Mais j'ai justement prévu de refaire un travail manuel pour mettre un peu de tag heigt sur cette zone.. - quand j’importe les données OSM pour la France entière dans mon logiciel utilisant libosmscout qui compile tout ça dans une base binaire de 4.5Go (avec les lignes de niveau à intervalle de 10m) je dois filtrer les arbres car sinon l’import explose à cause d’une trop forte concentration d’un même type de noeud (les arbres) dans certaines zones ! Oui bon là c'est pas trop de la faute de mon import ;p ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Importation des arbres municipaux sur Nice
Le 27/07/2015 01:01, osm.sanspourr...@spamgourmet.com a écrit : Mais c'est l'arbre qui cache la forêt : je vois que des rues de Nice n'ont pas de nom (http://www.openstreetmap.org/way/156776064). Il semble pourtant y avoir des habitants, il y a même des numéros sur les bâtiments (http://tile.openstreetmap.fr/~cquest/leaflet/bano.html#19/43.71235/7.27541). Alors un nom de rue, de résidence ? Non, pas de numéros sur les bâtiments dans OSM... ils seraient en vert sur le rendu BANO. Ce qui est en bleu c'est le cadastre (avec rapprochement OSM), en jaune c'est l'opendata et en gris la BAN. Oui des noms de rues manquent encore sur Nice... et bien qu'il n'y ait pas de priorité à mapper tel ou tel type d'info avant une autre, c'est quand même symptomatique d'une zone avec une communauté pas très active surtout par rapport à la densité de population. Si je veux aller à Nice, la carte me sert avant tout à trouver les rues. Les arbres, ça vient après, seulement après. PSS donne des infos pertinentes sur des lieux remarquables, comme http://structurae.net/. Relier ces données à OSM me semble bien plus intéressant, pertinent. La notion de valeur ajoutée me semble très importante. Bien sûr les arbres importés ne vont pas décourager une communauté locale, mais importer ces données sans se mettre en relation avec cette communauté ne va pas dans le bon sens pour la développer. OSM est aussi un projet très social... il faut un petit peu de temps pour intégrer aussi cet aspect. Il m'a fallu du temps pour prendre du recul avec la technique et pour comprendre cette dimension... je ne pense pas être le seul. Relire nos premières interventions sur talk-fr est assez instructif de ce point de vue ! Il y a plein de dev à faire, mais surtout pour mettre à disposition des non-dev des outils de plus en plus pratiques, ergonomiques, rapides, efficaces pour viser le meilleur rapport temps passé/valeur ajoutée et utilisables par le public le plus large. -- Christian Quest - OpenStreetMap France ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Importation des arbres municipaux sur Nice
Le 27 juillet 2015 22:46, Christian Quest cqu...@openstreetmap.fr a écrit : Le 27/07/2015 01:01, osm.sanspourr...@spamgourmet.com a écrit : Mais c'est l'arbre qui cache la forêt : je vois que des rues de Nice n'ont pas de nom (http://www.openstreetmap.org/way/156776064). Il semble pourtant y avoir des habitants, il y a même des numéros sur les bâtiments ( http://tile.openstreetmap.fr/~cquest/leaflet/bano.html#19/43.71235/7.27541). Alors un nom de rue, de résidence ? Non, pas de numéros sur les bâtiments dans OSM... ils seraient en vert sur le rendu BANO. Ce qui est en bleu c'est le cadastre (avec rapprochement OSM), en jaune c'est l'opendata et en gris la BAN. Oui des noms de rues manquent encore sur Nice... et bien qu'il n'y ait pas de priorité à mapper tel ou tel type d'info avant une autre, c'est quand même symptomatique d'une zone avec une communauté pas très active surtout par rapport à la densité de population. Si je veux aller à Nice, la carte me sert avant tout à trouver les rues. Les arbres, ça vient après, seulement après. PSS donne des infos pertinentes sur des lieux remarquables, comme http://structurae.net/. Relier ces données à OSM me semble bien plus intéressant, pertinent. La notion de valeur ajoutée me semble très importante. Bien sûr les arbres importés ne vont pas décourager une communauté locale, mais importer ces données sans se mettre en relation avec cette communauté ne va pas dans le bon sens pour la développer. Je suis bien d'accord mais à vrai dire c'est un peu ce que je pensais faire en créant ce thread au titre plutôt évocateur. Malheureusement pas beaucoup de niçois se sont manifestés... En tout cas j'ai essayé de contacter les 3 contributeurs qui avaient déjà rajoutés des arbres sur Nice: - un seul m'a répondu pour l'instant et il n'est plus sur la région (tiens ça me rappelle mon exemple, qui va maintenant s'occuper des arbres qu'il a créé ? :p) - un autre ne m'a pas répondu mais au vu de ses contributions il n'est plus sur la région non plus ! - l'autre par contre est encore dans les parages, j'ai donc encore un peu d'espoir de pas être tout à fait seul Après c'est sûr que c'est pas les seuls (j'essayerai d'autres contributeurs récemment actifs) mais ça montre qu'effectivement il n'y a pas une énorme activité sur la région, ce qui est effectivement surprenant vu la densité de population.. OSM est aussi un projet très social... il faut un petit peu de temps pour intégrer aussi cet aspect. Il m'a fallu du temps pour prendre du recul avec la technique et pour comprendre cette dimension... je ne pense pas être le seul. Relire nos premières interventions sur talk-fr est assez instructif de ce point de vue ! Personnellement ça m'a semblé assez clair dès le début et c'est d'ailleurs pour ça que je n'ai pas hésité dès le début à communiquer et demander de l'aide sur mes imports.. Il y a plein de dev à faire, mais surtout pour mettre à disposition des non-dev des outils de plus en plus pratiques, ergonomiques, rapides, efficaces pour viser le meilleur rapport temps passé/valeur ajoutée et utilisables par le public le plus large. C'est sur que c'est primordiale, je trouve d'ailleurs que l'éditeur iD est assez génial de ce point de vue là.. Bon en tout cas ça ne résout pas vraiment mon problème pour savoir si je peux ou pas envoyer mon import sur le serveur.. en tant que chef tu ne pourrais pas me donner un autorisation spéciale (si possible sans clause NC ;p) ? En tout cas si certains sont intéressés ils peuvent voir le XML généré ainsi que les logs par ici http://up.lbzh.fr/uploads/55b6aaf971201.zip (dispo pendant 48h). ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Importation des arbres municipaux sur Nice
Je trouve qu’il a beaucoup trop de de morale et pas assez d’esprit de partage, vis-à-viis du projet de Vincent Frison sur l’import des arbres de Nice. Les remarques sur ce qu’il devrait faire (compléter les noms de voie) sont totalement hors-sujet et frisent la condescendance. Il a souvent été été dit ici que les suggestions de se focaliser sur tel ou tel territoire n’engagent que ceux qui les font. Chacun est libre de rajouter une information pertinente et l’incomplétude n’est pas un frein. La limite est le danger de détruire des objets pertinents, sûrement pas les pronostics invérifiables. Il est souvent rappelé qu’OSM est un projet itératif et personne ne peut prétendre prévoir ce qui sera fait des objets recensés (complétion à des fins de recherches ou de statistiques). Christian R. ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Importation des arbres municipaux sur Nice
Le 27 juillet 2015 00:58, Vincent de Château-Thierry v...@laposte.net a écrit : Le 27/07/2015 00:08, Vincent Frison a écrit : Je commence juste à me rendre compte (je suis un nouveau de 6 mois hein) à quel point les imports auto sont mal vues par ici. Je savais bien que ça pouvait être sensible (ils en parlent même sur la page import du wiki) mais pour être franc je ne m'attendais pas du tout à une telle levée de boucliers pour cet import d'arbres.. si peu risqué à mon sens ! Ça n'est pas pour rien qu'on met un point d'honneur en France à parler d'intégration et non d'import. Intégration signifie que le contributeur (humain) a toujours le dernier mot avant d'envoyer les données au serveur, et que le travail de combinaison avec l'existant lui incombe, bien plus qu'à un robot-algo. Mais en fait c'est un peu le cas puisque les contributions existantes sont conservées et en plus ça passe par la case JOSM pour vérifier le contenu avant l'import. Mon programme peut en effet se synchroniser avec OSM soit directement en faisant des requêtes vers l'API soit en générant du XML pour JOSM. Dans ce dernier cas là on est donc plus dans l'import semi-automatique et que totalement automatique... J'ai bien conscience que la problématique de la maintenance est évidemment primordiale mais personnellement je ne suis vraiment pas sûr qu'une donnée rentrée manuellement soit forcément plus viable, sur le long terme, qu'une entrée rentrée automatiquement, surtout pour ce type de donnée.Pour revenir par exemple au cas où je rentre manuellement un arbre de mon quartier puis je déménage, je risque fortement de ne plus jamais le mettre à jour. Alors que je pourrais continuer à rejouer tous les 6 mois et sans effort via mon script pour utiliser la dernière mise à jour de l'opendata de Nice indiquant le très peu probable abattage de l'arbre. Ce qui veut dire une confiance totale en la source Open Data. Ça a déjà été rappelé dans ce fil (et dans bien d'autres avant) : une source Open Data doit être croisée à autre chose et pas prise comme telle, seule. D'où souvent le verdict du terrain pour valider la qualité. J'ai passé pas mal d'heures à vérifier ces données et franchement tout à l'air bon même si je n'ai pas vérifié l'intégralité des 30 000 arbres individuellement. ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Importation des arbres municipaux sur Nice
Le 27 juillet 2015 01:01, osm.sanspourr...@spamgourmet.com a écrit : L'import se résume à peu de valeur ajoutée, ce n'est pas comparable à PSS. Ici tu veux ajouter un nœud par arbre (nouveau). Pas de taille, pas d'âge, pas d'espèce, etc... Donc suffisant pour la municipalité pour savoir quoi arroser. C'est le problème de l'usage. Ajouter une info globalement pauvre même si pertinente sur un point, c'est bien *s**'il* est probable que les gens la complètent. Si c'est une graine que tu peux faire germer c'est bien, si c'est un sapin de Noël synthétique, ça nuit aux données alentour ! Je comprends pas, pourquoi pas un arbre rajouté par mon import serait un sapin synthétique nuisible comparé à un arbre rajouté manuellement ? Actuellement la donnée ne concerne que la position, si on avait eu le type et la hauteur ça aurait été génial mais c'est pas le cas. Mais à partir du moment où ça correspond à la position d'un arbre réel c'est une info qui a le droit d'être rentrée dans OSM au même titre que position d'un arbre rentrée manuellement. Je rappelle que la majorité des arbres rentrés manuellement n'ont justement que la position et rien d'autres. Si je veux aller à Nice, la carte me sert avant tout à trouver les rues. Les arbres, ça vient après, seulement après. Je suis bien d'accord que c'est dommage qu'il manque des infos sur Nice mais pour autant est ce une raison pour refuser l'ajout d'éléments moins prioritaires ? ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Importation des arbres municipaux sur Nice
Alors pour répondre à la question de Jérôme sur la gestion des conflits: Avant je ne considérais que l'arbre existant le plus proche de l'arbre importé. Mais comme je disais dans un post précédent: la gestion des multi matching trees (ie. les arbres existants qui sont dans le rayon de plusieurs arbres importés) est très basique puisque je met à jour l'élément avec les valeurs du 1er arbre importé tout simplement (pour les autres éléments importés je créé donc un nouvel élément). Comme tu l'as remarqué Jérôme il y a aucun tag taxon ou genus sur l'ensemble des arbres existants de Nice, ce qui est une mauvaise chose dans l'absolu... mais plutôt une bonne chose pour mon import ! :p Ceci dit on était pas à l'abri de cas problématiques, imaginons 2 arbres importés I1, I2 et 3 arbres existants E1, E2, E3 (et que le rayon est de 5m). I12mE1 I13mE2 I21mE1 I24mE3 Avant si je tombais d'abord sur I1 j'utilisais E1 pour le mettre à jour et laissait E2 tel quel. Sauf que I2 est encore plus proche de E1, il devrait être donc être mis à jour pour I2 et c'est E2 qui devrait être mis à jour pour I1. C'est maintenant le cas car je conserve pour chaque arbre existant l'arbre importé le plus proche. - si l'arbre importé n'est pas le meilleur candidat (ie. il y a un autre arbre importé qui est plus proche de l'arbre existant), j'essaye avec les autres arbres existants qui étaient dans son rayon (et s'il n'y a plus d'autres arbres existants alors il faudra créer un nouvel élément) - si l'arbre importé est le meilleur candidat, je peux alors utiliser l'arbre existant pour le mettre à jour. Mais je dois alors relancer tout le processus pour l'ancien meilleur arbre importé qui à son tour pourrait éventuellement faire des changements (fonction récursive). Bon c'est pas évident d'expliquer tout ça par mail mais vous pouvez voir les sources ici: https://github.com/vince-from-nice/osmaxil/blob/master/src/main/java/org/openstreetmap/osmaxil/plugin/maker/NiceTreeMaker.java Il faut que je fasse plus de vérifications mais ça a l'air de bien fonctionner. De plus, comme je suis sûr d'associer l'arbre existant avec l'arbre importé le plus proche, je peux me permettre d'augmenter le rayon (là j'ai mis 5 mètres). D'ailleurs je peux attacher le résultat sur la mailing list (environ 500KB) ? PS: outch j'avais pas vu tous les mails qui s'était accumulés depuis que j'ai commencé mon mail hier soir ! Je vais essayer d'y répondre un peu plus tard... ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Importation des arbres municipaux sur Nice
Je comprends aisément votre méfiance sur les imports automatiques, surtout si ceux ci sont mal faits, ou faits à partir de mauvaises données. Sauf que là je ne pense pas que ça soit le cas car les données importées correspondant bien à la réalité. La précision n'est évidemment pas parfaite, tout comme celles des arbres existants d'ailleurs, mais je pense qu'elle est largement suffisante pour des arbres. Et je pense pas faire ça mal, en tout cas je ne fais pas ça comme un sagouin tout seul dans mon cave: j'essaye de communiquer autant que possible et j'essaye de prendre en compte vos remarques bien souvent constructives. Par contre j'ai plus de mal à adhérer à l'idée que les imports automatiques déshumaniseraient OSM. Bon déjà je serais le premier partant pour aller boire un verre avec des contributeurs locaux pour parler architecture et botanique :) Mais surtout, à partir du moment où évidemment les données sont correctes, je ne vois pas en quoi ça gêne: un import a le mérite de rajouter avec peu d'effort (enfin quoique) beaucoup de données qui seraient généralement beaucoup trop fastidieuses à rentrer manuellement. Alors qu'il y a tellement de chose à rajouter dans OSM... c'est pas comme si je volais du travail à des contributeurs humains ! De plus je rappelle que je conserve les contributions existantes au lieu de les supprimer comme initialement. Pour revenir à l'exemple US que je ne connais pas du tout, j'avoue avoir du mal à croire que ça soit simplement à cause de l'import auto de TIGER qu'il y ait aussi peu de contributeurs. Sauf si l'import a été mal fait mais à ce moment là c'est un autre problème. En fait j'aurais même tendance à penser l'inverse: il est plus facile de motiver des contributeurs à travailler sur une carte déjà bien remplie plutôt que sur une carte quasiment vide, où à peu près tout reste à faire.. mais bon là on rentre dans la psychologie. Donc voilà, à mon sens je ne vois que des côtés positifs à partir du moment où l'import automatique est bien fait. Et encore une fois rien n'empêche de pas retravailler manuellement des données importées automatiquement. Rajouter les tags height / taxon / etc. sur les 30 000 les arbres municipaux de Nice représenterait un sacré travail manuel. Je serais tout à fait partant pour le faire avec du monde mais il faut aussi être réaliste, les forces vives sur la région niçoise ont l'air assez minces. J'ai en tout cas contacté les 2 personnes qui ont déjà rajouté des arbres sur Nice, s'ils me répondent j'essayerai de voir s'elles sont motivées mais si au final on est que 3 ou 4 ça serait titanesque de faire l'ensemble des arbres. Disons qu'on pourrait au moins faire la Prom' (pour ceux qui ne connaissent pas c'est la route en bord de mer de Nice). Par contre je verrais plutôt ça en rajoutant les tags directement dans OSM depuis son téléphone plutôt que de les noter sur une carte imprimée pour après les faire intégrer dans l'OD de Nice (s'ils le veulent bien !) pour après les réimporter dans OSM... à ce moment autant considérer que LA référence c'est OSM ! ;p Le 26 juillet 2015 14:44, Vincent Frison vincent.fri...@gmail.com a écrit : Alors pour répondre à la question de Jérôme sur la gestion des conflits: Avant je ne considérais que l'arbre existant le plus proche de l'arbre importé. Mais comme je disais dans un post précédent: la gestion des multi matching trees (ie. les arbres existants qui sont dans le rayon de plusieurs arbres importés) est très basique puisque je met à jour l'élément avec les valeurs du 1er arbre importé tout simplement (pour les autres éléments importés je créé donc un nouvel élément). Comme tu l'as remarqué Jérôme il y a aucun tag taxon ou genus sur l'ensemble des arbres existants de Nice, ce qui est une mauvaise chose dans l'absolu... mais plutôt une bonne chose pour mon import ! :p Ceci dit on était pas à l'abri de cas problématiques, imaginons 2 arbres importés I1, I2 et 3 arbres existants E1, E2, E3 (et que le rayon est de 5m). I12mE1 I13mE2 I21mE1 I24mE3 Avant si je tombais d'abord sur I1 j'utilisais E1 pour le mettre à jour et laissait E2 tel quel. Sauf que I2 est encore plus proche de E1, il devrait être donc être mis à jour pour I2 et c'est E2 qui devrait être mis à jour pour I1. C'est maintenant le cas car je conserve pour chaque arbre existant l'arbre importé le plus proche. - si l'arbre importé n'est pas le meilleur candidat (ie. il y a un autre arbre importé qui est plus proche de l'arbre existant), j'essaye avec les autres arbres existants qui étaient dans son rayon (et s'il n'y a plus d'autres arbres existants alors il faudra créer un nouvel élément) - si l'arbre importé est le meilleur candidat, je peux alors utiliser l'arbre existant pour le mettre à jour. Mais je dois alors relancer tout le processus pour l'ancien meilleur arbre importé qui à son tour pourrait éventuellement faire des changements (fonction récursive). Bon c'est pas évident d'expliquer tout ça par
Re: [OSM-talk-fr] Importation des arbres municipaux sur Nice
Bonsoir, Le 26/07/2015 21:30, Vincent Frison a écrit : Bon d'accord l'import TIGER a visiblement été très négatif pour la naissance de la communauté US.. mais pour revenir concrètement (et plus modestement) à mon import d'arbres sur Nice, vous pensez sincèrement que ça aurait un impact négatif sur la communauté niçoise d'OSM ? Oui, tant que cette communauté n'aura pas dit le contraire. Ce qui est pointé depuis hier, c'est notamment le caractère intimidant de données importées, et le fait que la maintenance est une tâche beaucoup plus ingrate que la création de données. D'où l'importance de pouvoir s'approprier ce qui est fait, et le meilleur moyen reste encore d'avoir eu l'opportunité de le faire soi-même. Avec un import, difficile de se sentir concerné, affecté, par les données. C'est plutôt le découragement qui prévaut. J'aurais un discours plus modulé si on avait dans le cadre de ce fil un echo de contributeurs locaux, qui diraient en substance : c'est bon, que l'import soit fait, on s'occupe de la suite. Mais pour l'instant je n'entends rien. Le constat sur la couverture BANO va dans le même sens. En s'appuyant sur les stats par département (pour Nice : http://cadastre.openstreetmap.fr/fantoir-dev/stats_dept.html#dept=06 ) sur les 10 plus grosses communes de France Nice est celle avec le moins bon ratio a/c. Ça n'est qu'un constat (surtout pas un reproche) mais ce thermomètre (parmi d'autres) de l'activité locale montre qu'on a moins de dynamisme que sur les autres villes de même importance. Et dans ce contexte, je ne vois pas comment un ajout massif et mécanique va motiver du monde pour s'approprier la ville et alentours et _maintenir_ les données (des arbres mais pas que). Le 26/07/2015 21:34, Jérôme Seigneuret a écrit : Autre problématique d'intégration et dont il n'y a même pas un consensus (même sur une commune) c'est adresse postal Certains parle de le mettre à l'entrée du bâtiment, d'autres sur le bâtiment, d'autre devant la rue à l'entrée. On fait quoi pour qui en fait? La poste prendra la boite et la sonnette, d'autre service pour les clients ce sera la porte d'entrée, Certains ce sera le boitier électrique, le compteur de gaz ou d'eau. Et c'est la même pour les commerces. Pour les adresses, la démarche a consisté à ne pas décider qu'un modèle était meilleur qu'un autre : on a pas moins de 8 schémas de tags disponibles par commune. Et surtout, ce qui est généré à http://cadastre.openstreetmap.fr/ sont des fichiers à intégrer, manuellement, par les contributeurs. C'est un choix délibéré. Techniquement il était tout à fait possible, une fois les adresses extraites du cadastre, de tout importer, sur les 30.000 communes vectorielles. Mais ça n'est pas parce que c'est techniquement possible que c'est forcément souhaitable (pour les raisons évoquées plus haut notamment). vincent ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Importation des arbres municipaux sur Nice
Le 26 juillet 2015 19:51, JB jb...@mailoo.org a écrit : Quelques réponses décousues : Le 26/07/2015 15:47, Vincent Frison a écrit : Par contre j'ai plus de mal à adhérer à l'idée que les imports automatiques déshumaniseraient OSM. Bon déjà je serais le premier partant pour aller boire un verre avec des contributeurs locaux pour parler architecture et botanique :) Vas-y, lance une invitation. Je pense qu'on ne le fait pas assez. En rase campagne, c'est pas forcément évident, mais en ville… On va y aller tranquille, j'ai déjà envoyé des mails à 2 personnes.. et je pars bientôt en vacances ! :) Mais surtout, à partir du moment où évidemment les données sont correctes, je ne vois pas en quoi ça gêne: un import a le mérite de rajouter avec peu d'effort (enfin quoique) beaucoup de données qui seraient généralement beaucoup trop fastidieuses à rentrer manuellement. … d'où la demande de leur entretien. Si ça n'intéresse pas grand monde de les mapper, qui va en plus les entretenir ? Dans 10, 20 ans, à quoi ressemblera la base de données ? Oui mais bon à ce moment là on ne peut plus rien rajouter ! Si je rajoute (manuellement) un arbre dans mon quartier et que dans 20 ans je ne suis plus dans la région qui va mettre à jour mon arbre ? Pour revenir à l'exemple US que je ne connais pas du tout, j'avoue avoir du mal à croire que ça soit simplement à cause de l'import auto de TIGER qu'il y ait aussi peu de contributeurs. Sauf si l'import a été mal fait mais à ce moment là c'est un autre problème. En fait j'aurais même tendance à penser l'inverse: il est plus facile de motiver des contributeurs à travailler sur une carte déjà bien remplie plutôt que sur une carte quasiment vide, où à peu près tout reste à faire.. mais bon là on rentre dans la psychologie. Quelle était ta première contribution ? Dans les ateliers de découverte, l'accroche des participants est classiquement : il manque ma rue, le nom de ma rue, la boite aux lettres à coté de chez moi, mon boulanger. Une fois ça ajouté, ils sont pris dans le jeu et continuent. Tu leurs donnes une carte visuellement « complète », ils ne voient pas quoi faire. Alors, si l'import Tiger a été fait avant d'avoir une base de contributeurs locaux, celle-ci est beaucoup plus difficile à construire à postériori. Et puis, je ne veux pas tourner en rond, mais tu préfères contribuer sur de la nouvelle donnée, ou corriger l'existant, voire reprendre l'existant quand celui-ci est foireux ? Donc voilà, à mon sens je ne vois que des côtés positifs à partir du moment où l'import automatique est bien fait. Et encore une fois rien n'empêche de pas retravailler manuellement des données importées automatiquement. Même question. Qui préfère retravailler de la mauvaise donnée que d'en entrer de la nouvelle ? Oui mais bon là t'es en train de partir sur le postulat que j'insère des mauvaises données... Je ne connais pas le langage Java, mais processMultiMatchingTree n'est-il pas une emplâtre sur une jambe de bois ? Un petit tri par distance à l'existant, pour intégrer d'abord les plus proches ? Ah ba te remercie pour la jambe de bois ! ;p Le souci c'est que le tri doit se faire à plusieurs niveaux.. mais il y a sans doute y avoir plus simple ou plus efficace, même si la performance n'est pas du tout un problème puisque l'import prend déjà très peu de temps (environ 3 minutes). Ceci toute pull request est évidemment la bienvenue.. Mais surtout, aussi beau que tu fasses l'algorithme, s'il y a plusieurs MatchingTree avec des distances à moins de 5m avec des distances à peu près équivalentes (un arbre à 2.5m, un autre à 3m), pour moi, c'est plutôt un signe que ces cas devraient être gérés à la main… C'est un cas extrêmement rare qui pourrait éventuellement poser problème mais à condition que les 2 arbres soient différents. Mais il faut rappeler qu'aucun arbre existant sur Nice n'a de tag taxon / height / etc. Il y a juste ceux de la Prom' ont le type=palm (qui sera gardé). ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Importation des arbres municipaux sur Nice
Quelques réponses décousues : Le 26/07/2015 15:47, Vincent Frison a écrit : Par contre j'ai plus de mal à adhérer à l'idée que les imports automatiques déshumaniseraient OSM. Bon déjà je serais le premier partant pour aller boire un verre avec des contributeurs locaux pour parler architecture et botanique :) Vas-y, lance une invitation. Je pense qu'on ne le fait pas assez. En rase campagne, c'est pas forcément évident, mais en ville… Mais surtout, à partir du moment où évidemment les données sont correctes, je ne vois pas en quoi ça gêne: un import a le mérite de rajouter avec peu d'effort (enfin quoique) beaucoup de données qui seraient généralement beaucoup trop fastidieuses à rentrer manuellement. … d'où la demande de leur entretien. Si ça n'intéresse pas grand monde de les mapper, qui va en plus les entretenir ? Dans 10, 20 ans, à quoi ressemblera la base de données ? Pour revenir à l'exemple US que je ne connais pas du tout, j'avoue avoir du mal à croire que ça soit simplement à cause de l'import auto de TIGER qu'il y ait aussi peu de contributeurs. Sauf si l'import a été mal fait mais à ce moment là c'est un autre problème. En fait j'aurais même tendance à penser l'inverse: il est plus facile de motiver des contributeurs à travailler sur une carte déjà bien remplie plutôt que sur une carte quasiment vide, où à peu près tout reste à faire.. mais bon là on rentre dans la psychologie. Quelle était ta première contribution ? Dans les ateliers de découverte, l'accroche des participants est classiquement : il manque ma rue, le nom de ma rue, la boite aux lettres à coté de chez moi, mon boulanger. Une fois ça ajouté, ils sont pris dans le jeu et continuent. Tu leurs donnes une carte visuellement « complète », ils ne voient pas quoi faire. Alors, si l'import Tiger a été fait avant d'avoir une base de contributeurs locaux, celle-ci est beaucoup plus difficile à construire à postériori. Et puis, je ne veux pas tourner en rond, mais tu préfères contribuer sur de la nouvelle donnée, ou corriger l'existant, voire reprendre l'existant quand celui-ci est foireux ? Donc voilà, à mon sens je ne vois que des côtés positifs à partir du moment où l'import automatique est bien fait. Et encore une fois rien n'empêche de pas retravailler manuellement des données importées automatiquement. Même question. Qui préfère retravailler de la mauvaise donnée que d'en entrer de la nouvelle ? Pourquoi la BD Carthage n'a pas été importée ? …Par contre je verrais plutôt ça en rajoutant les tags directement dans OSM depuis son téléphone plutôt que de les noter sur une carte imprimée… La reconnaissance terrain, ce n'est pas forcément avec les Fieldpapers… La charte du contributeur ne le mentionne pas… Ceci dit on était pas à l'abri de cas problématiques, imaginons 2 arbres importés I1, I2 et 3 arbres existants E1, E2, E3 (et que le rayon est de 5m). I12mE1 I13mE2 I21mE1 I24mE3 Avant si je tombais d'abord sur I1 j'utilisais E1 pour le mettre à jour et laissait E2 tel quel. Sauf que I2 est encore plus proche de E1, il devrait être donc être mis à jour pour I2 et c'est E2 qui devrait être mis à jour pour I1. C'est maintenant le cas car je conserve pour chaque arbre existant l'arbre importé le plus proche. - si l'arbre importé n'est pas le meilleur candidat (ie. il y a un autre arbre importé qui est plus proche de l'arbre existant), j'essaye avec les autres arbres existants qui étaient dans son rayon (et s'il n'y a plus d'autres arbres existants alors il faudra créer un nouvel élément) - si l'arbre importé est le meilleur candidat, je peux alors utiliser l'arbre existant pour le mettre à jour. Mais je dois alors relancer tout le processus pour l'ancien meilleur arbre importé qui à son tour pourrait éventuellement faire des changements (fonction récursive). Je ne connais pas le langage Java, mais processMultiMatchingTree n'est-il pas une emplâtre sur une jambe de bois ? Un petit tri par distance à l'existant, pour intégrer d'abord les plus proches ? Mais surtout, aussi beau que tu fasses l'algorithme, s'il y a plusieurs MatchingTree avec des distances à moins de 5m avec des distances à peu près équivalentes (un arbre à 2.5m, un autre à 3m), pour moi, c'est plutôt un signe que ces cas devraient être gérés à la main… Bon c'est pas évident d'expliquer tout ça par mail mais vous pouvez voir les sources ici: https://github.com/vince-from-nice/osmaxil/blob/master/src/main/java/org/openstreetmap/osmaxil/plugin/maker/NiceTreeMaker.java ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Importation des arbres municipaux sur Nice
Le 26 juillet 2015 19:59, Emilie Laffray emilie.laff...@gmail.com a écrit : Petite anecdote. Il fut même considéré a un moment d'effacer les données TIGER existantes afin de recréer une toile blanche. Chose qui au final ne s'est pas fait du faire de la difficulté de séparer ce qui avait été retouché (mais base sur TIGER) et ce qui ne l'avait pas été. Bon d'accord l'import TIGER a visiblement été très négatif pour la naissance de la communauté US.. mais pour revenir concrètement (et plus modestement) à mon import d'arbres sur Nice, vous pensez sincèrement que ça aurait un impact négatif sur la communauté niçoise d'OSM ? Personnellement je ne le pense pas.. je dirais même que la communauté niçoise s'intéressant aux arbres, passerait de 2 à 3 personnes, ce qui ferait tout de même un gain de 50% ! ;p ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Importation des arbres municipaux sur Nice
Le 27/07/2015 00:08, Vincent Frison a écrit : Je commence juste à me rendre compte (je suis un nouveau de 6 mois hein) à quel point les imports auto sont mal vues par ici. Je savais bien que ça pouvait être sensible (ils en parlent même sur la page import du wiki) mais pour être franc je ne m'attendais pas du tout à une telle levée de boucliers pour cet import d'arbres.. si peu risqué à mon sens ! Ça n'est pas pour rien qu'on met un point d'honneur en France à parler d'intégration et non d'import. Intégration signifie que le contributeur (humain) a toujours le dernier mot avant d'envoyer les données au serveur, et que le travail de combinaison avec l'existant lui incombe, bien plus qu'à un robot-algo. J'ai bien conscience que la problématique de la maintenance est évidemment primordiale mais personnellement je ne suis vraiment pas sûr qu'une donnée rentrée manuellement soit forcément plus viable, sur le long terme, qu'une entrée rentrée automatiquement, surtout pour ce type de donnée.Pour revenir par exemple au cas où je rentre manuellement un arbre de mon quartier puis je déménage, je risque fortement de ne plus jamais le mettre à jour. Alors que je pourrais continuer à rejouer tous les 6 mois et sans effort via mon script pour utiliser la dernière mise à jour de l'opendata de Nice indiquant le très peu probable abattage de l'arbre. Ce qui veut dire une confiance totale en la source Open Data. Ça a déjà été rappelé dans ce fil (et dans bien d'autres avant) : une source Open Data doit être croisée à autre chose et pas prise comme telle, seule. D'où souvent le verdict du terrain pour valider la qualité. Je me permet quand même de rappeler que mon import insère des arbres qui sont actuellement bien réels, tout.en respectant les données déjà insérés par environ.. 3 contributeurs différents depuis le tout début d'OSM ! Il faut peut-être admettre le fait que c'est pas un sujet qui passionne les foules et le fait que l'on puisse se l'approprier ou pas un arbre en le créant ne va pas changer grand chose. Avec un peu de pragmatisme on imagine sans peine que sans import automatique il n'y aura jamais de bonne couvertures du parc niçois avant un bon petit siècle.. Le sujet, depuis le début du fil, ce ne sont pas les arbres. C'est comment ce contenu _et le reste_ forme un tout cohérent et maintenu. Quant au temps, ça n'est vraiment pas un souci. Si un besoin d'utiliser les arbres de Nice se présente demain, le fichier OD en tant que tel peut servir, sans passer par la case OSM. Bref j'aurais vraiment du mal admettre que l'on m'interdisse cet import (après la déception de celui pour PSS ça serait dur) même si je ne fera évidemment rien si c'était le cas.. par contre ça serait bien de me le dire clairement et si possible rapidement parce que mine de rien le dev est bientôt fini. Personne ne t'interdira quoi que ce soit, mais entends les messages que tu as ici depuis quelques jours. Tu le dis toi même, ton implication dans le projet est récente, et, de ce que j'en vois, surtout liée à des activités d'import. Ça vaudrait vraiment le coup que tu explores d'autres facettes du projet que les tentatives d'import. Et si c'est vraiment l'aspect technique (dev Java ou autre) qui te botte au final, ce ne sont pas les projets qui manquent dans l'ecosystème OSM pour y trouver ton compte. vincent ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Importation des arbres municipaux sur Nice
Le 26 juillet 2015 22:26, Vincent de Château-Thierry v...@laposte.net a écrit : Le 26/07/2015 21:30, Vincent Frison a écrit : Bon d'accord l'import TIGER a visiblement été très négatif pour la naissance de la communauté US.. mais pour revenir concrètement (et plus modestement) à mon import d'arbres sur Nice, vous pensez sincèrement que ça aurait un impact négatif sur la communauté niçoise d'OSM ? Oui, tant que cette communauté n'aura pas dit le contraire. Ce qui est pointé depuis hier, c'est notamment le caractère intimidant de données importées, et le fait que la maintenance est une tâche beaucoup plus ingrate que la création de données. D'où l'importance de pouvoir s'approprier ce qui est fait, et le meilleur moyen reste encore d'avoir eu l'opportunité de le faire soi-même. Avec un import, difficile de se sentir concerné, affecté, par les données. C'est plutôt le découragement qui prévaut. J'aurais un discours plus modulé si on avait dans le cadre de ce fil un echo de contributeurs locaux, qui diraient en substance : c'est bon, que l'import soit fait, on s'occupe de la suite. Mais pour l'instant je n'entends rien. Il est effectivement assez peu probable qu'une task force niçoise envahissent le forum pour me venir en secours, à priori elle aurait déjà fait vu le titre du sujet ! Je commence juste à me rendre compte (je suis un nouveau de 6 mois hein) à quel point les imports auto sont mal vues par ici. Je savais bien que ça pouvait être sensible (ils en parlent même sur la page import du wiki) mais pour être franc je ne m'attendais pas du tout à une telle levée de boucliers pour cet import d'arbres.. si peu risqué à mon sens ! J'ai bien conscience que la problématique de la maintenance est évidemment primordiale mais personnellement je ne suis vraiment pas sûr qu'une donnée rentrée manuellement soit forcément plus viable, sur le long terme, qu'une entrée rentrée automatiquement, surtout pour ce type de donnée. Pour revenir par exemple au cas où je rentre manuellement un arbre de mon quartier puis je déménage, je risque fortement de ne plus jamais le mettre à jour. Alors que je pourrais continuer à rejouer tous les 6 mois et sans effort via mon script pour utiliser la dernière mise à jour de l'opendata de Nice indiquant le très peu probable abattage de l'arbre. Je me permet quand même de rappeler que mon import insère des arbres qui sont actuellement bien réels, tout.en respectant les données déjà insérés par environ.. 3 contributeurs différents depuis le tout début d'OSM ! Il faut peut-être admettre le fait que c'est pas un sujet qui passionne les foules et le fait que l'on puisse se l'approprier ou pas un arbre en le créant ne va pas changer grand chose. Avec un peu de pragmatisme on imagine sans peine que sans import automatique il n'y aura jamais de bonne couvertures du parc niçois avant un bon petit siècle.. Bref j'aurais vraiment du mal admettre que l'on m'interdisse cet import (après la déception de celui pour PSS ça serait dur) même si je ne fera évidemment rien si c'était le cas.. par contre ça serait bien de me le dire clairement et si possible rapidement parce que mine de rien le dev est bientôt fini. ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Importation des arbres municipaux sur Nice
L'import se résume à peu de valeur ajoutée, ce n'est pas comparable à PSS. Ici tu veux ajouter un nœud par arbre (nouveau). Pas de taille, pas d'âge, pas d'espèce, etc... Donc suffisant pour la municipalité pour savoir quoi arroser. C'est le problème de l'usage. Ajouter une info globalement pauvre même si pertinente sur un point, c'est bien *s**'il* est probable que les gens la complètent. Si c'est une graine que tu peux faire germer c'est bien, si c'est un sapin de Noël synthétique, ça nuit aux données alentour ! Mais d'un point de vue cartographique c'est pauvre. MarcelHerault http://www.openstreetmap.org/user/MarcelHerault a ajouté le type (bon, il a dû se taper Bing pour repérer les palmiers). Tu ne peux pas contacter ceux qui ont contribué localement à OSM pour voir s'ils sont disposés à compléter les données que tu veux importer ? Ce qu'on essaye de dire, ce n'est pas que tu as bossé pour rien, c'est qu'il faut ce servir de ce travail pour apporter une vraie valeur ajoutée (mon discours) ou de pas casser la communauté ou inciter à la créer. Peut-être que les deux autres mappeurs d'arbres sur OSM seront contents et s'ils disent qu'ils veulent partir de cet import pour le compléter, banco. Et je suis le premier à reconnaître que la discussion aura permis d'éviter des problèmes d'import (import avec destruction, hauteur arbitraire). Ce qui es la preuve que tu n'as pas bossé pour rien puisque tu as appris (pas de raison d'être frustré). Ce qu'on te suggère c'est d'importer sous QGIS, umap, etc... et de faire des carto-parties (en vriae, en orhto-pohto, en Mapillary...) pour ajouter de vraies informations. Désolé, savoir qu'il y a un arbre m'importe peu. Un parc, oui c'est une info intéressante, un chêne centenaire aussi. Mais un arbre quelconque ? Et si c'est une rangée de platanes, si tu as le type d'un, la suite est facile. Mais c'est l'arbre qui cache la forêt : je vois que des rues de Nice n'ont pas de nom (http://www.openstreetmap.org/way/156776064). Il semble pourtant y avoir des habitants, il y a même des numéros sur les bâtiments (http://tile.openstreetmap.fr/~cquest/leaflet/bano.html#19/43.71235/7.27541 http://tile.openstreetmap.fr/%7Ecquest/leaflet/bano.html#19/43.71235/7.27541). Alors un nom de rue, de résidence ? Si je veux aller à Nice, la carte me sert avant tout à trouver les rues. Les arbres, ça vient après, seulement après. PSS donne des infos pertinentes sur des lieux remarquables, comme http://structurae.net/. Relier ces données à OSM me semble bien plus intéressant, pertinent. Jean-Yvon Le 27/07/2015 00:08, Vincent Frison - vincent.fri...@gmail.com a écrit : Le 26 juillet 2015 22:26, Vincent de Château-Thierry v...@laposte.net mailto:v...@laposte.net a écrit : Le 26/07/2015 21:30, Vincent Frison a écrit : Bon d'accord l'import TIGER a visiblement été très négatif pour la naissance de la communauté US.. mais pour revenir concrètement (et plus modestement) à mon import d'arbres sur Nice, vous pensez sincèrement que ça aurait un impact négatif sur la communauté niçoise d'OSM ? Oui, tant que cette communauté n'aura pas dit le contraire. Ce qui est pointé depuis hier, c'est notamment le caractère intimidant de données importées, et le fait que la maintenance est une tâche beaucoup plus ingrate que la création de données. D'où l'importance de pouvoir s'approprier ce qui est fait, et le meilleur moyen reste encore d'avoir eu l'opportunité de le faire soi-même. Avec un import, difficile de se sentir concerné, affecté, par les données. C'est plutôt le découragement qui prévaut. J'aurais un discours plus modulé si on avait dans le cadre de ce fil un echo de contributeurs locaux, qui diraient en substance : c'est bon, que l'import soit fait, on s'occupe de la suite. Mais pour l'instant je n'entends rien. Il est effectivement assez peu probable qu'une task force niçoise envahissent le forum pour me venir en secours, à priori elle aurait déjà fait vu le titre du sujet ! Je commence juste à me rendre compte (je suis un nouveau de 6 mois hein) à quel point les imports auto sont mal vues par ici. Je savais bien que ça pouvait être sensible (ils en parlent même sur la page import du wiki) mais pour être franc je ne m'attendais pas du tout à une telle levée de boucliers pour cet import d'arbres.. si peu risqué à mon sens ! J'ai bien conscience que la problématique de la maintenance est évidemment primordiale mais personnellement je ne suis vraiment pas sûr qu'une donnée rentrée manuellement soit forcément plus viable, sur le long terme, qu'une entrée rentrée automatiquement, surtout pour ce type de donnée. Pour revenir par exemple au cas où je rentre manuellement un arbre de mon quartier puis je déménage, je risque fortement de ne plus jamais le mettre à jour. Alors que je pourrais continuer à rejouer tous les 6 mois et sans effort via mon script pour
Re: [OSM-talk-fr] Importation des arbres municipaux sur Nice
2015-07-26 10:51 GMT-07:00 JB jb...@mailoo.org: Pour revenir à l'exemple US que je ne connais pas du tout, j'avoue avoir du mal à croire que ça soit simplement à cause de l'import auto de TIGER qu'il y ait aussi peu de contributeurs. Sauf si l'import a été mal fait mais à ce moment là c'est un autre problème. En fait j'aurais même tendance à penser l'inverse: il est plus facile de motiver des contributeurs à travailler sur une carte déjà bien remplie plutôt que sur une carte quasiment vide, où à peu près tout reste à faire.. mais bon là on rentre dans la psychologie. Quelle était ta première contribution ? Dans les ateliers de découverte, l'accroche des participants est classiquement : il manque ma rue, le nom de ma rue, la boite aux lettres à coté de chez moi, mon boulanger. Une fois ça ajouté, ils sont pris dans le jeu et continuent. Tu leurs donnes une carte visuellement « complète », ils ne voient pas quoi faire. Alors, si l'import Tiger a été fait avant d'avoir une base de contributeurs locaux, celle-ci est beaucoup plus difficile à construire à postériori. Et puis, je ne veux pas tourner en rond, mais tu préfères contribuer sur de la nouvelle donnée, ou corriger l'existant, voire reprendre l'existant quand celui-ci est foireux ? Petite anecdote. Il fut même considéré a un moment d'effacer les données TIGER existantes afin de recréer une toile blanche. Chose qui au final ne s'est pas fait du faire de la difficulté de séparer ce qui avait été retouché (mais base sur TIGER) et ce qui ne l'avait pas été. Parmi les exemples similaires, on peut parler des Pays-Bas qui après un import de très grande qualité a perdue une grosse partie de ses contributeurs. Le fait est travailler avec des données vectorielles n'est pas facile et il y a au moins une étude qui montre que pour beaucoup de contributeurs (je ne retrouve plus le lien) s'approprie ce qu'ils ont ajouté (cad C'est moi qui l'ai fait!). C'est aussi un peu la difficulté de la maintenance d'OSM (la encore plusieurs articles scientifiques sur le sujet) une fois que la carte est bien remplie. ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Importation des arbres municipaux sur Nice
Mais surtout, aussi beau que tu fasses l'algorithme, s'il y a plusieurs MatchingTree avec des distances à moins de 5m avec des distances à peu près équivalentes (un arbre à 2.5m, un autre à 3m), pour moi, c'est plutôt un signe que ces cas devraient être gérés à la main… Ce que je voulais entendre de la part de Vincent quand je parlais de ne pas privilégier une source plus qu'une autre. Surtout si l'on part du principe que les données ne sont pas de bonne qualité (ce qui n'est pas forcément le cas) Et pas besoin de FieldPapers pour aller faire du terrain avec un fond de plan. QGIS le fait très bien! Et pour travailler sur une thématique c'est assez simple de pointer avec un stylo et de vérifier avec une ortho. Comme dit précédemment, un Smartphone pour prendre des points sur le terrain c'est vraiment médiocre surtout quand ces points sont pris par des personnes qui considèrent que le GPS c'est toujours le meilleurs moyen d'avoir de la qualité et que les données sont poussés dans OSM sans retouche... On a des données à OSM qui sont affichés au même niveau avec une différence de qualité de rendu. Chaque référentiel importé ou non dans OSM est prévu avec une précision correspondant à son utilisation métier. Le problème c'est de pouvoir regrouper des usages. Autre problématique d'intégration et dont il n'y a même pas un consensus (même sur une commune) c'est adresse postal Certains parle de le mettre à l'entrée du bâtiment, d'autres sur le bâtiment, d'autre devant la rue à l'entrée. On fait quoi pour qui en fait? La poste prendra la boite et la sonnette, d'autre service pour les clients ce sera la porte d'entrée, Certains ce sera le boitier électrique, le compteur de gaz ou d'eau. Et c'est la même pour les commerces. Pas facile de faire la part des choses quand on parle de précision avec une base qui en contient différents niveaux de précision (contribution ou données importées) ___ 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] Importation des arbres municipaux sur Nice
Je comprends les raisons et je vais pas insister dessus. D'ailleurs en passant par QGIS, je peux valider mes données, en vérifier la complétude, invalider ou valider mes données avant de faire une intégration ou un complément sous JOSM. J'aurais un discours plus modulé si on avait dans le cadre de ce fil un echo de contributeurs locaux, qui diraient en substance : c'est bon, que l'import soit fait, on s'occupe de la suite. Mais pour l'instant je n'entends rien. Le constat sur la couverture BANO va dans le même sens. En s'appuyant sur les stats par département (pour Nice : http://cadastre.openstreetmap.fr/fantoir-dev/stats_dept.html#dept=06 ) sur les 10 plus grosses communes de France Nice est celle avec le moins bon ratio a/c. Ça n'est qu'un constat (surtout pas un reproche) mais ce thermomètre (parmi d'autres) de l'activité locale montre qu'on a moins de dynamisme que sur les autres villes de même importance. Et dans ce contexte, je ne vois pas comment un ajout massif et mécanique va motiver du monde pour s'approprier la ville et alentours et _maintenir_ les données (des arbres mais pas que). Ça justifie la problématique de suivi. ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Importation des arbres municipaux sur Nice
Le 25 juillet 2015 18:53, Vincent Pottier vpott...@gmail.com a écrit : Si le programme, qui détecte la présence d'un arbre à 2 m, pouvait modifier le point existant plutôt que de le remplacer, ce serait top. Merci pour ceux qui ont œuvré à OSM. Mais c'est le cas ! J'ai justement changé le programme pour qu'il mette à jour les arbres existants à moins de X mètres au lieu de les supprimer.. ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Importation des arbres municipaux sur Nice
Moi, ce qui me gène dans le fait de remplacer ( effacer et créer un nouvel ) un arbre, c'est la perte de l'historique et le passage à la trappe des contributions antérieures. OpenStreetMap, c'est aussi la mémoire des contributions anciennes. Comme dans Wikipédia, la trace historique est une façon d'honorer ceux qui ont fait OSM. Certes, le point ancien reste quelque part au fond de la base de donnée. Mais, il n'apparait plus dans aucun historique d'objet présent, enterré, oublié, disparu. Dans le roman de science-fiction 1984, l'histoire est effacée et ré-écrite, sans mémoire, sans épaisseur du temps. Nous ne sommes pas Winston Smith, qui efface les archives pour les faire correspondre à l'actualité du Parti. Certes, dans le roman, l'effacement est idéologique, dans le cas présent, il ne serait que par négligence, insouciance, facilité. La richesse d'OSM, c'est bien sur ses données, techniquement excellentes (tout au moins on s'y essaie), mais c'est plus encore sa communauté. Que devient cette richesse technique, si par facilité, on efface l'épaisseur humaine de cette communauté ? Une donnée technique mouvante, errante à travers le temps ? Un peuple sans mémoire est un peuple sans avenir aurait dit un certain Foch. Si le programme, qui détecte la présence d'un arbre à 2 m, pouvait modifier le point existant plutôt que de le remplacer, ce serait top. Merci pour ceux qui ont œuvré à OSM. C'était mon quart-d'heure philo... -- FrViPofm Le 21 juillet 2015 14:05, Vincent Frison vincent.fri...@gmail.com a écrit : Hello Je compte importer dans OSM l'ensemble des arbres municipaux de Nice, merci au portail OpenData de l'agglomération de Côte d'Azur. Ici c'est du vrai open data, je ne devrais donc pas avoir la même frustration qu'avec l'import des immeubles de PSS ;) Ils viennent de mettre à jour leur fichier qui contient maintenant plus de 30 000 arbres : http://opendata.nicecotedazur.org/data/dataset?q=arbres En plus de créer les nouveaux arbres mon programme vérifie également la présence d'arbres existants afin de les effacer. Actuellement j'ai mis un rayon de 2 mètres donc pour chaque arbre importé, je regarde les arbres existants qui sont à moins de 2 mètres. Pour l'instant je n'efface que l'arbre plus proche de l'arbre importé (je pourrais également supprimer tous les arbres qui sont à moins de x mètres mais en fait ça ne change pas grand chose car s'il y a plusieurs arbres existants qui sont très proches à priori il y aura également plusieurs arbres importés qui seront très proches donc au final même en ne supprimant que l'arbre existant le plus proche tous les arbres existants seront bien effacés, ce que j'ai pu vérifier par mes tests). Concrètement sur les ~30 000 arbres importés il y a ~540 arbres existants à supprimer. Ce qui est dommage c'est que le fichier n'indique pas le type des arbres et c'est d'autant plus dommage que les arbres existants ont parfois un tag type=*. Par ex. les arbres existants le long de la Promenade des Anglais sont marqué comme palmier (type=palm). Malheureusement je serai obligé de remettre le type à la main une fois l'import exécuté. Mon programme pourrait éventuellement récupérer le type des arbres existants mais bon ça ne marcherait que sur une toute petite partie des arbres importés... D'ailleurs j'ai un peu de mal à comprendre la bonne manière d'indiquer le type car sur la page Wiki du tag natural=tree ( http://wiki.openstreetmap.org/wiki/Tag:natural%3Dtree) il est marqué que le tag type=* est obsolète et qu'il faut plutôt utilisé le tag leaf_type=*. Sauf que ce dernier n'est censé prendre que les valeurs suivantes : broadleaved / needleleaved / mixed / leafless. De plus sous JSOM si on met type=palm ça affiche bien l'arbre avec une image de palmier mais ça ne le fait pas si j'essaye avec genus|species=palm|palmtree. Bref c'est pas très clair... Voila si vous avez des conseils ou suggestions n'hésitez surtout pas.. ++ Vincent. ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Importation des arbres municipaux sur Nice
Au fait le portail OpenData de Nice utilise la Licence Ouverte ( http://www.etalab.gouv.fr/licence-ouverte-open-licence), on est bien d'accord que c'est bien compatible avec l'ODbL ? A priori oui mais c'est juste pour être sûr ;) ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Importation des arbres municipaux sur Nice
De plus si une administration a un SIG donnant ces informations et les proposant à l'import, on peut supposer que soit ils comptent sur les contributeurs pour leur signaler les problèmes soit ils vont vouloir que l'import soit fait régulièrement. Sinon ça ne fait pas très sérieux. Vincent, tu peux peut-être voir avec eux pour que leur base et OSM restent cohérents. Selon le wiki http://wiki.openstreetmap.org/wiki/FR:Tag:natural%3Dtree : natural=tree : Arbre important seul ou en groupes. 453 298 en France. Si tu ne sais pas, ne vaut-il pas mieux mettre pour les nouvelles entrées : natural http://wiki.openstreetmap.org/wiki/FR:Key:natural wood http://wiki.openstreetmap.org/wiki/Tag:natural%3Dwood Nœud http://wiki.openstreetmap.org/wiki/FR:%C3%89l%C3%A9ments#N.C5.93ud_.28node.29 Zone http://wiki.openstreetmap.org/wiki/FR:%C3%89l%C3%A9ments#Area_.28closed_way.29 Bois. 360 en France Par contre quand je vois proposer de mettre une taille par défaut, ça me semble aller contre l'usage : quand on n'a pas d'info, on ne l'invente pas. Tu peux peut-être ajouter un fixme pour discriminer ceux qui n'ont pas été vérifiés sur le terrain, ou fixme et une hauteur arbitraire. Il me semble plus efficace d'essayer de récupérer plus d'information (j'imagine que la municipalité sait ce qui est planté). Ou une note (pour que les cartographes aillent compléter). Le rendu est donc conforme à la description (arbre important, pas arbre et encore moins arbuste). Donc soit il s'agit d'un arbre soit il s'agit d'un arbuste. Si tu veux ajouter une estimation de largeur : est_width http://wiki.openstreetmap.org/wiki/FR:Key:est_width=*. Alors est_height si tu y tiens ? Ou : height= source:height http://wiki.openstreetmap.org/wiki/FR:Key:source extrapolation Doit on mettre operator avec le service technique de Nice ? Jean-Yvon Le 24/07/2015 16:16, Jérôme Seigneuret - jseigneuret-...@yahoo.fr a écrit : Le problème des arbres est similaire à celui du bâti. On dézingue pas des arbres régulièrement (en tout cas en ville)... Il y a qu'a voir les platanes. Sauf maladie, tempête, risque pour la sécurité des usagers, il n'y a pas de raison. Si la croissance est importante et que les arbres sont plantés trop proche pour les premières années (histoire de faire joli), il y a un arbre sur deux qui saute (au bout de dix ans en principe). D'ici là on a le temps de voir les choses changer. Le 24 juillet 2015 14:53, Vincent Frison vincent.fri...@gmail.com mailto:vincent.fri...@gmail.com a écrit : Le 24 juillet 2015 14:44, JB jb...@mailoo.org mailto:jb...@mailoo.org a écrit : Sans vouloir trop m'avancer, je pense que Christian demandait : « Qui va s'occuper de l'entretien des données arbres à Nice ? ». C'est beau (ou pas) de les importer, mais quid de leur évolution dans 2, 5, 15 ans ? Est-ce que les mappeurs locaux sont ok pour s'en charger ? Est-ce que tu es prêt à t'en charger ? Oui je suis ok pour m'en occuper (j'habite la région pour info), y compris dans 15 ans si je suis toujours vivant... ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Importation des arbres municipaux sur Nice
Le 25 juillet 2015 16:45, osm.sanspourr...@spamgourmet.com a écrit : De plus si une administration a un SIG donnant ces informations et les proposant à l'import, on peut supposer que soit ils comptent sur les contributeurs pour leur signaler les problèmes soit ils vont vouloir que l'import soit fait régulièrement. Sinon ça ne fait pas très sérieux. Vincent, tu peux peut-être voir avec eux pour que leur base et OSM restent cohérents. A vrai dire je n'ai plus de nouvelles d'eux depuis quelque temps, la personne avec qui j'étais en contact est surement en vacance. Selon le wiki http://wiki.openstreetmap.org/wiki/FR:Tag:natural%3Dtree : natural=tree : Arbre important seul ou en groupes. 453 298 en France. Si tu ne sais pas, ne vaut-il pas mieux mettre pour les nouvelles entrées : natural http://wiki.openstreetmap.org/wiki/FR:Key:natural wood http://wiki.openstreetmap.org/wiki/Tag:natural%3Dwood [image: Nœud] http://wiki.openstreetmap.org/wiki/FR:%C3%89l%C3%A9ments#N.C5.93ud_.28node.29 [image: Zone] http://wiki.openstreetmap.org/wiki/FR:%C3%89l%C3%A9ments#Area_.28closed_way.29 Bois. 360 en France J'avoue ne pas très bien comprendre, apparemment ce natural=wook est vraiment fait pour les forêts ou bois, mais dans le cadre d'import d'arbres municipaux ça n'a pas trop de sens.. enfin cela pourrait éventuellement en avoir pour deux ou trois gros parcs dans Nice mais perso je préfère les implémenter en rajoutant des éléments avec natural=tree. En plus de ça mon programme ne sait pas faire cela actuellement, il faudrait détecter des zones a forte concentration et c'est pas si simple. Ceci dit si c'est vraiment gênant rien n'empêchera de le faire manuellement après l'import (cad supprimer les arbres importés et rajouter une zone avec natural=wood). Par contre quand je vois proposer de mettre une taille par défaut, ça me semble aller contre l'usage : quand on n'a pas d'info, on ne l'invente pas. Tu peux peut-être ajouter un fixme pour discriminer ceux qui n'ont pas été vérifiés sur le terrain, ou fixme et une hauteur arbitraire. Il me semble plus efficace d'essayer de récupérer plus d'information (j'imagine que la municipalité sait ce qui est planté). Ou une note (pour que les cartographes aillent compléter). Oui j'avoue que cela me gênait aussi.. du coup j'essayerai de faire des mises à jour manuelles sur les arbres de la Prom' pour réduire la taille des petits arbres. Le rendu est donc conforme à la description (arbre important, pas arbre et encore moins arbuste). Donc soit il s'agit d'un arbre soit il s'agit d'un arbuste. J'ai pas trop compris.. il ne faudrait pas importer des arbres dans OSM si ceux ci sont petits ? Si tu veux ajouter une estimation de largeur : est_width http://wiki.openstreetmap.org/wiki/FR:Key:est_width=*. Alors est_height si tu y tiens ? Ah je ne savais pas que ce tag est_height existait.. mais est il vraiment pris en charge par les moteurs de rendu (F4map) ? Parce qu'il n'a pas l'air super officiel puisqu'il n'existe pas sur le wiki (contrairement au tag est_width) mais je vais essayer. Doit on mettre operator avec le service technique de Nice ? Ah je sais pas, mais ça me parait une bonne idée... en mettant Municipality of Nice comme valeur ? ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Importation des arbres municipaux sur Nice
Les deux ne sont pas incompatible. L'import ne donne que la position. Rien n’empêche de faire une campagne de terrain pour définir qu'elle est le type d'arbre et les infos qui suivent. Je suis bien d'accord que faire du terrain en groupe c'est cool. Maintenant, il y a un intérêt certains d'avoir les arbres sur le plan et de pourvoir vérifier avec une version imprimé directement. Après il est sûr que suite à l'intégration laisser un message sur la liste PACA ou celle du 06 serait une bonne chose. Il y a aussi les Lycée d'aménagements Paysagers qui pourraient être sollicité ou intéressé ainsi que les filières SIG du coin... Peut-être qu'un serveur avec une carte bac à sable avec une possibilité d'imprimer offrirait le meilleur compromis pour éviter des coups d'intégration massif (de bonne volonté). Osmose me semble pas être le seul moyen de faire de l'intégration (en tous cas du point par point pour des arbres c'est trop long). Je rentre près de 200 arbres par jour pour des arbres d'alignements avec les taxons. D'ailleurs après avoir corrigé une erreur de tag obsolète name:botanical (proposition existant toujours dans le formulaire JOSM) et l'avoir remplacé massivement en taxon à partir de JOSM, j'ai les avertissements d'erreurs qui sont toujours présents. En évolution il serait intéressant d'ajouter un bouton pour forcer la vérification des erreurs pour savoir si elles existent encore ou de faire un check lors de la connexion. Le 25 juillet 2015 22:50, Vincent de Château-Thierry v...@laposte.net a écrit : Le 25/07/2015 19:27, Vincent Frison a écrit : Le 25 juillet 2015 18:53, Vincent Pottier vpott...@gmail.com mailto:vpott...@gmail.com a écrit : Si le programme, qui détecte la présence d'un arbre à 2 m, pouvait modifier le point existant plutôt que de le remplacer, ce serait top. Merci pour ceux qui ont œuvré à OSM. Mais c'est le cas ! J'ai justement changé le programme pour qu'il mette à jour les arbres existants à moins de X mètres au lieu de les supprimer.. Et si on s'y prenait autrement ? Et si les données des arbres de Nice étaient un prétexte à une autre démarche, où le programme, en cours de discussion, n'était pas une fin mais juste un moyen ? Les imports au sens strict sont rares en France. On a eu Corine fin 2009, les repères géodésiques début 2010, et depuis, pas grand chose. Car on a mis un point d'honneur, à maintes reprises, à _ne pas_ procéder à des imports, mais à des opérations d'intégration. En insistant bien sur la nuance : l'intégration laisse le dernier mot au contributeur, et non à un robot, aussi futé soit-il. L'intégration s'appuie sur Osmose ou des outils spécifiques (postes, écoles, adresses, bâtiments, etc.). Pourtant, ce ne sont pas les données qui manquent, qui seraient prétextes à import. On croule sous les jeux de données OpenData, on a depuis l'année dernière accès aux adresses du cadastre vectoriel, bref, si on voulait, on passerait notre temps à importer. Sauf qu'un import laisse de côté, par définition, une des forces principales d'OSM, à savoir l'implication de contributeurs sur le terrain, la connaissance qu'ils en tirent, et qui en retour profite à la base et au projet. Vincent, je salue ton initiative de vouloir ajouter les arbres sur Nice et alentours. Sans contester la finalité, si on prenait un autre chemin pour y arriver ? Par exemple, en prenant ce matériau comme prétexte pour réunir quelques contributeurs niçois, autour d'un ordi et d'un verre, afin de discuter d'une démarche concertée pour ajouter les arbres sur Nice ? Quid d'un relevé sur un quartier ? De prises de vue ? D'une intégration suite à constat terrain, qui au passage permet une vraie évaluation du jeu de données OD ? D'une division du territoire où chacun s'empare d'un quartier ? Si on parvient via ce prétexte à fédérer des énergies, le bénéfice, sur la durée, me semble évident. La contrepartie, toute aussi évidente, est que la présence des arbres de Nice dans la base prendra bien plus de temps et de délai que via un import. Mais est-ce un problème ? vincent ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Importation des arbres municipaux sur Nice
Le 25/07/2015 23:42, Jérôme Seigneuret a écrit : Les deux ne sont pas incompatible. L'import ne donne que la position. Si au moins il la donnait... La précision géographique n'est clairement pas ce qu'il y a de meilleur quand on commence à challenger les jeux de données OpenData. Par principe il est impossible de généraliser sur la qualité, tant il y a de producteurs et de méthodes différents, mais s'il y a bien un point sur lequel il faut douter sur _tous_ les jeux de données, c'est le positionnement, la qualité de la géométrie. Rien n’empêche de faire une campagne de terrain pour définir qu'elle est le type d'arbre et les infos qui suivent. Je suis bien d'accord que faire du terrain en groupe c'est cool. Maintenant, il y a un intérêt certains d'avoir les arbres sur le plan et de pourvoir vérifier avec une version imprimé directement. L'intérêt d'avoir les arbres in fine, je ne le discute pas, c'est un niveau de détail vers lequel on va (tout comme distinguer les trottoirs du filaire de voie, etc.) même si la densité de points en certains endroits (c'est le cas dans Nice) va en intimider plus d'un au moment d'éditer la carte. Après il est sûr que suite à l'intégration laisser un message sur la liste PACA ou celle du 06 serait une bonne chose. Bingo : il n'y a ni liste PACA ni liste 06... Construire une dynamique locale passe je pense plus par la constitution de ce genre d'espace d'échange que par un import. Il y a aussi les Lycée d'aménagements Paysagers qui pourraient être sollicité ou intéressé ainsi que les filières SIG du coin... Par exemple oui. Peut-être qu'un serveur avec une carte bac à sable avec une possibilité d'imprimer offrirait le meilleur compromis pour éviter des coups d'intégration massif (de bonne volonté). Je lis coût ;) Imprimer le jeu de données dans son contexte, avec un fond carto dessous, ne nécessite absolument pas d'avoir procédé à un import. Avec un outil comme QGis (voire JOSM, mais je ne sais pas ce qu'il vaut pour imprimer) c'est très simple de combiner un jeu de données comme les arbres de Nice, et un fond OSM ou autre. Et c'est un bon document de travail pour aller sur place. vincent ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Importation des arbres municipaux sur Nice
L'intérêt d'avoir les arbres in fine, je ne le discute pas, c'est un niveau de détail vers lequel on va (tout comme distinguer les trottoirs du filaire de voie, etc.) Disons que ça fait une carte à plusieurs échelle de précision. C'est un peu le principe du schéma suisse INTERLIS 2 qui permet suivant l'échelle de spécifier des objets avec plus ou moins de détail. C'est pas forcément utile partout mais en ville c'est quand même sympa surtout quand derrière on parle de faire de la 3D. C'est sur que quand on parle de détail j'ai en mémoire la CLC et une échelle qui ne correspond pas à ce que l'on souhaite dans OSM. Si on parle de vandalisme en affichant des arbres qu'en est t'il de la CLC? J'ai déjà corrigé des zones mais en plus avec les multipolygones c'est vraiment pas simple à gérer. Perso je redécoupe Bingo : il n'y a ni liste PACA ni liste 06... Construire une dynamique locale passe je pense plus par la constitution de ce genre d'espace d'échange que par un import. Pas de liste de coordination ne veut pas forcément dire pas de contributeurs. Il n'y en a pas beaucoup de renseigné mais il y a ça juste pour Nice alors pour PACA je ne sais pas http://wiki.openstreetmap.org/wiki/Category:Users_in_Nice Je lis coût ;) Imprimer le jeu de données dans son contexte, avec un fond carto dessous, ne nécessite absolument pas d'avoir procédé à un import. Avec un outil comme QGis (voire JOSM, mais je ne sais pas ce qu'il vaut pour imprimer) c'est très simple de combiner un jeu de données comme les arbres de Nice, et un fond OSM ou autre. Et c'est un bon document de travail pour aller sur place. Je parle du bac à sable car ça permettrait aussi de faire des tests en effet ça a un coût mais c'est aussi le coût de l'entrainement ou le la formation pour éviter d'intégrer n'importe quoi n'importe comment. Oui c'est vrai que via QGIS c'est aussi possible.Où avais-je la tête... . Pour la question est-ce un bon document? Clairement oui. Je travaille ainsi sur le terrain pour faire mes relevés et je gagne pas mal de temps. Coté édition mobile c'est trop long pour moi et la qualité c'est trop pourri (de 3m à 15m) proche de batîments testé avec Mapillary qui refusait des fois de faire la prise de vu à cause d'une précision. Reste les bonnes vieilles méthodes. La trigonométrie sur le terrain avec un mètre de terrain de 20 à 50m et des points de référence. Au moins on voit ce qui est intégré. Le truc qui me manque coté QGIS c'est le mapcss qui existe sur JOSM pour faire de la carte orientée thématique. Peut-être en faisant des exports Overpass par thème et faire une symbologie spécifique sous QGIS. Jérôme ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Importation des arbres municipaux sur Nice
Le 25/07/2015 19:27, Vincent Frison a écrit : Le 25 juillet 2015 18:53, Vincent Pottier vpott...@gmail.com mailto:vpott...@gmail.com a écrit : Si le programme, qui détecte la présence d'un arbre à 2 m, pouvait modifier le point existant plutôt que de le remplacer, ce serait top. Merci pour ceux qui ont œuvré à OSM. Mais c'est le cas ! J'ai justement changé le programme pour qu'il mette à jour les arbres existants à moins de X mètres au lieu de les supprimer.. Et si on s'y prenait autrement ? Et si les données des arbres de Nice étaient un prétexte à une autre démarche, où le programme, en cours de discussion, n'était pas une fin mais juste un moyen ? Les imports au sens strict sont rares en France. On a eu Corine fin 2009, les repères géodésiques début 2010, et depuis, pas grand chose. Car on a mis un point d'honneur, à maintes reprises, à _ne pas_ procéder à des imports, mais à des opérations d'intégration. En insistant bien sur la nuance : l'intégration laisse le dernier mot au contributeur, et non à un robot, aussi futé soit-il. L'intégration s'appuie sur Osmose ou des outils spécifiques (postes, écoles, adresses, bâtiments, etc.). Pourtant, ce ne sont pas les données qui manquent, qui seraient prétextes à import. On croule sous les jeux de données OpenData, on a depuis l'année dernière accès aux adresses du cadastre vectoriel, bref, si on voulait, on passerait notre temps à importer. Sauf qu'un import laisse de côté, par définition, une des forces principales d'OSM, à savoir l'implication de contributeurs sur le terrain, la connaissance qu'ils en tirent, et qui en retour profite à la base et au projet. Vincent, je salue ton initiative de vouloir ajouter les arbres sur Nice et alentours. Sans contester la finalité, si on prenait un autre chemin pour y arriver ? Par exemple, en prenant ce matériau comme prétexte pour réunir quelques contributeurs niçois, autour d'un ordi et d'un verre, afin de discuter d'une démarche concertée pour ajouter les arbres sur Nice ? Quid d'un relevé sur un quartier ? De prises de vue ? D'une intégration suite à constat terrain, qui au passage permet une vraie évaluation du jeu de données OD ? D'une division du territoire où chacun s'empare d'un quartier ? Si on parvient via ce prétexte à fédérer des énergies, le bénéfice, sur la durée, me semble évident. La contrepartie, toute aussi évidente, est que la présence des arbres de Nice dans la base prendra bien plus de temps et de délai que via un import. Mais est-ce un problème ? vincent ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Importation des arbres municipaux sur Nice
J'aime assez la proposition de Vincent (celui à qui un reflet d'un petit guide vert permet de faire un clin d’œil - vdct pour ceux qui n'auraient pas compris) : c'est de la Cartographie Assistée par Ordinateur. Il n'est pas le seul à se méfier des imports tueurs, le plus célèbre restant la base de donnée routière américaine Tiger. Excellent pour avoir 80 %... et geler les 20 % restants. Combien de routes en pleine campagne voir en forêt aux États-Unis sont encore taguées route résidentielle ? Un rapprochement comme ceux que proposent Osmose ou les outils typiquement proposés par Christian permet de faciliter la tâche sans la déshumaniser. Si après import, la référence devient OSM (mais je doute), on est sûr que ce ne sera pas une terre gelée. J'étais moins radical en proposant des fixme, j'avoue que maintenant je ne sais pas trop que penser (il faut aussi connaître le potentiel OSM du côté de Nice). Si tu ne sais pas, ne vaut-il pas mieux mettre pour les nouvelles entrées : natural http://wiki.openstreetmap.org/wiki/FR:Key:natural wood http://wiki.openstreetmap.org/wiki/Tag:natural%3Dwood Nœud http://wiki.openstreetmap.org/wiki/FR:%C3%89l%C3%A9ments#N.C5.93ud_.28node.29 Zone http://wiki.openstreetmap.org/wiki/FR:%C3%89l%C3%A9ments#Area_.28closed_way.29 Bois. 360 en France J'avoue ne pas très bien comprendre, apparemment ce natural=wook est vraiment fait pour les forêts ou bois, mais dans le cadre d'import d'arbres municipaux ça n'a pas trop de sens.. C'est normal, j'ai oublié un mot : nœud : il y a 360 nœuds natural=wood en France, pour les zones ce sont des bois mais je n'y faisait pas référence. Je n'imagine pas qu'il s'agisse de parcs (un parc réduit à un nœud...) mais d'arbustes. du coup j'essayerai de faire des mises à jour manuelles sur les arbres de la Prom' pour réduire la taille des petits arbres. Si un de ces quatre vous entendez parler d'un maniaque du sécateur sur la Promenade qui s'attaque aux petits arbres :-D. J'ai pas trop compris.. il ne faudrait pas importer des arbres dans OSM si ceux ci sont petits ? je disais que s'ils sont petits on doit se poser la question : natural=wood ou natural=tree ? Non le tag est_height n'existe pas encore. Mais si on estime la taille il vaut mieux le dire proprement et voir avec F4map pour qu'il soit utilisé (et proposer le tag ça va de soit). Entrer massivement des données fausses ça s'appelle du vandalisme. Donc un height=une valeur arbitraire, tu oublies. Une carto-partie où tu te sers des données (en les imprimant) et en demandant aux mappeurs d'indiquer : - existe (ou pas) - position correcte (ou pas) - hauteur approximative (un étage = 3 m, on n'a pas besoin de la cinquième décimale) - taxon ou type de feuilles ? Ça devrait permettre d'améliorer les données open source puis de les importer. Comme ça le boulot de Vincent (toi) est utilisé et on suit Vincent (le guide de la Voie Verte ;-)). Maintenant, je dis ça, mais je suis loin (y'a qu'à, faut qu'on). Jean-Yvon ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Importation des arbres municipaux sur Nice
Le 25/07/2015 23:45, osm.sanspourr...@spamgourmet.com a écrit : J'aime assez la proposition de Vincent (celui à qui un reflet d'un petit guide vert permet de faire un clin d’œil - vdct pour ceux qui n'auraient pas compris) ;) = bis ! Il n'est pas le seul à se méfier des imports tueurs, le plus célèbre restant la base de donnée routière américaine Tiger. Excellent pour avoir 80 %... et geler les 20 % restants. Combien de routes en pleine campagne voir en forêt aux États-Unis sont encore taguées route résidentielle ? Et même sans se perdre en forêt, j'ai pu faire le constat en plein New York lors du dernier SOTM US. On pourrait s'attendre là bas à un contenu ultra riche et à jour, et pas du tout. En rentrant, j'ai contribué sur un contenu aussi banal que les stations de velo en libre service : en en ajoutant 8, je me suis retrouvé 1er contributeur sur cette thématique, avec 18% des nodes. Car on en recense que 45 sur NYC dans OSM, contre +400 sur le terrain. Y'a comme un souci. Les 20% gelés sont un peu là. Instructif mais pas forcément pour suivre la même trajectoire par chez nous. J'étais moins radical en proposant des fixme, j'avoue que maintenant je ne sais pas trop que penser (il faut aussi connaître le potentiel OSM du côté de Nice). Devoir ajouter systématiquement un tag fixme est pour moi révélateur de la non adequation d'un contenu avec OSM. Car en pratique, le fixme va rester. Une carto-partie où tu te sers des données (en les imprimant) et en demandant aux mappeurs d'indiquer : - existe (ou pas) - position correcte (ou pas) - hauteur approximative (un étage = 3 m, on n'a pas besoin de la cinquième décimale) - taxon ou type de feuilles ? Ça devrait permettre d'améliorer les données open source puis de les importer. D'accord avec l'idée, y compris la chronologie. L'import serait alors la restitution du relevé terrain. vincent ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Importation des arbres municipaux sur Nice
Bonjour, pour enfoncer encore un peu plus le clou que Vincent a enfonce. Je ne suis pas convaincue sur l'aspect de la precision des donnees present dans les jeux de donnees de type en general. Il me semble d'ailleurs que la plupart du temps ils sont plus fournis a titre indicatif et complemente par des puces implantes dans l'arbre. Grosso modo, ce n'est la que pour donner une indication generale. Pour avoir aider a l'import Corine et avoir vu un import similaire peu de temps a Girona avant le SOTM 10, on s'est retrouve avec une qualite un peu bizarre. Certains d'entre nous avions tente d'etablir la qualite de l'import (globalement bon) mais quand on comparait avec des donnees GPS (en incluant differentes puces), on se rendait compte que la precision etait mediocre (precision de 5 a 10m). N'oublions pas que la quasi totalite des puces GPS dont Smartphone ont au mieux une precision de 5 metres et qu'OpenStreetMap a une precision de 6 decimales (en gros 15cm si je me rappelle bien), on se retrouve avec quelque chose de douteux. Bref, lorsqu'on descendra au centrimetrique en GPS, j'aurais plus confiance. Anecdocte amusante, les feuilles des arbres absorbent la frequence utilisee par les GPS rendant la qualite du GPS bien pire. Je suis plus moderee sur l'aspect negatif d'un import sur la communaute surtout dans le cas d'un import de ce type. Toutefois, je suis convaincue tout comme Vincent de l'importance d'une communaute locale afin d'assurer une maintenance continue de la carte. Dans un de tes precedents emails, tu parlais de l'application potentielle de ce genre de donnees. C'est bien joli mais la premiere chose que je ferrai si j'avais a traiter ce genre de chose c'est surement de separer ces donnees dans une couche a part (voir aussi les arguments de Vincent). Bref, oui pour l'import, mais tes marges me font peur. De plus s'il y a overlap, soit on ne touche pas, soit on deplace le point existant. 2015-07-25 15:08 GMT-07:00 Vincent de Château-Thierry v...@laposte.net: Le 25/07/2015 23:42, Jérôme Seigneuret a écrit : Les deux ne sont pas incompatible. L'import ne donne que la position. Si au moins il la donnait... La précision géographique n'est clairement pas ce qu'il y a de meilleur quand on commence à challenger les jeux de données OpenData. Par principe il est impossible de généraliser sur la qualité, tant il y a de producteurs et de méthodes différents, mais s'il y a bien un point sur lequel il faut douter sur _tous_ les jeux de données, c'est le positionnement, la qualité de la géométrie. Rien n’empêche de faire une campagne de terrain pour définir qu'elle est le type d'arbre et les infos qui suivent. Je suis bien d'accord que faire du terrain en groupe c'est cool. Maintenant, il y a un intérêt certains d'avoir les arbres sur le plan et de pourvoir vérifier avec une version imprimé directement. L'intérêt d'avoir les arbres in fine, je ne le discute pas, c'est un niveau de détail vers lequel on va (tout comme distinguer les trottoirs du filaire de voie, etc.) même si la densité de points en certains endroits (c'est le cas dans Nice) va en intimider plus d'un au moment d'éditer la carte. Après il est sûr que suite à l'intégration laisser un message sur la liste PACA ou celle du 06 serait une bonne chose. Bingo : il n'y a ni liste PACA ni liste 06... Construire une dynamique locale passe je pense plus par la constitution de ce genre d'espace d'échange que par un import. Il y a aussi les Lycée d'aménagements Paysagers qui pourraient être sollicité ou intéressé ainsi que les filières SIG du coin... Par exemple oui. Peut-être qu'un serveur avec une carte bac à sable avec une possibilité d'imprimer offrirait le meilleur compromis pour éviter des coups d'intégration massif (de bonne volonté). Je lis coût ;) Imprimer le jeu de données dans son contexte, avec un fond carto dessous, ne nécessite absolument pas d'avoir procédé à un import. Avec un outil comme QGis (voire JOSM, mais je ne sais pas ce qu'il vaut pour imprimer) c'est très simple de combiner un jeu de données comme les arbres de Nice, et un fond OSM ou autre. Et c'est un bon document de travail pour aller sur place. vincent ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Importation des arbres municipaux sur Nice
Arfff, Je viens de voir qu'il n'y a pas d'information sur la taxonomie dans le fichier. Dommage. ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Importation des arbres municipaux sur Nice
Juste une précision. Comment gères-tu les conflits quand les tags sont remplis ou quand tu détectes un arbre dans le rayon en question? Normalement on ne peut pas considérer une source de données plus fiable qu'une autre car les erreurs humaines existent. Pour la partie attributaire je viens de voir ce qui est fait coté Bordeaux et l'utilisation du tag *taxon *n'est pas bonne. Le 25 juillet 2015 19:27, Vincent Frison vincent.fri...@gmail.com a écrit : Le 25 juillet 2015 18:53, Vincent Pottier vpott...@gmail.com a écrit : Si le programme, qui détecte la présence d'un arbre à 2 m, pouvait modifier le point existant plutôt que de le remplacer, ce serait top. Merci pour ceux qui ont œuvré à OSM. Mais c'est le cas ! J'ai justement changé le programme pour qu'il mette à jour les arbres existants à moins de X mètres au lieu de les supprimer.. ___ 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] Importation des arbres municipaux sur Nice
Bonsoir, 2015-07-25 17:02 GMT-07:00 Jérôme Seigneuret jseigneuret-...@yahoo.fr: Le 26 juillet 2015 00:43, Emilie Laffray emilie.laff...@gmail.com a écrit : Bonjour, pour enfoncer encore un peu plus le clou que Vincent a enfonce. Je ne suis pas convaincue sur l'aspect de la precision des donnees present dans les jeux de donnees de type en general. Il me semble d'ailleurs que la plupart du temps ils sont plus fournis a titre indicatif et complemente par des puces implantes dans l'arbre. Grosso modo, ce n'est la que pour donner une indication generale. J'ai pas compris où tu veux en venir. En quoi le fait d'avoir une puce pose un problème d'intégration et cela entraînerait un jeu de données de mauvaise qualité ? Un jeu de données ça ce test avec un échantillon aléatoire. Question qualité, il n'existe pas de jeu de données avec une fiabilité à 100% à cause de plein de raison. J'ai jamais testé un jeu de données à 100% question coût ;-) Le point que je faisais passer etait que comme la précision des données concernant les arbres étaient tellement faible, on marque l'arbre avec une puce individuelle, ce qui permet de travailler avec l'arbre que l'on veut sans avoir une localisation precise. Pour avoir aider a l'import Corine et avoir vu un import similaire peu de temps a Girona avant le SOTM 10, on s'est retrouve avec une qualite un peu bizarre. Certains d'entre nous avions tente d'etablir la qualite de l'import (globalement bon) mais quand on comparait avec des donnees GPS (en incluant differentes puces), on se rendait compte que la precision etait mediocre (precision de 5 a 10m). N'oublions pas que la quasi totalite des puces GPS dont Smartphone ont au mieux une precision de 5 metres et qu'OpenStreetMap a une precision de 6 decimales (en gros 15cm si je me rappelle bien), on se retrouve avec quelque chose de douteux. Bref, lorsqu'on descendra au centrimetrique en GPS, j'aurais plus confiance. Anecdocte amusante, les feuilles des arbres absorbent la frequence utilisee par les GPS rendant la qualite du GPS bien pire. Comparer la CLC à des arbres positionnés le plus souvent sur des ortho du département ou de la ville dont la qualité est quand même pas celle de la CLC... le pixel d'une ortho a une résolution de 20cm maintenant 50cm pour la BD Ortho. Reste le calage... Sans compté qu'il est clair que connaitre le mode de saisie est important. Si c'est la ville je ne pense pas qu'il face ça avec un smartphone mais avec du Trimble et que c'est corrigé en bureau. Tu auras plus de décalage avec le changement de projection qu'avec la levé de terrain... Sinon les données correspondent (en tout cas pour celles des collectivités) à des données de CAO et à des plans de plantations. Moui, enfin, j'ai juste mentionné CLC afin de faire référence au fait que l'import je connais un peu, et le point principal était surtout sur l'import des arbres de la ville de Gerone en Espagne. De plus, si tu veux rentrer dans les détails des puces GPS soit mais je n'ai jamais parle de puce GPS pour Smartphone. Grosso modo, oui, il faut utiliser du GPS différentiel ou du RTK si tu veux de la précision centimétrique, mais je ne suis pas convaincue que la plupart des municipalités s'amusent avec ce genre de matériel en premier lieu. Au final, dans beaucoup de cas, je ne suis pas convaincue que les plans de plantations crées généralement a postériori ou des données de CAO soit vraiment si bon que ça. Bref, on en revient a la source des données au final. Dans un de tes precedents emails, tu parlais de l'application potentielle de ce genre de donnees. C'est bien joli mais la premiere chose que je ferrai si j'avais a traiter ce genre de chose c'est surement de separer ces donnees dans une couche a part (voir aussi les arguments de Vincent). Oui surement comme le bati, le réseau routier ou l'occupation du sol... reste qu'OSM et une base de données et pas un jeu de shapefile OSM est en effet une base de données. Je ne suis pas contre un import de ce type, je suis généralement contre un import dont la qualité peut être douteuse. Enfin dans le cas présent, la précision a quelques mètres d'un arbre n'est pas bien grave dans la plupart des cas (voir carte non voyant) par exemple. Historiquement, je fais partie des membres du bureau de la fondation qui se sont opposes a la création d'un map.openstreetmap.com parce que pour moi OSM est une base de donnée. Je suis parfaitement consciente qu'OSM n'est pas un jeu de shapefile mais si tu regardes bien l'usage qui en fait dans de nombreux milieux, tu vois une décomposition en couche ce qui est relativement naturel dans la manière de travailler des gens. La question se pose alors sur la pertinence d'avoir ce jeu de données dans OSM au lieu d'un shapefile différent, en tenant compte de la qualité des données en premier lieu et de ces implications. Un des gros problèmes actuellement est a mes yeux les éditeurs OSM qui gère mal la densité des
Re: [OSM-talk-fr] Importation des arbres municipaux sur Nice
Le 26 juillet 2015 00:43, Emilie Laffray emilie.laff...@gmail.com a écrit : Bonjour, pour enfoncer encore un peu plus le clou que Vincent a enfonce. Je ne suis pas convaincue sur l'aspect de la precision des donnees present dans les jeux de donnees de type en general. Il me semble d'ailleurs que la plupart du temps ils sont plus fournis a titre indicatif et complemente par des puces implantes dans l'arbre. Grosso modo, ce n'est la que pour donner une indication generale. J'ai pas compris où tu veux en venir. En quoi le fait d'avoir une puce pose un problème d'intégration et cela entraînerait un jeu de données de mauvaise qualité ? Un jeu de données ça ce test avec un échantillon aléatoire. Question qualité, il n'existe pas de jeu de données avec une fiabilité à 100% à cause de plein de raison. J'ai jamais testé un jeu de données à 100% question coût ;-) Pour avoir aider a l'import Corine et avoir vu un import similaire peu de temps a Girona avant le SOTM 10, on s'est retrouve avec une qualite un peu bizarre. Certains d'entre nous avions tente d'etablir la qualite de l'import (globalement bon) mais quand on comparait avec des donnees GPS (en incluant differentes puces), on se rendait compte que la precision etait mediocre (precision de 5 a 10m). N'oublions pas que la quasi totalite des puces GPS dont Smartphone ont au mieux une precision de 5 metres et qu'OpenStreetMap a une precision de 6 decimales (en gros 15cm si je me rappelle bien), on se retrouve avec quelque chose de douteux. Bref, lorsqu'on descendra au centrimetrique en GPS, j'aurais plus confiance. Anecdocte amusante, les feuilles des arbres absorbent la frequence utilisee par les GPS rendant la qualite du GPS bien pire. Comparer la CLC à des arbres positionnés le plus souvent sur des ortho du département ou de la ville dont la qualité est quand même pas celle de la CLC... le pixel d'une ortho a une résolution de 20cm maintenant 50cm pour la BD Ortho. Reste le calage... Sans compté qu'il est clair que connaitre le mode de saisie est important. Si c'est la ville je ne pense pas qu'il face ça avec un smartphone mais avec du Trimble et que c'est corrigé en bureau. Tu auras plus de décalage avec le changement de projection qu'avec la levé de terrain... Sinon les données correspondent (en tout cas pour celles des collectivités) à des données de CAO et à des plans de plantations. Je suis plus moderee sur l'aspect negatif d'un import sur la communaute surtout dans le cas d'un import de ce type. Toutefois, je suis convaincue tout comme Vincent de l'importance d'une communaute locale afin d'assurer une maintenance continue de la carte. Je suis aussi de cet avis. En même temps, il y a des gens qui font ça en vacance (cas vu chez nous d'un jeune qui préfère ça à sa playstation) Dans un de tes precedents emails, tu parlais de l'application potentielle de ce genre de donnees. C'est bien joli mais la premiere chose que je ferrai si j'avais a traiter ce genre de chose c'est surement de separer ces donnees dans une couche a part (voir aussi les arguments de Vincent). Oui surement comme le bati, le réseau routier ou l'occupation du sol... reste qu'OSM et une base de données et pas un jeu de shapefile Bref, oui pour l'import, mais tes marges me font peur. De plus s'il y a overlap, soit on ne touche pas, soit on deplace le point existant. En effet. C'est pour cela que je lui ai posé la question de savoir ce qu'il ferait en cas de conflit. Là c'est le terrain qui doit permettre de faire un choix en cas de conflit ou un fond de plan bien calé pour le positionnement ou des données GPS de qualité pro. C'est le même principe pour le reste des éléments comme le nom des voies en cas de conflits entre différentes sources ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Importation des arbres municipaux sur Nice
Sans vouloir trop m'avancer, je pense que Christian demandait : « Qui va s'occuper de l'entretien des données arbres à Nice ? ». C'est beau (ou pas) de les importer, mais quid de leur évolution dans 2, 5, 15 ans ? Est-ce que les mappeurs locaux sont ok pour s'en charger ? Est-ce que tu es prêt à t'en charger ? Les batiments, le consensus semble être que ça bouge suffisamment peu pour être modifié au cas par cas. Qu'en est-il des arbres, surtout quand le travail à la main devient laborieux ? JB. Le 24/07/2015 12:03, Vincent Frison a écrit : Alors les données ont l'air d'être bien entretenues puisqu'ils viennent justement de mettre à jour leur export 2015 qui contient environ 600 arbres supplémentaires par rapport à celui de 2014. On peut donc espérer qu'ils continuent à le mettre à jour de temps en temps (j'attends leur réponse à ce sujet ainsi que sur leur taux de couverture globale). ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Importation des arbres municipaux sur Nice
Le 24 juillet 2015 14:44, JB jb...@mailoo.org a écrit : Sans vouloir trop m'avancer, je pense que Christian demandait : « Qui va s'occuper de l'entretien des données arbres à Nice ? ». C'est beau (ou pas) de les importer, mais quid de leur évolution dans 2, 5, 15 ans ? Est-ce que les mappeurs locaux sont ok pour s'en charger ? Est-ce que tu es prêt à t'en charger ? Oui je suis ok pour m'en occuper (j'habite la région pour info), y compris dans 15 ans si je suis toujours vivant... ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Importation des arbres municipaux sur Nice
Ben c'est plutôt pas mal tous ça. En tous cas ça confirme ce que je pense. J'ai le cas des parkings de l'Odyseum sur Montpellier. En effet ça fait beaucoup d'arbres ;-) Le 24 juillet 2015 12:03, Vincent Frison vincent.fri...@gmail.com a écrit : Alors les données ont l'air d'être bien entretenues puisqu'ils viennent justement de mettre à jour leur export 2015 qui contient environ 600 arbres supplémentaires par rapport à celui de 2014. On peut donc espérer qu'ils continuent à le mettre à jour de temps en temps (j'attends leur réponse à ce sujet ainsi que sur leur taux de couverture globale). La précision a l'air bonne tout du moins sur les zones que j'ai regardé en détail. Pour moi le seul vrai souci c'est que leur fichier n'indique que la position de l'arbre, on a donc pas le type de l'arbre ni sa hauteur ce qui est bien dommage (certains villes comme Lyon je crois fournissent ces infos, il y a même la circonférence). Cela n'est pas gênant sur une carte classique en 2D mais c'est un peu plus déroutant avec un carte 3D puisque les moteurs ne peuvent pas faire un rendu différent entre un arbre de 2 mètre et un de 20 mètres, ils sont tous affichés avec la même hauteur (celle par défaut). En même temps c'est pas comme si j'étais en train d'importer des informations fausses, elle sont juste incomplètes (tout comme pour 98% des arbres existants). De ce que j'ai vu il n'y a que 4/5 utilisateurs différents qui ont rajouté des arbres sur Nice, notamment un qui en fait beaucoup sur la Promenade des Anglais en prenant soin de rajouter le type=palm. Je vais le contacter pour voir avec lui si on peut trouver une solution pour ne pas gêner le rendu actuel. En gros il a déjà ajouté des arbres correspondants à la plupart des grands palmiers. Mon import va les conserver (éventuellement en les déplaçant légèrement) mais il va rajouter pas mal d'éléments correspondant à des arbres de petites tailles (2/3 mètres) situés autour de ces grands palmiers. Mais comme il n'y aura pas de tag hauteur=* ils seront affichés comme des grands arbres, ça va pas faire joli, ni réaliste. Peut-être qu'une petite requête rajoutant un tag hauteur de 2/3 mètres sur l'ensemble des arbres de la Prom' qui n'ont pas le type palmier seraient souhaitable... Sinon 2 mètres pour le rayon de conflation c'était effectivement un peu court, à 3 mètre je pense qu'on est pas mal : Total of makable imports: 30521 Total of created trees: 29819 Total of updated trees: 702 Total of created or updated trees: 30521 Total of multi matching trees: 107 Pour revenir à la discussion sur les 1188 arbres existants (visibles via Overpass) ça me parait finalement assez cohérent: 700 sont donc mis à jour et les 480 manquant sont tout simplement des arbres non référencés, car généralement non municipaux. Par ex. rien que sur l’aéroport de Nice il y a près de 200 arbres existants qui ne sont pas référencés ! Après j'avoue avoir du mal à adhérer au principe consistant à ne pas rajouter trop de données dans OSM car ça risquerait de trop complexifier la maintenance. En plus dans la cadre concret des arbres ça doit pas arriver bien souvent, la tendance c'est plutôt d'en rajouter pas d'en enlever ! ;p Sauf dans le cas de construction de nouveaux bâtiments ou de nouvelles routes par exemple, mais bon dans ce cas là je ne vois pas ce qu'il y aurait de si compliqué à supprimer tous les arbres sur une zone précise (le fait que les arbres soient très proches les uns des autres n'est en rien gênant). Après sur une grande zone remplie d'arbres (bois / forêt) il vaut é videmment mieux utiliser par exemple le tag landuse=forest mais là sur des petits squares ou petits parcs en pleine ville je vois pas le problème de rajouter quelques dizaines d'éléments arbres, bien au contraire... Le 23 juillet 2015 16:05, Jérôme Seigneuret jseigneuret-...@yahoo.fr a écrit : Oui si l'Open Data existe sauf que sur Montpellier c'est l'inverse qui se passe. C'est les données contenues dans OSM qui sont proposées (avec la licence OSM) sur le portail de Montpellier. Voilà pourquoi je produis ces données en fonction du terrain que j'effectue et que j'intègre directement dans OSM. La même pour ajouter l'éclairage public (en parallèle). Pour le placement je le corrige avec Bing quand c'est possible. Pour l'alignement avec JOSM, un petit coup de Maj+B et hop! C'est plus propre que la levé GPS dans certains cas. On n'est pas nombreux ici à le faire mais bon. Il suffit d'aller faire une requête Overpass pour se rendre compte des ajouts. J'ai déjà fais pas mal de chose. Nice à un SIG puissant d'ailleurs le gars qui s'occupait du SIG est maintenant chez ESRI et s'occupe de programme Arcopole. Je pense que le SIG est bien plus puissant (équipe, données, logiciel...) qu'ici. Pour la question d suivi et de maintenant il y a des ref en principe. Si tel est le cas il est facile de voir celle qui n'en ont pas de celle qui ont été importé.
Re: [OSM-talk-fr] Importation des arbres municipaux sur Nice
Le problème des arbres est similaire à celui du bâti. On dézingue pas des arbres régulièrement (en tout cas en ville)... Il y a qu'a voir les platanes. Sauf maladie, tempête, risque pour la sécurité des usagers, il n'y a pas de raison. Si la croissance est importante et que les arbres sont plantés trop proche pour les premières années (histoire de faire joli), il y a un arbre sur deux qui saute (au bout de dix ans en principe). D'ici là on a le temps de voir les choses changer. Le 24 juillet 2015 14:53, Vincent Frison vincent.fri...@gmail.com a écrit : Le 24 juillet 2015 14:44, JB jb...@mailoo.org a écrit : Sans vouloir trop m'avancer, je pense que Christian demandait : « Qui va s'occuper de l'entretien des données arbres à Nice ? ». C'est beau (ou pas) de les importer, mais quid de leur évolution dans 2, 5, 15 ans ? Est-ce que les mappeurs locaux sont ok pour s'en charger ? Est-ce que tu es prêt à t'en charger ? Oui je suis ok pour m'en occuper (j'habite la région pour info), y compris dans 15 ans si je suis toujours vivant... ___ 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] Importation des arbres municipaux sur Nice
Certains imports sont à bien peser... @Jérôme: ces données ont un intérêt, certes, mais leur disponibilité en opendata permet déjà tout les usages que tu as listé. La question de l'entretien et de la mise à jour des données est celle qu'il faut à mon avis se poser après celle de la qualité des données qu'on envisage d'importer. Qualité: qui a vérifié avec un échantillonnage sur le terrain qu'elles étaient précises et à jour ? Quelle espoir de les voir mises à jour par le producteur et quid de l'intégration de ces mises à jour ? Entretien: qu'en disent les contributeurs locaux ? Ce sont eux qui vont en priorité pouvoir entretenir des données aussi détaillées. Le 23/07/2015 00:37, JB a écrit : Le 22/07/2015 16:36, Jérôme Seigneuret a écrit : Après, je me pose la question de l'intérêt d'importer une zone comme ça, avec des arbres espacés de moins de 1m : http://hpics.li/85d8ec5. Il y en a plusieurs. Tu aurais des statistiques de distances ? Moi et QGis, on essaye de s'aimer, mais c'est pas toujours facile. À part compliquer la contribution, foirer le rendu, rendre impossible toute correction humaine ultérieure Je vois pas comment les corrections ne serait pas faisable... L'import a un intérêt pour la gestion des arbres. Les arbres plantés en touffe à moins d'un mètre c'est une réalité du terrain aussi... Oui, certes. Mais si tu mets 5 minutes à trouver dans les données quel arbre a été abattu, parce qu'il y en a 52 dans la zone, que le gps n'est pas assez précis, qu'il faut compter à partir de la bordure nord-est, mais qu'ils sont pas alignés, du coup ça marche pas. Chaque pavé d'une rue, c'est une réalité. Chaque arbre des forêts aussi. Pourtant, c'était une blague à la mode il y a pas si longtemps. Il y a d'autres façons de cartographier pour ça : landuse, landcover. Pour une commune l'intérêt est de gérer les plantations. Il me semble qu'avec l'age on peut aussi déterminer des arbres remarquables. Quand à la hauteur c'est plus dur à déterminer et à maintenir dans le temps. Sauf mettre la date de la prise de la hauteur car elle évolue dans le temps. Oui, ils ont même parfois un SIG pour gérer ça. Mais c'est pas un argument pour rentrer toutes les données dans OSM. Ca a aussi un intérêt environnemental: - étude des pollens - accueille de la faune Un intérêt patrimonial, paysager, ... On pourrait aussi gérer l'état de santé même si rien n'existe pour le moment dans OSM mais là on est plus dans la gestion. Peut être avec des ref=* pour gérer l'abattage d’arbres dangereux et l'élagage ajouter un facteur de croissance automatique par espèce pour déterminer un planning prévisionnel d'entretien. Bref les possibilités sont grandes même si certains n'en trouve pas l'intérêt. Bof, change le mot « intérêt » en « inconvénients dépassent les avantages ». ___ 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] Importation des arbres municipaux sur Nice
Oui si l'Open Data existe sauf que sur Montpellier c'est l'inverse qui se passe. C'est les données contenues dans OSM qui sont proposées (avec la licence OSM) sur le portail de Montpellier. Voilà pourquoi je produis ces données en fonction du terrain que j'effectue et que j'intègre directement dans OSM. La même pour ajouter l'éclairage public (en parallèle). Pour le placement je le corrige avec Bing quand c'est possible. Pour l'alignement avec JOSM, un petit coup de Maj+B et hop! C'est plus propre que la levé GPS dans certains cas. On n'est pas nombreux ici à le faire mais bon. Il suffit d'aller faire une requête Overpass pour se rendre compte des ajouts. J'ai déjà fais pas mal de chose. Nice à un SIG puissant d'ailleurs le gars qui s'occupait du SIG est maintenant chez ESRI et s'occupe de programme Arcopole. Je pense que le SIG est bien plus puissant (équipe, données, logiciel...) qu'ici. Pour la question d suivi et de maintenant il y a des ref en principe. Si tel est le cas il est facile de voir celle qui n'en ont pas de celle qui ont été importé. Si ces données ne sont pas dans le SI de Nice il faut vérifier si c'est pas en partie privé ou si c'est un manque et donc proposer un intégration dans le SI de Nice. La question de la mise à jour est valable pour toutes les données. Dixit Bâtiment détruit suite à un programme immobilier. Ajout de zone cyclable, modification des passage piétions avec conformité handicape. Zones de travaux? Le problème de certains tag ou de certaines données c'est la durée de vie. A partir de quand doit-on revérifier les données et considère-t-on qu'elles sont obsolètes. Il est certains que quand ce sont les opérateurs eux-même qui s'occupent de l'intégration et du suivi des données, on peut s'attendre à ce qu'ils maintiennent correctement les informations. Ici, j'ai l'impression qu'on a surtout de la contribution perso ou associative. Peut-être qu'une implication de la Métropole permettrait d'avoir une dynamique plus intéressante du fait qu'elle touche la globalité du territoire. Le 23 juillet 2015 14:13, Christian Quest cqu...@openstreetmap.fr a écrit : Certains imports sont à bien peser... @Jérôme: ces données ont un intérêt, certes, mais leur disponibilité en opendata permet déjà tout les usages que tu as listé. La question de l'entretien et de la mise à jour des données est celle qu'il faut à mon avis se poser après celle de la qualité des données qu'on envisage d'importer. Qualité: qui a vérifié avec un échantillonnage sur le terrain qu'elles étaient précises et à jour ? Quelle espoir de les voir mises à jour par le producteur et quid de l'intégration de ces mises à jour ? Entretien: qu'en disent les contributeurs locaux ? Ce sont eux qui vont en priorité pouvoir entretenir des données aussi détaillées. Le 23/07/2015 00:37, JB a écrit : Le 22/07/2015 16:36, Jérôme Seigneuret a écrit : Après, je me pose la question de l'intérêt d'importer une zone comme ça, avec des arbres espacés de moins de 1m : http://hpics.li/85d8ec5. Il y en a plusieurs. Tu aurais des statistiques de distances ? Moi et QGis, on essaye de s'aimer, mais c'est pas toujours facile. À part compliquer la contribution, foirer le rendu, rendre impossible toute correction humaine ultérieure Je vois pas comment les corrections ne serait pas faisable... L'import a un intérêt pour la gestion des arbres. Les arbres plantés en touffe à moins d'un mètre c'est une réalité du terrain aussi... Oui, certes. Mais si tu mets 5 minutes à trouver dans les données quel arbre a été abattu, parce qu'il y en a 52 dans la zone, que le gps n'est pas assez précis, qu'il faut compter à partir de la bordure nord-est, mais qu'ils sont pas alignés, du coup ça marche pas. Chaque pavé d'une rue, c'est une réalité. Chaque arbre des forêts aussi. Pourtant, c'était une blague à la mode il y a pas si longtemps. Il y a d'autres façons de cartographier pour ça : landuse, landcover. Pour une commune l'intérêt est de gérer les plantations. Il me semble qu'avec l'age on peut aussi déterminer des arbres remarquables. Quand à la hauteur c'est plus dur à déterminer et à maintenir dans le temps. Sauf mettre la date de la prise de la hauteur car elle évolue dans le temps. Oui, ils ont même parfois un SIG pour gérer ça. Mais c'est pas un argument pour rentrer toutes les données dans OSM. Ca a aussi un intérêt environnemental: - étude des pollens - accueille de la faune Un intérêt patrimonial, paysager, ... On pourrait aussi gérer l'état de santé même si rien n'existe pour le moment dans OSM mais là on est plus dans la gestion. Peut être avec des ref=* pour gérer l'abattage d’arbres dangereux et l'élagage ajouter un facteur de croissance automatique par espèce pour déterminer un planning prévisionnel d'entretien. Bref les possibilités sont grandes même si certains n'en trouve pas l'intérêt. Bof, change le mot « intérêt » en « inconvénients dépassent les avantages
Re: [OSM-talk-fr] Importation des arbres municipaux sur Nice
Après un regard d'un peu plus près, les emplacements semblent correspondre assez bien avec l'imagerie, j'ai vu des écarts jusqu'à 5m, mais globalement bien en dessous. Après, je me pose la question de l'intérêt d'importer une zone comme ça, avec des arbres espacés de moins de 1m : http://hpics.li/85d8ec5. Il y en a plusieurs. Tu aurais des statistiques de distances ? Moi et QGis, on essaye de s'aimer, mais c'est pas toujours facile. À part compliquer la contribution, foirer le rendu, rendre impossible toute correction humaine ultérieure, montrer qu'on sait bien importer, j'ai du mal à voir à quoi ça sert… Pour moi, si on perd le coté humain de la base de données (comprenez, un humain peut modifier les données), on a tout perdu. JB. Le 22/07/2015 00:43, Vincent Frison a écrit : Le 21 juillet 2015 22:00, Vincent Frison vincent.fri...@gmail.com mailto:vincent.fri...@gmail.com a écrit : Je ferai aussi quelques tests en variant le rayon, je vous tiendrai au courant des résultats... Avec un rayon de 2 mètres : Total of created trees: 29947 Total of updated trees: 574 Total of multi matching trees: 28 Avec un rayon de 5 mètres : Total of created trees: 29767 Total of updated trees: 754 Total of multi matching trees: 281 Maintenant je met à jour les éléments existants au lieu de les effacer. La mise à jour consiste à mettre la même position (la même que l'arbre importé) et de rajouter un tag ref:FR:Nice:trees=* avec l'identifiant de leur jeu de données. Par contre la gestion des multi matching trees (ie. les arbres existant qui matchent plus qu'un seul arbre importé) est très basique puisque je met à jour l'élément avec les valeurs du 1er arbre importé tout simplement (pour les autres éléments importés je créé donc un nouvel élément). Mais bon, avec un rayon de 2 mètres ça ne concerne moins d'1/1000e des arbres.. et surtout je rappelle qu'en plus on parle de décalages inférieurs à 2 mètres donc bon je pense que c'est tolérable. Et du coup je pense qu'il faut garder un rayon faible comme 2 mètres. Au niveau des 1188 arbres visibles sur Overpass il faut voir que: - certains arbres municipaux ne sont pas référencés - certains arbres existants ne sont pas des arbres municipaux - certains arbres existants peuvent être municipaux (et référencés) mais éventuellement trop mal positionnés (et dans ce cas là je pourrai pas faire grand chose) Mais effectivement je vais devoir creuser un peu pour mieux comprendre ;) ___ 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] Importation des arbres municipaux sur Nice
Le 22/07/2015 16:36, Jérôme Seigneuret a écrit : Après, je me pose la question de l'intérêt d'importer une zone comme ça, avec des arbres espacés de moins de 1m : http://hpics.li/85d8ec5. Il y en a plusieurs. Tu aurais des statistiques de distances ? Moi et QGis, on essaye de s'aimer, mais c'est pas toujours facile. À part compliquer la contribution, foirer le rendu, rendre impossible toute correction humaine ultérieure Je vois pas comment les corrections ne serait pas faisable... L'import a un intérêt pour la gestion des arbres. Les arbres plantés en touffe à moins d'un mètre c'est une réalité du terrain aussi... Oui, certes. Mais si tu mets 5 minutes à trouver dans les données quel arbre a été abattu, parce qu'il y en a 52 dans la zone, que le gps n'est pas assez précis, qu'il faut compter à partir de la bordure nord-est, mais qu'ils sont pas alignés, du coup ça marche pas. Chaque pavé d'une rue, c'est une réalité. Chaque arbre des forêts aussi. Pourtant, c'était une blague à la mode il y a pas si longtemps. Il y a d'autres façons de cartographier pour ça : landuse, landcover. Pour une commune l'intérêt est de gérer les plantations. Il me semble qu'avec l'age on peut aussi déterminer des arbres remarquables. Quand à la hauteur c'est plus dur à déterminer et à maintenir dans le temps. Sauf mettre la date de la prise de la hauteur car elle évolue dans le temps. Oui, ils ont même parfois un SIG pour gérer ça. Mais c'est pas un argument pour rentrer toutes les données dans OSM. Ca a aussi un intérêt environnemental: - étude des pollens - accueille de la faune Un intérêt patrimonial, paysager, ... On pourrait aussi gérer l'état de santé même si rien n'existe pour le moment dans OSM mais là on est plus dans la gestion. Peut être avec des ref=* pour gérer l'abattage d’arbres dangereux et l'élagage ajouter un facteur de croissance automatique par espèce pour déterminer un planning prévisionnel d'entretien. Bref les possibilités sont grandes même si certains n'en trouve pas l'intérêt. Bof, change le mot « intérêt » en « inconvénients dépassent les avantages ». ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Importation des arbres municipaux sur Nice
Après, je me pose la question de l'intérêt d'importer une zone comme ça, avec des arbres espacés de moins de 1m : http://hpics.li/85d8ec5. Il y en a plusieurs. Tu aurais des statistiques de distances ? Moi et QGis, on essaye de s'aimer, mais c'est pas toujours facile. À part compliquer la contribution, foirer le rendu, rendre impossible toute correction humaine ultérieure Je vois pas comment les corrections ne serait pas faisable... L'import a un intérêt pour la gestion des arbres. Les arbres plantés en touffe à moins d'un mètre c'est une réalité du terrain aussi... Pour une commune l'intérêt est de gérer les plantations. Il me semble qu'avec l'age on peut aussi déterminer des arbres remarquables. Quand à la hauteur c'est plus dur à déterminer et à maintenir dans le temps. Sauf mettre la date de la prise de la hauteur car elle évolue dans le temps. Ca a aussi un intérêt environnemental: - étude des pollens - accueille de la faune Un intérêt patrimonial, paysager, ... On pourrait aussi gérer l'état de santé même si rien n'existe pour le moment dans OSM mais là on est plus dans la gestion. Peut être avec des ref=* pour gérer l'abattage d’arbres dangereux et l'élagage ajouter un facteur de croissance automatique par espèce pour déterminer un planning prévisionnel d'entretien. Bref les possibilités sont grandes même si certains n'en trouve pas l'intérêt. ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Importation des arbres municipaux sur Nice
2m ça me parait bien peu pour une conflation efficace. Les espèces et autre ont plein de tags prévus pour: genus / species/ taxon, voir http://wiki.openstreetmap.org/wiki/Key:species +1 aussi pour compléter les objets existants plutôt que de les supprimer pour les remplacer. Le 21/07/2015 14:41, Jérôme Seigneuret a écrit : Perso je m'occupe d'intégrer les arbres de Montpellier + éclairage (campagne terrain plus Bing pour le placement) Les palmiers c'est du feuillu persistant. Il n'y a plus de distinction. Je laisse type=palm uniquement pour les palmiers... Sinon leaf_type=* et leaf_cycle sur chaque arbre et c'est ok Pour le nom complet latin j'utilise taxon=* et pas plus quand j'aurais mis tous les arbres j'ajouterai le reste par requête (Overpass) Penses à tester tout de même les zones contenant déjà un couvert végétal dans OSM pour éviter les doublons et de supprimer le tout. Après je mettrais plutôt 5 à 7m pour le rayons. Faire plusieurs tests en variant d'un mètre pour vérifier le rayons le plus probant. Le 21 juillet 2015 14:37, JB jb...@mailoo.org mailto:jb...@mailoo.org a écrit : Salut, Quelques remarques : - Overpass trouve 1188 arbres dans Nice : soit il en manque dans le fichier de l'agglo, soit 2m, c'est pas assez. Soit le fichier de l'agglo n'est pas assez bon, soit ce qui est dans OSM n'est pas assez bon. Problèmatique de tenter d'importer avant d'en savoir plus. - Pas vraiment d'accord pour supprimer l'existant pour y mettre la donnée de « référence » à la place. Le but est d'éviter d'arriver à la situation US vue d'ici (difficile de savoir ce qu'il en est réellement sans être sur place) ou l'essentiel de la donnée est issue d'import avec peu de vie communautaire locale. Et d'éviter la frustration des mappeurs locaux. - Es-tu inscrit à la liste de discussion import ? JB. Le 21/07/2015 14:05, Vincent Frison a écrit : Hello Je compte importer dans OSM l'ensemble des arbres municipaux de Nice, merci au portail OpenData de l'agglomération de Côte d'Azur. Ici c'est du vrai open data, je ne devrais donc pas avoir la même frustration qu'avec l'import des immeubles de PSS ;) Ils viennent de mettre à jour leur fichier qui contient maintenant plus de 30 000 arbres : http://opendata.nicecotedazur.org/data/dataset?q=arbres En plus de créer les nouveaux arbres mon programme vérifie également la présence d'arbres existants afin de les effacer. Actuellement j'ai mis un rayon de 2 mètres donc pour chaque arbre importé, je regarde les arbres existants qui sont à moins de 2 mètres. Pour l'instant je n'efface que l'arbre plus proche de l'arbre importé (je pourrais également supprimer tous les arbres qui sont à moins de x mètres mais en fait ça ne change pas grand chose car s'il y a plusieurs arbres existants qui sont très proches à priori il y aura également plusieurs arbres importés qui seront très proches donc au final même en ne supprimant que l'arbre existant le plus proche tous les arbres existants seront bien effacés, ce que j'ai pu vérifier par mes tests). Concrètement sur les ~30 000 arbres importés il y a ~540 arbres existants à supprimer. Ce qui est dommage c'est que le fichier n'indique pas le type des arbres et c'est d'autant plus dommage que les arbres existants ont parfois un tag type=*. Par ex. les arbres existants le long de la Promenade des Anglais sont marqué comme palmier (type=palm). Malheureusement je serai obligé de remettre le type à la main une fois l'import exécuté. Mon programme pourrait éventuellement récupérer le type des arbres existants mais bon ça ne marcherait que sur une toute petite partie des arbres importés... D'ailleurs j'ai un peu de mal à comprendre la bonne manière d'indiquer le type car sur la page Wiki du tag natural=tree (http://wiki.openstreetmap.org/wiki/Tag:natural%3Dtree) il est marqué que le tag type=* est obsolète et qu'il faut plutôt utilisé le tag leaf_type=*. Sauf que ce dernier n'est censé prendre que les valeurs suivantes : broadleaved / needleleaved / mixed / leafless. De plus sous JSOM si on met type=palm ça affiche bien l'arbre avec une image de palmier mais ça ne le fait pas si j'essaye avec genus|species=palm|palmtree. Bref c'est pas très clair... Voila si vous avez des conseils ou suggestions n'hésitez surtout pas.. ++ Vincent. ___ 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
Re: [OSM-talk-fr] Importation des arbres municipaux sur Nice
Effectivement je vais plutôt modifier les éléments existants plutôt que de les supprimer, c'est une meilleure manière de procéder, en tout cas moins agressive. Je ferai aussi quelques tests en variant le rayon, je vous tiendrai au courant des résultats... ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Importation des arbres municipaux sur Nice
Bonjour Je ne connais rien aux arbres dans osm ni à la qualité des données de Nice mais je sais que la localisation des toilettes publiques et des grands dessins type BD à Bruxelles fournis par la ville sur son portail opendata officiel est tellement mauvaise que nous avons renoncé à osm-be à l'importation automatique. En résumé : à mon avis souvent les données Gis officielles doivent etre vérifiées sur le terrain une à une. C'est dommage mais c'est la réalité Nicolas À mar. juil. 21 08:37:18 2015 GMT-0400, JB a écrit : Salut, Quelques remarques : - Overpass trouve 1188 arbres dans Nice : soit il en manque dans le fichier de l'agglo, soit 2m, c'est pas assez. Soit le fichier de l'agglo n'est pas assez bon, soit ce qui est dans OSM n'est pas assez bon. Problèmatique de tenter d'importer avant d'en savoir plus. - Pas vraiment d'accord pour supprimer l'existant pour y mettre la donnée de « référence » à la place. Le but est d'éviter d'arriver à la situation US vue d'ici (difficile de savoir ce qu'il en est réellement sans être sur place) ou l'essentiel de la donnée est issue d'import avec peu de vie communautaire locale. Et d'éviter la frustration des mappeurs locaux. - Es-tu inscrit à la liste de discussion import ? JB. Le 21/07/2015 14:05, Vincent Frison a écrit : Hello Je compte importer dans OSM l'ensemble des arbres municipaux de Nice, merci au portail OpenData de l'agglomération de Côte d'Azur. Ici c'est du vrai open data, je ne devrais donc pas avoir la même frustration qu'avec l'import des immeubles de PSS ;) Ils viennent de mettre à jour leur fichier qui contient maintenant plus de 30 000 arbres : http://opendata.nicecotedazur.org/data/dataset?q=arbres En plus de créer les nouveaux arbres mon programme vérifie également la présence d'arbres existants afin de les effacer. Actuellement j'ai mis un rayon de 2 mètres donc pour chaque arbre importé, je regarde les arbres existants qui sont à moins de 2 mètres. Pour l'instant je n'efface que l'arbre plus proche de l'arbre importé (je pourrais également supprimer tous les arbres qui sont à moins de x mètres mais en fait ça ne change pas grand chose car s'il y a plusieurs arbres existants qui sont très proches à priori il y aura également plusieurs arbres importés qui seront très proches donc au final même en ne supprimant que l'arbre existant le plus proche tous les arbres existants seront bien effacés, ce que j'ai pu vérifier par mes tests). Concrètement sur les ~30 000 arbres importés il y a ~540 arbres existants à supprimer. Ce qui est dommage c'est que le fichier n'indique pas le type des arbres et c'est d'autant plus dommage que les arbres existants ont parfois un tag type=*. Par ex. les arbres existants le long de la Promenade des Anglais sont marqué comme palmier (type=palm). Malheureusement je serai obligé de remettre le type à la main une fois l'import exécuté. Mon programme pourrait éventuellement récupérer le type des arbres existants mais bon ça ne marcherait que sur une toute petite partie des arbres importés... D'ailleurs j'ai un peu de mal à comprendre la bonne manière d'indiquer le type car sur la page Wiki du tag natural=tree (http://wiki.openstreetmap.org/wiki/Tag:natural%3Dtree) il est marqué que le tag type=* est obsolète et qu'il faut plutôt utilisé le tag leaf_type=*. Sauf que ce dernier n'est censé prendre que les valeurs suivantes : broadleaved / needleleaved / mixed / leafless. De plus sous JSOM si on met type=palm ça affiche bien l'arbre avec une image de palmier mais ça ne le fait pas si j'essaye avec genus|species=palm|palmtree. Bref c'est pas très clair... Voila si vous avez des conseils ou suggestions n'hésitez surtout pas.. ++ Vincent. ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr -- Envoyé depuis mon Jolla ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Importation des arbres municipaux sur Nice
Le 21 juillet 2015 22:00, Vincent Frison vincent.fri...@gmail.com a écrit : Je ferai aussi quelques tests en variant le rayon, je vous tiendrai au courant des résultats... Avec un rayon de 2 mètres : Total of created trees: 29947 Total of updated trees: 574 Total of multi matching trees: 28 Avec un rayon de 5 mètres : Total of created trees: 29767 Total of updated trees: 754 Total of multi matching trees: 281 Maintenant je met à jour les éléments existants au lieu de les effacer. La mise à jour consiste à mettre la même position (la même que l'arbre importé) et de rajouter un tag ref:FR:Nice:trees=* avec l'identifiant de leur jeu de données. Par contre la gestion des multi matching trees (ie. les arbres existant qui matchent plus qu'un seul arbre importé) est très basique puisque je met à jour l'élément avec les valeurs du 1er arbre importé tout simplement (pour les autres éléments importés je créé donc un nouvel élément). Mais bon, avec un rayon de 2 mètres ça ne concerne moins d'1/1000e des arbres.. et surtout je rappelle qu'en plus on parle de décalages inférieurs à 2 mètres donc bon je pense que c'est tolérable. Et du coup je pense qu'il faut garder un rayon faible comme 2 mètres. Au niveau des 1188 arbres visibles sur Overpass il faut voir que: - certains arbres municipaux ne sont pas référencés - certains arbres existants ne sont pas des arbres municipaux - certains arbres existants peuvent être municipaux (et référencés) mais éventuellement trop mal positionnés (et dans ce cas là je pourrai pas faire grand chose) Mais effectivement je vais devoir creuser un peu pour mieux comprendre ;) ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
[OSM-talk-fr] Importation des arbres municipaux sur Nice
Hello Je compte importer dans OSM l'ensemble des arbres municipaux de Nice, merci au portail OpenData de l'agglomération de Côte d'Azur. Ici c'est du vrai open data, je ne devrais donc pas avoir la même frustration qu'avec l'import des immeubles de PSS ;) Ils viennent de mettre à jour leur fichier qui contient maintenant plus de 30 000 arbres : http://opendata.nicecotedazur.org/data/dataset?q=arbres En plus de créer les nouveaux arbres mon programme vérifie également la présence d'arbres existants afin de les effacer. Actuellement j'ai mis un rayon de 2 mètres donc pour chaque arbre importé, je regarde les arbres existants qui sont à moins de 2 mètres. Pour l'instant je n'efface que l'arbre plus proche de l'arbre importé (je pourrais également supprimer tous les arbres qui sont à moins de x mètres mais en fait ça ne change pas grand chose car s'il y a plusieurs arbres existants qui sont très proches à priori il y aura également plusieurs arbres importés qui seront très proches donc au final même en ne supprimant que l'arbre existant le plus proche tous les arbres existants seront bien effacés, ce que j'ai pu vérifier par mes tests). Concrètement sur les ~30 000 arbres importés il y a ~540 arbres existants à supprimer. Ce qui est dommage c'est que le fichier n'indique pas le type des arbres et c'est d'autant plus dommage que les arbres existants ont parfois un tag type=*. Par ex. les arbres existants le long de la Promenade des Anglais sont marqué comme palmier (type=palm). Malheureusement je serai obligé de remettre le type à la main une fois l'import exécuté. Mon programme pourrait éventuellement récupérer le type des arbres existants mais bon ça ne marcherait que sur une toute petite partie des arbres importés... D'ailleurs j'ai un peu de mal à comprendre la bonne manière d'indiquer le type car sur la page Wiki du tag natural=tree ( http://wiki.openstreetmap.org/wiki/Tag:natural%3Dtree) il est marqué que le tag type=* est obsolète et qu'il faut plutôt utilisé le tag leaf_type=*. Sauf que ce dernier n'est censé prendre que les valeurs suivantes : broadleaved / needleleaved / mixed / leafless. De plus sous JSOM si on met type=palm ça affiche bien l'arbre avec une image de palmier mais ça ne le fait pas si j'essaye avec genus|species=palm|palmtree. Bref c'est pas très clair... Voila si vous avez des conseils ou suggestions n'hésitez surtout pas.. ++ Vincent. ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Importation des arbres municipaux sur Nice
D'expérience par rapport à Lyon, les implantations d'arbres issus des données ouvertes ne sont pas toujours plus fiables que ce qui a déjà été mis sur OpenStreetMap. Florian Le Mardi 21 juillet 2015 14h16, Vincent Frison vincent.fri...@gmail.com a écrit : Hello Je compte importer dans OSM l'ensemble des arbres municipaux de Nice, merci au portail OpenData de l'agglomération de Côte d'Azur. Ici c'est du vrai open data, je ne devrais donc pas avoir la même frustration qu'avec l'import des immeubles de PSS ;) Ils viennent de mettre à jour leur fichier qui contient maintenant plus de 30 000 arbres : http://opendata.nicecotedazur.org/data/dataset?q=arbres En plus de créer les nouveaux arbres mon programme vérifie également la présence d'arbres existants afin de les effacer. Actuellement j'ai mis un rayon de 2 mètres donc pour chaque arbre importé, je regarde les arbres existants qui sont à moins de 2 mètres. Pour l'instant je n'efface que l'arbre plus proche de l'arbre importé (je pourrais également supprimer tous les arbres qui sont à moins de x mètres mais en fait ça ne change pas grand chose car s'il y a plusieurs arbres existants qui sont très proches à priori il y aura également plusieurs arbres importés qui seront très proches donc au final même en ne supprimant que l'arbre existant le plus proche tous les arbres existants seront bien effacés, ce que j'ai pu vérifier par mes tests). Concrètement sur les ~30 000 arbres importés il y a ~540 arbres existants à supprimer. Ce qui est dommage c'est que le fichier n'indique pas le type des arbres et c'est d'autant plus dommage que les arbres existants ont parfois un tag type=*. Par ex. les arbres existants le long de la Promenade des Anglais sont marqué comme palmier (type=palm). Malheureusement je serai obligé de remettre le type à la main une fois l'import exécuté. Mon programme pourrait éventuellement récupérer le type des arbres existants mais bon ça ne marcherait que sur une toute petite partie des arbres importés... D'ailleurs j'ai un peu de mal à comprendre la bonne manière d'indiquer le type car sur la page Wiki du tag natural=tree (http://wiki.openstreetmap.org/wiki/Tag:natural%3Dtree) il est marqué que le tag type=* est obsolète et qu'il faut plutôt utilisé le tag leaf_type=*. Sauf que ce dernier n'est censé prendre que les valeurs suivantes : broadleaved / needleleaved / mixed / leafless. De plus sous JSOM si on met type=palm ça affiche bien l'arbre avec une image de palmier mais ça ne le fait pas si j'essaye avec genus|species=palm|palmtree. Bref c'est pas très clair... Voila si vous avez des conseils ou suggestions n'hésitez surtout pas.. ++ Vincent. ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Importation des arbres municipaux sur Nice
Salut, Quelques remarques : - Overpass trouve 1188 arbres dans Nice : soit il en manque dans le fichier de l'agglo, soit 2m, c'est pas assez. Soit le fichier de l'agglo n'est pas assez bon, soit ce qui est dans OSM n'est pas assez bon. Problèmatique de tenter d'importer avant d'en savoir plus. - Pas vraiment d'accord pour supprimer l'existant pour y mettre la donnée de « référence » à la place. Le but est d'éviter d'arriver à la situation US vue d'ici (difficile de savoir ce qu'il en est réellement sans être sur place) ou l'essentiel de la donnée est issue d'import avec peu de vie communautaire locale. Et d'éviter la frustration des mappeurs locaux. - Es-tu inscrit à la liste de discussion import ? JB. Le 21/07/2015 14:05, Vincent Frison a écrit : Hello Je compte importer dans OSM l'ensemble des arbres municipaux de Nice, merci au portail OpenData de l'agglomération de Côte d'Azur. Ici c'est du vrai open data, je ne devrais donc pas avoir la même frustration qu'avec l'import des immeubles de PSS ;) Ils viennent de mettre à jour leur fichier qui contient maintenant plus de 30 000 arbres : http://opendata.nicecotedazur.org/data/dataset?q=arbres En plus de créer les nouveaux arbres mon programme vérifie également la présence d'arbres existants afin de les effacer. Actuellement j'ai mis un rayon de 2 mètres donc pour chaque arbre importé, je regarde les arbres existants qui sont à moins de 2 mètres. Pour l'instant je n'efface que l'arbre plus proche de l'arbre importé (je pourrais également supprimer tous les arbres qui sont à moins de x mètres mais en fait ça ne change pas grand chose car s'il y a plusieurs arbres existants qui sont très proches à priori il y aura également plusieurs arbres importés qui seront très proches donc au final même en ne supprimant que l'arbre existant le plus proche tous les arbres existants seront bien effacés, ce que j'ai pu vérifier par mes tests). Concrètement sur les ~30 000 arbres importés il y a ~540 arbres existants à supprimer. Ce qui est dommage c'est que le fichier n'indique pas le type des arbres et c'est d'autant plus dommage que les arbres existants ont parfois un tag type=*. Par ex. les arbres existants le long de la Promenade des Anglais sont marqué comme palmier (type=palm). Malheureusement je serai obligé de remettre le type à la main une fois l'import exécuté. Mon programme pourrait éventuellement récupérer le type des arbres existants mais bon ça ne marcherait que sur une toute petite partie des arbres importés... D'ailleurs j'ai un peu de mal à comprendre la bonne manière d'indiquer le type car sur la page Wiki du tag natural=tree (http://wiki.openstreetmap.org/wiki/Tag:natural%3Dtree) il est marqué que le tag type=* est obsolète et qu'il faut plutôt utilisé le tag leaf_type=*. Sauf que ce dernier n'est censé prendre que les valeurs suivantes : broadleaved / needleleaved / mixed / leafless. De plus sous JSOM si on met type=palm ça affiche bien l'arbre avec une image de palmier mais ça ne le fait pas si j'essaye avec genus|species=palm|palmtree. Bref c'est pas très clair... Voila si vous avez des conseils ou suggestions n'hésitez surtout pas.. ++ Vincent. ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Importation des arbres municipaux sur Nice
Perso je m'occupe d'intégrer les arbres de Montpellier + éclairage (campagne terrain plus Bing pour le placement) Les palmiers c'est du feuillu persistant. Il n'y a plus de distinction. Je laisse type=palm uniquement pour les palmiers... Sinon leaf_type=* et leaf_cycle sur chaque arbre et c'est ok Pour le nom complet latin j'utilise taxon=* et pas plus quand j'aurais mis tous les arbres j'ajouterai le reste par requête (Overpass) Penses à tester tout de même les zones contenant déjà un couvert végétal dans OSM pour éviter les doublons et de supprimer le tout. Après je mettrais plutôt 5 à 7m pour le rayons. Faire plusieurs tests en variant d'un mètre pour vérifier le rayons le plus probant. Le 21 juillet 2015 14:37, JB jb...@mailoo.org a écrit : Salut, Quelques remarques : - Overpass trouve 1188 arbres dans Nice : soit il en manque dans le fichier de l'agglo, soit 2m, c'est pas assez. Soit le fichier de l'agglo n'est pas assez bon, soit ce qui est dans OSM n'est pas assez bon. Problèmatique de tenter d'importer avant d'en savoir plus. - Pas vraiment d'accord pour supprimer l'existant pour y mettre la donnée de « référence » à la place. Le but est d'éviter d'arriver à la situation US vue d'ici (difficile de savoir ce qu'il en est réellement sans être sur place) ou l'essentiel de la donnée est issue d'import avec peu de vie communautaire locale. Et d'éviter la frustration des mappeurs locaux. - Es-tu inscrit à la liste de discussion import ? JB. Le 21/07/2015 14:05, Vincent Frison a écrit : Hello Je compte importer dans OSM l'ensemble des arbres municipaux de Nice, merci au portail OpenData de l'agglomération de Côte d'Azur. Ici c'est du vrai open data, je ne devrais donc pas avoir la même frustration qu'avec l'import des immeubles de PSS ;) Ils viennent de mettre à jour leur fichier qui contient maintenant plus de 30 000 arbres : http://opendata.nicecotedazur.org/data/dataset?q=arbres En plus de créer les nouveaux arbres mon programme vérifie également la présence d'arbres existants afin de les effacer. Actuellement j'ai mis un rayon de 2 mètres donc pour chaque arbre importé, je regarde les arbres existants qui sont à moins de 2 mètres. Pour l'instant je n'efface que l'arbre plus proche de l'arbre importé (je pourrais également supprimer tous les arbres qui sont à moins de x mètres mais en fait ça ne change pas grand chose car s'il y a plusieurs arbres existants qui sont très proches à priori il y aura également plusieurs arbres importés qui seront très proches donc au final même en ne supprimant que l'arbre existant le plus proche tous les arbres existants seront bien effacés, ce que j'ai pu vérifier par mes tests). Concrètement sur les ~30 000 arbres importés il y a ~540 arbres existants à supprimer. Ce qui est dommage c'est que le fichier n'indique pas le type des arbres et c'est d'autant plus dommage que les arbres existants ont parfois un tag type=*. Par ex. les arbres existants le long de la Promenade des Anglais sont marqué comme palmier (type=palm). Malheureusement je serai obligé de remettre le type à la main une fois l'import exécuté. Mon programme pourrait éventuellement récupérer le type des arbres existants mais bon ça ne marcherait que sur une toute petite partie des arbres importés... D'ailleurs j'ai un peu de mal à comprendre la bonne manière d'indiquer le type car sur la page Wiki du tag natural=tree ( http://wiki.openstreetmap.org/wiki/Tag:natural%3Dtree) il est marqué que le tag type=* est obsolète et qu'il faut plutôt utilisé le tag leaf_type=*. Sauf que ce dernier n'est censé prendre que les valeurs suivantes : broadleaved / needleleaved / mixed / leafless. De plus sous JSOM si on met type=palm ça affiche bien l'arbre avec une image de palmier mais ça ne le fait pas si j'essaye avec genus|species=palm|palmtree. Bref c'est pas très clair... Voila si vous avez des conseils ou suggestions n'hésitez surtout pas.. ++ 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] Importation des arbres municipaux sur Nice
Pourquoi supprimes-tu ? Si tu détectes qu'un arbre existe déjà, dans un rayon de 2m, pourquoi ne pas plutôt déplacer l'arbre existant et lui ajouter les éventuelles infos que tu apportes (source, date, ...) ? Ça permettrait de ne pas supprimer un travail déjà fait, et de conserver les éventuels tags déjà apposés (tel que le type que tu évoques). Francescu Le 21 juillet 2015 14:05, Vincent Frison vincent.fri...@gmail.com a écrit : Hello Je compte importer dans OSM l'ensemble des arbres municipaux de Nice, merci au portail OpenData de l'agglomération de Côte d'Azur. Ici c'est du vrai open data, je ne devrais donc pas avoir la même frustration qu'avec l'import des immeubles de PSS ;) Ils viennent de mettre à jour leur fichier qui contient maintenant plus de 30 000 arbres : http://opendata.nicecotedazur.org/data/dataset?q=arbres En plus de créer les nouveaux arbres mon programme vérifie également la présence d'arbres existants afin de les effacer. Actuellement j'ai mis un rayon de 2 mètres donc pour chaque arbre importé, je regarde les arbres existants qui sont à moins de 2 mètres. Pour l'instant je n'efface que l'arbre plus proche de l'arbre importé (je pourrais également supprimer tous les arbres qui sont à moins de x mètres mais en fait ça ne change pas grand chose car s'il y a plusieurs arbres existants qui sont très proches à priori il y aura également plusieurs arbres importés qui seront très proches donc au final même en ne supprimant que l'arbre existant le plus proche tous les arbres existants seront bien effacés, ce que j'ai pu vérifier par mes tests). Concrètement sur les ~30 000 arbres importés il y a ~540 arbres existants à supprimer. Ce qui est dommage c'est que le fichier n'indique pas le type des arbres et c'est d'autant plus dommage que les arbres existants ont parfois un tag type=*. Par ex. les arbres existants le long de la Promenade des Anglais sont marqué comme palmier (type=palm). Malheureusement je serai obligé de remettre le type à la main une fois l'import exécuté. Mon programme pourrait éventuellement récupérer le type des arbres existants mais bon ça ne marcherait que sur une toute petite partie des arbres importés... D'ailleurs j'ai un peu de mal à comprendre la bonne manière d'indiquer le type car sur la page Wiki du tag natural=tree ( http://wiki.openstreetmap.org/wiki/Tag:natural%3Dtree) il est marqué que le tag type=* est obsolète et qu'il faut plutôt utilisé le tag leaf_type=*. Sauf que ce dernier n'est censé prendre que les valeurs suivantes : broadleaved / needleleaved / mixed / leafless. De plus sous JSOM si on met type=palm ça affiche bien l'arbre avec une image de palmier mais ça ne le fait pas si j'essaye avec genus|species=palm|palmtree. Bref c'est pas très clair... Voila si vous avez des conseils ou suggestions n'hésitez surtout pas.. ++ Vincent. ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr -- Francescu ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
