[OSM-talk-fr] Corine Land Cover : nomenclature 14 "Espaces verts artificialisés, non agricoles"

[Vincent Pottier]

Emilie Laffray a écrit :
> 2009/5/27 Vincent Pottier <vpottier at gmail.com>:
>   
>> D'après ce que j'ai compris, osmosis sait extraire une zone selon une
>> bbox. et osmosis, c'est du java en ligne de commande.
>> Il faut donc un petit script qui écrive la requête pour osmosis à partir
>> du formulaire http et qui retourne un fichier .osm, et qui sache traiter
>> les erreurs de base : hors zone, zone invalide (Est < Ouest), code
>> inexistant (on peut traiter une partie en frontend avec du javascript et
>> lancer une requête xmlHTTP si valide)
>> Ce qui suppose une petite API : définition du code clc et du
>> recouvrement, et correspondance au nom de fichier, bbox... pour
>> interfacer avec osmosis
>>     
>
> Ton idee est donc d'utiliser le fichier osm produit.
>   
Mon idée est d'utiliser LES fichiers osm produits, beaucoup plus légers,
probablement exploitables durant le temps accordé à une requête http (30
secondes souvent)

http://www.grayonox.com/nooverlaptown.osm.bz2
http://www.grayonox.com/overlaptown.osm.bz2
http://www.grayonox.com/smalloverlaptown.osm.bz2
http://www.grayonox.com/nooverlapmdc.osm.bz2
http://www.grayonox.com/overlapmdc.osm.bz2
http://www.grayonox.com/smalloverlapmdc.osm.bz2


> Extraire avec une bounding box est facile pour Osmosis. On peut meme
> extraire avec un polygone plus complexe mais le cout est assez eleve
> meme si je doute que dans le cas present on aura un probleme puisqu'on
> parle de la France.
> Il est aussi possible avec Osmosis d'extraire un way avec la syntaxe
> k.v, genre landuse.forest ou CLC:code.111 par exemple. Il ne devrait
> pas y avoir de probleme. Toutefois, Osmosis n'a aucun moyen de filtrer
> une relation a l'etat actuel rendant la procedure actuel seulement
> utile dans le cas d'un way.
> L'autre chose c'est que le parametre de recouvrement n'est pas inclus
> dans le fichier OSM. Si l'on veut utiliser cette valeur avec Osmosis,
> cela implique de rentrer la valeur directement dans le fichier OSM, et
> c'est quelque chose a laquelle je m'oppose.
L'idée d'utiliser les fichiers produits, c'est de chercher une tranche
de recouvrement (no/small/full...) : le calcul est déjà fait.
> Cette valeur devrait
> tendre a terme vers 100 pour chaque objet.
C'est exact ! Quoi que l'intérêt de l'import manuel, c'est aussi de
faire des retouches sur le polygone, pas seulement de lui attribuer les
bons tags notamment pour les zones hétérogènes.
> De plus, du fait que l'on
> doive utiliser Osmosis dans un mode k.v, cela implique de ne pas
> pouvoir garder les valeurs telles qu'elles sont. Cela impliquerait de
> garder quelque chose comme une valeur dans la gamme (0, 10, 20, 30,
> etc...). Si l'on n'a plus de valeurs, ca devient ingerable.
> Maintenant, osmosis a un cout non negligeable. Je pense que la charge
> de travail sur le serveur sera assez eleve s'il est utilise
> regulierement.
>
> Emilie Laffray
>   
Vincent