Re: [OSM-talk-fr] Rives d'une rivière non rendues : à l'aide !
Je confirme. Le polygone n’apparaissait pas J'ai tenté le F5, /dirty, attentes, qui d'habitude marchent bien. Mais là rien. C'est seulement après le mail d'Yves indiquant son déplacement de nœud que F5 a fait correctement apparaître la zone. Cordialement, Cedric ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Rives d'une rivière non rendues : à l'aide !
Je me demande si ce ne serait pas un bug sur les fichiers diff qui provoquerait ce genre de désynchronisation, ou bien un bug dans osm2pgsql... C'est quand même étonnant que pour retrouver le polygone correctement rendu il faille le modifier. -- Christian Quest - OpenStreetMap France Un nouveau serveur pour OSM... http://donate.osm.org/server2013/ ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Rives d'une rivière non rendues : à l'aide !
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@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Rives d'une rivière non rendues : à l'aide !
Bonjour, J'ai supprimé 2 chemins qui se superposaient à ton riverbank. http://www.openstreetmap.org/browse/changeset/17237117 Mais ça n'a pas eu grands effets... Cedric Le 06/08/2013 08:50, Hélène PETIT 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@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Rives d'une rivière non rendues : à l'aide !
Le 6 août 2013 à 08:50, Hélène PETIT h...@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. Bingo :-D J'ai juste déplacé un nœud. Je me suis bien arraché les cheveux avec ça car j'ai du le rencontré souvent. Je mettais le problème sur le compte de relations multipolygones défectueuses, mais en fait je devais bouger quelques nœuds au passage. J'avais aussi remarqué que le polygone était bien rendu sur la couche landscape de opencyclemap.org. Encore merci. -- Yves ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Rives d'une rivière non rendues : à l'aide !
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 h...@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@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Rives d'une rivière non rendues : à l'aide !
Non Philippe, il s'agit bien d'un bug du moteur de rendu. Autant être clair, inutile de tergiverser. Mais faire un /dirty moins de 10 minutes après la modification n'a généralement pas l'effet attendu. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Rives d'une rivière non rendues : à l'aide !
Pour l'instant je ne l'ai jamais observé (la tergiversation est de ne pas essayer cette solution simple et de dire qu'il suffit d'ajouter une pseudo-modification plus polluante qu'utile). Un /dirty, suivi de 10 minutes d'attente avant un rafraîchissement a toujours réglé le problème sur les mises à jour oubliées par un moteur de rendu (sauf celles concernant les lignes de côtes qui sont rarement à jour et inondent certaines îles ou mettent certaines baies hors d'eau), sauf sur Mapquest qui apparemment n'a pas ce système de signalement des rendus pas à jour (il se débrouille tout seul pour gérer ses priorités de mises à jour, ou sinon demande qu'on lui envoie un ticket). Mapquest tient la route toutefois, ses mises à jour sont assez régulières pour tenir compte des données saisies ou modifiées une semaine avant, pas besoin d'attendre des mois un hypothétique changement. Je n'ai d'ailleurs même pas vu d'anomalie lors du premier mail envoyé sur de fil de discussion, j'avais déjà un rendu correct sans que rien soit modifié dans la base. Le 6 août 2013 20:11, Hélène PETIT h...@free.fr a écrit : Non Philippe, il s'agit bien d'un bug du moteur de rendu. Autant être clair, inutile de tergiverser. Mais faire un /dirty moins de 10 minutes après la modification n'a généralement pas l'effet attendu. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
[OSM-talk-fr] Rives d'une rivière non rendues : à l'aide !
Bonjour,Ce "chemin"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é.Avez-vous une explication et un remède ?Merci d'avance,--Yves___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
