Este é um problema perverso . Tentamos vários sistemas, que funcionaram em graus variados por um tempo e, eventualmente, cresceram pesadamente e começaram a desmoronar à medida que mais casos extremos que não se encaixam são encontrados. Dito isto, cada um dos sistemas que usamos é muito melhor que nada, provando a máxima de que qualquer sistema é melhor que nenhum sistema.
Aqui está uma visão geral em miniatura de nossa prática atual:
Coloque tudo, exceto rasters, em um geodatabase de arquivo, quanto menos, melhor. Não aninhe classes de recurso em conjuntos de dados de recursos, a menos que estejam relacionados de alguma maneira (por exemplo, hidrelétricas, hidrelétricas, lagos, hidrelétricas> áreas úmidas, etc.). Isso leva a uma grande lista longa no topo do fgdb, mas esse é um mal aceitável.
Crie arquivos de camada para todas as classes de recursos e organize-os; isso oferece muita liberdade para nomear conforme necessário, usando caracteres não suportados etc. * e capacidade de mover e renomear conforme as circunstâncias mudam. Também permite duplicação sem redundância, por exemplo, um conjunto de camadas agrupadas de acordo com a escala nominal (50k, 250k ...), outra por região (AK, YT ...), uma terceira por tema (caribu, uso da terra, transporte ...) e um quarto pelo cliente enquanto o próprio armazenamento de dados permanece inalterado.
Para duplicatas, use atalhos em vez dos próprios arquivos de camada; caso contrário, há muitas coisas a serem atualizadas quando as coisas mudam. Configure o ArcCatalog para mostrar atalhos: * Ferramentas> Opções> tipos de arquivo: .lnk (Limitações: visualização e metadados não funcionam, você não pode seguir o atalho até sua origem no ArcCatalog. Isso pode ser corrigido usando Links Simbólicos em vez de atalhos , consulte Extensão do Shell de Link )
* (dica: adicione a pasta Camadas como uma barra de ferramentas do Menu Iniciar para que elas estejam sempre ao seu alcance.)
Z: \ Camadas \
Base\
Temático\
Referência\
All Dressed Base (250k) .lyr
Limites da administração (1000k) .lyr
...
Z: \ Raster \
Landsat \
Orthos \
Z: \ Data \
Foo_50k.gdb
Foo_250k.gdb
NoScale.gdb
Mapeie composições e saídas (arquivos de impressão, PDFs, exportações etc.) que por natureza são mais dinâmicas e variáveis são armazenadas e organizadas de maneira diferente em outro lugar. Esta é a parte que tem sido mais difícil para nós. Atualmente, usamos uma unidade dedicada com pastas nomeadas de acordo com o trabalho # (fazendo isso novamente, eu usaria date em vez de '2010-10-26' ) e subpastas para dados e resultados / deliberáveis específicos do projeto. Um índice da planilha lista todos os números de trabalhos (nome da pasta), seus títulos de mapas correspondentes e cliente. Ex:
W: \ Foo_0123 \
Foobarmap_001.mxd
Documentos \
ReadMe.doc
Dados\
buffers_2000m.shp
gps_tracks.csv
Saída\
Foobarmap_001.pdf
Entregas
Manter o índice atualizado é um ponto de atrito, as pessoas não gostam de fazê-lo, evitam-no e são inconsistentes com a nomeação etc. (usar um banco de dados em vez de planilha ajudaria). O uso de uma convenção numérica de nomes de pastas também dificulta o mapeamento do projeto X sem o índice, outra fonte notável de atrito. Idealmente, o índice seria uma página html clicável, gerada automaticamente a partir de um aplicativo db. Esse é todo o outro projeto.
Princípios chave:
- separar o material que muda lentamente e frequentemente reutilizado do dinâmico e variável e tratá-los de maneira diferente
- Não duplique desnecessariamente, use arquivos de camada e atalhos / links sempre que possível.
- não mude de sistema com muita frequência, tente cada uma com firmeza.
Congratulo-me com exemplos de outras estruturas, pois disse que não estamos contentes com o que temos. :)