Contournement de la limite de 10 caractères du nom de champ dans les fichiers de formes?

J'exporte une géométrie avec des attributs de texte attachés depuis la base de données Oracle vers le format esri shapefile (.shp) avec les bibliothèques Java et Geotools.

Les colonnes d'attributs de notre base de données ont des noms de plus de 10 caractères, et Geotools oblige à les tronquer. Je comprends que cela est dû aux spécifications de fichiers .shp ou .dbf.

Je peux contourner ce problème en créant un fichier txt simple avec "shrtname" = "Le nom complet et long", mais il ne sera évidemment pas compris et importé par aucun autre logiciel que le nôtre.

Existe-t-il un moyen officiel de mapper des noms de champs courts à des noms de texte intégral longs?

Par exemple, fichier xml à côté de tous les autres fichiers .shp .dbf et .shx.

Désolé, la réponse est non. Vous devez déployer votre propre mappeur de champs et seul le logiciel utilisant votre mappeur le comprendra. Vous pouvez utiliser d'autres formats ne présentant toutefois pas cette limitation (par exemple, géodatabase fichier, spatialite, etc.).

Quelques conseils sur les solutions de contournement de l'expérience personnelle.

Lorsque les personnes choisissent des fichiers de formes (et les insistent sur elles) comme format principal, elles sont généralement choisies pour leur interopérabilité - pensez-y comme adhérant à une spécification. Si vous choisissez de lancer votre propre mappeur de champs, vous faites essentiellement le contraire - puisque vous faites des choses en dehors d'une spécification - vous avez créé votre "spécification étendue".

Ai-je déjà fait cela par le passé? Oui. Et il est très certainement toujours plus pénible que de résoudre un problème, car chaque fois que vous essayez d'ouvrir les fichiers de formes en quelque chose de plus capable de lire / écrire des fichiers de formes, vous vous retrouvez avec une table avec tout un tas de champs difficiles à comprendre. .

À ce stade, je vous demanderais pourquoi vous utilisez des fichiers de formes. Soit une solution de flux de travail qui respecte la spécification de fichier de formes et ses limitations, soit vous modifiez les formats de fichier. Tout le reste n'est qu'une recette pour des maux de tête.

Il existe un moyen standard de gérer cela, bien que vos clients ne soient peut-être pas entièrement satisfaits: vous exportez deux fichiers, un fichier de formes et un fichier de données dans un format lisible par leur logiciel. Le fichier de formes n'a qu'un identifiant unique, [Id], pour les attributs. Le fichier de données a plusieurs attributs: [Id] pour correspondre à la forme, [Champ] pour fournir le nom du champ, [Type] pour indiquer son type et un attribut de chaque type de données possible pour stocker la valeur. Chaque champ du fichier d'origine est stocké en tant qu'enregistrement dans ce fichier de données.

Par exemple, une table source ressemblant à ceci:

[Shape] [Id] [Name]     [Population2010]
shape1  A1   California         37253956
shape2  A2   Texas              25145561
shape3  A3   Wyoming              563626

aurait un fichier de données correspondant

[Id] [Field]        [Type]  [Text]     [Integer]
A1   Name           Text    California    <Null>
A1   Population2010 Integer <Null>      37253956
A2   Name           Text    Texas         <Null>
A2   Population2010 Integer <Null>      25145561
A3   Name           Text    Wyoming       <Null>
A3   Population2010 Integer <Null>        563262

Il devrait être évident de savoir comment utiliser ces données dans n’importe quel SGBDR et comment effectuer des conversions entre les deux formats.

Si votre client utilise ArcGIS, vous pouvez fournir un script pour attribuer des alias de champs en bloc . Cela leur donnerait l'apparence de noms de champs longs lorsqu'ils utilisent les données.

Des scripts similaires peuvent également fournir des alias dans d'autres packages SIG.

La solution la plus simple consiste à stocker UNIQUEMENT votre géométrie en tant que fichier de formes. Pour les excellentes fonctionnalités d’édition de géométrie existantes dans de nombreuses applications SIG, ENCORE, stockez toutes vos données de champ (ou la plupart d’entre elles) dans sqlite sous forme de tableaux. Rejoignez-les si nécessaire pour rechercher vos données de terrain.

MAIS SI vous devez modifier les tables en effectuant des requêtes spatiales ou en sélectionnant les fonctions de fichier de formes dans QGIS, vous devrez oublier l'option [les fichiers de formes joints à des tables sqlite] et au lieu de tout exporter vers Spatialite. Apprenez à utiliser Qspatialite et Spatialite_GUI (ils sont complémentaires l'un de l'autre avec de nombreuses fonctionnalités qui font défaut à l'autre - vous en aurez besoin et vous utiliserez les deux si vous faites beaucoup de choses avec SQLITE)

Il est important de garder à l’esprit que les tables (jointes au shapefile) ne seraient pas modifiables en même temps que la jointure. Ainsi, migrer vers Spatialite serait une excellente alternative aux fichiers de formes. Il conserve la simplicité et la portabilité des fichiers de formes tout en offrant la plupart des avantages d'une base de données SQL, sans la complexité de PostgreSQL.

Un correctif temporaire peut être, en tant que fichier TAB, qui peut avoir des noms de colonne d’une longueur maximale de 31 caractères.