[OSM-talk-fr] Rives d'une rivière non rendues : à l'aide !

[Philippe Verdy]

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.

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.

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).

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).

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.

----

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.

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) !

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).


Le 6 août 2013 08:50, Hélène PETIT <hpmt at free.fr> a écrit :

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