"Extravagâncias" na especificação técnica Shapefile

Escrevi uma biblioteca de análise de shapefile e encontrei algumas decisões de design na especificação que não entendo imediatamente. Espero que exista um desenvolvedor ESRI velho e enrugado por aqui que possa me dizer por que essas coisas são do jeito que são.

1. O arquivo de registro principal (.shp) é de natureza mista . Especificamente, partes do cabeçalho apresentam grande quantidade de bytes endian, mas os registros são todos pouco endian. Normalmente, trabalho em um nível superior a bytes e bits, mas tudo o que li até agora sobre endianness o considera incomum. Por que o arquivo não especificado é de endianness uniforme?

2. O campo "Comprimento do arquivo", assim como outros campos de comprimento e posição, são gravados em palavras de 16 bits, em vez do posicionamento mais padrão (da minha perspectiva limitada) de 8 bits. Como essa decisão foi tomada?

Publiquei uma pergunta semelhante no Stack Overflow, mas não obtive resposta. Se isso parecer muito fora do assunto para outras pessoas, eu poderia apoiar o fechamento.

O desenvolvimento de shapefiles foi simultâneo ao desenvolvimento do ArcView, que foi projetado especificamente para ser independente de plataforma. (De fato, essa foi a sua queda: contando com uma interface desenvolvida em uma GUI independente de plataforma chamada "Neuron Data", não foi possível tirar proveito de muitos recursos do Windows. Acabou refletindo o pior de todos os sistemas que Embora a especificação do shapefile fosse estranha desde o início, ela fazia um sentido meio estranho nessa estrutura de design: como os shapefiles eram destinados a muitas plataformas, suas especificações não deveriam favorecer nenhuma delas e, portanto, deveriam ser igualmente desagradáveis. para programadores de todas as persuasões.

A segunda pergunta parece basear-se em uma suposição que não é verdadeira. Por exemplo, o campo "Tamanho do arquivo" aparece no deslocamento de byte 24 no cabeçalho principal e é um número inteiro de quatro bytes (assinado) (32 bits), como deve ser para representar um comprimento de até 2 ^ 31- 1 Ele é precedido por um "Código de arquivo" de quatro bytes e mais cinco campos de quatro bytes reservados para uso futuro: quando você estiver reservando esse espaço, é claro que deseja tornar os campos tão grandes quanto possível, o que na época foi de 32 bits, a fim de manter a maior flexibilidade possível. Também ajuda a alinhar campos numéricos em um arquivo nos limites das palavras:

Alguém lá fora sabe essas respostas e muito mais, mas não está falando.

A equipe com a qual estou trabalhando para decodificar os arquivos sbn e sbx não documentados descobriu muitas mais esquisitices que são semelhantes e ainda mais bizarras ao mesmo tempo.

A maioria das estruturas de shapefile é lógica e muito eficiente, o que sugere que os desenvolvedores da ESRI pensaram no assunto. É como se tivessem um monte de desenvolvedores inteligentes com um lunático.

Conforme sugerido por outras postagens, as esquisitices provavelmente são o resultado de requisitos de máquina ou idioma que são estranhos para nós agora.

Eu sempre suspeitei que as palavras de 16 bits eram uma maneira fácil de economizar espaço. Você descobrirá que precisa manter os valores das palavras de 16 bits na memória ao manipular arquivos. A estratégia de calcular valores para economizar espaço é comum em formatos binários até hoje. Mas a sugestão int nativa de Mike também é igualmente provável.

O lançamento de endian é simplesmente estranho. Ninguém tem uma boa resposta que eu já tenha visto.

O formato dbf foi extraído do formato dbase III, originado na década de 1960. Ele tem sido amplamente utilizado desde então e pode ser encontrado sob outros nomes, incluindo foxpro e xbase.

Apesar das falhas, esquisitices e limitações do formato shapefile, ele persiste teimosamente dentro e ao redor do campo de GIS. Todas as outras tentativas de substituí-lo foram inchadas demais para armazenamento vetorial simples ou proprietárias demais. Até a ESRI achou que os shapefiles seriam um brinquedo que levaria os iniciantes ao ArcINFO, coberturas e geodatabases. A Internet provavelmente tinha muito a ver com o formato decolando.

Eu aprendi muito escrevendo pyshp. Escrever um analisador é uma maneira fantástica de aprender um formato.

Esta é a minha opinião.

O formato Shapefile provavelmente evoluiu do ARC / INFO, que tinha um histórico que remonta às origens do FORTRAN / PR1ME. Todos os formatos ARC / INFO tinham esse cabeçalho de 100 bytes e a grande endianidade do código e do comprimento do arquivo (por exemplo, coberturas, TINs).

Quando os Shapefiles foram criados para o ArcView 1, a ESRI estava focada em invadir o mercado do Microsoft Windows e o restante do formato Shapefile está fortemente focado em ser pouco endian dos PCs.

A alternância constante entre endianess era, presumivelmente, a necessidade de apoiar as origens herdadas, antecipando os benefícios ao invadir a plataforma.

Sempre presumi que a divisão endian era causada por ter duas equipes, uma nas estações de trabalho Sun e a outra nos PCs, e elas não se reuniam até perto do final do processo de desenvolvimento.

Eu adoraria saber o que realmente aconteceu.

Acho que em algum lugar lá atrás, ouvi algo sobre a origem do dbf / foxpro.
Isso poderia ter sido apenas um sonho estranho que eu tive.

Você precisa entender que os shapefiles foram introduzidos há cerca de 20 anos, naquela época havia uma infinidade de formatos de arquivo inconsistentes e mal projetados, portanto, os shapefiles não são exceção. Eu mesmo escrevi um analisador de shapefile e devo dizer que tive muitos problemas ao analisar o formato DBF em comparação com os próprios shapefiles (.SHP).