[OSM-talk-fr] Importation des arbres municipaux sur Nice
JB
jbosm at mailoo.org
Dim 26 Juil 17:51:16 UTC 2015
Quelques réponses décousues :
Le 26/07/2015 15:47, Vincent Frison a écrit :
> 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 :)
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…
> 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.
… 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 ?
> 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.
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 ?
> 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.
Même question. Qui préfère retravailler de la mauvaise donnée que d'en
entrer de la nouvelle ? Pourquoi la BD Carthage n'a pas été importée ?
> …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…
La reconnaissance terrain, ce n'est pas forcément avec les Fieldpapers…
La charte du contributeur ne le mentionne pas…
>
> 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).
>
Je ne connais pas le langage Java, mais 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 ? 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…
>
> 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
>
-------------- section suivante --------------
Une pièce jointe HTML a été nettoyée...
URL: <http://lists.openstreetmap.org/pipermail/talk-fr/attachments/20150726/f3d8ae75/attachment.htm>
Plus d'informations sur la liste de diffusion Talk-fr