[OSM-talk-fr] JOSM : impossible d'envoyer les modifications

Philippe Verdy verdy_p at wanadoo.fr
Jeu 27 Mar 10:16:56 UTC 2014


En plus je ne sais pas d'où tu sors ton chiffre de "21 M" (milliers ?
millions ?)
Mon compteur est encore de 2815 "changesets" en totalité sur plusieurs
années. cela ne fait que 5 ou 6 par jour, indépendamment du volume
(certains sont réduis à 3 ou 4 objets, la moyenne est souvent autour de 400
objets, envoyés en un peu moins de 100 requêtes).

Je ne vois aucun intérêt à faire des requêtes de modifs volumineuses. J'en
ai fait l'amère expérience une fois avec le paramétrage par défaut de JOSM
et la récupération suite à une perte de session m'a coûté près de 3
semaines de travail pour vérifier des centaines de conflits avec mes
propres envois dont JOSM n'a pas reçu le statut de complétion. J'ai rié
pendant tout ce temps que mon PC ne soit pas obligé de rebooter suite à une
mise à jour automatique du système, de fait pendant tout ce temps j'ai du
couper les mises à jour système et aussi prié qu'il n'y ait pas de coupure
de courant car je ne pouvais strictement rien sauvegarder...

Si je ne met que 5 objets par envoi, la résolution de conflits est beaucoup
moins longue (et par suite engendre beaucoup moins d'erreurs manuelles lors
de la résolution avec l'éditeur de conflits). De fait je n'ai jamais plus à
gérer des listes de conflits de plusieurs centaines d'objets, sachant aussi
que JOSM ne sait toujours PAS sauvegarder un travail en cours avec l'état
des conflits en cours non résolus, en revanche il sait sauvegarder un
travail non complètement envoyé à condition qu'il n'y ait aucun conflit.

Le seul "intérêt" à grouper des centaines ou milliers d'objets dans une
même requête c'est de réduire le nombre de "roundtrip" mais cela ne change
rien à la charge totale du serveur qui au contraire doit tout traiteren un
seul gros batch, ce qui nécessite alors une longue attente et c'est là
qu'un "timeout" peut se produire au niveau du serveur front-end de l'API ou
d'un proxy.

Admettons qu'on passe de 500 à 5 objets par requête cela multiple par 100
le nombre de roundtrip, mais un roundtrip coute environ 60 millisecondes
pour tout le monde. Au total l'envoi durera seulement 6 secondes de plus...
C'est négligeable par rapport au temps passé pour préparer les modifs. Je
peux bien attendre 6 secondes de plus si ça m'évite ensuite de perdre des
heures ou des jours (et pendant tout ce temps là laisser les données sur le
serveur dans un état intermédiaire instable, que certains autres
utilisateurs vont tenter de corriger sans voir que le changeset n'est pas
finalisé, car le serveur va le fermer automatiquement au bout de 2 heures
avant qu'on ait fini de tout résoudre et tout envoyer : résultat, tout en
continuant à envoyer les données manquantes en résolvant les conflits un
par un on se retrouve à gérer de nouveaux conflits d'édition).



Le 27 mars 2014 10:13, François Lacombe <
francois.lacombe at telecom-bretagne.eu> a écrit :

>
> Le 27 mars 2014 01:42, Philippe Verdy <verdy_p at wanadoo.fr> a écrit :
>
> Ca arrive de temps en temps: problème de proxy du côté serveur qui perd sa
>> session prématurément.
>> Personnellement je n'envoie plu que 5 objets par requête et ça répond
>> correctement sur une connexion fibre. Et ça évite en fait pas mal de
>> problèmes. S'il y en a un c'est aussi lus facile de reprendre sans chercher
>> longtemps l'objet à resynchroniser
>>
>
> Je comprends mieux comment on en arrive à 21 M éditions !
>
> Personnellement j'envoie rarement moins de 1000 objets par requête et je
> n'ai jamais eu de problème...
> JOSM permet de sauvegarder ses couches de données, si sa ne passe pas à un
> moment, il est toujours possible de retenter ensuite.
>
>
> *François Lacombe*
>
> francois dot lacombe At telecom-bretagne dot eu
> http://www.infos-reseaux.com
>
-------------- section suivante --------------
Une pièce jointe HTML a été nettoyée...
URL: <http://lists.openstreetmap.org/pipermail/talk-fr/attachments/20140327/107dd905/attachment.htm>


Plus d'informations sur la liste de diffusion Talk-fr