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.
Respuestas:
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:
fuente
inttenía 16 bits.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.
fuente
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.
fuente
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ó.
fuente
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.
fuente
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).
fuente