Le 25 juillet 2012 16:15, Vincent Privat <[email protected]> a écrit : > > Le 25 juillet 2012 09:53, Philippe Verdy <[email protected]> a écrit : > >> >> Le plugin de revert ne marche pas non plus > > > J'ai contacté Upliner (l'auteur du plugin) à ce sujet mais n'ai pas encore > eu de réponse. > Le ticket qui trace ce problème est ici: > http://josm.openstreetmap.de/ticket/7845 > >> >> (il y a encore des >> anomalies dans la gestion des noeuds supprimés dans JOSM, qui confonds >> les suppressions par un utilisateur avec celles par le bot de >> rédaction, j'obtiens encore des exceptions de pointeur nul même dans >> la dernière version de développement, car là cela touche uniquement à >> des relations supprimées sans aucun noeud ou chemin, ce qui est encore >> plus bizarre). > > > Peux-tu indiquer si les NPE surgissent dans le plugin reverter ou dans le > noyau JOSM ? > Si ce n'est pas dans le plugin, peux-tu réouvrir le ticket qui te semble > correspondre, ou en créer un nouveau ?
J'en ai des tonnes, qui souvent génèrent des conflits insollubles qui ne riment d'ailleurs à rien du tout. JOSM garde alors des tonnes de données obsolètes. Pour palier le problème ce que je fais c'est sauver le fichier OSM en cours (en ignorant les conflits détectés à tord), et je le recharge : le rechargement du fichier OSM fait d'avantage de tests et parvient à résoudre les données obsolètes et les nettoyer avant même de commencer à retravailler dessus, mais au moins on a résussi avant la sauvegarde du fichier à récupérer les historiques dans un état correct suffisant pour que le chargement n'échoue plus. lorsqu'on enverra les données on verra alors des tonnes de messages de suppression d'objets déjà supprimés dans la base, mais ce n'est pas méchant et sans conséquence. On arrive alors à se sortir des cas les plus difficiles comme ça. Mais travailler dans une seule session en chargeant des données à corriger même de façon mineure, ne permet pas de renvoyer les données correctement immédiatement. Des tests de cohérence avec les données supprimées, présentes dans les données par référence, sont encore manquants. Le validateur local intégré à OSM ne détecte pas tout et ne répare pas autant de chose que le chargement de données d'un fichier OSM. Il y a d'autres anomélies li"es aussi au travail sur plusieurs calques (ils ne sont pas synchronisés entre eux quand ils sont sensés partager des données communes. C'est assez frustrant (notamment dans le gestionnaire de conflits). Pourtant par sécurité je charge toujours des données dans un calque séparé, quitte à faire une fusion après avoir d'abord tenté une sauvegarde locale de ce calque (sinon on a des cas insolubles et on risque de perdre des tas de données en cours de modif mais pas encore envoyées au sereur car la cohérence impose d'en modifier d'autres qui ont leurs propres conflits avec les données plus anciennes des historiques où se mèlent objets effacés et objets modifiés par des attributs effacés et recréés depuis par quelqu'un d'autre). Vu que je travaille sur des fichiers OSM très volumineux (de l'ordre de 300 à 500 mégaoctets) pour faire des tonnes de tests de cohérence, sachant que ma connexion internet lente impose d'en stocker beaucoup en cache, je suis exposé au fait que nombre de ces données sont impactées par le bot de rédaction (souvent plusieurs fois dans des zones difficiles où le bot a tourné en plusieurs passes successives, parfois même pour restaurer des données qui n'auraient pas du être masquées). _______________________________________________ Talk-fr mailing list [email protected] http://lists.openstreetmap.org/listinfo/talk-fr
