> Si tu as des fonctions postgis gourmandes en CPU, tu peux peut-être > tenter un simplify() sur la colone geometry, avant de passer aux > fonctions qui bourrinent.
Et bien l'idée valait le coup d'être tentée, y'a pas à chier, ça gagne en temps : sans st_simplify : http://beta.letuffe.org/cartes/communes.png : 1 minutes 30 avec : http://beta.letuffe.org/cartes/communes2.png : 15 secondes ( avec ST_SimplifyPreserveTopology : http://beta.letuffe.org/cartes/communes3.png : 1 minute) Hélas comme j'en avais peur, le st_simplify sort des géométries valides sur la base de géométries non valides (le ST_SimplifyPreserveTopology semble carrément toutes les corriger ) Mais par essais/erreurs, j'ai rajouté des st_simplify sur les grosses géométries type départements avant de les donner à mapnik et ça gagne de 20 à 30% (parfois bien plus, mais je pense heurter un problème de tunning de mon postgres qui doit s' emmêler les buffers ) A noter finalement que après tous ces tests, une vérité revient super régulièrement : Ce sont les disques durs qui sont limitant. Si je lance deux rendus identiques à la suite l'un de l'autre (histoire que le noyau linux me laisse tout dans un cache RAM) le temps varie de diviser par 3 à diviser par 10. Conclusion : mettre 16Go de RAM et laisser la base postgis sur un RAM-disque ;-) -- 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
