«Странности» в техническом описании Shapefile

Я писал библиотеку для разбора шейп-файлов и столкнулся с парой проектных решений в спецификации, которые я не сразу понимаю. Я надеюсь, что здесь есть старый опытный разработчик ESRI, который может сказать мне, почему эти вещи такие, какие они есть.

1. Основной файл записи (.shp) имеет смешанный порядок байтов . В частности, части заголовка имеют порядок байтов с прямым порядком байтов, но все записи имеют порядок байтов. Обычно я работаю на более высоком уровне, чем байты и биты, но все, что я до сих пор читал о порядке байтов, помечает это как необычное. Почему указанный файл не имеет порядка байтов?

2. Поле «Длина файла», а также другие поля длины и позиции записываются в 16-разрядных словах вместо более стандартного (с моей ограниченной точки зрения) 8-разрядного позиционирования. Как это решение было достигнуто?

Я опубликовал аналогичный вопрос о переполнении стека, но не получил никакого ответа. Если это кажется другим не по теме, я могу поддержать его закрытие.

Разработка шейп-файлов проводилась одновременно с разработкой ArcView, которая была специально разработана для обеспечения независимости от платформы. (Фактически, это оказалось его недостатком: полагаясь на интерфейс, разработанный в независимом от платформы графическом интерфейсе под названием «Нейронные данные», он не смог воспользоваться многими возможностями Windows. В итоге он отразил наихудшую из всех систем, которые он использовал. был продан.) Хотя спецификация шейп-файла была странной с самого начала, в этой структуре проектирования имелся какой-то зацикленный смысл: поскольку шейп-файлы предназначались для многих платформ, их спецификация не должна благоприятствовать какой-либо из них и поэтому должна быть одинаково неприятной программистам всех убеждений.

Второй вопрос, как представляется, основан на предположении, которое не соответствует действительности. Например, поле «Длина файла» появляется с байтовым смещением 24 в главном заголовке и представляет собой (подписанное) четырехбайтовое (32-битное) целое число, как и должно быть для представления длины до 2 ^ 31- 1. Ему предшествует четырехбайтовый «Код файла» и еще пять четырехбайтовых полей, зарезервированных для будущего использования: когда вы резервируете такое пространство, конечно, вы хотите, чтобы поля были как можно более большими, что в то время было 32 бита, чтобы поддерживать максимально возможную гибкость. Также помогает выровнять числовые поля в файле по границам слов:

Кто-то знает эти ответы и многое другое, но они не разговаривают.

Команда, с которой я работал над декодированием недокументированных файлов sbn и sbx, обнаружила гораздо больше странностей, которые оба похожи, но в то же время еще более причудливы.

Большинство структур шейп-файлов логичны и очень эффективны, что позволяет разработчикам ESRI все продумать. Как будто у них была куча умных разработчиков с одним сумасшедшим.

Как утверждают другие посты, странности, вероятно, являются результатом требований машин или языков, которые сейчас нам чужды.

Я всегда подозревал, что 16-битные слова - это простой способ сэкономить место. Вы обнаружите, что вам нужно хранить 16-битные значения слов в памяти при работе с файлами. Стратегия вычисления значений для экономии места распространена в двоичных форматах даже сегодня. Но родное внушение Майка также вероятно.

Переворот-это просто странно. Ни у кого нет хорошего ответа, который я видел.

Формат dbf был извлечен из формата dbase III, созданного в 1960-х годах. С тех пор он широко используется и может быть найден под другими именами, включая foxpro и xbase.

Несмотря на формате шейп-файла в недостатки, странности и ограничения она сохраняется упорно и вокруг области ГИС. Любая другая попытка заменить его была слишком раздутой для простого векторного хранения или слишком частной. Даже ESRI полагал, что шейп-файлы будут игрушкой, которая поможет новичкам перейти к ArcINFO, покрытиям и базам геоданных. Интернет, вероятно, был во многом связан с тем, что формат начал развиваться.

Я многому научился писать пышп. Написание парсера - это фантастический способ выучить формат.

Это мое мнение.

Формат шейп-файла, скорее всего, произошел от ARC / INFO, история которого берет свое начало от его происхождения на FORTRAN / PR1ME. Все форматы ARC / INFO имели этот 100-байтовый заголовок и Big Endianess кода файла и длины файла (например, Coverages, TINs).

Когда были созданы шейп-файлы для ArcView 1, ESRI была сосредоточена на проникновении на рынок Microsoft Windows, а оставшаяся часть формата шейп-файлов была в значительной степени ориентирована на то, чтобы быть чуть-чуть младше ПК.

Постоянное переключение между порядком байтов было, предположительно, необходимостью поддерживать унаследованное происхождение, в то же время ожидая выгод от взлома платформы.

Я всегда предполагал, что разделение по порядку следования байтов было вызвано наличием двух команд, одна на рабочих станциях Sun, а другая на ПК, и они не встретились до конца процесса разработки.

Я хотел бы знать, что на самом деле произошло.

Я думаю, что где-то там я что-то слышал о происхождении dbf / foxpro.
Это могло быть просто странным сном, который у меня был.

Вы должны понимать, что шейп-файлы были введены около 20 лет назад, в то время существовало множество несовместимых и плохо разработанных форматов файлов, поэтому шейп-файлы не являются исключением. Я сам написал анализатор шейп-файлов и должен сказать, что у меня было гораздо больше проблем с анализом формата DBF по сравнению с самими шейп-файлами (.SHP).