Tag opensource

Boa tarde pessoal,

Hoje iremos falar sobre como exportar os dados do PostGIS diretamente para um FileGDB utilizando nada mais do que a OGR, a ferramenta mais capaz de conversão de formatos que existe.

Independente se no linux ou Windows, você pode testar o suporte para a FileGDB API, usando:

ogrinfo --formats
Supported Formats:
 -> "ESRI Shapefile" (read/write)
     -> "MapInfo File" (read/write)
     -> "UK .NTF" (readonly)
     -> "SDTS" (readonly)
     -> "TIGER" (read/write)
     -> continua

Se a FileGDB, estiver disponível, você não precisa instalá-la.

Existem alguns passos importantes para que você consiga realizar esta exportação, principalmente no caso de sistemas operacionais Linux. Como a biblioteca FileGDB API, é proprietária da ESRI, ela não pode ser incluída na distribuição normal da GDAL/OGR, ou seja, precisamos instalar ela, antes de compilar nossa GDAL.

Vamos ao passo a passo:

1. Faça download da API no site da ESRI;
2. Descompacte-a no caminho /usr/local/lib/;
3. Compile a GDAL, especificando o caminho da pasta no momento da compilação, através da flag –with-fgdb=/usr/local/lib/FileGDB_API
4. Rode o comando “ogrinfo –formats” novamente para ver se o suporte está disponível;

Para utilizar a OGR para exportar os dados do PostGIS para um file geodatabase, você pode usar o comando ogr2ogr, com algumas opções. Vou dar um exemplo e explicar o que cada flag significa:

ogr2ogr -overwrite -nlt <LAYER_TYPE> -nln <NOME_TABELA_NOVA> -sql "SELECT * FROM <NOME_TABELA_BANCO>" -f "FileGDB" <CAMINHO_SAIDA.gdb> PG:"host=<SERVIDOR> port=<PORTA> dbname='<BANCO_DADOS>' user='<USUARIO>' password='<SENHA>'"

As opções:

• -overwrite significa sobrescrever o File Geodatabase. Caso você exporte a mesma tabela duas vezes, ela será sobrescrita. Caso exporte duas tabelas diferentes, a ogr2ogr irá adicionar as Feature Classes ao mesmo geodatabase;
• -nlt LAYER_TYPE: é o tipo da geometria;
• -nçn NOME_TABELA_NOVA: é o nome que a tabela terá no File Geodatabase;
• -sql: indica que você quer exportar os resultados de uma consulta SQL. Você pode ser criativo e criar consulta bem complexa antes da exportação;
• -f “FileGDB”: formato de saída, FileGDB;
• <CAMINHO_SAIDA.gdb>: caminho completo do FileGeodatabase de saída;
• as outras opções são de conexão ao banco de dados do PostgreSQL;
• lembrem-se, as variáveis estão listadas entre <>, que não devem aparecer na chamada;

Atualmente estamos usando esta solução para exportar dados para um ciente em FileGeodatabase, sem a necessidade de termos uma licença (bem cara) do ArcGIS Desktop (ou qual seja o nome que deram agora).

Uma outra boa notícia, é que estão desenvolvendo a Open FileGDB API. É uma implementação open-source, disponível também para a GDAL/OGR, mas que pelo momento é somente leitura. A API proprietária da ESRI suporta leitura e escrita.

Comentem no Facebook os exemplos de uso que vocês tem para a GDAL/OGR, uma ferramenta porreta.

Uma nova versão do QGIS foi lançada estes dias! A versão 2.4 conta com diversas funcionalidades novas e correções de bugs.

Acho incrível uma equipe com tão reduzida consiga manter um software de alta qualidade, com milhares de linhas de código e releases tão apertadas. Parabéns time QGIS!

A grande mudança do momento é a renderização multi-threaded! Antes o QGIS utilizava apenas um core do processador para renderizar os dados dos mapas. Agora ele utiliza vários. A funcionalidade, já saiu do modo beta e está em produção, mas ainda acredito que necessita de testes, principalmente em ambientes que utilizam bancos de dados.

Os tempos de renderização com a funcionalidade de multi-thread melhoraram bastante. Em testes simples com um cronômetro externo, medimos junto com a equipe os tempos em diversas áreas do projeto, em diversas escalas.

Em alguns pontos saímos de 5,9s para 3,92 – isto para a extensão total de um projeto, com milhares de objetos, em uma máquina quad-core com 4Gb de RAM. Não se esqueçam, as renderizações atuais dos softwares GIS não são aceleradas por GPUs (placas de vídeo, para facilitar). É uma melhora de (mais ou menos) 30%. Em outros casos a melhoria foi um pouco mais tímida, mas ainda assim, significante: de 2,83s para 1,61.

A única coisa que não consegui medir foi se o QGIS está onerando o banco mais que o necessário, mas acredito que não. Em nosso parque de máquinas, apenas um usuário conta com o 2.4, mas os outros devem migrar logo.

Novos renderizadores poligonais também foram incluídos, permitindo o uso de gradientes, internos e externos (lembram dos mapas da National Geographic?).

O changelog completo pode ser conferido aqui.

Mais uma vez, parabéns time QGIS!

Em nosso dia a dia, produzimos muitos dados cartográficos. A SIGMA, apesar de uma pequena empresa, tem contratos de grande volume para produção de dados vetoriais cartográficos, seja através de interpretação de imagens, seja através de técnicas de geoprocessamento.

Como trabalhamos basicamente com tecnologias livres, conseguimos automatizar um pouco o processo, facilitando a criação dos bancos de dados onde estes dados serão armazenados, como a geração de “projetos padrões” que são distribuídos para os colaboradores do projeto.

Para este fim, utilizamos muito SQL e scripts bash. Só para constar, nosso ambiente de produção cartográfica conta com:

• QGis 2.2 Valmiera;
• PostgreSQL 9.1 e PostGIS 2.0.1;
• Django 1.6;
• Tornado;

Os softwares dispensam muita apresentação, mas o QGis é nossa ferramenta default de geoprocessamento, sendo utilizada pelos gerentes e analistas para produção cartográfica, conectados diretamente no banco de dados PostgreSQL.

Com o Django, criamos uma aplicação Python que consulta diversos logs que geramos durante a digitalização dos dados e os publica com notificações do tipo push para um painel em tempo real, que fica em uma televisão na área de produção – onde todos os analistas e gerentes podem acompanhar o progresso do projeto, minuto a minuto.

Automatizamos diversas tarefas, dentro do escopo de cada projeto, mas basicamente as seguintes estão presentes para todos os projetos de produção:

• Validação topológica de dados poligonais (sobreposição e vazios);
• Validação de validade geométrica (somente para dados poligonais, afinal, apenas polígonos podem ser inválidos);
• Validação topológica de dados lineares, respeitando topologias do tipo arco-nó;
• Auditoria de transações;
• Instalação de novos bancos de dados;
• Realização de backups em nuvem;
• Acompanhamento de progresso;
• Relatórios de problemas cartográficos (tickets criados pelos gerentes e analistas, bem como quantos são resolvidos e criados diariamente);
• Exportação de dados do banco para shapefiles e File Geodatabases;

Para gerenciar tudo isto foi criado o Cartobash. É um repositório (ainda privado – sorry pessoal) no github que contém diversas stored procedures, scripts bash, projetos padrão e funcionalidades diversas para ajudar o gerente de cada projeto a administrá-lo.

Um exemplo legal, é a forma que utilizamos para construção de um novo banco de dados. O Cartobash, nos dá toda a infraestrutura básica, como usuários, permissões, esquemas personalizados, auditoria e tudo mais que é comum entre projetos. O que não é comum entre projetos, é fornecido através de um diretório, informado pelo usuário e o helper faz o restante.

./instalar_banco.sh localhost 5432 teste2 <usuario> <senha> <caminho_scripts_modelo> > ~/Desktop/log.txt

Esta linha de comando dispara a função de instalação do banco, gerando um log correspondete. O procedimento de instalação deixa a critério do usuário os modelos principais e auxiliares, bem como uma lista de camadas e suas validações a serem executadas. Todas as camadas poligonais já são marcadas por padrão para validações topológicas e as lineares são deixadas a cargo do usuário.

Além disso, a própria instalação agenda no crontab do usuário do banco de dados as tarefas periódicas de validação e backup, não sendo necessário refazer isto na mão.

Vocês devem estar se perguntando como exportamos para File Geodatabases no Linux. Bem, acontece que a ESRI lançou uma API para Linux que permite a criação, edição e leitura dos mesmos. A GDAL/OGR usa esta API e permite estas operações em softwares como QGis e demais.

Nossos script de exportação, através da OGR, consegue criar um modelo de geodatabase e o popula através da mesma linha de comando – facilitando ainda mais as entregas para os clientes.

Ficamos por aqui! Caso tenham dúvidas ou queiram saber mais, entrem em contato!

O repositório está disponível aqui: https://gitlab.sigmageosistemas.com.br/cartohelper/cartobash

Um abraço!