Shapefile技術仕様の「奇数」

私はシェープファイル解析ライブラリを書いてきましたが、すぐには理解できない仕様の設計上の決定にいくつか遭遇しました。これらの事柄がなぜそうなのかを教えてくれる、賢明な古いESRI開発者がここにいることを望んでいます。

1. メインレコードファイル（.shp）は混合エンディアンです。具体的には、ヘッダーの一部はビッグエンディアンのバイト順を特徴としていますが、レコードはすべてリトルエンディアンです。私は通常、バイトやビットよりも高いレベルで作業しますが、エンディアンについてこれまで読んだことはすべて、これを異常であるとマークしています。なぜファイルは均一なエンディアンであると指定されていないのですか？

2. 「ファイルの長さ」フィールドは、他の長さおよび位置フィールドと同様に、より標準的な（私の限られた観点から）8ビットのポジショニングではなく、16ビットのワードで記録されます。この決定はどのようにして達成されましたか？

Stack Overflowで同様の質問を投稿しましたが、応答がありませんでした。これが他の人にとって話題から外れているように思える場合、私はそれを閉じることをサポートできます。

シェープファイルの開発は、プラットフォームに依存しないように特別に設計されたArcViewの開発と同時に行われました。（実際、それはその没落であることが判明しました。「Neuron Data」と呼ばれるプラットフォームに依存しないGUIで開発されたインターフェイスに依存するため、多くのWindows機能を利用できませんでした。シェイプファイルの仕様は最初から奇妙でしたが、このデザインフレームワーク内でループのような意味を成していました：シェープファイルは多くのプラットフォームを対象としているため、それらの仕様はいずれも優先するべきではなく、したがって同様に不快なはずですすべての説得力のあるプログラマーに。

2番目の質問は、正しくない仮定に基づいているようです。たとえば、「ファイル長」フィールドは、メインヘッダーのバイトオフセット24に表示され、最大2 ^ 31-の長さを表すために必要な（符号付き）4バイト（32ビット）整数です。 1。その前に4バイトの「ファイルコード」と、将来の使用のために予約されている5つの4バイトフィールドがあります。そのようなスペースを確保する場合、もちろん、可能な限りフィールドをできるだけ大きくしたい最大限の柔軟性を維持するために、32ビットでした。また、ファイル内の数値フィールドを単語境界に揃えることも役立ちます。

誰かがこれらの答えなどを知っていますが、彼らは話していません。

文書化されていないsbnファイルとsbxファイルをデコードするために協力してきたチームは、似ているがさらに奇妙な、より多くの奇妙な点を同時に発見しました。

シェープファイル構造のほとんどは論理的で非常に効率的であり、ESRI開発者が考え抜いたことを示唆しています。まるで狂人が投げ込まれた賢い開発者がたくさんいたようです。

他の投稿で示唆されているように、奇妙な点はおそらく、現在私たちにとって異質な機械または言語の要件の結果です。

16ビットの単語はスペースを節約する簡単な方法だといつも思っていました。ファイルを処理するときは、メモリに16ビットワード値を保持する必要があることがわかります。スペースを節約するために値を計算する戦略は、今日でもバイナリ形式で一般的です。しかし、Mikeのネイティブなint提案も同様に可能性があります。

エンディアンの反転は奇妙です。誰も私が見た良い答えを持っていません。

dbf形式は、1960年代に始まったdbase III形式からリッピングされました。それ以来、広く使用されており、foxproやxbaseなどの他の名前で見つけることができます。

シェープファイルフォーマットの欠陥、奇妙な点、制限にもかかわらず、GISの分野内および周辺では頑固に存続しています。それを置き換える他のすべての試みは、単純なベクターストレージには肥大化しすぎているか、独自のものです。ESRIでさえ、シェープファイルは初心者がArcINFO、カバレッジ、およびジオデータベースに移行するおもちゃになると考えていました。インターネットはおそらく、このフォーマットの普及に大きな影響を与えていたでしょう。

pyshpを書くことをたくさん学びました。パーサーを書くことは、フォーマットを学ぶための素晴らしい方法です。

これは私の考えです。

シェープファイル形式は、おそらくFORTRAN / PR1MEの起源に由来する歴史を持つARC / INFOから進化したものです。すべてのARC / INFO形式には、この100バイトのヘッダーと、ファイルコードとファイル長の大きなエンディアン（カバレッジ、TINなど）がありました。

シェープファイルがArcView 1用に作成されたとき、ESRIはMicrosoft Windows市場への参入に焦点を合わせ、シェープファイルフォーマットの残りはPCのリトルエンディアンに重点を置いていました。

エンディアンネス間の絶え間ない切り替えは、おそらく、プラットフォームに侵入することの利点を予想しながら、レガシーの起源をサポートする必要性でした。

エンディアンの分割は、一方がSunワークステーションに、もう一方がPCにあり、開発プロセスの終わり近くまで会わないことが原因であると常に考えていました。

私は本当に何が起こったのか知りたいです。

そこのどこかでdbf / foxproの起源について何か聞いたことがあると思います。
それはちょうど私が持っていた奇妙な夢だったかもしれません。

シェープファイルは約20年前に導入されたことを理解する必要がありますが、当時は一貫性がなく、設計が不十分なファイル形式が無数にあったため、シェープファイルも例外ではありません。私は自分でシェープファイルパーサーを作成しましたが、シェープファイル（.SHP）自体と比較して、DBF形式の解析に多くの問題があったと言わざるを得ません。