Rawdit n'a rien à voir dans l'histoire. Je ne parlais bien QUE des envois depuis JOSM qui concernaient tout autre chose. rawedit est utilisé via Osmose mais PAS pour la création d'objets et uniquement pour des corrections mineures. Oui rawedit ne ferme pas son changeset, mais il n'a rien à voir avec le porblème que j'ai eu évoqué ci-dessus et qui était la création ou la modification d'objets dans JOSM. Il m'arrive d'utiliser les 2 en même temps mais jamais sur les mêmes objets. Les changeset restés ouverts dont je parlais sont bel et bien ceux créés par JOSM, avec leur commentaire à l'ouverture. Et c'est bien là qu'était le problème. Et que ces changesets soient créés par rawedit ou par JOSM ne change pas le fait que les uns comm les autres soient affichés avec un mélange entre heure d'été et heure d'hiver dans le site web d'OSM.org. Bref, merci de ne pas tout mélanger, je n'ai jamais évoqué rawedit, jusqu'ici.
Oui je sais très bien que le serveur fermera automatiquement les changesets restés ouverts au bout d'une heure. Mais cela n'explique toutefois pas pourquoi l'objet de certains objets dans un changeset aboutit à des bloquages complets du serveur qui cesse de répondre immédiatement après la création du changeset dans JOSM. Le changeset reste ouvert et après l'erreur du serveur (qui prends plusieurs minutes avant de retourner une erreur "connection reset" où le serveur ferme la session HTTP sans aucune réponse, ou bien juste avec une réponse HTTP 500), JOSM fermant alors seulement sa fenêtre d'envoi de données (sans avertir l'utilisateur de l'erreur survenue, le détail on ne l'a que dans la console Java si elle est ouverte et qui affiche un log de l'exception Java qui a eu lieu) mais pouvant malgré tout continuer à utiliser le changeset sans en créer un autre pour autant (sauf si on le ferme explicitement avec CTRL+ALT+Q), pour qu'on puisse y envoyer un partie des données qui sont encore restés à l'état "modified". Je ne sais pas si ce que je dis est assez clair. Mais il y a bien un problème côté serveur pour l'envoi de certains objets. En tentant de les envoyer un par un (je lance dans JOSM une rechercher CTRL+F, avec "modified", dans la liste sélectionnée je choisis un objet et j'essaye de l'envoyer isolément dans le changeset en cours. Selon les cas, cela marche immédiatement, et dans d'autres le serveur ne répond pas du tout et ferme la session HTTP brutalement sans répondre ou en répondant avec une erreur HTTP 500, et le changset est encore ouvert sur le serveur). Il n'y a strictement aucun critère qui permet de savoir quand le serveur va répondre ou s'il s'enferme dans ce qui semble être une récursion infinie, la nature des données n'y faisant strictement rien (cela peut être un unique nouveau noeud sans attribut, un unique chemin modifié pour inclure ce noeud, une nouvelle relation simple ou une relation modifiée dans un tag sans changer aucun de ses membres, ou un membre ajouté ou retiré/fusionné. Dans certains cas je n'ai pas eu le choix de faire autrement que de demander la suppression de l'objet existant bloquant tout (toute modification était impossible, aucune réponse du serveur) pour le recréer strictement à l'identique (avec une réponse immédiate et avec succès du serveur). Bref le problème touche certains objets de la base, sans critère déterminant. Et je pense que l'anomalie est du côté du serveur SQL lui-même (qui cesse totalement de répondre à certaines requêtes demandée via un front-end), et non dans aucun des front-ends (la DB API, que ce soit celle d'OSM ou l'API FR, ou bien le site web OSM.org dans ses affichages). Je soupçonne un index de table SQL défaillant/corrompu lors des mises à jour. Le 2 avril 2013 16:18, Pieren <pier...@gmail.com> a écrit : > Le seul problème, c'est que tu utilises RawEdit qui ne ferme pas les > changesets. Et tous les changesets qui ne sont pas fermés par le client le > sont automatiquement par le serveur au bout d'une heure d'inactivité (ce qui > est extrapolé sur la page web des changesets lorsqu'ils sont encore > ouverts). Rien à voir avec le changement d'horaire été/hiver. Comme > d'habitude, tu racontes un peu n'importe quoi. > > Pieren > > _______________________________________________ > Talk-fr mailing list > Talk-fr@openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk-fr > _______________________________________________ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
