Le 20 octobre 2012 16:56, Stéphane Péneau <[email protected]> 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 [email protected] http://lists.openstreetmap.org/listinfo/talk-fr
