«Curiosités» dans la spécification technique Shapefile

32

Je suis en train d'écrire une bibliothèque d'analyse de fichier de formes et j'ai pris quelques décisions de conception dans la spécification que je ne comprends pas tout de suite. J'espère qu'il y a un vieux développeur ESRI assoiffé ici qui peut me dire pourquoi ces choses sont comme elles sont.

Le fichier d'enregistrement principal (.shp) a une finalité mixte . Plus précisément, certaines parties de l'en-tête présentent un ordre d'octet volumineux, mais les enregistrements sont tous peu étendus. Je travaille généralement à un niveau plus élevé que les octets et les bits, mais tout ce que j'ai lu jusqu'à présent au sujet de l'endianisme marque ce fait comme inhabituel. Pourquoi le fichier spécifié n'a-t-il pas une finalité uniforme?
Le champ "Longueur du fichier", ainsi que d'autres champs de longueur et de position, sont enregistrés en mots de 16 bits, au lieu du positionnement 8 bits plus standard (de mon point de vue limité). Comment cette décision a-t-elle été prise?

J'ai posté une question similaire sur Stack Overflow, mais je n'ai reçu aucune réponse. Si cela semble trop éloigné du sujet pour d'autres personnes, je pourrais soutenir la fermeture.

shapefile

— canisrufus
source

4

Joel Lawhead de GeospatialPython.com travaille depuis un certain temps à résoudre les mystères des fichiers de formes.

— Chad Cooper le

Pas exactement lié, mais soigné! J'espère que le comprendre.

— Canisrufus

28

Le développement des fichiers de formes s'est déroulé parallèlement au développement d'ArcView, spécialement conçu pour être indépendant de la plate-forme. (En fait, cela s’est avéré être son inconvénient: en s’appuyant sur une interface développée dans une interface graphique indépendante de la plate-forme appelée "Neuron Data", il ne pouvait tirer parti de nombreuses fonctionnalités de Windows. Il finissait par refléter le pire de tous les systèmes qu’il utilisait. a été commercialisé.) Bien que la spécification de fichier de forme ait été étrange au début, elle a toutefois donné un sens à ce concept: dans la mesure où les fichiers de forme sont destinés à de nombreuses plates-formes, leur spécification ne doit favoriser aucune d’entre elles et doit donc être tout aussi odieuse. aux programmeurs de toutes tendances.

La deuxième question semble reposer sur une hypothèse fausse. Par exemple, le champ "Longueur du fichier" apparaît avec le décalage d'octet 24 dans l'en-tête principal et correspond à un entier (signé) de quatre octets (32 bits), comme il doit l'être pour représenter une longueur maximale de 2 ^ 31- 1. Il est précédé d'un "Code de fichier" de quatre octets et de cinq autres champs de quatre octets réservés pour une utilisation future: lorsque vous réservez cet espace, vous souhaitez bien entendu agrandir autant que possible les champs, ce qui à l'époque était de 32 bits, afin de maintenir la plus grande flexibilité possible. Il est également utile d’aligner les champs numériques d’un fichier sur les limites de mots:

— whuber
source

2

:) Exactement ce que je cherchais. Lorsque je dis que le champ "Longueur du fichier" est "enregistré en mots de 16 bits", ce que je tente de dire, c'est que la valeur de l'entier 32 bits enregistre la longueur du fichier en mots de 16 bits. (D'après la spécification: "La valeur de la longueur du fichier est la longueur totale du fichier en mots de 16 bits"). Il semble que cela puisse représenter une longueur d'octet de 2 * 2 ^ 31-1, ce qui correspond à environ 4 Go. Il en va de même pour les valeurs du fichier .shx. Il semble qu'il devrait pouvoir prendre en charge des fichiers d'une longueur maximale de 2 * 2 ^ 31-1 octets. Qu'est-ce que je rate?

— Canisrufus

Bon point - j'ai raté ça. En fait, la conception aurait tout aussi bien pu créer des longueurs et des décalages de fichiers (pointeurs dans le fichier .shx) en termes de mots de quatre octets, augmentant ainsi la taille possible du fichier .shp à 4 * (2 ^ 31-1) (environ 8 milliards d'octets). Je ne sais pas pourquoi ils ont choisi des mots de deux octets, ni même pourquoi ils utilisent systématiquement signé des entiers non signés où entiers sont à la fois plus appropriés et prévoient deux fois plus de stockage.

— whuber

1

Je me demande si la bizarrerie 16 bits a à voir avec les ordinateurs 16 bits utilisés à l'époque, où un ordinateur natif intétait de 16 bits.

— Mike T

C'est toujours une possibilité, @Mike. Cependant, même les ordinateurs 80286 (c. 1984) prenaient nativement en charge les ints 32 bits - ils utilisaient des paires de registres pour effectuer des opérations arithmétiques.

— whuber

5

Un collègue d'Esri dit qu'il se souvient que le mélange d'endurance était délibéré. Quelque chose du genre "nous ferons en sorte que les développeurs s'en chargent carrément à cause de problèmes multi-plateformes". Mais, bien sûr, tout cela est apocryphe.

— Mkennedy

10

Quelqu'un connaît ces réponses et plus mais il ne parle pas.

L’équipe avec laquelle j’ai travaillé pour décoder les fichiers non documentés sbn et sbx a découvert beaucoup d’autres bizarreries qui sont à la fois similaires et encore plus bizarres à la fois.

La plupart des structures de fichier de formes sont logiques et très efficaces, ce qui suggère aux développeurs d’ESRI de réfléchir. C'est comme si ils avaient un groupe de développeurs intelligents avec un lunatique jeté dedans.

Comme suggéré par d'autres publications, les bizarreries sont probablement le résultat d'exigences de machine ou de langage qui nous sont étrangères maintenant.

J'ai toujours pensé que les mots 16 bits étaient un moyen simple de gagner de la place. Vous constaterez que vous devez conserver les valeurs de mot de 16 bits en mémoire lorsque vous manipulez des fichiers. La stratégie consistant à calculer des valeurs pour économiser de l'espace est courante dans les formats binaires, même aujourd'hui. Mais la suggestion int native de Mike est tout aussi probable.

Le retournement endian est juste bizarre. Personne n'a une bonne réponse que j'ai vue.

Le format dbf a été extrait du format dbase III datant des années 1960. Il a été largement utilisé depuis et peut être trouvé sous d'autres noms, y compris foxpro et xbase.

Malgré les défauts, les bizarreries et les limitations du format de fichier de formes, il persiste obstinément dans et autour du domaine des SIG. Toute autre tentative de le remplacer a été trop compliquée pour permettre un simple stockage de vecteurs ou trop exclusive. Même ESRI pensait que les fichiers de formes seraient un jouet qui permettrait aux débutants d’orienter ArcINFO, les couvertures et les géodatabases. Internet a probablement beaucoup à voir avec le décollage du format.

J'ai beaucoup appris en écrivant pyshp. Écrire un analyseur est un moyen fantastique d’apprendre un format.

— GeospatialPython.com
source

Hmm. Bonne réponse. Je ne comprends pas comment l'utilisation de mots de 16 bits permet d'économiser de l'espace. Pour mes besoins (construire ArrayBufferViews en javascript), cela ne fait que me forcer à le multiplier par deux pour obtenir le décalage correct: je brûle des cycles supplémentaires sans aucun bénéfice. Voulez-vous élaborer?

— Canisrufus

1

Oui, puisqu'ils ont utilisé des entiers signés, ils ont une valeur supérieure à 32 767, ce qui leur permet de stocker des nombres plus importants sur 2 octets au lieu de 4. Les valeurs attribuées aux mots de 16 bits, comme je l'ai dit, sont des valeurs que vous finissez par retenir RAM lorsque vous travaillez avec des fichiers de formes pour des opérations de lecture et d’écriture. Venir avec un schéma pour économiser de l'espace sur les doubles (que j'ai vu dans d'autres formats binaires) est toujours laid et compliqué. Ils se sont donc contentés d'un schéma simple pour les valeurs de taille de données.

— GeospatialPython.com

En outre, j'ai découvert dans les fichiers shx qui m'ont bloqué au début. Les fichiers SHX ont des cadres de sélection pour les fonctionnalités mappées sur une grille de 256x256 nombres entiers. Cette technique est courante dans l'indexation mais pas sur une grille aussi petite. Ils enregistrent les coordonnées sous forme de caractères de 1 octet au lieu d’ints. C'est pourquoi la grille est seulement 256x256. Maintenant, c’est carrément avare de mémoire, même pour les années 90! Il existe bien sûr de nombreux autres gains d'efficacité, tels que le regroupement implicite de pièces à l'aide d'un index. Vous avez raison - ces techniques alourdissent la charge du programmeur. Donc, l'utilisation de la mémoire doit avoir été une priorité.

— GeospatialPython.com

1

Yah, je lis votre écriture. Vous faites le bon travail du seigneur sur celui-là;) J'attends avec impatience votre analyse finale. En ce qui concerne le problème 16 bits, je ne suis pas sûr que votre argument soit valable. 1. Dans les fichiers SHP et SHX, il n'y a pas de champs 16 bits, sauf erreur de ma part. 2. Représenter des valeurs de 16 bits au lieu de 8 bits ne fait que doubler la longueur pouvant être décrite (2 * 2 ^ 15), ce qu'ils auraient pu obtenir simplement en utilisant un unsigned int (2 ^ 16). En fin de compte, cela ne économise aucun espace.

— Canisrufus

Lorsque vous vous référez à "utilisation de la mémoire", il est difficile de dire si vous voulez dire RAM ou disque. Au début des années 90, un lecteur de 2 Go et de 16 à 32 Mo de RAM étaient plutôt haut de gamme: économiser de l'espace sur les fichiers (ou la bande passante du réseau) aurait tout de même son importance. Un ingénieur en logiciel responsable voudrait bien réfléchir aux implications pour leurs futurs clients des compromis entre espace et espace; avec le recul, je leur donnerais le bénéfice du doute à moins que le choix ne soit manifestement, inefficace et dévastateur.

— whuber

5

Ceci est mon point de vue sur elle.

Le format de fichier de formes a très probablement évolué à partir d’ARC / INFO, dont l’histoire remonte aux origines de FORTRAN / PR1ME. Tous les formats ARC / INFO avaient cet en-tête de 100 octets et la grande finesse du code de fichier et de la longueur du fichier (par exemple, les couvertures, les TIN).

Lorsque les fichiers de formes ont été créés pour ArcView 1, ESRI a concentré ses efforts sur le marché de Microsoft Windows et le reste du format Shapefile est fortement axé sur le fait d’être un peu moins puissant que les PC.

La permutation constante entre les finales était, sans doute, la nécessité de préserver les origines existantes tout en anticipant les avantages liés à l’introduction de la plateforme.

— Stephen Quan
source

Cela semble plausible. Merci pour la perspicacité!

— whuber

Ceci est ma conjecture préférée sur l'endianité. Maintenant, tout ce dont nous avons besoin, c'est Dangermond pour publier "The ESRI Tell All, édition technique" pour voir si vous avez raison!

— Canisrufus

2

Si le format du fichier de formes a évolué à partir des formats ARC / INFO, il était considérablement plus ancien que la v7. En 1994, lorsque j'ai commencé à travailler chez ESRI, AV2 était déjà disponible et les travaux de développement d'ARC / INFO 7 étaient en cours.

— Mkennedy

Bon point, Melita. L'essentiel de cette réponse - selon laquelle certains choix de formats pourraient finalement avoir des origines fortranes - resterait valable jusqu'aux applications Arc et Info d'origine.

— whuber

Merci @mkennedy, j'ai supprimé la référence à la v7. Je me souviens encore des jours où les manuels d’utilisation originaux d’ARC / INFO (v3 .. v6 era) avaient des en-têtes qui, je crois, étaient tirés du code FORTRAN.

— Stephen Quan

4

J'ai toujours supposé que la scission finale était causée par la présence de deux équipes, l'une sur les stations de travail Sun et l'autre sur les PC, qui ne se réunissaient pas avant la fin du processus de développement.

J'aimerais savoir ce qui s'est réellement passé.

— Ian Turton
source

3

Je pense que ESRI était un peu plus coordonné que cela. En fait, leur logiciel a tendance à donner l'impression que les comités ont trop participé à sa conception.

— whuber

0

Je pense que quelque part là-bas, j'ai entendu quelque chose à propos de l'origine dbf / foxpro.
Cela aurait pu être juste un rêve étrange que j'avais cependant.

— Brad Nesom
source

5

Les parties .shp et .shx, dont il est question ici, ont été conçues de manière totalement indépendante du format .dbf, utilisé depuis près de 20 ans.

— whuber

0

Vous devez comprendre que les fichiers de formes ont été introduits il y a environ 20 ans. À cette époque, il existait une myriade de formats de fichiers incohérents et mal conçus. Les fichiers de formes ne font donc pas exception. J'ai moi-même écrit un analyseur de fichier de formes et je dois dire que l'analyse du format DBF me pose bien plus de problèmes que les fichiers de formes (.SHP) eux-mêmes.

— Igor Brejc
source