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). > I1<2m>E1 > I1<3m>E2 > I2<1m>E1 > I2<4m>E3 > 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
