On mardi 29 septembre 2009, Thomas Petazzoni wrote: > Bonjour, > Le dernier article fait notamment le point sur le problème d'avoir une > base de données de la planète entière mise à jour de façon régulière. > Contributions et idées bienvenues sur le sujet, nous sommes un peu secs > et ça nous empêche d'implémenter le support pour d'autres pays.
Salut, Si mes devinettes sont bonnes, vous utilisez un serveur kimsuffi chez ovh, et à en voir vos résultats je dirais http://www.kimsufi.com/ le premier ? Bref, avec ça, je dirais que ça va être vraiment chaud de gérer osm worldwide (que ce soit l'import initial ou les diffs). Concernant l'optimisation d'osm2pgsql, je ne pense pas que cette voie soit bien terrible, certes ça profiterait à tout le monde, mais je doute que ce soit codé avec les pieds, donc je doute qu'il y est beaucoup à gagner. Idées en vrac (alternatives ou cumulables) : - se rabattre sur l'europe plutôt que la terre (j'utilise des hour diff qui prennent environ 5/8 minutes, mais mon serveur est plus costaud ) - ne pas tout importer (laisser de coté certains poi/way/polygone de moindre importance) - changer de serveur, et impérativement booster les accès disques qui sont ~90% résponsables du temps d'import (Penser au RAID 0, disques SSD, ou autres) PS1: deux serveurs est une mauvaise idée si vous pensez faire une base postgres d'un coté, et les imports diff de l'autre, vous serez limiter par le réseau, et c'est bien pire que les disques PS2: pas besoin de diff pour l'europe, vous utilisez ceux de la terre, et vous appliquez une bbox PS3:au fait, tant que l'import d'un diff est inférieur à 24h, où est le problème ? -- 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
