<div class="gmail_quote">2010/6/29 christophe t <span dir="ltr"><<a href="mailto:arbailles@gmail.com">arbailles@gmail.com</a>></span><br><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
Est-ce normal qu'il n'y aie pas qu'un seul changeset ? <br></blockquote><div><br>dans ton cas, oui<br> </div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
Y-a-t'il un changeset par lot lors de l'upload ?<br></blockquote><div><br>de mémoire, c'est configurable mais chez toi, le premier changeset s'est fermé parce qu'il avait atteint la taille limite des 50.000 edits.<br>
 <br></div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">

Les changeset apparaissent comme étant fermés alors que manifestement un au moins n'est pas allé au bout. Si quelqu'un peut m'éclairé sur ce fonctionnement. A quel moment a lieu le commit ?<br></blockquote><div>
<br>Le "commit" a lieu à la fin de chaque "lot" ou "chunk". Les changesets ne sont pas liés aux transactions de la bdd. C'est juste une entité logique pour regrouper des edits, en principe par thème.<br>
 </div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">J'ai à présent 2 solutions :<br>

- recharger la zone dans JOSM, merger mon fichier du bati et utiliser validator pour corriger<br>- faire un rollback et re-uploader de manière moins massive quartier par quartier<br><br>Je pencherais plutôt pour la seconde solution.<br>
<br></blockquote><div><br>Je pencherais plutot pour la premiere. Ton deuxième changeset ajoutait le bâti, ça veut dire que tu avais déjà créé 50.000 nodes dans le 1er changeset plus 2246 dans le 2e. Ca serait bête de faire un revert alors qu'il ne reste plus que quelques milliers de polygones et que les 52.000 nodes sont déjà là.  Maintenant, tout dépend aussi de la manière dont Validator va se charger des duplicatas. Pour les nodes, il y a une fonction automatique mais il faut espérer que la fonction de merge conserve le node qui existe déjà dans la base (sinon il risquerait d'effacer celui-ci pour en créer un neuf, ce qui fait deux transactions au lieu de zéro). Pour les polygones, ça risque d'être plus difficile, il faut trouver un moyen de régler le conflit des 4000 buildings déjà créés sinon à la main, tu ne t'en sortiras pas. C'est là où ça pourrait empêcher le choix 1. Si ça ne va pas, alors on pourra te faire ton revert même si c'est dommage parce que les 3/4 étaient déjà fait.<br>
<br>Pieren<br></div></div>