Un autre truc que ne fait toujours pas correctement JOSM c'est minimiser l'impact de ce qu'on doit faire en cas de conflits détectés lors des envois d'objets à modifier ou à supprimer: Comme OSM accepte des envois par lots, il peut y avoit de nombreux lots intermédiaires entre les objets vides à créer et leur utilisation dans d'autres objets. De fait on commence souvent par envoyer de gros lots de noeud vierges de tout tag qui ne seront utilisés que lors de l'envoi bien plus tard des chemins ou relations qui les utilisent.
Idéalement, on devrait tenter de réduire cet écart dans les lots envoyés en assurant de compléter intégralement et le plus vite possible (avant les autres) les objets qui utilisent les objets déjà envoyés. C'est d'autant plus critique que les créations d'objets (noeuds chemin ou relations) se font de façon très éloignée, et que ce n'est ensuite que lors des étapes d'envois d'objets créés plus tard ou pire ceux qui sont modifiés, que ces nouveaux objets vont être utilisés dans la base, et que ce n'est que lors des envois d'objets à modifier qu'on va détecter des conflits d'édition. Les premiers conflits d'éditions se produisent donc souvent très tard, alors qu'on a déjà envoyé beaucoup de nouveaux objets, et que cela complique sévèrement la récupération en cas de problème (conflit d'édition, ou même problème réseau interrompant la session en cours). Un tri topologique devrait donc toujours être réalisé afin que les envois de données vers la base OSM soient terminés le plus tôt possible dans un état cohérent. Sinon on se retrouve facilement avec la base laissant des tas d'objets inutilisés (et souvent même sans aucune balise quand il s'agit des noeuds qui se retrouvent orphelins). La gestion des erreurs et la facilitation des situations de récupération d'erreurs de dessions ou de conflits d'édition doit être pensé assez tôt, sinon la tâche qui incombe à l'utilisateur pour nettoyer ça prend un temps fou et est particulièrement complexe (même les outils poru faire un revert ont du mal à gérer les dépendances pour faire ça proprement). Pour des grosses modifs (contenant nécessairement plein de travaux de préparation, de fusion et d'intégration), les conflits d'édition sont inévitables, surtout dans des zones denses ou étendues. Là dessus les outils (pas seulement JOSM) peuvent encore et devraient s'améliorer sur la façon dont ils ordonnent les envois au serveur. Car on passe énormément plus de temps souvent à gérer les conflits d'édition (aevc un gros risque de commettre des erreurs pour les résoudre manuellement) Et ce n'est même pas plus facile non plus d'abandonner en cours et vouloir faire un revert complet (les reverts sont encore une affaire de spécialistes qui savent jongler avec les dépendances d'objets, sélectionner manuellement des sous-listes d'objets à envoyer d'abord avant les autres... alors qu'une machine ferait les choses bien plus facilement et plus proprement en procédant dans le bon ordre) . Le 22 décembre 2013 22:14, François Lacombe < [email protected]> a écrit : > Pas de soucis Christian. > > Le format OsmChange concerne l'appel changeset/#id/upload de l'API v0.6 > Normalement je vais essentiellement traiter des input JOSM mais je ne sais > pas ce qu'il utilise de l'API, je me contente d'implémenter le protocole en > entier. > > J'ai pas la même structure qu'OSM mais j'ai les mêmes primitives. > Du coup pas de soucis, seuls les nœuds sont porteurs des coordonnées chez > moi aussi. Nul besoin d'avoir la voie dans le fichier OsmChange si la liste > de ses membres n'est pas modifiée. > > Tout le travail consistait à traduire mes objets au format OSM et à bien > interpréter les documents en retour. > Après c'est du gâteau. > > > > *François Lacombe* > > francois dot lacombe At telecom-bretagne dot eu > http://www.infos-reseaux.com > > > Le 22 décembre 2013 22:07, Christian Quest <[email protected]> a > écrit : > >> Je ne sais pas quels fichiers osmChange tu vas traiter, mais pour les >> changeset issus des diff des serveurs OSM, il faut prendre en compte un >> truc important: tu peux avoir un changement sur un noeud qui impactera des >> ways sans que les ways ne figurent dans le changeset. Leur géométrie est >> modifiée, mais pas leur définition. >> Pareil pour les relations... >> >> C'est compréhensible sur le plan base de données relationnelle, ça l'est >> beaucoup moins pour une base de données géographiques. >> C'est ce qui fait toute la complexité d'osm2pgsql (et autres) sur la >> gestion des diffs... >> >> _______________________________________________ >> dev-fr mailing list >> [email protected] >> https://lists.openstreetmap.org/listinfo/dev-fr >> >> > > _______________________________________________ > dev-fr mailing list > [email protected] > https://lists.openstreetmap.org/listinfo/dev-fr > >
_______________________________________________ dev-fr mailing list [email protected] https://lists.openstreetmap.org/listinfo/dev-fr
