<p>En regardant un peu le code de bulk_upload (donc en apprenant comment fonctionne l'api), ca fait un put http du changeset, donc même si ca passait en sax pour charger le fichier OSM source de 1.4Go et générer la requête d'envoi, je me demande si le serveur destination saura traiter ce fichier du mm ordre de grandeur...</p>

<p><blockquote type="cite">Le 8 juil. 2009, 6:13 PM, "Etienne Chové" <<a href="mailto:chove@crans.org">chove@crans.org</a>> a écrit :<br><br>Pieren a écrit :<br>
<p><font color="#500050">> Malheureusement, j'ai l'impression que ma version tente de charger le
> document en entier en mémo...</font></p>Il y a deux grandes familles de parseurs :<br>
  - ceux qui chargent tout le document en ram, donc permettent un accès<br>
    aléatoire à tous les éléments du document<br>
  - ceux qui parsent un document de façon linéaire et qui donnent à<br>
    un 'handler' les éléments les uns après les autres<br>
<br>
bulk_upload utilise xml.etree qui est du premier type. Il faudrait donc<br>
utiliser un sax (classe xml.sax). L'inconvenient de sax est qu'il ne<br>
permet pas de recontruire un document xml à partir d'un nœud (comme le<br>
fait bulk_upload avec ET).<br>
<br>
Quitte à utiliser sax, autant réutiliser les bibliothèques de parsage et<br>
d'envoi vers l'api d'osmose, presque tout est fait. Je regarderai ça<br>
vendredi si personne ne l'a fait d'ici là. Le serveur de yoann étant hs<br>
(?) je ne peut pas donner de liens vers ces lib.<br>
<br>
--<br>
<font color="#888888">Etienne<br>
</font><p><font color="#500050">
_______________________________________________
Talk-fr mailing list
<a href="mailto:Talk-fr@openstreetmap.org">Talk-fr@openstreetmap.org</a>
http...</font></p></blockquote></p>