[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