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

32

He estado escribiendo una biblioteca de análisis de shapefile, 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 por aquí que pueda decirme por qué estas cosas son como son.

  1. El archivo de registro principal (.shp) es de endianness mixto . Específicamente, las partes del encabezado tienen ordenamiento de bytes big endian, pero los registros son todos endian pequeños. Normalmente trabajo en un nivel más alto que los bytes y los bits, pero todo lo que he leído hasta ahora sobre endianness marca esto como algo inusual. ¿Por qué no se especifica que el archivo sea de carácter 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 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 obtuvo ninguna respuesta. Si este tema parece demasiado extraño para otras personas, podría apoyar el cierre.

    
pregunta canisrufus 18.01.2012 - 16:48

6 respuestas

28

El desarrollo de shapefiles fue simultáneo con el desarrollo de ArcView, que fue diseñado específicamente para ser independiente de la plataforma. (De hecho, eso resultó ser su caída: al confiar en una interfaz desarrollada en una interfaz gráfica de usuario independiente llamada "Neuron Data", no podía aprovechar muchas capacidades de Windows. Terminó reflejando el peor de todos los sistemas que utiliza. fue comercializado para.) Aunque la especificación de shapefile era extraña desde el principio, tenía un poco de sentido en este marco de diseño: debido a que los shapefiles estaban destinados a muchas plataformas, su especificación no debería favorecer a ninguna de ellas y, por lo tanto, debería ser igualmente detestable. A los programadores de todas las tendencias.

La segunda pregunta parece estar basada en un supuesto que no es cierto. Por ejemplo, el campo "Longitud del archivo" aparece en el byte offset 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 cinco campos más de cuatro bytes reservados para uso futuro: cuando reserva dicho espacio, por supuesto, desea que los campos sean lo más grandes posible, lo que en ese momento Tenía 32 bits, para mantener la mayor flexibilidad posible. También es útil alinear los campos numéricos en 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 problemas (sutiles) potenciales con compiladores de nivel superior que podrían rellenar automáticamente sus STRUCTs alinear con palabras o palabras dobles.

    
respondido por el whuber 18.01.2012 - 17:31
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 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 shapefile son lógicas y muy eficientes, lo que sugiere que los desarrolladores de ESRI analizaron las cosas. Es como si tuvieran un montón de desarrolladores inteligentes con un lunático arrojado.

Según lo sugerido por otras publicaciones, las rarezas son probablemente el resultado de requisitos de máquina o idioma que nos son extraños ahora.

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

El cambio de endian es simplemente raro. Nadie tiene una buena respuesta que yo haya visto.

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

A pesar de las fallas, rarezas y limitaciones del formato de shapefile, persiste obstinadamente en y alrededor del campo de GIS. Todos los demás intentos de reemplazarlo han sido demasiado inflados para el almacenamiento vectorial simple o demasiado patentados. Incluso ESRI pensó que los shapefiles serían un juguete que movería a los principiantes hacia ArcINFO, coberturas y geodatabases. Internet probablemente tuvo mucho que ver con el despegue del formato.

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

    
respondido por el GeospatialPython.com 19.01.2012 - 06:05
5

Esta es mi opinión.

Es muy probable que el formato Shapefile haya evolucionado desde ARC / INFO, cuya historia 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 los Shapefiles para ArcView 1, ESRI se enfocó en ingresar al mercado de Microsoft Windows y el resto del formato del Shapefile está muy enfocado en ser un poco endian de las PC.

El cambio constante entre endianess fue, presumiblemente, la necesidad de respaldar los orígenes heredados al tiempo que se anticipan beneficios al entrar en la plataforma.

    
respondido por el Stephen Quan 19.01.2012 - 13:04
4

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

Me encantaría saber qué sucedió realmente.

    
respondido por el Ian Turton 18.01.2012 - 17:02
0

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

    
respondido por el Brad Nesom 18.01.2012 - 17:28
0

Hay que entender que los shapefiles 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 shapefiles no son una excepción. Yo mismo he escrito un analizador de shapefile y tengo que decir que he tenido muchos más problemas con el análisis del formato DBF en comparación con los shapefiles (.SHP).

    
respondido por el Igor Brejc 18.01.2012 - 17:31

Lea otras preguntas en las etiquetas