<div dir="ltr">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).<div><br></div><div>La précision a l'air bonne tout du moins sur les zones que j'ai regardé en détail. </div><div><br></div><div>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).</div><div><br></div><div>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...</div><div><br></div><div>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 :</div><div></div><div><pre style="color:rgb(0,0,0)">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</pre></div><div>Pour revenir à la discussion sur les <span style="font-size:12.8000001907349px">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 !</span><br></div><div><span style="font-size:12.8000001907349px"><br></span></div><div><span style="font-size:12.8000001907349px">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 é</span><span style="font-size:12.8000001907349px">videmment</span><span style="font-size:12.8000001907349px"> mieux </span><span style="font-size:12.8000001907349px">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...</span></div></div><div class="gmail_extra"><br><div class="gmail_quote">Le 23 juillet 2015 16:05, Jérôme Seigneuret <span dir="ltr"><<a href="mailto:jseigneuret-pro@yahoo.fr" target="_blank">jseigneuret-pro@yahoo.fr</a>></span> a écrit :<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">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.<div><br></div><div>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).</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>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? </div><div><br></div><div>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. </div><div><br></div><div><br></div><div><br></div></div><div class="HOEnZb"><div class="h5"><div class="gmail_extra"><br><div class="gmail_quote">Le 23 juillet 2015 14:13, Christian Quest <span dir="ltr"><<a href="mailto:cquest@openstreetmap.fr" target="_blank">cquest@openstreetmap.fr</a>></span> a écrit :<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div>
Certains imports sont à bien peser...<br>
<br>
@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é.<br>
<br>
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.<br>
<br>
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 ?<br>
<br>
Entretien: qu'en disent les contributeurs locaux ? Ce sont eux qui
vont en priorité pouvoir entretenir des données aussi détaillées.<div><div><br>
<br>
<br>
<div>Le 23/07/2015 00:37, JB a écrit :<br>
</div>
</div></div><blockquote type="cite"><div><div>
Le 22/07/2015 16:36, Jérôme Seigneuret a écrit :<br>
<blockquote type="cite">
<div dir="ltr"><br>
<div class="gmail_extra">
<div class="gmail_quote">
<blockquote class="gmail_quote">
<div>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 : <a href="http://hpics.li/85d8ec5" target="_blank">http://hpics.li/85d8ec5</a>.
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.<br>
À part compliquer la contribution, foirer le rendu,
rendre impossible toute correction humaine ultérieure</div>
</blockquote>
<div><br>
</div>
<div>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...</div>
</div>
</div>
</div>
</blockquote>
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.<br>
<blockquote type="cite">
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote">
<div>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. </div>
</div>
</div>
</div>
</blockquote>
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.<br>
<blockquote type="cite">
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote">
<div>Ca a aussi un intérêt environnemental: </div>
<div> - étude des pollens</div>
<div> - accueille de la faune</div>
<div>Un intérêt patrimonial, paysager, ...</div>
<div><br>
</div>
<div>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.</div>
<div>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.</div>
<div><br>
</div>
<div>Bref les possibilités sont grandes même si certains
n'en trouve pas l'intérêt.</div>
</div>
</div>
</div>
</blockquote>
Bof, change le mot « intérêt » en « inconvénients dépassent les
avantages ».<br>
<br>
<fieldset></fieldset>
<br>
</div></div><span><pre>_______________________________________________
Talk-fr mailing list
<a href="mailto:Talk-fr@openstreetmap.org" target="_blank">Talk-fr@openstreetmap.org</a>
<a href="https://lists.openstreetmap.org/listinfo/talk-fr" target="_blank">https://lists.openstreetmap.org/listinfo/talk-fr</a>
</pre>
</span></blockquote>
<br><span>
<pre cols="72">--
Christian Quest - OpenStreetMap France</pre>
</span></div>
<br>_______________________________________________<br>
Talk-fr mailing list<br>
<a href="mailto:Talk-fr@openstreetmap.org" target="_blank">Talk-fr@openstreetmap.org</a><br>
<a href="https://lists.openstreetmap.org/listinfo/talk-fr" rel="noreferrer" target="_blank">https://lists.openstreetmap.org/listinfo/talk-fr</a><br>
<br></blockquote></div><br></div>
</div></div><br>_______________________________________________<br>
Talk-fr mailing list<br>
<a href="mailto:Talk-fr@openstreetmap.org">Talk-fr@openstreetmap.org</a><br>
<a href="https://lists.openstreetmap.org/listinfo/talk-fr" rel="noreferrer" target="_blank">https://lists.openstreetmap.org/listinfo/talk-fr</a><br>
<br></blockquote></div><br></div>