J'ai un peu "tittillé" le passage à niveau en le recréant sur un nouveau nœud et supprimant l'ancien nœud, ça règle le problème du chemin parasite (les mises à jour de rendu sont en cours pour les niveaux de zoom plus bas). Au passage j'ai un peu amélioré la précision de placement de la ligne de chemin de fer.
Le 9 août 2018 à 23:28, Philippe Verdy <verd...@wanadoo.fr> a écrit : > La modif n'a pas d'effet sur le chemin parasite, il semble que le rendu > curieux soit lié au fait que le serveur de rendu a bien deux chemins mais > il n'en trouve qu'un correctement tagué dans sa base mais avec une > géométrie incomplète, et l'autre vient de la géométrie qu'il voit mais pas > tagué correctement. Un changeset est visiblement passé sur ce serveur, mais > visiblement pas au complet, il était peut-être tronqué quand il a été > chargé, et cela a laissé ces parasites avec des modifs incomplètement > chargées sur sa base esclave. > Je reste persuadé que c'est un problème de remise en route des serveurs > migré de Londres à Amsterdam: suite à l'arrêt il a du manquer certains > diffs ou des diffs incomplets ou un problème d'espace disque ou d'espace > temporaire saturé (suite aux scripts de migration) ou de connectivité > temporaire (erreurs de caches DNS par exemple) a pu causer ce bogue. On > voit ces bogues à divers endroits, tous autour des modifications effectuées > durant une seule heure environ. > > La désynchronisation des "diffs" semble bien la bonne piste. Cela est déjà > arrivé aussi sur les serveurs de rendu d'OSM France et chaque fois il a > fallu repartir en chargeant un dump complet postérieur aux problèmes de > diffs constatés puis rechargeant les autres nouveaux diffs émis depuis ce > dump. > > En terme de tags je ne vois pas de problème, et les rendus d'OSM France ou > Allemagne ou Mapquest ne sont pas impactés ici (mais eux n'ont pas changé > d'hébergement et de config réseau pendant ce temps). De toute façon comme > le bogue est connu et signalé, OSM.org trouvera bien une solution (quitte à > arrêter deux de ses 4 serveurs de rendu et avoir un peu plus de "lag" > pendant ce temps là, le temps de recharger leur base). > > En tout cas une chose est sure, cela ne vient pas des caches de tuiles > (sur les 21 sites du CDN d'OSM.org) : ils sont bien à jour et pas en retard. > > > Le 9 août 2018 à 22:46, <osm.sanspourr...@spamgourmet.com> a écrit : > >> Le 09/08/2018 à 19:09, marc marc - marc_marc_...@hotmail.com a écrit : >> >> si tu regardes le point qui a visuelement un >> problèmehttps://www.openstreetmap.org/node/252291030 >> il ne fait plus partie que d'un rail. donc problèe entre temps résolu >> et lag dans la maj du rendu (il y a un bug majeur sur 2 serveur de rendu >> osm.org) >> >> Ça fait 9 mois que baleineaux >> <https://www.openstreetmap.org/user/baleineaux> l'a mis comme >> level_crossing d'un seul éléments ferré et d'un non ferré. >> Et 12 jours qu'il a mis à jour la liaison https://www.openstreetmap.org/ >> way/262550757#map=12/47.5247/-3.0738&layers=H >> >> Je vois que Philippe a titillé le chemin en lui mettant sa référence (et >> en supposant une vitesse de 80 km/h). >> La référence est bien affichée mais au niveau 18 on a un curieux rendu : >> https://www.openstreetmap.org/query?lat=47.67901&lon=-3.0216 >> 7#map=18/47.67904/-3.02191 >> >> https://a.tile.openstreetmap.org/18/128871/91473.png >> [image: https://a.tile.openstreetmap.org/18/128871/91473.png] >> Sachant que le railway va de part et d'autre du PAN... >> >> N.B. : le décalage horaire ne me semble pas une bonne piste. >> Jean-Yvon >> >> _______________________________________________ >> 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
