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 <[email protected]> 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 <[email protected]> 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 ? >> _______________________________________________ Talk-fr mailing list [email protected] http://lists.openstreetmap.org/listinfo/talk-fr
