[OSM-talk-fr] Revert de changesets pour vandalisme ?

[Philippe Verdy]

Le 25 juillet 2012 16:15, Vincent Privat <vincent.privat at gmail.com> a écrit :
>
> Le 25 juillet 2012 09:53, Philippe Verdy <verdy_p at wanadoo.fr> 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).