O que é uma boa taxonomia ou convenção de nomenclatura para arquivos e pastas que contêm dados GIS? [fechadas]

Minha empresa coletou cerca de 30 TBs de dados GIS nos últimos 8 anos e sempre me pego fazendo as seguintes perguntas:

1. Que tipo de dados temos para uma determinada área geográfica?
2. Quais são os detalhes sobre esses dados (por exemplo, resolução em metros por pixel)?
3. Onde os dados existem no disco rígido para que eu possa usá-los?
4. Já processamos os dados ou estão de forma inalterada a partir da fonte?

Até agora, tentei abordar essas questões criando uma taxonomia / hierarquia apropriada de pastas e arquivos. Alguém tem idéias / sugestões sobre algumas maneiras compreensíveis, talvez até padrão, de organizar dados GIS usando arquivos e pastas?

Também estou aberto a aprender mais sobre como o uso de um banco de dados pode beneficiar minha empresa; somos desenvolvedores de software, não especialistas em GIS, por isso desconfio que estamos um pouco atrasados ​​sobre a melhor maneira de abordar o problema de armazenar / organizar dados GIS para facilitar o uso. Eu vi a pergunta Melhores práticas para gerenciar dados geoespaciais, mas só consegui tirar o uso marginal das respostas, porque não estou familiarizado com os bancos de dados geográficos.

ATUALIZAÇÃO: Nesta semana passada, passei um bom tempo lendo sobre bancos de dados GIS e comecei a me familiarizar com o PostGIS. A longo prazo, acho que acabaremos adotando um servidor de banco de dados e de metadados, conforme recomendado por JasonBirch em Melhores práticas para gerenciar dados geoespaciais .

Se você estiver realmente tentando editar dados ou desenvolver um mapa, precisará manter os dados em que está trabalhando ativamente separados dos dados com os quais começou. Quando inicio um projeto, crio uma pasta SourceData, com subdiretórios nomeados pelo tipo de dados (DEM, Ortofoto, Hidrologia etc.). Isso manterá todas as camadas que estou usando apenas para referência. Todos os dados em que estou trabalhando serão copiados para uma pasta diferente chamada Trabalhando. A pasta Working contém dados, MXDs e qualquer outra coisa que eu modifique ou crie em subdiretórios que geralmente se correlacionam com uma fase do projeto (MXDs, RoadEdits, Delivery, etc.)

Além dos dados GIS reais, você deve criar uma pasta Comunicações ou Especificações para armazenar todos os documentos do seu cliente / cliente interno / professor. Isso pode servir como metadados quando você voltar ao projeto posteriormente, além de criar um local centralizado onde qualquer outra pessoa possa ver o que deveria estar acontecendo.

Parece-me que você precisa de um conjunto de metadados para armazenar essas informações e um sistema de recuperação que use os metadados para permitir a extração de dados com base nas informações.

Eu acho que você deseja uma solução que ofereça suporte a um serviço de catálogo OGC, para máxima interoperabilidade. Vi colegas usarem o Deegree - embora, é claro, haja outras soluções que você deva verificar.

Aqui está um exemplo de como vinculamos o Deegree ao nosso software (a demonstração ao vivo está em manutenção no momento - você não sabia! -, mas deve voltar na próxima semana)

Quanto à nomeação de arquivos, se você tiver um serviço de catálogo e mecanismo de entrega, haverá menos problemas sobre como os arquivos são nomeados e onde estão. Caso contrário, acho que depende de como você olha para os dados. Você começa estreitando a área geográfica ou o tipo de dados? Isso determinará se a hierarquia começa dividindo os dados em blocos e, em seguida, os tipos de dados por bloco; ou dividindo-o em tipos de dados, cada um com um conjunto de blocos.

Obviamente, com um banco de dados espacial, você não tem os mesmos problemas em dividir os dados em blocos, o que geralmente é um método preferencial - desde que o aplicativo de uso final suporte o uso desse tipo de dados.

Eu escolheria o SpatiaLite, que é um banco de dados de um arquivo onde você pode inserir todos os seus shapefiles, rasters e tabelas. Então, como um banco de dados SQL relacional, você tem o poder de consultas SQL à sua disposição para executar todas as ações necessárias (associação, seleção, mesclagem, união, divisão, etc) entre atributos e arquivos.

O SpatiaLite também é acessível a partir de linguagens de programação como Python para um maior grau de automação. O céu é o limite.

Documentação e tutoriais do SpatiaLite

Considero útil criar documentos do Word intitulados "Nome ou tema do mapa - Metadados comments.doc". Documente as principais edições e fluxos de trabalho em ordem cronológica (AAAA-MM-DD) para cada mapa e / ou tema do conjunto de dados. Se você precisar descobrir o histórico de um conjunto de dados: i) Inclua a data de modificação / data criada dos arquivos relacionados que são úteis como referências históricas ou possíveis arquivos de origem. Inclua um breve resumo do conteúdo de cada arquivo (nomes de camadas, número de registros), prestando atenção às semelhanças ou diferenças gerais (isto é, o que há de novo em cada versão de um mapa ou conjunto de dados). Mantenha o arquivo "- Comentários de metadados" na mesma pasta de trabalho que a versão mais recente do mapa ou conjunto de dados. Coloque versões mais antigas do mapa ou dados em uma subpasta Archive. O processo de três etapas funciona bem no desenvolvimento de software, desenvolvimento de banco de dados e gerenciamento de arquivos: 1) Desenvolver (& documentar); 2) Teste (e documento); 3) Publicar (incluindo metadados). 1) pasta de trabalho; 2) Subpasta de arquivo; 3) versão publicada.