Arquivo da Categoria: Intermédio

Visualizar CAD online

CAD, Intermédio, SIG,
Tempo de leitura: 6 min

A visualização de informação CAD via web, por si só ou em conjunto com outra informação georreferenciada, é importante para as áreas de Engenharia, como sejam as de Projecto, Empreitada, Exploração e Manutenção de infra-estruturas. Nestas áreas a informação CAD é rainha – qualquer menção de outros formatos ou, perdendo completamente a cabeça, referir SIG é garantir o epiteto de “o tipinho dos Mapas”… Mas fora de brincadeiras, o valor da informação CAD em Engenharia é obviamente indiscutível, e as ferramentas CAD e SIG são naturalmente complementares, e talvez até sequenciais em muitos fluxos de trabalhos. Mas isso seria material de outros artigos…

O objecto deste artigo é apresentar 2 metodologias para visualizar ficheiros CAD num browser, e como veremos, isto pode ser feito actualmente com e sem downloads de software.

Os ficheiros DWG não dados a visualizações rápidas. Até hoje não vi ainda uma aplicação que rapidamente mostre o conteúdo de um DWG. Se usarmos software Autodesk os recursos do computador que são ocupados apenas para abrir um pequeno DWG são impressionantes, mas as coisas têm vindo a melhorar ultimamente. O visualizador que mais me agradou até hoje é o eDrawings: uma aplicação gratuita, rápida, e eficaz. Surpreendentemente, o próprio MapGuide não publica ficheiros DWG, a não ser que se convertam primeiro para DWF. (se alguém souber o contrário, por favor diga-me!)

Em relação ao problema de visualizar na web ficheiros DWG, foram encontradas 2 soluções, e passam ambas por os converter para DWF. Só depois poderemos usar um controle ActiveX para o Internet Explorer (ou mais recentemente um plugin para Firefox 3.x) para visualizar estes ficheiros, ou recorrer ao serviço gratuito da Autodesk chamado Freewheel. Mas vejamos cada solução em detalhe.

Solução 1 – Controle ActiveX para IE ou plugin Firefox 3.x

Ao instalar software da Autodesk é também instalado um controle ActiveX que lê ficheiros DWF e  faz muitas outras coisas, sendo um autêntico mini-programa de CAD. Este controle era incluído no DWF Viewer, um produto gratuito que entretanto foi substituído pelo Design Review. De qualquer forma, muitos dos programas da Autodesk, como o AutoCAD, TrueView, ou o Design Review, instalam também este controle, e por isso muitos dos utilizadores terão já o controle no seu PC, mesmo sem saberem.

Este controle permite incluir este mini-visualizador CAD em aplicações Windows, como o IE, Word, PowerPoint, etc., e isso é muito útil para o nosso objectivo.

Para abrir um ficheiro DWF no IE, basta incluir numa página web o seguinte código HTML:

<OBJECT CLASSID="clsid:A662DA7E-CCB7-4743-B71A-D817F6D575DF"
CODEBASE=http://www.autodesk.com/global/dwfviewer/installer/
DwfViewerSetup.cab#version=7,0,0,928
WIDTH="640" HEIGHT="480">
<PARAM NAME="Src"
VALUE="http://www.autodesk.com/global/dwf/samples/multiple_layouts_large.dwf">
</OBJECT>

O resultado é excelente. A imagem seguinte mostra o resultado…

dwfviewer_1

Caso o PC não tenha ainda o controle instalado, o browser inicia o processo de download e instalação, caso o utilizador permita.

Observando a toolbar podemos ver funções como imprimir, gravar (para DWF ou DWFx), zoom e pan, ver Model e todos os Layouts, controlar Layers, Propriedades, e muitos outros, oferecendo assim um verdadeiro mini-CAD dentro do browser.

Este exemplo pode ser encontrado num dos blogs da Autodesk. Como o código já é um pouco antigo, a versão indicada do controle é também antiga (7.0.0.928), e podemos usar uma mais recente. Para isso localizamos a dll do controle no nosso computador (C:\Program Files\Common Files\Autodesk Shared\DWF Common\AdView.dll), verificamos a sua versão e actualizamos o código (no meu PC a dll tem a versão 9.0.0.96 e vinha incluída no Design Review 2009). Devemos escolher uma versão que seja a mais comum na empresa onde vamos implementar este sistema de visualização, para evitar que os utilizadores tenham de instalar software adicional.

Uma última nota – se incluirmos o controle ActiveX numa página web, sem indicar um ficheiro para abrir, então o botão de Abrir ficheiro fica activo e podemos escolher qualquer ficheiro que tenhamos no disco ou numa partilha. Mas é estranho que ao indicarmos um ficheiro no código essa opção fique inactivada…

Vantagens desta solução:

  • visualizador muito completo no browser
  • permite abrir qualquer ficheiro DWF acessível ao PC, quer em disco, partilha, ou web
  • permite imprimir, gravar como DWF/DWFx, e capturar imagens
  • interface muito familiar para quem usa software Autodesk

Desvantagens:

  • exige IE
  • exige que já exista software Autodesk instalado, ou que se instale o controle ActiveX

Links de interesse:

Solução 2 – Serviço Freewheel da Autodesk

A Autodesk lançou um serviço online (já em 2006!) que permite fazer upload de um ficheiro DWF e visualizá-lo num browser sem qualquer software adicional. Pode até visualizar-se num PDA. Se a página for configurada para abrir um ficheiro pré-definido, então o ficheiro tem de estar num url acessível ao servidor da Autodesk e é preciso cuidado com firewalls ou proxies restritivos. Mas se for o utilizador a indicar o ficheiro que pretende visualizar, então o proxy/firewall não deverá interferir.

Algumas empresas poderão não estar dispostas a colocar os seus desenhos DWF num website público, embora pessoalmente essa questão me pareça pouco importante – até porque seria necessário conhecer o url exacto do ficheiro para o poder obter. Por outro lado, (confesso já que não li os termos de utilização do serviço com atenção) fico com a sensação de que também aqui se podem levantar questões de confidencialidade – o que sucede aos ficheiros passados para o servidor da Autodesk? Quem os pode ver?… Se alguém quiser esclarecer esta questão seria óptimo.

O código HTML a incluir na página web é muito simples:

<iframe scrolling="no" width="800" height="600"
src="http://freewheel.autodesk.com/dwf.aspx?path=http://www.pinnacle-pizza.com/Hotel5.dwf">
</iframe>

A página ficaria com este aspecto:

dwf_freewheel_1

Não há software a instalar no nosso PC, e a visualização é excelente. Há menos controles disponíveis na toolbar, mas mesmo assim podemos fazer zoom e pan, e navegar pelo Model e Layouts do ficheiro. Através do menu File, podemos ainda abrir um ficheiro diferente (que é enviado para o servidor da Autodesk), enviar por email, e imprimir.

Como funciona? O servidor Freewheel recebe os pedidos do nosso browser para visualizar determinada parte do ficheiro DWF e devolve uma imagem dessa visualização, e assim por diante. Ao fazer zoom sobre, por exemplo, a área da legenda, essa área é devolvida ao browser como uma imagem que é mostrada ao utilizador, simulando o trabalho com o ficheiro.

O serviço Freewheel disponibiliza uma pequena API que permite efectuar pedidos específicos através do endereço (url): que ficheiro queremos, que área, que zoom, etc. E é isso que enviamos por email quando usamos essa opção no browser – um url que permite ao destinatário ver o desenho exactamente na posição em que o estamos a ver.

Mas há mais… o Autodesk Labs (equivalente ao Google Labs, onde se experimentam tecnologias até serem promovidas a produtos “a sério”) oferece uma versão melhorada do Freewheel. A capacidade que mais me impressionou foi a de podermos criar um repositório de ficheiros DWF que podemos manter no servidor da Autodesk e reutilizar ou partilhar com colegas de trabalho. Mais: é possível até partilhar uma sessão de visualização em que um dos utilizadores manipula o desenho e os restantes podem observar, trocar mensagens, e anotar o desenho. Quando testei com o Chrome o tamanho do texto e desenhos estava demasiado grande, e não sei quanto tempo os ficheiros ficam disponíveis… mas estas capacidades de cooperação são impressionantes.

Vantagens desta solução:

  • não é necessário software adicional
  • interface muito simples, com zooms e pan
  • acesso ao model e layouts do DWF
  • o utilizador pode carregar qualquer ficheiro DWF para visualizar
  • qualquer browser e até PDAs podem visualizar ficheiros DWF
  • pode-se imprimir
  • pode-se enviar um email com url para visualizar o ficheiro DWF
  • pode-se fazer uma sessão de visualização em conjunto
  • pode-se a partir de links fazer thumbnails usando apenas Javascript

Desvantagens:

  • menos funcionalidade CAD
  • os ficheiros a visualizar são transmitidos para o servidor da Autodesk, o que pode demorar
  • o desempenho depende da nossa ligação à Internet e da capacidade de resposta do servidor da Autodesk
  • os ficheiros são passados para o servidor da Autodesk
  • Internet é obrigatória

Links de interesse:

Conclusão

Estas 2 abordagens permitem resolver a questão de visualizar ficheiros CAD online, embora ainda de forma isolada e obrigando a converter para o formato DWF, mas é um primeiro passo para podermos ter a informação CAD integrada numa abordagem web. Claro que a partir do momento em que aceitamos a obrigatoriedade de converter os nossos ficheiros CAD para DWF abrimos a porta a usar o MapGuide para publicar esses ficheiros em serviços WMS, serviços esses que podem ser incluídos em aplicações webGIS… e isso já é outra estória.

Medindo o Desempenho de Servidores SIG

Gestão, Intermédio, SIG, ,
Tempo de leitura: 8 min

Neste artigo a expressão “Servidores SIG” refere-se a servidores de mapas online (ou webgis). A questão que se coloca é: medir a performance do nosso servidor ArcIMS, MapServer, ArcGIS Server, GeoServer, etc.

Em geral podemos considerar que temos um bom servidor se for capaz de produzir 2 mapas por segundo. As aplicações webgis são muito interactivas, e um utilizador quando faz zoom não quer ficar à espera muito tempo até que o mapa volte a ser redesenhado.

Claro que desde 2005, com o aparecimento das aplicações baseadas em pequenas quadrículas (tiles) já pré-processadas e prontas no disco rígido do servidor para serem mostradas ao utilizador, a exigência sobre o dinamismo das aplicações tradicionais (sem tiles) subiu em flecha. Mas não é uma exigência justa… (Pelo menos do ponto de vista técnico – do ponto de vista do utilizador “isso não interessa nada”.)

Um mapa que é gerado dinamicamente necessita sempre de mais tempo para ser processado. Basta pensar em todas as tarefas que têm de ser executadas até chegar à imagem final: ler a configuração do mapa, obter os dados para a zona visível, desenhar os dados, e gravar a imagem. Isto comparando com a abordagem com tiles: 1) qual é a imagem que é preciso mostrar? 2) Ahh, é esta. Portanto, um servidor que consegue debitar 2 mapas dinâmicos por segundo é muitíssimo bom, e se o seu servidor não conseguir tanta velocidade não lhe leve a mal.

Recentemente, tive a boa sorte de poder contar com um novo servidor para suportar todas as aplicações webgis de um SIG empresarial, e tenho andado no processo de instalação do software e de migração das aplicações que estão no servidor “velho”. Embora a nova configuração seja muito mais moderna, afinal passaram 5 anos, o novo processador tem menos 1,2GHz de velocidade de relógio e isso, confesso, deixou-me apreensivo. Decidi que haveria que medir o desempenho dos 2 servidores. Quem não tiver interesse em ler todo o artigo pode sempre saltar para as conclusões.

Configurações dos servidores em comparação

O servidor “velho” tem um processador Xeon a 3,2 GHz baseado no Pentium 4, Windows Server 2003, com 2GB de memória.

O novo servidor tem um Xeon moderno a 2,0 GHz baseado no Core 2, Windows Server 2003 64 bit, e com 8 GB de memória.

Os discos que equipam ambos os servidores não serão muito influentes no teste uma vez que todos os dados usados residem numa base de dados Oracle/ArcSDE numa máquina separada, à qual ambos os servidores se ligam por rede a 1 Gbps. Em relação à memória, vamos desprezar o efeito que poderá ter, uma vez que a máquina mais antiga teve sempre memória de sobra mesmo só com 2 GB.

O software usado como servidor SIG é o ArcIMS da ESRI. No servidor “velho” está instalado a versão 9.2, e no novo a versão 9.3. Ambos os servidores usam o IIS e o Tomcat.

O serviço de mapas usado para o teste contém uma mistura de dados vectoriais de de imagem (ortofotomapas com 0,4m de resolução), e usa simbologia bastante complexa, com labels, e anti-aliasing. É portanto um serviço que se pode considerar bastante exigente ao nível de processamento.

Software de Testes – JMeter

Já há algum tempo que procurava uma aplicação que me permitisse efectuar testes de desempenho em ambiente web, mas que fosse fácil e prático, sem grandes manuais e configurações… o JMeter encaixa perfeitamente nestes requisitos. É uma aplicação Java desenvolvida pelo grupo Apache, é Open Source, logo gratuito. Tem uma boa documentação, e encontram-se vários exemplos de iniciação na Internet.

A forma de funcionar é muito simples. Um teste é composto por painéis que vamos adicionando. Cada painel é de um determinado tipo e serve uma função: definir parâmetros default, executar um pedido via HTTP, agregar resultados num relatório, e até efectuar operações mais complexas como definir variáveis, ciclos, estruturas de decisão if-then, usar ficheiros csv com parâmetros, etc. É uma ferramenta que pode ser usada tanto de forma muito simples (o meu caso) como de forma muito complexa.

Mas a cereja no topo do bolo é a capacidade do JMeter gravar o que fizermos no browser, e depois usar essa gravação para bombardear o servidor, repetindo a mesma sessão mas multiplicando-a como se existissem vários utilizadores simultâneos.

Gravando um teste

Para gravar uma sessão de utilização do browser, basta iniciar o JMeter e adicionar ao nosso “Workbench”, um painel “HTTP Proxy Server”. Com este painel, o JMeter vai capturar tudo o que fizermos no Internet Explorer, construindo assim o nosso teste. Depois basta retirar o que não é essencial, como imagens jpeg ou gif, ficheiros html, js, e restante conteúdo estático, que é processado pelo servidor web (IIS, Apache) e não pelo nosso servidor SIG. Em seguida, na entrada “Test Plan” acrescenta-se um “Thread Group”. Este item é o contentor de todos os passos do nosso teste. O Thread Group define o n.º de utilizadores simulados e o n.º de repetições que cada utilizador fará (Loop Count).

Com estas definições, usamos a opção Run/Start, e de seguida iniciamos o IE e abrimos uma aplicação de mapas que esteja no nosso servidor. No meu caso, usei o visualizador “HTML Viewer” que é instalado com o ArcIMS. Fiz alguns zooms e pans, e para terminar um Identify. De seguida bastou parar o JMeter com a opção Run/Stop. O teste ficou com o seguinte aspecto (já com todos os nossos passos gravados):

JMeter_testeinicialopt

Alterar o teste de desempenho

Em seguida, apagam-se todos os passos que não sejam pedidos directos ao ArcIMS. Os pedidos ao ArcIMS têm endereços que apontam para algo como “/servlet/Esrimap”… o objectivo é testar apenas os conteúdos que são direccionados ao servidor de mapas e não ao servidor web.

No final, acrescenta-se um painel “Aggregate Report”, que vai recolher automaticamente os resultados dos vários passos do teste. No final, ficaremos a saber o n.º de pedidos efectuados, a média de tempo de processamento, tempos mínimo e máximo, KB/s transmitidos e n.º de pedidos processados por segundo. Mais à frente veremos os resultados e a interpretação que se pode fazer para se chegar ao n.º de mapas/s.

O teste resultante ficou com o seguinte aspecto:

JMeter_testefinal_opt

É claro que também teremos de apagar o HTTP Proxy Server…

Resta-nos correr o teste. Gravam-se as estatísticas do relatório usando o botão “Save Table Data”, e alteram-se os endereços para apontarmos para o novo servidor. Repete-se o teste, e gravam-se as novas estatísticas para outro ficheiro.

Testando

No meu caso particular, executei 2 testes em cada servidor – um em que se simulou só um utilizador, e outro em que se simularam 10 utilizadores simultâneos. Os zooms foram feitos sempre aos mesmos locais, com exactamente as mesmas coordenadas. Geralmente, isto não é desejável, principalmente quando se quer testar a performance de uma aplicação ou medir o impacto das melhorias espectaculares que fizemos ao nosso serviço de mapas. Mas no caso em mãos, o objectivo é comparar 2 servidores, e o facto de se pedir sempre mapas das mesmas áreas faz com que os dados usados sejam sempre os mesmos, eliminando-se variações de desempenho no seu acesso. Acresce que ao usarmos uma base de dados, os mecanismos de cache da mesma irão entrar em pleno funcionamento, atenuando ainda mais qualquer flutuação na velocidade de acesso à informação.

Resultados e análise com 1 utilizador

Para o teste de 1 conexão obtivemos os seguintes resultados para a máquina antiga:

Aggregate Report_1ediasigims_opt

A 1ª linha é o pedido inicial feito ao ArcIMS para obtermos a lista de layers no mapa, extensão geográfica inicial, e outros dados genéricos. É um pedido que foi processado muito rapidamente, demorando 157 ms.

A 3ª linha é o pedido final de Identify. É também muito rápido, tendo o servidor demorado 225 ms a devolver os atributos do vector que se encontrava sob o ponto clicado.

A 2ª linha é a mais interessante: aglomera os 8 pedidos de mapa, em 8 locais diferentes e a escalas diferentes. Aqui o servidor teve de trabalhar mais: demorou um mínimo de 889 ms, e um máximo de 8859 ms, ou seja 8,9 s! Quando esta imagem chegou já o utilizador tinha ido tomar café!! Se virmos o final desta linha temos o valor de 21,3/min que significa que com base nestes 8 resultados estima-se que o servidor conseguirá processar 21,3 mapas por minuto. Ou seja, 1 mapa demora em média 2,8 segundos a ser processado.

E para a nova máquina, obtivemos os seguintes resultados:

Aggregate Report_1ediabeja019_opt

Ignorando os valores das 1ª e 3ª linhas, vamos directos ao que interessa – a 2ª linha.

Este servidor demorou um mínimo de 174 ms e um máximo de 3355 ms para gerar cada uma das imagens pedidas. E a sua capacidade estimada a partir destes resultados é de 39,9 mapas por minuto. Ou seja, 1 mapa demorou em média 1,5 segundos a ser processado.

É preciso aqui introduzir 2 notas: i) o mapa que demora tanto tempo a produzir é o mapa inicial, que mostra uma panorâmica regional, tem de desenhar muitos dados, e deveria por isso ser optimizado. ii) apenas se considerou 1 utilizador, e portanto nenhum dos servidores terá sido usado na sua capacidade máxima.

Resultados e análise com 10 utilizadores

Repetiram-se os testes agora indicando ao JMeter que seriam simulados 10 utilizadores, e cada um faria 5 repetições, totalizando assim 500 pedidos a cada servidor.

Para a máquina “velha” obtiveram-se estes resultados:

Aggregate Report_1ediasigimsx10_opt

Com 10 utilizadores simulados já começam a aparecer números mais interessantes (2ª linha): mínimo de 616 ms, máximo de 41056 ms! O tempo de espera médio por cada mapa subiu para 11,4 segundos! Mas processaram-se mais mapas por minuto subindo para 51,7 mapas/min. O problema é que com este número de pedidos simultâneos o servidor está claramente a funcionar acima da sua capacidade de processamento, e demora demasiado tempo a processar cada um.

Para a nova máquina obtiveram-se os seguintes números:

Aggregate Report_1ediabeja019x10_opt

Com 10 utilizadores, o novo servidor obteve um mínimo de 145 ms e um máximo de 12066 ms. O tempo mínimo desceu, o que indicaria que o servidor teve capacidade de processamento suficiente para tantos pedidos, mas o tempo máximo quadruplicou, o que indicaria o oposto… E o tempo médio também triplicou chegando a 3,9 segundos por cada mapa gerado, o que também indica alguma sobrecarga. No entanto, foram processados 2,2 mapas por segundo!! O que é bastante impressionante – chegamos assim à marca mágica de 1 mapa em ½ segundo!

Conclusão

O novo servidor baseado num Xeon Core 2 com 4 cores e a 2,0GHz é muito mais rápido com o ArcIMS do que o antigo servidor baseado num Xeon Pentium 4 a 3,2GHz. Vejamos o resumo dos resultados dos testes de 1 utilizador e de 10 utilizadores:

 

Mapas/min

KB/s

Mapas/min

KB/s

Xeon P4 3,2GHz

21,3

5,1

51,7

12,4

Xeon Quad 2GHz

39,9

10,2

132

33,7

melhoria %

87%

100%

155%

172%
 

1 utilizador

10 utilizadores

Ou seja, com 1 único utilizador ligado, o novo Xeon Quad 2GHz foi capaz de processar mais 87% de mapas por minuto que o Xeon P4 3,2GHz. E com 10 clientes simultâneos o novo Xeon Quad foi capaz de processar mais 155% mapas por minuto!!

Além disso, enquanto que o Xeon P4 manteve a ocupação do cpu entre 76% e 94% (mais à volta dos 90%), o novo Xeon Quad manteve-se entre 30% e 58% (mais à volta dos 50%), distribuindo a carga pelos 4 cores, e nunca chegando aos 60% da capacidade de processamento. Haveria a possibilidade de afinar a configuração do ArcIMS para que use melhor todos os 4 cores, mas não era esse o objectivo, pelo contrário – pretendeu-se limitar o ArcIMS a 1 core no novo Xeon Quad para melhor comparar os 2 processadores. Claramente este objectivo não foi totalmente conseguido e a carga de processamento foi dividida pelos vários cores, sendo por isso uma comparação injusta com o Xeon P4 de 1 core apenas. No entanto, os números obtidos no teste de 1 utilizador simulado permitem uma comparação mais justa, e aqui é inegável a superioridade do novo processador, mesmo com uma velocidade de relógio 30% inferior.

Concluindo, mesmo funcionando com menos 1,2GHz o Xeon Quad Core é muito superior, obtendo um resultado 87% superior no teste mais “suave”. Impressionante…

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á.