<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">Le 26 juillet 2015 19:51, JB <span dir="ltr"><<a href="mailto:jbosm@mailoo.org" target="_blank">jbosm@mailoo.org</a>></span> a écrit :<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000">
Quelques réponses décousues :<span class=""><br>
<br>
<div>Le 26/07/2015 15:47, Vincent Frison a
écrit :<br>
</div>
<blockquote type="cite">
<div dir="ltr">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 :) </div>
</blockquote></span>
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…</div></blockquote><div><br></div><div>On va y aller tranquille, j'ai déjà envoyé des mails à 2 personnes.. et je pars bientôt en vacances ! :)</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div bgcolor="#FFFFFF" text="#000000"><span class=""><blockquote type="cite"><div dir="ltr">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. </div>
</blockquote></span>
… 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 ?</div></blockquote><div><br></div><div>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 ?</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div bgcolor="#FFFFFF" text="#000000"><span class=""><blockquote type="cite"><div dir="ltr">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.</div>
</blockquote></span>
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 ?<span class=""><br>
<blockquote type="cite">
<div dir="ltr">
<div>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.</div>
</div>
</blockquote></span>
Même question. Qui préfère retravailler de la mauvaise donnée que
d'en entrer de la nouvelle ? <br></div></blockquote><div><br></div><div>Oui mais bon là t'es en train de partir sur le postulat que j'insère des mauvaises données...<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div bgcolor="#FFFFFF" text="#000000"><span class=""><blockquote type="cite"><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">
</div>
</blockquote>
</div>
</div>
</blockquote></span>
Je ne connais pas le langage Java, mais <span>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 ?</span></div></blockquote><div><br></div><div>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..</div><div> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div bgcolor="#FFFFFF" text="#000000"><span>
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…<br></span></div></blockquote><div><br></div><div>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é).</div><div><br></div></div><br></div></div>