Vous pouvez utiliser l'outil de géotraitement Migrer le stockage pour effectuer la migration des éléments binaires ou spatiaux ou des colonnes raster d'un type de stockage à un autre. Pour ce faire, indiquez un mot-clé de configuration contenant un paramètre ATTRBUTE_BINARY, GEOMETRY_STORAGE ou RASTER_STORAGE défini sur le nouveau type de stockage vers lequel effectuer la conversion.
Vous pouvez également utiliser l'outil de géotraitement Migrer le stockage pour changer le format de stockage des attributs géométriques des objets paramétriques et des faces surfaciques dans les géodatabases dans SQL Server.
Il est important que le mot-clé de configuration créé contienne le paramètre et la valeur corrects. Si vous indiquez un mot-clé avec des informations inexactes ou manquantes, les informations sont lues à partir du mot-clé DEFAULTS. Esri vous recommande de créer un mot-clé personnalisé spécifiquement pour la migration. Assurez-vous que le mot-clé contienne le paramètre et la valeur vers lesquels vous migrez les données, ainsi que le paramètre UI_TEXT. Le paramètre UI_TEXT rend le mot-clé accessible aux clients ArcGIS.
Voici les chemins de migration pris en charge pour chaque système de gestion de bases de données :
| Système de gestion de bases de données | Paramètre de configuration | Migrer depuis/vers |
|---|---|---|
Oracle | ATTRIBUTE_BINARY | LONG RAW vers BLOB |
GEOMETRY_STORAGE | Long Raw (SDEBINARY) vers BLOB (SDELOB) | |
Long Raw (SDEBINARY) vers ST_Geometry | ||
BLOB (SDELOB) vers ST_Geometry | ||
SDO_Geometry vers ST_Geometry | ||
RASTER_STORAGE | LONG RAW vers BLOB | |
Long Raw vers ST_Raster* | ||
BLOB vers ST_Raster* | ||
PostgreSQL | RASTER_STORAGE | Bytea vers ST_Raster* |
SQL Server | RASTER_STORAGE | Image vers ST_Raster* |
GEOMETRY_STORAGE | SDEBINARY vers Geometry | |
SDEBINARY vers Geography | ||
OGCWKB vers Geometry | ||
OGCWKB vers Geography | ||
Attributs géométriques stockés dans une table associée vers des attributs géométriques stockés dans une colonne de la table de base |
*ST_Raster doit être installé dans la géodatabase. Reportez-vous aux rubriques Installer ST_Raster dans Oracle, Installer ST_Raster dans PostgreSQL ou Installer ST_Raster dans SQL Server pour plus d'informations.
Pourquoi migrer les données ?
Voici pourquoi migrer vos données :
- Pour accéder à vos données spatiales ou raster à l'aide de SQL (Structured Query Language)
- Pour passer d'un type de données qui peut ne plus être pris en charge à l'avenir à un type pris en charge
- Pour déplacer les informations des attributs géométriques d'une table de base dans SQL Server à une colonne dans la table de base afin d'optimiser les performances dans les ateliers parcellaires
Accès aux données à l'aide de SQL
L'accès aux informations dans une géodatabase via SQL permet aux applications externes (celles qui ne sont pas développées dans un environnement ArcObjects) d'utiliser les données tabulaires gérées par la géodatabase. Si ces applications doivent accéder aux données spatiales ou raster dans la géodatabase, vous devez stocker vos données spatiales ou raster dans des types de données qui permettent un accès SQL. Par exemple, le type de stockage ST_Geometry permet d'accéder aux données d'entité par SQL, ce qui n'est pas facile si les données sont stockées dans un champ BLOB ou Long Raw.
Migrer de types qui peuvent ne plus être pris en charge dans les versions futures
Les classes d'entités créées dans les géodatabases ArcGIS 10.1 et version ultérieure, sur SQL Server, utilisent le type Geometry Microsoft par défaut. Pour déplacer vos classes d'entités existantes vers le type de stockage Geometry, utilisez l'outil de géotraitement Migrer le stockage ou un script Python.
Déplacer les attributs géométriques pour optimiser les performances
A partir d'ArcGIS 10.5, le stockage des attributs géométriques des objets paramétriques (les courbes vraies, par exemple) et des faces surfaciques (les ID de point et les multipatchs, par exemple) s'est amélioré. Il est placé directement dans la table métier. Dans les versions antérieures, ces données attributaires étaient stockées dans une table associée qui était jointe à une table métier. Cette jointure pouvait engendrer des performances médiocres et était souvent remarquée lors de l'utilisation d'ateliers parcellaires.
Si vos classes d'entités existantes font partie d'ateliers parcellaires ou stockent une courbe vraie, des multipatchs ou des ID de point et que vous constatez une dégradation des performances, envisagez de migrer le stockage de ces attributs géométriques. Voici les chemins de migration pris en charge pour les classes d'entités existantes :
- Le type de stockage est Géométrie Microsoft et vous voulez continuer à utiliser le type de géométrie.
Pour migrer les attributs géométriques de la table associée vers une nouvelle colonne dans la table métier de la classe d'entités, indiquez un mot-clé de configuration dont le paramètre GEOMETRY_STORAGE est défini sur Géométrie et exécutez l'outil Migrer le stockage.
- Le type de stockage est Géographie Microsoft et vous voulez continuer à utiliser le type de géographie.
Pour migrer les attributs géométriques de la table associée vers une nouvelle colonne dans la table métier de la classe d'entités, indiquez un mot-clé de configuration dont le paramètre GEOMETRY_STORAGE est défini sur Géographie et exécutez l'outil Migrer le stockage.
- Le type de stockage est SDEBINARY et vous voulez effectuer la migration vers le type Géométrie Microsoft. Dans ce cas, indiquez un mot-clé de configuration dont le paramètre GEOMETRY_STORAGE est défini sur Géométrie et exécutez l'outil Migrer le stockage. Cette opération permet de migrer à la fois le type de données spatiales et les attributs géométriques vers le nouveau format de stockage.
Dans ce cas, indiquez un mot-clé de configuration dont le paramètre GEOMETRY_STORAGE est défini sur Géographie et exécutez l'outil Migrer le stockage. Cette opération permet de migrer les attributs géométriques vers le nouveau format de stockage.
- Le type de stockage est SDEBINARY et vous voulez effectuer la migration vers le type de géométrie.
Dans ce cas, indiquez un mot-clé de configuration dont le paramètre GEOMETRY_STORAGE est défini sur Géographie et exécutez l'outil Migrer le stockage. Cette opération permet de migrer à la fois le type de données spatiales et les attributs géométriques vers le nouveau format de stockage.
Conditions requises pour la migration
Les conditions suivantes doivent être vérifiées avant la conversion de vos données :
- Vous devez effectuer une sauvegarde des données avant d'effectuer leur migration.
- Si vous effectuez une conversion du type de données de colonne spatiale, les données doivent être stockées en haute précision. Si vos données sont actuellement stockées en précision de base, vous devez tout d'abord effectuer une migration vers la haute précision avant de migrer le type de stockage. Utilisez l'outil de géotraitement Mettre à jour une référence spatiale pour procéder à une mise à niveau vers la haute précision.
- La table ou la classe d'entités doit être inscrite auprès de la géodatabase.
- Le mot-clé de configuration spécifié lors de la migration du type de données doit contenir la valeur correcte pour le paramètre GEOMETRY_STORAGE, ATTRIBUTE_BINARY ou RASTER_STORAGE. Par exemple, si vous voulez effectuer la migration d'une colonne de géométrie depuis le type Long Raw vers le type ST_Geometry, mais vous spécifiez un mot-clé ayant le paramètre GEOMETRY_STORAGE défini sur SDO_GEOMETRY, la migration échoue parce qu'il ne s'agit pas d'un chemin de migration pris en charge.
- Vous devez être connecté en tant que propriétaire de la table contenant la colonne à migrer.
- Pour effectuer la migration d'une classe d'entités vers le type SQL Server Geography, les données doivent être dans l'un des systèmes de coordonnées géographiques pris en charge par le type Geography.