<div dir="ltr">Souvent il n'y a besoin de rien faire du tout : la carte affiche un ancien rendu et n'a pas été redessinée. On peut faire un coup de "/dirty" pour forcer un recalcul tenant compte du changement.<div>

<br></div><div>Mais faire un "/dirty" moins de 10 minutes après la modification n'a généralement pas l'effet attendu: la carte est redessinée sans que les données modifiées soient encore en base. Quand les données arrivent moins de 10 minutes après, la carte ne sera pas redessinée non plus automatiquement, c'est remis à faire seulement plus tard, quand il y aura une autre demande, ou un autre changement.</div>

<div><br></div><div>En fin de compte, même s'il y a une nouvelle demande, cela pourrait n'afficher que ce qui est dans le cache du frontal proxy, le serveur de rendu ne verra pas la demande si le cache n'a pas été invalidé. Même en invalidant le cache, si le moteur de rendu est surchargé, ce qui est dedans sera malgré tout envoyé en réponse à la demande, pour ne pas la faire attendre plus que nécessaire (et tant pis si cette image n'est pas à jour).</div>

<div><br></div><div>Dans ce cas-là encore un "/dirty" peut forcer le serveur de rendu à voir qu'il a une nouvelle tâche à faire pour rafraichir un carreau. Mais il faut malgré tout rafraîchir l'affichage après quelques minutes, car les premiers rafraîchissements dans la minute après un "/dirty" téléchargeronnt encore l'ancien rendu tant que le nouveau rendu n'a pas remplacé l'ancien. Le "/dirty" ne fait qu'inscrire le carreau en dernière place dans la file d'attente du moteur de rendu (cette file d'attente a une capacité limitée, si elle est déjà pleine, il est possible que rien ne se passe).</div>

<div><br></div><div>Les clients qui téléchargent une carte ne sont mis en attente que si rien n'est disponible dans le proxy cache côté serveur (qui se purge tout seul en fontion des trafics concurrents) et que si le serveur de rendu voit qu'il n'a pas de rendu précalculé pouvant répondre à la demande, et si le serveur n'a pas invalidé son rendu par un /dirty présent dans sa file d'attente. Le serveur doit en effet limiter la durer des transactions client, sinon il risquerait de tomber à court de sessions (chaque connexion HTTP consomme un port, et le frontal proxy web ne peut former un nombre infini de session au serveur de rendu, s'il y a mise en attente du client c'est uniquement du côté du proxy et non du serveur, et seulement si le proxy n'a rien dans son cache pour répondre à la demande.</div>

<div><br></div><div>----</div><div><br></div><div>Dans certains cas, si le proxy lui-même n'a plus assez de ports disponible du côté web pour mettre le client en attente, il peut interrompre la session du client au bout de 2 minutes d'attente (ou moins selon les réglages internes du proxy ou selon sa charge du côté internet) et on obtient une erreur proxy HTTP 500 : le client n'aura rien et devra afficher le rendu de la carte plus tard.</div>

<div><br></div><div>Certains moteurs de rendu ne retournent pas d'erreur HTTP 500 mais affichent une image par défaut avec un statut normal HTTP 200 (avec un message dessiné dans le rendu indiquant que le serveur est surchargé et demandant qu'on lui achète un SSD...), une TRES mauvaise solution à mon avis car cela invalide le cache du client pour remplacer le contenu ancien encore partiellement utilisable par un contenu complètement faux qui va polluer le cache du client, et obliger le client à purger son cache complètement et puis à générer à nouveau un trafic important vers le serveur (quand le client ensuite demande à recharger sa page) !</div>

<div><br></div><div>Donc en fin de compte, il ne sert souvent à rien de faire une pseudo-modif (comme un microdéplacement de noeud, ou l'ajout d'un noeud au milieu d'un segment rectiligne) ; si on le fait, cela devrait être pour améliorer un peu la précision géométrique d'un tracé (tous les moteurs de rendu couvrant la zone seront impactés par le changement, mais ils ne feront normalement rien immédiatement, tant qu'on ne leur demande pas le rendu correspondant).</div>

</div><div class="gmail_extra"><br><br><div class="gmail_quote">Le 6 août 2013 08:50, Hélène PETIT <span dir="ltr"><<a href="mailto:hpmt@free.fr" target="_blank">hpmt@free.fr</a>></span> a écrit :<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

C'est un "petit" bug qui se manifeste de temps en temps**.<br>
Quand on regarde le même endroit avec la "carte cyclable", c'est<br>
correct. Il s'agit donc d'un bug du moteur de rendu.<br>
Jusqu'ici il nous a suffit de faire une minuscule modif du chemin (ce<br>
qui oblige le moteur de rendu à refaire ses calculs) pour le voir<br>
réapparaître.<br>
<br>
dis-nous si ça a  marché pour toi.<br>
<br>
Hélène<br>
**<br>
<a href="http://lists.openstreetmap.org/pipermail/talk-fr/2011-March/030960.html" target="_blank">http://lists.openstreetmap.org/pipermail/talk-fr/2011-March/030960.html</a><br>
<br>
<br>
<br>
<br>
Le 06/08/2013 07:53, Yves Pratter a écrit :<br>
> Bonjour,<br>
><br>
> Ce "chemin <<a href="http://www.openstreetmap.org/browse/way/204018203" target="_blank">http://www.openstreetmap.org/browse/way/204018203</a>>" situé à<br>
<div class="im">> coté de l'épanchoir de Gailhousty n'est pas affiché ni dans la couche<br>
> osm standard, ni dans OpenRiverBoatMap.<br>
> J'ai vérifié visuellement et avec JOSM, il semble pourtant bien fermé.<br>
<br>
<br>
</div>_______________________________________________<br>
Talk-fr mailing list<br>
<a href="mailto:Talk-fr@openstreetmap.org">Talk-fr@openstreetmap.org</a><br>
<a href="http://lists.openstreetmap.org/listinfo/talk-fr" target="_blank">http://lists.openstreetmap.org/listinfo/talk-fr</a><br>
</blockquote></div><br></div>