En fouillant un peu mieux, je constate en fait l'inverse : c'est l'affichage de la tuile dans un onglet séparé qui effectue la requête HTTP la plus riche :
Request URL:http://a.layers.openstreetmap.fr/voirie-cadastre/7/67/44.png Request Method:GET Entêtes : GET /voirie-cadastre/7/63/45.png HTTP/1.1 Host: b.layers.openstreetmap.fr Connection: keep-alive Cache-Control: max-age=0 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.4 (KHTML, like Gecko) Chrome/22.0.1229.94 Safari/537.4 Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 Referer: http://layers.openstreetmap.fr/?zoom=7&lat=46.88444&lon=-1.68743&layers=B00FFFFFFFFFFFFFFFFFFT Accept-Encoding: gzip,deflate,sdch Accept-Language: fr,en-US;q=0.8,en;q=0.6 Accept-Charset: UTF-8,*;q=0.5 DNT: 1 If-None-Match: "4ceeff3b43fdaeca2ff3ff59c6510421" alors que dans la page web la requête HTTP faite par OpenLayers ne contient que : Request URL:http://a.layers.openstreetmap.fr/voirie-cadastre/7/67/44.png Request Method:GET sans aucun autre entête. La réponse du serveur, même si c'est la même, est alors stockée dans le cache séparément puisque les résultats de ces requêtes dépendent (logiquement) de ces entêtes. Parmi les entêtes justifiant le stockage des deux versions de la tuile dans le cache du navigateur, il y a notamment tous ceux-là (ajoutés par le navigateur, mais pas par le framework OpenLayers dans ses requêtes dynamiques, mais dont il est tenu compte pour savoir si les versions doivent être séparées dans le cache du navigateur) : Cache-Control: max-age=0 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.4 (KHTML, like Gecko) Chrome/22.0.1229.94 Safari/537.4 Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 Referer: http://layers.openstreetmap.fr/?zoom=7&lat=46.88444&lon=-1.68743&layers=B00FFFFFFFFFFFFFFFFFFT Accept-Encoding: gzip,deflate,sdch Accept-Language: fr,en-US;q=0.8,en;q=0.6 Accept-Charset: UTF-8,*;q=0.5 DNT: 1 Dans ce cas, ce n'est pas réellement une anomalie du serveur de tuiles, ni du navigateur. Je ne vois pas de parade évidente et immédiate pour le corriger dans le framework OpenLayers, qui n'a pas connaissance de la plupart de ces autres entêtes et dont il n'a pas lui-même besoin (pas plus que le serveur de tuiles non plus, à moins qu'il lui prenne un jour de tenir compte de "Accept-Language:" pour retourner des tuiles affichant ses libellés dans la langue préférée de l'utilisateur et configurée dans son navigateur, ce qui nécessiterait qu'OpenLayers ajoute ce paramètre de langue dans ses requêtes dynamiques, en tirant sa valeur de celle déjà présente dans la page web où il va afficher les tuiles qu'il demande). Le 20 octobre 2012 18:02, Philippe Verdy <verd...@wanadoo.fr> a écrit : > Le 20 octobre 2012 16:56, Stéphane Péneau <stephane.pen...@wanadoo.fr> a > écrit : >> 24h plus tard : >> >> Au zoom 7, ça a l'air d'être ok, par contre, pas au zoom 6. >> >> Plus embarrassant, certaines couleurs ont de nouveau disparues. Par exemple >> Falleron : >> http://layers.openstreetmap.fr/?zoom=13&lat=46.8784&lon=-1.67533&layers=B00FFFFFFFFFFFFFFFFFFT >> La relation de Falleron : >> http://www.openstreetmap.org/browse/relation/166092 > > Pour Falleron c'est une anomalie de remplissage de la zone (alors que > la zone est bien prise en compte puisque son libellé apparaît bien > centré). Ce cas apparaît parfois quand certaines zones voisines sont > mal fermées, la formation des polygones est alors ambiguë quand on > n'extrait qu'une partie des données (et que les données extraites > semblent suffisantes). > > Dans d'autres cas c'est lié à l'existence d'une frontière en doublon > (les deux frontières sont utilisées alors simultanément dans le rendu, > ce qui permet de positionner le libellé et tracer les contours, mais > pas de remplir la zone qui alors ne se ferme pas correctement). > > On voit assez souvent alors des anomalies de raccordement des > remplissages entre une tuile et la tuile voisine (qui parfois aussi va > remplir la zone de gris, mais pas sa tuile voisine). > > A chaque fois que j'ai vu ça, c'est qu'il y a une anomalie dans les > données de la base ou bien des données incomplètes ou mal "taguées" > (par exemple on a omis de taguer un segment de rivière utilisé comme > frontière dans une relation, ou bien ce segment est oublié dans la > relation, et l'extraction des données ne voit pas ce segment, ou bien > il y a un segment en trop dans la relation, ou bien il manque des tags > dans la relation elle-même pour qu'elle soit prise en compte > correctement pour ce qu'elle est sensée représenter). > > Concernant certains "retards" de mise à jour, ces anomalies dans la > base peuvent en être aussi la cause. Si on croit que c'est correct, on > peut toujours faire (avec certains navigateurs qui le proposent comme > Chrome) un clic droit sur la tuile concernée pour demander à > l'afficher isolément dans un onglet séparé du navigateur, puis ajouter > "/dirty" à son URL pour demander à ce qu'elle soit rafraîchie plus tôt > (cela a aussi pour effet de demander le rafraîchissement d'un certain > nombre de tuiles voisines au même niveau de zoom, mais cela ne demande > pas le rafraîchissement des tuiles couvrant la zone aux autres niveaux > de zoom). > > Si quelques minutes plus tard (délai variable selon la charge du > serveur de tuiles, dont on peut savoir s'il a traité la demande de > rafraîchissement en utilisant "/status" à la place de "/dirty" afin > qu'il indique quelle en est la date et l'heure de génération), et en > réaffichant la tuile dans l'onglet séparé (CTRL+R) on ne voit toujours > aucun changement, c'est qu'il y a bien une anomalie à corriger dans la > base, et il faut regarder plus en détail ce qui manque. > > ===== > > Noter une anomalie apparente de Chrome (à confirmer) : > > Une tuile correctement rafraîchie séparément dans un onglet pour > afficher sa nouvelle version, peut, lorsqu'on l'affiche dans la page > web de la carte générale, n'être affichée parfois que dans son > ancienne version. > > Chrome "semble "se mélanger dans la gestion de son cache, lorsque les > images sont chargées par des requêtes HTTP dynamiques, au contraire > des affichages demandés avec l'URL simple de la tuile, et son cache > alors contient les deux versions : il se trompe en utilisant une > version ancienne toujours présente aussi dans le cache. > > Ce n'est peut-être pas une anomalie du cache de Chrome, mais une > anomalie du Javascript de la page web, dont les requêtes HTTP > dynamiques utiliseraient certaines métadonnées comme par exemple un > cookie de session dont il est tenu compte pour sélectionner la version > de tuile à utiliser, ce cookie n'étant pas utilisé quand on demande la > tuile dans un onglet séparé. > > La seule parade à ça pour l'instant, est de vider le cache du > navigateur, car même la fermeture et la réouverture du navigateur, ou > le rafraîchissement de la page web ne lui suffit pas à utiliser la > version plus récente dans son cache, alors qu'il affiche parfaitement > la version plus récente quand on la demande séparément. Cette purge du > cache suffit à effacer la version marquée du cookie de session (une > nouvelle session sera créée avec ses propres cookies, qui affichera la > version récente de la tuile même si c'est la même version rendue que > celle affichée séparément hors de cette session). > > L'anomalie peut aussi être causée par des métadonnées différentes > retournées par le serveur suivant les deux types de requêtes HTTP qui > sont, visiblement, différentes (l'une des requêtes, celle pour > l'affichage de la tuile isolée, est plus dépouillée que l'autre, celle > effectuée par les requêtes dynamiques en javscript du framework > OpenLayers). > > J'ai tendance ici à penser que c'est une anomalie du framework > OpenLayers (qui effectue des requêtes HTTP trop "riches" en paramètres > pour obtenir les tuiles au lieu de se contenter seulement de leur URL > en éliminant des données qui ne servent qu'à la mise en page de la > page web où on les insère), je peux me tromper. _______________________________________________ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
