Centralizando dados do shapefile no banco de dados

Eu tenho centenas de shapefiles de vários projetos GIS diferentes que quero começar a consolidar em uma única plataforma de banco de dados, atualmente tentando isso com o Postgres / PostGIS.

Quase nenhum dado é padronizado - o que significa que são muitos dos mesmos tipos de dados , mas os nomes / tipos de atributos específicos não correspondem.

Onde devo começar a lidar com isso? Devo desenvolver um modelo padrão para migrar cada arquivo shapefile para o primeiro (por exemplo, Hydro_line, transport_line, Hydro_poly, etc)?

Uma alternativa é apenas importar cada shapefile para o Postgres individualmente, para que cada shp se torne uma tabela no banco de dados, mas não tenho certeza sobre isso em termos de desempenho e organização. Parece como adiar o inevitável ...

Algum conselho sobre como lidar com essa tarefa assustadora?

Dê uma olhada nos softwares Spatial ETL (Extract - Transform - Load), eles são dedicados a essas tarefas. O mais conhecido é o FME da Safe, mas agora estão disponíveis algumas alternativas de código aberto (parcial), como SDI (Spatial Data Integrator) e GeoKettle .

Hallo

Eu o importaria primeiro para o PostGIS. Existem ferramentas para carregar várias formas em tabelas individuais. A extensão do espeto QGIS é uma. O novo gráfico shp2pgsql no tronco PostGIS ou binários experimentais é outra alternativa. Ou você pode simplesmente escrever um script em lote com shp2pgsql.

Eu começaria por aí, importaria tudo para um esquema chamado original ou algo assim. Então, a partir disso, eu estruturaria os dados. Mesclando em tabelas, onde apropriado e assim por diante.

O bom de fazer dessa maneira é que, se você salvar todas as consultas usadas para fazer essas transformações, terá uma ótima documentação sobre o histórico dos seus dados. Também é muito fácil refazê-lo, se necessário. Quando estiver pronto para o seu trabalho de organização, despeje um backup do seu esquema "original" e guarde-o em algum lugar.

Eu acho que essa é uma maneira estruturada e limpa de fazer isso. E, como dito anteriormente, você obterá uma documentação muito sólida de qual campo mudou de nome para qual novo nome e quais tabelas originais são mescladas nesse novo e grande novo e assim por diante.

No FME e em softwares como esse, é claro que você também pode salvar o que fez, mas além de ser muito lento em comparação às consultas internas ao banco de dados, não é a maneira universal de documentar o que é feito como consultas sql. Eles serão utilizáveis ​​e legíveis enquanto houver arquivos de texto e bancos de dados relacionais.

Eu uso para acabar com arquivos de texto parecidos com:

-- A query to merge all roads in Norway

Create table road_tables.all_roads as
SELECT id as roadid, status, the_geom from original.big_roads
union all
SELECT rid as roadid, condition as status, the_geom from original.small_roads;

e assim por diante. Este arquivo salvo como texto tem um grande valor após alguns anos.

Atenciosamente Nicklas

Minha sugestão seria escolher 2 a 5 das camadas de dados usadas mais pesadas (shapefiles) e migrá-las para um rdbms.
Investigue e implemente fluxos de trabalho para esses dados. Acostumando-se às limitações e requisitos de rdbms vs dados baseados em arquivo.

As limitações incluem: exportação necessária, zona de aterrissagem, coordsys, tipo de arquivo para colaboração.

Existem muitos benefícios no que você está propondo.
Lado NOTA: (Meu avô disse a meus pais para gastar 6 meses procurando uma casa antes de comprar) considere que você está procurando uma casa (a longo prazo) para seus dados, não quer pagar por algo daqui a 30 anos a partir de agora. não gosto.

Minha recomendação seria escrever (digital ou analógica) uma lista de árvore de suas fontes de dados e visualizá-las em um quadro geral; isso permitirá que você organize os dados em agrupamentos mais concisos.

Existem métodos dentro do arcgis (minha suposição: você não especificou seu sistema preferido) para integrar dados diferentes.

Você pode tentar algumas dessas informações se estiver interessado em aprender boas práticas de design ...

visão geral do design do
geodatabase documentação do geodatabase
Há também links similares para o arco 10. Banco
de
dados geodatabase arc10