Archive for the 'Open Source' Category

Page 2 of 2

PostgreSQL e ESRI – Parte 1

Publicado em 10 de Julho de 2009 em Gestão, Inicial, Open Source and SIG. 8 Comments Tags: , , .

A atracção do software Open Source é também sentida pelos utilizadores ESRI. Numa discussão na web li uma vez alguém descrever um utilizador de ArcGIS da seguinte maneira: “a única forma de retirar o ArcGIS das mãos de um utilizador é arrancá-lo das suas mãos mortas e frias”… a crer nisto, no lado de aplicações SIG desktop não será fácil substituir o ArcGIS por qualquer outra alternativa.

Será no entanto mais fácil explorar alternativas para os componentes que se encaixam na área dos servidores SIG, ou seja, bases de dados espaciais e servidores webGIS. Um dos produtos Open Source que tem recebido muita atenção na comunidade ESRI é o par PostgreSQL+PostGIS, que recentemente foi incluída na lista de bases de dados suportadas pela ESRI.

A partir da versão 9.3 a ESRI incluiu a possibilidade de utilizar, com toda a sua família de software ArcGIS, a base de dados PostgreSQL e o seu módulo geoespacial PostGIS, ambos Open Source. Esta possibilidade é muito atraente por vários motivos, sendo para mim os mais importantes:

  • PostgreSQL e PostGIS são produtos de grande qualidade, grande difusão, com utilizadores de referência credíveis, existindo uma comunidade muito activa ao seu redor;
  • São Open Source e gratuitos;
  • Oferecem funções de manipulação e análise geográfica de dados vectoriais através de SQL, ombreando com os melhores produtos existentes, open source ou comerciais;
  • Seguem os standards da indústria para SQL espacial (da OGC, e neste momento está em fase de implementar o standard da ISO), o que é obviamente uma abordagem irrepreensível e de enorme importância;
  • Quase a totalidade das aplicações SIG Open Source são compatíveis com esta bd;
  • O facto da ESRI incluir esta base de dados no grupo de sistemas suportados “oficialmente”, oferece uma segurança aos departamentos de TI que pode ser um factor decisivo na adopção ou não do PostgreSQL na empresa (e eu sei que este ponto gera polémica na comunidade de utilizadores e apoiantes, mas é um facto que existe esta barreira).

Porquê mudar?

Uma plataforma SIG muito comum, e aquela com que mais trabalho, é baseada em Oracle e ArcSDE, onde vários utilizadores de ArcGIS visualizam e editam a informação aí residente, havendo também servidores webGIS e aplicações que utilizam a informação residente em Oracle/ArcSDE. Neste artigo vou frequentemente referir esta arquitectura como ponto de comparação.

Quando já existe, trocar de base de dados não é tarefa fácil, consoante o volume e complexidade da informação existente, da dependência das aplicações desenvolvidas, e das novas competências que será necessário adquirir. Mas, há um  momento fulcral na vida de uma base de dados durante o qual vale tudo: a migração de servidor e upgrade de versão!

Nesta situação, a vantagem de migrar para PostgreSQL/PostGIS é passar a contar com um grande conjunto de aplicações SIG Open Source que podem usar a base de dados sem passar pelo ArcSDE – ou seja, podemos usar software não-ESRI e software ESRI para ler e manter a base de dados geográfica, efectivamente criando um sistema híbrido. (NOTA: uso aqui a expressão “SIG Híbrido” no sentido de integrar componentes comerciais e componentes Open Source num sistema de forma a usufruir das vantagens de cada componente, com as dificuldades inerentes, tal como Dan Dale Lutz tão bem explicou aqui.)

Note-se que esta interoperabilidade já é possível em alguma medida, especialmente com Oracle, desde que os dados sejam armazenados em Oracle Spatial ou Locator (sempre incluído em todas as versões Oracle). Só que neste caso existem muito menos aplicações SIG que lêem este tipo de dados, algumas Open Source. Mas em geral, as opções Open Source têm uma compatibilidade pouco fiável e de instalação nem sempre fácil. Por outro lado, tenho encontrado sistematicamente um desempenho muito inferior ao usar ArcGIS com dados Oracle Spatial quando comparado com o modo tradicional do ArcSDE armazenar dados em Oracle (denominado SDEBINARY). Mais sobre estas opções adiante…

Um sistema híbrido porquê?

O cenário de adoptar o PostgreSQL num SIG baseado em ESRI (ou Autodesk) implica que se pode manter todo o restante ecossistema SIG – ferramentas desktop, servidores webGIS, e aplicações desenvolvidas, bem como o nível de produtividade actual da equipa de edição/análise (que tipicamente é atingido após anos de experiência da equipa técnica com estas ferramentas). E ainda se abrem as portas para alargar o ecossistema a ferramentas  Open Source e de outros vendedores.

No caso da ESRI, todo o seu software comunica com o ArcSDE para chegar aos dados, e não directamente com a base de dados. Por isso a troca por outra bd não tem qualquer impacto sobre a restante plataforma SIG. E isto é uma vantagem. Claro que a desvantagem é o preço do ArcSDE…

No caso em que o ArcSDE já existe, podemos alegremente ignorar este custo (embora o custo de manutenção anual continue a existir)!! Em situações onde não exista ArcSDE deve-se incluir o seu custo de aquisição na análise das alternativas disponíveis.

A vantagem do SQL espacial

Um dos grandes trunfos de usar uma bd que, como o PostgreSQL+PostGIS, oferece funções de manipulação e análise espacial por SQL é podermos usar comandos na própria bd que vão efectuar as análises que estamos habituados a fazer apenas com as nossas ferramentas SIG desktop favoritas.  (Aliás, para ser exacto, o ArcSDE desde a v9.3 adiciona sempre o seu próprio dialecto de SQL espacial à bd onde é instalado, que pode ser usado como alternativa ao SQL nativo da bd. Isto também se aplica ao PostgreSQL. O administrador da bd é que decide se usa o dialecto da ESRI ou o dialecto nativo da bd.)

Por exemplo, com SQL espacial é possível seleccionar as classes de solo intersectadas pelo novo traçado do IP2, recorrendo apenas ao PostgreSQL, e sem usar ArcView. E como a máquina onde se instalam bases de dados é tipicamente muito mais potente que o nosso posto de trabalho, a velocidade de processamento destas análises será também superior. Já para não falar de evitar a transmissão de dados na rede entre a bd e o posto de trabalho. Apenas os resultados são transmitidos à aplicação SIG para visualização.

Então porque é que não estamos todos a usar SQL espacial para fazer análise geográfica?

Porque ainda é preciso que o utilizador saiba escrever estes comandos SQL! E isto não é uma tarefa trivial. Notem que escrevi “ainda é preciso saber…” sendo a palavra chave “ainda“. Isto porque hoje todas as bases de dados comerciais têm suporte a SQL espacial – Oracle, SQL Server, DB2, Informix – umas há mais tempo que outras, umas com SQL mais padronizado que outras, mas a funcionalidade está lá. O que falta são as aplicações que sabem executar essa análise nessas bd’s, facilitando a vida ao utilizador com botões e menus amigáveis, e dispensando assim o conhecimento de SQL espacial!

Por exemplo, quando o ArcView calcula um buffer não utiliza as capacidades da bd de cálculo de buffers, mesmo que elas existam. Apenas lê os dados armazenados na bd, e usa o nosso posto de trabalho para fazer o cálculo. E a esmagadora maioria das aplicações SIG actuais fazem o mesmo, quer comerciais quer Open Source.

Mas parece-me inevitável que ao longo dos próximos anos assistamos à mudança deste paradigma. Até porque desde que a Microsoft incluiu SQL espacial no SQL Server 2008 há toda uma nova geração de programadores que “acordou” para as capacidades do SQL espacial.

Quando uma aplicação SIG com peso no mercado conseguir fazer uma análise 10x mais rapidamente que os seus concorrentes (porque recorre às capacidades do servidor de base de dados) o que acham que vai acontecer?

Opções para utilizadores ESRI

Então que opções existem para os utilizadores ESRI que querem utilizar PostgreSQL+PostGIS?

ArcSDE

A opção standard do ponto de vista da ESRI é, claro, instalar o ArcSDE. Na versão 9.3 existe um setup de instalação que até instala o PostgreSQL e o PostGIS de uma forma muito automatizada. Pode-se encontrar alguns tutoriais de instalação, como este do Adriano Hantequeste: ArcSDE [Passo 1] Instalando o PostgreSQL. Há que ter atenção, no entanto, aos passos opcionais de instalar o PostGIS manualmente, para podermos no fim optar pelas suas capacidades nativas. (No manual de instalação do ArcSDE está tudo bem explicado.)

Mas há mais para além da instalação do ArcSDE. Podemos configurar a forma como o ArcSDE armazena os dados vectoriais no PostGIS. Existem 2 opções:

  • formato proprietário ESRI (ST_GEOMETRY)
  • formato nativo PostGIS (PG_GEOMETRY)

Estas opções definem o formato como as geometrias dos nossos vectores são armazenados na bd. Para o utilizador de ArcGIS é invisível se optamos por uma ou outra, mas há consequências importantes.

O formato ESRI guarda as geometrias no PostgreSQL de forma a que apenas se podem ler ou alterar usando software compatível (leia-se ESRI). Ou seja, o Quantum GIS para ler estes dados terá de usar um plugin ArcSDE (para ser exacto, o plugin é instalado no OGR que por sua vez é usado através do QGIS).

Por sua vez, o formato PostGIS guarda as geometrias usando as capacidades do PostGIS, e isso significa que todo o software compatível com PostGIS as pode ler e alterar. Ou seja, podemos carregar dados na bd usando o ArcCatalog (que passa pelo ArcSDE), e depois usar o QGIS para ler esses dados, sem passar pelo ArcSDE e sem plugins. Confuso? Espero que não… em última análise, esta opção permite ter na empresa aplicações gratuitas como o QGIS a usufruirem da bd central, a fazer impressões, análises, confrontações, etc. sem duplicação de dados ou conversões desconfortáveis.

Como se configura esta opção do formato de armazenamento das geometrias?

Sem querer entrar em grandes detalhes, pode-se dizer que é muito simples. Basta executar um comando que altera uma linha na tabela de configuração do ArcSDE. O comando é o seguinte:

sdedbtune -o alter -i 5151 -k DEFAULTS -P GEOMETRY_STORAGE -v “PG_GEOMETRY” -s <server_name> -D postgis -u sde -p <ArcSDE_admin_password>

Esta opção tem outras configurações e particularidades que terão de ficar para outra oportunidade.

zigGis

zigGIS é uma extensão para ArcGIS que permite ler e escrever em PostGIS, sem usar ArcSDE. É um produto que começou como Open Source, e que evoluiu para uma solução comercial. Embora a fonte do programa esteja disponível, é exigida a compra de licenças na maioria das situações (excepto para uso pessoal e académico que continuam isentos de pagamento – ver licença aqui).

Ora o preço é de apenas US $279! por posto de trabalho. É naturalmente muito apetecível. O cenário em vista é conseguir um SIG, com base de dados geográficos e aplicação desktop de topo, apenas pelo preço de ArcView + $279.  Será que há algum truque, uma armadilha? Parece que não, a ver pelo excelente exemplo da implementação na Câmara Municipal de Albufeira, é uma opção extremamente flexível.

O papel do ArcSDE

Claro que surge a questão óbvia: então para que serve o ArcSDE? Bom, esta questão é debatida há muitos anos, bem antes de existir o zigGIS, e posso apenas manifestar a minha opinião – o ArcSDE é o pivot de dados que serve toda a plataforma ArcGIS – desde o modelo de dados, ao servidor webGIS, às aplicações desktop. Sem o ArcSDE, as várias peças do ArcGIS “descolam”, e temos de recorrer a ficheiros para partilhar informação entre as componentes do sistema. Por outro lado, o ArcSDE permite à ESRI implementar funções para além dos standards. Em geral, os standards na área SIG e SQL são desenvolvidos mais lentamente que as aplicações desenvolvidas pelos maiores fabricantes. Por exemplo, antes de existir WMS já existiam servidores webGIS. Antes de existir standard de SQL espacial, já existiam bases de dados geográficos. Com o ArcSDE a ESRI implementa um modelo de dados com funcionalidade que não está padronizada pela indústria: rasters, terrains (para LIDAR), topologia com regras de validação automática, gestão de versões, gestão de histórico, bd’s distribuídas, sincronização de bd’s… bom, não é o meu papel “defender” o ArcSDE, mas encontro valor acrescentado no produto. Para os casos que não necessitam desta integração ou destas funções, fará menos sentido a sua aquisição. Para os outros casos…

Conclusão

Já vai longo este artigo… contra todas as regras de bom comportamento em blogs :)

Nos próximos tempos penso continuar este tema com mais alguns artigos, olhando com mais detalhe para a combinação PostgreSQL+PostGIS<->ArcSDE<->ArcGIS.

Para já, é certo que podemos contar com a possibilidade de criar sistemas híbridos com software ESRI e componentes Open Source, usando o melhor dos 2 mundos. E isso é um passo de gigante  que demorou décadas a chegar ao ArcGIS, mas finalmente aí está.

Balanço Open Source para SIG

Publicado em 23 de Maio de 2009 em Gestão, Inicial, Open Source and SIG. 4 Comments Tags: , , , , .

Já há algum tempo que tenho planeado escrever sobre a integração entre Postgresql e ArcSDE, agora que a ESRI suporta esta combinação. Mas ao começar esse artigo dei por mim a reflectir sobre a utilização que faço de ambos os mundos – open e closed source…

Sou utilizador de software ESRI há muitos anos, e sou também utilizador de software Open Source em tempo igual. Curiosamente.

Sucede que comecei a trabalhar em SIG num projecto de investigação na universidade (no Instituto Superior de Agronomia, “antigo” Dept. de Eng.ª Rural), e em simultâneo iniciei o mestrado. No projecto de investigação trabalhei com Linux, aprendendo as bases deste SO que ainda hoje me servem – na altura não havia sistemas de distribuição de pacotes de software já pré-configurados… por exemplo, o sistema de email que usava tive que o compilar… outros tempos (sou tão velho “informaticamente” que a minha mulher quer oferecer-me pelo aniversário uma tshirt do ZX Spectrum). Para a tese de mestrado usei ArcInfo numa estação de trabalho IBM com o SO AIX, uma variante de Unix desenvolvido por este fabricante. Desde aí mantive o gosto por Open Source, e continuei utilizador ESRI.

Para um utilizador ESRI, a integração com software Open Source é uma questão muito pertinente, por vários motivos – anoto aqui apenas alguns. Afinal, e não o escondo, o ArcGIS é o meu software SIG favorito, mas não faz tudo o que preciso, e nem tudo o que faz é feito da melhor forma. Nada melhor do que complementá-lo com pérolas de software gratuito. Por outro lado, existem tarefas para as quais prefiro utilizar um programa mais ligeiro, como o QGIS. E claro, para tarefas relacionadas com outro software Open Source também não é o mais indicado. Por exemplo, exportar um ficheiro .map para o MapServer a partir de um mapa devidamente simbolizado. Também a interoperabilidade e capacidade de interagir com os diversos standards OGC são limitadas no ArcGIS em alguns aspectos. Por exemplo, criar ficheiros SLD (de simbologia) para uso no GeoServer. Mas para os críticos do ArcGIS não se ficarem a rir, não conheço nenhum outro programa que crie ficheiros KML tão facilmente e com tanta funcionalidade como o ArcGIS. E o KML também é um standard OGC…

A situação com o Software Aberto na área SIG (SASIG) teve uma evolução explosiva nos últimos anos. Na minha opinião, devido em grande parte à publicidade positiva que a área recebeu da Google e a Microsoft. E hoje o panorama de software no lado do servidor e no lado do desktop é extraordinário. O software Open Source não serve só como complemento, e terá todo o mérito e capacidade em ser utilizado como peça central de um SIG. Tudo depende dos objectivos, necessidades, e processos de trabalhos escolhidos.

No servidor, temos 3 players fenomenais: MapServer, GeoServer (web), e Postgresql+PostGIS (bd).

No desktop, podemos também escolher facilmente 3 campeões da causa: gvSIG, Kosmo, e Quantum GIS – embora existam muitos mais.

Na categoria de ferramentas para conversão de dados, que tanto são usadas no lado servidor como no lado desktop, temos o incontestável par GDAL/OGR para raster e vector. Outras iniciativas mais recentes que poderão ser interessantes são o FeatureServer, o Spatial Data Integrator e o GeoKettle (ambos semelhantes ao FME).

Para o desenvolvimento de aplicações web também temos óptimos produtos: OpenLayers, pmapper, MapFish, e vários outros.

Já para desenvolver aplicações desktop o cenário é muito diferente, e não será uma tarefa fácil tentar criar uma aplicação SIG baseada em componentes Open Source. Pessoalmente, a minha opção seria sempre pela facilidade de utilização, e assim optaria pelo objecto ActiveX do MapWindow GIS, ou o extraordinário SharpMap para .NET (cujo desenvolvimento tem sido extremamente lento, para grande desencanto da comunidade… o jovem Morten foi contratado pela… (suspense)… ESRI!). Estas seriam as opções mais simpáticas, com menor exigência técnica e de tempo para criar uma aplicação SIG desktop adaptada a um objectivo específico.

Para adeptos Java existem também várias opções, embora mais complexas. As opções mais proeminentes serão a GeoTools (sem mecanismo de visualização?), GISToolkit (última versão de 2003), e OpenMap (apenas visualização). O mundo Java é para mim mais desconhecido, e agradeço contribuições de quem tenha mais prática com esta tecnologia para esclarecer a situação actual face a componentes SIG.

A área continua a evoluir e é difícil manter uma noção actualizada do que vai acontecendo nos vários domínios. Têm vindo a ser publicados artigos com o diagnóstico da “situação actual”:

Faltará talvez uma página web fixa onde se possam actualizar os vários produtos, talvez num wiki? Para nós lusófonos, seria excelente manter uma página destas no wiki do OSGeo PT. Há voluntários???

GDAL Como criar ficheiros tfw

Publicado em 6 de Fevereiro de 2009 em Inicial, Open Source and SIG. 0 Comments Tags: , .

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.

GDAL: Formatos Comprimidos

Publicado em 6 de Janeiro de 2009 em Intermédio and Open Source. 0 Comments

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

Publicado em 23 de Dezembro de 2008 em Inicial and Open Source. 1 Comment 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.