Todos os artigos de duarte

GDAL Como criar ficheiros tfw

Inicial, Open Source, SIG,
Tempo de leitura: < 1 min

Uma nota rápida sobre criar ficheiros de georreferenciação .tfw a partir de ficheiros GeoTiff.

As imagens GeoTIFF são ficheiros TIFF que contém a georreferenciação na própria imagem e por isso não são acompanhados pelo ficheiro .tfw, que é apenas um ficheiro de texto indicando as coordenadas da imagem.

Existem momentos em que queremos ter os TIFF acompanhados dos ficheiros tfw, seja porque o programa que vamos usar o exige ou porque a aplicação que estamos a desenvolver só consegue ler as coordenadas num ficheiro de texto, ou por outra razão qualquer…

A questão é saber: existe alguma forma rápida de obter o ficheiro tfw??

Claro. Basta usar um comando que vem incluído na distribuição FWTools e no MS4W (que inclui o GDAL), e que se chama listgeo.

Ao executar o listgeo numa janela FWTools, recebemos de volta a apresentação da sintaxe:
C:\Program Files\FWTools2.2.6>listgeo
Usage: listgeo [-d] [-tfw] [-proj4] [-no_norm] [-t tabledir] filename

-d: report lat/long corners in decimal degrees instead of DMS.
-tfw: Generate a .tfw (ESRI TIFF World) file for the target file.
-proj4: Report PROJ.4 equivelent projection definition.
-no_norm: Don't report 'normalized' parameter values.
filename: Name of the GeoTIFF file to report on.
Assim, para criar o .tfw de uma imagem podemos usar um comando como o seguinte:
listgeo -tfw 26501500.tif
E ficamos com o .tfw criado.
Dubium sapientiae initium.

Desenvolver aplicações SIG de forma Agile!

Avançado, Gestão, SIG,
Tempo de leitura: 4 min

Estou a digerir tudo o que vi na formação de 3 dias sobre metodologias Agile e Scrum e este post servirá como bloco de notas.

Esta semana estive 3 dias em formação com o excelente formador Mitch Lacey. Este sr. tem já uma grande experiência em projectos de desenvolvimento de software, e ouvi-lo foi realmente uma experiência enriquecedora.

Não vou entrar em grandes detalhes teóricos sobre Agile/Scrum, porque não sou definitavemente a pessoa indicada para o fazer. Vou em vez disso enumerar os pontos que mais me impressionaram e que mais valor terão se os integrar na forma como a “minha” equipa funciona. Portanto, as afirmações seguintes devem ser encaradas como uma perspectiva muito pessoal…

Agile é um conjunto de práticas que visam desenvolver um projecto de forma iteractiva, com ciclos curtos entre versões intermédias antes de chegar à entrega final, com vista a reduzir os riscos associados a este tipo de projectos – sendo o maior entregar um produto que não se ajusta à visão do cliente!

Scrum é a metodologia Agile mais difundida, e obteve o seu nome do Rugby: scrum é a altura em que os jogadores se reunem para reiniciar o jogo, e ambas as equipas disputam a bola. Em Agile, Scrum é um método em que uma equipa de desenvolvimento se concentra ferozmente em terminar um conjunto de tarefas num prazo curto – tipicamente 14 ou 28 dias – e se compromete a no final do prazo produzir uma versão funcional do produto que está a desenvolver.

Qual é a grande diferença em relação ao processo tradicional (designado “Waterfall” ou “em Cascata“)? É que no processo Waterfall, os requisitos para a aplicação a desenvolver são definidos à partida, na fase de levantamento e definição dos mesmos. Em seguida, esta lista de especificações é trabalhada com o cliente final, e atinge-se um acordo, sendo fechada a lista de itens a implementar. E é aqui que este método tem a sua maior fraqueza: é pouco flexível, e não considera facilmente requisitos que se alteram com o tempo (alguém se identifica com esta experiência??). A analogia de construir uma casa é muito clarificadora: ao olhar para a planta da minha futura casa, posso ficar muito satisfeito com o que está planeado. Mas, mais tarde, ao andar pela estrutura já construída da casa, vou conseguir obter uma visão mais clara do que estava na planta, e consequentemente vou definir melhoramentos e até novas funções que quero ter na versão final da casa. Isto é um processo natural e não deve ser combatido. E é o que os métodos Agile nos oferecem: ao cliente final permite algum controlo durante a vida do projecto, e à equipa de desenvolvimento permite um grande poder de adaptação à mudança, permitindo concluir o projecto dentro do prazo e do orçamento, mesmo absorvendo alterações aos pressupostos iniciais. E para descansar os espíritos mais desconfiados, resta acrescentar que esta metodologia é reconhecida pelo PMI, e é usada pelas maiores empresas de software como Microsoft ou IBM.

Porque é que estas técnicas me interessaram? Os pontos mais importantes:

  • A equipa de desenvolvimento com que trabalho é pequena – podemos contar com 2,5 técnicos (sim, temos realmente uma metade de técnico!), e somos facilmente dispersados por várias solicitações em simultâneo
  • O meio onde nos inserimos é muito dinâmico – as alterações aos requisitos são muito frequentes, e a sua definição inicial é muito difícil de obter e estabilizar
  • Trabalhamos para o “Cliente Interno”, onde as relações informais dominam, e os processos formais inerentes ao método Waterfall dificilmente são aplicados e respeitados

Da abordagem Scrum, estes são os pontos que mais me agradam e que vejo possibilidade de implementar rapidamente:

  1. Definir o “Product Backlog”, que mais não é que uma lista de funções a implementar numa aplicação, ordenada por prioridade
  2. Definir o “Sprint Backlog”, que é a lista prioritizada de funções que vamos implementar no próximo ciclo de 14 dias (o sprint)
  3. Reuniões relâmpago diárias, onde rapidamente (15 min.) cada um dos elementos da equipa percorre estes 3 pontos – o que concretizaste ontem, o que vais fazer hoje, e tens algum ponto crítico?
  4. Estar atento a solicitações de alterações ou novas funções, mas lutar por integrá-las no Product Backlog, que poderá ser re-prioritizado todas as semanas (mas as funções só podem entrar num sprint no seu início)
  5. Consciencializar todos os elementos da equipa de que todos são responsáveis pela equipa! Todos se devem preocupar com a saúde emocional da equipa e com a concretização dos compromissos assumidos com o exterior (notem aqui a grande diferença mental entre cumprir objectivos e cumprir compromissos)
  6. Obter uma versão funcional no final de cada Sprint! E demonstrá-la. Na teoria Scrum, a demo deve ser feita ao cliente. No meu caso, parece-me mais plausível realizar uma demo interna à equipa, para validar a direcção dada ao projecto, detectar incongruências, enfim, andar pela estrutura da casa e ver se é como imaginámos quando fizemos a planta…

É realmente uma forma de trabalhar muito aliciante, e que de alguma forma torna o desenvolvimento de projectos mais humano.

Algumas ferramentas consideradas essenciais a uma boa prática Agile já utilizamos na equipa:

  • Repositório de código e Controle de versões – usamos o SVN, e o AnkhSVN para integrar com o Visual Studio. Não há checkin de código que não compile. Este é um passo fundamental na organização da equipa!
  • Documentação – embora não tenhamos ainda a prática de documentação automática do código, embora já se tenha discutido o assunto várias vezes, usamos um Wiki para documentar quer a vertente técnica quer a vertente de utilização das aplicações

E das peças que nos faltam, o que podemos integrar no nosso caso particular?

  • Teste unitários – é algo que deveremos implementar, mas que está ainda algo longíquo de ser possível… é necessário primeiro re-organizar o código em componentes suficientemente pequenos, modulares, para possibilitar esta técnica. Mas os ganhos são óbvios – rapidez de efectuar testes e na detecção de bugs
  • Test Driven Development – ver ponto anterior, é algo desejável, mas cuja execução obriga a remodelar o repositório de código existente. Talvez a longo prazo seja possível…

Para mais informação recomendo vivamente a leitura deste artigo: “Agile Project Management for GIS“. Muitos mais podem ser encontrados “googlando” a Internet (como por exemplo este na revista PM Network, pp 42). E para aqueles que ficarem convencidos, fica a referência do curso – Fullsix.

Planeta SIG – notícias RSS num só local

SIG
Tempo de leitura: 3 min

Durante o fim de 2008 e início de 2009 decidi criar um agregador de notícias RSS sobre SIG em português. Podem encontrá-lo aqui:

htpp://planetasig.viasig.com

Como usar

A forma mais simples de usar um Planeta é consultar o site directamente no browser e ver as notícias que aparecem. As mais recentes são colocadas no topo da página, e no caso do Planeta SIG aparecem divididas por dia.

A forma mais prática de usar um Planeta é recorrer a um leitor de feeds RSS, ou seja, um leitor de notícias (RSS Reader). Eu uso o leitor do Google Desktop e que se vê na barra lateral. Mas existem várias opções, e para todos os gostos. Quem usa o Vista tem um leitor de RSS que pode incluir na barra lateral. Tem só de acrescentar o endereço RSS do Planeta SIG que é:

http://feeds.feedburner.com/PlanetaSig

Selecção de Conteúdos

Ao pesquisar a blogosfera por conteúdos interessantes para incluir no cheguei à penosa conclusão de que existe muito pouco conteúdo sobre SIG em português. E assim para tornar tudo mais interessante alarguei o âmbito para incluir também conteúdos que possam ser interessantes a leitores portugueses, excluindo claro a blogosfera não lusofona (inglês principalmente – para isso basta visitar o Planet Geospatial). Esta decisão permitiu incluir vários conteúdos brasileiros. Depois pensei ainda que a comunidade PT se interessa muito pelo que os nossos vizinhos espanhóis vão fazendo, principalmente nas áreas Open Source, e de publicação de dados. E assim incluí também feeds em língua espanhola. A lista actualizada dos conteúdos coleccionados pode ser vista na página do Planeta SIG à direita.

A lista não está fechada, e procuro activamente blogs e sítios de notícias que possam interessar à comunidade geo-espacial portuguesa (ou já agora lusófona). Se tiverem uma sugestão, por favor deixem um comentário.

As única regras para inclusão de conteúdos são:

  1. ser sobre SIG e afins
  2. blog estar activo
  3. ser relevante para a comunidade pt (pode ser espanhol, brasileiro, etc., mas não inglês, francês, etc.)
  4. e uma 4ª regra: não há blogs de empresas…

Tecnologia

Depois de pesquisar as opções existentes para criar agregadores RSS, acabei por seguir as indicações do James Fee, que mantém o Planet Geospatial, e do Chris Schmidt (pioneiro do OpenLayers). A OSGeo seguiu as indicações destes 2 srs. e usou o software Venus para criar o planeta sobre a blogoesfera da área SIG Open Source – PlanetOSGeo. E eu, humildemente, segui o mesmo conselho.

O Venus é baseado em Python, linguagem que o meu fornecedor de presença Internet (hosting provider) suporta. Mas não se encontra traduzido em Português, e assim as datas, títulos, separadores, e outros textos estão em inglês.

O Venus lê um ficheiro de configuração que inclui a lista de endereços de notícias RSS a consultar, e compila uma página HTML com todas essas notícias, separadas por dia e por sítio. A própria página é desenhada de acordo com um modelo (template), que podemos alterar. Por isso, traduzir todos os textos de inglês para português foi fácil – excepto as datas! Porque as datas são criadas pelos módulos de Python e por omissão são construídas em inglês – e isto inclui o nome dos meses e dos dias da semana. Não se pode controlar através do template.

Depois de analisar os ficheiros do Venus, descobri que alterando o ficheiro config.py, indicando que se devem seguir as definições regionais de portugal, conseguia datas em português. Assim ficou tudo resolvido, fazendo as seguintes alterações ao ficheiro:

alterada a linha 29:

import os, sys, re, urllib, locale

adicionada a linha 33:

locale.setlocale(locale.LC_ALL,'pt_PT')

E bastou estas pequenas alterações para ter todo o Planeta SIG em PT.

Uma última nota: em Vista, o locale acima não é reconhecido. Devemos usar ‘Portuguese_Portugal.1252’.

Actualização das notícias

A actualização é feita automaticamente, através de um comando PHP executado por um pedido web, e recorrendo ao serviço gratuito WebSchedule da ArtCava (que equivale ao comando cron do Linux e às “Tarefas Agendadas” do Windows).

Parametrizei a actualização para ser feita a cada 1h, mas suspeito que este período não está a ser cumprido… talvez seja mais de 4h em 4h.

Crise chega aos SIG v2

Gestão
Tempo de leitura: < 1 min

Os municípios nos EUA (na realidade os “Mayors”) compilaram uma lista de investimentos preparados para avançar caso sejam financiados pelo governo federal, com o objectivo de estimular a “Economia Real”.

Matt Ball, do blog Spatial Sustain analisou a lista e concluiu que existem projectos SIG no valor total de 31 milhões de dólares. O total de investimentos ronda os 47 biliões de dólares. A grande maioria dos projectos SIG são na área de Estradas e Segurança/Protecção Civil.

A minha reacção inicial foi de contentamento ao ver que a área geo-espacial recebeu uma atenção merecida! Mas ao reflectir melhor, se as contas apresentadas estiverem correctas, a fatia de investimento em SIG representa 0,066% do total! Ouch…

Mesmo assim, a lista de projectos SIG que o Matt mostra no seu artigo ilustra exemplos de aplicações SIG bem aliciantes: sistemas SIG para estradas (400.000$), localização de infra-estruturas construídas (750.000$), construção de um SIG regional (450.000$), sistema SIG de águas e saneamento (2.700.000$)…

Visto assim, com valores individuais, já começa a impressionar: apenas um destes projectos, mesmo o mais pequeno, financiava por alguns anos qualquer das nossas empresas nacionais.

Crise chega aos SIG?

Gestão,
Tempo de leitura: < 1 min

Aparentemente, a crise económica mundial está a ter os seus efeitos nas empresas de software SIG e CAD…

Hoje a Autodesk anunciou o despedimento de 10% da sua força laboral a nível mundial, reduzindo 750 postos de trabalho, e em simultâneo irá re-estruturar a orgânica da empresa.

Por seu lado, ontém a Intergraph também anunciou despedimentos e respectiva re-estruturação… irá despedir 5% da sua força laboral, cerca de 200 postos de trabalho.

A Google, que tem vindo a eliminar vários produtos do seu vasto portfolio, cortou agora o Dodgeball, um site que liga redes sociais à localização, através dos telemóveis (apenas nos EUA). E também anunciou que irá eliminar 100 postos de trabalho… na área de recrutamento (curioso). É uma sequência lógica ao anúncio anterior de abrandamento no recrutamento.

A ESRI (EUA) não anunciou intenções de despedir colaboradores. Mas tem surgido nas notícias de forma mais original: ao promover uma iniciativa para combater a crise nos EUA por meio da criação de um SIG Nacional, que custaria  1,2 biliões de dólares aos contribuintes norte americanos. Há um pdf a circular com a assinatura de Jack Dagermond, presidente e proprietário da ESRI, e de Anne Hale Miglarese e Booz Allen Hamilton, cuja afiliação desconheço.

Esta iniciativa, claro está, tem provocado uma polémica agradável na geo-esfera. Embora a ideia de um SIG nacional me pareça sensata em termos gerais, tenho de concordar que os números são pouco realistas: um cadastro para os EUA por 200 milhões?? O “nosso” pequenino SiNErGIC tem um custo anunciado de 450 350 milhões de Euros. Alguém fez mal as contas…

Falta agora sabermos o que se passa em Portugal. Quais os resultados para 2008 que as empresas portuguesas irão apresentar? Notar-se-ão já as dificuldades, ou ficará para as contas de 2009?

GDAL: Formatos Comprimidos

Intermédio, Open Source
Tempo de leitura: 5 min

Esta é a parte 3 de uma série de artigos sobre o GDAL, o kit de ferramentas para conversão de imagens SIG. Pode também ler aqui as outras partes da série: parte 1, parte 2.

Principais Formatos

Os formatos geo-espaciais comprimidos mais comuns são: JPEG, JPEG2000, ECW e MrSID.

O formato TIFF foi já tratado na 2ª parte da série, e sabemos que este formato tem uma série de opções de compressão, incluindo compressão JPEG.

Estes formatos podem dividir-se em 2 grupos: JPEG por um lado, e os restantes por outro. O formato JPEG é sobejamente conhecido da fotografia digital e do mundo dos computadores em geral. O grau de compressão de uma imagem em JPEG depende da escolha do utilizador, e quanto maior for mais a imagem é degradada. Uma taxa de compressão 1:10 é comum, apresentando degradação pouco perceptível. Uma taxa de 1:100 resultará num ficheiro muito menor mas com grande degradação. Além disso, imagens de grande dimensão tornam-se lentas de visualizar, ocupando muita memória. Para usar este formato em SIG é necessário um ficheiro adicional contendo as coordenadas reais da imagem, geralmente com a extensão .jgw. Outra limitação prende-se com a necessidade de criar as pirâmides (overviews) em ficheiros separados, se quisermos optimizar a visualização de grandes imagens.

Os formatos JPEG2000, ECW e MrSID usam algoritmos de compressão denominados “wavelet”, e proporcionam taxas de compressão tipicamente entre 1:10 e 1:100, incluêm pirâmides no próprio ficheiro, e ainda metadados sobre a imagem. A grande facilidade com que são usadas em software SIG aliada às enormes taxas de compressão que proporcionam justificam a sua adopção. Um único ficheiro inclui toda a informação de que necessitamos: a imagem original, as pirâmides, a georreferenciação, e o sistema de coordenadas.

Outras vantagens deste grupo de formatos são: grande compatibilidade com o software mais usado, possibilidade de compressão sem degradação perceptível a taxas de compressão elevadas, boas velocidades de visualização (excepto o JPEG2000 como veremos a seguir).

Comparação entre formatos

Para comparar os vários formatos comprimi um ortofotomapa com 465MB usando o GDAL. Na altura, o teste serviu para definir qual a melhor opção para integrar um catálogo de imagens numa arquitectura ESRI, ou seja, para visualizar em ArcGIS e ArcIMS, na versão 9.2. Entretanto, tentarei actualizar a tabela com resultados para gvSIG e para MapServer. Se alguém quiser contribuir por favor deixe as suas conclusões nos comentários.

Formato Compressão Taxa
%		 Taxa c/ Pirâmides ArcGIS ArcIMS gvSIG MapServer
TIF LZW 22,3 -3,3 ok ok ND ND
TIF DEFLATE 31,5 8,94 X ND ND ND
TIF PACKBITS -0,79 -34 ok ND ND ND
JPEG QUALITY=25 97,7 64 sofrível sofrível ND ND
ECW TARGET=80 86,6 86,6 ok n** ND ND
JP2 TARGET=80 80,8 80,8 lento lento ND ND
MrSID COMPRESSION=20 94,7 94,7 ok ok ND ND

**É possível publicar imagens ECW em serviços de imagem (baseados em AXL se o ArcGIS estiver instalado na mesma máquina. Mas o licenciamento não cobre esta abordagem…

Como se pode ver, em TIFF a melhor compressão é DEFLATE, mas como indicado na parte 1, é uma opção pouco compatível. Quem puder usar esta opção fica no entanto bem servido, com imagens não degradadas e poupando mais de 30% de espaço. Considerando a criação de pirâmides com o mesmo formato, poupamos ainda assim cerca de 9% de espaço.

Quanto ao JPEG, obtém-se uma óptima compressão de 98% quando usamos a opção QUALITY=25, embora a qualidade já seja afectada. Mas o pior, pelo menos em ArcGIS e ArcIMS, é a velocidade de visualização que fica realmente muito lenta. Se considerarmos a criação de pirâmides externas ao ficheiro, o espaço poupado em disco cai para 64%.

Quanto aos 3 formatos mais modernos, ECW, JP2 e MrSID, o campeão de compressão é o MrSID com quase 95% de espaço poupado! E isto já com pirâmides incluídas no ficheiro. Os outros 2 formatos ficam muitos próximos, com 81% para o JPEG2000 e 87% para o ECW.

Conclusões do Teste

O problema do formato MrSID é que não existe uma licença gratuita de compressão… por este facto, encontram-se frequentemente relatos em blogs sobre conversões a partir de MrSID para outros formatos, para efectuar alguma manipulação, e depois recompressão para um formato mais barato, como ECW ou JPEG2000. Aliás, nem a descompressão de MrSID usando o GDAL é legal sem uma licença adquirida. Pode-se no entanto descarregar uma ferramenta para esse efeito no site da LizardTech, empresa proprietária do formato. A seu favor, o formato MrSID tem a melhor taxa de compressão conseguida neste ensaio, e uma grande compatibilidade com o software existente, além de uma excelente rapidez de visualização.

Assim, excluindo o formato MrSID por questões de preço, ficamos com as opções ECW e JP2 para criar o nosso catálogo de imagens comprimidas (nesta situação para usar em ArcGIS e ArcIMS).

O ECW é um formato comercial concorrente do MrSID, lançado pela ER Mapper (empresa que comercializa o produto com o mesmo nome e recentemente adquirida pela ERDAS). Este é um formato que me agrada muito, já que tem as vantagens do MrSID e ainda disponibiliza  uma licença gratuita para compressão de imagens até 500MB. Este limite chega para podermos comprimir a grande maioria das imagens que se usam no dia-a-dia num departamento SIG. A única desvantagem que encontro é que o ArcIMS não lê imagens ECW a não ser através de projectos ArcMap (ficheiros *.mxd). E eu evito esta abordagem por questões de performance. Mas uma vez que o mundo ESRI se encontra todo a migrar para ArcGIS Server, que só usa ficheiros mxd, este problema começa a pertencer ao passado.

E quanto a JPEG2000? Este é um formato não proprietário, ou seja, sem limitações de uso. Por isso, seria o candidato ideal, certo? Bem, o problema é que a visualização é demasiado lenta para poder ser uma melhor opção que o ECW. Assim, a não ser que tenha imagens com mais de 500MB, ou o seu software favorito se comporte bem com JPEG2000, eu diria que ECW é o melhor formato comprimido de imagens georreferenciadas.

Compressão não-degradante (lossless)

Outro cenário interessante é saber como criar imagens muito comprimidas mas sem perda de qualidade. Ou seja, comprimir o mais possível as imagens originais, por exemplo para arquivar em DVD, e ainda assim manter a capacidade de ao descomprimir obter as imagens originais inalteradas. Como o formato ECW não suporta esta operação, restam só 2 dos formatos mais comprimidos – MrSID e JPEG2000. Como o MrSID tem de ser adquirido, fica apenas o JPEG2000. Na tabela encontram as taxas de compressão sem degradação para cada formato, e ainda para o TIFF+DEFLATE para comparação. Também se apresenta o resultado obtido usando o ArcGIS para converter para JP2.

Formato Compressão Taxa %
TIF DEFLATE 31,5
JP2 (GDAL) 0 54,2
JP2 (ArcGIS) 100 42

Para arquivo de imagens originais podemos assim usar o formato JP2, desde que usemos o parâmetro de qualidade máxima (ou de compressão mínima consoante o software de compressão). Ficamos ainda com o bónus serem incluídas pirâmides nas imagens , úteis para o caso de as visualizarmos. A única desvantagem é a lentidão de visualização… portanto só mesmo para arquivo. Se usarmos o GDAL para a compressão conseguimos gravar em 1/2 dos DVDs…

Comandos GDAL de compressão

Aqui fica uma cábula de comandos GDAL para compressão de imagens nos diversos formatos, e as respectivas taxas de compressão obtidas no teste. Não se esqueça que na 2ª parte da série encontra um script (.bat) para compressão de todos os ficheiros numa directoria.

Formato Taxa
%		 Comando
TIF com compressão DEFLATE 31,5 gdal_translate -of GTiff -co COMPRESS=DEFLATE -co PREDICTOR=2 in.tif out.tif
TIF com compressão LZW 22,3 gdal_translate -of GTiff -co COMPRESS=LZW -co PREDICTOR=2 in.tif out.tif
JP2, agressivo 80,2 gdal_translate -of JP2ECW -co TARGET=80 in.tif out.jp2
JP2, sem degradação 54,2 gdal_translate -of JP2ECW -co TARGET=0 in.tif out.jp2
ECW, agressivo 86,6 gdal_translate -of ECW -co TARGET=80 in.tif out.ecw
ECW, mínima degradação 59,8 gdal_translate -of ECW -co TARGET=0 in.tif out.ecw
JPEG, agressivo* 97,7* gdal_translate -of JPEG -co QUALITY=25 -co WORLDFILE=YES in.tif out.jpg

* Sem pirâmides. Ao criar pirâmides, a taxa de compressão reduz-se significativamente.

A parte 4 da série será dedicada à criação de catálogos de imagens com o GDAL… até lá.

GDAL: conversão entre formatos de imagem SIG

Inicial, Open Source,
Tempo de leitura: 4 min

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

Gestão,
Tempo de leitura: 5 min

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

Inicial,
Tempo de leitura: 3 min
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!

Olá, mundo!

Sem categoria
Tempo de leitura: < 1 min

Finalmente dei o passo de manter um blog. Depois de anos a considerar a hipótese, e de recear a dedicação exigida, reuni a motivação suficiente para avançar com este compromisso.

O meu dia-a-dia profissional será a inspiração principal para os artigos, que serão dedicados aos problemas e soluções com que me for cruzando. Também notícias que me impressionem mais, apresentações, e discussões virão aqui parar. E finalmente, talvez um ou outro artigo de opinião.

Espero que consiga fazer algo de interessante. Até breve!