[OSM-talk-fr] Utilisation de bulk_upload & bulk_upload_sax

Vincent Pottier vpottier at gmail.com
Mar 21 Sep 12:10:55 UTC 2010


On 21/09/2010 13:00, Benoît ROUSSEAU wrote:
>
> Je veux bien mettre en accusation JOSM, BULK_UPLOAD et d'autres 
> clients API si on me prouve qu'effectivement il ne respectent pas 
> l'API, les protocoles, ... Cela devrait être faisable par des 
> programmeurs dans ces langages, étant donné qu'ils sont open-source.
Quoi qu'il en soit du respect des protocoles, je trouve JOSM peu clair 
au moment de la transaction ou de son échec.
Il me semble que dans des versions précédentes de JOSM (il y a 6 mois 
environ), lors d'un upload par paquet, les objets en local étaient mis à 
jour paquet par paquet (id et statut), ce qui, me sembl-t-il n'est plus 
le cas. Lors d'un upload de 20 paquets, si la transaction est 
interrompue (volontairement ou non) au 10e, j'ai l'impression que les 9 
paquets envoyés ne sont pas mis à jour dans JSOM, ce qui fait qu'une 
relance de la transaction renvoie les nouveaux objets en double.
Mais, bon, je n'ai pas de certitude...
>
> Sommes nous sûr que la bases, le matériel, ... côté serveur tiennent 
> la charge à tout moment ? A ton testé, prouvé, ... ? Peux t-on 
> reproduire ces pb sur des serveurs "perso" ? Peux t'on répéter 
> exactement et à coup sûr ces pbs ? Si on refait un import "merdé" a 
> t'on les mêmes pbs ? ...
Il y a eu, fin août début septembre, une fatigue perceptible du serveur 
API. Il y a eu quelques allusions sur cette ML.
Peut-être que certains problèmes évoqués datent de cette période.
>
> Ces investigations et/ou des essais pourraient très bien être menés en 
> coordination avec l'équipe OSM en charge des serveurs en attaquant la 
> vraie base avec des objets générés sur des zones de "tirs" (pourquoi 
> pas les champs de tirs militaires inscrits dans la base), ...
>
> Dans un premier temps, Émilie, pourrais-tu nous obtenir l'avis de 
> l'équipe qui gère les serveurs sur l'origine possible ou avérée de 
> tous ces doublons d'après eux ?
Quelles sont les orientations pour l'API 0.7 ?
Est-ce qu'un upload asynchrone est envisagé : demande d'un jeton 
~changeset id, envoi des paquets, réception des statut de paquets, envoi 
de la commande EXECUTE, réception du résultat.
Ce type de protocole diminuerait considérablement les erreurs rencontrées.
--
FrViPofm
-------------- section suivante --------------
Une pièce jointe HTML a été nettoyée...
URL: <http://lists.openstreetmap.org/pipermail/talk-fr/attachments/20100921/4ae09448/attachment.htm>


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