2009/12/4 Pierre Touzard <pierretouz...@yahoo.fr> > > étape 1 : extraction et assemblage des bâtiments commune par commune... > étape 2 : conversion en WGS84 > etape 3 : fusion des polygones contigües pour faire disparaitre les limites > "administratives" pouvant exister entre des bâtiment. En somme, on passe > d'une couche "bâtiments durs" à une couche "îlots de bâtiments durs" > étape 4: pour chaque polygone on supprime tous les attributs et on affecte > un nouvelle attribut "source =DGFiP" > ... Il me semble que nous venons de créer là un "produit dérivé" ? oui ou > non ? > étape 5: ouverture de la couche SIG dans QGIS et import dans OSM > > Ce genre d'import serait-il bénéfique à OSM ? oui ou non ? > La procédure décrite conviendrait-elle ? oui ou non ? > Cela nécessiterait-il un travail préparatoire (interférences avec les zones > déjà mappée) ? >
Je travaille actuellement sur la vectorisation des données raster que l'on obtient sur le site du cadastre, donc je vois ce que tu fais. De plus, ce que tu as fait a déjà été fait par Steven et Francois pour la communauté urbaine de Brest. L'import serait bénéfique a OSM. La conversion en WGS84 est le plus gros problème pour moi actuellement car je dois deviner quel SRID utiliser pour le georeferencage. Si tu as le bon SRID pour les données, la encore la conversion dans Postgis se fait tout seul en quelques lignes. Concernant l'étape 3, je ne suis pas sure que la fusion soit une bonne chose en soi. L'autre chose c'est qu'a partir de cette étape je mets tout dans une base de donnée Postgis. Donc je peux faire une sélection (en théorie) sur le type facilement. A noter qu'avec les bâtiments, tu peux créer facilement un landuse residential qui soit "correct" en quelques lignes de commande SQL. Mon étape 4 est de justement procéder a un calcul de superposition avec ce qui existe déjà. Une fois que j'ai obtenu cela, je génère un fichier OSM a partir d'un fichier SHP généré a partir de la base de donnée. En aucun cas, je n'utilise une couche SIG. Je trouve cela bien trop lourd et pas assez flexible, mais bon la c'est vrai que j'ai le biais d'aimer ma base de donnée, qui me permet de faire des choses très puissantes sans avoir a coder une usine a gaz. De plus, je préférerais voir une interface web a la Corine pour l'import d'une ville plutôt qu'un import massif. Je préfère un import a la mano par la communauté. Ça permet de donner du travail a des gens qui ne peuvent pas forcement participer a OSM. Le but du jeu est d'attirer le plus de monde sur OSM, et de les faire participer. Ce genre d'outil permet de faire cela justement, et de "fidéliser" les gens qui y participent au final. Maintenant, sur les autres considérations, a moins de connaître comment tu as eus les données et pourquoi, on ne peut pas te répondre. On ne sait pas les accords que ta société a signé avec les détenteurs du cadastre. Ce n'est pas a nous de nous justifier sur le plan légal mais plutôt a toi. Déjà, c'est a toi de savoir si tu as le droit d'utiliser ces données légalement en premier lieu car c'est toi qui les propose. Ton ton volontairement caricaturale me gêne énormément, car au final tu n'as pas répondu a la question par toi même, toi qui est justement en position d'y répondre. Ce genre d'import ne pose pas de problèmes techniques majeurs a la base. La discussion technique n'a d'intérêt que si on a l'accord d'utiliser les données, sinon ça reste du théorique. Emilie Laffray
_______________________________________________ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
