La façon d’organiser et d’inscrire vos données sur le serveur détermine si les données ont besoin d’être empaquetées et copiées sur le serveur lors de la publication.
Avant de lire cette rubrique, il est important de comprendre les principes fondamentaux de stockage et d’accès aux données par ArcGIS Server. Pour plus d’informations, consultez les liens suivants :
- Comment rendre vos données accessibles pour ArcGIS Server
- Copie automatique de données sur le serveur lors de la publication.
Les jeux de données raster et les jeux de données mosaïque peuvent comporter de nombreux fichiers différents. Cette rubrique vous guidera lors de l’organisation de ces données afin que vous obteniez les résultats souhaités pendant la publication.
Il est essentiel de comprendre si le chemin d’accès aux données est inscrit dans le répertoire de données, carArcGIS Server suppose qu’il contient toutes les données. En général, cela ne pose pas de problème lorsque l’emplacement inscrit est partagé avec le serveur, contrairement à ce qui se produit lorsque l’emplacement est un doublon. Dans ce cas, les modifications effectuées à un emplacement doivent l’être dans l’autre. Par exemple, si vous construisez des pyramides pour un jeu de données raster dans votre emplacement local, mais que vous ne les copiez pas à l’emplacement dupliqué sur le serveur, elles ne seront pas copiées lors de la publication, car le serveur suppose que tous les fichiers de données sont dupliqués.
Les jeux de données mosaïque sont plus complexes car un plus grand nombre de fichiers est impliqué. L’un des facteurs de complexité concerne l’emplacement des données source de votre jeu de données mosaïque. Si les données source sont un ensemble de jeux de données raster, notamment des pyramides, des statistiques et des fichiers de métadonnées, toutes ces données peuvent se trouver à un emplacement accessible en lecture par le jeu de données mosaïque.
Pour un jeu de données mosaïque stocké dans une géodatabase fichier, si vous créez des vues d’ensemble, elles sont stockées dans un dossier à côté de la géodatabase. Ce dossier porte le même nom que la géodatabase, suivi de l’extension .Overviews. Si vous avez ajouté des données lidar ou généré un cache pour un élément raster, un autre dossier est stocké à côté de la géodatabase avec le même nom et une extension .Cache. Les emplacements de stockage des vues d’ensemble et du cache sont tous deux stockés par défaut à côté de la géodatabase, mais vous pouvez choisir de les stocker ailleurs, ce qui renforce la complexité de votre organisation de données.
Lors de la publication, vérifiez que le serveur a accès à l’ensemble du contenu géré par le jeu de données mosaïque. Vous devez définir le répertoire de données et préparer le jeu de données mosaïque correctement. Chaque scénario ci-dessous traite de ce problème spécifiquement lors de l’utilisation des jeux de données mosaïque, car un jeu de données mosaïque fait référence à des données qui peuvent se trouver n’importe où (tant qu’elles sont lisibles).
Scénario 1 : toutes les données se trouvent à un emplacement partagé
Il s’agit de la structure organisationnelle de données recommandée. Dans ce scénario, toutes les données sont stockées à un emplacement partagé avec vous et le serveur. Vous devez inscrire cet emplacement sur le serveur et vous y connecter dans la fenêtre Catalog (Catalogue) (ou ArcCatalog) pour partager les données qu’il contient sous forme de service d’imagerie. C’est également un moyen de publication rapide, car 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 Catalog (Catalogue). Cette configuration est couramment utilisée lorsque le serveur se trouve dans un cloud ou sur un système d’exploitation Linux.
Vous devez vous assurer que les données sont exactement identiques. Par exemple, si vous modifiez le jeu de données mosaïque en ajoutant une nouvelle image ou en changeant les emprises, vous devez vérifier que la copie à laquelle le serveur accède est mise à jour. Vous devez également vous assurer que les chemins d’accès aux données sont modifiés en conséquence. Un jeu de données mosaïque contient des chemins précodés qui permettent d’accéder à l’ensemble de son contenu. Ainsi, si l’emplacement de votre contenu est D:\MyData et que les données sur le serveur se trouvent dans \\Blue\ServerData, vous devez mettre à jour les chemins dans le jeu de données mosaïque à l’emplacement \\Blue\ServerData. Vous pouvez mettre à jour ces chemins avant ou après la duplication du jeu de données mosaïque (et des fichiers associés) à l’emplacement du serveur ; consultez la rubrique Réparation des chemins d’accès dans un jeu de données mosaïque.
Avant la publication, inscrivez l’emplacement local et celui du serveur en tant que doublons, puis vérifiez que les données sont dupliquées et que les chemins d’accès sont corrects. Vous pouvez ensuite publier le jeu de données mosaïque en pointant vers l’emplacement sur votre machine locale. Le serveur saura que l’emplacement est dupliqué et ne déplacera donc aucune donnée. Comme dans le scénario 1, cela accélère également la publication.
Scénario 3 : aucun emplacement de données n’est inscrit
Comme le scénario 1, ce scénario n’implique pas l’emplacement des données ni l’accès du serveur à leur version correcte. Dans ce scénario, toutes les données sont empaquetées et déplacées vers le serveur lors de la publication. Cela est recommandé pour les petits ensembles de données, mais pas pour ceux de moyenne ou grande taille, en raison du temps nécessaire à l’empaquetage et au déplacement des données. Vous pouvez choisir cette option lorsque vous n’avez pas accès à l’emplacement utilisé par le serveur, ou si vous publiez un petit jeu de données raster, mais cette méthode n’est pas efficace pour déplacer des gigaoctets de données ou davantage.
Scénario 4 : seules les données source se trouvent à un emplacement inscrit
Dans ce scénario, l’emplacement des données source n’est pas le même que celui du jeu de données mosaïque. Cet 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é dans \\yellow\RasterData. Sur votre machine locale, vous créez un jeu de données mosaïque et ajoutez les données à partir de \\yellow\RasterData. Ensuite, lorsque vous publiez le jeu de données mosaïque, le processus inclut l’empaquetage du jeu de données mosaïque et des fichiers associés (comme le contenu du dossier *.Overviews), son déplacement vers le serveur et la mise à jour des chemins d’accès aux fichiers précodés (ou la vérification que les emplacements relatifs demeurent identiques). Cette opération risque de prendre du temps s’il y a beaucoup de vues d’ensemble.
Exemple 2 : données source dupliquées
Les données source sont dupliquées ; sur le serveur, elles se trouvent sur P:\SourceData\RasterData, tandis que sur votre machine locale, elles figurent sur D:\RasterData.
Dans cet exemple, vous devez vérifier que le jeu de données mosaïque n’est pas créé dans D:\RasterData, car le serveur suppose que ces deux emplacements sont dupliqués et ne vérifiera pas P:\SourceData\RasterData pour voir si le jeu de données mosaïque est présent lors de la publication.
Créez votre jeu de données mosaïque à un emplacement unique, comme D:\Collections. Ensuite, lorsque vous publiez le jeu de données mosaïque, le processus inclut l’empaquetage du jeu de données mosaïque et des fichiers associés (comme le contenu du dossier *.Overviews), son déplacement vers le serveur et la mise à jour des chemins d’accès aux fichiers précodés (ou la vérification que les emplacements relatifs demeurent identiques).
Vous avez un commentaire à formuler concernant cette rubrique ?