Tag dev

Olá pessoal, boa tarde!

Estamos prestando uma consultoria à um órgão governamental que possui um banco de dados em PostgreSQL bastante extenso. Uma de nossas tarefas era documentar o banco de dados todo, incluindo a criação de um dicionário de dados compreensivo, com informações sobre as tabelas, views, procedures, etc.

Como o banco é grande, possuindo muitos objetos, decidimos criar uma solução simples em Python que conecta-se ao banco de dados e utilizando um template, escreve o dicionário para nós, baseados nos comentários existentes para cada objeto.

No PostgreSQL, acredito que quase todos os objetos do banco possuem um campo de comentário, ou seja, ao invés da documentação ficar somente no papel, ela fica diretamente armazenada no campo de comentário de cada objeto, podendo ser consultada por quem já tem permissão aquele determinado objeto. É uma ideia simples, mas funcional.

Para inserir os comentários em lote, geramos um arquivo .yaml estruturado, onde as descrições podem ser preenchidas e posteriormente sincronizadas com o banco de dados. Outro utilitário, gera a documentação no formato de um template, podendo o mesmo ser customizado.

Ainda precisa de algumas mudanças e criação de testes para ficar um pouco mais modular, mas basicamente conseguimos ler todo o catálogo do PostgreSQL e gerar esta documentação em pouquíssimo tempo.

Outras funcionalidades veem a mente:

• Geração de diagramas de forma automatizada;
• Geração de relatórios de problemas comuns de banco de dados (ex: chave única em que é permitido valor nulo, etc);
• Refatoração do código para funcionar com outros bancos de dados;

O docgen foi um projeto interessante de ser feito. Todo escrito em Python e agilizou bastante nossa vida. Fiquem a vontade para conhecê-lo no Github.

Olá pessoal, boa tarde!

Implementamos recentemente uma nova funcionalidade no site da SIGMA – o chat. Através do chat é possível obter atendimento imediato para consultas técnicas e comerciais.

Estamos disponíveis com o chat durante todo o horário comercial, sendo que você ainda pode escolher com qual área quer falar: técnica, vendas, entre outras.

É uma pequena melhoria que visa engajar mais diretamente com nossos clientes. Atendimento rápido e fácil, aumentando o leque de opções que temos para melhor servi-lo.

Passe lá e nos dê um alô!

Abraços

Olá pessoal,

Existe um tremendo esforço atualmente para realizar a tradução da documentação do PostGIS. Anteriormente, este era um processo muito chato, que envolvia copiar arquivos, traduzir enormes parágrafos sem referências em um formato que não é muito familiar para muitas pessoas, o xml.

Em discussão com o time do PostGIS, conseguimos ajustar uma conta em um site especializado para isto, o Transifex. Dentro do Transifex, qualquer um pode criar uma conta pessoal ou de um projeto (nosso caso) e importar os arquivos brutos de documentação. O Transifex é inteligente, separando o que deve e o que não deve ser traduzido, permitindo a criação de múltiplas línguas “alvo” para a tradução.

Através dele, é possível administrar quais são os colaboradores, qual linguagem ele tem permissão para traduzir e estabelece processos formais de revisão, string por string.

Atualmente, temos as seguintes línguas e as porcentagens de tradução de cada uma:

• Inglês – 100% (original);
• Italiano – 36%;
• Francês – 28%;
• Espanhol – 26%;
• Português Brasil – 17%;
• Coreano – 6%;
• Polonês – 8%;

Existem ainda mais umas dez línguas, mas sem nenhuma tradução.

Precisamos aumentar a margem de tradução para o Português. Embora nós, aqui na SIGMA, tenhamos traduzido um pouco por dia, o esforço é muito grande.

Ajude-nos! Crie uma conta no Transifex e solicite um login na página de tradução do PostGIS. Logo que possível, autorizo a tradução e basta mandar brasa.

Lembro ainda, que ajudar na tradução da documentação é uma boa fonte de aprendizado, já que você acaba se obrigando a ler toda a documentação que for traduzir. Existem coisas que eu mesmo nem sabia que existiam que aprendi através da tradução direta dos documentos.

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.