Monthly Archive for Dezembro, 2008

GDAL: conversão entre formatos de imagem SIG

Publicado em 23 de Dezembro de 2008 em Inicial and Open Source. 2 Comments Tags: , .

Esta é a parte 2 de um conjunto de artigos sobre o GDAL, o kit de ferramentas para conversão de imagens SIG. Pode também ler aqui a parte 1 desta série.

Conversão de formatos

Uma das operações mais comuns efectuadas com o GDAL é a conversão entre formatos. Alguns exemplos:

  • Converter de TIFF para JPEG, com ou sem georreferenciação
  • Converter de GeoTIFF para TIFF+tfw, e vice-versa
  • Manter o formato TIFF mas alterar a compressão interna, para JPEG, LZW e outras
  • Converter um dos formato suportados para ECW, um formato geo-espacial extremamente comprimido e de rápido acesso (na parte 3 desta série são analisados os diversos formatos comprimidos suportados pelo GDAL)

Comando de conversão básico

Nestes artigos usamos o FWTools, um pacote de várias aplicações que inclui o GDAL e que é fácil de instalar e usar.

Para aceder aos comandos do GDAL, executamos FWTools Shell (disponível no desktop ou no menu Iniciar) para abrir a janela de comandos pré-configurada do GDAL. Nesta janela podemos executar os comandos do GDAL sem preocupações com a definição correcta da PATH e outras variáveis de ambiente.

Assim, na janela do FWTools Shell, para converter um ficheiro TIFF para um ficheiro JPEG usamos o seguinte comando:

gdal_translate -of JPEG imagem.tif imagem.jpg

A sintaxe básica é portanto:

  gdal_translate -of formato_de_saída imagem_de_entrada imagem_de_saída.

No nosso exemplo, um ficheiro TIFF de 28MB passou a um JPEG com 2,15MB. Ou seja, foi obtida uma compressão de 92%. Claro que a taxa de compressão variará com a própria imagem em causa…

Controlando o processo de conversão

Para controlar a conversão, o GDAL suporta parâmetros dedicados a cada formato, denominados “Creation Options”, ou “co”. Como cada formato tem as suas próprias opções, é necessário consultar a documentação de formatos no site do GDAL para saber que opções existem.

Por exemplo, no formato JPEG as opções de criação são actualmente:

  • WORLDFILE=YES: Cria um ficheiro de coordenadas separado com a extensão .wld (que podemos renomear para .jgw para usar em ArcView)
  • QUALITY=n: Indica o nível de compressão, entre 10-100, sendo 75 o valor por omissão. Quanto maior a qualidade, menor a taxa de compressão obtida. Não se traduz directamente numa taxa 0-100%, mas influencia-a directamente. 
  • PROGRESSIVE=ON: Especialmente indicado para imagens publicadas online porque os browsers são capazes de os mostrar progressivamente consoante as descarregam. Outras aplicações podem não conseguir ler estas imagens.

Assim, assumindo que o nosso TIFF tem coordenadas, para o converter para um JPEG, manter as coordenadas, e ainda obter uma taxa de compressão superior (indicando uma qualidade de 25), o comando seria o seguinte:

gdal_translate -of JPEG -co QUALITY=25 -co WORLDFILE=YES imagem.tif imagem.jpg

O ficheiro passaria a ter apenas 902KB… e seria criado um ficheiro com o mesmo nome da imagem mas com extensão .wld. Este ficheiro contém a informação de georreferenciação do JPEG. Para que o JPEG pudesse ser usado correctamente no ArcView bastaria alterar a extensão para .jgw.

Transformar GeoTIFF em TIFF

O formato GeoTIFF é uma variante TIFF que inclui a informação de georreferenciação no próprio ficheiro TIFF, e não num ficheiro externo. Por vezes é útil podermos exportar esta informação para um ficheiro separado, normalmente com a extensão .tfw.

O comando para converter um GeoTIFF para TIFF “básico”, e com um ficheiro .tfw com a georreferenciação é:

gdal_translate -of GTiff -co PROFILE=BASELINE -co TFW=YES imagem.tif imagem_saida.tif

O GDAL usa a mesma sigla GTiff para indicar o formato TIFF e GeoTIFF. Para ver todas as opções de criação para o formato TIFF pode consultar a página do formato TIFF do GDAL.

Comprimindo ficheiros TIFF

Uma das opções mais interessantes permitidas pelo GDAL é comprimir o ficheiro TIFF, mas mantendo-o nesse formato. As opções de compressão disponibilizadas pelo GDAL são: JPEG/LZW/PACKBITS/DEFLATE/CCITTRLE/CCITTFAX3/CCITTFAX4/NONE.

Ou seja, um ficheiro TIFF pode ter a imagem comprimida num destes esquemas de compressão. A compressão JPEG é a opção mais recente, com a melhor taxa de compressão, mas que degrada a imagem e não é suportada por algum software.

A compressão LZW por outro lado, é capaz de oferecer uma boa taxa de compressão (~10%) e sem perda de qualidade. Também pode haver problemas de compatibilidade, mas de forma menos frequente.

Nos primeiros testes que efectuei com a compressão LZW fiquei surpreendido, negativamente. Isto porque o tamanho da imagem aumentou!! Depois de descobrir que é possível ajudar o algoritmo de compressão indicando o tipo de imagem que estamos a comprimir (com a opção PREDICTOR), o resultado já foi o esperado.

Para converter um ficheiro TIFF para outro, mas comprimido com LZW, usamos o comando seguinte:

gdal_translate -of GTiff -co PROFILE=BASELINE -co TFW=YES-co COMPRESS=LZW -co PREDICTOR=2 imagem.tif imagem_saida.tif

A opção PREDICTOR=2 é indicada para imagens de cor real, 32 bit, como ortofotomapas.

Existe uma compressão melhor que LZW para o formato TIFF mas que dá mais problemas de compatibilidade: DEFLATE. Este é o método de compressão usada nos ficheiros .zip, e pode dar melhores resultados.

Comprimindo directorias

Por vezes, temos muito mais do que apenas um ficheiro para converter ou comprimir. Quando temos uma directoria cheia de ficheiros para converter, o que fazer?

É possível criar um pequeno script na forma de ficheiro .bat que aplica um comando GDAL a todos os ficheiros com determinada extensão numa directoria, e que ainda grava os resultados noutra directoria…

Um desses scripts poderia ser:

@echo off
for /R %1 %%I in (*.tif) do gdal_translate -of JPEG -co QUALITY=25 -co WORLDFILE=YES %%I %2\%%~nI.jpg
:END

Este script irá converter todos os ficheiros TIFF na directoria a indicar pelo utilizador, para ficheiros JPEG, colocando-os na directoria de destino indicada. Podemos alterar o comando GDAL, mantendo o restante texto intacto, para obter diferentes operações.

Para usar este script seria necessário criar um ficheiro com extensão .bat com o conteúdo indicado acima. E para o executar, bastaria usar numa Janela de Comandos o seguinte:

exemplo.bat directoria_com_tiffs directoria_destino

 

E é tudo por agora. No próximo artigo desta série serão analisados os formatos de compressão mais comuns.

Até lá, boas navegações.

Virtual Earth e SIG nos Municípios

Publicado em 11 de Dezembro de 2008 em Gestão. 0 Comments Tags: , .

No passado dia 4 (portanto este post já vem atrasado) assisti ao Microsoft Solutions Day dedicado ao Virtual Earth, e saí com a sensação de que realmente há algo muito forte em movimento na área de webgis. Uma das principais novidades que ouvi foi o anúncio da revisão ao protocolo entre o Estado Português e a Microsoft, que passou agora a incluir também as Câmaras Municipais no acordo, permitindo-lhes a utilização gratuita do Virtual Earth (exceptuando-se aplicações para fins comerciais: ie venda de algo). Em simultâneo, foi renovada a cobertura da imagem aérea, sendo agora baseada nos ortofotomapas de 2007 e com resolução de 50cm por pixel! Portugal fica assim com uma das melhores coberturas do mundo no VE!

O VE é como se sabe, muito resumidamente, um visualizador da informação geográfica da Microsoft (cartografia base e ortofotomapas) onde por meio de programação podemos sobrepôr a nossa própria informação no mapa. Não me vou alongar aqui na descrição técnica do VE e das suas capacidades, talvez noutro artigo… E outras empresas têm produtos semelhantes, sendo o mais notável o Google Earth e Maps (havendo outros).

Qual é a novidade?

A verdade é que já há muito tempo que os produtores tradicionais de software SIG comercializam produtos deste tipo para publicar e explorar informação geográfica usando um browser via Internet.

Então, qual é a novidade? Que impacto é que podem ter a Microsoft e a Google quando lançam também os seus visualizadores?

É que há 1 factor determinante e que faz uma diferença fracturante em relação ao que tinhamos antes, havendo depois uma miríade de outros factores que ajudam a criar um impacto cada vez maior: informação…

Informação de base e ortos para todo o mundo

Esta é a questão central - já não será necessário adquirir informação geográfica de base! (obviamente que nem sempre será verdade)

Imaginemos uma câmara municipal que decide implementar o seu SIG e começa a colocar as questões habituais:

- que hardware, que software, que técnicos, que informação, que procedimentos?

E qual é a questão mais cara? Isso mesmo - os dados.

Lançar concurso para aquisição de cartografia vectorial e de ortofotomapas para todo o concelho pode custar de dezenas a centenas de milhares de euros, é moroso, complexo, e arriscado. Frequentemente não se consegue obter um produto de qualidade. E depois? Depois continuam as dificuldades: onde armazenar essa informação, como manipulá-la correctamente, como torná-la útil? Quem sabe fazê-lo?

Agora, eliminem-se todas essas questões de uma só pernada: Ao usar uma aplicação baseada em VE, a câmara recebe uma aplicação web que além de ter um aspecto gráfico profissional ainda mostra uma cartografia extraordinária, com nomes de rua actualizados e ortofotomapas de alta resolução. E para terminar o preço é 0! Isso mesmo, zero, nada, zilch!

Hmmm… decisão difícil …

(Atenção que para quem não está incluído no protocolo referido podem existir custos de licenciamento. Há que investigar se somos ou não abrangidos pela licença gratuita do produto que escolhermos.)

Mas não existem grandes limitações e problemas?

É verdade que existem problemas a resolver. Esta abordagem não é uma panaceia para todas as situações. É antes uma nova abordagem a integrar com as já existentes. Há que saber conviver com ela da melhor forma. Por exemplo, é necessário fazer a ligação entre o visualizador e a nossa própria informação. E isso só se faz recorrendo a programação. Simples ou complicada, é sempre necessária. As funções que necessitamos incluir no visualizador e que não venham incluídas de raíz, têm também de ser desenvolvidas à medida. Outro facto incontornável.

Também a impressão é mais difícil. Existem limitações técnicas que é preciso saber rodear, e aprender a aceitar compromissos: se não é possível imprimir tal como se gostaria, então até onde é possível chegar? E isso será suficiente para o meu caso? Eu diria que 90% frequentemente as necessidades de impressão podem ser satisfeitas utilizando visualizadores como o VE. E mais, em aplicações webgis a tarefa de impressão é geralmente muito simplificada.

E se a Microsoft decidir acabar com o VE? Ou começar a cobrar fortunas? Esta é uma questão que não me parece especialmente pertinente. Enquanto nos preocupamos com uma possibilidade mais ou menos remota, desperdiçamos uma boa oportunidade. Se e quando esta situação ocorrer, já teremos usufruido deste sistema durante os anos em que a plataforma esteve activa. Por outro lado, é discutível que todo o software incorre em riscos semelhantes…

Como interligar com a nossa informação?

O que torna um visualizador especialmente útil para cada organização será a sua capacidade de integração com a “nossa” informação geográfica. Existem 2 formas de colocarmos a nossa informação no VE: como imagens ou como vectores.

Para publicar a nossa informação como imagens, é necessário criar uma aplicação que é responsável por ler os nossos dados e criar imagens de mapas com a simbologia que desejamos, sempre de acordo com as regras do VE. Estas imagens são depois sobrepostas à informação do VE usando transparências. Uma pesquisa no Google revela milhares de resultados com exemplos de código para todos os gostos.

Para publicar a informação como vectores, é também necessário criar uma aplicação, mas que converte a nossa informação para um formato aceite pelo VE. Actualmente são aceites os formatos KML, GPX, e o formato próprio do VE.

Aqui também existem problemas para os quais é preciso ajustar a nossa perspectiva… Estes visualizadores usam as capacidades do browser para literalmente desenhar vértice-a-vértice a nossa informação vectorial. E os browsers não oferecem grande performance neste aspecto. Se quisermos representar algumas dezenas de pontos não há problema. Mas se quisermos visualizar o PDM? Ou o cadastro? Ou a rede de águas? Consoante aumenta o número de vértices a desenhar também o desempenho do browser diminui, até ficar inoperante. Podemos optar pela publicação por imagens, mas isso implica perder a interactividade que os vectores oferecem – e.g. colocar o rato sobre um polígono e obter informação adicional. Como sempre, existem soluções também para esta situação (aglomeração, tiles de vectores, generalização, clipping, escalonamento por escalas), e temos que saber explorá-las de forma a obtermos um resultado satisfatório.

Qual o papel do software SIG tradicional?

Uma das discussões que têm surgido frequentemente é sobre o papel das empresas que actuam no mercado de software SIG – ESRI, Intergraph, Autodesk…

Não penso que terão o futuro ameaçado, antes pelo contrário. Acredito que o Virtual Earth e restantes visualizadores vieram abrir novas oportunidades a estas empresas, embora tenham também provocado um enorme aumento de concorrência por parte do sector informático genérico (não SIG).

Isto é, se uma organização pretender implementar uma solução VE, irá procurar quem ofereça esse serviço. E poderá optar não só por uma empresa SIG, mas também por qualquer parceiro Microsoft especializado em Virtual Earth. Confesso que neste aspecto sou tendencioso: acredito que uma empresa SIG oferece vantagens acrescidas, pela experiência e conhecimentos alargados na área – tem contexto!

Ao nível do software também as empresas SIG não ficaram paradas. Uma após outra incluíram nos seus produtos capacidades de integração com as plataformas geográficas dos gigantes Google e Microsoft. Todos lêem o formato KML, que hoje é praticamente o formato universal aceite por todas as plataformas, e alguns conseguem até converter para este formato. Faltará ainda uma boa capacidade de criação e edição de KML… mas lá chegarão.

E recentemente os produtos de servidor começaram a oferecer capacidades de integração com o VE e Google Maps/Earth. Ou seja, em vez de programar aplicações de integração, hoje apenas temos que configurar a forma como queremos publicar a nossa informação para estes visualizadores. E tudo dinamicamente: Se editarmos a nossa informação, ela aparecerá editada no VE. Um exemplo: praticamente todos estes produtos publicam KML directamente a partir dos nossos dados: ArcGIS Server da ESRI, MapGuide da Autodesk, e os principais produtos Open Source – MapServer (por enquanto via plugin), GeoServer, e MapGuide Open Source.

A tendência é assim de alargar a caixa de ferramentas que os técnicos SIG utilizam – o VE e semelhantes são mais uma ferramenta que devemos integrar na nossa actividade profissional.

Conclusão

Assistimos actualmente à trivialização da publicação de informação geográfica para as plataformas de serviços geográficos. E esta capacidade é já um factor diferenciador dos produtos. Quem oferece mais integração, e maior facilidade, tem o melhor produto. Quanto mais estas capacidades aumentam, menor é a necessidade de programar esta interligação tornando-a cada vez mais acessível.

Claro que um departamento SIG que produz cartografia temática de alguma especificidade, executa análises geográficas, e edita informação frequentemente, não pode ser substituído por uma aplicação deste tipo… Um departamento com conhecimento técnico especializado, experiência profissional, e capacidade de execução, não pode ser comparado com uma aplicação webgis.

Nos locais em que não existe uma equipa especializada, e com poucos recursos, a utilização do VE ou GE/GMaps é uma solução rápida e barata para implementar soluções SIG na web. E onde já existe esta equipa, ainda melhor – poderá potenciar a sua utilização em diversas soluções focadas em questões específicas.

Mãos à obra!

GDAL: Introdução a gestão de imagens georreferenciadas

Publicado em 5 de Dezembro de 2008 em Inicial. 2 Comments Tags: , .
Este é a 1ª parte de uma série de artigos que pretendo escrever sobre as ferramentas incluídas no GDAL: Geospatial Data Abstraction Library.
O GDAL (www.gdal.org) é o canivete suíço para conversão de imagens georreferenciadas, constituído por um conjunto de ferramentas usadas numa janela de Linha de Comandos (ou seja, sem interface gráfica). Mas o pacote de instalação mais popular para Windows, o FWTools, inclui também um visualizador/conversor com interface gráfica (OpenEV). O GDAL é usado em vários produtos Open Source e em vários produtos Closed Source, como o ArcGIS. Há ainda o irmão OGR para o universo de dados vectoriais, e que suporta também uma grande variedade de formatos e operações.
O autor principal e original (porque hoje são vários os autores que contribuem código) é o Frank Warmerdam, um pioneiro em Open Source para a área SIG, e que foi até recentemente o 1º Presidente eleito da OSGeo.

O que consegue o GDAL fazer?

O GDAL faz muito mais do que converter imagens. Em resumo, se tivesse de escolher um TOP 10, estas seriam as funções do GDAL que eu escolheria:

  1. Listar informação sobre uma imagem (sistema de coordenadas, resolução, sistema de coordenadas, e mais)
  2. Conversão entre 95 formatos (entre eles JPEG, GeoTIFF, ECW, JPEG2000)
  3. Reprojecção de imagens
  4. Criação de pirâmides (overviews) para visualização rápida de imagens de grande volume (“pesadas”) em MapServer
  5. Criação de índices de imagens, ou mais conhecidos por catálogos de imagens, também para utilização em MapServer (mas não só)
  6. Converter imagens 24bit para 8bit e vice-versa
  7. Criar um mosaico de imagens georreferenciadas, ou seja, criar uma imagem única que é o resultado da junção das imagens originais
  8. Transformação de uma lista de coordenadas entre 2 sistemas de coordenadas diferentes
  9. Criação – a partir de uma imagem – de uma estrutura de directorias com tiles para visualização em OpenLayers e Google Maps, com criação de pequenos visualizadores web já prontos a usar
  10. Criação de uma matriz (grid) a partir de um conjunto de pontos por interpolação espacial, usando diferentes métodos de interpolação

… e a lista não termina aqui…

Instalação

Bem, a instalação do GDAL é extremamente simples. Basta obter a última versão no sítio do FWTools, e descarregar a versão para Windows ou Linux. Usarei a versão Windows para todos os exemplos, porque trabalho geralmente com este SO. A versão para Windows é um instalador normal (.exe), bastando executá-lo para iniciar a instalação.

Durante a instalação podemos seguir com as opções pré-definidas. A instalação é muito rápida e no final, teremos um novo ícone no Ambiente de Trabalho chamado “FWTools Shell”. Este atalho abre uma janela de Linha de Comandos já configurada para usarmos os comandos do GDAL. Numa janela de Linha de Comandos normal (aberta executando o comando cmd.exe por exemplo) os comandos do GDAL não serão executados porque a PATH não estará correctamente definida (além de outras variáveis de ambiente) .

Primeiros comandos GDAL

Se leu este artigo até aqui, merece começar já a teclar comandos e ver resultados do seu esforço!

Por exemplo, para ver as características geográficas de uma imagem qualquer no disco, basta teclar o seguinte comando na janela do FWTools:

gdalinfo c:\directoria_de_exemplo\imagem.tif

Substitua o caminho e nome da imagem por dados reais que tenha no seu computador. No meu caso, o output foi o seguinte:

Driver: JP2ECW/ERMapper JPEG2000
Files: 0441A1Argbx.jp2
0441A1Argbx.jp2.aux.xml
Size is 8000, 10000
Coordinate System is:
LOCAL_CS["unnamed",
UNIT["unknown",1]]
Origin = (80000.000000000000000,-100000.000000000000000)
Pixel Size = (0.500000000000000,-0.500000000000000)
Metadata:
TIFFTAG_XRESOLUTION=1
TIFFTAG_YRESOLUTION=1
TIFFTAG_RESOLUTIONUNIT=2 (pixels/inch)
Corner Coordinates:
Upper Left  (   80000.000, -100000.000)
Lower Left  (   80000.000, -105000.000)
Upper Right (   84000.000, -100000.000)
Lower Right (   84000.000, -105000.000)
Center      (   82000.000, -102500.000)
Band 1 Block=8000x1 Type=Byte, ColorInterp=Red
Overviews: arbitrary
Band 2 Block=8000x1 Type=Byte, ColorInterp=Green
Overviews: arbitrary
Band 3 Block=8000x1 Type=Byte, ColorInterp=Blue
Overviews: arbitrary

Olhando para esta informação podemos facilmente obter a resolução da imagem (0,5m por pixel), as coordenadas da extensão da imagem (de 80000, -105000 a 84000, -100000) e do seu centro (82000, -102500), n.º de colunas (10000) e linhas (8000), e o sistema de coordenadas que nesta imagem não se encontra caracterizado e por isso o GDAL não o identifica.

Outro comando rápido é obter a lista de formatos que a versão instalada reconhece, isto porque dependendo da versão podemos ter mais ou menos formatos reconhecidos.

gdalinfo --formats

Por agora ficamos por aqui. Em breve, continuarei esta série de artigos com exemplos de transformação entre formatos de imagem, com descrição de alguns dos formatos mais interessantes – TIFF, JPEG, JPEG2000 e ECW.

Até breve!