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

[sylvain letuffe]

> Sinon, je serais interessee par les query que tu as mis en place :)
> Je ne me preoccupe pas du tout d'affichage mais je serais interessee par 
> les optimisations que tu obtiens.

en moyenne c'est de la bidouille "essais/erreurs", mais je files tout librement :
http:///beta.letuffe.org/mapnik-styles



> Par experience, Postgis a du mal avec les tres grosses geometries. De 
> plus, il existe un bug connu lie au pages TOAST qui ne tiennent pas 
> compte de la taille de la geometrie.
> Si la table est relativement petite et que la geometrie est enorme, les 
> index seront ignores par le planner de Postgres au profit d'un scan. 
> C'est quelque chose que j'ai deja subi. J'ai resolu le probleme en ne 
> faisant plus de scan sur la table qui posait probleme :p
> Plus serieusement, la solution generalement dans ce cas la est de 
> decouper les geometries, en partie plus petites avec un nombre limite de 
> points. Cela permet d'augmenter le nombre de ligne et de reduire la 
> taille de la geometrie.
> A noter que je parle d'un cas totalement different en premier lieu, donc 
> ca peut ne pas s'appliquer a ce que tu fais.
> 
> Emilie Laffray
> 
> sly (sylvain letuffe) wrote:
> >> 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 ;-)
> >
> >   
> 
> 
> _______________________________________________
> Talk-fr mailing list
> Talk-fr at openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-fr