> Mais il faut aussi que je fasse des tests pour voir si le script > bulk_upload.py est capable de gérer une telle quantité d'éléments. > En effet, pour chaque élément créé, il regarde si son id n'est pas > déjà translaté dans le serveur. On va se retrouver avec un tableau > (collection, hashmap?) de 18 millions d'id (en fait deux id's, le > local et celui du serveur) et je ne connais pas suffisament Python > pour savoir s'il est capable de gérer ça correctement (c.a.d > rapidement).
Après quelques rapides tests : Un fichier de OSM de 9Mo a pris environ 30mn à être traité sur le dev server Comme pieren l'avait relevé dans le foreach (node, way, relation) le bidule upload d'abord les noeuds. La syntaxe du fichier de stockage de noeuds locaux est en texte : (dp0 S'-18031717' (local) p1 S'403774' (distant) p2 (...) bulk_upload.py (version par défaut) va bien découper en autant de changesets que nécessaire : $ python bulk_upload.py -c "Import Corine polygone" -i nooverlapwater.osm -u li...@letuffe.org -p slyslysly Uploading change set:1783 Uploading change set:1784 (...) Uploading change set:1857 Error uploading changeset:500 <h2>Application error</h2>Rails application failed to start properly Mais cette histoire se termine mal : http://api06.dev.openstreetmap.org/user/slydev/edits Le "plantage" dont je n'ai aucune explication est arrivé au premier changeset avec des ways http://api06.dev.openstreetmap.org/browse/changeset/1857 Voilà, j'imagine que tu allais le tenter de toute façon sur dev, mais si tu obtiens la même erreur, on pourra se dire que ça n'est pas "pas de chance" -- 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
