Como você gerencia seus dados geoespaciais? Tenho terabytes de dados espalhados por centenas de conjuntos de dados e tenho uma solução ad-hoc usando links simbólicos em projetos que se vinculam a um diretório de archive baseado em nome de domínio para cada conjunto de dados. Isso funciona principalmente, mas tem seus próprios problemas.
Também gosto de saber se alguém gerencia seus dados geoespaciais em um sistema de controle de revisão; Atualmente, uso um para meu código e pequenos conjuntos de dados, mas não para conjuntos de dados completos.
Respostas:
Eu acho que a resposta estoque / óbvia seria usar um banco de dados espacial (PostGIS, Oracle, SDE, MSSQL Spatial, etc) em conjunto com um servidor de metadados, como o GeoPortal da esri ou o aplicativo GeoNetwork de código aberto, e no geral acho que isso geralmente é a melhor solução. No entanto, você provavelmente sempre precisará de snapshots / branches / tags baseados em projeto. Alguns dos bancos de dados mais avançados têm maneiras de gerenciá-los, mas geralmente não são tão fáceis de usar / gerenciar.
Para coisas que você armazena fora de um banco de dados (imagens grandes, arquivos baseados em projetos), acho que a chave é ter uma convenção de nomenclatura consistente e, novamente, um registro de metadados (mesmo algo de baixa tecnologia como uma planilha) que permita rastreá-los e garantir que eles sejam gerenciados adequadamente. Por exemplo, no caso de arquivos baseados em projeto, isso pode significar excluí-los quando a política de gerenciamento de registros exigir, ou lançá-los no repositório central na conclusão do projeto.
Eu vi algumas soluções interessantes embora ...
Quando o Ministério do Meio Ambiente da BC estava executando coisas fora das coberturas do Arc / Info, eles tinham um processo muito legal de sincronização bidirecional baseado em rsync. As coberturas que estavam sob controle central foram enviadas às regiões todas as noites e os dados regionais foram enviados novamente. Essa transferência diferencial em nível de bloco funcionou muito bem, mesmo com 56k links. Houve processos semelhantes para replicar os bancos de dados de atributos baseados em Oracle, mas não acho que eles normalmente tenham se saído muito bem na discagem :)
Meu local de trabalho atual usa uma solução híbrida semelhante. Cada conjunto de dados tem sua cópia autorizada (alguns no Oracle, outros no MapInfo, outros em bancos de dados pessoais) e esses são ETL cruzados noturnos usando o FME. Existem algumas despesas gerais bastante importantes aqui quando se trata de manutenção; o esforço para criar qualquer novo conjunto de dados e garantir que a visibilidade organizacional seja consideravelmente maior do que deveria. Estamos no processo de uma revisão com o objetivo de encontrar uma maneira de consolidar para evitar essa sobrecarga.
fonte
Os metadados são de longe a questão mais importante aqui. Se os metadados respondem a quem, quando, por que e onde é um registro de metadados aceitável.
Tendo experiência de trabalho em grandes empresas com apenas alguns usuários de GIS (cerca de 30), tivemos grandes problemas para controlar dados, especialmente versões e permissões. Um lado disso pode ser resolvido com uma extensa documentação de dados (metadados) e os outros problemas provavelmente são resolvidos com um repositório central, no qual o PostGIS brilha.
O GeoNetwork é um bom começo para lidar com problemas de metadados. Resolver o repositório central é mais complicado, pois pode levar uma pessoa especializada para projetar / manter o banco de dados.
A questão complicada é quem será responsável pelo controle de qualidade / controle de qualidade desses conjuntos de dados e seus metadados. Embora os processos controlados por computador funcionem bem, eles não podem ser tão rigorosos quanto um bom gerenciador / guardião de dados, que foi feito nessa empresa em que trabalhei. Agora, existe alguém exclusivo para revisar / confirmar metadados e organizar dados geoespaciais que não estão centralizados em um DBMS.
fonte
Utilizamos um sistema de arquivos organizado hierarquicamente por: - extensão geográfica (país ou continente) - provedor de dados, licenciante - domínio / conjunto de dados - data / versão
Depois disso, temos uma política para separar os dados de origem (no mesmo formato que estava em qualquer CD / DVD que obtivemos do provedor) de quaisquer conjuntos de dados derivados que produzimos em nossa empresa.
O sistema de arquivos facilita muito a ingestão de dados do cliente e também permite alguma flexibilidade em termos de armazenamento físico - mantemos nossos arquivos em discos maiores e mais lentos e temos servidores de arquivos especiais (vinculados de forma transparente à hierarquia) para os conjuntos de dados usados com mais frequência.
Para facilitar o gerenciamento dentro dos projetos, usamos links simbólicos. Mantemos nossos vetores em um banco de dados (Oracle) e estabelecemos como regra ter pelo menos uma instância de banco de dados por cliente (e vários usuários / esquemas para os projetos). No entanto, não mantivemos muitos rasters em um banco de dados, pois eles tendem a ocupar muito espaço, mesmo fora de um. Além disso, gostamos de manter nossas instâncias de banco de dados o mais leve possível.
E sim, temos alguém encarregado de 'policiar' a coisa toda, para que não fique muito confuso.
O maior problema que temos com essa configuração atualmente é a falta de uma interface agradável para o usuário, o que nos ajudaria a ter uma visão geral melhor de tudo, e planejamos incluir um armazenamento de metadados em cima disso. Ainda estamos considerando nossas opções aqui.
Estamos usando o controle de versão para o nosso código e o usamos para documentos, mas acontece que o controle de versão não é realmente feito para grandes conjuntos de dados, especialmente se forem na maioria arquivos binários, por isso não recomendo que , exceto se você estiver lidando com o GML ou algo semelhante ao texto (os problemas incluem enormes custos indiretos no uso do disco do lado do servidor, bem como os clientes travando ao verificar grandes repositórios).
fonte
Como @JasonBirch disse, o controle de versão é um grande problema.
Também descobrimos que um fluxo de trabalho apropriado é extremamente importante. Por exemplo, ao coletar dados de campo, tendemos a usar bancos de dados temporários nos quais os dados de campo podem ser submetidos a controle de qualidade antes de serem mesclados no conjunto de dados mestre. Dependendo da quantidade de dados que precisa ser controlada pelo controle de qualidade, isso sempre criará alguma sobrecarga.
Além disso, se você ainda não o viu, recomendo dar uma olhada no ebook de Geo-comunicação e design de informações de Lars Brodersen, pelo menos para o que ele tem a dizer sobre modelagem de dados.
fonte
Postgres como todo mundo já disse, no entanto, se você quiser mantê-lo portátil e fácil de mover, poderá sempre usar o SQLite + a extensão Spatialite.
Não é tão fácil de usar quanto o Postgres em termos de ferramentas de gerenciamento, mas o QGis PODE conversar diretamente com um Banco de Dados GIS espacializado, sem problemas.
Na verdade, eu uso o SQLite + Spatialite para backup, tenho um serviço do Windows que é executado em segundo plano (personalizado), que monitora minha instância PGSql e espelha meus dados GIS em vários bancos de dados SQLite que residem em unidades USB externas.
Mais uma dica com PG também, use esquemas
Muitas pessoas que conheço simplesmente descartam tudo em "público" e terminam, mas se você organizar seu banco de dados corretamente, isso fará a diferença.
Por exemplo, meu banco de dados "Ordnance_Survey" possui esquemas para VectormapDistrict VectormapLocal Topo50 LookupGrids CodePointWithPolygons CodePointOpen
onde guardo todos os dados associados.
Enquanto isso, as tabelas de metadados, como colunas de geometria etc., apenas vivem em Public, a extensão Postgis também é ativada apenas no esquema público, mas é acessível a partir de todos os outros esquemas em uso.
fonte
Conforme mencionado na postagem anterior, os bancos de dados espaciais e um servidor de metadados são a configuração usual. Penso que uma coisa importante a lembrar é que "um tamanho não serve para todos". Você terá dados que se encaixam melhor no Oracle, servidores de arquivos, SQL server, qualquer que seja. Eu tentei usar todos os dados necessários em uma solução e geralmente falha.
Espere usar soluções diferentes que se ajustem aos dados e planejem para eles. É aqui que o portal geográfico (servidor de metadados) realmente entra.
fonte
Eu tenho que concordar com 'George' acima, de que os metadados devem desempenhar um grande papel no gerenciamento de dados geoespaciais. Realmente com qualquer dado digital, os metadados são fundamentais - pense em um fotógrafo que tenta gerenciar seus arquivos de fotos digitais sem os metadados adequados. A vida fica muito mais fácil se você marcar as coisas religiosamente e tiver um bom software que possa utilizar os dados. Agora, a pergunta original sobre 'gerenciar dados geoespaciais' é bastante ampla - podem ser formatos de dados para armazenar, convenções de nomes, hierarquia de conjuntos de dados e recursos, funções e privilégios de edição, etc. etc. etc.
fonte
O padrão de armazenamento para dados geoespaciais depende de como você deseja consultá-lo / o que deseja fazer com ele. A seguir, algumas ferramentas que você pode considerar:
Postgres + PostGIS: Suporta índices geoespaciais e todos os tipos de consultas que você pode imaginar. Para gerenciar seus terabytes de dados, você precisará aplicar sharding, otimização de consultas etc. Se a sua carga de gravação for pesada, eu não recomendaria isso.
MongoDB: suporta grandes quantidades de dados. Ótimo para armazenamento simples, recuperação e consultas geoespaciais limitadas.
Armazenamento de arquivos: se você é realmente apenas um sistema de arquivamento e usa apenas parte dos dados para consulta, pode ser econômico armazenar seus dados como arquivos. Seu requisito de controle de versão pode estar bem satisfeito com isso.
Redis: você pode combinar qualquer uma das opções acima com o suporte Redis Geo para armazenar uma pequena quantidade de dados "quentes" em redis que você precisa acessar com freqüência. Pense nisso como seu cache.
fonte