[OSM-talk-fr] zoom sur carte

[Philippe Verdy]

Le 28 juin 2012 08:37, Marc Sibert <marc at sibert.fr> a écrit :
> N’hésites pas à rafraichire le cache du navigateur (shift - mise à jour de
> la page sur firefox). Il existe aussi une procédure permettant de forcer le
> recalcul d'une tuile côté serveur, mais c'est rarement nécessaire.
>
> http://c.tile.openstreetmap.org/18/133039/90247.png/status (donne l'état de
> la tuile)
> http://c.tile.openstreetmap.org/18/133039/90247.png/dirty (force le refresh)

Dommage qu'on n'ait pas la même chose (au moins la sous-page
"/status") sur les autres serveurs de tuiles hors ceux ici de Mapnik.

De même le framework OpenLayers ne tient pas compte de l'état du cache
web affiche de façon indéfinie des images obsolètes récupérées
d'anciennes versions stockées dans le cache, même lorsque le
navigateur a chargé une nouvelle version des tuiles. (On s'en rend
compte en faisant un click droit pour ouvrir une tuile dans un nouvel
onglet, pour ensuite l'y rafraîchir avec F5, mais quand on revient à
la page OpenLayers, on a beau bouger la page ou même la recharger,
c'est encore l'ancienne version qui s'affiche et non celle remise à
jour pourtant séparément dans le cache du navigateur ! Le seul moyen
d'afficher une nouvelle version est de vider complètement le cache du
navigateur (en fermant d'abord la page) ce qui est carrément
contreproductif quand on veut voir l'effet d'une modification (par
exemple juste après une correction).

Au moins on n'a pas ce problème de rafraîchissement avec les autres
frameworks. Mais OpenLayers est une collection de scripts
particulièrement complexes qui génère du code Javascript effectuant
apparemment ses requêtes HTTP lui-même sans passer par les fonctions
de chargement web du navigateur, et gérant d'une façon étrange le
stockage dans le cache (ou qui ne tient pas compte des dates
d'obsolescence): il génère alors un cache local absolument énorme
contenant des tonnes de tuiles obsolètes qui ne sont même pas purgées.

D'ailleurs ce problème de croissance incontrôlée du cache local de
tuiles existe aussi dans JOSM qui fait croitre de façon démesurée le
cache avec des tuiles qui ne sont ensuite plus jamais purgées (on se
retrouve alors avec un répertoire cache contenant vite dans un seul
dossier des dizaines de milliers de fichiers (à ne surtout pas stocker
dans un volume FAT, NTFS est très hautement conseillé sinon ça rame de
plus en plus ! Mais même avec NTFS on constate que finalement le cache
devient vite plus lent au moindre accès que simplement redemander les
tuiles au serveur).

Je veux bien qu'il y ait une politique pour les tuiles, seulement un
serveur de tuiles indique une date d'obsolescence raisonnable, et le
protocole HTTP pourrait être respecté quand une tuile est rafraichie,
afin que le client en tienne compte ! Si la solution c'est de vider le
cache du navigateur à chaque fois, pour restaurer les performances et
éviter d'encombrer indéfiniment un volume disque, ces logiciels
clients doivent être mis à jour (c'est la principale cause
actuellement des plantage de JOSM, qui rapidement ne parvient même
plus à lire en entier les fichiers de son cache local de tuiles,
tellement il y stocke de fichiers, même en version 64 bits avec une
taille de VM imposante, par exemple 8 Go).

Enfin les logiciels qui gèrent des caches de tuiles devraient éviter
de stocker des dizaines de milliers de fichiers dans un même dossier
du système de fichiers. Si les fichiers ont des noms bien
définissables, on doit pouvoir calculer une clé de hachage simple mais
prédistible de ces noms permettant de les répartir en par exemple un
maximum de 256 dossiers de 256 sous-dossiers maximum (ou toute
division suffisante adaptée au niveau de zoom de ces tuiles selon le
serveur), afin d'accélérer considérablement l'accès et la maintenance
de leurs contenus, comme aussi accélérer considérablement le nettoyage
(surtout sur les volumes FAT ou NFS ou UFS qui n'ont pas d'index
d'accès direct, les fichiers étant trouvés dans un dossier en le
parcourant depuis le début, ou le dossier étant maintenu trié et
demandant de plus en plus de maintenance au fur et à mesure que le
nombre de leurs entrées croit).

Si on devait aller plus loin, même les métadonnées pour les tuiles
devraient non pas être dans des fichiers texte séparés pour chaque
tuile mais dans un index de base de données locale (sur un volume
NTFS, ces métadonnées peuvent être stockées dans des streams sans
entrée supplémentaire dans les dossiers, ces streams étant eux aussi
autoindexables en B-arbres paginables avec un accès direct très rapide
aussi bien en lecture qu'en mise à jour, sinon on peut aussi utilise
un fichier de base de données unique dans le dossier des images; si
cette base de données est corrompue ou plus à jour, il peut être
reconstruit en ignorant et purgeant automatiquement aussi les images
du dossier sans métadonnées; la base de données doit uniquement
contenir les champs d'entête MIME pertinents pour la gestion du cache
HTTP et émis par le serveur, indépendamment des dates et noms
utilisées localement pour le stockage des images).

Mais je me demande dans tout ça à qui demander de revoir la gestion
défaillante des caches locaux de tuiles dans JOSM et OpenLayers, qui
sont les seuls logiciels qui jusqu'à présent ne permette pas une
automatisation de la purge selon une politique raisonnée. A cause de
cela, je suis obligé d'utiliser un logiciel de proxy cache externe
transparent, et de demander au navigateur et à JOSM de réduire au
minimum ses caches locaux afin qu'ils interrogent systémtiquement le
proxy cache externe transparent (qui lui au moins respecte les
politiques HTTP émises par les serveurs); sans cela, cela finit
rapidement par ralentir totalement le système hôte et peur provoquer
trop facilement des anomalies et pertes de données ou corruptions et
bloquages au niveau système à cause des trop nombreux fichiers stockés
en vrac dans un même dossier au contenu trop instable et sans cesse
croissant.