Arquivo de etiquetas: GDAL

Mosaicos com áreas transparentes

Neste artigo regresso a um assunto já familiar neste blog – criar mosaicos de ortofotomapas usando o GDAL – (sim eu sei, outra vez?) mas como tenho andado às voltas com as áreas sem informação, que surgem negras nos mosaicos pensei em postar o que acabei por fazer. A solução final é usar máscaras, e não bandas alfa como habitual. Vamos ver como e porquê… assume-se já alguma familiaridade com o GDAL, mas pode sempre saltar as partes teóricas aborrecidas e ver os comandos usados no final do artigo ;) Ler artigo completo

QGIS – Revisitando ficheiros DXF

O QGIS há muito tempo que lê ficheiros DXF ASCII, aproveitando sempre os melhoramentos que a biblioteca OGR vai trazendo com as novas versões.

Estando a planear introduzir o QGIS na empresa de forma generalizada, tive que revisitar esta função, dado que ler CAD é uma função essencial para muitos utilizadores.

Update 2013-06-05: O problema já foi resolvido. A versão de desenvolvimento já permite abrir ficheiros dxf e escolher que tipo de geometria queremos carregar. Realmente, trabalhar assim é uma maravilha.
Ler artigo completo

MDT 30m para Portugal

Update: adicionei um comentário (1/6/2010) sobre a qualidade deste MDT, avaliada pelo Prof. José Alberto Gonçalves.

Em Junho do ano passado (2009), falei neste artigo sobre o modelo digital do terreno global disponibilizado online e gratuitamente pelos EUA e Japão. Na altura terminei o texto com a esperança de que algum voluntário se oferecesse para obter os dados para Portugal, os processar e disponibilizar à comunidade. Hoje, conheço apenas a iniciativa da ESRI Portugal, que fez estes passos e disponibilizou o MDT aos seus utilizadores através do ArcGIS Online, permitindo o download dos dados já processados ou a sua utilização no ArcGIS de forma remota. O acesso remoto inclui até acesso via WMS, permitindo assim o acesso por utilizadores de outro software (não-ESRI). O endereço WMS pode ser consultado na lista de servidores nacionais WMS do grupo OSGeo-PT. Basta fazer copy/paste para um programa como o QGIS ou o gvSIG para utilizar este MDT. Mais informação sobre o serviço e todas as formas de lhe aceder pode ser consultada no ArcGIS Online.

Mas para os utilizadores que preferem fazer o download dos dados, a solução da ESRI não é tão universal, já que o formato dos dados permite apenas a sua utilização em ArcGIS – isto porque o mdt é disponibilizado numa File Geodatabase.

Assim, pensei em fazer esse pequeno trabalho, e peguei no mdt que tinha tratado na altura, e coloquei-o online. Os passos que fiz foram estes:

  • converti o mdt para o formato mais universal possível – GeoTIFF;
  • reprojectei os dados para o sistema de coordenadas também mais usado – Hayford-Gauss Datum 73;
  • comprimi o resultado num arquivo 7zip;
  • coloquei numa partilha pública no SkyDrive (serviço da Microsoft que oferece 25GB gratuitos).

Pode assim obter o mdt de 30m para Portugal acedendo a esta página e clicando na opção “Transferir”.

Algumas Notas

A reprojecção foi aplicada aos dados originais usando os parâmetros do IGP para a transformação Bursa-Wolf de WGS84 para DT73.

O ficheiro GeoTIFF foi criado usando o GDAL, e foi criado sem compressão (343MB), para depois conseguir atingir uma compressão elevada usando o 7zip. Só assim consegui um arquivo com menos de 50MB, o máximo permitido pelo SkyDrive para um só ficheiro.

Para descomprimir o arquivo 7z é preciso usar o programa 7zip que podemos obter no site www.7zip.org. Update: é necessário o 7zip 91.0 Beta para descomprimir!

O valor que representa ausência de dados no GeoTIFF é 32767. Pode ser confirmado usando o seguinte comando do GDAL:
gdalinfo –nogcp –nomd –norat –noct mdt_aster_pt_D73_GeoTIFF.tif
Depois de obter o GeoTIFF de 343MB, podemos convertê-lo para um GeoTIFF comprimido de 54MB, o que permite poupar algum espaço em disco. O comando para esta conversão é o seguinte:
gdal_translate -of GTIFF -co COMPRESS=LZW -co PREDICTOR=2 -co TFW=YES mdt_aster_pt_D73.tif mdt_aster_pt_D73_lzw.tif

Licença ASTER

A licença destes dados pode ser consultada aqui:
Open Access. Data from ASTER GDEM
https://lpdaac.usgs.gov/lpdaac/about/news_archive/wednesday_october_07_2009

Uma vez que os dados foram reprojectados, podem ser distribuídos.

Mais informação sobre o MDT ASTER:
http://www.gdem.aster.ersdac.or.jp/

Utilizar no QGIS

Ao usar este mdt no QGIS, foi apenas necessário ajustar as propriedades da simbologia:

  • Load min/Max values  from band: usar a opção Estimate, e clicar no botão Load;
  • Contrast enhancement: Current com opção Stretch to MinMax.

Também é essencial criar pirâmides para que a visualização seja rápida e eficaz, dado o tamanho do ficheiro (isto pode ser feito acedendo às propriedades do tema no QGIS 1.4.0).

O aspecto visual depois de aplicadas estas opções foi o seguinte:

image

Nota: a memória ocupada pelo QGIS sobe até 500-800MB ao abrir o ficheiro, para depois estabilizar em valores mais razoáveis de 50-90MB.

Com a resolução de 30m, o QGIS indica a escala 1:140.000 como sendo a “best scale”, mas parece-me perfeitamente aceitável até à escala 1:50.000.

Para usar como carta hipsométrica, podemos ainda criar uma rampa de cores no QGIS. Recriei a rampa de elevação do GRASS, com os seguintes passos:

  • nas propriedades do tema, na simbologia, seleccionar a opção “Colormap”;
  • na categoria “Colormap”, escolher 6 entradas e clicar em Classify;
  • na opção “Color interpolation” escolher a opçãoo “Linear”;
  • inserir as cores da rampa do GRASS em cada classe;
  • clicar em OK e ver os resultados.

Adaptei um pouco as cores ao meu gosto, e também os intervalos de altitude definidos pelo QGIS (apenas oferece o método de intervalos iguais, o que não é o mais apropriado para este fim). O resultado final foi este:

image

image

Nota Final

O facto de ter o MDT como ficheiro local permite operações que o acesso via WMS não suporta, como análises topográficas, alteração da simbologia, extracção de áreas de interesse, etc.

O QGIS mais uma vez revela-se como uma ferramenta que impressiona pela abrangência da sua funcionalidade. Notamos ainda alguns pontos a melhorar (como a ausência de rampas de cores para ficheiros raster), mas conseguimos já suprir essas ausências com trabalho manual e um pouco de imaginação. Excelente.

Aliás, vários comandos GDAL que usei podem agora ser realizados com o QGIS graças ao novo plugin GDAL Tools, desenvolvido pela Faunalia. Começo a ter aquele sentimento familiar de ser um dinossauro…

Para terminar, se alguém detectar problemas com este ficheiro, por favor informe-me, por email ou deixando aqui um comentário.

Até à próxima…

Mosaicos de imagens em MapServer, com GDAL

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

Balanço Open Source para SIG

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

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: conversão entre formatos de imagem SIG

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.

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

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

O que consegue o GDAL fazer?

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

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

… e a lista não termina aqui…

Instalação

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

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

Primeiros comandos GDAL

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

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

gdalinfo c:\directoria_de_exemplo\imagem.tif

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

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

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

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

gdalinfo --formats

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

Até breve!