Le mode d'organisation et d'inscription des données auprès du serveur détermine si elles doivent ou non être empaquetées et copiées sur le serveur lors de la publication.
Avant de lire cette rubrique, il est important de comprendre les notions de base concernant la manière dont ArcGIS Server stocke les données et y accède. Pour plus d'informations, reportez-vous aux liens suivants :
- Comment rendre vos données accessibles dans ArcGIS Server
- Copie automatique de données sur le serveur lors de la publication.
Nul n'ignore que les jeux de données raster et les mosaïques peuvent se composer de nombreux fichiers différents. Cette rubrique vous aide à organiser les données de manière à obtenir les résultats souhaités lors de la publication.
Il est important de comprendre que si le chemin d'accès aux données est enregistré dans le magasin de données, ArcGIS Server part du principe que toutes les données s'y trouvent. En règle générale, cela ne pose aucun problème lorsque l'emplacement enregistré est partagé avec le serveur. En revanche, des problèmes peuvent survenir si l'emplacement est un doublon. Dans ce cas, il convient de s'assurer que les éventuelles modifications ont bien été effectuées aux deux emplacements. Par exemple, si vous créez des pyramides pour un jeu de données raster sur votre emplacement local, mais que vous ne les copiez pas sur l'emplacement dupliqué sur le serveur, elles ne seront pas copiées au cours de l'opération de publication, étant donné que le serveur part du principe que tous les fichiers de données sont dupliqués. Les choses se compliquent avec les mosaïques, dans la mesure où davantage de fichiers sont concernés.
L'emplacement des données source de votre mosaïque est l'une des difficultés auxquelles il convient de faire face. Pour simplifier, supposons que les données source correspondent à un ensemble de jeux de données raster, et comprennent des fichiers de métadonnées, de statistiques et de pyramides. Toutes ces données peuvent résider dans un emplacement auquel la mosaïque a accès.
Vient ensuite la mosaïque. Pour simplifier, supposons qu'elle soit stockée dans une géodatabase fichier. Si vous créez des aperçus, ils sont stockés dans un dossier proche de la géodatabase. Ce dossier porte le même nom que la géodatabase, associé à une extension .Overviews. Si vous avez ajouté des données lidar ou généré un cache pour un élément raster, un autre dossier sera stocké à côté de la géodatabase, avec le même nom que cette dernière et une extension .Cache. Les emplacements de stockage du cache et de l'aperçu se situent, par défaut, à côté de la géodatabase, mais vous pouvez modifier ce paramètre ; cela aura toutefois pour effet de compliquer, davantage encore, l'organisation de vos données.
Lors de la publication, vous souhaitez vous assurer que le serveur a accès à l'ensemble du contenu géré par la mosaïque. Vous devez donc définir le magasin de données et préparer correctement la mosaïque. Les scénarios ci-dessous abordent cette question sous l'angle de l'utilisation de mosaïques, dans la mesure où une mosaïque fait référence à des données qui peuvent résider n'importe où (pour autant qu'elles soient lisibles).
Scénario 1 : toutes les données sont stockées dans un emplacement partagé
Il s'agit probablement de la structure d'organisation des données la plus appropriée. Dans ce scénario, toutes les données sont stockées dans un emplacement partagé par vous et par le serveur. Vous devez enregistrer cet emplacement auprès du serveur et vous y connecter dans la fenêtre Catalogue (ou ArcCatalog) afin de partager les données qui en sont issues en tant que service d'imagerie. Cela constitue également une méthode de publication rapide, dans la mesure où aucune donnée n'est déplacée.
Scénario 2 : toutes les données sont dupliquées
Dans ce scénario, vos données sont stockées à deux emplacements : l'un accessible par le serveur et un autre auquel vous vous connectez dans la fenêtre Catalogue. Cette configuration est généralement utilisée lorsque le serveur se trouve dans le Cloud ou utilise un système d'exploitation Linux.
Vous devez vous assurer que les données sont parfaitement identiques. Par exemple, si vous modifiez la mosaïque en ajoutant une image ou en modifiant les emprises, vous devez vous assurer que le serveur accède à la copie actualisée. Vous devez également vérifier que les chemins d'accès aux données sont modifiés en conséquence. Une mosaïque contient des chemins d'accès précodés vers tout son contenu. Par conséquent, si votre contenu est stocké sous D:\MyData et que les données sur le serveur se trouvent à l'emplacement \\Blue\ServerData, vous devez vous assurer que les chemins d'accès dans la mosaïque sont mis à jour à l'emplacement \\Blue\ServerData. Vous pouvez mettre à jour ces chemins d'accès avant ou après la duplication de la mosaïque (et des fichiers associés) sur l'emplacement serveur ; pour en savoir plus, reportez-vous à la rubrique Réparation des chemins d'accès dans une mosaïque.
Avant de publier, veillez à enregistrer les emplacements locaux et serveur en tant qu'emplacements en double. Vérifiez également que les données sont dupliquées et que les chemins d'accès sont corrects. Vous pouvez ensuite publier la mosaïque en pointant vers l'emplacement sur votre machine locale. Le serveur sait alors que l'emplacement est dupliqué et, par conséquent, ne déplace aucune donnée. A l'instar du scénario 1, la publication est plus rapide.
Scénario 3 : aucun emplacement de données n'est enregistré
Comme pour le scénario 1, ce scénario s'avère particulièrement simple, dans la mesure où vous ne devez pas vous soucier de l'emplacement de vos données, ni de savoir si le serveur peut y accéder ou si leur version est correcte. Dans ce scénario, toutes les données sont empaquetées et déplacées vers le serveur lors de leur publication. Cette solution donne d'excellents résultats pour les petits ensembles de données, mais elle est déconseillée pour les ensembles de taille moyenne et de grande taille en raison du temps nécessaire pour empaqueter et déplacer les données. Vous pouvez sélectionner cette option si vous n'avez pas accès à l'emplacement utilisé par le serveur ou si vous publiez un petit jeu de données raster Notez toutefois que cette méthode n'est pas efficace pour déplacer des giga-octets de données.
Scénario 4 : seules les données source sont stockées dans un emplacement enregistré
Dans ce scénario, l'emplacement des données source est différent de celui de la mosaïque. L'emplacement des données source peut être partagé ou dupliqué.
Exemple 1 : données source partagées
L'emplacement des données source est partagé sur \\yellow\RasterData. Créez une mosaïque sur votre machine locale et ajoutez les données en provenance de \\yellow\RasterData. Ainsi, lorsque vous publierez la mosaïque, la procédure consistera à empaqueter cette dernière et les données associées (telles que le contenu du dossier *.Overviews), à les transférer vers le serveur et à mettre à jour les chemins d'accès aux fichiers précodés (ou à s'assurer que leurs emplacements relatifs ne changent pas). Cette opération peut durer longtemps si le nombre d'aperçus est important.
Exemple 2 : données source dupliquées
Les données source sont dupliquées ; elles sont stockées sous P:\SourceData\RasterData sur le serveur et sous D:\RasterData sur votre machine locale.
Dans cet exemple, vous devez vous assurer que la mosaïque n'est pas créée dans D:\RasterData, car le serveur part du principe que ces deux emplacements sont dupliqués et il ne vérifie pas si elle se trouve dans P:\SourcData\RasterData lors de la publication.
Créez votre mosaïque à un emplacement unique, tel que D:\Collections. Ainsi, lorsque vous publierez la mosaïque, la procédure consistera à empaqueter cette dernière et les données associées (telles que le contenu du dossier *.Overviews), à les transférer vers le serveur et à mettre à jour les chemins d'accès aux fichiers précodés (ou à s'assurer que leurs emplacements relatifs ne changent pas).
Vous avez un commentaire à formuler concernant cette rubrique ?