Este es un un problema muy grave . Hemos probado varios sistemas, que han funcionado en mayor o menor medida durante un tiempo, y que finalmente se han vuelto poco manejables y han empezado a desmoronarse a medida que se encontraban más casos límite que no encajaban del todo. Dicho esto, cada uno de los sistemas que hemos utilizado es mucho mejor que nada, lo que demuestra la máxima de que cualquier sistema es mejor que ningún sistema.
He aquí un resumen de nuestra práctica actual:
Ponga todo, excepto los rásteres, en una geodatabase de archivos, cuanto menos, mejor. No anide las clases de características bajo los conjuntos de datos de características a menos que estén relacionados de alguna manera (por ejemplo, agua>arroyos, agua>lagos, agua>humedales, etc.). Esto conduce a una gran lista en la parte superior del fgdb, pero es un mal aceptable.
Crear archivos de capas para todas las clases de características y organizar eso en su lugar, esto da mucha libertad para nombrar como sea necesario, utilizando caracteres no soportados, etc.*, y la capacidad de mover y renombrar como las circunstancias cambian. También permite la duplicación sin redundancia, por ejemplo, un conjunto de capas agrupadas según la escala nominal (50k, 250k...), otro por región (AK, YT...) , un tercero por tema (caribú, uso de la tierra, transporte...), y un cuarto por cliente, mientras que el almacén de datos en sí no cambia.
Para los duplicados, utilice los accesos directos en lugar de los propios archivos de capa, ya que, de lo contrario, hay demasiadas cosas que actualizar cuando las cosas cambian. Configure ArcCatalog para mostrar los accesos directos: *Herramientas > Opciones > tipos de archivo: .lnk (Limitaciones: la vista previa y los metadatos no funcionan, no se puede seguir el acceso directo a su fuente en ArcCatalog. Esto se puede remediar utilizando Enlaces Simbólicos en lugar de accesos directos, ver Extensión de la cáscara de enlace )
* (consejo: añade la carpeta de capas como barra de herramientas del menú de inicio para tenerlas siempre a mano).
Z:\\Layers\\
Base\\
Thematic\\
Reference\\
All Dressed Base (250k).lyr
Administration Boundaries (1000k).lyr
...
Z:\\Raster\\
Landsat\\
Orthos\\
Z:\\Data\\
Foo\_50k.gdb
Foo\_250k.gdb
NoScale.gdb
Las composiciones de mapas y los resultados (archivos de impresión, pdf, exportaciones, etc.), que por naturaleza son más dinámicos y variables, se almacenan y organizan de forma diferente en otro lugar. Esta es la parte que nos ha resultado más difícil. Actualmente utilizamos una unidad de disco dedicada con carpetas nombradas según el número de trabajo (si lo hiciéramos de nuevo, utilizaríamos la fecha), '2010-10-26' ) y subcarpetas para los datos específicos del proyecto y los resultados/deliberables. Un índice de hoja de cálculo enumera todos los números de trabajo (nombre de carpeta), sus correspondientes títulos de mapa y el cliente. Ej:
W:\\Foo\_0123\\
Foobarmap\_001.mxd
Docs\\
ReadMe.doc
Data\\
buffers\_2000m.shp
gps\_tracks.csv
Output\\
Foobarmap\_001.pdf
Deliverables
Mantener el índice actualizado es un punto de fricción, a la gente no le gusta hacerlo, lo evita, y es inconsistente con los nombres, etc. (usar una base de datos en lugar de una hoja de cálculo ayudaría). El uso de una convención numérica de nombres de carpetas también hace muy difícil encontrar el mapa del proyecto X sin el índice, otra notable fuente de fricción. Lo ideal sería que el índice fuera una página html en la que se pudiera hacer clic y que se generara automáticamente a partir de una aplicación de base de datos. Pero ese es otro proyecto.
Principios clave:
- separar las cosas que cambian lentamente y se reutilizan a menudo de las dinámicas y variables, y tratarlas de forma diferente
- No duplique innecesariamente, utilice archivos de capas y accesos directos/enlaces siempre que sea posible.
- no cambies de sistema con demasiada frecuencia, dale a cada uno una prueba sólida.
Agradezco mucho los ejemplos de otras estructuras, ya que, como he dicho, no nos conformamos con lo que tenemos :)
