Mosaicos de imagens em MapServer, com GDAL

Tempo de leitura: 12 min
Quando fica incumbido de publicar informação geográfica na web é quase sempre confrontado com esta questão – como publicar aquela colecção de ortos, composta por uma directoria cheia de ficheiros tif? (ou jpeg, ou ecw, ou sid…)

Este artigo nasceu num desses momentos, e da necessidade de determinar quais as opções existentes no MapServer, e saber qual delas é a melhor.

AVISO – artigo longo, com resultados de uma série de testes!!! Conclusões no final para os mais stressados…

Cenário inicial

Imaginemos um pequeno concelho que tem uma colecção de 45 ortofotomapas, em formato TIFF, não comprimido. Cada imagem ocupa 234MB, o que totaliza 10GB de imagens.

O objectivo é publicar estas imagens como uma cobertura que abrange o concelho, numa aplicação webgis, servida pelo MapServer.

A melhor opção

Para escolher a melhor forma de publicar as imagens é preciso saber o que é mais importante para nós: velocidade ou espaço em disco?

A verdade é que a compressão das imagens impõe uma penalização na velocidade com que os programas conseguem mostrar essas imagens. Essa penalização pode ser muito pequena ou muito grande, consoante o tipo de compressão e o tipo de imagem criada durante o processo de compressão. Geralmente, os ficheiros ECW e SID são extremamente comprimidos e relativamente rápidos. Em geral também, o formato JPEG2000 comprime muito as imagens mas é lento. O formato mais antigo JPEG é um compromisso entre os 2 grupos anteriores. Outra regra: assume-se que o MapServer é mais rápido com o formato TIFF, sem compressão, do que com formatos comprimidos, mas estas imagens ocupam muito mais espaço em disco.

Portanto, se a sua única preocupação é velocidade, e tem espaço em disco que não se importa de gastar com os seus ortofotomapas, em principio já sabe a sua resposta – use TIFFs sem compressão. Mas nada como verificar se esta “verdade” realmente se aplica aos seus dados em particular. Ahh, e não se esqueça de considerar o tráfego que vai gerar na rede se quiser usar os ortos em programas SIG desktop…

Temos ainda de saber como criar um layer em MapServer que use todas as imagens como um conjunto único. Afinal não quer que o utilizador seja obrigado a ligar 45 imagens uma-por-uma.

Para iniciar os testes converteram-se todas as imagens para os diversos formatos. Os tamanhos totais em cada formato ficaram assim:

Formato Dimensão
TIF+overheads 13,5 GB
JPG+overheads 915 MB
ECW 605 MB
JP2 509 MB

Os tamanhos indicados incluem imagens de resolução reduzida, chamadas overheads ou pirâmides. Mais sobre isto adiante…

Para ver os comandos de conversão do GDAL para cada formato pode consultar este artigo anterior – GDAL: Formatos comprimidos.

Usar mosaicos em MapServer

Um mosaico de imagens em MapServer é um layer do tipo RASTER que aponta para um conjunto de imagens em vez de uma só.

A forma tradicional de referenciar um mosaico é criando um shapefile que contém um quadriculado com as extensões das imagens. Este shapefile é criado com um comando do GDAL chamado gdaltindex.

Mas há uma nova opção. Podemos usar o formato VRT, um formato virtual que é constituído por um ficheiro de texto que indica a fonte dos dados e a forma como são organizados. Um ficheiro VRT pode listar um conjunto de imagens de forma a que o MapServer e outras aplicações o leiam como uma imagem única, quando na verdade será composto por todas as nossas imagens. O comando para criar um mosaico VRT é o gdalbuildvrt.

Por último, temos a opção de força bruta: juntar todas as imagens numa só, criando uma imagem enorme em disco que abrange toda a nossa área de interesse. Ou seja, no nosso caso em estudo esta imagem teria 10GB. Para criar este mosaico monolítico usamos o comando gdal_merge.

Vamos ao longo do artigo analisar cada opção e no final medir os tempos que o MapServer demora a visualizar cada tipo de mosaico.

Mosaico VRT

O GDAL suporta um formato virtual, VRT, que lista ficheiros já existentes e os descreve como um todo. Podemos agregar várias imagens numa só, definir um novo sistema de coordenadas, ou no caso de ficheiros vectoriais definir filtros de atributos, e renomear atributos, tudo sem alterar os ficheiros originais. Os ficheiros VRT são ficheiros de texto em formato XML e podem ser editados manualmente, ou criados com o gdal_translate ou com o comando gdalbuildvrt. Mais info aqui.

Para construir um mosaico a partir das imagens numa directoria, basta usar o seguinte comando:

gdalbuildvrt mosaico_tif.vrt directoria\*.tif

O ficheiro “mosaico_tif.vrt” é criado com o seguinte conteúdo:

<VRTDataset rasterXSize="40000" rasterYSize="20000">
  <SRS>LOCAL_CS[&quot;unnamed&quot;,UNIT[&quot;metre&quot;,1,AUTHORITY[&quot;EPSG&quot;,&quot;9001&quot;]]]</SRS>
  <GeoTransform>-1.6000000000000000e+004, 5.0000000000000000e-001, 0.0000000000000000e+000,-7.0000000000000000e+004, 0.0000000000000000e+000,-5.0000000000000000e-001</GeoTransform>
  <VRTRasterBand dataType="Byte" band="1">
    <ColorInterp>Red</ColorInterp>
    <SimpleSource>
      <SourceFilename relativeToVRT="1">tif\003941Argbx.tif</SourceFilename>
      <SourceBand>1</SourceBand>
      <SourceProperties RasterXSize="8000" RasterYSize="10000" DataType="Byte" BlockXSize="8000" BlockYSize="1"/>
      <SrcRect xOff="0" yOff="0" xSize="8000" ySize="10000"/>
      <DstRect xOff="0" yOff="0" xSize="8000" ySize="10000"/>
    </SimpleSource>

… seguem-se as restantes imagens em sucessivos SimpleSource até terminar a lista de imagens, para a 1ª banda. Depois inicia-se a 2ª banda:

</VRTRasterBand>
  <VRTRasterBand dataType="Byte" band="2">
    <ColorInterp>Green</ColorInterp>
    <SimpleSource>
      <SourceFilename relativeToVRT="1">tif\003941Argbx.tif</SourceFilename>
      <SourceBand>2</SourceBand>
      <SourceProperties RasterXSize="8000" RasterYSize="10000" DataType="Byte" BlockXSize="8000" BlockYSize="1"/>
      <SrcRect xOff="0" yOff="0" xSize="8000" ySize="10000"/>
      <DstRect xOff="0" yOff="0" xSize="8000" ySize="10000"/>
    </SimpleSource>

… seguem depois as imagens para compor a 3ª banda…

</VRTRasterBand>
  <VRTRasterBand dataType="Byte" band="3">
    <ColorInterp>Blue</ColorInterp>
    <SimpleSource>
      <SourceFilename relativeToVRT="1">tif\003941Argbx.tif</SourceFilename>
      <SourceBand>3</SourceBand>
      <SourceProperties RasterXSize="8000" RasterYSize="10000" DataType="Byte" BlockXSize="8000" BlockYSize="1"/>
      <SrcRect xOff="0" yOff="0" xSize="8000" ySize="10000"/>
      <DstRect xOff="0" yOff="0" xSize="8000" ySize="10000"/>
    </SimpleSource>

Finalizando-se o ficheiro assim:

   </VRTRasterBand>
</VRTDataset>

O QGIS 1.4.0 consegue ler este tipo de ficheiro, mostrando-o como uma só imagem:

Mosaico VRT visualizado no QGIS 1.4.0
Mosaico VRT visualizado no Quantum GIS 1.4.0.

Mas a performance é um problema. Para visualizar este mosaico, o QGIS tem de abrir as 45 imagens, ler todos os pixels, e mostrá-los. Ainda por cima, nesta escala a maior parte da informação é inútil porque não se distinguem todos os pixels. Para resolver este problema, criam-se overheads…

Criar Overheads

Os ficheiro TIFF originais têm 234MB cada um, e para visualizar todos os ortos o QGIS tem de ler todas as imagens, num total de 9GB, e mostrá-las numa escala onde o todo pormenor se perde. Este problema aplica-se a todos os programas SIG, incluindo o MapServer.

Para evitar este desperdício de tempo, criam-se overheads ou pirâmides, que são imagens de resolução decrescente gravadas num só ficheiro com extensão OVR. Assim, para uma escala pequena, como a do exemplo anterior, o QGIS tem apenas de ler e mostrar a imagem de pior resolução, já que se ajusta bem ao pormenor visível a essa escala. Consoante o utilizador faz “zoom in”, o QGIS selecciona a imagem com a resolução apropriada a essa escala, até que a partir de uma dada escala começa a mostrar a imagem original. Mas neste momento já só é necessário ler uma pequena porção da imagem para cobrir a área visível. E assim se acelera a visualização das imagens.

Para criar overheads usamos o comando do GDAL, gdaladdo:

gdaladdo -ro <ficheiro_de_imagem> 2 4 8 16 32 64 128

O parâmetro “-ro” indica que a imagem original não deve ser alterada, e portanto as overheads serão criadas num ficheiro separado, que terá a extensão OVR.

Os números depois do nome da imagem são os níveis a criar com resolução reduzida. O n.º 2 indica metade da resolução original, 4 é 1/4 e assim sucessivamente. Até que nível de redução calculamos depende da extensão geográfica das imagens e da sua resolução original. Uma forma fácil de determinar até que redução devemos chegar é consultar o QGIS…

O QGIS consegue agora criar overheads – acedendo às propriedades de um tema de imagem, na secção de Pyramids existe um botão para criar pirâmides (embora seja mais lento que o comando GDAL). Aqui o QGIS mostra a lista de resoluções que aconselha – é só contar quantos níveis são aconselhados pelo QGIS. Na imagem seguinte, podemos ver o QGIS a criar pirâmides para uma das imagens:

Construir pirâmides/overheads no Quantum GIS 1.4.0.
Construir pirâmides/overheads no Quantum GIS 1.4.0.

Como o QGIS indicava 7 níveis de pirâmides para as minhas imagens, foi o que usei no comando: 2, 4, 8, 16, 32, 64, 128 = 7 níveis.

Criei então overheads para o mosaico VRT. O resultado foi um ficheiro OVR com 776MB, ou seja, 33% do tamanho original. Esta é a taxa comum na criação de overheads e temos de prever este consumo adicional de disco.

Para testar as overheads, carreguei de novo o mosaico VRT no QGIS. Agora a imagem total foi mostrada quase instantaneamente. Mas ao fazer zoom in a velocidade degradou-se. Significa que o QGIS deixa de usar as pirâmides do VRT e passa a mostrar as imagens originais… penso que poderá ser um bug.

Portanto a solução passa por criar overheads para cada uma das imagens originais, e ver se assim o QGIS utiliza sempre as overheads.

Para isso usei um comando de linha que percorre todas as imagens TIFF numa directoria e executa o comando gdaladdo:

for %I in (directoria_originais\*.tif) do gdaladdo -ro %I 2 4 8 16 32 64 128

O resultado foi a criação de um ficheiro OVR para cada TIFF, cada um com 82MB (35% dos originais). Voltando a carregar o mosaico VRT no QGIS, o desempenho foi excelente em todos os níveis de zoom, provando que o QGIS usou sempre as overheads.

NOTA: por curiosidade abri o mosaico VRT no ArcGIS, e tudo funcionou perfeitamente, incluindo as overheads! Sabe-se há muito que o ArcGIS incluía o GDAL, não se sabendo bem para o quê. Pelos vistos, servirá também para ler VRT’s e overheads.

O caso ECW

O formato ECW agrada-me muito. Tem compressões equivalentes ao MrSID, é gratuito para comprimir imagens até 500MB, é rápido a visualizar, e já inclui pirâmides no próprio ficheiro. Poupa assim espaço em disco 2x: na compressão e nas pirâmides.

A questão que se coloca é saber até que ponto vai a penalização na performance do MapServer ao ter que descomprimir os ECW para os visualizar a cada Zoom e a cada Pan.

Para criar um mosaico VRT com ECW’s tivemos de converter todos os TIFF originais, com o seguinte comando:

for %I in (directoria_originais\*.tif) do gdal_translate -of ECW -co TARGET=90 %I directoria_destino\%~nI.ecw

As imagens originais passaram de 13GB (contando com as overheads) para 605MB – poupando 95% do espaço! Podiamos ainda comprimir mais, mas neste estudo preferi manter os defaults…

Criámos um novo VRT com as imagens ECW, e testámos no QGIS. A visualização foi muito rápida e sem degradação ao aumentar a escala.

O caso JPEG

Este formato é muito apreciado por ser familiar, bastante rápido, e apresentar taxas de compressão bastante atractivas (embora não consiga acompanhar a compressão dos novos formatos como MrSID e ECW). A questão que se coloca é saber se a multa devida pela descompressão se nota ou não em MapServer. Não esquecer que será necessário criar overheads. Neste teste optei por criar as pirâmides também em formato JPEG, por forma a ser mais fiel ao formato. Se este formato for suficientemente rápido poderá ser uma boa alternativa ao TIFF. Para criar pirâmides em formato JPEG pode-se usar o seguinte comando (está tudo documentado na página do gdaladdo):

gdaladdo --config COMPRESS_OVERVIEW JPEG --config PHOTOMETRIC_OVERVIEW YCBCR --config INTERLEAVE_OVERVIEW PIXEL imagem 2 4 8 16 32 64 128

O resultado foram imagens JPEG e OVR ocupando 915MB (93% de compressão). Em QGIS o resultado foi mais uma vez excelente… visualização rápida de inicio, sem degradação com os zoom in… Além da velocidade, fiquei surpreendido com a compressão atingida e com a óptima qualidade das imagens ao ver todo o mosaico.

O caso JPEG2000

Este formato é uma alternativa aos formatos ECW e MrSID, mas mais aberto. No entanto, tem-se revelado sistematicamente lento demais para o poder utilizar a não ser para fins de arquivo.

Decidi mesmo assim inclui-lo no teste. Converti todas as imagens TIFF para JP2, e criei um mosaico VRT. No teste com QGIS, a velocidade foi muito rápida de início, apenas demorando um pouco mais com o aumento da escala de visualização. No entanto, a sua qualidade de imagem ao ver todo o mosaico foi excelente.

Mosaicos Shapefile (TILEINDEX)

A forma tradicional de usar mosaicos no MapServer é criar um shapefile com polígonos que cobrem a área de cada ortofotomapa. Este shapefile é depois referenciado no mapfile em vez do ficheiro VRT.

A questão que se coloca é saber se a utilização de um VRT implica uma redução de performance, quando comparada com a utilização de um shapefile.

Criei por isso mosaicos usando shapefiles, e medi os tempos de visualização em MapServer. Afinal, nem sempre novos métodos se revelam melhores que os antigos. O comando que usei foi o seguinte:

gdaltindex mosaico.shp directoria\*.tif

Não descobri forma de visualizar este tipo de mosaico em QGIS…

Mosaicos monolíticos

A última variante de mosaicos conhecida pela humanidade – juntar todas as imagens numa única, e gigante, imagem.

Para criar este mosaico vamos usar a ferramenta gdal_merge, que é um script python incluído no GDAL (pelo menos na versão FWTools). O plano é juntar todos os tiffs originais, criando um novo tiff. Mas nesta altura, o espaço em disco começava a escassear…

Para poupar algum espaço em disco, optei por usar compressão JPEG. Como o ficheiro poderá ser maior que 4GB usei a opção “bigtiff=yes” (por limitações do formato tiff). E como o ficheiro cobrirá uma grande extensão geográfica, para acelerar o acesso a pequenas áreas, usei também a opção “tiled=yes”. Assim, o comando para criar o mosaico foi o seguinte:

gdal_merge -o mosaico.tif -of gtiff -co compress=jpeg -co tiled=yes -co tfw=yes -co bigtiff=yes -v imagens_originais\*.tif

Isto produziu um ficheiro com 3,5GB, dada a compressão JPEG dentro do ficheiro TIFF. Confuso? Sucede que o formato TIFF suporta uma variedade de processos de compressão. Um deles é o JPEG. Claro que esta compressão poderá comprometer a velocidade do mosaico, mas não tinha mais espaço em disco para criar um mosaico sem compressão.

O passo seguinte foi criar overheads/pirâmides para este mosaico. Também aqui optei por criar pirâmides comprimidas em JPEG, usando o seguinte comando:

gdaladdo --config COMPRESS_OVERVIEW JPEG --config PHOTOMETRIC_OVERVIEW YCBCR --config INTERLEAVE_OVERVIEW PIXEL -ro mosaico.tif 2 4 8 16 32 64 128

Este comando criou um ficheiro OVR com 320MB, sendo apenas 9% do original devido à compressão usada. No total, a compressão foi de 72%. Nada mau…

Em QGIS este mosaico foi extremamente rápido, mostrando o ficheiro numa fracção de segundo, e zooms e pans foram também muito rápidos. Definitivamente, foi das melhores prestações senão a melhor.

NOTA: seria interessante criar um mosaico enorme ECW, mas não foi possível por causa do limite de 500MB imposto pela licença gratuita do compressor ECW (incluído no GDAL).

E agora… com MapServer

Todos os testes foram efectuados num portátil,  com Windows 7, 32-bit, 2 GB de memória, e MS4W 2.2.7 (inclui o MapServer 5.0.2). Portanto, podemos esperar melhores resultados num PC ou servidor, onde o disco rígido será em princípio bastante mais rápido. Os testes foram feitos com uma pequena aplicação OpenLayers, que inicia com um mosaico visível em toda a extensão, sendo depois feitos 4 zooms no centro do mapa, manualmente.

Os tempos foram obtidos no log produzido pelo MapServer. Para criar este log, inseriram-se as seguintes linhas no mapfile:

MAP
    CONFIG  "MS_ERRORFILE" "/ms4w/mapserver.log"
    DEBUG 5

O mapa foi configurado para gerar imagens em JPEG, através do AGG, usando esta secção no mapfile:

  OUTPUTFORMAT
    NAME jpg
    DRIVER AGG/JPEG
    IMAGEMODE RGB
  END

Para definir um layer com um mosaico VRT usou-se a seguinte sintaxe no mapfile, indicando o ficheiro VRT no tag DATA:

   LAYER
    NAME 'mosaicoTotal_tif'
    TYPE RASTER
    DUMP true
    TEMPLATE fooOnlyForWMSGetFeatureInfo
    EXTENT -16500.000000 -83122.641509 4500.000000 -66877.358491
    DATA 'mosaicoTotal_tifoverhds.vrt'
    METADATA
      'ows_title' 'mosaicoTotal_tif'
    END
    STATUS OFF
    TRANSPARENCY 100
    PROJECTION
    'init=EPSG:27492'
    END
  END

Note-se que foram criados vários layers deste tipo, havendo um VRT para cada tipo de imagem: TIFF, ECW, JPG, JP2.

Para os mosaicos baseados em shapefile usou-se a seguinte sintaxe (TILEINDEX e TILEITEM no lugar de DATA):

   LAYER     NAME 'mosaicoTotalshp_tif'     TYPE RASTER     DUMP true     TEMPLATE fooOnlyForWMSGetFeatureInfo     EXTENT -16500.000000 -83122.641509 4500.000000 -66877.358491     TILEINDEX 'mosaicoshp_tif.shp'     TILEITEM 'location'     METADATA       'ows_title' 'mosaicoTotalshp_tif'     END     STATUS OFF     TRANSPARENCY 100     PROJECTION     'init=EPSG:27492'     END   END

Resultados do MapServer

Usando mosaicos VRT obtiveram-se os seguintes tempos:

Zoom TIFF+overhds ECW JP2 JPG TIFmonolítico
Inicial 0.298 0.744 1.108 0.81 0.094
Z1 0.354 0.609 3.205 0.945 0.259
Z2 0.419 0.761 3.173 1.018 0.291
Z3 0.415 0.709 3.053 1 0.284
Z4 0.65 0.658 2.533 0.966 0.276
Totais 2.136 3.481 13.072 4.739 1.204
Espaço disco 13,5GB 605MB 509MB 915MB 3,85GB*

*usando compressão JPEG, e incluindo overheads.

E em gráfico (a última categoria “Totais” representa a soma de todos os zooms, evidenciando os ganhos acumulados nos formatos mais rápidos):

Desempenho de mosaicos VRT em MapServer.
Desempenho de mosaicos VRT em MapServer.

E o vencedor é… o mosaico monolítico, destacadíssimo. Dos mosaicos VRT, o mais rápido foi o mosaico de TIFF’s não comprimidos, como se supunha de início, com o formato ECW em 2º lugar, bastante melhor que o JPEG em 3º. O formato JPEG2000 é completamente desaconselhado.

Usando mosaicos baseados em Shapefile, obtiveram-se os seguintes resultados:

Zoom TIFF+overhds ECW JP2 JPG TIFmonolítico
Inicial 0.287 2.374 4.206 2.366 0.094
Z1 0.337 2.355 6.121 2.355 0.259
Z2 0.247 1.082 3.583 1.139 0.291
Z3 0.186 0.656 3.069 0.76 0.284
Z4 0.176 0.657 2.412 0.926 0.276
Totais 1.233 7.124 19.391 7.546 1.204
Espaço disco 13,5GB 605MB 509MB 915MB 3,85GB*

*usando compressão JPEG, e incluindo overheads.

E em gráfico:

Desempenho de mosaicos SHP em MapServer Desempenho de mosaicos SHP em MapServer

 

E o vencedor é… de novo o TIFF monolítico, mas havendo várias alterações. Só o mosaico de TIFF’s não comprimidos melhorou o desempenho em quase 100%, reduzindo de 2,1s para 1,2s. Todos os outros pioraram bastante, por vezes duplicando o tempo de visualização. Não encontrei explicação para esta penalização. O shapefile continha apenas 45 polígonos, sendo difícil acreditar que possa causar tão grande penalização, mesmo considerando que o MapServer tem de determinar quais os polígonos visíveis num momento, determinar as áreas de cada um, e abrir as imagens correspondentes… parece-me pouco trabalho para explicar diferenças de 1,6s como no caso dos ECW… Mas factos são factos.

Conclusões

Se não existirem impedimentos, deverá unir as suas imagens num mosaico único, em formato TIFF, comprimido em JPEG, e criar pirâmides também com compressão JPEG. Obtém o maior desempenho possível e com o extra de poupar 70% do espaço em disco. Esta abordagem foi simplesmente a melhor… mais vale guardar os seus originais num arquivo.

Quanto aos mosaicos VRT mostraram ser uma boa opção. Quase todos os formatos tiveram melhor desempenho quando usados através deste formato virtual, do que usando um mosaico baseado em shapefile. A excepção foi o mosaico de TIFF’s não comprimidos. Aqui, usar o mosaico shapefile foi melhor, muito melhor.

Nota Final

O formato VRT não serve apenas para criar mosaicos sem alterar as imagens originais, e por isso poderá ser uma opção atractiva em certas situações. Podemos, por exemplo, definir uma deslocação de +200km, +300km sem andar a editar ficheiros de coordenadas – alguém se lembra de passar por isto?? Parece-me que sim.

Cábula de Comandos

Todos os comandos usados no artigo…

Criar mosaico VRT a com imagens de uma directoria:
gdalbuildvrt mosaico_tif.vrt directoria\*.tif
Criar overheads/pirâmides de uma imagem, num ficheiro separado
gdaladdo -ro imagem.tif 2 4 8 16 32 64 128
Criar overheads/pirâmides para todas as imagens TIFF numa directoria
for %I in (directoria_originais\*.tif) do gdaladdo -ro %I 2 4 8 16 32 64 128
Converter todos os TIFF numa directoria para ECW noutra directoria
for %I in (directoria_originais\*.tif) do gdal_translate -of ECW -co TARGET=90 %I directoria_destino\%~nI.ecw
Criar overheads/pirâmides com compressão JPEG
gdaladdo –config COMPRESS_OVERVIEW JPEG –config PHOTOMETRIC_OVERVIEW YCBCR –config INTERLEAVE_OVERVIEW PIXEL imagem.tif 2 4 8 16 32 64 128
Criar mosaico baseado em shapefile das imagens TIFF numa directoria
gdaltindex mosaico.shp directoria\*.tif
Criar um mosaico monolítico tif, com compressão jpeg, das imagens tiff numa directoria
gdal_merge -o mosaico.tif -of gtiff -co compress=jpeg -co tiled=yes -co tfw=yes -co bigtiff=yes -v imagens_originais\*.tif
MapServer: configurar um mapfile para gerar um ficheiro log com tempos
MAP    CONFIG  “MS_ERRORFILE” “/ms4w/mapserver.log”    DEBUG 5

20 thoughts on “Mosaicos de imagens em MapServer, com GDAL

  1. Excelente artigo, parabéns!

    Uma outra opção que será bom ter em conta é recorrer ao conceito de Cache. Este conceito irá aumentar a performance da disponibilização e reduzir o espaço em disco. Por outro lado temos que ter em atenção o que necessitamos de fazer com as imagens já que cache poderá ter limitações quando queremos usar múltiplos sistemas de coordenadas.

    Para implementarmos este conceito o procedimento será:

    – Criar um serviço de imagem com todas as imagens originais (não as alterando nem mosaicando);
    – Publicar esse serviço no nosso servidor WebSIG;
    – Fazer cache a esse serviço optimizando o quer o tamanho de imagem quer o tipo de formato (por exemplo, tiles de 256x256px a PNG 32b)
    – Guardar as imagens originais em arquivo

    Deste modo garantimos um melhoramento na performance, uma redução do espaço em disco e a protecção das imagens originais.

    Um abraço,
    Sandro

  2. Olá Sandro.
    É bem verdade. Para MapServer há 2 opções de servidores de tiles que são mais usadas: o TileCache, baseado em Python, e o GeoWebCache, baseado em Java e agora incluído no GeoServer. Curiosamente, só usei ainda o TileCache, mas numa versão adaptada a Jython (Java), para usar num site ArcIMS… grandes voltas!

  3. Muito bom o artigo, bem explicado, passo-a-passo, bem didático. Meus parabéns. Só tem um adendo: você saberia me informar a velocidade de leitura do disco rígido?

  4. Luigi, os testes foram feitos no meu portátil com um disco MK1646GSX (HDD2D92): 2.5″ HDD 160GB, de 5400 rpm. Mais info neste link.

    Uma outra coisa a ter em conta é que não simulei vários utilizadores e portanto pode haver alterações nas performances quando a carga no servidor sobe…

    Duarte

  5. Olá Duarte, óptimo artigo. Escrevo só para lembrar que, para a grande maioria das situações onde é preciso usar GDAL para manusear rasters, já não é “obrigatório” usar a linha de comandos. Com o plugin “gdal tools” para QGIS

    http://www.faunalia.pt/plugins#gdaltools

    temos basicamente tudo o que é preciso nas situações mais comuns (funciona também para trabalhos “batch”). O Plugin será melhorado, por exemplo contamos de acrescentar os novos tools disponibilizados pela nova versão 1.7.1 da biblioteca GDAL, como por exemplo gdaldem.

    Para pedidos e reportar bugs se pode usar o bug tracker próprio do projecto

    https://trac.faunalia.it/GdalTools-plugin/

    Abraços

    — Giovanni —

  6. Oi Giovanni. O QGIS está a avançar a uma velocidade impressionante. Com a quantidade de plugins existente, está a tornar-se uma máquina de geoprocessamento. Este plugin dispensa conhecer a linha de comando, o que é óptimo. Uma sugestão: se o gdal não estiver na PATH, ter uma opção de configuração para indicar o caminho para a instalação do GDAL/FWTools/… .

    Duarte

  7. Olá Duarte,
    por enquanto o plugin é feito para funcionar correctamente nas instalações de QGIS feitas com o installer osgeo4w, que é o que usamos nas plataformas Windows, também porque o installer clássico não inclui GRASS, uma “ferramenta” para nós indispensável.

    Abraços

  8. Duarte,

    Excelente artigo e iniciativa!
    Este é um assunto que dá pano para mangas, e muito solicitado por quem se inicia nesta aventura dos Web-SIG OS. É bom que outros sigam este exemplo do Duarte, em partilhar a sua experiência!
    Posso sugerir, a quem queira aprofundar este assunto, a excelente workshop de Sydney, a que tive o prazer de assistir, em Inglês e dedicada à alternativa Geoserver + PostGIS:

    Making Maps Fast – Performance tuning and Tile Caching
    http://2009.foss4g.org/workshops/#workshop_05

    Abraço,
    Ricardo Pinho

  9. Caro Duarte, nem preciso dizer sobre a enorme contribuição e esclarecimento que vc atribui a este tema. Eu já trabalhei com MapServer e agora estou modelando dados espaciais no Autodesk MapGuide Enterprise 2010. Encontrar a fórmula mais adequada para publicar grandes imagens na Web não é fácil e o seu artigo foi muito enriquecedor ao compartilhar as suas experiencias. Em algumas pesquisas na Web, eu encontrei o MapTiler, que gera tiles das imagens com pirâmides em PNG e voltado para o Google Maps e Earth. Seria possível agregar esta tecnologia ao MapGuide, pois isso resolveria completamente na questão da agilidade na renderização das imagens. Caso alguém tenha alguma experiencia neste sentido, seria muito bom acrescentar a este contexto. Parabéns pelo artigo e pela iniciativa.

  10. Olá, André, e obrigado pelo elogio!

    Na verdade, começo a pensar que o artigo começa a estar desactualizado… com o tempo, os servidores e clientes web começam a suportar tiles de forma universal… e os programas para desktop (não web) começam a seguir no mesmo caminho – por exemplo, o QGIS suporta já serviços TMS e WMST. O ArcGIS suporta também tiles mas no formato da ESRI.
    Não há quem bata um servidor de Tiles em termos de velocidade, mas também têm as suas limitações, como projecção e escalas fixas… como sempre, há que escolher bem.
    Quanto ao MapGuide, não conheço o produto a ponto de saber se consome caches de Tiles, TMS, ou WMST… se sim, então pode usar um TileCache para criar a cache, e ligá-lo ao MapGuide.

    Abraço,
    Duarte

  11. É verdade. Trabalhar com Tiles de tamanho minusculo é extremamente rápido em aplicações Web. O MapGuide publica mapas atraves do Ajax Viewer (que faz TileCache das imagens e é muito rápido) e do Fusion (que não suporta TileCache). Este ultimo ambiente possui muito mais possibilidades, visual sofisticado e vantagens em desenvolvimento, porém, ainda é sofrível ao renderizar imagens grandes. Ganha-se de um lado, mas perde-se em aspectos importantes do outro. Eu vou pesquisar mais sobre os serviços TMS e WMST. Valeu pela dica. Conforme vou avançando, posto aqui prá compartilhar as experiencias.

    Abraços,

    André Oliveira

  12. Olá Duarte,

    Primeiramente, parabéns pelo blog.

    É o seguinte, estou desenvolver um sistema de animação com raster, utilizando MapServer e OpenLayers . Ou seja, são dados de diversos anos e a ideia é fazer uma animação de transição ano a ano. E, para fazer isso estou buscando uma forma que o carregamento dos rasters sejam rápido (para assim ter uma transição eficiente entre os rasters). Vc tem alguma sugestão ou exemplo como posso fazer essa animação?

    obrigado.

  13. Bom dia Duarte,

    Parabéns pelo blog!

    Estou com um problema que minha imagem tiff está com 32 gb. Preciso apenas comprimir o máximo possível sem perder muita qualidade e não possuo muito entendimento sobre a criação de comandos gdal. O método usado neste post de mosaico monolíticos, me pareceu o melhor método. Porem não estou conseguindo aplicar ele para apenas comprimir minha imagem. Se possível gostaria de um suporte no comando gdal.

    Obrigado

  14. Gustavo, as minhas desculpas pela demora na resposta, mas não tenho notificações para os comentários… e assim só descubro tarde… algo a resolver.
    Quanto à sua imagem tiff de 32gb, o que pode fazer depende da imagem. Já está comprimida? Se não estiver, pode comprimir e ver o que fica. Se usar uma compressão agressiva pode conseguir chegar a 5-10gb. Se já estiver comprimida, pode tentar dividi-la em quadrículas regulares, com o tamanho que pretenda.
    Mas a maior questão será perceber porque quer reduzir a imagem? Se for para visualizar em programas desktop ou para publicar na web não tem de comprimir a imagem. Tem só de adicionar as overviews (ou pirâmides em alguns programas). Se for para arquivar e poupar espaço em disco, então o melhor é comprimir num formato que mantém a qualidade (o jpeg2000 é bom neste caso). Se for para transmitir a imagem toda pela rede, então terá mesmo de comprimir ou dividir em pedaços menores.
    De qualquer forma, pode usar o qgis, as ferramentas no menu raster são muitas baseadas em gdal, e mostram o comando final. É muito útil para aprender o que o gdal consegue fazer.
    Por exemplo, para comprimir uma imagem pode usar a opção Raster->Traduzir, e escolher a opção compressão Jpeg. Aqui pode alterar o parâmetro JPEG_QUALITY para ter mais ou menos compressão. Se usar o valor 95 terá uma compressão enorme mas também uma queda na qualidade.

Deixe um comentário

O seu endereço de email não será publicado. Campos obrigatórios marcados com *