Spécification des données utilisées par le serveur WMS/WMTS ROK4

Introduction

Fonctionnement général

Le serveur ROK4, à son initialisation, va charger tous les fichiers XML de layer (extension .lay) présents dans le dossier défini dans sa configuration. Un fichier « layer » correspond à une couche, une donnée de diffusion. Ceux-ci contiennent bon nombre d’informations que l’on pourra retrouver lors d’une requête « GetCapabilities », mais surtout où trouver les données raster à utiliser.

Ces données sont formatées de manière à faciliter leur utilisation, pour une requête WMS comme WMTS. Elles sont stockées sous forme de pyramide, tuilées et multi-résolutionnées.

Serveur - Couche - Pyramide

Représentation du chemin entre le serveur ROK4 et la
pyramide des donnée

Il était prévu à la base qu’une couche puisse référencer plusieurs pyramides. Cette possibilité a été mise de côté et on a privilégié la génération d’une « pyramide virtuelle » (ne contenant que des liens vers différentes pyramides) afin d’obtenir un résultat similaire.

Nous allons donc détailler les caractéristiques de l’ensemble des éléments composant une pyramide.

Notions de base

Le Tile Matrix Set

Un TMS est un ensemble de Tile Matrix, définissant le quadrillage d’autant de niveaux dans un fichier XML. Le SRS du TMS est indiqué avec la même convention que pour les utilitaires basés sur la librairie PROJ4, c’est-à-dire avec une chaîne de caractères formée du registre dans lequel est défini le SRS et de l’identifiant du SRS dans ce registre, par exemple : IGNF:LAMB93 ou EPSG:4326. EPSG peut être indiqué en minuscules ou en majuscule. Toutes les informations sont définies en fonction du SRS (unité du SRS pour les coordonnées et les résolutions).

Un TM possède un identifiant (chaîne de caractères) unique dans le TMS. Les résolutions d’un niveau à l’autre ne vont pas nécessairement de deux en deux (bien que ce soit le cas le plus courant).

<tileMatrixSet>
<crs>IGNF:LAMB93</crs>
<tileMatrix>
<id>17</id>
<resolution>1</resolution>
<topLeftCornerX> 0 </topLeftCornerX>
<topLeftCornerY> 12000000 </topLeftCornerY>
<tileWidth>256</tileWidth>
<tileHeight>256</tileHeight>
<matrixWidth>5040</matrixWidth>
<matrixHeight>42040</matrixHeight>
</tileMatrix>
...
</tileMatrixSet>
Composantes d'un TileMatrix

Représentation spatiale des informations d’un Tile Matrix

Ce découpage de l’espace en tuile permet de se localiser grâce à des indices (principe du WMTS).

Ainsi, une tuile peut être identifiée avec :

On peut passer des coordonnées aux indices facilement. Cette conversion est utilisée pour identifier les tuiles nécessaires à la construction d’une image à partir de son emprise.

Une pyramide

Une pyramide est constituée d’un ensemble de niveaux dont les images sont toutes dans un SRS donné et de mêmes caractéristiques. Chaque niveau de la pyramide correspond à un TM, quadrillage sur lequel les images sont calées.

Différents produits peuvent être utilisés à des niveaux de pyramide différents (typiquement, des produits scannés d’échelles différentes réunies dans une même couverture).

Si plusieurs pyramides sont destinées à être utilisées en superposition, il est préconisé d’avoir recours à des niveaux de résolution identique. Il est également possible de les fusionner en une unique pyramide, afin d’éviter de recalculer la superposition à chaque fois.

Caractéristiques des images

Les caractéristiques d’une image sont :

Elles doivent être les mêmes pour toutes les images de tous les niveaux d’une pyramide.

Contenu des images

Les images contiennent de la donnée géographique, potentiellement de type différent (ortho-imagerie, cartes…). Peut y être associé un masque, image aux mêmes dimensions et dans une arborescence parallèle, sur un canal de 8 bits, qui permet de distinguer rigoureusement les zones de données des zones d’absence de données.

Les emprises des images suivent toujours le quadrillage du TM. Il est cependant possible de stocker plusieurs tuiles du TM par image (pour le Géoportail, les images contiennent 16 tuiles sur 16, soit 256 tuiles). On parlera alors de dalle dans la suite du document.

Dalles contenant plusieurs tuiles

Exemple de dalle, de 3 tuiles sur 2

Descripteur de pyramide

Le descripteur de pyramide est un fichier XML (extension .pyr) contenant toutes les informations nécessaires au serveur ROK4 pour exploiter la pyramide.

Informations globales

Extrait d’un descripteur de pyramide pour du MNT :

<tileMatrixSet>RGM04UTM38S_10cm</tileMatrixSet>
<format>TIFF_LZW_FLOAT32</format>
<channels>1</channels>
<nodataValue>-99999</nodataValue>
<interpolation>nn</interpolation>
<photometric>gray</photometric>

On notera que le SRS n’est pas renseigné, il l’est indirectement via le TMS.

Informations par niveau

Les niveaux sont renseignés dans l’ordre, du plus haut (moins résolu) au plus bas (meilleure résolution).

Extrait d’un descripteur de pyramide pour un niveau :

<level>
<tileMatrix>level_N</tileMatrix>
<baseDir>chemin relatif/PYRAMIDE/IMAGE/level_N</baseDir>
<mask>
<baseDir>chemin relatif/PYRAMIDE/MASK/level_N</baseDir>
</mask>
<tilesPerWidth>16</tilesPerWidth>
<tilesPerHeight>16</tilesPerHeight>
<pathDepth>2</pathDepth>
<nodata>
<filePath>chemin relatif/PYRAMIDE/NODATA/level_N/nd.tif</filePath>
</nodata>
<TMSLimits>
<minTileRow>8291</minTileRow>
<maxTileRow>8393</maxTileRow>
<minTileCol>1213</minTileCol>
<maxTileCol>1301</maxTileCol>
</TMSLimits>
</level>

Architecture de fichiers

Les données sont rangées dans une arborescence spécifique afin de faciliter la recherche des images utiles. On note que les images de la pyramide ne sont pas intrinsèquement géoréférencées (GeoTiff, tfw…). Le chemin dans l’arborescence tient ce rôle.

Arborescence générale

Toutes les images, que ce soit les données, les tuiles de « nodata » ou encore les masques (et peut-être les maques de métadonnée dans le futur), sont dans un dossier portant traditionnellement le même nom que le descripteur. Elles sont cependant séparées dans des sous arborescences parallèles.

Arborescence des fichiers dans une pyramide raster ROK4

Arborescence générale d’une pyramide ROK4

Règle de nommage des données, masques et métadonnées associées

Indexation des dalles

Nous avons dit que le géoréférencement était implicitement stocké dans le chemin du fichier. À l’instar des tuiles, les dalles sont indexées (colonne, ligne) en partant du coin supérieur gauche définit dans le TMS.

Il faut bien distinguer l’indexation des tuiles (utilisée dans les requêtes WMTS et dans le descripteur de pyramide avec les indices extrêmes) de l’indexation des dalles utilisée pour le nommage des fichiers. Considérons des dalles de données qui contiennent 16 tuiles sur 16, alors la dalle (3, 2) contient toutes les tuiles de (48, 32) à (63, 47).

Pour connaître les indices d’une tuile, on doit connaître (exemple avec un TMS en Lambert 93) :

Paramètres

Définition (source)

Exemple

tileWidth

Largeur d’une tuile en pixel (TM)

256

tileHeight

Hauteur d’une tuile en pixel (TM)

256

imageWidth

Nombre de tuile dans la largeur d’une dalle (descripteur)

16

imageHeight

Nombre de tuile dans la hauteur d’une dalle (descripteur)

16

resolution

Taille au sol d’un pixel (TM)

0,4

X0

Abscisse du coin supérieur gauche, origine du quadrillage (TM)

0

Y0

Ordonnée du coin supérieur gauche, origine du quadrillage (TM)

12000000

X

Abscisse du coin supérieur gauche de la dalle dont on veut les indices

653000

Y

Ordonnée du coin supérieur gauche de la dalle dont on veut les indices

6865000

On obtient donc, pour une dalle dont les coordonnées du coin supérieur gauche sont (X, Y) :

Soit dans notre exemple : (398, 3134).

Codage en base 36 et découpage

Connaissant les indices de la dalle, on les convertit en base 36 (lettres en majuscule).

Base 10

0

1

2

3

4

5

6

7

8

Base 36

0

1

2

3

4

5

6

7

8

Base 10

9

10

11

12

13

14

15

16

17

Base 36

9

A

B

C

D

E

F

G

H

Base 10

18

19

20

21

22

23

24

25

26

Base 36

I

J

K

L

M

N

O

P

Q

Base 10

27

28

29

30

31

32

33

34

35

Base 36

R

S

T

U

V

W

X

Y

Z

Poursuivons notre exemple : (398, 3134) donne (B2, 2F2).

On peut être amené à ajouter des 0 pour forcer la longueur de l’écriture en base 36, pour s’adapter à la profondeur d’arborescence voulue ou avoir la même longueur pour les 2 indices. Ici, on va considérer (0B2, 2F2).

Prenons nos indices en base 36 :

On va découper ces nombre afin de constituer le chemin. Si l’on a une profondeur d’arborescence de 2, avec le fichier, cela nous donne un découpage sur 3 parties. On aura donc préalablement forcer la conversion en base 36 sur au moins 3 caractères.

On obtient le chemin suivant, en relatif à partir de la racine du niveau : C3L3C2L2 / C1L1 / C0L0.tif

Soit dans notre exemple : 02 / BF / 22.tif

Et à partir de la racine de la pyramide : PYRAMIDE / IMAGE / level_N / 02 / BF / 22.tif

Voilà comment ROK4, à partir de coordonnées terrain, identifie les fichiers image à utiliser.

Structure d’une image de la pyramide

Le recours à des dimensions relativement importantes (sur le Géoportail, 4096 x 4096) permet de réduire le nombre de fichiers à gérer, et par conséquent, les impacts liés aux accès disque par le système de fichiers.

Format

Les images sont au format TIFF (Tagged Image File Format). Ce dernier offre de nombreuse possibilité de stockage des données. Le concept principal est de renseigner les différentes informations via des « tags », des champs. On peut ainsi préciser les nombres de canaux, leur format et taille, la photométrie, la structure des données… Toute sorte de métadonnées, rendant possible l’interprétation de l’image par les programmes. Ce document n’a par pour but de reprendre les spécifications du format TIFF, mais de voir globalement les possibilités et préciser celles exploitées.

On va distinguer deux parties dans le fichier : l’en-tête et les données.

En-tête

On retrouve dans cette partie toutes les informations sur le fichier que les logiciels vont utiliser pour afficher l’image.

Détaillons légèrement le fonctionnement d’un tel stockage.

Par exemple, l’étiquette imageWidth (256), de type Long (4), une seule valeur sur 32 bits, elle tient donc sans passer par une adresse : 4096. Ce qui donne en héxadécimal, little endian :

00 01 04 00 01 00 00 00 00 10 00 00

Cependant, ROK4 a déjà connaissance de ces métadonnées car stockées dans le descripteur de pyramide et TMS. On peut donc gagner du temps en ignorant cet en-tête. C’est pourquoi celle-ci fait toujours 2048 octets, quitte à remplir de valeur nulle.

On va enfin trouver dans cet en-tête les informations sur le tuilage, ou plutôt sur l’endroit où ces informations sont stockées (adresses et tailles).

Données

Concept de tuilage

Le format TIFF permet de stocker les images par bloc, ceci dans le but d’accéder efficacement à toutes les parties de l’image. On peut ainsi accéder à chaque tuile contenue dans l’image (dalle) facilement. On conserve bien dans la structure de l’image le découpage en tuile. Chaque tuile est indépendante des autres, formant une image à part entière, moins l’en-tête. Elles sont enregistrées de gauche à droite puis de haut en bas.

Pour ce faire, on renseigne l’adresse de début (TileOffsets) sur 4 octets et la taille en octet (TileByteCounts) sur 4 octets de chaque tuile. Ces valeurs sont stockées à partir de 2048 octets, ce sont les premières valeurs lues par le serveur ROK4.

L’en-tête contient les étiquettes :

De cette manière, que ce soit ROK4 en étêtant de 2048 octets, ou les autres programmes, le tuilage est compris.

Compression des données

Le format TIFF permet de nombreuse compression des données. Cette compression est effectuée sur chaque tuile. ROK4 va comprendre l’absence de compression et les compressions :

Le PNG a une particularité : la compression correspond à du Deflate, mais on veut que ROK4 puisse retourner facilement des tuiles de PNG, avec l’en-tête.

Dans ce cas, les dalles ne sont pas lisible par d’autres applications que ROK4. En annexe, des précisions sur le format PNG.

Récapitulatif

Voici la structure globale d’une image de la pyramide ROK4, dalle contenant N tuiles.

Détails sur le format PNG

Le format PNG est composée d’une signature, suivie de 3 chunks :

Signature PNG

Chunk IHDR

Chunk IDAT

Chunk IEND

La signature PNG comporte 8 octets :

Octet

1

2

3

4

5

6

7

8

Valeur décimale

137

80

78

71

13

10

26

10

Chaque chunk se décompose ainsi en 4 champs :

Chunk IHDR

Champ

Valeur

Taille (octets)

Codage

taille des données

13

4

« big-endian »

type

‘IHDR’

4

ascii

données

Largeur

4

Hauteur

4

Bit depth 1 byte

1

Color type

1

Compression method

1

Filter metho

1

Interlace metho

1

Clé CRC

4

« big-endian »

 Chunk IDAT

Champ

Valeur

Taille (octets)

Codage

taille des données

n

4

« big-endian »

type

‘IDAT’

4

ascii

données

Flux PNG

n

clé CRC

4

« big-endian »

Le flux PNG est la compression par l’algorithme Deflate (RFC 1951) de la tuile brute légèrement modifiée, en y rajoutant simplement un 0 sur un octet au début de chaque ligne (pixels entrelacés dans le cas d’images RGB).

Chunk IEND

Champ

Valeur

Taille (octets)

Codage

taille des données

0

4

« big-endian »

type

‘IEND’

4

ascii

données

0

clé CRC

4

« big-endian »

Paramétrage

Le niveau de compression PNG est réglable via le paramètre « compression speed » de la zlib, implémentation de référence de la compression Deflate.

Glossaire

Cache

Ensemble des images de l’entrepôt de données du serveur WMS/WMTS

Dalle

Image tuilée appartenant à l’entrepôt de données

Niveau

Partie d’une pyramide contenant des images homogènes en résolution

Pyramide

Ensemble d’images dans un SRS donné, organisé en niveaux

Résolution

Dimensions de l’emprise au sol (dans l’unité du SRS) d’un pixel

SRS

Système à Référence Spatiale

TM

TileMatrix, grilles décrivant le découpage des tuiles à une échelle et dans une région données

TMS

TileMatrixSet, ensembles de TM dans un même SRS

Tuile

Partie (bloc) d’une dalle, élément cible d’une requête WMTS

WMS

Web Map Service

WMTS

Web Map Tiling Standard