"Rarezas" en la especificación técnica de Shapefile

Question

He estado escribiendo una biblioteca de análisis de archivos shape, y he encontrado un par de decisiones de diseño en el pliego de condiciones que no entiendo inmediatamente. Espero que haya algún viejo desarrollador de ESRI por aquí que pueda decirme por qué estas cosas son como son.

1. El archivo de registro principal (.shp) es de la mezcla de idiomas . Específicamente, partes de la cabecera presentan un ordenamiento de bytes big endian, pero los registros son todos little endian. Normalmente trabajo a un nivel superior al de los bytes y los bits, pero todo lo que he leído hasta ahora sobre la endianidad marca esto como inusual. ¿Por qué no se especifica que el archivo tenga un endianamiento uniforme?

2. El campo "Longitud del archivo", así como otros campos de longitud y posición, se registran en palabras de 16 bits, en lugar del posicionamiento más estándar (desde mi limitada perspectiva) de 8 bits. ¿Cómo se llegó a esta decisión?

He publicado una pregunta similar en Stack Overflow, pero no obtuve ninguna respuesta. Si esto parece demasiado fuera de tema para otras personas, podría apoyar cerrarlo.

Answer 1

El desarrollo de los shapefiles coincidió con el desarrollo de ArcView, que fue diseñado específicamente para ser independiente de la plataforma. (De hecho, eso resultó ser su perdición: al depender de una interfaz desarrollada en una GUI independiente de la plataforma llamada "Neuron Data", no podía aprovechar muchas de las capacidades de Windows. Acabó reflejando lo peor de todos los sistemas para los que se comercializó). Aunque la especificación de los shapefiles era extraña desde el principio, tenía una especie de sentido en este marco de diseño: dado que los shapefiles estaban destinados a muchas plataformas, su especificación no debía favorecer a ninguna de ellas y, por tanto, debía ser igualmente odiosa para los programadores de todas las tendencias.

La segunda pregunta parece basarse en una suposición que no es cierta. Por ejemplo, el campo "File Length" aparece en el byte 24 de la cabecera principal y es un entero (con signo) de cuatro bytes (32 bits), como debe ser para representar una longitud de hasta 2^31-1. Está precedido por un "Código de archivo" de cuatro bytes y otros cinco campos de cuatro bytes reservados para uso futuro: cuando se reserva este espacio, por supuesto se desea que los campos sean tan grandes como sea razonablemente posible, que en ese momento era de 32 bits, para mantener la mayor flexibilidad posible. También ayuda alinear los campos numéricos de un archivo en los límites de las palabras: el código a nivel de máquina para analizarlos es un poco más fácil de escribir y puede evitar posibles problemas (sutiles) con los compiladores de nivel superior que podrían rellenar automáticamente sus STRUCTs para alinearlos con las palabras o las dobles palabras.

Answer 2

Alguien por ahí sabe estas respuestas y más, pero no habla.

El equipo con el que he estado trabajando para decodificar los archivos sbn y sbx no documentados ha descubierto muchas más rarezas que son similares pero aún más extrañas al mismo tiempo.

La mayoría de las estructuras de los archivos shape son lógicas y muy eficientes, lo que sugiere que los desarrolladores de ESRI han pensado bien las cosas. Es como si tuvieran un grupo de desarrolladores inteligentes con un lunático añadido.

Como se ha sugerido en otros posts, las rarezas son probablemente el resultado de los requisitos de la máquina o del lenguaje que nos son ajenos ahora.

Siempre sospeché que las palabras de 16 bits eran una forma fácil de ahorrar espacio. Pero al manipular los archivos hay que mantener los valores de las palabras de 16 bits en la memoria. La estrategia de calcular los valores para ahorrar espacio es común en los formatos binarios incluso hoy en día. Pero la sugerencia de Mike sobre los int nativos también es igual de probable.

La inversión endiana es simplemente extraña. Nadie tiene una buena respuesta que yo haya visto.

El formato dbf fue arrancado del formato dbase III originado en los años 60. Se ha utilizado ampliamente desde entonces y puede encontrarse bajo otros nombres, como foxpro y xbase.

A pesar de sus defectos, rarezas y limitaciones, el formato shapefile persiste obstinadamente en el campo de los SIG. Todos los demás intentos de sustituirlo han sido demasiado abultados para el simple almacenamiento de vectores o demasiado propietarios. Incluso ESRI pensó que los shapefiles serían un juguete que movería a los principiantes hacia ArcINFO, coberturas y geodatabases. Probablemente, Internet tuvo mucho que ver con el despegue del formato.

He aprendido mucho escribiendo pyshp. Escribir un parser es una forma fantástica de aprender un formato.

Answer 3

Esta es mi opinión al respecto.

El formato Shapefile probablemente evolucionó a partir de ARC/INFO, cuya historia se remonta a sus orígenes en FORTRAN / PR1ME. Todos los formatos ARC/INFO tenían esta cabecera de 100 bytes y el Big endianess del Código de Archivo y la Longitud de Archivo (por ejemplo, Coberturas, TINs).

Cuando se hicieron los Shapefiles para ArcView 1, ESRI se centró en entrar en el mercado de Microsoft Windows y el resto del formato Shapefile está muy enfocado a ser little endian de PC.

El cambio constante entre endianismos se debió, presumiblemente, a la necesidad de dar soporte a los orígenes heredados, al tiempo que se preveían beneficios al irrumpir en la plataforma.

Answer 4

Siempre supuse que la división endiana se debía a que había dos equipos, uno en estaciones de trabajo Sun y otro en PC, y que no se reunían hasta casi el final del proceso de desarrollo.

Me gustaría saber qué pasó realmente.

Answer 5

Creo que en algún momento escuché algo sobre el origen de dbf/foxpro.
Sin embargo, podría haber sido sólo un sueño extraño que tuve.