[OSM-talk-fr] Ré-import de la base de génération des diffs, et mise en pause des diffs

[Philippe Verdy]

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.jaubert at 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 at openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>
-------------- section suivante --------------
Une pièce jointe HTML a été nettoyée...
URL: <http://lists.openstreetmap.org/pipermail/talk-fr/attachments/20140730/f412b9ec/attachment.htm>