[OSM-talk-fr] Beta letuffe - avancement communes - erreur

[sly (sylvain letuffe)]

> 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 sylvain at letuffe.org
qui suis-je : http://slyserv.dyndns.org