<div dir="ltr">Différentes raisons peuvent expliquer un changeset vide, même sans aucune erreur réseau.<div><br></div><div>Par exemple un utilisateur modifie ou supprime un chemin ou une relation et veut l'envoyer, ce sera la première transaction du changeset: il ouvre un changeset (qui est alors vide), puis envoie l'objet à modifier ou supprimer.</div>

<div><br></div><div>Et là le serveur détecte un conflit d'édition. L'utilisateur peut mettre des heures à gérer le conflit et réparer son envoi. Pendant ce temps-là, le changet n'aura toujours aucune transaction valide, et le serveur pourra même le fermer prématurément.</div>

<div><br></div><div>L'utilisateur peut aussi décider d'abandonner sa modif et ne rien faire d'autre que fermer le changeset (CTRL+ALT+Q dans JOSM), et jeter ses modifs en cours. Le changeset est là aussi fermé et reste vide.</div>

<div><br></div><div>Dans les deux cas, ce changeset vide reste dans le journal de l'utilisateur mais ne sert à personne, même pas à son auteur. Car même si l'auteur n'a pas abandonné ses données locales, s'il veut les envoyer après avoir résolu le conflit d'édition, il devra ouvrir un nouveau changeset (l'ancien a été fermé).</div>

<div><br></div><div>Un changeset peut rester vide et ouvert pendant assez longtemps avant que le serveur le ferme automatiquement (plusieurs heures ?). Ce n'est pas une anomalie donc d'avoir un changeset vide visible tant qu'il est ouvert, mais ça l'est si le changeset est fermé.</div>

<div><br></div><div>Le changeset étant lié à un utilisateur, si cet utilisateur est supprimé, cela ne peut pas se faire avec un changeset associé encore ouvert : ce changeset doit d'abord être fermé. Ce changeset peut alors être purgé (puisqu'il est vide), et l'utilisateur supprimé quand les autres changesets non vides de cet utilisateur ont été modifiés pour aller dans un compte utilisateur "poubelle" (là il faut lancer un processus de nettoyage comme pour le changement de licence, selon la validité des données associées qui restent dans la base, si leur licence était valide et si les données n'étaient pas abusives ou des déchets).</div>

<div><br></div><div>Le cas pourrait concerner des comptes utilisateurs bannis par le DWG, ou supprimés à la demande de l'utilisateur, quand les données bien que valides au plan de la licence pourraient être nuisibles à l'utilisateur sur sa vie privée ou celle des autres (imaginez qu'on trouve dans OSM des localisations précises des points de rassemblements LGBT en Russie ou en Iran, avec les dates et heures, ou listes de personnes attendues, ou leur numéros de téléphone, adresses mail, pages Facebook ou Twitter, ou des liens vers des documents compromettants, y compris des photos publiées par erreur ou mal anonymisées, etc. Imaginez aussi les liens nuisibles de type spam vers des sites redirecteurs, généralement on ne veut pas des "shortURL" anonymisées chez des fournisseurs qui n'ont aucun système de filtrage des abus).</div>

<div><br></div><div><br></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">Le 14 janvier 2014 06:49, Philippe Verdy <span dir="ltr"><<a href="mailto:verdy_p@wanadoo.fr" target="_blank">verdy_p@wanadoo.fr</a>></span> a écrit :<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">Le 12 janvier 2014 21:33, Pierre Béland <span dir="ltr"><<a href="mailto:pierzenh@yahoo.fr" target="_blank">pierzenh@yahoo.fr</a>></span> a écrit :<div class="im">

<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div style="font-size:10pt;font-family:HelveticaNeue,Helvetica Neue,Helvetica,Arial,Lucida Grande,sans-serif">Ce peut être un problème de communication entre ID et l'API. Mais de toute façon, il y a un problème d'enregistrement des informations par l'API. On ne devrait pas y enregister un  changeset sans transaction de données. Et encore moins avec un usager inexistant.</div>


</div></blockquote><div><br></div></div><div>Tous les changeset sont créés initialement vides avant qu'on y injecte des transactions dans des requêtes séparées.</div><div><br></div><div>Cependant les changesets sont ensuite autmatiquement fermés par le s'il n'y a plus d'autres transaction pendant un certain temps.</div>


<div><br></div><div>A ce moment-là (ou lorsque le changeset est fermé explicitement par une transaction "close"), s'il n'y a aucune transaction dedans, le serveur pourrait le supprimer aussitôt de la base (et aussi de l'historique de l'utilisateur, même s'il y a d'autres attributs comme un commentaire).</div>


<div><br></div></div></div></div>
</blockquote></div><br></div>