> Est ce qu a l echelle de la France le nombre de polygones filtres est
> beaucoup plus important que lors de la passe precedente ? 

Faut lire le thread en entier ;-)

Une différence de ~4000 pour un total de 164425 maintenant.

> Il va peut etre falloir faire un compromis entre quelques petits
> recouvrements et un gros boulot d import manuel 

Maintenant on est dans du "quelques petits recouvrements", sauf qu'avant si 
une surface représentait moins de 2% du polygone corine qui pouvait être mis 
dessus, le petit passait potentiellement sous le gros. (selon la 
représentation des données bien sûr, donc selon l'ordre dans les styles pour 
le rendu corine)

En reprenant ton exemple des 7 laux (tiens t'es du coin ? tiens tu traces 
encore des footway en montagne ?), je les ais patiemment tracé à la mimine 
(et y'en a pas que sept na di diou) et ça me ferait un peu chier qu'une forêt 
vienne se poser par dessus mon chouette boulot avec comme seule solution :
"y'a ka y repasser dessus et arranger la forêt boudiou !"

Tout ça pour dire, que les "rebuts", c'est à dire les 4000 plus un paquet 
d'autres encore (7500 au total si je ne m'abuse) resterons disponibles pour 
des imports manuels avec fusion manuelle. Mais on garde la base en état 
d'être utilisé pendant ce temps plutôt que d'avoir l'inverse, c'est à dire 
des chevauchements jusqu'a ce qu'on les corrige.

Je concède parfaitement que le boulot sera peut-être plus important à faire 
des ajouts qu'a faire des retraits (encore que ? ça dépendra de l'outil à 
disposition et de sa date de mise en place) mais au moins, comme je le disais 
avant, les courageux ayant tracé des trucs précis, (ou petits) n'auront pas 
l'impression qu'on ignore leur travail. (je sais c'est pas le cas, la surface 
sera toujours bien là en dessous, mais en dessous)

Bref, je radote d'accord.

A noter que émilie regarde une solution qui permettrait d'importer quand même 
certains polygones corine bien qu'il existe un "petit dedans" dans les cas, 
que l'on utilise et pré-suppose toujours dans osm, qui est la "relation 
d'importance ou de présence"

Je me doute que c'est pas clair, alors je donne un exemple :
Dans osm, quand on trace un lac, on trace un lac sans se demander s'il est 
dans une forêt, dans une prairie ou autre. On "pré-suppose" qu'il sera 
dessiné, et utilisé en étant toujours par dessus parce qu'il est "plus fort"
( La perfection voudrait qu'on utilise le système de relation multipolygon 
pour décrire qu'il y a un trou et que c'est un lac, mais la flemme tout ça, 
fait qu'en moyenne on le fait pas.)

Après le problème vient des cas où il est difficile de deviner qui est le plus 
fort, une forêt de conifère contre une forêt de feuillus ? une pairie contre 
de la garigue ? une ile contre un lac ? (ben là, on a pas le choix, si y'a 
des trous, on utilise les multipolygones)

La réflexion de tout à l'heure avec émilie est: ne peut on pas lister 
les "plus fort" ? et en déterminer lesquels on importe bien qu'ils 
superposent un truc plus petit.

L'exemple classique était le parc contre le landuse=residential. On a remarqué 
que plein de landuse residential n'allaient pas être importés parce que la 
ville contient au choix : cimetière, parc, forêt. Or on pourrait en fait, car 
les residential sont "moins fort" que les autres.

Bon, je m'égare aux morilles et j'ai p'tet dis des conneries, et je me dis 
aussi qu'on aurait pû considérer dans osm que tout polygone contenu 
intégralement dans un autre est "plus fort" qu'il doit donc être 
représenté/considéré comme existant vraiment et qu'on se fait peut-être ch... 
pour rien avec les multipolygones à trou et que d'un coup j'arrive plus à me 
rappeler pourquoi on s'en sert.



-- 
sly
Sylvain Letuffe sylv...@letuffe.org
qui suis-je : http://slyserv.dyndns.org



_______________________________________________
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Répondre à