Patrice Vetsel a écrit : > Avec la connaissance du terrain de par chez moi, cette source de données > est tout de même bien imprécise. Le Doubs a disparu dans Besançon ! > > Je me dis donc qu'il ne faut pas l'importer directement sous OSM. > > Par contre comme un outil développé sous forme de plugin pour Josm > (merkaartor etc.) ce serait là complètement dans ma démarche de qualité. > +1 surtout si quelques outils permettant des opérations booléennes sur les surfaces : intersection, fusion exclusion... (à l'image de la fusion déjà existante et toujours 'expérimentale') permettent de jouer entre l'existant dans osm et l'import retaillé : suppression du "riverbank" existant dans le tracé de la forêt de Corine Land Cover. Mais ça suppose, j'imagine, une approche par sous-claques pour regrouper et organiser les éléments d'une opération. Du boulot pour les programmeurs ;-) > > Il y a plusieurs approches possibles: > > - nationale avec une ou deux personnes se chargeant d'extraire toutes > > les forêts déjà dans la base et utilise un script intelligent (encore > > à développer) qui fait la combinaison du meilleur des deux puis un > > méga-upload; > > - départementale où le travail serait plus partagé et décentralisé Départemental, la connaissance du terrain entre alors en jeu...
Ne peut-on pas imaginer (imaginer, je sais faire, réaliser, non) un import en masse par défaut, pour les forêts pour commencer (code 31), puis pour les zones herbacées (code 32), qui saute les zones où existent déjà une surface dans OSM mais qui sauvegardent les tracés à la mode "beta.letuffe.../commune/ " avec un découpage de la France en 256x256 carreaux (ou autres)... Les zones critiques étant finies 'a la mano', avec des outils booléens. Bon, voila que je rêve moi aussi... Vincent _______________________________________________ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
