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é. 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 >> ». >> >> >> _______________________________________________ >> Talk-fr mailing >> listTalk-fr@openstreetmap.orghttps://lists.openstreetmap.org/listinfo/talk-fr >> >> >> -- >> Christian Quest - OpenStreetMap France >> >> >> _______________________________________________ >> Talk-fr mailing list >> Talk-fr@openstreetmap.org >> https://lists.openstreetmap.org/listinfo/talk-fr >> >> > > _______________________________________________ > Talk-fr mailing list > Talk-fr@openstreetmap.org > https://lists.openstreetmap.org/listinfo/talk-fr > >
_______________________________________________ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
