Types de cache

Author:Thomas Bonfort
Contact:tbonfort at terriscope.fr

Ce document détaille les différents backends pour le cache qui peuvent être utilisés pour stocker des tuiles.

Caches disque

Le cache basé sur le stockage disque est le plus simple à configurer parmi les types de cache, et celui avec l’accès le plus rapide aux tuiles existantes. Il est idéal pour les petits dépôts de tuiles, mais peut souvent causer des problèmes pour les sites qui hébergent des millions de tuiles, comme le nombre de fichiers ou répertoire est susceptible de dépasser les capacités du système de fichier sous-jacent. En plus, la taille des blocs de fichiers choisis pour le système de fichiers doit correspondre le plus possible à la taille moyenne d’une tuile stockée: idéalement, n’importe quelle tuile devrait juste contenir dans un bloc de système de fichiers, afin de ne pas gaspiller de l’espace de stockage dans chaque bloc et ne pas utiliser plusieurs blocs par tuile.

L’emplacement des répertoires/fichiers doit être en lecture/écriture pour l’utilisateur qui fait fonctionner le serveur de tuiles.

Configuration commune

Les caches disques sont ajoutés via

<cache name="disk_cache" type="disk" layout="...">
  ...
  <symlink_blank/>
  <creation_retry>3</creation_retry>
</cache>

Tous les caches sauf le « template » supportent l’option <symlink_blank/> qui (selon sa disponibilité sur la plateforme) détecte les tuiles monochromes et crée un lien symbolique vers une tuile unique de la même couleur au lieu de stocker les données monochromes dans le fichier de tuile.

Tous les caches supportent l’option <creation_retry>, qui spécifie combien de fois MapCache doit réessayer de créer un fichier de tuile ou un lien symbolique lorsque la première tentative échoue. Par défaut MapCache abandonne immédiatement: Une valeur supérieure à 0 peut être judicieuse lorsqu’un système de fichiers réseau est utilisé et que les erreurs temporaires sont fréquentes.

Structure par défaut

Le système de stockage de tuiles par défaut stocke les tuiles dans une structure pratiquement identique à la hiérarchie de fichiers/répertoires utilisée par TileCache (une solution plus ancienne de mise en cache). Le seul changement est que la structure de répertoire de niveau le plus élevé correspondant au nom de la grille est ajouté (comme MapCache supporte de multiples grilles par jeux de tuiles)

Ce cache est capable de détecter les tuiles « blanches » (c’est à dire avec une couleur uniforme) et d’utiliser un lien symbolique vers une seule tuile « blanche »pour gagner de l’espace disque.

<cache name="disk" type="disk">
   <base>/tmp</base>
   <symlink_blank/>
</cache>

Les deux seules clés dans la configuration sont le répertoire racine où les tuiles seront stockées, et la clé pour activer la mise en lien symbolique des tuiles vides.

Structure compatible Arcgis

<cache name="arcgis" type="disk" layout="arcgis">
   <base>/tmp</base>
   <symlink_blank/>
</cache>

Cette disposition crée une structure de tuiles compatible avec un cache arcgis éclaté. Les tuiles sont stockées dans des fichiers dont le chemin suit le schéma /tmp/{tileset}/{grid}/{dimension}/L{z}/R{y}/C{x}.{ext}

Structure compatible Worldwind

<cache name="worldwind" type="disk" layout="worldwind">
   <base>/tmp</base>
   <symlink_blank/>
</cache>

Cette disposition crée une structure de tuiles compatible avec un cache Worldwind. Les tuiles sont stockées dans des fichiers dont le chemin suit le schéma /tmp/{tileset}/{grid}/{dimension}/{z}/{y}/{y}_{x}.ext

Structure de « template »

Le modèle basé sur le cache disque vous permet de créer (ou réutiliser) une structure de tuiles (existante) que vous avez défini à l’avance. Le paramètre <template> prend une chaîne en argument où les différentes entrées du modèle seront remplacées à l’exécution par la valeur correcte pour chacune des tuiles à stocker.

<cache name="tmpl" type="disk" layout="template">
   <!-- template

       string template that will be used to map a tile (by tileset, grid name, dimension,
       format, x, y, and z) to a filename on the filesystem
       the following replacements are performed:
       - {tileset} : the tileset name
       - {grid} : the grid name
       - {dim} : a string that concatenates the tile's dimension
       - {ext} : the filename extension for the tile's image format
       - {x},{y},{z} : the tile x,y,z values
       - {inv_x}, {inv_y}, {inv_z} : inverted x,y,z values (inv_x = level->maxx - x - 1). This
            is mainly used to support grids where one axis is inverted (e.g. the google schema)
            and you want to create on offline cache.

      * Note that this type of cache does not support blank-tile detection and symlinking.

      * Warning: It is up to you to make sure that the template you chose creates a unique
        filename for your given tilesets. e.g. do not omit the {grid} parameter if your
        tilesets reference multiple grids. Failure to do so will result in filename
        collisions !

   -->
   <template>/tmp/template-test/{tileset}#{grid}#{dim}/{z}/{x}/{y}.{ext}</template>
</cache>

Caches Berkeley DB

Le cache du backend Berkeley DB stocke les tuiles dans une base de données clé-valeur à plat et donc n’a pas les désavantages des caches disques au regard du nombre de fichiers de tuiles stockées sur le système de fichiers. Comme les « blobs » d’images sont stockés de manière contiguë, la taille du bloc choisi pour le système de fichiers n’a pas d’influence sur la capacité de stockage du volume.

Notez que pour un cache Berkeley DB donné, seul un seul fichier de base de données est créé, qui stockera les tuiles des jeux de tuiles associés (c’est à dire qu’il n’y a pas de fichier de base de données créé par jeu de tuiles, grilles, et/ou dimensions). Si vous avez besoin de stocker différents jeux de donnés dans différents fichiers, alors utilisez de multiples entrées dans le cache Berkeley DB. Il n’est pas possible d’utiliser de multiples fichiers de base de données pour des grilles de jeux de tuiles ou des dimensions.

Les caches basés sur Berkeley DB sont un peu plus rapides que les caches basés sur le stockage disque mais sont un peu plus lents pour les écritures concurrentes si de nombreux threads essayent tous d’insérer des tuiles de manière concurrente.

<cache name="bdb" type="bdb">
   <!-- base (required)
      absolute filesystem path where the Berkeley DB database file is to be stored.
      this directory must exist, and be writable
   -->
   <base>/tmp/foo/</base>

   <!-- key_template (optional)
      string template used to create the key for a tile entry in the database.
      defaults to the value below. you should include {tileset}, {grid} and {dim} here
      unless you know what you are doing, or you will end up with mixed tiles
   <key_template>{tileset}-{grid}-{dim}-{z}-{y}-{x}.{ext}</key_template>
   -->
</cache>

Caches SQLite

Il y a deux caches SQLite différents qui varient par le schéma de la base de données qu’ils créent et interrogent. Les caches SQLite ont l’avantage de stocker les tuiles dans des « blobs » dans un seul fichier de base de données et donc ils n’ont pas les désavantages des caches disques au regard du nombre de fichiers de tuiles stockées. Comme les « blobs » d’images sont stockés de manière contiguë, la taille du bloc choisi pour le système de fichiers n’a pas d’influence sur la capacité de stockage du volume.

Les caches SQLite sont un peu plus lents que les caches disques, et peuvent avoir des problèmes de blocage en écriture au moment du remplissage si un nombre élevé de threads essaient tous d’insérer de nouvelles tuiles en même temps.

Schéma par défaut

Les tuiles sont stockées dans le fichier SQLite configuré créé par MapCache avec

create table if not exists tiles(
   tileset text,
   grid text,
   x integer,
   y integer,
   z integer,
   data blob,
   dim text,
   ctime datetime,
   primary key(tileset,grid,x,y,z,dim)
);
<cache name="sqlite" type="sqlite3">
   <dbfile>/path/to/dbfile.sqlite3</dbfile>
</cache>

Vous pouvez également ajouter des commandes pragmas SQLite personnalisées qui seront exécutées lors de la première connexion à la base de données, de façon à modifier les réglages SQlite par défaut

<cache name="sqlite" type="sqlite3">
   <dbfile>/tmp/sqlitefile.db</dbfile>
   <pragma name="max_page_count">10000000</pragma>
</cache>

Les entrées <pragma> résulteront en un appel à

PRAGMA max_page_count = 1000000;

Schéma personnalisé

Ce cache peut utiliser n’importe quel schéma de base de données. C’est à vous de fournir le SQL qui sera utilisé pour sélectionner ou insérer une nouvelle tuile.

Afin d’utiliser cette fonctionnalité, vous devez fournir les requêtes SQL que MapCache utilisera sur votre schéma personnalisé. Il est de votre responsabilité de vous assurer que les requêtes sont correctes et renvoient les bonnes données pour un jeu de tuiles, une dimension une grille et des coordonnées x, y et z donnés.

<cache name="sqlitecustom" type="sqlite3">
   <dbfile>/tmp/sqlitefile.db</dbfile>
   <queries>
     <create>create table if not exists tiles(tileset text, grid text, x integer, y integer, z integer, data blob, dim text, ctime datetime, primary key(tileset,grid,x,y,z,dim))</create>
     <exists>select 1 from tiles where x=:x and y=:y and z=:z and dim=:dim and tileset=:tileset and grid=:grid</exists>
     <get>select data,strftime("%s",ctime) from tiles where tileset=:tileset and grid=:grid and x=:x and y=:y and z=:z and dim=:dim</get>
     <set>insert or replace into tiles(tileset,grid,x,y,z,data,dim,ctime) values (:tileset,:grid,:x,:y,:z,:data,:dim,datetime('now'))</set>
     <delete>delete from tiles where x=:x and y=:y and z=:z and dim=:dim and tileset=:tileset and grid=:grid</delete>
   </queries>
</cache>

Il est important de noter que dans le cas de la requête <get> qui renvoie les données relatives à une tuile, le premier argument renvoyé est le « blob » d’image et le deuxième argument, optionnel, est la date de création de la tuile.

Détection de tuile vide

Les caches SQLites de MapCache supportent la détection et le stockage des tuiles vides (c’est-à-dire monochromes), et stockent dans le « blob » d’image les quatre octets de la composante RGBA de la couleur. Sur requête d’un client, ces quatre octets sont alors convertis à la volée en une image d’un pixel au format PNG à couleurs indexées.

<cache name="sqliteblank" type="sqlite3">
   <dbfile>/tmp/sqlitefile.db</dbfile>
   <detect_blank/>
</cache>

Note

Les fichiers SQLite créés avec cette option ne pourront être pleinenemt exploités que par MapCache, puisque les « blobs » images des tuiles sont susceptibles de contenir un quadruplet #RGBA au lieu de données PNG ou JPEG.

Utilisation de fichiers SQLite multiples

Il est possible de découper un cache SQLite en plusieurs fichiers, pour des besoins d’organisation ou pour conserver des fichiers de taille raisonnable lorsque de gros volumes de données sont à cacher.

Pour ce faire, il est possible d’utiliser un schéma de nommage pour déterminer quel fichier utiliser pour une tuile donnée:

<cache name="sqlite" type="sqlite3">
   <dbfile>/path/to/{grid}/{dim}/{tileset}.sqlite3</dbfile>
</cache>

Il est également possible de limiter le nombre de tuiles en x et en y à stocker dans un fichier SQLite:

<cache name="sqlite" type="sqlite3">
   <dbfile>/path/to/{grid}/{dim}/{tileset}/{z}/{x}-{y}.sqlite3</dbfile>
   <xcount>1000</xcount>
   <ycount>1000</ycount>
</cache>

Dans ce cas, vous devez inclure les variables de remplacement {x}, {y} et {z} dans le schéma de nommage qui détermine le fichier à utiliser. Dans l’exemple précédent, la tuile (z,x,y)=(15,3024,1534) est stockée dans un fichier nommé /path/to/g/mytileset/15/3000-1000.sqlite3 et la tuile (5,2,8) est stockée dans un fichier nommé /path/to/g/mytileset/5/0-0.sqlite3

Les paramètres suivants sont disponibles pour manipuler les x,y et z d’une tuile donnée:

  • {z} est remplacé par le niveau de zoom.
  • {x} est remplacé par l’abscisse de la tuile la plus à gauche dans le fichier SQLite qui contient la tuile demandée.
  • {inv_x} est remplacé par l’abscisse de la tuile la plus à droite.
  • {y} est remplacé par l’ordonnée de la tuile la plus en bas.
  • {inv_y} est remplacé par l’ordonnée de la tuile la plus en haut.
  • {div_x} est remplacé par l’indice du fichier SQLite en partant de la gauche de la grille (càd. {div_x} = {x}/<xcount>).
  • {inv_div_x} est semblable à {div_x} mais en partant de la droite.
  • {div_y} est remplacé par l’indice du fichier SQLite en partant du bas de la grille (càd. {div_y} = {y}/<ycount>).
  • {inv_div_y} est semblable à {div_y} mais en partant du haut.

Note

{inv_x} et {inv_div_x} seront probablement rarement utilisés, tandis que {inv_y} et {inv_div_y} peuvent trouver une utilité pour les personnes qui préfèrent numéroter leurs fichiers SQLite de haut en bas plutôt que de bas en haut.

Dans certains cas il peut être souhaitable de maîtriser précisément le nom du fichier à utiliser pour une recherche d’une tuile x,y,z, par exemple un fichier nommé Z03-R00003-C000009.sqlite3 plutôt que simplement Z3-R3-C9.sqlite3. l’élément <dbfile> supporte des attributs de format dont la syntaxe est calquée sur le printf() Unix (voir: http://linux.die.net/man/3/printf ). Ces attributs sont nommés d’après la variable de substitution correspondante en ajoutant le suffixe « _fmt », par exemple:

<cache name="mysqlite" type="sqlite3">
   <dbfile
      x_fmt="%08d"
      inv_y_fmt="%08d"
   >/data/{tileset}/{grid}/L{z}/R{inv_y}/C{x}.sqlite</template>
</cache>

Note

Sans indication, le fonctionnement par défaut utilise « %d » pour le formatage.

Caches MBTiles

Ce type de cache est un raccourci du schéma de cache SQLite personnalisée ci-dessus, avec des requêtes SQL pré-remplies correspondant aux spécifications MBTiles.

Bien que le schéma MBTiles par défaut soit très simple, MapCache utilise le même schéma multi-tables que l’on retrouve dans la plupart des fichiers MBTiles téléchargeables, principalement afin de permettre le stockage des tuiles vides (monochromes) sans avoir à dupliquer les données (de la même manière que le cache disque utilise des liens symboliques vers un fichier unique).

Le schéma MBTiles est créé avec:

create table if not exists images(
  tile_id text,
  tile_data blob,
  primary key(tile_id));
create table if not exists map (
  zoom_level integer,
  tile_column integer,
  tile_row integer,
  tile_id text,
  foreign key(tile_id) references images(tile_id),
  primary key(tile_row,tile_column,zoom_level));
create table if not exists metadata(
  name text,
  value text); -- not used or populated yet
create view if not exists tiles
  as select
     map.zoom_level as zoom_level,
     map.tile_column as tile_column,
     map.tile_row as tile_row,
     images.tile_data as tile_data
  from map
     join images on images.tile_id = map.tile_id;
<cache name="mbtiles" type="mbtiles">
   <dbfile>/Users/XXX/Documents/MapBox/tiles/natural-earth-1.mbtiles</dbfile>
</cache>

Note

Contrairement au schéma standard SQLite de MapCache, le fichier MBTiles n’accepte qu’un jeu de tuiles par cache. Le comportement si plusieurs jeux de tuiles sont associées au même cache n’est pas défini, et produira certainement des résultats incorrects.

Avertissement

Lorsqu’on travaille avec plusieurs processus (option -p) et caches SQLites, des erreurs sont susceptibles d’apparaître en situation de forte concurrence lors d’écritures dans la base SQLite (erreur: SQL logic error or missing database (1)). Une mise à niveau de SQLite en version supérieure ou égale à 3.7.15 semble résoudre le problème.

Caches Memcache

Ce type de cache stocke les tuiles au sein d’un serveur memcached externe, fonctionnant soit sur la machine elle-même soit accessible via le réseau. Ce type de cache a l’avantage de bien gérer l’expiration des tuiles, de sorte que la taille du cache ne dépassera jamais ce qui a été configuré dans l’instance memcache.

L’utilisation de Memcache nécessite une version plutôt récente de la librairie apr-util. Veuillez noter que sous de très fortes charges (généralement uniquement atteignable via des outils de benchmarking en localhost), l’implémentation memcache d’apr-util peut tomber et se mettre à abandonner les connexions pendant quelques intervalles de temps avant de revenir à la normale.

Vous pouvez ajouter de multiple entrées <server>.

<cache name="memcache" type="memcache">
   <server>
      <host>localhost</host>
      <port>11211</port>
   </server>
</cache>

Note

Les tuiles stockées au travers de memcache sont configurées pour expirer au bout d’une journée par défaut. Ce réglage peut être modifié au niveau du jeu de données en utilisant le mot-clé <auto_expire>.

Afin de réduire la mémoire utilisée par les tuiles vide dans l’instance memcache, vous pouvez activer la détection des tuiles vides, auquel cas un quadruplet #RGBA est stocké dans le cache en lieu et place des véritables données d’image. Sur requête d’un client, ces quatre octets sont alors convertis à la volée en une image d’un pixel au format PNG à couleurs indexées.

<cache name="memcache" type="memcache">
   <detect_blank/>
   ...
</cache>

Caches (Geo)TIFF

Les caches TIFF sont le plus récent ajout à la famille des caches. Ils utilisent la structure interne tuilée de la spécification TIFF pour accéder aux données tuilées. Les tuiles ne peuvent être stockées qu’en JPEG (TIFF n’implémente pas le format PNG).

Comme un fichier TIFF unique peut contenir beaucoup de tuiles, il y a une réduction drastique du nombre de fichiers qui doivent être stockés sur le système de fichiers, ce qui résoud les principaux défauts des caches disques. Un autre avantage est que les mêmes fichiers TIFF peuvent être utilisés par des logiciels ou des serveurs WMS qui n’accèdent qu’à des formats SIG raster courants tout en étant utilisés pour un accès tuilé hautes performances.

Le cache TIFF doit être considéré comme étant en lecture-seule pour le moment. L’accès en écriture est déjà possible mais doit être considéré comme expérimental en cela qu’il peut y avoir des problèmes de corruption de fichier, surtout dans le contexte de montages réseaux du système de fichiers. Veuillez noter que jusqu’à ce que toutes les tuiles d’un fichier TIFF donné aient été générées, le fichier TIFF est réputé « clairsemé » au sens qu’il manque des tuiles. La plupart des logiciels autres que GDAL auront des difficultés à ouvrir ces fichiers incomplets.

Veuillez noter que la structure des tuiles TIFF doit respecter exactement la structure de la grille devant être utilisée par le jeu de tuile, et les noms des fichiers TIFF doivent respecter de strictes conventions de nommage.

Définition des tailles de fichiers TIFF

Le nombre de tuiles stockées dans chacune des directions horizontales et verticales doit être défini:

  • <xcount> le nombre de tuiles stocké le long de la direction x (horizontal) du fichier TIFF
  • <ycount> le nombre de tuiles stocké le long de la direction y (horizontal) du fichier TIFF
<cache name="tiff" type="tiff">
   <xcount>64</xcount>
   <ycount>64</ycount>
   ...
</cache>

Configuration de la convention de nommage des fichiers

Le tag <template> détermine le modèle à utiliser lors de la recherche d’un fichier TIFF en fonction des x,y,z de la tuile demandée

<cache name="tiff" type="tiff">
   <template>/data/tiffs/{tileset}/{grid}/L{z}/R{inv_y}/C{x}.tif</template>
   ...
</cache>

Les paramètres suivants sont disponibles pour manipuler les x,y et z d’une tuile donnée:

  • {x} est remplacé par la valeur x de la tuile la plus à gauche dans le fichier TIFF contenant la tuile demandée.
  • {inv_x} est remplacé par la valeur x de la tuile la plus à droite
  • {y} est remplacé par la valeur y de la tuile la plus en bas
  • {inv_y} est remplacé par la valeur y de la tuile la plus en haut
  • {div_x} est remplacé par l’index du fichier TIFF commençant à gauche de la grille (i.e. {div_x} = {x}/<xcount>)
  • {inv_div_x} comme {div_x} mais en commençant à droite.
  • {div_y} est remplacé par l’index du fichier TIFF commençant au bas de la grille (i.e. {div_y} = {y}/<ycount>)
  • {inv_div_y} est similaire {div_y} mais en commençant par le haut.

Note

{inv_x} et {inv_div_x} seront probablement rarement utilisés, tandis que {inv_y} et {inv_div_y} trouveront un usage approprié pour les personnes préférant indexer leurs fichiers TIFF de haut en bas plutôt que de bas en haut.

Personnalisation des clés du « template »

Dans certains cas, il peut être souhaitable d’avoir un contrôle précis sur le nom du fichier à utiliser pour une tuile x,y,z particulière, par exemple pour retrouver un fichier nommé « Z03-R00003-C000009.tif » plutôt que « Z3-R3-C9.tif ». Le paramètre <template> permet d’utiliser des éléments de formatage pour peu qu’ils suivent la syntaxe unix printf ( c.f.: http://linux.die.net/man/3/printf ), en suffixant chacun des éléments <template> avec « _fmt » comme par exemple :

<cache name="tiff" type="tiff">
   <template
      x_fmt="%08d"
      inv_y_fmt="%08d"
   >/data/tiffs/{tileset}/{grid}/L{z}/R{inv_y}/C{x}.tif</template>
</cache>

Note

Sans indication, le fonctionnement par défaut utilise « %d » pour le formatage.

Définition des options de compression JPEG

Un paramètre optionnel complémentaire définit la compression JPEG à appliquer aux tuiles quand elles sont enregistrées dans le fichier TIFF:

  • <format> le nom du format (JPEG) à utiliser

Voir aussi

Format JPEG

<cache name="tiff" type="tiff">
   ...
   <format>myjpeg</format>
</cache>

Dans cet exemple, en utilisant une grille de 256x256 tuiles, les fichiers qui sont lus pour charger les tuiles sont des TIFFs tuilés avec une compression JPEG, dont la taille est de 16384x16384. Le nombre de fichiers à stocker sur le disque est ainsi réduit 4096 fois comparativement à un cache disque standard.

Utilisation d’un verrou spécifique

MapCache a besoin de créer un verrou pour écrire dans un fichier TIFF afin d’éviter que deux instances ne modifient le même fichier simultanément. Par défaut le verrou global de MapCache est utilisé. Toutefois, il est possible de configurer un mécanisme ou un comportement de verrouillage différent en le configurant à l’intérieur du cache TIFF proprement dit.

Voir aussi

Locking Mechanisms

<cache name="tiff" type="tiff">
   ...
   <locker> .... </locker>
</cache>

Support GeoTIFF

S’il est compilé avec le support GeoTIFF en écriture, MapCache ajoutera les informations de référencement aux fichiers TIFF qu’il créé, de sorte que les fichiers TIFF puissent être utilisés par n’importe quel logiciel utilisant du GeoTIFF. Le support en écriture ne produit pas des GeoTIFFs complets avec la définition de la projection utilisée, mais uniquement l’échelle du pixel et les points de calage, ce qu’on trouve généralement dans les fichiers .tfw.

Pour référence, voici la sortie produite par gdalinfo sur une fichier TIFF créé par MapCache quand il est compilé avec le support GeoTIFF:

LOCAL_CS["unnamed",
    UNIT["metre",1,
        AUTHORITY["EPSG","9001"]]]
Origin = (-20037508.342789247632027,20037508.342789247632027)
Pixel Size = (156543.033928040997125,-156543.033928040997125)
Metadata:
  AREA_OR_POINT=Area
Image Structure Metadata:
  COMPRESSION=YCbCr JPEG
  INTERLEAVE=PIXEL
  SOURCE_COLOR_SPACE=YCbCr
Corner Coordinates:
Upper Left  (-20037508.343,20037508.343)
Lower Left  (-20037508.343,-20037508.343)
Upper Right (20037508.343,20037508.343)
Lower Right (20037508.343,-20037508.343)
Center      (   0.0000000,   0.0000000)

Caches REST

Les types de caches suivants stockent et récupèrent les tuiles via des opérations HTTP standard GET et PUT. Ils peuvent être utilisés pour stocker les tuiles chez des fournisseurs populaires de stockage « cloud ».

Cache REST pur

Ce type de cache peut être utilisé pour stocker des tuiles sur un serveur WebDAV. Il est nécessaire de fournir un schéma d’URL à utiliser pour accéder à une tuile selon ses paramètres x,y,z, etc.

<cache name="myrestcache" type="rest">
  <url>https://myserver/webdav/{tileset}/{grid}/{z}/{x}/{y}.{ext}</url>
</cache>

Spécification des en-têtes HTTP

Il est possible de personnaliser les en-têtes HTTP à ajouter à une requête HTTP, soit de manière globale, soit spécifiquement pour chaque type de requête (envoyer, récupérer ou supprimer une tuile):

<cache name="myrestcache" type="rest">
  <url>https://myserver/webdav/{tileset}/{grid}/{z}/{x}/{y}.{ext}</url>
  <headers>
    <Host>my-virtualhost-alias.domain.com</Host>
  </headers>
  <operation type="put">
    <headers>
      <X-my-specific-put-header>foo</X-my-specific-put-header>
    </headers>
  </operation>
  <operation type="get">
    <headers>
      <X-my-specific-get-header>foo</X-my-specific-get-header>
    </headers>
  </operation>
  <operation type="head">
    <headers>
      <X-my-specific-head-header>foo</X-my-specific-head-header>
    </headers>
  </operation>
  <operation type="delete">
    <headers>
      <X-my-specific-delete-header>foo</X-my-specific-delete-header>
    </headers>
  </operation>
</cache>

Caches REST Amazon S3

Le cache REST a été spécialisé pour permettre l’accès à Amazon S3, afin d’ajouter la couche d’authentification et autorisation nécessaire à cette plateforme.

<cache name="s3" type="s3">
  <url>https://foo.s3.amazonaws.com/tiles/{tileset}/{grid}/{z}/{x}/{y}/{ext}</url>
  <headers>
    <Host>foo.s3.amazonaws.com</Host>
  </headers>
  <id>AKIE3SDEIT6TUG8DXEQI</id>
  <secret>5F+dGsTfsdfkjdsfSDdasf4555d/sSff56sd/RDS</secret>
  <region>eu-west-1</region>
  <operation type="put">
    <headers>
      <x-amz-storage-class>REDUCED_REDUNDANCY</x-amz-storage-class>
      <x-amz-acl>public-read</x-amz-acl>
    </headers>
  </operation>
</cache>

Les éléments <id>, <secret> et <region> sont requis. Ils sont obtenus via votre console de gestion Amazon. Vous devez lire la documentation pour déterminer quels en-têtes sont nécessaires selon votre profil d’utilisation (l’exemple fourni héberge des tuiles dans un espace meilleur marché, et permet de les rendre publiquement accessibles).

Caches REST Microsoft Azure

Le cache REST a été spécialisé pour permettre l’accès à Azure, afin d’ajouter la couche d’authentification et autorisation nécessaire à cette plateforme.

<cache name="azure" type="azure">
  <url>https://foo.blob.core.windows.net/tiles/{tileset}/{grid}/{z}/{x}/{y}/{ext}</url>
  <headers>
    <Host>foo.blob.core.windows.net</Host>
  </headers>
  <id>foo</id>
  <secret>foobarcccccccccccccccccccccyA==</secret>
  <container>tiles</container>
</cache>

Les éléments <id>, <secret> et <container> sont requis. Ils sont obtenus via votre console de gestion. Vous devez lire la documentation pour déterminer quels en-têtes sont nécessaires selon votre profil d’utilisation.

Google Cloud Storage REST Caches

Le cache REST a été spécialisé pour permettre l’accès à Google Cloud Storage, afin d’ajouter la couche d’authentification et autorisation nécessaire à cette plateforme.

<cache name="google" type="google">
  <url>https://storage.googleapis.com/mytiles-mapcache/{tileset}/{grid}/{z}/{x}/{y}.{ext}</url>
  <access>GOOGPGDWFDG345SDFGSD</access>
  <secret>sdfgsdSDFwedfwefr2345324dfsGdsfgs</secret>
  <operation type="put">
    <headers>
      <x-amz-acl>public-read</x-amz-acl>
    </headers>
  </operation>
</cache>

Les éléments <acces> et <secret> sont requis. Ils sont obtenus via votre console de gestion. Vous devez lire la documentation pour déterminer quels en-têtes sont nécessaires selon votre profil d’utilisation. Il est important de noter que le support de Google Cloud Storage passe par sa couche de compatibilité avec Amazon.

Méta-caches

Ces types de caches ne stockent pas de tuiles mais délèguent cette fonctionnalité à un certain nombre de caches sous-jacents selon un ensemble de règles ou de comportements. Ces caches sont principalement utiles pour des déploiements de MapCache impliquant de multiples instances, avec des back-ends de caches partagés (par exemple serveurs memcache dédiés et systèmes de fichiers en réseau).

Caches composites

Ce cache utilise différents caches sous-jacents selon le niveau de zoom des tuiles, et peut par exemple être utilisé pour stocker les tuiles des faibles niveaux de zoom dans un stockage permanent et les tuiles des niveaux de zoom plus forts dans un cache temporaire (memcache).

<cache name="mydisk" ...> ... </cache>
<cache name="mymemcache" ...> ... </cache>
<cache name="composite" type="composite">
   <cache grids="mygrid,g">mycache</cache>
   <cache min-zoom="0" max-zoom="8">mydisk</cache>
   <cache min-zoom="9">mymemcache</cache>
</cache>
<tileset ...>
   <cache>composite</cache>
   ...
</tileset>

Pour chaque tuile, les caches sont examinés dans leur ordre de définition dans le fichier de configuration, et le premier à satisfaire les contraintes de zoom et de grille est utilisé. À charge pour l’utilisateur de s’assurer que la succession de valeurs de zoom et de grille est pertinente, par exemple:

<cache name="composite" type="composite">
   <cache min-zoom="0">cache1</cache>
   <cache min-zoom="9">this_cache_will_never_be_used</cache>
</cache>

Caches de repli

Ces types de caches renvoient les tuiles depuis le premier sous-cache qui ne retourne pas une erreur. Ils peuvent être utilisés lorsqu’un des caches rencontre des conditions d’erreurs (par exemple des caches REST distants, un memcache).

<cache name="fallback" type="fallback">
   <cache>mymemcache</cache>
   <cache>mysqlitecache</cache>
</cache>

Une écriture dans un tel cache provoque une écriture dans l’ensemble des sous-caches.

Caches à plusieurs niveaux

Ces types de caches peuvent être utilisés pour combiner des caches rapides mais coûteux avec des caches bon marché mais lents.

<cache name="multitier" type="multitier">
   <cache>fast</cache>
   <cache>cheap</cache>
</cache>

Si une tuile donnée est absente du premier sous-cache, elle sera lue depuis le deuxième sous-cache et copiée dans le premier pour les accès ultérieurs. Ce type de cache est prévu pour être utilisé lorsque le premier cache supprime automatiquement les tuiles les plus anciennes (par exemple un memcache).

Une écriture dans un tel cache provoque une écriture dans le dernier sous-cache.

Combinaisons de caches

Tous ces méta-caches peuvent être combinés pour régler finement la disponibilité et les performances selon les coûts de stockage, le temps de recréation des tuiles manquantes, etc.

<cache name="slow_and_permanent" type="sqlite">...</cache>
<cache name="fast_and_transient" type="memcache">...</cache>
<cache name="low_zooms" type="multitier">
   <cache>fast_and_transient</cache>
   <cache>slow_and_permanent</cache>
<cache>
<cache name="mycache" type="composite">
   <cache maxzoom="12">low_zooms</cache>
   <cache>fast_and_transient</cache>
<cache>
<tileset>
   <cache>mycache</cache>
   ...
</tileset>

Dans l’exemple précédent, toutes les tuiles sont récupérées en premier lieu d’une instance memcache, néanmoins, les tuiles de niveaux de zoom inférieurs sont conservées dans un cache SQLite permanent qui est utilisé pour peupler le cache memcache rapide, par exemple lors d’un redémarrage.

Caches Riak

Nécéssite https://github.com/trifork/riack

<cache name="myriak" type="riak">
  <server>
    <host>riakhost</host>
    <port>12345</port>
    <bucket>mytiles</bucket>
  </server>
</cache>