Remarques concernant le géotraitement pour la sortie de fichiers de formes
Au fil des ans, Esri a développé trois principaux formats de données pour le stockage d'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 non topologique 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 autres qu'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.
- Les fichiers de formes utilisent le format de fichier dBASE (fichier .dbf) pour stocker les attributs. dBASE est un format autre qu'Esri qui a été développé au début des années 1980 et qui était, à l'époque, le format le plus répandu pour le stockage des tables attributaires. 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.
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 ?
- Lors de l'exportation de données à exploiter dans une application autre qu'un logiciel Esri.
- Lors de l'exportation de données à exploiter dans ArcView GIS 3 ou ArcInfo Workstation.
- Lorsque vous devez écrire rapidement des attributs et des entités simples, notamment pour les services de géotraitement (vous devez toutefois connaître les limites mentionnées 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 pour les chaînes de caractères Unicode, ils restreignent les noms de champ à 10 caractères et ils ne peuvent pas stocker une date et une heure dans le même champ. 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 lors de la consultation du 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 de fichier dBASE créé 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 désignées par "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 de l'objet
Nombre
9
Entier court
Nombre
4
Entier long
Nombre
9
Flottant
Flottant
13
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 (autres qu'Esri). Esri œuvre continuellement à la prise en charge Unicode dans les fichiers dBASE, la détection et la résolution des problèmes se poursuivent donc actuellement.
Remarque :pour la prise en charge d'Unicode dans vos noms ou valeurs de champ, il est fortement conseillé d'utiliser des géodatabases plutôt que des fichiers de formes.
- Les champs de date prennent en charge la date ou l'heure, mais pas les deux dans le même champ.
- 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. Si cette limite est dépassée, la conversion en fichier de formes est effectuée sur les 255 premiers champs.
- 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 :
Attention :Lorsque vous spécifiez des fichiers de formes ou au format dBASE (.dbf) dans des outils, ArcGIS ne peut pas déterminer si une valeur de champ représente une valeur Null ou une valeur légitime.
|
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 sous la forme zéro, mais affiche "<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
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 aborde 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 suivant ne sont PAS respectés lorsque la sortie d'un outil est un fichier de formes :