„Dziwactwa” w specyfikacji technicznej Shapefile

Piszę bibliotekę parsowania plików kształtów i napotkałem kilka decyzji projektowych w specyfikacji , których od razu nie rozumiem. Mam nadzieję, że jest tu stary stary programista ESRI, który może mi powiedzieć, dlaczego te rzeczy są takie, jakie są.

1. Główny plik rekordu (.shp) ma mieszaną endianowość . W szczególności części nagłówka zawierają porządek dużych bajtów endian, ale wszystkie rekordy są małe endian. Zazwyczaj pracuję na wyższym poziomie niż bajty i bity, ale wszystko, co do tej pory czytałem na temat endianizmu, oznacza to jako niezwykłe. Dlaczego plik nie jest określony jako jednolity endianness?

2. Pole „Długość pliku”, a także inne pola długości i pozycji, są zapisywane 16-bitowymi słowami, zamiast bardziej standardowego (z mojej ograniczonej perspektywy) 8-bitowego pozycjonowania. Jak podjęto tę decyzję?

Zadałem podobne pytanie na temat przepełnienia stosu, ale nie otrzymałem żadnej odpowiedzi. Jeśli dla innych wydaje się to zbyt nie na temat, mógłbym poprzeć jego zamknięcie.

Rozwój plików kształtowych był zbieżny z rozwojem ArcView, który został specjalnie zaprojektowany, aby był niezależny od platformy. (W rzeczywistości okazało się to jego wadą: polegając na interfejsie opracowanym w niezależnym od platformy interfejsie GUI o nazwie „Neuron Data”, nie mógł on korzystać z wielu możliwości systemu Windows. Ostatecznie odzwierciedlał to najgorszy ze wszystkich systemów, z których korzystał został wprowadzony na rynek.) Chociaż specyfikacja pliku kształtów była od samego początku dziwna, w ramach tej struktury projektowej miała sens z pętlą: ponieważ pliki kształtów były przeznaczone dla wielu platform, ich specyfikacja nie powinna faworyzować żadnej z nich, a zatem powinna być równie nieznośna dla programistów wszystkich przekonań.

Drugie pytanie wydaje się opierać na założeniu, które nie jest prawdziwe. Na przykład pole „Długość pliku” pojawia się z przesunięciem bajtu 24 w nagłówku głównym i jest (podpisaną) liczbą całkowitą czterobajtową (32-bitową), ponieważ musi być, aby reprezentować długość do 2 ^ 31- 1. Poprzedza go czterobajtowy „Kod pliku” i pięć kolejnych czterobajtowych pól zarezerwowanych do wykorzystania w przyszłości: kiedy rezerwujesz takie miejsce, oczywiście chcesz, aby pola były tak duże, jak to możliwe, co w danym momencie miał 32 bity, aby zachować jak największą elastyczność. Pomaga także wyrównać pola numeryczne w pliku na granicach słów:

Ktoś tam zna te odpowiedzi i jeszcze więcej, ale nie rozmawia.

Zespół, z którym pracowałem nad zdekodowaniem nieudokumentowanych plików sbn i sbx, odkrył wiele innych osobliwości, które są podobne, a nawet dziwniejsze w tym samym czasie.

Większość struktur plików kształtu jest logiczna i bardzo wydajna, co sugeruje, że programiści ESRI dobrze się zastanowili. To tak, jakby mieli grupę inteligentnych programistów z jednym szaleńcem.

Jak sugerują inne posty, osobliwości są prawdopodobnie wynikiem wymagań maszynowych lub językowych, które są nam obce.

Zawsze podejrzewałem, że 16-bitowe słowa były łatwym sposobem na zaoszczędzenie miejsca. Przekonasz się, że podczas przechowywania plików musisz przechowywać w pamięci 16-bitowe wartości słów. Strategia obliczania wartości w celu zaoszczędzenia miejsca jest powszechna nawet w formatach binarnych. Ale natywna sugestia Mike'a jest równie prawdopodobna.

Przerzucanie endianów jest po prostu dziwne. Nikt nie ma dobrej odpowiedzi, którą widziałem.

Format dbf został zgrany z formatu dbase III powstałego w latach 60. Od tego czasu jest szeroko stosowany i można go znaleźć pod innymi nazwami, w tym Foxpro i Xbase.

Pomimo wad formatu shapefile, osobliwości i ograniczeń, uparcie utrzymuje się w obszarze GIS i wokół niego. Każda kolejna próba jego zastąpienia była zbyt rozdęta, aby można ją było przechowywać w prosty sposób, lub zbyt zastrzeżona. Nawet ESRI uważało, że pliki kształtów będą zabawką, która poruszy początkującego w kierunku ArcINFO, relacji i geobaz. Internet prawdopodobnie miał wiele wspólnego ze startującym formatem.

Dużo nauczyłem się pyshp. Napisanie parsera to fantastyczny sposób na naukę formatu.

To jest moje zdanie na ten temat.

Format Shapefile najprawdopodobniej wyewoluował z ARC / INFO, którego historia sięga początków FORTRAN / PR1ME. Wszystkie formaty ARC / INFO miały ten 100-bajtowy nagłówek i dużą endianowość kodu pliku i długości pliku (np. Pokrycia, numery TIN).

Kiedy Shapefile zostały stworzone dla ArcView 1, ESRI koncentrowało się na wejściu na rynek Microsoft Windows, a pozostała część formatu Shapefile jest mocno skoncentrowana na byciu małym endianem komputerów.

Ciągłe przełączanie między endianessami było, prawdopodobnie, potrzebą wspierania starszych źródeł, jednocześnie przewidując korzyści z włamania się na platformę.

Zawsze zakładałem, że podział na endian był spowodowany tym, że dwie drużyny jedna działała na Sun Workstations, a druga na komputerach PC, a one nie spotykały się do końca procesu programowania.

Chciałbym wiedzieć, co się naprawdę wydarzyło.

Myślę, że gdzieś tam słyszałem coś o powstaniu dbf / foxpro.
To mógł być tylko dziwny sen, który miałem.

Musisz zrozumieć, że pliki kształtu zostały wprowadzone około 20 lat temu, w tym czasie istniała niezliczona ilość niespójnych i źle zaprojektowanych formatów plików, więc pliki kształtu nie są wyjątkiem. Sam napisałem parser plików shapefile i muszę powiedzieć, że miałem znacznie więcej problemów z analizowaniem formatu DBF w porównaniu do samych plików shapefile (.SHP).