"Kuriositäten" in der technischen Spezifikation von Shapefile

Ich habe eine Shapefile-Parsing-Bibliothek geschrieben und einige Designentscheidungen in der Spezifikation getroffen , die ich nicht sofort verstehe. Ich hoffe, es gibt hier einen alten ESRI-Entwickler, der mir sagen kann, warum diese Dinge so sind, wie sie sind.

1. Die Hauptdatensatzdatei (.shp) weist eine gemischte Endianität auf . Insbesondere sind Teile des Headers nach Big-Endian-Bytes sortiert, die Datensätze sind jedoch alle Little-Endian-Bytes. Ich arbeite normalerweise auf einer höheren Ebene als Bytes und Bits, aber alles, was ich bisher über Endianness gelesen habe, kennzeichnet dies als ungewöhnlich. Warum ist die angegebene Datei nicht einheitlich?

2. Das Feld "Dateilänge" sowie andere Längen- und Positionsfelder werden in 16-Bit-Wörtern anstelle der (aus meiner Sicht begrenzten) Standard-8-Bit-Positionierung aufgezeichnet. Wie ist diese Entscheidung zustande gekommen?

Ich habe eine ähnliche Frage zu Stack Overflow gestellt, aber keine Antwort erhalten. Wenn dies für andere Leute zu unangebracht erscheint, kann ich es unterstützen, es zu schließen.

Die Entwicklung von Shapefiles ging mit der Entwicklung von ArcView einher, das speziell für die Plattformunabhängigkeit konzipiert wurde. (Tatsächlich stellte sich heraus, dass dies ein Misserfolg war: Wenn man sich auf eine Schnittstelle stützte, die in einer plattformunabhängigen GUI namens "Neuron Data" entwickelt wurde, konnte man nicht viele Windows-Funktionen nutzen. Am Ende spiegelte sie das schlechteste aller Systeme wider wurde vermarktet für.) Obwohl die Shapefile-Spezifikation von Anfang an seltsam war, ergab sie innerhalb dieses Design-Frameworks einen gewissen Sinn: Da Shapefiles für viele Plattformen gedacht waren, sollte ihre Spezifikation keine von ihnen bevorzugen und daher gleichermaßen abscheulich sein für Programmierer aller Überzeugungen.

Die zweite Frage scheint auf einer Annahme zu beruhen, die nicht wahr ist. Beispielsweise erscheint das Feld "File Length" am Byte-Offset 24 im Hauptheader und ist eine (vorzeichenbehaftete) Vier-Byte- (32-Bit-) Ganzzahl, wie sie sein muss, um eine Länge von bis zu 2 ^ 31- darzustellen. 1. Davor stehen ein Vier-Byte- "Dateicode" und fünf weitere Vier-Byte-Felder, die für die zukünftige Verwendung reserviert sind: Wenn Sie solchen Speicherplatz reservieren, möchten Sie die Felder natürlich so groß wie möglich machen, was zu der Zeit der Fall ist war 32 Bit, um die größtmögliche Flexibilität beizubehalten. Es hilft auch, numerische Felder in einer Datei an Wortgrenzen auszurichten:

Jemand da draußen kennt diese und weitere Antworten, aber er redet nicht.

Das Team, mit dem ich zusammengearbeitet habe, um die undokumentierten sbn- und sbx-Dateien zu dekodieren, hat viele weitere Kuriositäten entdeckt, die sich ähneln und gleichzeitig noch bizarrer sind.

Die meisten Shapefile-Strukturen sind logisch und sehr effizient, was darauf hindeutet, dass sich die ESRI-Entwickler Gedanken gemacht haben. Es ist, als hätten sie eine Menge kluger Entwickler mit einem Wahnsinnigen.

Wie bereits in anderen Beiträgen erwähnt, sind die Seltsamkeiten wahrscheinlich das Ergebnis maschineller oder sprachlicher Anforderungen, die uns derzeit fremd sind.

Ich hatte immer den Verdacht, dass 16-Bit-Wörter eine einfache Möglichkeit sind, Platz zu sparen. Sie werden feststellen, dass Sie die 16-Bit-Wortwerte im Speicher halten müssen, wenn Sie mit Dateien arbeiten. Die Strategie, Werte platzsparend zu berechnen, ist bereits heute in Binärformaten üblich. Aber Mikes angeborener Int-Vorschlag ist ebenso wahrscheinlich.

Das Endian-Flipping ist einfach komisch. Niemand hat eine gute Antwort, die ich gesehen habe.

Das dbf-Format wurde aus dem in den 1960er Jahren entstandenen dbase III-Format gerippt. Es ist seitdem weit verbreitet und kann unter anderen Namen wie Foxpro und Xbase gefunden werden.

Trotz der Mängel, Kuriositäten und Einschränkungen des Shapefile-Formats bleibt es hartnäckig im und um das GIS-Gebiet. Jeder andere Versuch, es zu ersetzen, war zu aufgebläht für eine einfache Vektorspeicherung oder zu proprietär. Sogar ESRI dachte, Shapefiles wären ein Spielzeug, das Anfänger in Richtung ArcINFO, Coverages und Geodatabases bewegen würde. Das Internet hatte wahrscheinlich viel mit dem Formatstart zu tun.

Ich habe viel gelernt, pyshp zu schreiben. Das Schreiben eines Parsers ist eine fantastische Möglichkeit, ein Format zu lernen.

Das ist meine Einstellung dazu.

Das Shapefile-Format ist höchstwahrscheinlich aus ARC / INFO hervorgegangen, dessen Geschichte auf FORTRAN / PR1ME zurückgeht. Alle ARC / INFO-Formate hatten diesen 100-Byte-Header und die Big-Endianess des Dateicodes und der Dateilänge (z. B. Coverages, TINs).

Als Shapefiles für ArcView 1 erstellt wurden, konzentrierte sich ESRI darauf, in den Microsoft Windows-Markt einzudringen, und der Rest des Shapefile-Formats konzentriert sich stark darauf, ein kleines Endian von PCs zu sein.

Der ständige Wechsel zwischen Endianess war vermutlich die Notwendigkeit, die alten Ursprünge zu unterstützen und gleichzeitig die Vorteile eines Einbruchs in die Plattform zu erwarten.

Ich bin immer davon ausgegangen, dass der Endian-Split durch zwei Teams auf Sun Workstations und auf PCs verursacht wurde, die sich erst gegen Ende des Entwicklungsprozesses trafen.

Ich würde gerne wissen, was wirklich passiert ist.

Ich glaube, irgendwo dort habe ich etwas über die Entstehung von dbf / foxpro gehört.
Das könnte nur ein seltsamer Traum gewesen sein, den ich hatte.

Man muss verstehen, dass Shapefiles vor etwa 20 Jahren eingeführt wurden. Damals gab es unzählige inkonsistente und schlecht gestaltete Dateiformate, daher sind Shapefiles keine Ausnahme. Ich habe selbst einen Shapefile-Parser geschrieben und ich muss sagen, dass ich im Vergleich zu den Shapefiles (.SHP) selbst viel mehr Probleme beim Parsen des DBF-Formats hatte.