Gestion des données d'altitude : Partie 2 : Création et plan de gestion des données

Le public de ce workflow est principalement les gestionnaires de données d'image dans une organisation qui sont mandatés pour rendre des données d'altitude accessibles à une plage de communautés d'utilisateurs Ce workflow suppose que le gestionnaire de données d'image utilise ArcGIS Desktop pour gérer les données et ArcGIS Server pour distribuer les données en tant qu'un ou plusieurs services d'image, mais ce workflow permet également de gérer et de distribuer des données d'altitude dans ArcGIS Desktop uniquement.

Ce workflow est conçu pour traiter des données d'altitude raster par cellule. Les formats de données de point 3D (LAS par exemple) et de jeu de données de MNT doivent être convertis en jeux de données raster pour pouvoir être utilisés dans ce workflow.

La création générale de la gestion des données d'altitude est décrite ci-dessous. Chacun de ces points est décrit ci-dessous.

1. Stockage de données (taille, conditions requises et emplacements).
2. Préparer des données (un prétraitement peut être nécessaire).
3. Créer une mosaïque par collecte (source).
4. Créer une mosaïque à partir de chaque collecte (principale).
5. Créer différentes mosaïques pour la visualisation, l'analyse, l'accès des utilisateurs et pour la publication (référencées).

Stockage de données

Le stockage de données n'est pas décrit ici mais doit toutefois être planifié en fonction de vos besoins. Pour obtenir des précisions sur l'architecture de votre système, reportez-vous aux diapositives de la présentation 2011 Esri International User Conference : System Architecture for Large Image Services.

Le point fondamental réside dans l'organisation des données. Le scénario idéal est de pouvoir organiser les données en dossiers regroupés par produit. Par exemple, conservez les données SRTM dans un dossier et les données NED 1/3 de seconde d'arc dans un autre dossier. La procédure (Partie 3) vous décrit en quoi cela simplifie le chargement de données, dans l'assurance/contrôle qualité et dans la maintenance à plus long terme.

Utilisation des données

Ce workflow met en évidence trois modes d'utilisation des données d'altitude. La plupart des utilisateurs finals souhaitent afficher les virtualisations de la topographie contre un faible pourcentage d'utilisateurs qui souhaitent consulter les résultats d'une analyse topographique. La minorité de ces utilisateurs, des ingénieurs par exemple, doivent accéder aux valeurs d'altitude réelles pour procéder à leur propre analyse.

Il convient de connaître les différences entre les modes et d'implémenter le mode d'utilisation approprié à chaque utilisateur au risque d'affecter considérablement l'efficacité et la réactivité du système. Les différents modèles d'utilisation référencés à plusieurs reprises sont les suivants : utilisation de la visionneuse, utilisation des résultats d'analyse et utilisation des valeurs de données.

Modèle d'utilisation 1 : Utilisation de la visionneuse

Les utilisateurs doivent afficher des représentations des données d'altitude. Le gestionnaire de données doit donc créer des produits de virtualisation appropriés sur le serveur, puis fournir ces vues aux utilisateurs. Ceci s'applique au groupe d'utilisateurs le plus important (mais demandant le moins de technique), dans la plupart des cas le public général, qui a besoin d'un accès simple à un nombre quelconque de produits basés sur les données d'altitude relativement simples. Exemples :

• Une image ombrée ou de relief ombré : pour l'insertion d'une carte topographique ou d'un fond de carte
• Une image représentant une pente : pour l'urbanisme, la susceptibilité du terrain, etc.
• Une image représentant une exposition : pour l'agriculture, la délimitation et la gestion de l'habitat naturel, la modélisation du climat, etc.

Pour les utilisateurs d'ArcGIS ayant accès à des données d'altitude, il est entendu que l'application peut générer ces produits.

Modèle d'utilisation 2 : Utilisation des résultats d'analyse

Les utilisateurs définissent des paramètres et une région d'intérêt pour l'analyse côté serveur des données d'altitude, puis récupèrent les résultats. Cela s'applique au groupe d'utilisateurs qui doivent accéder à une variété de produits analytiques qu'il est possible de générer sur le serveur. Les résultats sont généralement des cartes ou des entités discrètes qui sont ensuite transmises aux utilisateurs sans les données sources d'origine. Exemples :

• Calcul et génération de cartes de plaine inondable : pour FEMA, les sociétés d'assurance, les administrations municipales ou départementales, l'immobilier et l'utilisation publique
• Utilisations dans la gestion des catastrophes : pour les plans d'évacuation, la réduction des inondations et une superposition basée sur le Web des données d'inondation en cours pour une prise de décision en temps réel
• Calculs du champ de vision pour l'analyse de la visibilité et de la ligne de visée : pour la détermination des éléments visibles à partir d'un emplacement, pour le placement des relais de téléphone mobile et de l'équipement de communication à micro-ondes, ou pour la planification de coupes rases
• Opérations militaires : pour des itinéraires de troupe sécurisés et non exposés aux tireurs embusqués
• Planification industrielle : pour le profil du vent et la visibilité des parcs éoliens, ou la conception d'un barrage de centrale électrique
• Calculs des isolignes cartographiques : pour l'affichage sur une carte
• Calcul des profils le long de lignes droites ou de segments de ligne : pour l'ingénierie des pipelines et les calculs de pression, l'aménagement de route ou l'aménagement de route d'exploitation du bois et les coûts d'extraction

Pour ces applications, l'utilisateur n'a généralement pas besoin des données d'altitude réelles. En distribuant uniquement ces produits, la bande passante nécessaire peut être légèrement réduite en raison de données de taille inférieure. Par exemple, les valeurs d'altitude brutes sont des données 32 bits alors que le champ de vision peut être un résultat de 1 ou 8 bits.

Modèle d'utilisation 3 : Utilisation des valeurs de données

Les utilisateurs doivent accéder aux valeurs d'altitude. Ceci s'applique à un utilisateur qui a besoin des données d'altitude d'origine au format numérique pour pouvoir effectuer des calculs numériques (probablement dans une application Web côté client ou bureautique). Par exemple

• En entrée d'un processus secondaire : pour l'orthorectification de l'imagerie
• En entrée des modèles ou processus de données propres à l'utilisateur : pour la création d'isolignes ou l'exécution d'une analyse du flux hydraulique utilisée dans la création hydrographique de systèmes d'irrigation ou dans la modélisation des inondations

Parmi les trois modèles d'utilisation, ce dernier est le plus coûteux en termes de temps et de ressources sur le serveur car il nécessite généralement d'accéder à et de transmettre une quantité de données bien plus importante.

Conditions requises

Pour fournir les données et l'accès appropriés requis par les modèles d'utilisation ci-dessus. La liste des conditions requises n'est pas exhaustive mais une simple introduction à quelques conditions requises importantes et spécifiques aux données d'altitude. Vous devez ensuite déterminer si ces conditions requises s'appliquent à votre organisation et prendre les bonnes décisions sur l'implémentation appropriée.

• Répartir une image, un résultat ou les données
• Proposer un accès en interne, via Intranet ou Internet
• Proposer un ou plusieurs modèles ou représentations d'altitude
• Proposer un accès à 1, 10, 100 ou 1 million d'utilisateurs
• Proposer un accès aux données sources
• Sources de données multiples, gérées comme une seule source
• Accès limité à la source et à la gestion
• Possibilité de mettre à jour ou de remplacer du contenu en toute simplicité

Téléchargement et exportation de données

Les gestionnaires de données d'image et les utilisateurs finals doivent savoir qu'un échantillonnage des données d'altitude entraîne une modification des données. Par exemple, si un jeu de données est affiché à une résolution autre que la résolution maximale, dans une autre projection ou un autre alignement des pixels, les données sont rééchantillonnées. Il n'est pas rare de suréchantillonner un jeu de données d'altitude. Par exemple, un zoom sur une échelle 1:1 000 d'un champ de vision créé à partir d'un jeu de données d'espacement des points de 5 mètres, ce qui est trop rapproché.

Pour certaines applications, les utilisateurs doivent accéder aux valeurs numériques d'une région d'intérêt (utilisation des valeurs de données). Deux méthodes permettent de fournir les valeurs de données numériques à un client : l'exportation et le téléchargement.

L'exportation correspond à la transmission de valeurs de données dans une zone définie par l'utilisateur, et rééchantillonnées à la résolution ou projection appropriée. Le téléchargement correspond à la transmission des valeurs de données d'origine (résolution maximale, non rééchantillonnées), généralement dans une zone définie par l'utilisateur. Sachez que le téléchargement peut entraîner le transfert d'un volume très important de données du serveur vers le client (tout particulièrement si les données couvrent une zone très étendue et qu'elles contiennent un nombre important de jeux de données). Des contraintes appropriées doivent donc être implémentées afin de s'assurer que l'utilisateur et le système sont prêts à recevoir ce résultat (en définissant une limite de quantité maximale de données à transférer ou en créant une application Web avec un avertissement).

sources de données.

Voici une liste d'exemples de données utilisées dans ce workflow. Ces données peuvent varier en termes de profondeurs de couleur, généralement 16 bits ou virgule flottante, signées ou non signées.

Ce workflow implique que les données utilisées par le gestionnaire de données soient des données stockées localement en interne.

Données	Description
GTOPO	GTOPO est un jeu de données d'altitude mondial global avec une résolution de 30 seconds d'arc (environ 1 km), disponible pour le téléchargement à l'adresse http://www1.gsi.go.jp/geowww/globalmap-gsi/gtopo30/gtopo30.html.
SRTM	SRTM (Shuttle Radar Topography Mission) sont des données d'altitude sur une échelle quasi-globale acquises par une navette spatiale visant à générer la base de données topographique numérique haute résolution de la Terre la plus complète possible. Ces données sont disponibles à l'adresse http://srtm.usgs.gov/index.php.
NED 10, NED 30	Le NED (National Elevation Dataset) a été créé par l'USGS pour les Etats-Unis. Les données NED sont disponibles au niveau national à des résolutions de 1 seconde d'arc (environ 30 mètres) et d'1/3 de seconde d'arc (environ 10 mètres, "NED 10"). Reportez-vous à http://ned.usgs.gov/.
Lidar	Les données lidar peuvent provenir de différentes sources. Dans ce cas particulier, les données sont fournies par le RLIS (Oregon Metro Regional Land Information System), puis converties aux formats DEM et DSM.

Organisation et services de gestion de données (produits)

Un objectif clé consiste à s'assurer que toutes les données, quelle qu'en soit l'étendue, soient gérées et réparties en une seule et même unité. L'alternative (généralement constatée dans le temps à mesure qu'une organisation se développe et que des projets individuels sont terminés) consiste à gérer des données de différentes zones géographiques dans des jeux de données distincts. ArcGIS permet toutefois de gérer efficacement des ensembles de jeux de données très importants, réduisant ainsi les coûts de création et de maintenance liés à la duplication des données et à une surcharge de gestion inutile.

Organisation des mosaïques

La mosaïque constitue la structure de données optimales pour gérer, afficher et publier votre ensemble de données d'altitude car elle permet de gérer les différents formats et différentes résolutions de fichier raster. De plus, les fichiers sont conservés sur le disque dans leur format d'origine. Elle inclut également de nombreuses fonctions d'affichage et de traitement des données d'altitude, la création d'une mosaïque dynamique par exemple qui offre la meilleure résolution d'affichage possible aux échelles appropriées, ainsi que des fonctions utilisées pour traiter les données et créer plusieurs produits sans copier les données sources.

Les fonctions spécifiques aux données d'altitude sont les suivantes : Ombrage, Relief ombré, Exposition et Pente.

Il est avantageux de séparer les mosaïques en deux types : celles qui sont utilisées principalement pour la gestion et celles qui proposent d'autres représentations des données (Ombrage par exemple) et qui sont publiées. Cette séparation peut optimiser l'organisation. Vous pouvez gérer l'imagerie au sein d'une mosaïque, mais utiliser une autre mosaïque pour partager ou diffuser (publier) le contenu.

Voici une présentation des différents types de mosaïques et de leur objectif :

• Source : utilisée pour la gestion de l'imagerie. Elle contient généralement un ensemble d'images similaires. Vous pouvez utiliser plusieurs de ces mosaïques sources pour gérer différents ensembles, SRTM et NED par exemple. Elles peuvent être publiées directement ou (plus généralement) utilisées comme source pour d'autres mosaïques.
• Principale (ou dérivée) : utilisée pour compiler plusieurs sources dans une mosaïque unique. La source d'une mosaïque principale est en général une ou plusieurs mosaïques sources mais elle peut également inclure d'autres images ou services.
• Référencée : type de mosaïque unique, principalement utilisé pour partager ou publier l'imagerie. Elle est créée à l'aide d'une mosaïque en entrée et n'autorise pas la modification des éléments de la table. Les entrées ne peuvent ainsi subir aucune modification. Elle est généralement utilisée pour fournir des sorties traitées différemment des entrées de la mosaïque source ou principale.

Les mosaïques sources et principales (dérivées) sont des noms symboliques utilisés pour mieux comprendre la structure organisationnelle des mosaïques alors qu'une mosaïque de référence présente une forme physique différente.

Les données d'altitude peuvent être stockées dans des dossiers organisés par vous-même ou le fournisseur de données, mais elles sont gérées et réparties à l'aide d'une ou plusieurs mosaïques et services d'image. Les données contenues dans une mosaïque source ont généralement le même nombre de canaux et les mêmes profondeurs de couleurs. Ici, elle est déterminée par la profondeur de couleurs et le produit. Par exemple, les données lidar peuvent être organisées dans une mosaïque source et les données SRTM dans une autre. Ceci permet de conserver des données organisées et de séparer les données avec des unités verticales différentes. Par exemple, les données lidar sont mesurées en pieds et les données SRTM en mètres. Cela vous permet également d'affiner les emprises, si nécessaire, ou de contrôler les valeurs NoData qui peuvent être uniques pour chaque produit.

Les mosaïques sources sont combinées à l'aide de la mosaïque principale. Des fonctions peuvent être ajoutées à certaines sources afin de s'assurer que les données représentent les mêmes informations, la conversion de pieds en mètres ou de la hauteur ellipsoïdale en hauteur orthométrique par exemple. (Pour la plupart des conditions requises, il est recommandé de créer une mosaïque avec une hauteur de sol orthométrique et de la gérer en tant que service principal utilisé comme base pour la création des autres mosaïques.)

Produits et services finals

Diverses mosaïques référencées peuvent être créées à partir de la mosaïque principale afin de fournir les services de données d'altitude recommandés suivants :

• Hauteur de sol orthométrique
• Hauteur de surface orthométrique : si des données d'altitude de surface (DSM) sont disponibles (permettent de représenter les bâtiments, le couvert forestier, les ponts, etc.)
• Hauteur de sol ellipsoïdale
• Pour les visualisations
  • Ombrage
  • Relief ombré
  • Pente
  • Exposition (utilisée pour la visualisation et l'analyse)

Si la communauté d'utilisateurs a besoin de plusieurs corrections de géoïde, le gestionnaire de données peut publier les géoïdes en tant que services d'image, et proposer ainsi les options appropriées aux utilisateurs.

Considérations sur les données océaniques

Dans tous les cas de figure, le gestionnaire de données doit déterminer la représentation des océans. Le choix approprié dépend des applications que les données doivent prendre en charge. Parmi les options, citons :

• Océan = altitude avec la valeur 0
• Océan = NoData
• Océans représentés par des données bathymétriques

Pour la plupart des applications, représenter le niveau de la mer avec la valeur 0 est acceptable. Si la mer est définie par une valeur NoData, l'orthorectification d'une zone NoData échoue. Une méthode simple d'entrée de valeurs de zéro consiste à appliquer une très faible résolution, à ajouter une image fictive mondiale à la mosaïque, où toutes les valeurs de pixel sont de 0. Ensuite, lorsque les valeurs des données (SRTM par exemple) sont des valeurs NoData, la valeur 0 de l'image fictive s'affiche.

Si le gestionnaire de données choisit d'inclure des données bathymétriques, les valeurs d'altitude dans les océans sont alors négatives, permettant ainsi de visualiser le fond océanique. Une flexibilité en termes du nombre de services pouvant représenter (afficher) les données est alors possible ; une application cliente peut afficher un remplissage bleu pour les étendues d'eau où l'altitude est inférieure à 0 et, dans la même zone, une autre application cliente peut représenter une altitude souterraine ombrée.

Vues d'ensemble

A la base, les vues d'ensemble de mosaïque sont comme des pyramides de jeux de données raster. Ce sont des images de faible résolution créées pour augmenter la vitesse d'affichage et réduire l'utilisation du processeur dans la mesure où moins de raster sont examinés pour afficher l'image mosaïquée. Toutefois, elles diffèrent grandement en cela que vous pouvez contrôler bon de nombre des paramètres servant à les créer. Vous pouvez les créer pour couvrir uniquement une surface donnée ou des résolutions spécifiques. Elles sont créées pour vous permettre d'afficher tous les raster contenus dans la mosaïque toute entière, pas seulement pour chaque raster. Les vues d'ensemble commencent généralement où s'arrêtent les pyramides raster, mais vous pouvez spécifier une taille en pixels de base à laquelle vos vues d'ensemble seront générées si vous préférez ne pas utiliser toutes les pyramides du raster.

Le gestionnaire de données doit déterminer la meilleure approche pour les vues d'ensemble. Des vues d'ensemble peuvent être créées à partir des données de projet. Toutefois, si des jeux de données de résolution inférieure appropriés sont disponibles auprès de sources alternatives, GTOPO, ETOPO et GMTED2010 par exemple, il est recommandé de les utiliser. La suite de ce workflow est basée sur cette approche afin de créer un service d'image de région étendue constitué de plusieurs jeux de données à des résolutions spatiales différentes (les vues d'ensemble ne sont donc généralement par nécessaires).

Pour en savoir plus sur les vues d'ensemble, reportez-vous à la rubrique Vues d'ensemble des mosaïques.

Metadata

Le gestionnaire de données doit vérifier différentes propriétés relatives aux données d'altitude. Le gestionnaire de données doit examiner et choisir les composants à conserver ainsi que les champs de métadonnées à fournir aux utilisateurs des données. Les métadonnées indiquées ci-dessous sont recommandées pour l'assurance qualité et la configuration du système.

Parmi les métadonnées que le gestionnaire de données doit vérifier, citons :

• Source ou propriétaire de données.
• Copyright.
• Système de coordonnées horizontal (projection, datum et unités).
• Datum vertical (modèle spécifique, rien si ellipsoïdal ou orthométrique) et unités (pieds ou mètres).
• Précision horizontale (mesurée généralement en tant que CE90 ou CE95, mais peut également être rapportée en tant qu'erreur RMS ou RMSE).
• Précision verticale (généralement mesurée en tant LE90).
• Résolution (espacement d'échantillon stocké dans le fichier de données, différente de la précision horizontale des données).
• Type de surface d'altitude (DEM ou DSM).
• Définition de la valeur NoData dans la mosaïque :
  • Existe-t-il des zones NoData ?
  • Si oui, sont-elles représentées par une valeur unique ?
  • Des valeurs NoData sont-elles limitées aux limites des jeux de données ou des données valides comportent-elles des valeurs NoData ?
  • Certains produits sont associés à des classes d'entités qui définissent des régions vides. Vérifiez si ces zones contiennent une valeur et s'il s'agit de la valeur NoData.
• Les données échantillonnées proviennent-elles d'une autre source ?
• Date d'acquisition des données brutes.
• Date de fin de l'assurance/contrôle qualité, personne chargée de l'opération, et méthodes et normes utilisées.
• Les données peuvent-elles être modifiées ou limitées (les données peuvent être propriétaires ou classées, gratuites pour version publique) ?

Pour les champs de métadonnées uniques, il peut être nécessaire de les ajouter manuellement à la table d'attributs de la mosaïque, les précisions horizontale et verticale par exemple. Les utilisateurs peuvent ainsi facilement rechercher ces informations dans la mosaïque.

Astuce :

Il convient de créer une liste de produits (ou sous-produits) que vous utilisez car vous souhaiterez peut-être modifier les données de la mosaïque, à l'aide de la fonction Arithmétique pour convertir d'une unité dans une autre par exemple.

Optimisation du format

L'optimisation du format n'est pas toujours nécessaire mais elle l'est lorsque les données ont un format non optimal ou non pris en charge correctement. Des recommandations de prise en charge du prétraitement des données d'altitude lors de la création d'un ensemble unique et de sa publication en tant que service sont indiquées ci-dessous.

• Conversion de point ou de données TIN au format raster. Vous avez le choix entre plusieurs outils de géotraitement en fonction de la source. Reportez-vous à la rubrique Jeu d'outils Vers un raster ou à la rubrique Jeu d'outils de 3D Analyst.
• Pour en savoir plus sur la conversion de données lidar en surfaces d'altitude dans ArcGIS 10.0, reportez-vous au blog : Solutions lidar dans ArcGIS, partie 2 : Création de MNT et de DSM raster à partir de vastes collections de points lidar.
  Remarque :

  Dans ArcGIS 10.1, les fichiers LAS et les jeux de données de MNT ne doivent pas être convertis en jeux de données raster. Ils ne sont pas pris directement en charge dans la mosaïque.

• Le format optimal des données d'altitude est une valeur à virgule flottante 32 bits avec compression LZW stockée format TIFF tuilé. La compression LZW n'entraîne aucune perte, est rapide, crée automatiquement des tuiles des données d'un fichier et les valeurs NoData n'occupent pas d'espace au format raster.
• La recommandation générale d'Esri consiste à ne pas convertir le format d'origine des données d'altitude sauf si le format de fichier est insuffisant et que les performances du serveur en sont affectées. Par exemple, si l'une des conditions suivantes est remplie, les données doivent être converties avant de les ajouter à la mosaïque :
  • Si les données d'altitude sont stockées dans un format de fichier insuffisant, ASCII XYZ par exemple (lecture impossible)
  • Si les fichiers de données d'altitude sont volumineux (nombre de lignes ou de colonnes > 5000), que les données ne sont pas tuilées, qu'elles n'ont pas de structure pyramidale et que les performances du serveur sont importantes

Dans certains cas, vous souhaiterez contrôler les performances avant de convertir les données afin de savoir si elles sont correctes ou si elles peuvent être améliorées à l'aide d'une conversion. Par exemple :

• Si les données d'origine sont stockées au format JPEG 2000, sachez que la décompression peut prendre du temps et affecter considérablement les performances. Pour des performances optimales, vous devrez peut-être convertir les données au format TIFF tuilé.
• Si les données d'origine sont au format de grille Esri Grid, il convient alors de les convertir si l'évolutivité est importante dans un environnement à traitement multiple.

Conversion de fichier

Si les fichiers sont convertis d'un fichier dans un autre, sans modification de la profondeur de couleurs ou d'autres propriétés du jeu de données nécessaire, utilisez l'outil Raster en d'autres formats (plusieurs). Si vous devez modifier des propriétés, utilisez l'outil Copier un raster. Lorsque vous appliquez cet outil à plusieurs jeux de données, cliquez avec le bouton droit sur l'outil et cliquez sur Par lot ou créez un script pour intégrer plusieurs jeux de données. Dans les deux cas, les environnements doivent être définis. Ceci est possible au niveau de l'application si vous l'appliquez à plusieurs outils ou au niveau de l'outil.

Etapes :

1. Accédez à la boîte de dialogue Environnements.
   • Dans le menu principal, cliquez sur Géotraitement > Environnements.
   • Dans l'outil, cliquez sur le bouton Environnements.
2. Développez la section Stockage des données raster.
3. Cochez la case Générer la structure pyramidale.
   1. Cliquez sur la flèche de la liste déroulante Méthode de rééchantillonnage des pyramides, puis sur BILINEAR.
   2. Cliquez sur la flèche de la liste déroulante Type de compression pyramidale, puis sur LZW.
4. Cochez la case Calculer les statistiques.
   1. Tapez 1000 pour les pas d'échantillonnage x et y.

   Cette valeur est dérivée en divisant le nombre de colonnes par 1 000.

5. Cliquez sur la flèche de la liste déroulante Compression, puis sur LZ77.
6. Vérifiez que la largeur Taille de tuile et les hauteurs sont définies sur 128.

projection

Si la projection n'est pas définie pour chaque jeu de données, utilisez l'outil Définir une projection. Pour plus d'informations, reportez-vous au blog : My image is in the wrong spot.

Les fichiers ne doivent généralement pas être reprojetés.

Générer la structure pyramidale

Si les données n'ont pas de structure pyramidale et que les tuiles sont importantes (nombre de lignes ou de colonnes supérieur à 5 000), il est recommandé de créer la structure pyramidale. Pour savoir si un fichier a une structure pyramidale, cliquez avec le bouton droit dans la fenêtre du catalogue ou dans la table des matières, cliquez sur Propriétés, puis consultez les informations raster de la structure pyramidale.

Lorsque vous créez une structure pyramidale pour plusieurs jeux de données, utilisez l'outil Construire des pyramides et des statistiques. Utilisez les mêmes paramètres d'environnement que ci-dessus.

La structure pyramidale requiert de l'espace disque supplémentaire et est créée dans un fichier distinct avec l'extension .ovr.

Remarque :

Aucune des données utilisées dans ce workflow n'a de structure pyramidale. Ceci est principalement dû au fait que les différentes résolutions sont intégrées et combinées (plus besoin de résolutions réduites des données sources) et à la structure tuilée des données (aucun fichier très volumineux).

FWTools

Astuce :

Si le nombre de fichiers de données est supérieur à 100 000 et que de nouvelles structures pyramidales seront créées, il peut être préférable de créer la structure pyramidale dans les fichiers de données afin de ne pas générer un trop grand nombre de fichiers supplémentaires. Pour cela, il est recommandé d'utiliser l'utilitaire FWTools (non fourni avec ArcGIS).

Vous pouvez télécharger FWTools à l'adresse http://fwtools.maptools.org, puis exécuter les commandes suivantes :

gdal_translate.exe -of Gtiff -co "TILED=YES" -co "COMPRESS=LZW" Input.xxx Output.tif
gdaladdo.exe -r average -ro --config TILED YES --config PHOTOMETRIC_OVERVIEW LZW output.tif 2 4 8 16

Pour l'imagerie 16 bits, insérez -co NBITS=12 avant Input.xxx.

Si les fichiers créés dépassent 4 Go, insérez BIGTIFF=YES ou BIGTIFF=IF_NEEDED avant Input.xxx.

Calculer les statistiques

Des statistiques relatives à un jeu de données raster ou à une mosaïque sont nécessaires pour effectuer certaines opérations de géotraitement ou certaines tâches dans les applications ArcGIS Desktop telles qu'appliquer un étirement de contraste ou classifier les données. Dans ce workflow, inutile de calculer les statistiques de chaque source de données car aucune n'est affichée ou utilisée et aucune fonction ni aucun des produits créés ne dépend des statistiques des jeux de données. Des statistiques sont calculées pour les mosaïques à des fins d'affichage.

Pour plus d'informations sur les statistiques, reportez-vous à la rubrique Statistiques concernant les jeux de données raster.