¿Cuál es una buena taxonomía o convención de nomenclatura para archivos y carpetas que contienen datos SIG? [cerrado]

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

1. ¿Qué tipo de datos tenemos para un área geográfica dada?
2. ¿Cuáles son los detalles sobre esos datos (por ejemplo, resolución en metros por píxel)?
3. ¿Dónde existen los datos en el disco duro para que realmente pueda usarlos?
4. ¿Ya hemos procesado los datos o están en una forma inalterada de la fuente?

Hasta ahora, inclusive, he intentado abordar estas preguntas al diseñar una carpeta y un archivo de taxonomía / jerarquía apropiados. ¿Alguien tiene alguna idea / sugerencia sobre algunas formas comprensibles, tal vez incluso estándar, de organizar los datos SIG utilizando 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 retrasados ​​en cuanto a la mejor manera de abordar el problema de almacenar / organizar datos SIG para facilitar su uso. Sí vi la pregunta Mejores prácticas para gestionar datos geoespaciales, pero solo pude extraer un uso marginal de las respuestas porque no estoy familiarizado con las geodatabases.

ACTUALIZACIÓN: Esta semana pasada pasé bastante tiempo leyendo sobre bases de datos SIG y comencé a familiarizarme con PostGIS. A largo plazo, creo que terminaremos avanzando hacia el empleo de una base de datos más un servidor de metadatos según lo recomendado por JasonBirch en Mejores prácticas para administrar datos geoespaciales .

Si realmente está tratando de editar datos o desarrollar un mapa, deberá mantener los datos en los que está trabajando de forma separada de los datos con los que comenzó. Cuando comienzo un proyecto, creo una carpeta SourceData, con subdirectorios nombrados por el tipo de datos (DEM, Ortofoto, Hidrología, etc.) Esto contendrá todas las capas que simplemente estoy usando como referencia. Todos los datos en los que estoy trabajando se copiarán en una carpeta diferente llamada Trabajo. La carpeta de trabajo contiene datos, MXD y cualquier otra cosa que modifique o cree en subdirectorios que generalmente se correlacionan con una fase del proyecto (MXD, RoadEdits, Delivery, etc.)

Además de los datos SIG reales, debe crear una carpeta de Comunicaciones o Especificaciones para guardar cualquier documento de su cliente / cliente interno / profesor. Esto puede servir como metadatos cuando regrese 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.

Me parece que necesita un conjunto de metadatos para almacenar esta información y un sistema de recuperación que utiliza los metadatos para permitirle extraer datos sobre la base de la información.

Creo que querría una solución que admitiera un servicio de catálogo OGC, para una interoperabilidad máxima. He visto a colegas usar Deegree , aunque, por supuesto, hay otras soluciones que debe consultar.

Aquí hay un ejemplo de cómo vinculamos a Deegree con nuestro software (la demostración en vivo está inactiva por mantenimiento en este momento, ¡no lo sabrías! Pero debería volver a funcionar la próxima semana)

En cuanto a la denominación de archivos, si tiene un servicio de catálogo y un mecanismo de entrega, entonces hay menos problemas sobre cómo se nombran los archivos y dónde están. De lo contrario, creo que depende de cómo busque los datos. ¿Comienza por reducir el área geográfica o el tipo de datos? Eso determinará si la jerarquía comienza dividiendo los datos en mosaicos, luego los tipos de datos por mosaico; o dividiéndolo en tipos de datos, cada uno de los cuales tiene un conjunto de mosaicos.

Por supuesto, con una base de datos espacial no tiene los mismos problemas para dividir los datos en mosaicos, por lo que a menudo es un método preferencial, siempre que la aplicación de uso final admita el uso de ese tipo de datos.

Elegiría SpatiaLite, que es una base de datos de un archivo donde puede insertar todos sus shapefiles, rásteres y tablas. Luego, como una base de datos SQL relacional, tiene el poder de las consultas SQL a su disposición para realizar todas las acciones necesarias (unir, seleccionar, fusionar, unir, dividir, etc.) entre atributos y archivos.

También se puede acceder a SpatiaLite desde lenguajes de programación como Python para un mayor grado de automatización. El cielo es el limite.

Documentación y tutoriales de SpatiaLite

Me resulta útil crear documentos de Word titulados "Nombre o tema del mapa - Metadata comments.doc". Documente las principales ediciones y flujos de trabajo en orden cronológico (AAAA-MM-DD) para cada tema de mapa y / o 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 son útiles como referencias históricas o posibles archivos fuente. Incluya un breve resumen del contenido de cada archivo (nombres de capa, número de registros) mientras presta 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 de metadatos" en la misma carpeta de trabajo que la versión más reciente del mapa o conjunto de datos. Coloque versiones anteriores del mapa o datos en una subcarpeta de archivo. El proceso de tres pasos funciona bien para el desarrollo de software, desarrollo de bases de datos y gestión de archivos: 1) Desarrollar (y documento); 2) Prueba (y documento); 3) Publicar (incluidos los metadatos). 1) Carpeta de trabajo; 2) Subcarpeta de archivo; 3) Versión publicada.