Separador OSM

Só uma nota rápida para quem não conhece, e fico sempre surpreendido com a quantidade de pessoas que me vão dizendo que não conhecem, o OSM é um projecto internacional, comunitário, de levantamento de dados cartográficos por hobbyistas (chamados pomposamente de voluntários). E tem sido um fenómeno enorme de popularidade, e vale muito a pena investigar. Até porque a sua qualidade é tal que é usado em vários produtos para navegação pessoal. Um dos últimos convertidos é a MapQuest - faça uma visita se quiser ficar impressionado. O OSM começou por levantar a rede rodoviária, e abrange hoje uma série de outras categorias de dados, especialmente pontos de interesse. Mas fiquemos por aqui sobre o projecto OSM em si.

Continuando…

Dizia eu, Beja praticamente não tinha dados levantados, e eu como iniciado entusiasta, lá vectorizei algumas vias principais: usando o OSMTracker andei de carro com o meu telemóvel, que tem GPS, passei os dados para o PC, e usei o JOSM para “limpar” os dados e preencher os nomes das ruas, e finalmente passei tudo para o servidor. “Charân” – cidade de Beja online! (Mas muito poucochinho…). Note-se que agora as coisas estão bem mais simples – vectorizamos por cima dos ortos do Bing usando o excelente Potlatch2, e falta só atribuir nomes às vias. Para isso podemos usar o Walking Papers. (isto porque não podemos copiar os nomes das ruas do Bing.)

Andei distraído algum tempo, e agora que tenho um tablet Android, comecei a testar programas de navegação que usam dados OSM (que são muitos). E é quando vejo a cidade de Beja completamente cartografada! Vias, Pontos de Interesse, áreas verdes, cemitério… farmácias, parques de estacionamento, supermercados… impressionante.

Mas de quem é a criança? Quero dizer, quem foi o cartógrafo de serviço?

Histórico do OSM

Devem existir outras formas de fazer isto, mas eu usei o ITO OSM Mapper, e deixo aqui a dica.

Este site permite visualizar para uma dada zona quais as edições feitas nos últimos 3 anos, identificando os utilizadores, as datas de edição, e o n.º de vias editadas em cada sessão. Espectáculo.

Então, observem. Esta imagem mostra as sessões de edição feitas em Beja no último ano. Podemos assim perceber as sessões de edição que mais contribuíram para o mapa(cada sessão terá uma cor).

Começa a ser claro, que um dos editores sobressai… alterando a caixa “View”, passamos a ver as edições por utilizador:

Olá… Sr. Luís Coentro!! Quero aqui deixar os meus parabéns!! Se um dia nos encontrarmos, faço questão de lhe oferecer uma imperial no Pulo do Lobo, para me contar a história de como mapeou a cidade de Beja!

Mais a sério

O OSM é um projecto com um potencial incrível. As organizações que necessitam de uma rede viária cartografada, fácil de usar, e de manter, podem contribuir e usufruir deste repositório, beneficiando dele e beneficiando todos os co-cidadãos pelo caminho. As câmaras municipais são potenciais utilizadores/produtores óbvios. As escolas com cursos técnico-profissionais podem também usufruir imenso deste projecto, enquanto ao mesmo tempo contribuem para o mesmo. Aliás, projectos de cooperação câmaras-escolas teriam toda a lógica, e seriam duplamente úteis. Sabendo das dificuldades em obter dados geográficos utilizáveis, e da dificuldade em encontrar projectos escolares úteis, aqui fica a sugestão.

Já agora ficam aqui alguns contactos para a malta tuga do OSM: lista de email osm-pt, páginas pt no wiki OSM, página no wiki da OSGeo-PT sobre o OSM, lista de email OSGeo-PT.

Bons mapas.

Partilhar

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:

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:

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…

Partilhar

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:

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:

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

Finalizando-se o ficheiro assim:

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

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:

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.

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:

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:

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):

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:

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:

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:

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:

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

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:

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

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:

*usando compressão JPEG, e incluindo overheads.

E em gráfico:

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…

Partilhar

Portanto é caso para dizer, em Inglês claro, OhOhOh Merry Christmas!

Update - links em falta:

documento do OS referido acima: Policy options for geographic information from Ordnance Survey.

mais info: artigo no Mapperz.

Partilhar

• PostgreSQL e ESRI – parte 1, que discute as opções disponíveis, e o trunfo do SQL Espacial.
• PostgreSQL e ESRI – parte 2, que discute a instalação e as 2 formas de conexão entre o ArcGIS e PgSQL.

Depois de instalar o PostgreSQL+PostGIS+ArcSDE, e configurar o formato de armazenar os nossos dados na bd, para que usemos as geometrias nativas do Pg em vez dos objectos ESRI (para compatibilidade com software Open Source), teremos de definir que utilizadores vamos criar na bd, e a forma como organizamos os dados.

Bases de Dados e Utilizadores

A organização interna do PostgreSQL é algo semelhante à do SQL Server, e bastante diferente do Oracle. Por exemplo, um servidor PostgreSQL contém várias bases de dados, ao contrário do Oracle onde uma bd corresponde a um serviço ou instância. Se quisermos mais bd’s temos de criar novas instâncias, com configuração independente, conexões, dados, utilizadores, etc.

Durante a instalação do PostGIS é instalada uma bd chamada “postgis”, e podemos usá-la para armazenar os nossos dados geográficos ou podemos criar outras bd’s ao nosso gosto…

Podemos assim guardar a informação geográfica na base de dados postgis que é criada durante a instalação do PostGIS. Ultrapassada esta decisão, temos de criar e configurar os utilizadores que vamos usar para carregar a nossa informação, evitando usar os utilizadores de sistema, criados durante a instalação, que são o “postgres” e o “sde” (utilizador criado pela instalação do ArcSDE e que serve para efectuar a sua gestão). A criação de novos utilizadores é muito recomendado e geralmente é omitido nos tutoriais e instruções de instalação…

Pessoalmente, prefiro configurações com poucos utilizadores, criando apenas 1 login para cada uso: os utilizadores do SIG usam o mesmo login para a visualização, e um outro para a gestão dos dados (criação, edição, eliminação de layers, metadados, etc.). Aplicações webgis podem partilhar também um único login para acesso aos dados. A abordagem oposta é a de criar um login por utilizador, ou usar a autenticação integrada do Windows (em que as contas de utilizador de domínio são também usadas na bd). Esta é uma decisão que se repercutirá mais tarde na manutenção e monitorização da actividade da bd. Se começarmos com a abordagem mais simples (poucos logins), podemos mais tarde introduzir o esquema de autenticação por utilizador do SIG.

Uma das razões apontada para usar o esquema de mais utilizadores, é que podemos controlar exactamente quem está ligado, ou mesmo até saber quem editou os dados numa dada altura. E esta é uma argumentação válida. Mas a abordagem mais simplista, de poucos logins, também permite algum controlo, uma vez podemos ver no servidor a listagem de conexões activas, e estas são descritas não só pelo login usado, mas também pelo nome da máquina de onde são efectuadas. Como em geral, uma máquina pertence a um utilizador, acabamos por saber que utilizador “real” está efectivamente ligado à bd.

Utilizadores e Schemas

Outra questão a considerar é a de quantos “schemas” serão criados na bd. Um schema é um agrupamento de objectos na bd ao qual se atribui um nome; o nome dos objectos apenas se podem repetir em schemas diferentes. Por exemplo, podemos ter schemas com o nome “Ambiente” com os dados desta temática, ou “Cadastro”, e por aí fora. É preciso sublinhar que podemos controlar quem tem acesso a um schema, podendo proibir o acesso a certos utilizadores, dar acesso apenas de leitura, ou por fim, dar controle completo.

Quando possível, prefiro usar o schema “public” criado de raiz durante a instalação do PgSQL, e não criar mais schemas. Esta abordagem é muito simples, e tem a vantagem de ser a mais compatível com o software que interage com o PostGIS (já aconteceu usar software que não via outros schemas além do public), além de simplificar a gestão de privilégios (o que também pode ser limitativo, caso as nossas necessidades exijam compartilhar os dados por áreas de edição).

Mas sucede que o ArcSDE necessita que todos os utilizadores que criam dados tenham o seu próprio schema. Pelo que a centralização dos dados geográficos no schema public não é possível. Temos de ter tantos schemas quantos os utilizadores que criam dados. Ou seja, se o utilizador João for alguém que tem de criar tabelas novas na bd, então terá de ter obrigatoriamente o seu próprio schema, e com o mesmo nome “João”!

A questão não é complicada se tivermos poucos criadores de dados, porque teremos de criar poucos schemas. Isto não impede que haja muitos editores, que podem editar dados de outros utilizadores e por isso não precisam de ter o seu próprio schema.

Mais info sobre schemas pode ser encontrada na documentação do PgSQL.

Criar Utilizadores

Para criar utilizadores no PostgreSQL usamos o PgAdmin (programa de administração) para criar “login roles“. Podemos também criar perfis que no PgSQL são denominados “group roles“, e que permitem gerir conjuntos de utilizadores em simultâneo, que partilham privilégios. O ArcSDE necessita que certas regras sejam seguidas na criação de utilizadores, se quisermos usar o ArcGIS para criar, editar e visualizar os dados.

Em resumo, para criar um novo utilizador que pode criar novos dados através do ArcGIS/ArcSDE, vamos:

i) criar um schema com o mesmo nome do novo utilizador; e

ii) criar um novo login na base de dados postgis, chamado por exemplo “gestorsig”. (Podemos usar o PgAdmin, mas aconselho usar a janela de sql para criar o utilizador.)

O utilizador deverá ter privilégios totais no seu próprio schema, mas também o privilégio de “usage” sobre o schema “sde”, onde são colocadas as tabelas de sistema do ArcSDE. Isto é necessário porque quando o utilizador cria uma nova tabela tem de a registar numa série de tabelas de sistema. Claro que isto é feito automaticamente pelo par ArcSDE/ArcGIS, mas se o utilizador não tiver privilégios não será possível.

Por outro lado, o utilizador “sde” precisa de ter acesso às tabelas criadas, sendo por isso necessário atribuir-lhe o privilégio “usage” sobre o schema do novo utilizador, para que seja capaz de efectuar algumas operações de manutenção (limpeza do versionamento).

E ainda um passo final – como optámos por armazenar os nossos vectores usando o tipo espacial nativo do PostGIS, o nosso utilizador necessita de acesso de escrita à tabela “public.geometry_columns”, onde se registam todas as tabelas espaciais do PostGIS. De outra forma, as nossas tabelas não seriam reconhecidas como tendo geometrias.

Concluindo, para criar um utilizador capaz de criar novas tabelas, usamos o seguinte SQL:

Update (13/06/2010): é também necessário dar pelo menos acesso (SELECT) à tabela de sistemas de coordenadas (spatial_ref_sys).

create role gestorsig login password 'PasswordDoUtilizador' noinherit createdb;
create schema gestorsig authorization gestorsig;
grant usage on schema sde to gestorsig;
grant usage on schema gestorsig to public;
grant select, insert, update, delete on table public.geometry_columns to gestorsig;
grant select on table public.spatial_ref_sys to gestorsig;

Neste código há uma pequena nuance: damos acesso ao nosso schema a todos os outros utilizadores (“…to public”), e assim não nos preocupamos se damos acesso a A ou B.

Para criar um utilizador que edita dados, mas não cria novas tabelas, o processo é quase igual. Apenas não necessita do seu próprio schema (usará o public por default):

create role editorsig login password 'PasswordDoUtilizador';
grant usage on schema sde to editorsig;
grant select, insert, update, delete on table public.geometry_columns TO editorsig;

Nota: como o nosso utilizador que cria dados (gestorsig) deu acesso a todos os utilizadores, não temos de o fazer explicitamente para novos utilizadores.

Nota 2: para podermos editar os dados criados pelo gestorsig, temos de dar privilégios de UPDATE ao nosso editor. Podemos fazê-lo usando o ArcCatalog (selecionar as Feature Classes, e com botão direito usar a opção “Privileges”), ou usando SQL.

No caso de utilizadores que só visualizam dados, o processo é igual. A diferença é que no ArcCatalog apenas damos o privilégio de SELECT sobre os objectos criados.

Deixo aqui 2 links que resumem a forma de criar novos utilizadores:

• HowTo:  Create a new user in PostgreSQL using psql
• User permissions for geodatabases in PostgreSQL

Todo este processo é muito semelhante ao que se passa com outros SGBDR’s, como Oracle ou SQL Server. Apenas muda a terminologia, e alguma da lógica de compartimentação da estrutura da bd. Para quem vem do mundo Oracle, a adaptação ao PostgreSQL é muito fácil, e para utilizadores de SQL Server não é muito diferente…

Partilhar

Esta decisão foi tomada pelo Governo Britânico e anunciada pelo 1º ministro britânico no dia 17 de Novembro de 2009. Aparentemente, foi muito impulsionada pelo “inventor” da web, Tim Berners-Lee, que desempenha um papel de assessor para esta questão desde Junho de 2009.

A questão sobre se os dados cuja produção é financiada pelo Estado devem ou não ser gratuitos é antiga e muito apaixonada. Sempre que alguém refere esta questão desenvolvem-se sempre grandes discussões, e amizades de uma vida podem perder-se!! Na minha perspectiva, existem 2 campos: aqueles a favor da venda dos dados (geralmente pessoas associadas ao IGP ou a empresas de cartografia), e depois o grupo daqueles que são a favor da distribuição tendencialmente gratuita dos dados, constituído pelo restante da humanidade.

Até recentemente, havia o grande fosso Americano-Europeu que mostrava bem a aplicação das 2 políticas. Os EUA aplicam a regra em que se os dados são produzidos com dinheiros públicos então devem ser gratuitos. Na Europa, a regra seria a de que para manter uma elevada qualidade dos dados e para os manter actualizados de forma sustentável, é necessário cobrar, e bem, pelos dados mesmo que sejam produzidos com dinheiro dos impostos. Do ponto de vista europeu, os dados americanos são maus e não servem os grandes interesses do público. Pois, mas por cá continuo sem ter uma rede de estradas nacional em formato SIG como os EUA têm… (vide TIGER).

Sucede que este fosso está a desaparecer, num movimento lento mas que parece agora acelerar. A Espanha decidiu implementar em 2008 uma política de difusão livre dos dados cartográficos do Instituto Geográfico Nacional espanhol. Em Novembro deste ano a Noruega também abriu o acesso a produtos cartográficos, embora de uma forma limitada a fins não lucrativos e individuos. Agora, a OS, uma das mais conceituadas entidades estatais responsáveis pela cartografia, vê-se forçada a libertar grande parte dos seus dados. Foram efectivamente forçados, porque até agora a OS tem defendido energicamente a sua posição de comercializar os dados que produz, numa política de recuperação total ou quase total de custos.

O impacto desta decisão ao nível financeiro parece estar acautelado, já que a decisão foi co-apresentada pelo responsável britânico das Finanças! Até agora não se encontram dados claros sobre o custo desta decisão, mas aparentemente a maior parte das receitas da OS são obtidas dos dados a escalas maiores (1:2500 e 1:1250), produtos que por cá nem existem. As estimativas que encontrei são muito variadas, indo de 5 milhões a 50 milhões de libras em receitas perdidas. Mas a questão parece não ser grave, e as mesmas estimativas apontam para uma geração de receitas muito superior na sociedade civil.

Agora, e relativamente a Portugal, como estamos? Dados livres temos os limites administrativos, e algumas imagens de cartas à escala 1:500.000 ou pior. E ainda algumas cartas temáticas de interesse circunscrito a áreas específicas (Cartografia de Risco de Incêndio Florestal, Rede de Nacional de Estações Permanentes). No total, existem 8 serviços WMS disponibilizados pelo IGP, e 3 deles são limites administrativos.

E dados pagos? Com qualidade e actualizados de forma sustentável? Onde andam? Mas mais importante, que receitas geram ao IGP? Que importância têm no orçamento do IGP? Será assim tão caro disponibilizar os ortofotomapas 1:10.000 de penúltima geração? E quanto custará (em receitas perdidas) disponibilizar alguma informação extraída da cartografia 1:10.000? E por fim, que tipo de actividade económica será gerada por esta disponibilidade de informação? Que receitas podem ser esperadas? Não serão maiores que os custos? Enfim, não será este o caminho a seguir?

Aguardemos o que o futuro nos trará. O presente parece cada vez melhor.

Partilhar

Agora, desde ontem 29 de Junho de 2009, foi disponibilizado um novo mdt global de 30m de resolução, criado a partir do satélite ASTER, numa colaboração entre a NASA e o governo japonês. O mdt foi criado a partir de 1,5 milhões de imagens ASTER, recorrendo à sua correlação estereográfica. Os detalhes podem ser consultados aqui: METI and NASA Release ASTER Global DEM.

Há vários locais para obter os dados. Um que experimentei é este: ASTER GDEM search system. É um sistema interactivo em que podemos seleccionar a área de interesse desenhando um polígono. Obtemos uma listagem das quadrículas que nos interessam e fazemos a sua descarga. (por alguma razão o download não correu bem…)

É-nos pedido o registo de utilizador, e que indiquemos o fim a que se destina a informação. Supostamente, obtemos uma licença de utilização limitada a esse fim… este tipo de permissão amputada  agasta-me… mais ainda numa informação distribuída gratuitamente. Têm receio que faça o quê com os dados? Enfim…

Depois de obtermos as quadrículas, o melhor será construir um mosaico num único ficheiro, e reprojectar para o sistema de coordenadas  que mais usamos – não confirmei mas julgo que o original está em WGS84. O formato também não consegui ainda confirmar, mas em tempos o ASTER produzia ficheiros no formato HDF-EOS, que é um formato algo complicado e pouco comum. Nessa altura, havia alguns programas para a conversão, incluindo os excelentes MicroDEM e 3DEM.

Ou seja, precisamos de um voluntário que obtenha os vários tiles do mdt, os junte num mosaico, e reprojecte num sistema de coordenadas comum em Portugal. E depois, se não for pedir muito, que o disponibilize à comunidade!! Alguém se apresenta?

Partilhar