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

32

He estado escribiendo una biblioteca de análisis de archivos de formas y he encontrado un par de decisiones de diseño en la especificación que no entiendo de inmediato. Espero que haya un viejo desarrollador ESRI viejo por aquí que pueda decirme por qué estas cosas son como son.

El archivo de registro principal (.shp) es de resistencia mixta . Específicamente, partes del encabezado presentan ordenación de bytes big endian, pero todos los registros son little endian. Normalmente trabajo a un nivel más alto que bytes y bits, pero todo lo que he leído hasta ahora sobre endianness marca esto como inusual. ¿Por qué no se especifica que el archivo sea de endianidad uniforme?
El campo "Longitud de archivo", así como otros campos de longitud y posición, se registran en palabras de 16 bits, en lugar del posicionamiento de 8 bits más estándar (desde mi perspectiva limitada). ¿Cómo se llegó a esta decisión?

Publiqué 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.

shapefile

— canisrufus
fuente

44

Joel Lawhead en GeospatialPython.com ha estado trabajando en resolver misterios de shapefile por un tiempo.

— Chad Cooper

¡No exactamente relacionado, pero ordenado! Espero que lo resuelvan.

— canisrufus

28

El desarrollo de shapefiles fue concurrente con el desarrollo de ArcView, que fue diseñado específicamente para ser independiente de la plataforma. (De hecho, resultó ser su caída: al confiar en una interfaz desarrollada en una GUI independiente de la plataforma llamada "Neuron Data", no pudo aprovechar muchas de las capacidades de Windows. Terminó reflejando lo peor de todos los sistemas que utilizaba). fue comercializado para). Aunque la especificación del archivo de forma era extraña desde el principio, tenía un sentido curioso dentro de este marco de diseño: debido a que los archivos de forma estaban destinados a muchas plataformas, su especificación no debería favorecer a ninguno de ellos y, por lo tanto, debería ser igualmente desagradable a programadores de todas las persuasiones.

La segunda pregunta parece estar basada en una suposición que no es cierta. Por ejemplo, el campo "Longitud del archivo" aparece en el desplazamiento de bytes 24 en el encabezado principal y es un entero (firmado) 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 reserva ese espacio, por supuesto, desea que los campos sean lo más grandes posible, lo que en ese momento era de 32 bits, para mantener la mayor flexibilidad posible. También ayuda alinear campos numéricos en un archivo en los límites de palabras:

— whuber
fuente

2

:) Exactamente lo que estaba buscando. Cuando digo que el campo "Longitud del archivo" está "grabado en palabras de 16 bits", lo que intento decir es que el valor del entero de 32 bits registra la longitud del archivo en palabras de 16 bits. (De la especificación: "El valor para la longitud del archivo es la longitud total del archivo en palabras de 16 bits"). Parece que puede representar una longitud de byte de 2 * 2 ^ 31-1, que parece ser de aproximadamente 4 GB. Lo mismo es cierto para los valores en el archivo .shx. Parece que debería ser capaz de soportar longitudes de archivo de hasta 2 * 2 ^ 31-1 bytes. ¿Qué me estoy perdiendo?

— canisrufus

Buen punto: me perdí eso. En realidad, el diseño podría haber hecho fácilmente las longitudes y las compensaciones del archivo (punteros en el archivo .shx) en términos de palabras de cuatro bytes, lo que aumenta el tamaño posible del archivo .shp a 4 * (2 ^ 31-1) (alrededor de 8 mil millones de bytes). No tengo idea de por qué eligieron las palabras de dos bytes, ni siquiera por qué consistente en el uso de firmar enteros donde enteros sin signo son a la vez más adecuada y proporcionan el doble de almacenamiento.

— whuber

1

Me pregunto si la rareza de 16 bits tiene que ver con las computadoras de 16 bits utilizadas en ese momento, donde un nativo inttenía 16 bits.

— Mike T

Siempre es una posibilidad, @Mike. Sin embargo, incluso las PC 80286 (c. 1984) admitían de forma nativa entradas de 32 bits: usaban pares de registros para hacer aritmética con ellas.

— whuber

55

Un colega de Esri dice que recuerda que la mezcla de endianidad fue deliberada. Algo parecido a 'haremos que los desarrolladores lo manejen directamente debido a problemas multiplataforma'. Pero, por supuesto, todo esto es apócrifo.

— mkennedy

10

Alguien por ahí sabe estas respuestas y más, pero no están hablando.

El equipo con el que he estado trabajando para decodificar los archivos sbn y sbx indocumentados 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 shapefile son lógicas y muy eficientes, lo que sugiere que los desarrolladores de ESRI pensaron detenidamente. Es como si tuvieran un grupo de desarrolladores inteligentes con un lunático.

Como sugieren otras publicaciones, las rarezas son probablemente el resultado de requisitos de máquina o lenguaje que ahora nos son extraños.

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

El giro endian es simplemente extraño. Nadie tiene una buena respuesta que he visto.

El formato dbf se extrajo del formato dbase III originado en la década de 1960. Se ha usado ampliamente desde entonces y se puede encontrar con otros nombres, incluidos foxpro y xbase.

A pesar de las fallas, rarezas y limitaciones del formato de archivo de forma, persiste obstinadamente en el campo de los SIG y sus alrededores. Cualquier otro intento de reemplazarlo ha sido demasiado hinchado para un simple almacenamiento de vectores o demasiado propietario. Incluso ESRI pensó que los shapefiles serían un juguete que movería a los principiantes hacia ArcINFO, las coberturas y las geodatabases. Probablemente Internet tuvo mucho que ver con el despegue del formato.

Aprendí mucho escribiendo pyshp. Escribir un analizador es una forma fantástica de aprender un formato.

— GeospatialPython.com
fuente

Hmm Buena respuesta. No entiendo cómo el uso de palabras de 16 bits ahorra espacio. Para mis propósitos (construir ArrayBufferViews en javascript), todo lo que hace es obligarme a multiplicar por dos para obtener el desplazamiento correcto: estoy quemando ciclos adicionales sin ningún beneficio. ¿Lo elaborarías?

— canisrufus

1

Sí, dado que usaron entradas firmadas, su extremo superior en esos valores sería 32,767, por lo que pueden almacenar números más grandes en 2 bytes en lugar de 4. Los valores asignados a palabras de 16 bits, como dije, son valores que terminas manteniendo RAM cuando se trabaja con archivos de forma para operaciones de lectura y escritura. Crear un esquema para ahorrar espacio en dobles (que he visto en otros formatos binarios) siempre es feo y complicado. Así que simplemente se quedaron con un esquema simple para valores de tamaño de datos.

— GeospatialPython.com

Además, descubrí en los archivos shx que me sorprendió al principio. Los archivos SHX tienen cuadros delimitadores para las características asignadas a una cuadrícula entera de 256x256. Esta técnica es común en la indexación, pero no en una cuadrícula tan pequeña. Guardan las coordenadas como caracteres de 1 byte en lugar de ints. Es por eso que la cuadrícula es solo 256x256. ¡Ahora eso es francamente tacaño con la memoria incluso para la década de 1990! Por supuesto, hay muchas otras eficiencias, como la agrupación implícita de piezas que utilizan un índice. Tienes razón: estas técnicas suponen una mayor carga para el programador. Por lo tanto, el uso de la memoria debe haber sido una prioridad.

— GeospatialPython.com

1

Yah, leí tu escrito. Estás haciendo el buen trabajo del señor en eso;) estoy esperando ansiosamente tu análisis final. Con respecto al problema de 16 bits, no estoy seguro de que su punto se mantenga. 1. En los archivos SHP y SHX, no hay campos de 16 bits, a menos que esté muy equivocado. 2. La representación de valores de 16 bits en lugar de valores de 8 bits solo duplica la longitud que se puede describir (2 * 2 ^ 15), que podrían haber logrado simplemente utilizando un int sin signo (2 ^ 16). En última instancia, no está ahorrando espacio.

— canisrufus

Cuando se refiere al "uso de memoria", es difícil saber si se refiere a RAM o disco. A principios de los 90, una unidad de 2 GB y 16-32 MB de RAM eran de gama alta: aún sería importante ahorrar algo de espacio en los archivos (o el ancho de banda de la red). Un ingeniero de software responsable querría pensar cuidadosamente sobre las implicaciones para sus futuros clientes de las compensaciones espacio-temporales en sus elecciones; en retrospectiva, les daría el beneficio de la duda a menos que la elección fuera obviamente, devastadoramente ineficiente.

— whuber

5

Esta es mi opinión sobre ella.

El formato de archivo de forma probablemente evolucionó de ARC / INFO, que tenía una historia que se remonta a sus orígenes FORTRAN / PR1ME. Todos los formatos ARC / INFO tenían este encabezado de 100 bytes y la gran endianess del Código de archivo y la Longitud del archivo (por ejemplo, Coberturas, TIN).

Cuando se crearon Shapefiles para ArcView 1, ESRI se centró en entrar en el mercado de Microsoft Windows y el resto del formato Shapefile se centró principalmente en ser poco endian de las PC.

El cambio constante entre endianess fue, presumiblemente, la necesidad de apoyar los orígenes heredados mientras se anticipaban beneficios al ingresar a la plataforma.

— Stephen Quan
fuente

Esto suena plausible. ¡Gracias por la visión de usted!

— whuber

Esta es mi conjetura favorita sobre el endianness. ¡Ahora todo lo que necesitamos es Dangermond para publicar "The ESRI Tell All, Technical Edition" para ver si tiene razón!

— canisrufus

2

Si el formato del archivo de forma evolucionó de los formatos ARC / INFO, fue considerablemente anterior a v7. En 1994, cuando comencé en ESRI, AV2 ya estaba fuera, y el trabajo de desarrollo para ARC / INFO 7 estaba en marcha.

— mkennedy el

Buen punto, Melita. El quid de esta respuesta, que algunas opciones de formato podrían tener orígenes en Fortran, seguiría siendo cierto desde las aplicaciones originales de Arc e Info.

— whuber

Gracias @mkennedy, eliminé la referencia a v7. Todavía recuerdo los días en que los manuales de usuario originales de ARC / INFO (era v3 .. v6) tenían encabezados que creo que fueron tomados del código FORTRAN.

— Stephen Quan el

4

Siempre supuse que la división endian fue causada por tener dos equipos, uno en las estaciones de trabajo Sun y el otro en las PC, y no se reunieron hasta cerca del final del proceso de desarrollo.

Me encantaría saber lo que realmente sucedió.

— Ian Turton
fuente

3

Creo que ESRI fue un poco más coordinado que eso. De hecho, en todo caso, su software tiende a parecer que ha habido demasiada participación del comité en su diseño.

— whuber

0

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

— Brad Nesom
fuente

55

Las partes .shp y .shx, que están en cuestión aquí, se diseñaron de manera completamente independiente del formato .dbf, que había existido durante casi 20 años antes.

— whuber

0

Debe comprender que los archivos de forma se introdujeron hace unos 20 años, en ese momento había una gran cantidad de formatos de archivo inconsistentes y mal diseñados, por lo que los archivos de forma no son la excepción. Yo mismo escribí un analizador de archivos de forma y tengo que decir que he tenido muchos más problemas al analizar el formato DBF en comparación con los propios archivos de forma (.SHP).

— Igor Brejc
fuente