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

[Philippe Verdy]

Je note que les contributions de l'utilisateur polonais qui avait
explicitement accepté la licence (mais pas les CT) ont été restaurées
et sont de nouveau visibles. Certes il ne peut plus contribuer, mais
ses données sont là à nouveau.

Je note aussi que JOSM les voit bien, comme aussi l'application web du
site officiel qui les réaffiche dans l'historique (en même temps que
toutes les modifications ultérieures sur ces objets "effacés"/"rédigés
invisibles" à tord), mais pas l'API utilisée par Layers qui les
considère encore comme effacées. Layers est donc désynchronisé et ne
prend pas en compte les données qui sont redevenues visibles.

Le bot est visiblement en train de restaurer des données en tenant
compte des licences et plus seulement des CT comme il n'a fait jusqu'à
présent.

L'état des logs du bot est un peu corrompu car s'y mélange des données
provenant du traitement de zones (de 1 degré de côté) différentes (ce
sont les cases rouges visibles sur la carte). Mais je me demande où
sont les logs de restauration de données.

Le 25 juillet 2012 20:12, Philippe Verdy <verdy_p at wanadoo.fr> a écrit :
> J'en ai eu hier, mais entre temps c'est vrai que la version de
> développement a été remise à jour aujourd'hui. Je ne peux pas la
> reproduire car les données sur lesquelels cela portait ont depuis été
> mises à jour. Mais je sais que cela va se reproduire, car cela ne
> correspond à aucun des bogues référencés.
> Mes gros fichiers OSM passent pour l'instant tant que je ne tombe pas
> sur une mise à jour qui les invalidera (car je n'ai pas pu mettre à
> jour la totalité pour l'instant, étant donné que je teste les zones
> signalées comme modifiées par le Bot de rédaction).
>
> Le moment venu je reposterai. Les bogues ne sont pas des anomalies NPE
> mais des impossibilités de résoudre des conflits inexistants. Pour
> l'instnat sauver le fichier malgré les conflits ignorés et le
> recharger tel quel suffit à passer outre. (j'ai vérifié que cela
> n'entrainait pas de modifs supplémentaires, hormi l'envoi d'objets "à
> supprimer" qui le sont déjà dans la base). Ca ralentit le process mais
> c'est contournable pour l'instant et ne génère pas de conflit.
>
> Il me faut juste 5 minutes pour enregistrer le fichier OSM, fermer
> JOSM et le relancer pour recharger le fichier en cours (la console
> Java affiche des tas d'anomalies d'objets référencés mais supprimés
> lors du chargement du fichier : noeuds supprimés encore dans un way,
> et que le chargement élimine tout seul du way, ou objets
> supprimés/inexistants pourtant référencés comme membres d'une relation
> (alors que la relation a pourtant bien été mise à jour par
> l'interface, elle conserve ces références parasites lors de la mise à
> jour).
>
> Cela se produit encore avec la version de dév numéro 5361 qui est
> chargée en ce moment.
>
> Le 25 juillet 2012 18:58, Vincent Privat <vincent.privat at gmail.com> a écrit :
>> Tu n'as pas répondu à ma question. Je ne pense pas qu'il y ait des tonnes de
>> NPE différentes qui surviennent mais plutôt qu'une ou 2 reviennent très
>> régulièrement.
>> Peux-tu m'en indiquer quelques-unes s'il te plaît ?
>>