Effectivement, surtout qu'il faut encore de la place pour la base de données dans laquelle on va charger les données.<div>J'ai déjà essayé de charger le fichier France et une VM de 160 Go (incluant environ 1 Go de logiciel mais pas l'espace swap de 64Go pour la mémoire virtuelle) n'a pas suffit. Et avant que la base de données déborde dans le système de fichier cela a pris tout de même 2 jours sur une VM à laquelle j'avais consacré 6 processeurs sur 8...</div>

<div><br></div><div>Charger le fichier France demande maintenant des ressources considérables, avec un serveur dédié, de l'espace de stockage confortable sur un système de fichier annexe pour les données temporaires.</div>

<div><br></div><div>Ce serait bien que ceux qui parviennent encore à l'utiliser mentionnent quelque part la configuration qui leur a été nécessaire la dernière fois, surtout pour la question de l'espace disque (hors espace swap). et une indication du temps de chargement (avec une description sommaire des ressources de la machine utilisée: nombre de processeurs, mémoire, type de processeur, et type de montage du système de fichier, et si quel espace de fichiers ils ont mis sur un disque flash et non un disque physique (surtout pour la phase de génération des index de pgSQL).</div>

<div><br></div><div>Si pour alléger le travail un préfilrage des données est effectué pour charger les données en plusieurs lots, ce serait bien aussi d'être guidé. c'est assez bête de faire tourner un script pendant 2 ou 3 jours et le voir planter parce que le système de fichiers n'a plus de place pour continuer à étendre la base de données pendant sa phase de préparation.</div>

<div><br></div><div>Aussi, une fois l'opération terminée, y a-t-il beaucoup d'espace de travail temporaire libéré.</div><div><br></div><div>La seule façon pour l'instant d'estimer cela c'est de commencer par une région plus petite pour estimer les besoins nécessaire approximativement pour une région plus grande. Malheureusement cette estimation à partir d'une région seulement est fausse : la densité spatiale des données n'est certainement pas du tout distribuée de la même façon selon qu'on considère l'île-de-France ou la Champagne-Ardenne, et il y a une part des volumes nécessaires non proportionnelle, ou qui croit de façon non linéaire (par exemple logarithmique), ce qui complique les estimations préalables d'espace.</div>

<div class="gmail_extra"><br><br><div class="gmail_quote">Le 1 décembre 2012 16:29, Christian Quest <span dir="ltr"><<a href="mailto:cquest@openstreetmap.fr" target="_blank">cquest@openstreetmap.fr</a>></span> a écrit :<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Et autant éviter de le décompresser si on peut utiliser bzcat en pipe...<br>
<br>
<br>
Le 1 décembre 2012 16:23, Michaël Zakrzewski<br>
<<a href="mailto:mikamika48197646@free.fr">mikamika48197646@free.fr</a>> a écrit :<br>
<div class="im HOEnZb">> Bonjour Claude,<br>
> regarde avec Winrar par exemple quelle est la taille du fichier décompressé france.osm avant de le décompresser car il est très probable que ce fichier fasse plus de 34 Go.<br>
><br>
> Michaël<br>
><br>
<br>
</div><span class="HOEnZb"><font color="#888888">--<br>
Christian Quest - OpenStreetMap France - <a href="http://openstreetmap.fr/u/cquest" target="_blank">http://openstreetmap.fr/u/cquest</a><br>
</font></span><div class="HOEnZb"><div class="h5"><br>
_______________________________________________<br>
Talk-fr mailing list<br>
<a href="mailto:Talk-fr@openstreetmap.org">Talk-fr@openstreetmap.org</a><br>
<a href="http://lists.openstreetmap.org/listinfo/talk-fr" target="_blank">http://lists.openstreetmap.org/listinfo/talk-fr</a><br>
</div></div></blockquote></div><br></div>