¿Organización y orden de múltiples copias de capas? [cerrado]

En los días en que estaba en la universidad tenía un problema de "Organización y orden": estaba desorganizado y mantenía mis capas en diferentes carpetas sin nombres distintos y, por lo tanto, tenía varias copias de cada capa.

Desde que comencé a trabajar, he mejorado mucho: mantengo carpetas especiales con subcarpetas especiales. Nombro mis capas de acuerdo con un sistema que me permite ser un poco más ordenado, pero como todavía tengo que administrar varias copias de capas (como Autocad y ArcGIS tienen sus diferencias cuando se trata de idiomas no latinos, tengo que mantener una copia ajustado para cada programa), me gustaría saber de sus experiencias y tal vez aprender algunos consejos de usted:

1. ¿Cómo organizas tus capas? ¿Cómo nombrarlos? Por nombre, fecha, contenido, cliente?
2. ¿Cómo organiza o maneja múltiples copias (más agudo: ¿cómo actualiza varias copias a la vez)?

Nota: estoy hablando del punto de vista del analista / DBA y no del punto de vista de un desarrollador web / administrador web (estoy hablando de organizar las capas para mí y tal vez para otros dos trabajadores de SIG, no más).

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. :)

Si otras personas accederán a los datos en su sistema, no puede hacer que el esquema de la organización sea significativo solo para usted; debe tener en cuenta su uso del sistema. Si no los considera, pasará mucho tiempo respondiendo preguntas como "¿dónde están los datos del uso de la tierra?" Y "¿por qué no puedo encontrar el [insertar conjunto de datos aquí]?"

Al mantener este sistema durante muchos años, descubrí que las personas no pueden encontrar datos si primero se organizan por fuente, por ejemplo, c:\CensusBureau\Roadsy c:\ESRI\Countries. En cambio, recomiendo enumerar los datos temáticamente primero, luego por fuente en caso de que tenga múltiples fuentes, por ejemplo, c:\Roads\CensusBureauy c:\Roads\LocalGovt.

Del mismo modo, no separaría rásteres y vectores en diferentes directorios. Sin embargo, puede ser necesario dividirlos en diferentes unidades físicas o lógicas si tiene muchos datos ráster que no caben en una unidad.

Recomiendo la siguiente estructura de directorios. Theme \ SourceYear, donde Theme es la capa temática, Source es un nombre abreviado para la fuente de datos y Year es el año que representan los datos en el terreno. En este escenario, los caminos TIGER de la Oficina del Censo se ubicarían en \Roads\Census00y \Roads\Census10(o reemplazarían 'Censo' con 'TIGRE').

Tenga en cuenta que ciertas extensiones en ArcGIS no funcionan con nombres de archivo de más de 13 caracteres. No puedo recordar qué extensión, solo recuerdo que esto es un problema.

Trabajamos en un nivel de proyecto para archivos cad, supongo que depende de cómo esté configurado su flujo de trabajo particular, tenemos nuestro proyecto de trabajo maestro y luego preparamos cualquier almacén de datos adicional a partir de esto en un script de exportación al final de la sesión de edición.

datadir \ cad \ cadastre.dgn
datadir \ srv \ fuel.dgn
datadir \ srv
\ sewerage.dgn
datadir \ map \ base.dgn datadir \ map \ printsets.dgn
...

entonces cada archivo tiene niveles / capas / características nombradas con un identificador
sewPipe
sewManhole
sewPit
...

Luego lo exportamos todo a SQL espacial en lugar de leer nuestros archivos de proyecto de trabajo donde se muestra al usuario a través de Mapguide o cualquier aplicación GIS de sabor necesaria.

Las capas SIG se ordenan por nombre de entidad con identificadores y un diseño de carpeta similar para permitir la clasificación.