"Stranezze" nelle specifiche tecniche di Shapefile

Ho scritto una libreria di analisi dello shapefile e ho riscontrato un paio di decisioni di progettazione nelle specifiche che non capisco immediatamente. Spero che ci sia un vecchio sviluppatore ESRI avvizzito qui che può dirmi perché queste cose sono come sono.

1. Il file di record principale (.shp) è di endianness misto . In particolare, parti dell'intestazione presentano un ordinamento di byte big endian, ma i record sono tutti little endian. In genere lavoro a un livello superiore rispetto a byte e bit, ma tutto ciò che ho letto finora sull'endianness lo segna come insolito. Perché il file non è specificato come endianness uniforme?

2. Il campo "Lunghezza file", così come altri campi di lunghezza e posizione, sono registrati in parole a 16 bit, anziché nel posizionamento più standard (dalla mia prospettiva limitata) a 8 bit. Come è stata raggiunta questa decisione?

Ho pubblicato una domanda simile su Stack Overflow, ma non ho ricevuto alcuna risposta. Se questo sembra troppo fuori tema per altre persone, potrei sostenere di chiuderlo.

Lo sviluppo di shapefile è stato contestuale allo sviluppo di ArcView, che è stato specificamente progettato per essere indipendente dalla piattaforma. (In effetti, ciò si è rivelato essere la sua rovina: basandosi su un'interfaccia sviluppata in una GUI indipendente dalla piattaforma chiamata "Neuron Data", non ha potuto sfruttare molte funzionalità di Windows. Ha finito per riflettere il peggio di tutti i sistemi che è stato commercializzato per.) Anche se le specifiche del file di forma erano strane sin dall'inizio, aveva un certo senso all'interno di questo framework di progettazione: poiché i file di forma erano destinati a molte piattaforme, le loro specifiche non dovrebbero favorire nessuna di esse e quindi dovrebbero essere ugualmente odiose ai programmatori di tutte le persuasioni.

La seconda domanda sembra basarsi su un presupposto che non è vero. Ad esempio, il campo "Lunghezza file" appare all'offset di byte 24 nell'intestazione principale ed è un numero intero (firmato) a quattro byte (32 bit), come deve essere per rappresentare una lunghezza fino a 2 ^ 31- 1. È preceduto da un "Codice file" a quattro byte e da altri cinque campi a quattro byte riservati per un utilizzo futuro: quando si riserva tale spazio, ovviamente si desidera rendere i campi più grandi ragionevolmente possibili, che all'epoca era di 32 bit, al fine di mantenere la massima flessibilità possibile. Aiuta anche ad allineare i campi numerici in un file sui confini delle parole:

Qualcuno là fuori conosce queste risposte e altro, ma non sta parlando.

Il team con cui ho lavorato per decodificare i file sbn e sbx non documentati ha scoperto molte più stranezze che sono entrambe simili ma anche più bizzarre allo stesso tempo.

La maggior parte delle strutture dello shapefile sono logiche e molto efficienti, il che suggerisce agli sviluppatori ESRI di aver riflettuto. È come se avessero avuto un sacco di sviluppatori intelligenti con un folle gettato dentro.

Come suggerito da altri post, le stranezze sono probabilmente il risultato di requisiti di linguaggio o macchina che ci sono estranei adesso.

Ho sempre sospettato che le parole a 16 bit fossero un modo semplice per risparmiare spazio. Scoprirai che devi tenere in memoria i valori delle parole a 16 bit durante la gestione dei file. La strategia di calcolo dei valori per risparmiare spazio è comune nei formati binari anche oggi. Ma anche il suggerimento int nativo di Mike è altrettanto probabile.

Il lancio di endian è semplicemente strano. Nessuno ha una buona risposta che io abbia visto.

Il formato dbf è stato strappato dal formato dbase III originato negli anni '60. Da allora è stato ampiamente utilizzato e può essere trovato sotto altri nomi tra cui foxpro e xbase.

Nonostante i difetti, le stranezze e le limitazioni del formato shapefile, persiste ostinatamente dentro e intorno al campo del GIS. Ogni altro tentativo di sostituirlo è stato troppo gonfio per una semplice memorizzazione vettoriale o troppo proprietario. Persino l'ESRI pensava che gli shapefile sarebbero stati un giocattolo che avrebbe spostato i principianti verso ArcINFO, coperture e geodatabase. Internet probabilmente ha molto a che fare con il decollo del formato.

Ho imparato molto scrivendo pyshp. Scrivere un parser è un modo fantastico per imparare un formato.

Questa è la mia opinione su di esso.

Il formato Shapefile si è probabilmente evoluto da ARC / INFO che aveva una storia che risale alle sue origini FORTRAN / PR1ME. Tutti i formati ARC / INFO avevano questa intestazione da 100 byte e la grande endianess del codice file e della lunghezza del file (ad esempio Coverages, TINs).

Quando gli Shapefile sono stati realizzati per ArcView 1, ESRI si è concentrato sull'irruzione nel mercato Microsoft Windows e il resto del formato Shapefile è fortemente focalizzato sull'essere un piccolo endian dei PC.

Il costante passaggio tra endianess era, presumibilmente, la necessità di supportare le origini legacy, anticipando i benefici sull'irruzione nella piattaforma.

Ho sempre pensato che la divisione degli endian fosse causata dal fatto che due team erano uno su Sun Workstation e l'altro su PC e che non si incontravano fino alla fine del processo di sviluppo.

Mi piacerebbe sapere cosa è successo davvero.

Penso che da qualche parte laggiù abbia sentito qualcosa sull'origine di dbf / foxpro.
Sarebbe potuto essere solo uno strano sogno che avevo fatto.

Devi capire che gli shapefile sono stati introdotti circa 20 anni fa, a quel tempo c'erano una miriade di formati di file incoerenti e mal progettati, quindi gli shapefile non fanno eccezione. Ho scritto io stesso un parser di file di forma e devo dire che ho avuto molti più problemi con l'analisi del formato DBF rispetto agli stessi file di forma (.SHP).