CartoPartie | Optimisation des données matricielles

Parc du Thabor, Rennes, Ortho 2017-2018

Optimisation d’une orthophotographie aérienne

Les méthodes de représentation des données matricielles peuvent procurer plusieurs avantages, y compris la représentation efficace de surfaces continues, le traitement algébrique rapide des cartes, l’affichage des données de surface et la représentation efficace des données images.

Cependant, les représentations de données matricielles peuvent donner lieu à des ensembles de données très volumineux, en comparaison avec les ensembles de données vectorielles relativement homogènes représentant des phénomènes semblables. Toutefois, certains phénomènes ne sont pas représentés efficacement au moyen du modèle vectoriel et c’est pourquoi, en règle générale, les données matricielles font partie des mises en œuvre contemporaines des OWS.

Le présent document décrit la méthodologie et le résultat des tests réalisés pour l’optimisation de la performance des services : pour améliorer le temps de réponse et l’efficacité des services avec l’orthophoto  2017-2018 de Rennes métropole. Lest données sont accessibles en téléchargement sur data.rennes.fr. De nombreuses stratégies peuvent être utilisées pour optimiser la performance. Les principales techniques utilisées sont les suivantes :

  1. les overview internes
  2. les overview externes
  3. les pyramides d’images (Image Pyramids)

Des outils libres, comme ceux compris dans la distribution GDAL peuvent être utilisés pour générer des pyramides d’images et convertir (gdal.translate) l’imagerie non compressée en format compressé.

La plupart des communautés d’applications logicielles fournissent des directives précises sur la façon d’optimiser les données matricielles et le niveau d’optimisation (par exemple, MapServer, GeoServer).

Dans cette étude, nous utiliserons les commandes de GDAL pour créer la pyramide et les overview mais aussi Geoserver pour stocker les données et Openlayers pour les visualiser.

Process d’optimisation

Le jeu de données est composé de 893 dalles de 1 km x 1 km pour un volume d’environ 33 Go dans le format JPEG 2000 (JP2) pour la résolution 10 cm. Pour optimiser notre orthophoto, nous avons créé une grille. Un maximum de 2 giga par image est recommandée dans la bibliographie pour accroitre les performances de Geoserver.

            En effet, Geoserver peut traiter efficacement avec de grandes images, au niveau des aperçus, tant qu’elles sont en dessous de la limite de taille de 2 Go. Si la cette limite est dépassée, alors il est recommandé de  créer une pyramide  pour maintenir une vitesse d’affichage raisonnable. La pyramide construit plusieurs mosaïques d’images, chacun à un niveau de zoom différent, faisant en sorte que chaque tuile est indexée et stockée dans un fichier séparé.

Pour ne pas dépasser la taille optimale des fichiers dans Geoserver,  nous avons créé  des « BLOCK » de 256*256 pixels avec  une résolution de 2048*2048.

Puis, nous avons testé plusieurs algorithmes de  réchantillonnages , créer des overview internes et externes et une pyramide afin de déterminer lequel de ces trois sera le plus performant  pour servir notre orthophoto.

 Enfin  nous avons comparé la résolution spectrale des algorithmes de réchantillonnage et le temps de réponses des requêtes WMS pour afficher les tuiles.

Analyse des résultats

1/-La résolution spectrale

Nous analyserons ici uniquement la qualité du  rendu  des tuiles. Voici les résultats:

En plus de cette analyse, nous avons constaté des différences notables entre les  niveaux de zoom  notamment en mixant les réechantillonage par exemple cubicspline dans les grandes échelles et lanczos dans les petites échelles. 

Finalement nous avons jugé plus intéressant d’utiliser le lanczos comme algorythme de rééchantillonange pour l’orthophoto.

2-/ La réponse des requêtes WMS

Pour visualiser la performance des aperçus et de la pyramide, nous analyserons les résultats à partir du temps de connexion et de réponse de chaque requête selon le niveau de zoom. Sur ce graphique, nous avons le temps de réponse des requêtes en seconde en ordonnée et le niveau de zoom en abscisse.

Temps de réponse des requêtes wms

La tendance générale montre que plus le niveau de zoom est important, plus des disparités divergent entre le 10cm original qui met le plus de temps pour se connecter à Geoserver et à envoyer une réponse. On constate également une nette performance de l’overview externe par rapport à l’overview externe.

Les overview  sont ici utilisés pour afficher des aperçus de résolutions réduites plus rapidement que pourrait être fait par la lecture de toutes les données en pleine résolution et le sous-échantillonnage. Ce qui explique donc le temps de chargement beaucoup plus rapide que l’ortho original qui est beaucoup plus  lourd à charger pour chaque requête.

Les données raster à haute résolution peuvent ralentir la navigation. En créant des copies des données de plus basses résolutions (des pyramides), les performances sont  considérablement améliorées puisque Geoserver sélectionne la résolution la plus pertinente à utiliser en fonction du niveau de zoom.

Donc, contrairement aux overview, et l’ortho original, la pyramide  est  de loin la plus performante surtout sur les premiers niveaux de zoom puisqu’elle accélère l’affichage des données raster en récupérant uniquement les données à une résolution spécifiée qui est nécessaire pour l’affichage. Avec  la pyramide, une copie basse résolution des données affiche rapidement, lors de l’élaboration, l’ensemble des données.  Lorsque vous zoomez, les niveaux avec des résolutions plus fines sont tirés ; la performance est maintenue quand il s’agit de plus petites zones. Geoserver  choisit le niveau de la pyramide la plus appropriée automatiquement en fonction de l’échelle d’affichage de l’utilisateur.En conclusion, notre choix s’est orienté vers la pyramide avec un algorithme de  rééchantillonage de type LANCZOS.  

Pour aller plus loin, voici les commandes utilisées

Afficher les métadonnées 

Gdalinfo image10cm.tif

Création des BLOCK

Pour optimiser les données, la bibliographie conseille d’utiliser des blocks de 256*256  avec des overview internes ou externes.

Pour créer des blocks vous devez utiliser Gdal_translate qui est l’outil de transformation de GDAL (to translate = transformer, convertir), il sert principalement à changer le format, mais aussi à extraire une dalle à partir d’un raster existant.

gdal_translate -co –r bicubic "TILED=YES" -co "BLOCKXSIZE=256" -co "BLOCKYSIZE=256" "C:\Documents and Settings\a.diouck\Bureau\GDAL\ortho10cm\assemblage\10cm.tif" "C:\Documents and Settings\a.diouck\Bureau\GDAL\ortho10cm\assemblage\100cmblock256.tif"

Overview

Il est simple de créer des overview avec la commande gdaladdo . Ici avec un rééchantillonnage  cubique

Overview Externe

    gdaladdo -r cubic 1329_7218.tif  2 4 8 16 32 64 128

Overview Externe

gdaladdo --config COMPRESS_OVERVIEW DEFLATE 1329_7218.tif  2 4 8 16 32 64 128

Laisser un commentaire