Comprendre et utiliser BE4

Pyramide d’images vous dites…

Une pyramide d’image est un ensemble d’images, classées dans une arborescence de dossiers bien définie, contenant plusieurs fois la même donnée raster mais à des résolutions différentes. Cette structure est la base de travail du serveur WMS/WMTS ROK4. Tous les détails concernant cette architecture de fichiers se trouve ici.

On parle de pyramide car les images sont triées par niveau, c’est-à-dire par résolution. Chaque niveau est d’autant plus léger que la résolution est grande (moins bonne). Ainsi, un niveau de résolution 2m (un pixel représente 2m sur 2m au sol) sera 4 fois plus léger qu’un niveau de résolution 1m (les 2 niveaux couvrent la même étendue mais avec des précisions différentes).

On fera attention à bien distinguer une image de la pyramide, qu’on appellera aussi dalle, d’une tuile, “case” du quadrillage défini dans le TMS. Une dalle pourra contenir plusieurs tuiles.

BE4, kezako ?

BE4 permet de formater des données raster afin qu’elles respectent les spécifications demandées par ROK4. BE4 génère une pyramide d’images. Son nom vient du fait que l’outil intervient avant l’utilisation de ROK4.

Une génération se fait en deux temps :

Que donner à BE4…

De manière générale, on configure une génération en précisant :

… Et comment ?

Toutes ces informations sont transmises à l’outil BE4 via 3 fichiers :

L’appel à la commande BE4 se fait alors de la manière suivante :

be4.pl --conf=prop.txt --env=env.txt

Ces différents fichiers de paramétrage respectent le même format. Les paramètres sont définis au format “propriété = valeur” et peuvent être agencés en sections, définies entre [ crochet ]. Les commentaires sont précédés d’un point-virgule “; blabla bla”, sur une ligne à part.

[ nomDeSection ]

prop1 = val1

;Commentaires
prop2 = val2

Détaillons maintenant le fonctionnement et l’utilisation de tous ces paramètres.

Le Tile Matrix Set

Un Tile Matrix Set est un fichier XML qui définit un quadrillage, une grille (le tuilage), pour plusieurs niveaux (un niveau = une résolution). Les niveaux de la pyramide vont respecter cette grille. C’est donc le TMS qui permet la communication entre BE4 et ROK4.

TMS, entre BE4 et ROK4

Le TMS, garant de la communication entre BE4 et ROK4.

C’est également le TMS qui définit le système de référence natif de la pyramide.

Encore une fois, plus de détails sur le TMS sont présents dans les spécifications d’une pyramide.

Une limitation de BE4 cependant. Bien qu’il n’y ait a priori aucune contrainte sur les niveaux du TMS, BE4 ne gère que 2 types de TMS :

Génération avec TMS "quad tree"

Génération d’une pyramide, avec un TMS “quad tree”

Génération avec TMS "PPV"

Génération d’une pyramide, avec un TMS “plus proche voisin”

De plus, le fichier contenant le TMS doit avoir l’extension .tms ou .TMS.

Voici comment préciser le TMS dans les fichiers de configuration générale, dans la section pyramid :

[ pyramid ]

tms_name = LAMB93_10cm.tms
tms_path = /home/moi/TMS/

Par usage, on met tous les TMS dans le même dossier, la propriété tms_path est mise dans le fichier d’environnement “env.txt” et le nom du TMS tms_name dans “prop.txt”.

Les données en entrée

Qu’est ce qu’une donnée source ?

Une source de données peut être :

Si aucune source d’images n’est donnée, on doit préciser sur quelle étendue la génération doit se faire.

Dans les deux cas, on doit préciser un système spatial, qui sera celui des images sources ou celui de l’étendue.

Et si on en veut plusieurs…

On peut préciser plusieurs sources de données, à utiliser selon les niveaux. Typiquement, on aimerait avoir des cartes avec des sémiologies différentes selon les échelles, donc utiliser des produits SCAN différents selon les niveaux de la pyramide. Cela est possible en une génération.

Utilisations de plusieurs sources de données pour générer une pyramide d’images

On doit d’abord connaître le niveau de base pour chaque source de données, c’est-à-dire le niveau (renseigné grâce à son identifiant, chaîne de caractère) dans le TMS (associé à une résolution) à partir duquel la donnée est utilisée. Le niveau de base est directement généré à partir des données sources alors que les niveaux supérieurs reprennent les niveaux du dessous. Ce fonctionnement permet de reporter les erreurs à des échelles plus petites, ce qui facilite la validation des données générées.

Nous avons vu le niveau du bas, mais jusqu’où génère-t-on ? On utilise une source de données jusqu’à ce que :

En bref :

Une source de données

Une source de données : un ensemble d’informations.

Comment la configurer ?

Toutes les propriétés concernant les sources de données sont listées et expliquées dans la documentation techniques, à cet endroit. Beaucoup de paramètres sont très spécifiques et rarement utilisés. Nous allons voir ici des configurations courantes.

Pour une génération à partir d’une unique source d’images, sans reprojection

On possède des images géoréférencées, en TIFF, non tuilées, dans le système spatial Lambert 93. On veut générer une pyramide dans le même système. La résolution des images est 50cm. On utilise le TMS “LAMB93_10cm”. Dans ce TMS, le niveau “19” (“0″ étant le haut, le moins résolu) est à la résolution 40 cm, on veut partir de là. Les images sont dans le répertoire “/home/moi/data/paris_lamb93_50cm/”. On peut trier les données dans des sous-répertoires. Seuls les fichiers avec les extensions .tif, .tiff, .TIF et .TIFF sont utilisés

On crée donc un fichier “source.txt” qui contient le texte suivant :

; le nom de la section correspond au niveau de base

[ 19 ]

srs = IGNF:LAMB93
path_image = /home/moi/data/paris_lamb93_50cm

Pour une génération à partir d’un service WMS vecteur, avec multi-granularité

On connaît un serveur WMS vecteur mettant à disposition les frontières des pays et les villes sur le monde entier. On aimerait en faire une pyramide d’images (rasterisation des données). Cependant, on veut conserver le comportement suivant. Selon les échelles, on veut avoir une granularité différente : les capitales aux niveaux du haut, puis des villes de plus en plus petite en zoomant. De plus, on veut que les toponymes gardent globalement la même taille, quelque soit le niveau de zoom. Le WMS vecteur gère cela.

On utilise un TMS dans un système mondial : le Pseudo Mercator (EPSG:3857). On va devoir préciser que l’on veut re-moissonner toutes les images à chaque niveau, pour respecter les volontés de granularités différentes. Le cas du WMS vecteur présente quelques particularités :

Nous sommes sur une étendue mondiale (que l’on renseignera en Pseudo Mercator avec une BBOX). Il ne faut pas partir d’un niveau trop bas. On commencera à 8 (environ 600m en résolution).

Voyons ce que cela donne, dans notre fichier “source.txt” :

; le nom de la section correspond au niveau de base

[ 8 ]
srs = EPSG:3857

; Étendue géographique sur laquelle on moissonne : ici, nous avons une BBOX représentant le monde
extent = -19981848,-12932243,19981848,12932243

; partie obligatoire pour tout WMS (vecteur ou raster)
wms_layer   = NATURALEARTH
wms_url     = http://server.wms.com
wms_version = 1.3.0
wms_request = getMap
wms_format  = image/png

; définition des paramètres de la rasterisation, style, couleur de fond...
wms_style  = line
wms_bgcolor  = 0x80BBDA
wms_transparent  = false

; si la dalle moissonnée a une taille inférieure à cette valeur, on ne la garde pas
min_size = 256000

; on ne moissonne pas d'image plus grande que ça. Si on veut une image 4096x4096, on la moissonne en 16 fois
; doit être un diviseur de la largeur de la dalle finale
max_width = 1024
; doit être un diviseur de la hauteur de la dalle finale
max_height = 1024

; on répète tout pour les niveaux du dessus, afin de forcer BE4 à re-moissonner chaque niveau

[ 7 ]
srs = EPSG:3857
extent = -19981848,-12932243,19981848,12932243
wms_layer   = NATURALEARTH
wms_url     = http://server.wms.com
wms_version = 1.3.0
wms_request = getMap
wms_format  = image/png
wms_style  = line
wms_bgcolor  = 0x80BBDA
wms_transparent  = false
min_size = 256000
max_width = 1024
max_height = 1024

[ 6 ]
srs = EPSG:3857
extent = -19981848,-12932243,19981848,12932243
wms_layer   = NATURALEARTH
wms_url     = http://server.wms.com
wms_version = 1.3.0
wms_request = getMap
wms_format  = image/png
wms_style  = line
wms_bgcolor  = 0x80BBDA
wms_transparent  = false
min_size = 256000
max_width = 1024
max_height = 1024

[ 5 ]
srs = EPSG:3857
extent = -19981848,-12932243,19981848,12932243
wms_layer   = NATURALEARTH
wms_url     = http://server.wms.com
wms_version = 1.3.0
wms_request = getMap
wms_format  = image/png
wms_style  = line
wms_bgcolor  = 0x80BBDA
wms_transparent  = false
min_size = 256000
max_width = 1024
max_height = 1024

L’ordre dans lequel les sources sont définies n’a pas d’importance, seuls les niveaux de base (nom des sections) sont utilisés pour connaître la source selon le niveau.

On fait référence au fichier “source.txt” dans le fichier de configuration général de BE4, dans la section datasource :

[ datasource ]
filepath_conf = source.txt

Paramétrage des pyramides

Tous les paramètres concernant cette partie sont détaillés dans la documentation technique (valeurs possibles…). Ils sont tous à mettre dans un fichier  de configuration général (prop.txt ou env.txt), dans la section pyramid.

Chemins pour la nouvelle pyramide

On commence par donner le nom de notre nouvelle pyramide. Celui ci sera utilisé pour nommer de nombreux dossiers afin de différencier les générations (et éviter les écrasements de données). PAS D’ESPACES.

pyr_name_new = ma_nouvelle_pyramide

Deux répertoires à préciser :

pyr_data_path = /home/moi/pyramids/data
pyr_desc_path = /home/moi/pyramids/descriptors

Avec un telle configuration, on aura l’arborescence de fichiers suivante :

Emplacements des divers éléments générés par BE4

Caractéristique de la nouvelle pyramide

On va également configurer le format de sortie, c’est-à-dire décrire le contenu d’une image, sa taille, comment l’interpréter… Voici une configuration classique, pour des photos aériennes sur 3 canaux (16 millions de couleur), en RVB :

; Nombre de tuiles dans une image de la pyramide (dalle)
image_width = 16
image_height = 16

; On précise la profondeur d'arborescence pour stocker les données, cela influe directement sur l'indexation des fichiers utilisée
dir_depth = 2

; pas de compression
compression = raw
bitspersample = 8
sampleformat = uint
photometric = rgb
samplesperpixel = 3
interpolation = bicubic
; nodata blanc
color = 255,255,255

Et l’ancêtre, pour une mise à jour

Un des intérêts de BE4 est de pouvoir mettre à jour une pyramide avec de nouvelles données. Cela permet de ne pas re-générer l’ensemble mais que la zone voulue.

Techniquement, BE4 va importer les images de la pyramide ancêtre dans la nouvelle pyramide avec des liens symboliques (il utilise la liste de contenu de l’ancienne pyramide pour ne pas avoir à parcourir toute l’arborescence). Si une dalle est concernée par les nouvelles données, on utilise l’ancienne donnée comme fond et on écrase avec la nouvelle (cette dalle deviendra alors un vrai fichier de la nouvelle pyramide).

Il parait alors évident qu’une pyramide de mise à jour a les même caractéristiques que l’ancienne. On récupère donc au maximum les paramètres à partir de l’ancienne pyramide, de son descripteur (pas besoin de mettre tous les paramètres dans les fichiers de configuration, ils seront écrasés).

On précise la localisation de l’ancienne pyramide (comme pour la nouvelle) :

pyr_name_old = mon_ancienne_pyramide
pyr_data_path_old = /home/moi/data/
pyr_desc_path_old = /home/moi/descriptors/

Paramétrage de la génération

Nous avons vu jusqu’ici comment paramétrer le résultat de la génération. Il y a cependant certaines informations qui concernent la génération en elle-même. Ces paramètres sont dans la section process. On répond aux questions :

[ process ]
path_shell = /home/moi/scripts/generation1
; Temporaires différents
path_temp = /home/moi/tmp
path_temp_common = /mnt/partage/tmp
; Temporaires au même endroits
path_temp = /home/moi/tmp
path_temp_common = /home/moi/tmp
job_number = 4
[ logger ]
log_level = INFO
log_path = /tmp/log/be4
log_file = log.txt

Voyons l’état de l’arborescence avec une telle configuration (temporaires au même endroit, génération d’une pyramide “quad tree”) :

Arborescence de travail de la génération

Ici, les scripts SCRIPT_1.sh, SCRIPT_2.sh, SCRIPT_3.sh et SCRIPT_4.sh peuvent être exécutés en même temps et SCRIPT_FINISHER.sh doit être exécuté tout seul, après que le dernier script a terminé.

Conclusion

Nous avons fait le tour général de l’outil BE4, de son fonctionnement et de son paramétrage. Pour les paramètres qui ne concernent pas les sources de données, leur répartition entre le fichier de propriété et le fichier d’environnement dépend de l’utilisation que vous en aurez.

Rien ne vaut un exemple, voir plusieurs

À partir d’image géoréférencées

Voici un premier exemple concret : génération d’une pyramide de SCAN 1000, avec reprojection et masques de données (données en démonstration de ROK4).

Contenu du dossier du tutoriel, avant toute utilisation

be4.pl --conf=proprietes.txt --env=environnement.txt

Sortie de be4.pl, sur la console

Contenu du dossier du tutoriel, après avoir exécuté la commande perl be4.pl

bash scripts_be4/SCRIPT_1.sh
bash scripts_be4/SCRIPT_2.sh
bash scripts_be4/SCRIPT_3.sh
bash scripts_be4/SCRIPT_FINISHER.sh
create-layer.pl --pyr=pyramids/descriptors/SCAN1000_PYR-JPG_FXX_PM.pyr --tmsdir=./ --layerdir=/opt/rok4/config/layers

Ici, toutes les commandes ont été (et doivent être) lancées depuis le dossier Tuto_1_SCAN1000 car tous les chemins étaient renseignés en relatif. Donnez les chemins en absolu et vous pourrez lancer les commandes et scripts depuis là où vous voulez. C’est d’ailleurs l’utilisation que nous conseillons.

Et voici la visualisation sous Quantum GIS, en utilisant le flux WMTS :

 

Visualisation des données SCAN1000 via un flux WMTS

À partir d’un flux WMS

Un second exemple, utilisant un moissonnage de données depuis un WMS. Nous allons générer une pyramide de MNT, en teinte hypso + estompage. Pour cela, nous allons utiliser une pyramide de données flottantes, diffusée en WMS par le serveur ROK4, avec application de styles.

Cet exemple va nous amener à étudier plusieurs paramètres, dans les configurations du serveur ROK4 et de ses couches.

Étape 1 : publication des données MNT avec styles, via ROK4

Commençons par télécharger le jeu de données.

Nous allons générer la pyramide de données flottantes. La procédure est la même que pour l’exemple précédant.

 

Contenu du dossier avant génération

Contenu du dossier après génération

Vous allez diffuser ces données grâce au ROK4 que vous avez déployé (à faire si ce n’est déjà fait). Deux descripteurs de couches sont présents dans le dossier “layers” :

Ces deux couches utilisent la même pyramide d’images, mais avec des paramètres différents. Ces descripteurs de couches doivent être déposés dans le dossier utilisé par ROK4 (/opt/rok4/config/layers par défaut), et le champ <pyramid> doit être mis à jour avec la valeur effective du chemin vers le descripteur de pyramide :

&lt;pyramid&gt;.../Tuto_2_MNT/pyramids/descriptors/BDALTI_PYR-ZIP_FXX_PM.pyr&lt;/pyramid&gt;

Pour pouvoir demander 2 couches dans une même requête, il faut modifier un paramètre du serveur ROK4. Celui-ci se trouve dans le fichier “services.conf” (/opt/rok4/config/services.conf par défaut) : <layerLimit>, à 1 par défaut. Mettez 2.

Vous pouvez maintenant redémarrer votre serveur ROK4, afin de prendre toutes les modifications en compte.

Les données MNT sont disponibles en WMS, avec les styles voulus (hypso et estompage). Il ne reste plus qu’à générer la pyramide d’image par moissonnage.

Étape 2 : génération de la pyramide d’images par moissonnage

Téléchargeons les configurations