Uso o ArcView desde 2000 sem que este assunto tenha sido alguma vez discutido em profundidade, nem nos diversos cursos que frequentei, nem nas conversas que tenho tido com os poucos utilizadores de SIG que conheço.

Nesse contexto o modo de organizar os projectos de ArcView tem evoluído ao sabor da necessidade, da experiência acumulada e das capacidades do software.

O que pretendo então é partilhar o método que uso, explicar, na medida do possível, como e porque razão acorreram as alterações ao mesmo e, acima de tudo, ouvir os conselhos que queiram partilhar.

O enquadramento.

Até há bem pouco tempo todos os projectos eram guardados localmente em estações de trabalho reservadas para o SIG e o trabalho em cada um desses projectos era, na maioria dos casos, feito por um só técnico–assim o permitia a dimensão média dos projectos.

ArcView 3.X

De maneira a minimizar o mais possível o número de cliques necessário para percorrer as directorias de um projecto e eliminar os espaços que existiam nos caminhos mais comuns do Windows 2000 (Desktop, Os Meus Documentos) optamos por colocar a raiz de cada projecto o mais próximo possível da raiz do disco, assim:

• C:\Projecto_X

Em detrimento de:

• C:\Documents and Settings\Utilizador\Os Meus Documentos\Projecto X

Para acelerar ainda mais a navegação colocamos os projectos num disco reservado para os projectos de ArcView, desse modo evitávamos ter as pastas de raiz dos projectos a coabitar com as pastas do sistema

• D:\Projecto_X

Para que os os nomes das pastas de projecto fossem imediatamente identificáveis, relacionáveis com as outras vertentes do projecto e dispostas por ordem cronológica, adoptou-se o código único, sequencial anual já em vigor na empresa, acrescentando-se apenas o sufixo “SIG_”.

• D:\SIG_01056

A pasta de projecto continha no seu interior os projectos (*.apr ou *.mxd) e sub-pastas que agrupavam os elementos geográficos por tipo (Shapefile, Raster ou CAD) ou outra característica que assim o justificasse (Temporário, Auxiliar).

• D:\
  • SIG_01056
    • Arquivo_SHP
    • Arquivo_GRD
    • Arquivo_TMP
    • Figura_1.mxd
    • Figura_2.mxd
    • (...)

Para não sobrecarregar as pastas de projecto com elementos que se repetiam na maioria dos projectos–elementos como a CAOP, o arquivo das cartas militares, o atlas do ambiente, entre outros–foi criada uma pasta que se manteria na raiz do disco D. O nome Arquivo_SIG tinha como benesse adicional ficar no topo da lista de pastas no disco D (partindo do princípio que as pastas estavam ordenadas alfabéticamente) de onde era imediatamente acessível, e permitindo desta forma poupar uns cliques.

• D:\
  • Arquivo_SIG
    • Arquivo_limites_administrativos
    • Arquivo_carta_militar
    • Arquivo_layouts
    • (...)
  • SIG_01056
    • Arquivo_SHP
    • Arquivo_GRD
    • Arquivo_TMP
    • Figura_1.mxd
    • Figura_2.mxd
    • (...)

ArcView 8.X

A diferença entre o 3.X e o 8.X era tão grande que a ESRI permitiu temporáriamente a utilização em simultâneo das duas licenças a quem fizesse a actualização (?). Mas foi uma evolução bem vinda e passados uns meses já se funcionava a todo o gás na nova plataforma. E no entanto, independentemente do paradigma causado pelo novo programa, o modo de estruturar os projectos sofreu poucas alterações.

Por suportar nomes com mais caracteres, acrescentei uma pequena descrição ao nome da pasta de projecto.

Para libertar a raiz do disco D que entretanto se encontrava saturada de pastas de projecto, criei arquivos anuais para onde colocaria os projectos finalizados ou “adormecidos”.

• D:\
  • Arquivo_2001
    • SIG_01056_Lorem_Ipsum_(versao_X)
    • SIG_01056_Lorem_Ipsum_(versao_Y)
    • SIG_01092_Lorem_dolor
    • (...)
  • Arquivo_2002
    • SIG_02021_Phasellus_ac_ligula
    • SIG_02022_Fusce_eu_massa
    • SIG_02076_Vestibulum_ut_nulla
    • (...)
  • Arquivo_SIG
    • Arquivo_limites_administrativos
    • Arquivo_carta_militar
    • Arquivo_layouts
    • (...)
  • SIG_03108_Lorem_Ipsum
    • Arquivo_SHP
    • Arquivo_GRD
    • Arquivo_TMP
    • Figura_1.mxd
    • Figura_2.mxd
    • (...)

ArcView 9.X

A complexidade crescente dos projectos tornou necessária a sua distribuição por entre elementos da equipa. O arquivo local passou então a incluir no nome a identificação do técnico responsável pelo mesmo.

• D:\
  • SIG_09156_GD_Lorem
    • Arquivo_SHP
    • Arquivo_TMP
    • Figura_1.mxd
    • Figura_2.mxd
    • (...)
• D:\
  • SIG_09156_FC_Lorem
    • Arquivo_SHP
    • Arquivo_GRD
    • Figura_3.mxd
    • Figura_4.mxd
    • (...)

A passagem da CAOP, em Agosto de 2008, para o sistema de referência ETRS89-PT-TM06 (CAOP2008.1) serviu como pretexto para rever a informação armazenada na pasta Arquivo_SIG, informação que até então usava predominantemente o sistema de referência Hayford-Gauss Datum 73 (e, já em minoria, o Datum Lisboa).

O modelo inicial de organização do Arquivo_SIG dividia os elementos cartográficos por colecções, como por exemplo: Carta_de_solos, Carta_geológica, Atlas_do_ambiente, Arquivo_diversos (onde colocava o que não conseguia classificar) etc… . Este modelo funcionou bem até se ter atingido um número elevado de colecções. A partir desse ponto, a enorme quantidade de pastas e ficheiros começou a dificultar a navegação e posterior escolha dos elementos geográficos.

De forma a minimizar este caos, reorganizei a informação, a um primeiro nível, usando a entidade emissora da colecção. E sempre que a quantidade de elementos o justificava, separava-os em sub-colecções.

• Arquivo_SIG
  • Arquivo_APA
    • Atlas_do_Ambiente-Continente
    • Atlas_do_Ambiente-Madeira
    • Atlas_do_Ambiente-Acores
    • (...)
  • Arquivo_IGEO
    • Arquivo_CAOP
      • Arquivo_CAOP2008.1
      • Arquivo_CAOP2009.0
    • (...)
  • Arquivo_IGEOE
    • Arquivo_CM_400_499
      • CM_400_3.tif
      • CM_401_3.tif
      • (...)
    • Arquivo_CM_500_599
    • Cartograma_da_serie_E888_ETRS89
    • Cartograma_da_serie_E888_DT73
    • Cartograma_da_serie_E888_DTLX
    • (...)
  • Arquivo_ICNB
    • Rede_Nacional_Areas_Protegidas_ETRS89
    • Rede_Nacional_Areas_Protegidas_DT73
    • Sitios_de_Importancia_Comunitaria_ETRS89
    • Sitios_de_Importancia_Comunitaria_DT73
    • (...)

Existe, neste modelo de centralizar os elementos recorrentes, um senão: Quando se torna necessário enviar o projecto ou criar um cd-rom/dvd-rom que funcione autónomamente, tem de se refazer o projecto de modo a incluir na pasta do mesmo todos os elementos que normalmente estariam no Arquivo_SIG.

Independentemente desta limitação, outros problemas surgem naturalmente quando os projectos atingem uma certa complexidade e tamanho. Tal facto obrigou a uma nova revisão ao processo

O actual sistema local

Com o descer do preço dos discos rígidos e o aumento da capacidade dos mesmos, parecia inevitável que se teriam de criar projectos autónomos–nos quais todos os elementos estivessem incluídos na pasta de projecto–no entanto isso iria dificultar o processo de backup e, mais precisamente, o processo de backup online/offsite usando serviços actualmente disponíveis como por exemplo o Amazon AWS S3, ou mesmo o Google Docs.

A solução encontrada foi separar os elementos geográficos mediante hierarquias de salvaguarda

Assim, os elementos críticos–criados no âmbito do projecto e geralmente mais difíceis de recuperar em caso de falha, são arquivados numa geodatabase identificada com o código do projecto.

Os restantes elementos geográficos são arquivados numa geodatabase reutilizável identificada apenas pela versão da sua revisão.

Esta geodatabase reutilizável consistirá numa versão reduzida do Arquivo_SIG contendo apenas os elementos essenciais à maioria dos projectos. Sempre que se justificar uma revisão, como por exemplo: substituir a CAOP por uma nova versão que entretanto tenha sido publicada ou incluir uma colecção que considere essencial, altera-se a versão da geodatabase e regista-se em que consistiu a alteração.

Em resumo, a utilização desta geodatabase reutilizável trás os seguintes benefícios:

• Só é necessário efectuar um backup por versão;
• Assim que se termina um projecto, pode-se apagar esta geodatabase reutilizável de forma poupar espaço em disco. É apenas necessário referir que edição da geodatabase se usou;

Deste modo temos a seguinte estrutura:

• Arquivo_SIG
  • Arquivo_APA
    • Atlas_do_Ambiente-Continente
    • Atlas_do_Ambiente-Madeira
    • Atlas_do_Ambiente-Acores
    • (...)
  • Arquivo_IGEO
    • Arquivo_CAOP
      • Arquivo_CAOP2008.1
      • Arquivo_CAOP2009.0
    • (...)
  • Arquivo_IGEOE
    • Arquivo_CM_400_499
      • CM_400_3.tif
      • CM_401_3.tif
      • (...)
    • Arquivo_CM_500_599
    • Cartograma_da_serie_E888_ETRS89
    • Cartograma_da_serie_E888_DT73
    • Cartograma_da_serie_E888_DTLX
    • (...)
• SIG10103GD_Lorem_Ipsum_Dolor
  • RASTER_10103 (para backup imediato)
  • DTM
  • SLP_PERC
  • FLOWDIR
  • FLOWACC
  • (...)
  • SHAPEFILE_10103 (para backup imediato)
  • Area_de_estudo_poligonos
  • Area_de_estudo_buffer50m
  • Area_de_estudo_linhas
  • Unidades_de_paisagem
  • Habitats
  • DTM_curvas_de_nivel
  • (...)
  • BASE_001 (arquivo reutilizável, versão 1, dispensa backup)
    • CAOP2009.0
    • ESRI
    • ICNB
    • INTERSIG
    • LAYOUT
  • Figura_1.mxd
  • Figura_2.mxd
  • (...)

Como refiro no título e ao longo do post, esta estrutura aplica-se ao uso num computador local.

Se há uma coisa que aprendi neste anos de trabalhar em SIG é que cada projecto é único e, muitas vezes, as rotinas não se conseguem aplicar… lol