„Dziwactwa” w specyfikacji technicznej Shapefile

32

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.

canisrufus
źródło
4
Joel Lawhead z GeospatialPython.com od dłuższego czasu pracuje nad rozwiązywaniem tajemnic plików kształtu .
Chad Cooper
Nie do końca spokrewnione, ale schludne! Mam nadzieję, że to rozgryziesz.
canisrufus

Odpowiedzi:

28

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:

Whuber
źródło
2
:) Dokładnie to, czego szukałem. Kiedy mówię, że pole „Długość pliku” jest „zapisywane 16-bitowymi słowami”, próbuję powiedzieć, że wartość 32-bitowej liczby całkowitej zapisuje długość pliku w 16-bitowych słowach. (Ze specyfikacji: „Wartość długości pliku to całkowita długość pliku w 16-bitowych słowach”). Wygląda na to, że może reprezentować bajt o długości 2 * 2 ^ 31-1, który wygląda na około 4 GB. To samo dotyczy wartości w pliku .shx. Wygląda na to, że powinien obsługiwać pliki o długości do 2 * 2 ^ 31-1 bajtów. czego mi brakuje?
canisrufus
Dobra uwaga - tęskniłem za tym. W rzeczywistości projekt mógł równie łatwo tworzyć długości i przesunięcia plików (wskaźniki w pliku .shx) w kategoriach czterobajtowych słów, zwiększając w ten sposób możliwy rozmiar pliku .shp do 4 * (2 ^ 31-1) (około 8 miliardów bajtów). Nie mam pojęcia, dlaczego wybrali dwóch bajtów słowa, ani nawet dlatego konsekwentnie używać podpisane liczb całkowitych, gdzie liczby całkowite bez znaku są zarówno bardziej odpowiednie i przewidują dwa razy tyle pamięci.
whuber
1
Zastanawiam się, czy 16-bitowa dziwność ma związek z 16-bitowymi komputerami używanymi w tym czasie, gdzie natywny intmiał 16 bitów.
Mike T
Zawsze jest taka możliwość, @Mike. Jednak nawet komputery 80286 (ok. 1984) natywnie wspierały 32-bitowe inty - używały par rejestrów, aby wykonywać z nimi arytmetykę.
whuber
5
Kolega z Esri mówi, że pamięta, że ​​połączenie endianizmu było celowe. Coś w stylu „sprawimy, że programiści poradzą sobie z tym całkowicie z powodu problemów międzyplatformowych”. Ale oczywiście wszystko to jest apokryficzne.
mkennedy,
10

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.

GeospatialPython.com
źródło
Hmm Dobra odpowiedź. Nie rozumiem, w jaki sposób użycie 16-bitowych słów oszczędza miejsce. Dla moich celów (budowanie ArrayBufferViews w javascript) wszystko, co zmusza mnie do pomnożenia przez dwa, aby uzyskać prawidłowe przesunięcie: spalam dodatkowe cykle bez żadnej korzyści. Czy rozwinąłbyś to?
canisrufus
1
Tak - ponieważ używali podpisanych liczb wewnętrznych, dla tych wartości górny koniec wyniósłby 32 767, więc mogą przechowywać większe liczby w 2 bajtach zamiast 4. Wartości przypisane do 16-bitowych słów, jak powiedziałem, są wartościami, w których ostatecznie trzymasz RAM podczas pracy z plikami kształtu dla operacji odczytu i zapisu. Wymyślenie schematu oszczędzania miejsca w grze podwójnej (który widziałem w innych formatach binarnych) jest zawsze brzydkie i skomplikowane. Więc utknęli z prostym schematem wartości wielkości danych.
GeospatialPython.com
Poza tym - odkryłem w plikach shx, które mnie zaskoczyły. Pliki SHX mają ramki ograniczające dla funkcji odwzorowanych na siatkę liczb całkowitych 256 x 256. Ta technika jest powszechna w indeksowaniu, ale nie na tak małej siatce. Zapisują współrzędne jako znaki 1-bajtowe zamiast liczb całkowitych. Właśnie dlatego siatka ma tylko 256 x 256. Teraz jest to wręcz skąpe w pamięci nawet w latach 90.! Istnieje oczywiście wiele innych wydajności, takich jak dorozumiane grupowanie części za pomocą indeksu. Masz rację - te techniki stanowią większe obciążenie dla programisty. Dlatego użycie pamięci musiało być priorytetem.
GeospatialPython.com
1
Tak, czytam twoje pismo. Wykonujesz dobrą robotę na tym;) Z niecierpliwością czekam na twoją ostateczną analizę. Jeśli chodzi o problem 16-bitowy, nie jestem pewien, czy masz rację. 1. W plikach SHP i SHX nie ma 16-bitowych pól, chyba że się mylę. 2. Reprezentowanie wartości 16-bitowych zamiast wartości 8-bitowych podwaja jedynie opisywalną długość (2 * 2 ^ 15), którą mogliby osiągnąć po prostu przy użyciu int bez znaku (2 ^ 16). To ostatecznie nie oszczędza miejsca.
canisrufus
Kiedy mówisz o „zużyciu pamięci”, trudno powiedzieć, czy masz na myśli pamięć RAM czy dysk. Na początku lat 90-tych dysk 2 GB i 16-32 MB pamięci RAM były dość wysokiej klasy: oszczędność miejsca na pliki (lub przepustowości sieci) nadal miałaby znaczenie. Odpowiedzialny inżynier oprogramowania chciałby dokładnie przemyśleć konsekwencje dla swoich przyszłych klientów dotyczące kompromisów czasoprzestrzennych w swoich wyborach; z perspektywy czasu dałbym im korzyść z wątpliwości, chyba że wybór byłby oczywiście, niszczycielsko nieskuteczny.
whuber
5

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ę.

Stephen Quan
źródło
Brzmi to realistycznie. Dziękuję za wgląd!
whuber
To moja ulubiona hipoteza na temat endianizmu. Teraz wystarczy nam Dangermond, aby opublikować „The ESRI Tell All, Technical Edition”, aby sprawdzić, czy masz rację!
canisrufus
2
Jeśli format pliku kształtu ewoluował z formatów ARC / INFO, był znacznie wcześniejszy niż wersja 7. W 1994 roku, kiedy zacząłem pracę w ESRI, AV2 był już dostępny i trwały prace nad rozwojem ARC / INFO 7.
mkennedy,
Dobra uwaga, Melita. Sedno tej odpowiedzi - że niektóre opcje formatowania mogą ostatecznie mieć pochodzenie w Fortranie - nadal byłoby prawdziwe aż do oryginalnych aplikacji Arc i Info.
whuber
Dzięki @mkennedy, usunąłem odniesienie do wersji 7. Nadal pamiętam dni, w których oryginalne instrukcje obsługi ARC / INFO (era v3 .. v6) miały nagłówki, które, jak sądzę, zostały zaczerpnięte z kodu FORTRAN.
Stephen Quan
4

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.

Ian Turton
źródło
3
Myślę, że ESRI był trochę bardziej skoordynowany. W istocie ich oprogramowanie ma tendencję do wyglądania na zbyt duże zaangażowanie komitetów w jego projektowanie.
whuber
0

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

Brad Nesom
źródło
5
Części .shp i .shx, o których tu mowa, zostały zaprojektowane całkowicie niezależnie od formatu .dbf, który istniał już prawie 20 lat wcześniej.
whuber
0

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).

Igor Brejc
źródło