Et visiblement elle impacte aussi la disponibilité de nombreuses tuiles du rendu OSM FR (pas de réponse du serveur), même en version ancienne (visiblement elles ne sont pas en cache).
C'est un problème pour ceux qui utulisent le rendu OSM OFR comme image de fond semitransparente associée à une imagerie aérienne pour travailler sur des zones étendues et zoomer sur certains détails à télécharger (on ne peut pas toujours charger la totalité d'une zone, on zoome sur certaines zones d'intérêt et on essay de charger le minimum pour ne pas déborder en mémoire, ou rendre l'éditeur très poussif). On a toujours les rendus OSM.org et Mapquest, mais ils affichent beaucoup moins précisément les détails locaux pour repérer des modifs à faire, ce qui oblige à charger des zones pus grandes que nécessaire. ---- Noter aussi que sur JOSM, si on fait de la place en mémoire après avoir chargé un peu trop de données, avec la commande "Fichier>Purger", on aboutit souvent à des bogues de désynchronisation de versions d'objets impossibles à resynchroniser, même en forçant le rechargement des objets. Le symptôme se voit lors de la tentative d'envoi des données modifiées avec une erreur "NO DATASET, où les données en mémoire renseignent une version précédente alors que c'est bien la nouvelle version qui est en mémoire, la version précédente ayant été purgée mais étant impossible à recharger, la commande purge crée onc dans certains cas des conflits avecnos propre modifs déjà partiellement envoyées, et qui sont purgées alors qu'elles sont encore dépendantes; en général cela se produits quand n a purgé des chemins référencés par une relation, et que certains points du chemin ont été conservés car référencés par un chemin qui, lui, n'a pas été purgé et a déjà changé de version: la purge se pante dans les numéros de version à garder en mémoire, elle garde des versions qui ne sont plus lié à aucun dataset. L'impact est alors qu'on a beaucoup trop de données en mémoire pour des modifs longues et complexes (avec des dépendances complexes entre objets, et parfois même des dépendances cycliques pour certaines relations), à cause de l'obligation de charger des zones plus grandes que nécessaire. J'ai d"ailleurs l'impression que ce bogue de purge survient justement dans ces relations à dépendance cyclique (qui existent bel et bien dans la base : ces dépendances cycliques ont provoqué dans le passé des plantages de JOSM dans la passé lors du simple rendu de la carte, avant qu'un patch soit appliqué qui évite de parcourir une même relation à l'infini en boucle avec un débordement de pile, et saturation mémoire, qui proquait même un plantage complet de l'UI sous Windows pouvant même bloquer les autres applications par une utilisation brutale massive de ressources graphiques. Ce bogue des références cycliques est corrigé depuis longtemps pour le rendu local de JOSM dans son UI, mais visiblement semble encore affecter la commande "Purge") Le 29 juillet 2014 14:09, Jocelyn Jaubert <jocelyn.jaub...@gmail.com> a écrit : > Bonjour, > > Suite à des nodes incorrects dans la base de donnée utilisée pour générer > les > diffs de http://download.openstreetmap.fr, j'ai ré-importé hier soir, et > les > diffs depuis le 24 juillet sont en cours de re-génération. > > L'état actuel peut être suivi ici: > > http://munin.openstreetmap.fr/osm12.free.org/osm108.openstreetmap.fr/osm_replication_lag_osmbin.html > > En théorie, tout devrait être à jour dans la semaine. > > > Cette mise en pause des diffs impacte aussi l'api oapi-fr.openstreetmap.fr > , > la base de donnée osmosis France maintenue sur osm110, et les extracts > disponibles sur http://download.openstreetmap.fr. > > -- > Jocelyn > > _______________________________________________ > 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
