Tags
Twitter
- RT @ConanOBrien: Just spent all day at Legoland. It was so much fun, next time I think I'll bring my children. 2010/09/06
- RT @Glinner: A full page of one and two-star film reviews in Guardian today. Not unusual. But of course, it's file-sharing that's destro ... 2010/09/03
- RT @kottke: Esquire phone phreaking article from 1971 http://kottke.org/x/4oz5 2010/09/02
- RT @abraham: Sometimes I write a letter on paper with a pen then burn it laughing about how Google must be crying over information it wi ... 2010/09/02
- BBC Radio 4 - A History of the World in 100 Objects - http://itunes.apple.com/pt/podcast/a-history-world-in-100-objects/id351096296 #iTunes 2010/09/02
Arquivos
Estrutura local de um projecto de SIG
Antes de mais, a razão deste post.
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:
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
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_”.
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.
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”.
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.
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.
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:
Deste modo temos a seguinte estrutura:
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