Menu : | html | yaml | json | edit | check | reindex | dump | unset |
name | tilecache.inc.php | ||||||||
title | tilecache.inc.php - Cache de tuiles implémentant l'interface iTileServer | ||||||||
journal |
|
title | Cache de tuiles implémentant l'interface iTileServer |
doc |
La classe TileCache gère un cache de tuiles implémentant l'interface iTileServer La stratégie de remplissage du cache est la suivante: - on ne définit pas un niveau donné pour lequel le cache serait rempli - le remplissage s'effectue selon un algo récursif - je pars par exemple du niveau 6 pour lequel la métropole correspond à 31-33/21-23 soit 9 tuiles - Pour une tuile donnée: - si elle correspond à une tuile simple (par exemple moins de 200 objets, défini dans FeatureViewer::simpleTile()) - alors je fabrique l'image sans conserver le résultat en cache - sinon: - j'effectue un appel récursif aux 4 sous-tuiles, - j'agrège les 4 sous-images et - je conserve le résultat en cache Pour l'affichage: - si la tuile est en cache - alors je l'utilise - sinon: - si elle est simple - alors je la reconstruis interactivement - sinon j'abandonne avec une erreur 404 L'affichage ne remplit pas le cache. Cet algo est réparti entre les 3 couches logicielles: - le cache qui enregistre les images en cache - le featureViewer qui fabrique l'image à partir du vecteur et qui décrète si une tuile est simple ou complexe - le featureDataset qui expose les objets vecteurs Cet algo doit fonctionner pour les objets pas trop complexes comme les parcelles. Cela ne fonctionnerait probablement pas bien pour l'occupation du sol à cause de la complexité des zones. Dans le cas d'objets complexes, il faut probablemnt une première phase de simplification des objets. Outre les champs de métadonnées, le document doit définir les champs suivants: - tileServer : identifiant d'un document iTileServer correspondant au serveur de tuiles à mettre en cache - layers - lyrName : nom de la couche du tileServer à mettre en cache |