¿Cuál es una buena taxonomía o convención de nombres para los archivos y carpetas que contienen datos del SIG?

Question

Mi empresa ha recopilado unos 30 TB de datos del SIG en los últimos 8 años, y siempre me encuentro con las siguientes preguntas:

1. ¿De qué tipo de datos disponemos para una zona geográfica determinada?
2. ¿Cuáles son los detalles de esos datos (por ejemplo, la resolución en metros por píxel)?
3. ¿Dónde están los datos en el disco duro para poder utilizarlos?
4. ¿Hemos procesado ya los datos, o están en una forma inalterada desde la fuente?

Hasta ahora, he intentado abordar estas cuestiones diseñando una taxonomía/jerarquía de carpetas y archivos adecuada. ¿Alguien tiene alguna idea/sugerencia sobre algunas formas comprensibles, quizá incluso estándar, de organizar los datos del SIG mediante archivos y carpetas?

También estoy abierto a aprender más sobre cómo el uso de una base de datos podría beneficiar a mi empresa; somos desarrolladores de software, no expertos en SIG, por lo que sospecho que estamos bastante por detrás de la curva sobre la mejor manera de abordar el problema de almacenar/organizar los datos del SIG para facilitar su uso. He visto la pregunta Mejores prácticas para la gestión de datos geoespaciales pero sólo pude sacar un uso marginal de las respuestas porque no estoy familiarizado con las bases de datos geográficos.

ACTUALIZACIÓN: Esta última semana he pasado bastante tiempo leyendo sobre bases de datos SIG, y he empezado a familiarizarme con PostGIS. A largo plazo, creo que terminaremos por emplear una base de datos más un servidor de metadatos como recomienda JasonBirch en Mejores prácticas para la gestión de datos geoespaciales .

Answer 1

Si estás tratando de editar datos o desarrollar un mapa, tendrás que mantener los datos en los que estás trabajando activamente separados de los datos con los que empezaste. Cuando empiezo un proyecto, creo una carpeta SourceData, con subdirectorios nombrados según el tipo de datos (DEM, Ortofoto, Hidrología, etc.). Todos los datos con los que estoy trabajando serán copiado en una carpeta diferente llamada Working. La carpeta Working contiene datos, MXDs y cualquier otra cosa que modifique o cree en subdirectorios que normalmente se correlacionan con una fase del proyecto (MXDs, RoadEdits, Delivery, etc)

Además de los datos reales del SIG, debería crear una carpeta de Comunicaciones o Especificaciones para guardar cualquier documento de su cliente/cliente interno/profesor. Esto puede servir como metadatos cuando vuelvas al proyecto en una fecha posterior, así como crear una ubicación centralizada donde cualquier otra persona pueda ver lo que se supone que está sucediendo.

Answer 2

Me parece que se necesita un conjunto de metadatos para almacenar esta información, y un sistema de recuperación que utilice los metadatos para poder extraer datos en función de la información.

Creo que querrías una solución que soportara un Servicio de Catálogo OGC, para una máxima interoperabilidad. He visto a colegas utilizar Deegree - aunque, por supuesto, hay otras soluciones que deberías consultar.

Este es un ejemplo de cómo vinculado a Deegree en nuestro software (la demostración en vivo está fuera de servicio por mantenimiento - ¡no lo sabías! - pero debería volver a funcionar la semana que viene)

En cuanto a la nomenclatura de los archivos, si se dispone de un servicio de catálogo y un mecanismo de entrega, el problema de cómo se nombran los archivos y dónde están es menor. Por lo demás, creo que depende de cómo se busquen los datos. ¿Empiezas por acotar la zona geográfica o el tipo de datos? Eso determinará si la jerarquía empieza por dividir los datos en mosaicos, y luego los tipos de datos por mosaico; o por dividirlos en tipos de datos, cada uno de los cuales tiene un conjunto de mosaicos.

Por supuesto, con una base de datos espacial no se tienen los mismos problemas para dividir los datos en mosaicos, por lo que suele ser un método preferente, siempre que la aplicación de uso final admita el uso de ese tipo de datos.

Answer 3

Yo elegiría SpatiaLite que es un base de datos de un solo archivo donde puedes insertar todos tus shapefiles, rasters y tablas. Luego, como base de datos relacional SQL, tienes el poder de las consultas SQL a tu disposición para hacer todas las acciones necesarias (join,select,merge,union,split etc) entre atributos y archivos.

SpatiaLite también es accesible desde lenguajes de programación como Python para un mayor grado de automatización. El cielo es el límite.

Documentación y tutoriales de SpatiaLite

Answer 4

Me resulta útil crear documentos de Word titulados "Nombre del mapa o tema - Comentarios de los metadatos.doc". Documente las principales ediciones y flujos de trabajo en orden cronológico (AAAA-MM-DD) para cada mapa y/o tema del conjunto de datos. Si necesita averiguar el historial de un conjunto de datos: i) Incluya la fecha de modificación/fecha de creación de los archivos relacionados que sean útiles como referencias históricas o posibles archivos fuente. Incluya un breve resumen del contenido de cada archivo (nombres de capas, número de registros) prestando atención a las similitudes o diferencias generales (es decir, qué hay de nuevo en cada versión de un mapa o conjunto de datos). Mantenga el archivo "- Comentarios sobre los metadatos" en la misma carpeta de trabajo que la versión más reciente del mapa o conjunto de datos. Coloque las versiones más antiguas del mapa o los datos en una subcarpeta de archivo. El proceso de tres pasos funciona bien para el desarrollo de software, el desarrollo de bases de datos y la gestión de archivos: 1) Desarrollar (y documentar); 2) Probar (y documentar); 3) Publicar (incluyendo los metadatos). 1) Carpeta de trabajo; 2) Subcarpeta de archivo; 3) Versión publicada.