"Дивацтва" в технічній специфікації Shapefile

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

1. Основний файл запису (.shp) має змішану небезпеку . Зокрема, частини заголовка містять велике впорядкування байтів, але всі записи є мало ендіанськими. Я, як правило, працюю на більш високому рівні, ніж байти та біти, але все, що я до цього часу читав про ендіантність, відзначає це як незвичне. Чому вказаний файл не має однакової небезпеки?

2. Поле "Довжина файлу", а також інші поля довжини та позиції записуються 16-бітними словами, замість більш стандартного (з моєї обмеженої точки зору) 8-бітного позиціонування. Як було прийнято це рішення?

Я розмістив подібне запитання на Stack Overflow, але не отримав жодної відповіді. Якщо це здається занадто поза темою для інших людей, я можу підтримати його закриття.

Розробка форм-файлів паралельно розвивалася ArcView, який був спеціально розроблений для незалежної платформи. (Насправді, це виявилося його падінням: спираючись на інтерфейс, розроблений на платформі незалежному графічному інтерфейсі під назвою "Neuron Data", він не міг скористатися багатьма можливостями Windows. Це в кінцевому підсумку відображало найгірше з усіх його систем ) Хоча специфікація shapefile з самого початку була дивною, вона мала певний сенс у цій проектній структурі: оскільки shapefiles були призначені для багатьох платформ, їх специфікація не повинна надавати перевагу жодній із них, а тому повинна бути однаково небезпечною програмістам усіх переконань.

Здається, друге питання базується на припущенні, яке не відповідає дійсності. Наприклад, поле "Довжина файлу" з'являється при зміщенні байта 24 в головному заголовку і являє собою (підписане) чотирибайтове (32 бітове) ціле число, як воно повинно бути для того, щоб представляти довжину до 2 ^ 31- 1. Йому передує чотирибайтовий «Файловий код» та ще п’ять чотирьохбайтових полів, зарезервованих для подальшого використання: коли ви резервуєте такий простір, звичайно, ви хочете зробити поля максимально можливими, що в той час було 32 біта, щоб зберегти максимально можливу гнучкість. Це також допомагає вирівняти числові поля у файлі за межами слова:

Хтось там знає ці відповіді та інше, але вони не розмовляють.

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

Більшість структур форм-файлів є логічними та дуже ефективними, що дозволяє розробникам ESRI продумати обґрунтовані речі. Це все одно, що у них була купа розумних розробників з одним лунатиком.

Як пропонують інші дописи, дивацтва, ймовірно, є результатом машинних чи мовних вимог, які нам зараз чужі.

Я завжди підозрював, що 16-бітні слова - це простий спосіб заощадити місце. Ви побачите, що вам потрібно зберігати 16-бітні значення слів у пам'яті під час обробки файлів. Стратегія обчислення значень для економії місця поширена у двійкових форматах навіть сьогодні. Але натільна пропозиція Майка також є такою ж ймовірною.

Ендіан-гортання просто дивний. Ніхто не має гарної відповіді, яку я бачив.

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

Незважаючи на недоліки, дивацтва та обмеження формату filefile, він наполегливо зберігається в області та навколо ГІС. Кожна інша спроба його заміни була надто роздута для простого векторного зберігання або надто власна. Навіть ESRI вважав, що форматі файлів будуть іграшкою, яка рухатиме початківців до ArcINFO, покриттів та баз геоданих. Інтернет, мабуть, мав багато спільного з тим, як знімати формат.

Я багато навчився писати pyshp. Написання аналізатора - це фантастичний спосіб засвоїти формат.

Це мій погляд на це.

Формат Shapefile, швидше за все, розвинувся з ARC / INFO, яка мала історію, що починається з його джерел FORTRAN / PR1ME. Усі формати ARC / INFO мали цей 100-байтний заголовок та велику витривалість коду файлу та довжину файлу (наприклад, Покриття, TIN).

Коли Shapefiles були зроблені для ArcView 1, ESRI був зосереджений на прориві на ринок Microsoft Windows, а решта формату Shapefile сильно орієнтована на те, що це мало ендіатистів ПК.

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

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

Я хотів би дізнатися, що насправді сталося.

Я думаю, що десь там я почув щось про походження dbf / foxpro.
Це міг бути просто дивний сон, який я мав, хоча.

Ви повинні розуміти, що файли форм були введені десь 20 років тому, в той час існувало безліч непослідовних і погано розроблених форматів файлів, тому формні файли не є винятком. Я сам написав аналізатор shapefile, і я повинен сказати, що у мене було набагато більше проблем з розбором формату DBF порівняно з самими shapefiles (.SHP).