[OSM-talk-fr] A propos de la couche voirie/cadastre de layers.openstreetmap.fr

[Philippe Verdy]

Le 20 octobre 2012 16:56, Stéphane Péneau <stephane.peneau at 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.