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

32

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

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

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

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

canisrufus
источник
4
Джоэл Лоухед (Geel Lawhead) из GeospatialPython.com некоторое время работал над разгадкой тайн шейп-файлов.
Чед Купер
Не совсем похоже, но аккуратно! Я надеюсь, что понять это.
canisrufus

Ответы:

28

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

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

Whuber
источник
2
:) Именно то, что я искал. Когда я говорю, что поле «Длина файла» «записано в 16-разрядных словах», я пытаюсь сказать, что значение 32-разрядного целого числа записывает длину файла в 16-разрядных словах. (Из спецификации: «Значение длины файла - это общая длина файла в 16-битных словах»). Похоже, что он может представлять длину байта 2 * 2 ^ 31-1, который выглядит примерно 4 ГБ. То же самое верно для значений в файле .shx. Похоже, что он должен поддерживать длину файла до 2 * 2 ^ 31-1 байт. Чего мне не хватает?
canisrufus
Хороший вопрос - я пропустил это. На самом деле, дизайн мог бы так же легко сделать длины и смещения файлов (указатели в файле .shx) в терминах четырехбайтовых слов, увеличив таким образом возможный размер файла .shp до 4 * (2 ^ 31-1). (около 8 миллиардов байт). Я понятия не имею , почему они выбрали два байта слова, и даже почему они последовательно использовать подписаны целые , где целые числа без знака одновременно являются более подходящими и обеспечивают в два раза больше памяти.
whuber
1
Интересно, имеет ли 16-разрядная странность отношение к 16-разрядным компьютерам, которые использовались в то время, когда нативный intбыл 16-разрядным?
Майк Т
Это всегда возможно, @Mike. Однако даже 80286 ПК (ок. 1984 г.) изначально поддерживали 32-битные числа - они использовали пары регистров для выполнения арифметики с ними.
whuber
5
Коллега Esri говорит, что он помнит, что сочетание порядка байтов было преднамеренным. Что-то вроде «мы заставим разработчиков справиться с этим напрямую из-за кросс-платформенных проблем». Но, конечно, это все апокриф.
mkennedy
10

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

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

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

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

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

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

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

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

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

GeospatialPython.com
источник
Хм. Хороший ответ. Я не понимаю, как использование 16-битных слов экономит место. Для моих целей (создание ArrayBufferViews в javascript) все, что он делает, это заставляет меня умножаться на два, чтобы получить правильное смещение: я записываю дополнительные циклы без какой-либо выгоды. Не могли бы вы уточнить?
canisrufus
1
Да - поскольку они использовали подписанные целые числа, они имеют верхний предел этих значений, равный 32 767, поэтому они могут хранить большие числа в 2 байтах вместо 4. Значения, назначенные 16-разрядным словам, как я уже сказал, являются значениями, которые вы в конечном итоге удерживаете в ОЗУ при работе с шейп-файлами для операций чтения и записи. Придумать схему для экономии места на двойниках (что я видел в других двоичных форматах) всегда ужасно и сложно. Поэтому они просто придерживаются простой схемы значений размера данных.
GeospatialPython.com
Кроме того - я обнаружил в файлах shx, которые сначала озадачили меня. Файлы SHX имеют ограничивающие рамки для объектов, сопоставленных с целочисленной сеткой 256x256. Этот метод распространен в индексировании, но не в такой маленькой сетке. Они сохраняют координаты в виде 1-байтовых символов вместо целых. Вот почему сетка только 256x256. Теперь это скупо на память даже на 1990-е годы! Конечно, есть много других преимуществ, таких как подразумеваемая группировка деталей с использованием индекса. Вы правы - эти приемы налагают больше бремени на программиста. Таким образом, использование памяти должно быть приоритетом.
GeospatialPython.com
1
Да, я читаю твои записи. Вы делаете хорошую работу лорда на этом;) Я с нетерпением жду вашего окончательного анализа. Что касается 16-битной проблемы, я не уверен, что ваша точка зрения верна. 1. В файлах SHP и SHX нет 16-битных полей, если я не сильно ошибаюсь. 2. Представление 16-битных значений вместо 8-битных значений только удваивает описываемую длину (2 * 2 ^ 15), чего они могли бы достичь, просто используя unsigned int (2 ^ 16). В конечном итоге это не экономит место.
canisrufus
Когда вы ссылаетесь на «использование памяти», трудно сказать, имеете ли вы в виду RAM или диск. В начале 90-х годов накопитель объемом 2 ГБ и 16-32 МБ оперативной памяти были довольно дорогими: сохранение некоторого файлового пространства (или пропускной способности сети) все равно будет иметь большое значение. Ответственный разработчик программного обеспечения хотел бы тщательно продумать последствия для их будущих клиентов компромиссов в выборе времени и пространства; Оглядываясь назад, я бы дал им преимущество сомнения, если бы выбор не был явно, катастрофически неэффективным.
whuber
5

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

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

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

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

Стивен Куан
источник
Это звучит правдоподобно. Спасибо за понимание!
whuber
Это моя любимая гипотеза о порядке байтов. Теперь все, что нам нужно, это Dangermond, чтобы опубликовать "ESRI Tell All, Technical Edition", чтобы проверить, правы ли вы!
canisrufus
2
Если формат шейп-файла развивался из форматов ARC / INFO, это было значительно раньше, чем v7. В 1994 году, когда я начал работать в ESRI, AV2 уже вышел, и велась разработка ARC / INFO 7.
mkennedy
Хорошая мысль, Мелита. Суть этого ответа - что некоторые варианты форматов могут в конечном итоге иметь происхождение от Фортрана - все равно будет верна вплоть до первоначальных приложений Arc и Info.
whuber
Спасибо @mkennedy, я удалил ссылку на v7. Я до сих пор помню дни, когда у оригинальных руководств пользователя ARC / INFO (эпоха v3 .. v6) были заголовки, которые, как я считаю, были взяты из кода FORTRAN.
Стивен Куан
4

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

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

Ян Тертон
источник
3
Я думаю, что ESRI был немного более скоординированным. Действительно, если что-нибудь, их программное обеспечение имеет тенденцию выглядеть так, как будто в его разработке слишком много вовлечено комитетом.
whuber
0

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

Брэд Несом
источник
5
Части .shp и .shx, которые здесь обсуждаются, были разработаны полностью независимо от формата .dbf, который существовал почти 20 лет назад.
whuber
0

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

Игорь Брейц
источник