Donc l'idée serait de développer notre propre version du GEOFLA pour les communes, mais avec une meilleure résolution, pour les communes qu'on a déjà vectorisées. Voire plusieurs versions selon la résolution demandée, et adaptée à certaines échelles de rendu.
Ce genre de traitement de simplification (san extension par un buffer) a été fait pour les pays et pour les lignes de côtes (avec le paramètre de distance minimale entre les noeuds sucessifs à 300 mètres il me semble, et sans non plus tenir compte de la concavité des angles simplifiables). Le critère de concavité est pourtant assez simple à calculer: dès qu'on a fermé tous les anneaux et qu'on les a orienté de sorte que le côté interne est toujours à gauche (dans la direction du parcours du polygone), un sommet formant un angle qui tourne à gauche n'est pas éliminable (sauf en augmentant encore la longueur de buffer pour le déplacer encore plus loin), alors qu'un sommet qui forme un angle qui tourne à droite est candidat à l'élimination directe. Un autre paramètre concerne l'extension maximale des zones de buffers : celui des longueurs de biseaux. Ce paramètre existe dans tous les rendus vectoriels classiques (SVG ou Postscript par exemple), et est déterminé par le rapport maximum devant subsister entre la longueur du biseau (distance entre le sommet réel du polygone d'origine et le sommet déplacé par le buffer sur la pointe), et sa largeur (distance entre les points externes des rectangles formés orthogonalement de part et d'autre de chaque segment su polygone d'origine). Classiquement ce paramètre de seuil vaut 4 par défaut. Quand le rapport calculé pour former une jonction par un biseau dépasse ce paramètre de seuil, au lieu d'inclure ce biseau en entier (dont la forme est constituée de deux triangles isocèles formant un losange isocèle, et dont l'arête commune est le segment joignant les angles droits des rectangles de buffer de part et d'autre de chacun des segments successifs du polygone d'origine), on élimine du losange le triangle isocèle le plus pointu pour ne garder que le triangle isocèle le plus plat (qui joint les angles droits des deux rectangles de buffer, et le sommet du polygone d'origine) : cela génère alors 2 sommets (aux angles droits des rectangles à joindre) au lieu d'un seul sur le polygone d'origine. Ce traitement des biseaux doit se faire lors de l'étape de formation des buffers, avant celle de simplification des polygones pour réduire leur résolution (cette seconde étape continuera alors à utiliser le critère de concavité, c'est à dire le "tourne à gauche" ou "tourne à droite" quand le polygone est orienté avec un côté interne à gauche et un côté externe à droite, pour savoir quels sommets sont à garder absolument pour ne pas trop tronquer les pointes, même quand elles ont été jointes par un triangle et non un losange de biseau). Tout cela est un traitement purement mathématique avec des critères simples : - une distance (largeur d'extension externe des buffers) - le rapport de seuil d'extension par biseau (typiquement 4), utilisé lors de la première étape de création des buffers. - une autre distance (celle de la résolution demandée en fonction de l'échelle pour la simplification, mais qui peut être égale à la première) - éventuellement un dernier paramètre limitant le nombre maximum de sommets par polygone fermé (ce dernier traitement d'élimination de sommets sur les segments les plus courts, ne peut avoir lieu qu'après les deux premiers, il risque de tronquer des pointes qui auraient du être gardées et de créer des artéfacts comme ceux qu'on observe sur Layers où deux faces théoriquement parfaitement limitrophes dans leur définition et dans la base OSM ne le sont plus et laissent des superpositions et interstices entre ces faces) Le 17 octobre 2012 11:32, Christian Quest <[email protected]> a écrit : > Sauf si on en fait une version simplifiée, mais quand même moins que > le GEOFLA, un peu comme ce que j'avais fait en SVG pour les > départements et régions: > http://openstreetmap.fr/contours-departements-et-regions > > Le 17 octobre 2012 09:55, Nicolas Dumoulin > <[email protected]> a écrit : >> >> Et aussi, parce que les contours gratuits de l'IGN sont directement >> téléchargeable en .shp et que finalement la précision est suffisante et >> évite de >> coûter trop cher à traiter. >> Si demain, je devais afficher des contours de plusieurs communes en >> vectoriel, >> je ne prendrais surtout pas les contours bruts d'OSM, même si on les avait >> tous. >> > > > -- > Christian Quest - OpenStreetMap France - http://openstreetmap.fr/u/cquest > > _______________________________________________ > Talk-fr mailing list > [email protected] > http://lists.openstreetmap.org/listinfo/talk-fr _______________________________________________ Talk-fr mailing list [email protected] http://lists.openstreetmap.org/listinfo/talk-fr
