Desktop Help 10.0 - Chargement de jeux de données raster volumineux dans ArcSDE

Cette rubrique s'applique uniquement à ArcEditor et ArcInfo.

Compte tenu de la nature des données, les rasters ont tendance à être volumineux. Les jeux de données raster et les catalogues d'images occupent rarement moins de quelques gigaoctets (Go), voire plusieurs téraoctets (To) dans vos systèmes de gestion de base de données (SGBD). Aussi, le traitement d'une telle quantité de données présente-t-il des difficultés pour les administrateurs de base de données, même les plus chevronnés. Cette rubrique vous explique les étapes élémentaires pour charger de grandes quantités de données raster dans un jeu de données raster ou un catalogue d'images. Nous supposons que vous avez déjà pris la décision de stocker vos rasters dans une géodatabase ArcSDE.

La création de bases de données raster de grand volume se décompose en trois processus : la préparation du chargement des données, le chargement des données, la vérification et la validation du produit final. Pour ce faire, les tâches suivantes doivent être effectuées :

Préparation du chargement des données

Configuration du système
Estimation de l'espace de stockage du SGBD
Allocation de l'espace de stockage du SGBD

Chargement des données

Préparation des données source
Création de l'objet raster
Chargement de données raster dans le raster
Génération des statistiques SGBD
Génération des statistiques raster

Vérification et validation

Affichage du produit fini

Configuration du système

La configuration de votre système vise à deux objectifs : configurer le SGBD et configurer ArcSDE.

Configuration des paramètres de votre SGBD

La configuration de chaque SGBD pris en charge par ESRI est unique. Cependant, l'objectif est toujours le même, à savoir : augmenter, autant que possible, le débit de données dans la base de données. Pour charger de grandes quantités de données raster, les performances du SGBD doivent être optimisées en écriture ; cependant un SGBD optimisé pour le chargement de plusieurs gigaoctets de données raster, voire davantage, peut nuire aux performances d'autres applications qui utilisent les mêmes ressources pour exécuter d'autres tâches. Dès lors, si le SGBD n'est pas dédié au chargement de données raster, il est conseillé d'envisager la reconfiguration du système et de charger les données en dehors des heures de bureau afin d'éviter toute incidence négative sur le travail des autres utilisateurs ou la création d'une instance distincte du SGBD dédiée au chargement des données raster.

Plusieurs consignes s'appliquent au stockage des données raster dans SQL Server, Oracle, DB2 et Informix. Les informations ci-dessous mettent en évidence les renseignements disponibles dans chacun de ces guides.

Configuration des paramètres de votre SGBD SQL Server

Gérez les ressources utilisées par SQL Server si d'autres applications s'exécutent sur le serveur.
Utilisez la méthode de groupage léger pour réduire le nombre de commutateurs de contexte de thread.
Lorsque cela s'avère possible, optez pour un modèle de récupération de base de données simple. Cela est dû au fait que la récupération à un point spécifique dans le temps n'est pas nécessaire pendant le chargement des jeux de données raster et que le fait de poursuivre toute la journalisation augmente inutilement la taille des fichiers journaux.
Désactivez les options de fermeture et de réduction automatiques, dans la mesure où elles peuvent avoir une incidence négative sur les performances.

Pour en savoir plus, reportez-vous à la rubrique Jeux de données raster et catalogues d'images d'une géodatabase dans SQL Server.

Configuration des paramètres de votre SGBD Oracle

Configurez l'intervalle des points de vérification de sorte qu'il se déclenche uniquement pendant un commutateur "online redo log". Les administrateurs de base de données Oracle définissent les paramètres d'initialisation Oracle LOG_CHECKPOINT_INTERVAL et LOG_CHECKPOINT_TIMEOUT sur 0. Cela a pour effet de forcer le déclenchement du point de vérification au cours d'une commutation de consignation au journal.
Définissez la taille de chaque fichier "online redo log" sur au moins 1 Go.
Augmentez la taille du cache des tampons des blocs de données de sorte qu'il contienne les blocs impropres. Pour ce faire, définissez une valeur supérieure pour DB_BUFFER_CACHE.
Créez la base de données Oracle avec une taille de bloc de 8 Ko. Ceci est la taille de bloc optimale pour le stockage des données BLOB. Ces données sont devenues le type de stockage par défaut sous-jacent de toutes les données binaires ArcGIS. L'utilisation d'une taille de bloc plus importante (16 ou 32 Ko) provoquera vraisemblablement une perte d'espace dans les segments LOG du BLOB. Pour comprendre véritablement le stockage des données BLOB, consultez votre documentation Oracle.

Pour en savoir plus, reportez-vous à la rubrique Jeux de données raster et catalogues d'images d'une géodatabase stockée dans Oracle.

Configuration des paramètres de votre SGBD DB2

Créez des pools de mémoires tampons distincts pour les tablespaces de rasters.
Créez un pool de mémoires tampons de grande taille pour le tablespace accueillant la table des blocs raster.
Si DB2 est installé sur une plate-forme AIX, définissez les paramètres suivants :

db2set DB2_MMAP_READ=OFF
db2set DB2_MMAP_WRITE=OFF

Pour en savoir plus, reportez-vous à la rubrique Jeux de données raster et catalogues d'images d'une géodatabase dans DB2.

Configuration des paramètres de votre SGBD Informix

Configurez les paramètres onconfig.

Définissez BUFFERS sur une valeur suffisamment élevée pour devancer les nettoyeurs.
Définissez LOGSIZE sur 100000.
Assurez-vous que le journal physique n'a pas été créé dans le dbspace rootdbs.
Configurez LOG_BACKUP_MODE de manière à sauvegarder les journaux logiques de façon continue.
Définissez LOGSMAX sur 100.
Définissez RA_PAGES sur 125.
Définissez RA_THRESHOLD sur 85.
Définir RESIDENT sur -1.
Si vous avez l'intention d'utiliser des connexions directes, définissez le paramètre NETTYPE de manière à privilégier les connexions distantes.

Pour en savoir plus, reportez-vous à la rubrique Jeux de données raster et catalogues d'images d'une géodatabase dans Informix.

Configuration du serveur ArcSDE

ArcSDE utilise des tampons de transport pour transférer des données entre le client ArcSDE et le serveur ArcSDE. Dans le cadre d'une opération d'écriture, lorsque le tampon de données côté client atteint son seuil, il est purgé vers le serveur ArcSDE. Tandis que le serveur ArcSDE traite ce tampon, le client ArcSDE accepte des données supplémentaires dans son tampon. Le client renvoie son tampon une fois le seuil atteint mais seulement si le serveur ArcSDE est en attente. Pour les données raster, la taille du tampon de transport est contrôlée par le paramètre serveur ArcSDE RASTERBUFSIZE. Par défaut, ce paramètre est défini sur 200 Ko, ce qui constitue une taille adéquate pour la plupart des opérations de chargement. ArcSDE alloue la quantité de mémoire spécifiée par RASTERBUFSIZE afin de doubler les tampons sur le client et le serveur ArcSDE. Dès lors, si vous utilisez la valeur par défaut recommandée de 200 Ko, 400 Ko sont alloués au client et 400 Ko au serveur. Outre les tampons de transport, ArcSDE alloue trois autres tampons sur le serveur pour les données lues et écrites sur et depuis le SGBD. Cela a pour effet de porter la quantité totale de mémoire allouée au serveur à 1 000 Ko. Si vous utilisez une connexion directe, la fonctionnalité du client et du serveur ArcSDE s'exécute sur la machine client ; la mémoire allouée par une connexion directe équivaut donc à sept fois la taille spécifiée par RASTERBUFSIZE. Il est conseillé de ne modifier la taille du paramètre RASTERBUFSIZE que si sa taille par défaut n'est pas suffisante pour contenir une tuile raster non compressée. La taille non compressée d'une tuile raster peut être calculée en multipliant sa largeur par sa hauteur et en ajustant l'espace par pixel. Par exemple, si vous utilisez les valeurs par défaut de 128 par 128 pour la largeur et la hauteur de la tuile, le produit de ces deux valeurs est 16 384. Pour obtenir la taille non compressée de la tuile raster, multipliez ce produit par le facteur d'espace par pixel issu du tableau ci-dessous. Si l'espace par pixel est de 32, la taille non compressée calculée sera de 65 536 octets, c'est-à-dire bien en deçà de la valeur par défaut de 200 Ko. Cependant, si vous décidez d'augmenter la taille de tuile à 256 par 256, la taille non compressée atteindra 262 144 octets. Si vous n'augmentez pas la taille du paramètre RASTERBUFSIZE, vous risquez d'obtenir une erreur SE_RASTER_BUFFER_TOO_SMALL (-294). Dans ce cas, il est nécessaire d'augmenter la taille du paramètre RASTERBUFSIZE en lui affectant une valeur approximative de 300 Ko.

Espace par pixel	Facteur d'espace par pixel
1 bit	0,125
4 bits	0,25
8 bits	1
16 bits	2
32 bits	4
64 bits	8

Liste de facteurs d'espace par pixel pour les espaces par pixel

Pour modifier le paramètre RASTERBUFSIZE, utilisez l'outil d'administration sdeconfig d'ArcSDE avec l'option alter :

sdeconfig -o alter -v RASTERBUFSIZE=10240000 -u sde -p esri

La modification porte en réalité sur la table SDE.SERVER_CONFIG où est stockée la nouvelle valeur. Cette valeur affecte toutes les sessions ArcSDE qui se connectent après la modification du paramètre.

Il est conseillé de ne pas augmenter le paramètre RASTERBUFSIZE au-delà de la valeur requise pour contenir la taille de tuile raster non compressée. La sélection d'un paramètre trop important peut, en fait, nuire au flux des données raster dans le système.

Architecture de connexion

La construction d'une pyramide de résolution réduite est une opération multithread qui sollicite énormément le processeur. Cette tâche est effectuée par la fonctionnalité du serveur ArcSDE. En plaçant cette fonctionnalité sur la machine la plus puissante de votre architecture client/serveur, vous obtiendrez un meilleur débit des données raster dans la base de données. Pour déterminer la puissance de traitement, on multiplie le nombre de processeurs par leur vitesse.

Les fonctionnalités serveur peuvent soit s'exécuter de manière autonome, comme c'est le cas lors d'une connexion à un service ArcSDE, soit être incorporées dans l'application client (ArcCatalog, par exemple), comme lorsque vous établissez une connexion directe.

Selon que la puissance de traitement est plus importante sur la machine client ou sur le serveur qui héberge le service ArcSDE, on détermine s'il y a lieu d'utiliser ou non une connexion directe pour le chargement des données raster. Pour créer les pyramides sur la machine client, si celle-ci est plus puissante, utilisez une connexion directe.

Vous devez également tenir compte de la capacité de la machine serveur à héberger le service ArcSDE. Même si elle est plus puissante que la machine client, il se peut qu'elle soit proche de la limite de service des demandes en provenance d'autres applications. Si la machine serveur est plus puissante que la machine client et n'a pas atteint cette limite, connectez-vous au service ArcSDE.

Estimation de l'espace de stockage du SGBD

Il est conseillé d'organiser l'espace de stockage de votre SGBD avant de lancer un vaste projet de chargement de données raster. Pour ce faire, vous devez obtenir une estimation de l'espace nécessaire au stockage des données raster dans la base de données, ainsi que de tout espace requis pour mettre les fichiers image en attente avant leur chargement. Après avoir estimé l'espace disque nécessaire, vous pouvez allouer l'espace SGBD, définir les paramètres ArcSDE DBTUNE et commencer le chargement de vos données raster.

La table BLK du raster est incontestablement l'objet le plus volumineux parmi les tables et index du raster. Elle est généralement 150 fois plus grande que le second objet SGBD le plus grand, à savoir l'index composite de la table des blocs raster. Les autres tables et index de l'objet raster sont plusieurs milliers de fois plus petits et sont généralement associés à l'index composite de la table des blocs raster au sein d'un seul espace de stockage SGBD. Vu la taille de la table des blocs raster par rapport à tous les autres objets, c'est sur elle qu'est axée l'opération d'estimation des données raster.

Pour les jeux de données raster et les catalogues d'images, les données de pixels sont stockées à l'intérieur du SGBD dans la table BLK. En revanche, les mosaïques référencent les jeux de données raster et ne stockent pas les données de pixels dans la table BLK. La table BLK reste vide à moins que les vues d'ensemble de la mosaïque soient stockées dans le SGBD.

Il existe deux méthodes de base pour estimer la quantité d'espace occupée par une table de blocs raster dans la base de données. L'une d'elles suppose le chargement de quelques échantillons d'image et l'extrapolation de l'espace total que la table devrait occuper dans la base de données à partir de l'espace occupé par l'échantillon. Une autre méthode tente de calculer l'espace requis sur la base d'une formule qui accepte, comme entrées, les propriétés de l'objet raster attendu. En règle générale, la première méthode donne une meilleure estimation. Cependant, la seconde méthode se révèle particulièrement utile lorsque les données source ne sont pas disponibles avant la construction de la base de données. Pour estimer avec précision la taille d'une table de blocs raster, il faut que vous ayez préalablement déterminé les propriétés suivantes qui en affectent la taille de stockage :

Pour en savoir plus sur le rassemblement des informations de base sur un jeu de données raster

Estimation de la taille de la table des blocs raster sur la base d'un échantillon

Créez un petit objet raster en chargeant un certain nombre de jeux de données raster d'échantillon avec ArcCatalog. L'objet raster doit avoir les mêmes propriétés que l'objet final qu'il va représenter : type de compression, qualité de compression, espace par pixel, nombre de canaux et taille de tuile. Ces propriétés affectent la taille de stockage d'un objet raster dans la base de données.

Après avoir chargé un échantillon de données raster à l'aide d'ArcCatalog, déterminez l'espace occupé par la table des blocs de l'objet raster dans la base de données.

Pour effectuer cette opération dans Oracle, interrogez la colonne BLOCKS de la table système USER_TABLES relative aux blocs raster de l'objet raster. Pour cela, vous devez d'abord déterminer le nom de cette table, ce qui vous oblige à obtenir la propriété rastercolumn_id dans la table SDE.RASTER_COLUMN.

Remarque :

dans les exemples suivants, il est supposé que l'exemple de table métier de l'objet raster se nomme EARTH.

Obtenez la propriété rastercolumn_id pour l'objet raster.

SQL> select rastercolumn_id
from sde.raster_columns
where table_name = 'EARTH';

RASTERCOLUMN_ID 
=--------------- 
             14

Obtenez la taille de la table des blocs raster à l'aide de la requête ci-dessous.

SQL> exec dbms_stats.gather_table_stats (NULL,'EARTH'); 
SQL> select sum(length(rasterband_id)) 
          + sum(length(rrd_factor))
          + sum(length(row_nbr))
          + sum(length(col_nbr))
          + sum(length(block_data)) "total size"
      from sde_blk_14; 
total size 
=----------- 
762707968

La taille totale de la table des blocs raster est de 762 707 968 octets ou d'environ 727 Mo.

Déterminez le ratio entre la taille du jeu de données raster d'échantillon et la taille totale de tous les fichiers de jeu de données raster source que vous êtes sur le point de charger. La taille de cet échantillon est d'environ 2 Go, alors que la taille approximative de tous les fichiers de jeu de données raster en provenance du fournisseur de données est de 3 To.

Commencez par convertir les 3 téraoctets de la taille de fichier totale en gigaoctets :
```
3 TB * 1024 = 3072 GB
```
Le ratio entre la taille totale du jeu de données raster et la taille de l'échantillon est calculé comme suit :
```
total size of all rasters / sample raster size = total size to sample size
```
Par exemple :
```
3072 / 2 = 1536
```
La multiplication de ce résultat par la taille de l'échantillon stocké dans la base de données permet d'obtenir une estimation approximative de l'espace disque total nécessaire au stockage de tous les fichiers du jeu de données raster dans l'objet raster.
```
727 MB * 1536 = 1,116,672 MB = 1090 GB = 1.06 TB
```

Pour déterminer la taille de l'échantillon dans SQL Server, vous devez d'abord obtenir cette taille, puis revenir à l'étape 3 ci-dessus.

Obtenez la propriété rastercolumn_id pour le raster.

1> select rastercolumn_id 
2> from sde.sde_raster_columns 
3> where table_name = 'EARTH';

rastercolumn_id 
=--------------
              3

Utilisez l'ID pour déterminer l'espace utilisé par les données d'échantillon.
```
1> exec sp_spaceused 'sde_blk_3'; 
2> go 
name        rows   reserved   data       index_size  used
=--------------------------------------------------------------
SDE_blk_3   4233   29712 KB   29632 KB   16 KB       64 KB
```
Dans ce cas, la taille du jeu de données raster d'origine était de 50 Mo. Cependant, une fois le chargement effectué, l'espace utilisé est de 29 632 Ko + 16 Ko = 29 648 Ko, soit environ 29 Mo.

Estimation de la taille de la table des blocs raster sur la base d'une formule

La méthode décrite ci-après vous donne une estimation approximative de la taille de la table des blocs raster. Si les données source sont disponibles en partie ou en totalité, il est conseillé d'utiliser la méthode décrite précédemment pour obtenir une estimation plus précise de votre table des blocs raster.

Obtenez une estimation approximative de l'étendue, exprimée en mètres ou en pieds. Pour les jeux de données raster dont la résolution de pixel est exprimée en mètres (5 mètres, 15 mètres ou 150 mètres, par exemple), l'estimation doit être obtenue dans cette unité. Cette consigne vaut également si la résolution est exprimée en pieds ou en pouces. La création d'un contour surfacique de l'étendue d'image à l'aide d'ArcMap constitue un bon moyen pour connaître l'étendue. Vous devez éliminer autant d'espace vide que possible, dans la mesure où la géodatabase ne stocke pas les blocs vides.
Convertissez l'étendue en pixels.
```
(Extent of raster in pixel units) / (pixel resolution) = Number of pixels
```
Dans le cas des jeux de données raster source d'une résolution de 15 mètres et d'une étendue de 450 kilomètres carrés, la conversion en pixels est calculée comme suit :
```
(km² to m² conversion factor) / (the pixel resolution in m²) = pixels
(450 km² * 1,000,000) / (15 x 15) = 2,000,000 pixels
```
Prenons un autre exemple : une étendue de 50 miles carrés avec une résolution de 1 pied. L'étendue de pixel estimée est environ :
```
(mi² to ft² conversion factor) / (the pixel resolution in ft²) = pixels
(50 mi² * 5280²)/ (1 x 1) = 1,393,920,000 pixels
```
Multipliez le résultat par le nombre de canaux. Vous pouvez ignorer cette étape s'il s'agit d'un jeu de données raster noir et blanc ou en nuances de gris monocanal. Pour cet exemple, supposons que les données de 15 mètres issues de l'étape 2 aient trois canaux (représentant RVB).
```
2,000,000 pixel extent * 3 bands = 6,000,000 pixels
```
Effectuez une conversion en octets en appliquant le facteur d'espace par pixel indiqué dans le tableau ci-dessous.
Espace par pixel
Facteur d'octet
1 bit
0,125
4 bits
0,25
8 bits
1
16 bits
2
32 bits
4
64 bits
8
Liste des facteurs d'octet de pixel pour les espaces par pixel
```
8-bit data: 6,000,000 pixels * 1 = 6,000,000 Bytes / 1024² = 5.7 MB
16-bit data: 6,000,000 pixels * 2 = 12,000,000 Bytes / 1024² = 11.4 MB
```
Ajoutez la pyramide de résolution réduite. Cette pyramide augmente d'un tiers la taille du raster. Vous devez donc multiplier le nombre d'octets obtenu à l'étape 4 par 1,33.
```
5.72 MB * 1.33 = 7.67 MB
```
Appliquez la compression raster. La table suivante vous donne un exemple des gains attendus pour une compression et une qualité données. Les valeurs exactes dépendent des données utilisées.
Type de compression
Facteur de compression
LZ77
0,5
JPEG 75 %
0,15
JPEG 50 %
0,1
JPEG 2000 80/100
0,36
JPEG 2000 60/100
0,15
JPEG 2000 55/100
0,11
JPEG 2000 50/100
0,07
JPEG 2000 45/100
0,06
Facteurs de compression pour les types de compression
En vous basant sur l'exemple de l'étape 5 et en appliquant une compression JPEG avec une qualité de 50 %, multipliez le nombre d'octets par le facteur de compression 0,1.
```
7.67 MB * 0.1 = 0.77 MB
```
Augmentez l'estimation de la surcharge système du SGBD et les colonnes d'entiers de la table des blocs raster. La valeur de l'étape 7 est une estimation de l'espace absolu nécessaire aux données de pixel stockées dans la table des blocs raster. Les pixels sont divisés en blocs selon la taille de tuile sélectionnée lors de la création de l'objet raster. Ces blocs de pixels sont stockés dans les blocs de données de la base de données. Les blocs raster ne s'adapteront pas parfaitement en raison de la variabilité de la compression. Il y aura toujours une certaine quantité d'espace inutilisé pour les blocs. La table des blocs raster stocke, en outre, quatre colonnes d'entiers, en plus de colonne BLOB de pixels, afin d'identifier chaque bloc de manière unique. Ces colonnes augmentent également la surcharge de stockage. Augmentez l'estimation obtenue à l'étape 7 d'au moins 10 % afin de tenir compte de la surcharge système du SGBD et des colonnes d'entiers de la table des blocs raster.

Type de compression	Facteur de compression
LZ77	0,5
JPEG 75 %	0,15
JPEG 50 %	0,1
JPEG 2000 80/100	0,36
JPEG 2000 60/100	0,15
JPEG 2000 55/100	0,11
JPEG 2000 50/100	0,07
JPEG 2000 45/100	0,06

Allocation de l'espace de stockage du SGBD

La méthode de création de l'espace de stockage du SGBD dépend du mode de gestion que vous utilisez. Certains SGBD vous permettent de déplacer les fichiers de données d'une base de données, de sorte que vous puissiez stocker l'ensemble des index et des tables dans un même espace. Si le transfert de données n'est pas une priorité, créez l'espace de stockage en fonction du critère taille : grand pour la table des blocs et son index et plus petit pour les autres tables raster et leurs index.

Certains SGBD permettent une croissance automatique de l'espace du SGBD ; vous devez cependant préallouer l'espace pour être sûr de ne pas rencontrer de problèmes lors du chargement. Puisque vous vous êtes donné la peine d'estimer l'espace nécessaire aux données, vous pouvez également leur allouer de l'espace.

Création de l'espace de stockage du SGBD Oracle

Créez le tablespace de blocs non-raster.

create tablespace earth
datafile 'd:\oradata\earth.dbf'
size 500M
extent management local 
uniform size 1M;

Créez le tablespace de blocs raster.

create tablespace earth_blocks
datafile 'e:\oradata\earth_blocks.dbf'
size 50000M
extent management local
segment space management manual
uniform size 100M;

Création de l'espace de stockage du SGBD SQL Server

Créez une base de données SQL Server suffisamment grande pour stocker tout l'objet raster.

Création de l'espace de stockage du SGBD DB2

Créez un tablespace dans lequel seront stockées toutes les données des blocs non-raster.
```
create tablespace earth managed by database using (file 'd:\earth.dat' 500000);
```

Créez un tablespace dans lequel seront stockées les données de la table des blocs raster.

create long tablespace earth_blocks managed by database
using (file 'e:\earth_blocks.dat' 50000000);

Création de l'espace de stockage du SGBD Informix

Créez le dbspace dans lequel seront stockées toutes les tables des blocs non-raster.
```
onspaces -c -d earth -p d:\earth.dbs -o 0 -s 5000
```
Créez le ou les dbspace dans lesquels sera stockée la table des blocs raster.
```
onspaces -c -d earth_blocks -p e:\earth_blocks.dbs -o 0 -s 50000000
```

Configuration des mots-clés DBTUNE

La table SDE.DBTUNE contient les paramètres de stockage utilisés par ArcSDE pour créer des tables et des index dans la base de données. Ces paramètres sont organisés par mot-clé. En spécifiant le mot-clé DBTUNE lors de la construction d'un objet de géodatabase, tel qu'un raster, vous indiquez la manière dont les tables et index de cet objet doivent être créés, ainsi que l'unité de stockage de base de données dans laquelle ils seront situés.

Il existe un paramètre de stockage DBTUNE pour chaque combinaison de table et d'index du raster. Vous devrez modifier le fichier SDEHOME/etc/dbtune.sde en ajoutant un nouveau mot-clé suivi de la spécification relative à chaque paramètre de stockage. Quelques exemples sont illustrés ci-dessous. Vous devrez ensuite utiliser l'opération d'importation sdedbtune pour mettre à jour la table SDE.DBTUNE.

Les paramètres de stockage varient en fonction du SGBD. Les onze paramètres de stockage DBTUNE Oracle sont répertoriés ci-dessous ; nombre d'entre eux sont toutefois communs à d'autres SGBD.

Le paramètre de stockage de la table métier est B_STORAGE. Si cette table contient une colonne avec un ID de ligne enregistré ArcSDE, le paramètre de stockage correspondant est B_INDEX_ROWID. La table métier d'un jeu de données raster contient une seule ligne et est, par conséquent, très petite. Il en va généralement de même pour la table métier d'un catalogue d'images qui contient une seule ligne pour chaque jeu de données raster.
Exemples des paramètres de stockage B_STORAGE et B_INDEX_ROWID :
```
B_STORAGE "PCTFREE 0 INITRANS 4 TABLESPACE EARTH"
B_INDEX_ROWID "PCTFREE 0 INITRANS 4 TABLESPACE EARTH"
```
Le stockage de la table raster est contrôlé par le paramètre RAS_STORAGE, tandis que le stockage de l'index raster_id sur cette table est contrôlé par le paramètre RAS_INDEX_ID. La table raster d'un jeu de données raster contient une seule ligne et est, par conséquent, très petite. Il en va généralement de même pour la table raster d'un catalogue d'images, laquelle ne stocke qu'une seule ligne pour chaque jeu de données raster.
Exemples des paramètres de stockage RAS_STORAGE et RAS_INDEX_ID :
```
RAS_STORAGE "PCTFREE 0 INITRANS 4 TABLESPACE EARTH"
RAS_INDEX_ID "PCTFREE 0 INITRANS 4 TABLESPACE EARTH"
```
La table des canaux raster est stockée conformément au paramètre de stockage BND_STORAGE. Le paramètre BND_INDEX_ID contrôle le stockage de l'index rasterband_id, tandis que BND_INDEX_COMPOSITE contrôle le stockage de l'index composite sur les colonnes sequence_nbr et raster_id. Généralement de petite taille, la table des canaux raster stocke un seul enregistrement par canal raster. Par rapport à la table métier ou raster d'un objet raster, elle n'est que légèrement plus grande. Dans le cas d'un catalogue d'images stockant 1 000 jeux de données raster à trois canaux, la table des canaux raster contient 3 000 enregistrements.
Exemples des paramètres de stockage BND_STORAGE, BND_INDEX_COMPOSITE et BND_INDEX_ID :
```
BND_STORAGE "PCTFREE 0 INITRANS 4 TABLESPACE EARTH"
BND_INDEX_COMPOSITE "PCTFREE 0 INITRANS 4 TABLESPACE EARTH"
BND_INDEX_ID "PCTFREE 0 INITRANS 4 TABLESPACE EARTH"
```
Le paramètre de stockage AUX_STORAGE contrôle le stockage de la table auxiliaire du raster, tandis que AUX_INDEX_COMPOSITE contrôle le stockage de l'index composite de la table. Le nombre d'enregistrements de cette table auxiliaire varie en fonction des données de canal raster facultatives qui y sont stockées. Pour plus d'efficacité, le masque binaire NoData est stocké pour chaque canal raster mais à la seule condition que sa taille soit inférieure à 10 Mo. Dans le cas contraire, il n'est pas stocké et ArcSDE doit le récupérer à partir des blocs de pixels stockés dans la table des blocs raster. Il stocke également les statistiques raster si elles ont été calculées et, le cas échéant, la palette de couleurs. Pour un objet raster donné, il est possible que la table auxiliaire du raster soit vide ou contienne plus d'enregistrements que la table des canaux raster. En règle générale, elle est de la même taille que la table des canaux raster.
Exemples des paramètres de stockage AUX_STORAGE et AUX_INDEX_COMPOSITE :
```
AUX_STORAGE "PCTFREE 0 INITRANS 4 TABLESPACE EARTH"
AUX_INDEX_COMPOSITE "PCTFREE 0 INITRANS 4 TABLESPACE EARTH"
```
Le paramètre BLK_STORAGE contrôle le stockage de la table des blocs raster, qui est l'objet le plus volumineux parmi les tables et index de l'objet raster. La table des blocs raster stocke les données de pixel telles qu'elles sont définies par la taille de tuile lors de la création de l'objet raster. Le paramètre BLK_INDEX_COMPOSITE contrôle le stockage de l'index composite de la table des blocs raster, lequel indexe les quatre colonnes d'entiers, à savoir : rasterband_id, row_nbr, col_nbr et rrd_factor. La table des blocs raster est environ 150 fois plus grande que son index. Cependant, étant donné que cette table peut devenir très volumineuse, il est pratique de la stocker, ainsi que son index, dans le même tablespace.
Exemples des paramètres de stockage BLK_STORAGE et BLK_INDEX_COMPOSITE :
```
BLK_STORAGE "PCTFREE 0 INITRANS 4 TABLESPACE EARTH_BLOCKS STORAGE
     (INITIAL 500M MINEXTENTS 10) LOB( BLOCK_DATA) STORE AS (ENABLE STORAGE 
      IN ROW CHUNK 8K RETENTION CACHE)"
BLK_INDEX_COMPOSITE "PCTFREE 0 INITRANS 4 TABLESPACE 
     EARTH_BLOCKS"
```

Les emprises du jeu de données raster et du catalogue d'images sont stockées dans la colonne spatiale. Si cette colonne est créée comme type binaire ArcSDE, la configuration des paramètres de stockage DBTUNE ci-dessous s'avère également nécessaire :

S_STORAGE : table d'index spatiaux
S_INDEX_ALL : index de couverture qui répertorie toutes les colonnes de la table d'index spatial.
S_INDEX_SP_FID : index de colonne fid de la table d'index spatiaux

Vous trouverez ci-dessous quelques exemples d'affichage du mot-clé DBTUNE dans le fichier DBTUNE pour chaque SGBD. Les deux signes dièse (##) indiquent le début du mot-clé EARTH DBTUNE, tandis que END en marque la fin.

Exemple de mots-clés DBTUNE SQL Server

##EARTH_15M
B_CLUSTER_ROWID 0 
B_CLUSTER_SHAPE 1
B_CLUSTER_RASTER 0 
B_INDEX_ROWID "WITH FILLFACTOR = 100"
B_INDEX_SHAPE "WITH FILLFACTOR = 100"
B_INDEX_RASTER "WITH FILLFACTOR = 100"
B_STORAGE ""
B_TEXT_IN_ROW 256
RAS_STORAGE ""
RAS_CLUSTER_ID 1
RAS_INDEX_ID "WITH FILLFACTOR = 100"
BND_STORAGE "" 
BND_CLUSTER_ID 0
BND_INDEX_ID "WITH FILLFACTOR = 100"
BND_CLUSTER_COMPOSITE 0
BND_INDEX_COMPOSITE "WITH FILLFACTOR = 100"
AUX_STORAGE ""
AUX_CLUSTER_COMPOSITE 1
AUX_INDEX_COMPOSITE "WITH FILLFACTOR = 100" 
BLK_STORAGE "" 
BLK_CLUSTER_COMPOSITE 1
BLK_INDEX_COMPOSITE "WITH FILLFACTOR = 100" 
END

Exemple de mots-clés DBTUNE Oracle

##EARTH_15M 
RAS_STORAGE "PCTFREE 0 INITRANS 4 TABLESPACE EARTH" 
RAS_INDEX_ID "PCTFREE 0 INITRANS 4 TABLESPACE EARTH"
BND_STORAGE "PCTFREE 0 INITRANS 4 TABLESPACE EARTH"
BND_INDEX_COMPOSITE "PCTFREE 0 INITRANS 4 TABLESPACE EARTH"
BND_INDEX_ID "PCTFREE 0 INITRANS 4 TABLESPACE EARTH"
AUX_STORAGE "PCTFREE 0 INITRANS 4 TABLESPACE EARTH" 
AUX_INDEX_COMPOSITE "PCTFREE 0 INITRANS 4 TABLESPACE EARTH" 
BLK_STORAGE "PCTFREE 0 INITRANS 4 TABLESPACE EARTH_BLOCKS STORAGE 
       (INITIAL 500M MINEXTENTS 10) LOB( BLOCK_DATA) STORE AS (ENABLE 
        STORAGE IN ROW CHUNK 8K RETENTION CACHE)"
BLK_INDEX_COMPOSITE "PCTFREE 0 INITRANS 4 TABLESPACE EARTH_BLOCKS" 
END

Exemple de mots-clés DBTUNE DB2

##EARTH_15M 
AUX_STORAGE "IN EARTH INDEX IN EARTH" 
BLK_STORAGE "IN EARTH INDEX IN EARTH LONG IN EARTH_BLOCKS" 
BND_STORAGE "IN EARTH INDEX IN EARTH" 
RAS_STORAGE "IN EARTH INDEX IN EARTH"
END

Exemple de mots-clés DBTUNE Informix

##EARTH_15M 
RAS_STORAGE "EXTENT SIZE 16 NEXT SIZE 16 LOCK MODE ROW IN EARTH" 
RAS_INDEX_ID "FILLFACTOR 90 IN EARTH"
BND_STORAGE EXTENT SIZE 16 NEXT SIZE 16 LOCK MODE ROW IN EARTH"
BND_INDEX_COMPOSITE "FILLFACTOR 90 IN EARTH" 
BND_INDEX_ID "FILLFACTOR 90 IN EARTH" 
AUX_STORAGE "EXTENT SIZE 16 NEXT SIZE 16 LOCK MODE ROW IN EARTH" 
AUX_INDEX_COMPOSITE "FILLFACTOR 90 IN EARTH" 
BLK_STORAGE "EXTENT SIZE 1000 NEXT SIZE 1000 LOCK MODE ROW IN EARTH_BLOCKS" 
BLK_INDEX_COMPOSITE "FILLFACTOR 90 IN EARTH"
END

Préparation des données source

Pour rendre disponibles les fichiers source du jeu de données raster, mettez-les en attente sur des lecteurs de disque accessibles à ArcCatalog ou aux scripts ArcObjects utilisés pour le chargement des données dans la géodatabase.

CD ou DVD

Si les jeux de données raster se trouvent sur un CD ou DVD, copiez-les sur un disque dur rapide. Utilisez des disques durs locaux plutôt que lecteurs réseau. Il est déconseillé de charger directement des fichiers à partir d'un CD ou DVD, dans la mesure où le temps d'accès est beaucoup plus long qu'avec des disques durs.

Silo de bandes

Si vous chargez des fichiers à partir d'un silo de bandes, les fichiers du jeu de données raster doivent être mis en attente dans la mémoire cache en ligne avant de procéder au chargement.

Organisation des données source

Les fichiers image doivent être regroupés dans des dossiers distincts en vue de l'opération de chargement qui les exploitera. Ce faisant, l'outil de chargement est en mesure d'ouvrir tous les fichiers dans un dossier et de les charger par lots, plutôt qu'individuellement. Vous pouvez, par exemple, mosaïquer plusieurs jeux de données raster en un seul jeu de données raster, charger tous les jeux de données raster en entrée dans un seul jeu de données raster autonome, regrouper des jeux de données raster dans un catalogue d'images ou encore créer un catalogue d'images à l'aide de plusieurs jeux de données raster mosaïqués. Les systèmes d'exploitation présentent des limites différentes quant au nombre de fichiers ouverts. Par conséquent, si vous atteignez cette limite, vous devrez créer des dossiers supplémentaires et démarrer un autre processus de chargement.

Application d'une projection aux données source

Deux workflows de base permettent de projeter des données raster. Vous pouvez soit appliquer la projection en créant une autre copie du fichier image source, soit l'appliquer quand vous insérez le fichier image source dans la géodatabase.

Les tests ont démontré que la meilleure méthode consistait à appliquer la projection à une copie du fichier source du jeu de données raster et à insérer la source du jeu de données raster projeté dans la géodatabase. La projection du fichier source du jeu de données raster en cours de chargement peut se révéler légèrement plus rapide que la création d'un fichier source projeté intermédiaire. Cependant, si vous utilisez plusieurs processus pour insérer de nombreuses sources en parallèle, il est préférable de mettre en attente les fichiers source du jeu de données raster projeté sur le client, puis de les charger sur le serveur, dans la mesure où la projection des données raster peut prendre beaucoup de temps. L'utilisation de nombreux processus pour créer des fichiers source de jeu de données raster projeté et d'un petit nombre de processus pour insérer les fichiers projetés dans la géodatabase permet d'optimiser les ressources des machines client et serveur, plutôt que de disposer d'un serveur inactif avec des pointes d'activité susceptible de submerger occasionnellement les ressources du serveur.

Création de l'objet raster et chargement des données raster

Si vous ne vous limitez pas au stockage de plusieurs jeux de données raster autonomes, il est conseillé de créer le catalogue d'images ou le jeu de données raster où seront stockés les jeux de données raster en cours de chargement. Dans tous les cas de figure, vous devez toutefois connaître les propriétés du jeu de données raster qui sera chargé, ainsi que les propriétés qu'ils auront une fois chargés.

Il se peut que vous ayez déjà déterminé ces propriétés lors de l'estimation des besoins en termes de stockage ou de l'allocation de l'espace de stockage. Peut-être avez-vous également modifié le paramètre dbtune pour créer un mot-clé indiquant tous les paramètres de stockage ? Dans le cas contraire, vous devez déterminer ces propriétés maintenant.

Pour en savoir plus sur les propriétés des jeux de données raster

Quatre paramètres de géodatabase raster doivent être considérés : les pyramides, les statistiques raster, la compression et la taille de tuile.

La mise en pyramides affecte les performances d'affichage.

Pour en savoir plus sur les pyramides raster

Les pyramides peuvent être créées sur un jeu de données à mesure que les données raster y sont mosaïquées ou elles peuvent l'être une fois le chargement terminé. Une fois le mosaïquage effectué, la création des pyramides est la méthode la plus rapide. ArcGIS permet une construction pyramidale partielle, laquelle reconstruit uniquement la partie de la pyramide recouverte par les données source au cours d'un mosaïquage. Cela s'avère utile lors de la mise à jour d'un jeu de données raster mosaïqué, dans la mesure où le jeu de données raster complet ne doit pas obligatoirement reconstruire des pyramides si un nouveau jeu de données raster est ajouté. Cependant, si vous ajoutez les données à l'origine du jeu de données raster (point de référence de la pyramide), la pyramide doit être reconstruite pour tout le jeu de données.

L'origine du jeu de données raster est la coordonnée située la plus à gauche en haut du jeu de données. La construction de la pyramide commence à cette coordonnée et se poursuit de droite à gauche. Pour mosaïquer les données à gauche ou au-dessus de l'origine, ArcSDE doit décaler ce point de telle sorte qu'il reste la coordonnée supérieure la plus à gauche. Le décalage de l'origine du jeu de données raster existant nécessite la reconstruction de la pyramide par ArcSDE. Cette reconstruction peut se révéler particulièrement onéreuse, en particulier si la taille du jeu de données raster a augmenté en raison du mosaïquage de nombreux fichiers source de jeu de données raster (ou d'autres jeux de données raster).

La reconstruction de la pyramide étant une opération particulièrement longue, il est conseillé d'identifier la coordonnée supérieure gauche du jeu de données raster en analysant les données source, puis de la saisir lors de la création du jeu de données raster. ArcSDE vous permet de définir un point de référence de pyramide lors de la création de l'objet raster, plutôt que d'utiliser la coordonnée supérieure gauche du premier jeu de données raster inséré. Il est donc possible d'éviter le décalage de l'origine du jeu de données raster en définissant un point de référence de pyramide lors de la création du jeu de données raster.

Des statistiques relatives au jeu de données raster sont nécessaires pour effectuer certaines opérations de géotraitement ou certaines tâches dans ArcMap ou ArcCatalog, notamment pour appliquer un étirement de contraste ou classer des données.

Pour en savoir plus sur les statistiques raster.

La compression est déterminée par le type de données raster, ainsi que par l'utilisation prévue.

Pour en savoir plus sur la compression des données raster

ArcSDE subdivise les jeux de données raster en une ou plusieurs tuiles à des fins de stockage. Chaque tuile est stockée en tant que données binaires dans la table de stockage raster. Dans le cas d'un jeu de données raster multicanaux, les pixels issus de blocs raster coïncidents dans différents canaux sont stockés dans leurs propres lignes dans la table.

Le tuilage des jeux de données raster permet d'améliorer les performances. Ainsi, si vous effectuez un zoom avant sur une petite zone qui ne contient que quatre tuiles, ArcSDE doit seulement récupérer quatre lignes dans la table des blocs raster. En l'absence de partitionnement du raster, ArcSDE devrait récupérer le jeu de données raster complet.

Les tuiles sont dimensionnées selon le nombre de lignes et de colonnes utilisées pour les créer. A titre d'exemple, une taille de tuile de 128 par 128 correspond, en réalité, à 128 pixels par 128 pixels. Des grandes tuiles génèrent des champs BLOB volumineux, mais moins de lignes dans la table, tandis que des tuiles plus petites génèrent des petits champs BLOB, mais de nombreuses lignes dans la table. La taille de tuile par défaut est de 128 par 128 pixels. Si les données en cours de chargement n'appartiennent pas à une imagerie en couleurs à trois canaux, il se peut que la modification de la taille de tuile réduise l'espace de stockage nécessaire grâce à un ajustement efficace des tuiles dans les blocs de la base de données. Pour déterminer la taille idéale, il convient de procéder à un banc d'essai avec des rasters représentatifs. De manière générale, des tailles de tuile plus importantes génèrent des taux de compression plus élevés et entraînent le stockage de tuiles plus petites dans la base de données.

Vous pouvez créer des objets raster à l'aide d'un outil de géotraitement (dans ArcCatalog, par exemple), de sderaster ou d'ArcObjects. Les objets raster créés par l'outil de géotraitement sont vides ; ils possèdent des propriétés, mais ils ne contiennent aucune donnée de pixel dépendante de la géodatabase. Pour créer un jeu de données raster, reportez-vous à la rubrique Création de jeux de données raster dans une géodatabase ArcSDE. Pour créer un catalogue d'images, reportez-vous à la rubrique Création de catalogues d'images dans une géodatabase ArcSDE.

Les objets raster créés par sderaster contiennent toujours des données de pixel. Ils ne dépendent pas de la géodatabase. Ils ne contiennent aucune colonne d'emprises et, dans le cas d'un mosaïquage, les fichiers de géoréférencement doivent être parfaitement alignés. Pour plus d'informations sur la création de rasters avec ArcObjects, reportez-vous au site ESRI Developer Network, Code Exchange et consultez des exemples de données raster que vous pouvez modifier et utiliser. Vous pouvez, par exemple, copier et modifier l'échantillon Create Geodatabase Raster Dataset pour créer un jeu de données raster autonome. Les échantillons Mosaic Rasters In A Directory et Subdirectories To An ArcSDE Raster mettent à votre disposition un exemple de code pour mosaïquer toutes les sources de jeu de données raster d'un répertoire ou dossier en un jeu de données raster autonome spécifique. Vous pouvez créer un catalogue d'images à l'aide de l'échantillon Créer un catalogue d'images de géodatabase. Il est également possible de combiner cet échantillon avec Loading Raster Datasets In A Workspace To A GDB Raster Catalog, un échantillon qui insère des fichiers source de jeu de données raster dans un catalogue d'images.

L'utilisation du logiciel ArcObjects exige de l'opérateur des compétences particulières pour modifier et exécuter l'exemple de code. Cependant, cela présente les avantages non négligeables suivants :

Possibilité de référencer un répertoire contenant de nombreux fichiers source de jeu de données raster plutôt que d'avoir à saisir chaque source individuellement.
Possibilité d'ajouter un ordre d'exécution afin de gérer correctement les exceptions, telles qu'un fichier image source corrompu.

Les données raster peuvent être chargées de plusieurs façons dans une géodatabase : en utilisant la fonction d'importation des jeux de données raster (menu contextuel de la géodatabase), l'outil Copier un raster (outils de géotraitement) ou la fonction de chargement des données (menu contextuel de jeu de données d'ArcCatalog). Pour plus d'informations sur le chargement de données raster dans une géodatabase, reportez-vous à la rubrique suivante Importation de jeux de données raster.

Pour plus d'informations sur le chargement de données raster à l'aide de sderaster, reportez-vous à la rubrique Chargement de rasters dans ArcSDE à l'aide d'un raster SDE.

Génération de statistiques

La génération de statistiques portant sur le SGBD et le raster permet d'améliorer les performances d'affichage du raster, ainsi que son apparence.

La génération de statistiques SGBD n'est pas toujours nécessaire. Cependant, tous les SGBD pris en charge par ArcSDE ont recours à une optimisation sur la base de coûts. Ce type d'optimisation utilise des statistiques rassemblées précédemment à partir des objets SGBD pour déterminer le plan d'exécution idéal. SQL Server rassemble automatiquement des statistiques à mesure que les données sont chargées. Cependant, pour tous les autres SGBD, vous devez générer des statistiques SGBD au moins sur la table de blocs.

Pour générer des statistiques SGBD dans ArcCatalog, procédez comme suit :

Cliquez avec le bouton droit sur l'objet raster, puis cliquez sur Analyser.
Dans la boîte de dialogue Composants d'analyse, assurez-vous que le composant Table raster est coché.
Cliquez sur OK.

Vous pouvez utiliser l'opération sdetable update_dbms_stats pour générer des statistiques, comme illustré dans l'exemple suivant :

c:\>sdetable -o update_dbms_stats -t earth -m estimate -u mark -p mark -i 9000

L'exemple Oracle ci-dessous génère rapidement les statistiques sur la table de blocs :

SQL> select rastercolumn_id from sde.raster_columns
			where table_name = 'EARTH';

RASTERCOLUMN_ID
-----------------------
                      1

SQL> EXEC DBMS_STATS.GATHER_TABLE_STATS(NULL, 'SDE)BLK_1; NULL, 1);

Les statistiques raster peuvent être générées sur les jeux de données raster et sont stockées dans la table AUX d'ArcSDE. Ces statistiques comprennent la valeur minimale, la valeur maximale, la moyenne et l'écart type. Pour les jeux de données raster très volumineux, la génération des statistiques raster au niveau de la pyramide de base peut prendre beaucoup de temps.

Les statistiques raster sont nécessaires pour les données qui doivent être étirées statistiquement avant que les objets capturés dans le raster soient visibles pour l'œil humain.

Pour en savoir plus sur la génération de statistiques raster, consultez la rubrique Statistiques concernant les jeux de données raster.

Affichage des données raster

Pour visualiser les données raster, vous devez employer l'application qui sera utilisée pour le projet pour lequel le raster a été conçu ; ArcMap, ArcCatalog, ArcGlobe ou ArcScene, par exemple. Si la pyramide a été construite et que les statistiques SGBD sont à jour, le raster doit normalement s'afficher rapidement.

Si l'affichage est lent, le problème est généralement dû à des statistiques SGBD périmées, voire inexistantes. L'existence des statistiques dans la table des blocs revêt une importance toute particulière. Reportez-vous à la section précédente, Génération de statistiques, pour consulter les instructions relatives à la création de statistiques SGBD.

Avec l'introduction de la construction pyramidale partielle, il est désormais possible de visualiser un jeu de données raster pendant une opération de mosaïquage de grande envergure. Cependant, si vous visualisez un jeu de données raster en basse résolution au cours d'un mosaïquage, ne paniquez pas s'il disparaît, puis réapparaît à intervalles réguliers. Typique de la construction pyramidale partielle, ce phénomène est dû à la suppression et la réinsertion des niveaux supérieurs mis à jour de la pyramide.

Rubriques connexes

Transfert de jeux de données raster volumineux

7/10/2012