Au fil des ans, Esri a développé trois principaux formats de données pour stocker des informations géographiques : les couvertures, les fichiers de formes et les géodatabases. Les fichiers de formes ont été développés afin de constituer un format simple pour le stockage des données géographiques et attributaires. Grâce à leur simplicité, ils sont devenus un format ouvert très utilisé pour le transfert de données. Bien qu'ils puissent paraître un choix facile en raison de leur simplicité, leur utilisation comporte toutefois des limites, lesquelles sont résolues par les géodatabases. Lors de l'utilisation de fichiers de formes, vous devez être conscient de ces limites. De manière générale :
- Les données géographiques sont plus complexes que les entités et attributs simples stockés par un fichier de formes. Elles comprennent par exemple des annotations, relations attributaires, relations de topologie, domaines et sous-types attributaires, précision et résolution des coordonnées, ainsi que de nombreuses autres fonctions prises en charge dans les géodatabases mais pas dans les fichiers de formes.
- En raison de la popularité des fichiers de formes en tant que format ouvert pour le transfert de données, de nombreux progiciels non-Esri créent des fichiers de formes en sortie. (Pour connaître la spécification du format de fichier de formes, consultez l'adresse suivante : http://www.esri.com/library/whitepapers/pdfs/shapefile.pdf.) Malheureusement, ces progiciels ne respectent pas toujours le format des fichiers de formes. Il vous est peut-être déjà malheureusement arrivé de recevoir des fichiers de formes endommagés provenant d'une autre source.
- Pour stocker des attributs, les fichiers de formes utilisent le format de fichier dBASE (fichier .dbf). Le format dBASE non-Esri, développé au début des années 1980, était alors le format le plus répandu pour le stockage des tables d'attributs. La représentation de données a toutefois connu de nombreuses améliorations depuis, comme la norme Unicode qui assure la prise en charge de la majorité des systèmes d'écriture dans le monde. C'est l'une des raisons pour lesquelles les fichiers de formes n'assurent pas correctement le stockage de données dans les langues autres que l'anglais.
- Contrairement aux classes d'entités dans une géodatabase, ArcGIS ne calcule ni ne gère les champs Shape_Length et Shape_Area.
Ces problèmes (et bien d'autres encore) montrent que les fichiers de formes restent extrêmement limités dans le cadre de la gestion de bases de données actives. Ils ne sont pas adaptés au cycle de vie moderne de création, modification, versionnement et archivage des données.
Quand utiliser un fichier de formes ?
- Lorsque vous exportez des données destinées à des applications non-Esri
- Lorsque vous exportez des données destinées à ArcView GIS 3 ou ArcInfo Workstation
- Lorsque vous devez créer rapidement des entités et des attributs simples. (Tenez toutefois compte des limites ci-dessous.)
Quand utiliser un autre format ?
A l'exception des cas notés ci-dessous, les fichiers de formes sont acceptables pour le stockage de géométries d'entité simples. Ils entraînent toutefois des problèmes graves avec les attributs. Par exemple : ils ne peuvent pas stocker de valeurs Null, ils arrondissent les nombres, ils présentent une prise en charge médiocre des chaînes de caractères Unicode, ils restreignent les noms de champ à 10 caractères et ils ne peuvent pas stocker l'heure dans un champ de date. Il s'agit là uniquement des problèmes principaux. Ils ne prennent par ailleurs pas en charge certaines fonctionnalités qui figurent dans les géodatabases, comme les domaines et les sous-types. Il est donc recommandé de ne pas utiliser de fichiers de formes, sauf en cas d'attributs très simples n'exigeant pas de fonctionnalités de géodatabase.
Composants des fichiers de formes et extensions de fichier
Les fichiers de formes sont stockés dans trois fichiers ou plus, portant le même préfixe et stockés dans le même dossier système (espace de travail du fichier de formes). Les fichiers individuels ne s'affichent pas dans ArcCatalog, mais ils apparaissent dans le dossier dans l'Explorateur Windows.
| Extension | Description | Obligatoire |
|---|---|---|
| .shp | Fichier principal pour le stockage de la géométrie des entités. Ce fichier ne contient aucun attribut, uniquement la géométrie. | Oui |
| .shx | Fichier complémentaire du fichier .shp, indique la position des identifiants d'entités individuelles dans le fichier .shp. | Oui |
| .dbf | Table dBASE dans laquelle sont stockées les données attributaires des entités. | Oui |
| .sbn et .sbx | Fichiers contenant l'index spatial des entités. | Non |
| .atx | Créé pour chaque index attributaire dBASE généré dans ArcCatalog. | Non |
| .ixs et .mxs | Index de géocodage pour les fichiers de formes en lecture/écriture. | Non |
| .prj | Fichier contenant les données du système de coordonnées. | Non |
| .xml | Métadonnées pour ArcGIS ; stocke des informations sur le fichier de formes. | Non |
Limites de la géométrie
- Les fichiers composant le fichier de formes sont limités à une taille de 2 Go chacun, ce qui correspond à environ 70 millions d'entités ponctuelles. La capacité réelle d'un fichier de formes en entités linéaires ou surfaciques dépend du nombre de sommets de chaque entité (un sommet est équivalent à un point).
- Contrairement aux classes d'entités de géodatabase, les fichiers de formes ne contiennent aucune tolérance x,y. La tolérance x,y correspond à la distance minimale entre des coordonnées avant qu'elles ne soient considérées comme étant identiques. La tolérance x,y est utilisée lors de l'évaluation des relations entre les entités d'une même classe d'entités ou entre plusieurs classes d'entités différentes. Elle est aussi largement utilisée lors de la modification d'entités. Lorsque vous effectuez une opération impliquant une comparaison entre entités (utilisation des Outils de superpositions, de l'outil Découper ou Sélectionner une couche par emplacement ou encore de tout outil acceptant au moins deux classes d'entités en tant qu'entrée), vous devez utiliser des classes d'entités de géodatabase (ayant une tolérance x,y) plutôt que des fichiers de formes.
- Un fichier de formes peut occuper trois à cinq fois plus d'espace qu'une géodatabase fichier ou SDE en raison des méthodes de compression de forme.
- Les fichiers de formes prennent en charge les multipatchs, mais sans les fonctionnalités avancées suivantes :
- Coordonnées de texture,
- Couleur des textures et des parties,
- Normales d'éclairage.
- L'index spatial des fichiers de formes est inefficace comparé à celui d'une classe d'entités de géodatabase. Cela signifie que les requêtes spatiales (la sélection des entités dans un polygone, par exemple) prennent davantage de temps, comparé à une classe d'entités de géodatabase. Cette inefficacité est visible essentiellement lors du traitement de nombres importants d'entités.
- Les courbes définies à l'aide de paramètres (également appelées « courbes d'arc circulaire ») ne sont pas prises en charge dans les fichiers de formes. Vous pouvez créer des courbes paramétriques en modifiant des classes d'entités de géodatabase comme indiqué dans la rubrique Création d'une courbe. Les courbes d'arc circulaire utilisent une formule mathématique pour le tracé de la courbe. Si vous exportez une classe d'entités de géodatabase contenant des entités courbe d'arc circulaire vers un fichier de formes, les entités courbes sont transformées en simples entités linéaires avec des sommets rapprochés, permettant une approximation de la forme courbée.
Limites des attributs
- A la différence d'autres formats, les fichiers de formes stockent les attributs numériques dans un format caractère plutôt que dans un format binaire. Ce stockage peut provoquer des erreurs d'arrondi pour les nombres réels (autrement dit, les nombres comprenant des décimales). Cette limite ne concerne pas les coordonnées des formes, mais uniquement les attributs. Le tableau suivant récapitule la largeur de champ de chaque type de données attributaires.
Longueurs de champ dans un dBASEType de données de géodatabase Type de champ dBASE Largeur du champ dBASE (nombre de caractères) ID d'objet
Nombre
9
Entier court
Nombre
4
Entier long
Nombre
9
Flottant
Flottant
13
Réel double
Flottant
13
Texte
Caractère
254
Date
Date
8
- La norme de fichier dBASE ne prend en charge que des caractères ANSI dans les noms de champ et les valeurs. Esri a ajouté une prise en charge Unicode étendue pour les fichiers dBASE, afin de permettre le stockage de noms de champ et de valeurs Unicode. Cette prise en charge supplémentaire n'existe toutefois que dans ArcGIS et risque de ne pas être disponible dans des applications tierces non Esri.
- Les champs de date ne prennent en charge que la date. Ils ne prennent pas en charge l'heure.
- Les noms de champ ne peuvent pas dépasser 10 caractères.
- La longueur d'enregistrement maximale pour un attribut est de 4 000 octets. La longueur de l'enregistrement correspond au nombre d'octets nécessaire à la définition de l'ensemble des champs, pas au nombre d'octets utilisé pour stocker les valeurs réelles.
- Le nombre maximal de champs est 255. Lors de la conversion d'un fichier de formes, seuls les 255 premiers champs sont convertis si cette limite est dépassée.
- Le fichier dBASE doit contenir au moins un champ. Lors de la création d'un fichier de formes ou d'une table dBASE, un champ ID de type entier est créé par défaut.
- Les fichiers dBASE ne prennent pas en charge les types de champ BLOB, GUID, ID global, ID de coordonnées ou raster.
- Les fichiers dBASE disposent d'une prise en charge SQL restreinte, à l'exception d'une clause WHERE.
- Les index attributaires sont supprimés lors de la sauvegarde des modifications et doivent être recréés de toutes pièces.
Représentation de valeurs Null
Les valeurs Null ne sont pas prises en charge dans les fichiers de formes. Si une classe d'entités contenant des valeurs Null est convertie en un fichier de formes ou qu'une table de base de données est convertie en un fichier dBASE, les valeurs Null sont modifiées comme cela est indiqué dans la table suivante :
| Type de données contenant la valeur Null | Substitution de valeurs Null |
|---|---|
| Nombre : lorsque l'outil requiert une valeur NULL, infinie ou NaN (Not a Number) en sortie | -1.7976931348623158e+308 (norme IEEE pour la valeur négative maximale) |
| Nombre (tous les autres outils de géotraitement) | 0 |
| Texte | " " (vide, sans espace) |
| Date | Stockée comme un zéro, mais affichant <null> |
Fonctionnalités non prises en charge
Les fichiers de formes ne disposent d'aucun type de données étendu à l'échelle de l'espace de travail ou de la classe d'entités. Toute conversion d'une classe d'entités de géodatabase ou d'un autre format en fichier de formes implique la perte des éléments suivants :
- Sous-types
- Domaines attributaires
- Réseaux géométriques
- Topologies
- Annotation
Longueur de forme et surface de forme
Pour les classes d'entités linéaires ou surfaciques stockées dans une géodatabase, ArcGIS calcule et gère les champs shape_length et shape_area. Ainsi, lorsque vous modifiez la forme d'une ligne ou d'un polygone dans une classe d'entités de géodatabase, les valeurs des champs shape_length et shape_area sont recalculées pour refléter les modifications apportées aux entités. Ce n'est pas le cas pour les fichiers de formes. Même si votre fichier de formes comporte un champ shape_area ou shape_leng, ce dernier n'est pas mis à jour si le fichier de formes est modifié.
Fichiers de formes et géotraitement
Tout outil de géotraitement qui génère une classe d'entités permet de sélectionner soit un fichier de formes soit une classe d'entités de géodatabase comme format en sortie. De la même manière, un outil qui génère une table permet de sélectionner un fichier dBASE (.dbf) ou une table de géodatabase en sortie. Prenez toujours en compte le format utilisé, ainsi que les conséquences de la conversion d'une géodatabase en entrée en fichier de formes en sortie.
Les outils de géotraitement génèrent automatiquement une table ou une classe d'entités en sortie. Cette sortie automatiquement générée repose sur plusieurs facteurs décrits dans la rubrique Utilisation des environnements d'espace de travail temporaire et courant. Si votre environnement d'espace de travail temporaire est défini sur un dossier système au lieu d'une géodatabase, la classe d'entités en sortie générée automatiquement est un fichier de formes ou un fichier dBASE, comme illustré ci-dessous.
Il est conseillé de définir l'espace de travail temporaire sur une géodatabase fichier, de sorte que la sortie automatiquement générée soit écrite dans une géodatabase fichier plutôt qu'un fichier de formes ou une table .dbf.
En savoir plus sur les environnements de géotraitement
Comme les fichiers de formes s'écrivent rapidement, ils sont souvent utilisés pour écrire des données intermédiaires dans des modèles et accélérer de ce fait l'exécution des modèles. L'écriture dans une géodatabase fichier est toutefois presque aussi rapide que dans un fichier de formes. Si la vitesse d'exécution importe peu, il est donc conseillé de toujours utiliser une géodatabase fichier pour les données intermédiaires et en sortie. Si vous utilisez des fichiers de formes, prenez en compte les limites décrites ci-dessus et restreignez leur utilisation à des entités et attributs simples. L'alternative à l'utilisation de fichiers de formes pour les données intermédiaires consiste à enregistrer des entités dans l'espace de travail in_memory.
Pour en savoir plus sur l'espace de travail temporaire
Référence spatiale et fichiers de formes
La rubrique Référence spatiale et géotraitement souligne l'importance des propriétés de référence spatiale lors de l'utilisation d'outils de géotraitement. Il existe plusieurs environnements de géotraitement qui contrôlent la référence spatiale utilisée par les outils. Les environnements suivants ne sont pas respectés lorsque la sortie d'un outil est un fichier de formes :