Quelques pistes pour les algos de calculs de buffers de polygones: http://stackoverflow.com/questions/1109536/an-algorithm-for-inflating-deflating-offsetting-buffering-polygons Suivre les liens de cette discussion. La solution "naïve" que tu utilises n'est pas correcte mais le problème est connu et a des solutions. Plus de détails sur l'article suivant (avec un peu de code): http://www.cgal.org/Manual/3.2/doc_html/cgal_manual/Straight_skeleton_2/Chapter_main.html
Le 9 juin 2013 12:50, Philippe Verdy <verd...@wanadoo.fr> a écrit : > Je ne pense pas que changer les épaisseurs ne soient viable. Il me semble > que c'est l"algo qui fait un calcul appromximatif des buffers dans le > système de coordonnées en projection carto (pixels) qui est défaillant : on > ne doit pas se contenter de calculer un segment parallèle et le joindre au > segment suivant et précédent, il faut aussi clipper ces polygones pour > qu'il ne sortent pas du polygone de base, et éliminer les parties interne > en superposition multiples (c'est le principe compliqué de calcul > géométrique des buffers, que réalise PostGIS dans le système de coordonées > géographique, mais que tu n'utilises pas ici). > > Pour cela il existe des algos dans les bibliothèques graphiques, mais là > je n'ai aucune idée de ce dont tu disposes dans ton code pour le faire, et > si ta blibliothèque de rendu vectoriel le propose parmi ses utilitaires de > transformation de géométries (ce n'est pas un algo proposé par défaut pour > SVG ou Postscript par exemple) ; il y en a pour GDI+ ou Flash mais là je > n'ai aucune idée des nterfaces que tu utilises pour convertir les > géométries avant leur rendu vectoriel. Ces algos libres doivent pourtant > exister car PostGIS a bien du les implémenter pour calculer ses propres > buffers en coordonnées géographiques. > > > > Le 9 juin 2013 12:19, Christian Quest <cqu...@openstreetmap.fr> a écrit : > > Toujours mieux avec un permalien ! >> >> J'ai vu ces défauts sur les petits polygones. >> >> C'est lié à la technique utilisée (sans buffers postgis). >> >> Il va sûrement falloir changer l'épaisseur en fonction de la surface >> du polygone ou un truc du genre... >> >> >> Le 9 juin 2013 12:11, Philippe Verdy <verd...@wanadoo.fr> a écrit : >> > >> http://tile.openstreetmap.fr/?zoom=11&lat=47.61458&lon=-3.39151&layers=B00000F >> > >> > Regarde bien le sud de l'île de Groix au zoom 11, et vois comment ça >> déborde >> > (côté mer c'est plus facile à voir) par rapport au rendu du zoom 12. Les >> > débordements sont encore plus accentués au zoom 10. >> > Et ça explique pourquoi ces réserves semblent beaucoup plus étendues >> > qu'elles ne sont, et trop visibles aussi. En fait cela affecte *toutes* >> les >> > petites réserves. >> > >> >> -- >> Christian Quest - OpenStreetMap France >> Un nouveau serveur pour OSM... http://donate.osm.org/server2013/ >> >> _______________________________________________ >> Talk-fr mailing list >> Talk-fr@openstreetmap.org >> http://lists.openstreetmap.org/listinfo/talk-fr >> > >
_______________________________________________ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
