En gros donc c'est le processus de génération des "minute diffs" sur la base principale qui a un problème (initialement rejeté à tord comme "wontfix" car les admins d'OSM sur la base principale ont cru que c'était un problème des logiciels tiers utilisant les "minute diffs"). Il arrive parfois que le processus qui génère ces "minute diffs" soit redémarré et ne reprenne pas corectement l'état dans lequel il était et vienne alors écraser un fichier diff précédent pour le remplacer par un autre contenant plus de données ou des données différentes. Selon le moment où un service tiers (une instance Overpass par exemple) interroge les diffs, il peut donc récupérer une version ou une autre d'un de ces fichiers et n'a aucun moyen de savoir si c'est la bonne version, si la première version a déjà été traitée, les fichiers diffs suivants seront en revanche basés sur la deuxième version plus complète, et peuvent alors être rejetés comme invalides (contenant des références à des objets inexistants car ils n'étaient que dans la deuxième version du premier fichier qui a écrasé la 1re version sur la base principale). On peut donc avoir des cas de "trous de mémoire" sur certaines bases tierces, et on ne s'en aperçoit plus tard que parce que d'autres diffs paraitront inconsistants, essentiellement s'ils dont référence à de nouveaux objets qui n'ont pas été inclus dans une première version écrasée d'un vieux diff.
Je ne vois pas de moyen simple pour les service tiers de corriger ça autrement qu'en tentant de remonter les diffs traités les uns après les autres jusqu'à trouver une diférence dans un des diffs par rapport à ceux présents sur le serveur principal: * pour éviter d'avoir à télécharger tous les fichiers diffs et les analyser les uns après les autres, il serait peut-être plus simple que le serveur des fichiers diffs tienne un index de ces fichiers (groupés toutes les heures par exemple, ou par bloc d'un millier de fichiers) contenant les empreinte (SHA1) de leur contenu, au cas où l'un d'eux aurait été regénéré dans une version ultérieure. * ensuite les services tiers pourraient comparer avec leurs propres listes d'empreintes afin de savoir depuis quel diff il y a eu une désynchronisation. Si on n'a pas ça, le seule moyen alors est de passer par la très lourde procédure de rechargement d'un dump monde (qui prends plusieurs jours même pour les meilleurs serveurs les plus puissants, y compris ceux de Mapbox), ou d'avoir sur le serveur un système qui fait des requêtes aléatoires et continues à la base principale pour tenter de détecter des oublis dans les diffs. Il est d'ailleurs probable que Mapbox ne fasse rien du tout Pour régler le problème sans repasser par la demande lourde de rechargement d'un dump, on pourrait effectuer sur la base principale une modif mineure des objets qui manquent pour que ceux-ci réapparaissent dans les diffs suivants : là les diffs reçus seront vus comme incohérents (modification reçue les concernant alors qu'on n'a pas "vu" leur création) : cette incohérence constatée devrait alors être suivie par une requête pleine effectuée par le serveur tiers à la base principale pour relire l'état de l'objet manquant, en dehors des diffs désynchronisés reçus. Les minutes diffs ont donc un problème de fiabilité non réglé concernant leur génération sur le serveur principal, mais les solutions à ça ne sont pas simples à régler pour les services tiers si cela dépend du moment où chacun d'eux vient les interroger (on l'a vu, l'instance overpass allemande a été impactée par cette incohérence, pas l'instance française qui a pris uniquement la seconde génération du même fichier diff, les deux versions ayant pourtant eu un contenu correct et cohérent, mais avec une version moins complète que l'autre entrainant des incohérences dasn les diffs suivants!) Le 4 mai 2015 23:02, sly (sylvain letuffe) <lis...@letuffe.org> a écrit : > Le lundi 4 mai 2015 20:55:22, Augustin Doury a écrit : > > A voir d'ici quelques jours, si quelqu'un a une explication, top. > > Bonne soirée > > Pour information, l'explication en rapide ici (en anglais): > http://wiki.openstreetmap.org/wiki/Overpass_API/status > et en détail là : (en anglais): > https://github.com/drolbr/Overpass-API/issues/210 > > En rapide, aucune des modifications survenues entre > 2015-04-30 12:43 et 2015-04-30 13:36 UTC > ne sont présentes dans la base Overpass de http://overpass-api.de > > Un nouveau serveur est prévu et donc l'admin attend le remplacement de > l'actuel par le nouveau, ce qui corrigera le problème. > > L'instance sur http://api.openstreetmap.fr/oapi/ > a été corrigée par mes soins la nuit dernière et devrait contenir ce que > l'autre n'a pas. > > -- > sly (sylvain letuffe) > http://wiki.openstreetmap.org/wiki/User:Sletuffe > > _______________________________________________ > Talk-fr mailing list > Talk-fr@openstreetmap.org > https://lists.openstreetmap.org/listinfo/talk-fr >
_______________________________________________ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
