Este es un problema perverso . Hemos probado varios sistemas, que han funcionado en mayor o menor grado durante un tiempo, y finalmente crecieron poco manejables y comenzaron a desmoronarse a medida que se encontraron más casos extremos que no encajan del todo. Dicho esto, cada uno de los sistemas que hemos usado es mucho mejor que nada, lo que demuestra la máxima de que cualquier sistema es mejor que ningún sistema.
Aquí hay una descripción en miniatura de nuestra práctica actual:
Ponga todo, excepto los rásteres, en una geodatabase de archivos, cuantos menos mejor. No anide las clases de entidades en conjuntos de datos de entidades a menos que estén relacionadas de alguna manera (por ejemplo, hidro> corrientes, hidro> lagos, hidro> humedales, etc.). Esto lleva a una larga lista en la parte superior de la fgdb, pero eso es un mal aceptable.
Cree archivos de capa para todas las clases de entidad y organícelo en su lugar, esto le da mucha libertad para nombrar según sea necesario, usando caracteres no compatibles, etc. *, y la capacidad de moverse y cambiar el nombre a medida que cambian las circunstancias. También permite la duplicación sin redundancia, por ejemplo, un conjunto de capas agrupadas según la escala nominal (50k, 250k ...), otra por región (AK, YT ...), una tercera por tema (caribú, uso de la tierra, transporte ...), y un cuarto por cliente mientras el almacén de datos permanece sin cambios.
Para duplicados, use accesos directos en lugar de los archivos de capa, de lo contrario, hay demasiadas cosas para actualizar cuando las cosas cambian. Configure ArcCatalog para mostrar accesos directos: * Herramientas> Opciones> tipos de archivo: .lnk (Limitaciones: la vista previa y los metadatos no funcionan, no puede seguir el acceso directo a su fuente en ArcCatalog. Esto se puede solucionar utilizando enlaces simbólicos en lugar de accesos directos , vea Extensión de Shell de Enlace )
* (consejo: agregue la carpeta Capas como una barra de herramientas del menú Inicio para que siempre estén al alcance de su mano).
Z: \ Capas \
Base\
Temático\
Referencia\
All Dressed Base (250k) .lyr
Límites de administración (1000k) .lyr
...
Z: \ Ráster \
Landsat \
Orthos \
Z: \ Datos \
Foo_50k.gdb
Foo_250k.gdb
NoScale.gdb
Las composiciones y salidas de mapas (archivos de impresión, pdf, exportaciones, etc.) que por naturaleza son más dinámicas y variables se almacenan y organizan de manera diferente en otro lugar. Esta es la parte que ha sido más difícil para nosotros. Actualmente utilizamos una unidad dedicada con carpetas nombradas de acuerdo con el número de trabajo (de nuevo, usaría la fecha, '2010-10-26' ) y subcarpetas para datos específicos del proyecto y resultados / deliberables. Un índice de hoja de cálculo enumera todos los números de trabajo (nombre de la carpeta), sus títulos de mapas correspondientes y el cliente. Ex:
W: \ Foo_0123 \
Foobarmap_001.mxd
Docs \
ReadMe.doc
Datos\
buffers_2000m.shp
gps_tracks.csv
Salida\
Foobarmap_001.pdf
Entregables
Mantener el índice actualizado es un punto de fricción, a las personas no les gusta hacerlo, lo evitan y son inconsistentes con los nombres, etc. (sería útil usar una base de datos en lugar de una hoja de cálculo). El uso de una convención numérica de nombre de carpeta también hace que sea muy difícil para el mapa del proyecto X sin el índice, otra fuente notable de fricción. Idealmente, el índice sería una página html en la que se pueda hacer clic, que se genera automáticamente a partir de una aplicación db. Sin embargo, ese es todo otro proyecto.
Principios fundamentales:
- separe las cosas que cambian lentamente y que a menudo se reutilizan de las dinámicas y variables, y trátelas de manera diferente
- No duplique sin necesidad, use archivos de capa y accesos directos / enlaces siempre que sea posible.
- no cambie los sistemas con demasiada frecuencia, pruebe cada uno de manera sólida.
Doy la bienvenida a ejemplos de otras estructuras, ya que dije que no estamos contentos con lo que tenemos. :)