[OSM-talk-fr] Importation des arbres municipaux sur Nice

Ven 24 Juil 10:20:24 UTC 2015

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.frison at 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-pro at 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 <cquest at 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 at openstreetmap.orghttps://lists.openstreetmap.org/listinfo/talk-fr
>>>
>>>
>>> --
>>> Christian Quest - OpenStreetMap France
>>>
>>>
>>> _______________________________________________
>>> Talk-fr mailing list
>>> Talk-fr at openstreetmap.org
>>> https://lists.openstreetmap.org/listinfo/talk-fr
>>>
>>>
>>
>> _______________________________________________
>> Talk-fr mailing list
>> Talk-fr at openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-fr
>>
>>
>
> _______________________________________________
> Talk-fr mailing list
> Talk-fr at openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>
>
-------------- section suivante --------------
Une pièce jointe HTML a été nettoyée...
URL: <http://lists.openstreetmap.org/pipermail/talk-fr/attachments/20150724/d4d3d477/attachment.htm>