L'API pourrait effectivement faire un petit peu plus de contrôle avant de passer ça à la base de données.
Les contrôles auxquels j'ai pensé : - ce way comporte-t-il au moins 2 noeuds... différents - ce way repasse-t-il par le même noeud (sauf noeud identique en début et fin) - existe-t-il un noeud aux même coordonnées que celui que l'on veut créer (ou modifier d'ailleurs) Les deux premiers contrôles ne nécessitent aucun appel à la bdd, c'est juste du code ruby à rajouter. Le troisième nécessite d'interroger la base... Le 31 août 2012 16:41, Stéphane Péneau <stephane.pen...@wanadoo.fr> a écrit : > Merci pour ces infos, j'y vois un peu plus clair. > > Effectivement, peut-être que Josm pourrait gérer ces cas un peu mieux, mais > je me dis, peut-être à tord, que le serveur aussi pourrait faire quelque > chose s'il reçoit à la suite d'un changeset non fermé, un nouveau changeset > sur la même zone, avec des points à des coordonnées identiques. > > La première fois que ce genre de mésaventure m'est arrivé, c'était suite à > une coupure de courant pendant un upload. Il n'y a pas eu de souci du côté > de l'ordi puisque c'était un portable, mais j'ai bien évidemment perdu la > connexion à internet le temps que la box se resynchronise. J'ai bêtement > pensé que l'upload reprendrait son cours là où il s'était arrêté, ou au > pire, reprendrait depuis le début. > Erreur !! > > Et comme il s'agissait de mon premier import du cadastre, j'ai eu quelques > sueurs froides, et passé pas mal de temps à tout nettoyer. > > Stéphane > > > Le 31/08/2012 16:05, Pieren a écrit : > >> 2012/8/31 Vincent Privat <vincent.pri...@gmail.com>: >>> >>> A la question "pourquoi" c'est facile, les changesets ne sont pas >>> atomiques: >>> http://wiki.openstreetmap.org/wiki/API_v0.6#Changesets_2 >> >> Euh, En fait, ça ne répond pas à la question. Un changeset n'est pas >> une transaction. C'est vrai que ça n'est pas atomique. Mais chaque PUT >> vers le serveur est atomique. Ce qui manque, ce sont des commit en >> double phases (2PC) ou autres techniques pour la création de nouveaux >> objets (pour les updates, il y a l' "optimistic lock" qui gère les >> éventuels conflits de versions). >> >> Sans entrer dans les détails, le protocole entre ta machine et le >> serveur OSM est ultra-simple. Ce problème de dupplication ne peut >> arriver que pour de nouveaux éléments ajoutés dans ton éditeur : >> lorsque tu crées un nouvel noeud par exemple, JOSM lui assigne un ID >> négatif temporaire (l'OSM_ID, c.a.d un numéro identifiant unique pour >> chaque élément dans la base). Quand tu fais "upload", il envoie un >> message vers le seveur avec cet ID négatif (que le serveur ignore >> superbement) et reçoit en retour un message du serveur qui donne >> l'OSM-ID officiel dans la base de données. Quand tout se passe bien, >> JOSM continue de fonctionner avec l'ID officiel. Si ça se passe mal, >> c'est soit que la réponse du serveur est trop tardive, ou que >> l'utlisateur a interrompu l'upload (abort, cancel) ou que un truc >> s'est mal passé à l'intérieur du serveur OSM (c'est alors un bug, >> heureusement, ça arrive de moins en moins souvent). JOSM conserve >> alors l'ID négatif temporaire pour ce noeud puisqu'il n'a pas reçu la >> réponse correcte du serveur. Si tu relances l'upload, JOSM considère >> que ce noeud est encore nouveau et répète le même message de création >> vers la base. C'est comme ça qu'on peut se retrouver avec deux ou >> trois fois le même élément dans la base. >> Pour éviter ce genre de désagréments, il faut faire un download quand >> l'upload se passe mal. Comme ça, on voit ce qui est effectivement dans >> la base de données. En lançant une vérification avec Validator, on >> détectera les noeuds et ways superposés (mais peut-être pas les >> nouvelles relations). Bien sûr, ce que je viens de dire pourrait aussi >> être fait automatiquement par JOSM. Ca viendra peut-être un jour. >> >> >> 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 -- Christian Quest - OpenStreetMap France - http://openstreetmap.fr/u/cquest _______________________________________________ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
