Archive for the 'Intermédio' Category

QGIS e CAD

Publicado em 21 de Julho de 2010 em CAD, Intermédio, Open Source and SIG. 5 Comments Tags: , , , .

Os ficheiros CAD são uma das principais fontes de dados para um SIG.  Este artigo analisa as possibilidades actuais de lidar com CAD no Quantum GIS.

CAD e SIG

Existe uma rivalidade antiga entre quem trabalha com software CAD e quem trabalha com software SIG – é comum ouvirmos dizer coisas como “o CAD é menos avançado”, ou “os tipos do SIG têm a mania de complicar as coisas”, entre outros mimos. Na realidade CAD e SIG são ferramentas usadas para fazer coisas diferentes, com métodos de trabalho diferentes, e que (infelizmente) têm de conviver de forma muito próxima, sem se compreenderem muito bem… (Aviso: tentei ser isento, mas acho que desisti a meio do texto…)

Simbologia é informação

No CAD esta afirmação é verdadeira. No SIG não.

No CAD eu desenho os meus elementos gráficos com o objectivo principal de obter uma visualização – para ver no monitor ou para imprimir. Quanto mais produtivo for a criar a minha visualização melhor técnico CAD serei. Os elementos que crio no ficheiro CAD representam exactamente o que preciso de ver: uma árvore é constituída por uma copa, um poste de iluminação tem um pé e uma lâmpada, uma área ajardinada tem vários pequenos arbustos. Eu posso seleccionar cada um destes elementos e alterá-los para obter a visualização exacta que pretendo. Quando gravo um DWG ou um DGN gravo tudo isto – uma linha com dada cor, espessura, tipo de tracejado – gravo no ficheiro as geometrias que são também a simbologia em simultâneo. A estrutura do meu desenho é constituída pela forma como eu organizo os meus elementos por camadas (layers ou levels), e como crio os meus elementos (blocos ou elementos simples).

No SIG a situação é muito, muito semelhante. Mas 2 ligeiras diferenças são suficientes para tornar o diálogo entre as equipas CAD e SIG difícil e por vezes até antagónico.

1) No SIG eu desenho apenas geometrias. Recolho vértices XY. E recolho características das geometrias, que armazeno em atributos. Todas as geometrias que recolho num ficheiro têm sempre os mesmos atributos, e por isso descrevo-as de forma sistemática, formando uma tabela. Não há simbologia envolvida no processo. Ao gravar o trabalho num ficheiro de dados, guardo apenas vértices XY e atributos, sendo uma das razões por que grande parte do trabalho é focada em organizar informação, em decidir que atributos cada ficheiro terá. Mas esta obsessão organizativa vai mais longe! Cada ficheiro tem apenas um tipo de geometria – ponto, linha ou polígono – que nunca se misturam no mesmo ficheiro.

2) No SIG a simbologia é aplicada por regras a um ficheiro – não se define a simbologia de um só elemento. Usam-se os atributos para seleccionar um conjunto de geometrias a que depois aplicamos uma certa simbologia. Por exemplo, podemos representar especificamente as cidades com população maior que 1 milhão de habitantes como círculos pretos, as restantes cidades com um quadrado.  Se todos os pontos que são as cidades tiverem um atributo com a sua população, o software SIG aplica esta simbologia facilmente. Uma consequência desta abordagem à simbologia é que passa a ser dinâmica. Se quisermos alterar a simbologia, não alteramos as geometrias – alteramos as regras da simbologia. Para guardar a simbologia usam-se ficheiros de projecto, que não têm dados, apenas regras e definições de como representar a informação e como a imprimir (formato da página, orientação, seta do norte, título, ou seja, o layout).

cad_carto_thumb[1] sig_carto_thumb[1]
CAD SIG

Exemplo de informação CAD original, e quando convertida para SIG.

Então qual é o problema?

Como dizem os políticos, ainda bem que fez essa pergunta…

Pois é, o problema é na conversão de CAD para SIG. Este é um assunto muito extenso e interessante, mas como é Verão apetece mais uma bejeca… :) Mas ainda consigo lembrar-me de 3 grandes problemas nesta conversão:

1) Seleccionar num ficheiro CAD elementos que têm o mesmo significado é geralmente difícil. Se todos pontos que são as cidades estiverem num único layer, e nesse layer não existir outro tipo de pontos, então a sua selecção é facílima. Mas isso raramente acontece… geralmente elementos gráficos com diferentes significados coexistem no mesmo layer.

2) Determinar a posição correcta de um elemento é muitas vezes difícil – a cidade está no ponto de inserção do bloco, ou é o ponto central do bloco? O ponto cotado é o ponto de inserção, ou é a virgula decimal do texto da cota? E aqui junta-se a dificuldade de evitar as tramas ou “hatches”. (As tramas são linhas que representam simbologia mas não representam uma entidade no terreno. Geralmente aplicadas a polígonos, servem de arranjo gráfico, e não devem ser convertidas para SIG.) Outro exemplo são marcas quilométricas em eixos de infra-estruturas… no CAD são importantes, no SIG são considerados erros de conversão. Outro grupo de problemas pode ser aqui incluído – questões como converter linhas fechadas do CAD para polígonos no SIG, reconhecer vazios, e outras questões semelhantes…

3) E finalmente, recolher atributos juntamente com as geometrias é muitas vezes… … … difícil (novamente)! e para o SIG os atributos são fundamentais. Por exemplo, qual é a cota de cada ponto cotado ou curva de nível? Ou qual é o nome de cada eixo de rua? A verdade é que já foi feito o trabalho de recolha e digitalização desta informação pela equipa CAD, mas mesmo assim não é possível muitas vezes usá-la num SIG (ou noutro sistema qualquer). No CAD, o texto que mostra o nome de uma rua é uma entidade gráfica  independente da linha, e por isso não existem métodos automáticos fiáveis para associar cada linha a cada texto. A não ser que se crie o ficheiro CAD já com a preocupação de permitir este tipo de interoperabilidade, e assim avançamos para tópicos de CAD avançados que (na minha experiência) escapam à maioria dos desenhadores.

Então e agora?

Pois é… agora estamos todos numa grande alhada. Ao fim de dias a tentar converter ficheiros CAD, o pessoal do SIG está pronto a abraçar uma vida de crime, começando por cometer uma série de homicídios lá para as bandas do CAD.

A única solução é conhecer bem o software que usamos. Com o tempo vamos aprendendo as técnicas que o software suporta para conseguir conversões cada vez mais automáticas. Mas tudo depende dos ficheiros originais CAD. E é muito importante poder contar com alguém no “lado” CAD que possa alterar os ficheiros CAD de forma a facilitar o processo de conversão.

Outra via de facilitar a vida a todos os técnicos envolvidos num processo que passe por CAD e SIG, é estabelecer regras para os ficheiros CAD que facilitem depois um processo menos manual de conversão. E isso novamente vai depender da informação em causa, e do tipo de AutoCAD em uso (“normal”, Map, Civil…). Por exemplo, no AutoCAD Map podemos criar Object Data, Object Class, ou até ligar os nossos elementos gráficos a tabelas de atributos externos, mas em AutoCAD “simples” isso já não é possível…

Portanto, não há regras infalíveis. Cada caso é um caso, como se diz. Mas há regras de bom senso que resultam sempre bem – agrupar elementos gráficos com o mesmo significado num só layer é uma dessas regras: só eixos de via num layer, e todos os eixos de via estão nesse layer (não há outros tantos eixos noutros tantos layers); cada layer tem um nome claro e intuitivo (nada de layers com nomes do tipo “ev_de” – que quereria dizer “eixos de via do distrito de évora”…); para layers de polígonos criar também o respectivo layer de anotação ou blocos de atributos (onde também marcamos os vazios), e outras regras deste género. Bom senso é muito subestimado hoje em dia…

QGIS

E finalmente chegamos à parte principal do artigo, que originou o seu nome…

O QGIS usa como leitor de dados as bibliotecas do GDAL (imagens) e OGR (vectores). Este facto não é muito visível para o utilizador, mas é importante para compreender as capacidades do QGIS. Estas bibliotecas têm drivers que são responsáveis por cada formato que o GDAL/OGR suporta. No caso de ficheiros CAD só 2 formatos são suportados – DXF e DGN. Está já pronto um novo driver para DXF e que lê também DWG, mas ainda não é incluído no QGIS (nem mesmo na versão 1.5 a lançar já em Julho).

O caso DXF

O OGR converte DXF para qualquer outro formato que suporte, como o shapefile. E mantém alguns atributos, como o layer, o que é muitas vezes suficiente para converter e organizar a informação CAD. Mas enquanto o QGIS não usar uma versão de OGR que inclua o driver DXF não vamos conseguir ler estes ficheiros directamente no QGIS. Temos assim de usar comandos de linha…

Assim, para evitar usar a linha de comandos do OGR, podemos fazer esta conversão no QGIS usando o plugin Dxf2Shapefile (incluído na instalação do QGIS). Mas surpreendentemente este plugin não mantém quaisquer atributos quando converte ficheiros DXF, e ficamos com pontos, linhas e polígonos sem sabermos o que representam. O que é muito desapontante.  A sua utilização é muito fácil, mas os resultados são pobres dada a flagrante ausência de atributos.

image

Conversão de DXF para Shapefile no QGIS – perdem-se os atributos.

O caso DGN

Há uma outra opção – o QGIS lê directamente ficheiros DGN, e carrega-os para o mapa sem ser necessário uma conversão prévia. E melhor ainda, vários atributos são visíveis, e assim, tendo o ficheiro CAD no nosso mapa, podemos aplicar selecções de acordo com o level (equivalente ao layer dos DXF), e gravar para ficheiros shapefile.

image

O QGIS consegue ler DGN directamente e mantém atributos como o level, permitindo fazer selecções e gravar para shapefile.

Uma surpresa é que o DGN é carregado com todas as geometrias misturadas num só tema. O que é invulgar. Temos de nos habituar a esta ideia e encontrar forma de filtrar cada tipo de geometria para as conseguirmos separar e exportar para shapefile. Isto é, vamos criar um filtro (Query) no QGIS para ficar apenas com pontos, e exportá-los para um shapefile. E fazemos o mesmo depois para isolarmos as linhas e os polígonos.

Como o QGIS usa o OGR para ler ficheiros DGN, basta uma consulta à página do driver DGN do OGR, para ficarmos a saber quais os atributos a que temos acesso com ficheiros DGN. E vemos que o atributo “Type” indica o tipo de geometria:
Line (3): Line geometry.
Line String (4): Multi segment line geometry.
Curve (11): Approximated as a line geometry.
B-Spline (21): Treated (inaccurately) as a line geometry.
Arc (16): Approximated as a line geometry.
Ellipse (15): Approximated as a line geometry.
Shape (6): Polygon geometry.
Text (17): Treated as a point geometry.
Ou seja, para no QGIS seleccionar todas as linhas num DGN, podemos usar a seguinte query (usando a opção “Query” no menu de contexto do tema DGN, acedido clicando com o botão direito sobre o tema DGN):

Type = 3 OR Type = 4 OR Type=11 OR Type = 21 OR Type = 16 OR Type = 15

image

No QGIS filtramos o DGN com uma query, para isolar um só tipo de geometria (ponto, linha ou polígono).

Depois de fazer a query todos os elementos que restam visíveis no QGIS serão linhas, e podem ser gravados para um shapefile usando a opção “Save as” do menu de contexto do tema.

Depois de termos a informação dividida por 3 shapefiles, um por tipo de geometria, podemos então fazer selecções por level para tentar isolar objectos com determinados significados.

Na verdade nem é preciso exportar para shapefile. Podemos simplesmente carregar o ficheiro DGN, filtrar as geometrias, e aplicar depois a simbologia que queremos. Será necessário converter quando, por exemplo, quisermos converter uma série de ficheiros DGN  num único shapefile com toda a informação (ou para outro formato como PostGIS ou SpatiaLite).

O caso DWG

Este é o pior formato de informação geográfica do mundo. Ponto.

Além de ser alterado a cada 3 anos, é completamente fechado, isto é, para poder ler e escrever este formato é necessário pagar a terceiros, como a Autodesk ou a Open Design Alliance. A propósito da ODA e da má fama do DWG, podem ler esta novela espantosa relatada pelo 1º presidente desta ilustre fundação. Mas pode ser que as coisas estejam a mudar. Recentemente, a ODA chegou a acordo com a Autodesk e lá resolveram as disputas sobre marcas comerciais, e por coincidência (ou não) em Junho publicaram as especificações actualizadas que desenvolveram para ler e escrever DWG. É melhor aproveitar e fazer o download, não vá a situação alterar-se… Estas especificações têm sido insuficientes para criar programas que consigam escrever ficheiros DWG válidos, mas pelo menos para ler estes ficheiros já foram suficientes. Esta nova actualização não sei se virá alterar esta situação, mas terá nova informação sobre o formato DWG 2010…

Não vou alongar-me mais sobre o formato, interessa apenas frisar que até agora o software Open Source teve de criar bibliotecas para ler (ou escrever) ficheiros DWG fazendo um enorme esforço de “reverse engineering”. Que além de ser um trabalho muito pouco interessante, tem de ser revisto a cada 3 anos.

Assim, o QGIS não lê DWG. É possível que o venha a fazer no futuro próximo, havendo avanços no OGR nesse sentido. A ver vamos…

Mesmo a terminar este assunto, tenho de referir que o gvSIG lê DWG até à versão 2004…

Conclusão

Dadas as dificuldades actuais de interoperabilidade do formato DWG, este não é viável de momento com QGIS.

A opção DGN é muitíssimo funcional, e até muito fácil de trabalhar no QGIS. Para utilizadores de Microstation é óptimo. Para utilizadores de AutoCAD há a possibilidade de exportar para DGN a partir do AutoCAD 2008. Para os outros produtos baseados em DWG/DXF já não se pode dizer o mesmo.

Finalmente, o formato DXF é de momento uma má opção, a não ser que façamos a conversão pela linha de comando do OGR para shapefile ou semelhante. Mas espera-se em breve ter no QGIS um suporte ao nível do DGN. Mesmo assim, também obriga à exportação para DXF (a partir do formato CAD nativo), sendo um passo extra que é mais uma pedra na engrenagem para os técnicos CAD.

Se souberem de outras possibilidades aproveitem a secção de comentários.

Até breve.

Mosaicos de imagens em MapServer, com GDAL

Publicado em 22 de Janeiro de 2010 em Dados, Intermédio, Open Source, SIG, Sem categoria and WebGIS. 10 Comments Tags: , , , .
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

PostgreSQL e ESRI – parte 3

Publicado em 12 de Dezembro de 2009 em Dados, Gestão, Intermédio, Open Source, PostgreSQL and SIG. 2 Comments Tags: , , , .

Esta é a parte 3 desta série, sobre a utilização de PostGIS com ArcGIS, que aborda a estruturação da bd PostGIS. Os artigos anteriores são:

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:

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…

PostgreSQL e ESRI – parte 2

Publicado em 2 de Dezembro de 2009 em Intermédio, Open Source, PostgreSQL and SIG. 2 Comments Tags: , , .

Este post é o 2º sobre integrar ArcGIS e PgSQL. A 1ª parte pode ser encontrada aqui.

Este artigo continua a experiência de usar o PgSQL como base de um SIG baseado em ArcSDE/ArcGIS, debruçando-se sobre a instalação e tipo de conexões. Não é uma introdução ao PostgreSQL/PostGIS, e é assumido que o leitor tem algum conhecimento prévio ou que o irá obter noutra fonte… por exemplo aqui:

Instalação do ArcSDE+PostgreSQL+PostGIS

O instalador do ArcSDE é muito simples, e até inclui o PostgreSQL. Mas se seguirmos o wizard de instalação do ArcSDE, não será instalado o PostGIS e o ArcSDE será instalado no seu modo default, com o seu próprio tipo espacial (coluna de geometria) e o seu próprio SQL espacial. Desta forma, só se consegue aceder aos dados geográficos com software ESRI.

Para instalar o ArcSDE de forma a que os dados sejam armazenados usando o tipo espacial do PostGIS é necessário desviarmo-nos um pouco do caminho seguido pelo wizard de instalação. Quando o wizard acaba de instalar o PostgreSQL, temos de parar, e instalar o PostGIS, antes de prosseguir com o wizard do ArcSDE. Tudo é bem explicado neste artigo da ESRI:

HowTo:  Install PostgreSQL 8.3.0, ArcSDE 9.3, and PostGIS 1.3.2 on Windows

No final da instalação ficamos assim com o PostgreSQL, o PostGIS, e o componente ArcSDE.

O componente ArcSDE cria uma base de dados no PostgreSQL, chamada “sde”, e um utilizador próprio chamado “sde”. É nesta bd que ficam as tabelas de sistema do ArcSDE e a suas próprias funções, triggers, etc.

O nosso servidor PostgreSQL fica também com a estrutura habitual do PostGIS, havendo uma bd denominada “postgis”. Nesta bd também são instalados objectos do ArcSDE, como tabelas de configuração da geodatabase que mantém registo dos objectos que são criados através de software ESRI e que compõem o modelo de dados da geodatabase.

Na instalação há um problema com privilégios – a instalação do ArcSDE pára porque não consegue escrever nas directorias do PostgreSQL (”lib” e “bin”). Para resolver basta usar o explorador do Windows para adicionar o privilégio de escrita nessas pastas ao nosso utilizador (que estamos a usar ao executar o instalador do ArcSDE). Se usarmos o utilizador “Administrator” o problema não surge.

Outra nota importante é que o PostgreSQL é instalado com as definições pré-definidas. Sucede que estas definições são à prova de equipamento pré-histórico… ou seja, o PostgreSQL instalado e sem alterações funciona até num Intel 486 com 256MB de memória. Mas claro que a performance não é a desejada e deve-se editar as configurações. Noutro artigo espero discutir um pouco as opções mais comuns a alterar.

A título de curiosidade, os valores default de configuração ocupam cerca de 60MB de memória (sem iniciar o serviço SDE e sem contar com o pg_ctl.exe).

Tipo de Ligações ArcSDE

Depois da instalação são criados 2 novos serviços no Windows: o usual do PgSQL, e um próprio do ArcSDE.

O serviço do ArcSDE é o gestor de conexões do ArcSDE. Ou seja, as aplicações da ESRI ligam-se a este serviço, que depois inicia as conexões à base de dados para cada aplicação. A ESRI designa este esquema conexões como “Application Server connections” ou de 3 camadas (3-tier). Cada utilizador de ArcGIS que se liga deste modo vai criar um processo no servidor chamado “gsrvr.exe”, que optimiza a comunicação dos dados entre a bd e o ArcGIS. Cada um destes processos ocupa entre 15MB e 100MB de memória, para além da memória ocupada pelo próprioPgSQL. Se houver 10 postos ArcGIS, serão lançados 10 processos destes no servidor, ocupando 150-1000MB de memória. Isto para além dos processos que o PgSQL irá criar por si.

Nos últimos anos, a ESRI tem vindo a incentivar o uso de outro tipo de conexões – conexões directas.

Nas conexões directas não é necessário usar o serviço ArcSDE, o  ArcGIS liga-se directamente à bd. Isto é possível porque o ArcGIS passou a incluir as dll’s do ArcSDE, e assim a memória que era ocupada no servidor passa a ser consumida no PC com o ArcGIS. O inconveniente é que estas conexões ocupam um pouco mais a rede, mas teoricamente não há impacto perceptível. Com as conexões directas apenas temos de contar com os processos do próprio PgSQL.

Naturalmente, desde que a rede não esteja congestionada, é preferível usar conexões directas. No entanto, o esquema de conexões 3-níveis permite separar o ArcSDE da bd, o que possibilita a utilização de clusters, beneficiando da distribuição de carga que este tipo de sistemas oferece.

Conexões PgSQL

O PgSQL quando inicia cria um conjunto de 6 processos em memória no servidor. Em Windows, todos estes processos se chamam “postgres.exe”. Um destes processos é o processo principal do servidor que mantém a cache de dados e outras informação que persistem entre conexões. A configuração do PgSQL influenciará principalmente este processo, que tanto pode ocupar 26MB como 500MB, ou mais.

Por cada cliente que se conecta (QGIS, gvSIG, …), o PgSQL cria mais 1 processo na memória do servidor, correspondendo a essa conexão (curiosamente, no caso do ArcGIS são sempre criados 2 processos postgres.exe). Este processo ocupará memória consoante as definições do PgSQL, dependendo fortemente do tipo de operações executadas pelo cliente. Assim, uma pesquisa simples consumirá pouca memória, mas a visualização de um layer com 120.000 registos já ocupará +200MB. O caso de maior carga que encontrei foram operações de carregamento de informação em massa ocupando 500MB de memória ou mais.

Confesso que não estou habituado a esta flutuação no consumo de memória. Ao usar Oracle, temos uma certa rigidez no consumo de memória, que orbitará em redor dos parâmetros determinados pelo gestor. Se o Oracle der sinal de necessitar de mais memória, é o gestor que tem de redefinir os parâmetros permitindo que o Oracle consuma mais memória.

No caso do PgSQL, a memória ocupada é também reflexo da configuração definida pelo gestor, mas a variação da memória ocupada é muitíssimo maior. E varia por cada utilizador que se liga, e pelas operações que irá efectuar. É um dimensionamento mais difícil de manter dentro dos limites do servidor.

Suponho que é uma questão de habituação ao processo. Durante uma fase inicial de implementação será necessário monitorizar de perto a utilização de memória no servidor, e adaptar as configurações do PgSQL. Tal e qual como se passa com outros servidores SGDB. Penso ainda regressar a este assunto, continuando esta série de artigos… até breve.

Serviços SIG no AutoCAD

Publicado em 5 de Maio de 2009 em CAD, Intermédio and SIG. 1 Comment Tags: , , .

Olá a todos. Desde o meu último post passou mais tempo do que gostaria… mas hoje consegui “empurrar” este post.

A questão que trago aqui hoje é uma forma de integrar um SIG baseado em software ESRI com software Autodesk. Ou seja, se a sua organização usa ArcGIS Server então saiba que pode fazer chegar toda a sua informação SIG aos utilizadores de AutoCAD/Map/Civil, e tudo sem conversões ou múltiplos ficheiros. Melhor, pode visualizar toda a informação publicada pela ESRI no site ArcGIS Online no AutoCAD, e isso inclui os ortofotomapas do IGP, de 2004 e com 1 m de resolução.

A solução é o plugin da ESRI “ArcGIS for AutoCAD”, para AutoCAD (como o nome indica). É um download gratuito que está no site da ESRI. Depois de instalado vai acrescentar um menu e uma ribbon ao AutoCAD chamados “ArcGIS” e que permitem definir ligações a serviços ArcGIS Server, localizados na Intranet ou na Internet, o que abre uma grande via de comunicação entre o mundo SIG e o mundo CAD. Este plugin oferece ainda uma nova forma de produzir informação CAD (no AutoCAD) com atributos denominada “Mapping Specification for Drawings” e que, de acordo com a ESRI Inc., é mais interoperável – não obriga a conversões complexas, evita perda de informação quer no lado SIG quer no lado CAD, e é baseado apenas em ficheiros DWG “normais”. Pode obter mais informação aqui: Mapping Specification for Drawings. Ainda não tive a oportunidade de investigar em detalhe esta nova opção… mas este video da ESRI ilustra o processo.

Mas regressemos ao tópico principal – como ver no AutoCAD informação publicada através do ArcGIS Server?

Instalação do ArcGIS for AutoCAD

A instalação segue o processo normal: depois de fazer o download, basta executar o ficheiro obtido. Nos casos que observei, os novos elementos na interface do AutoCAD não foram correctamente adicionados, pelo que foi necessário fazê-lo manualmente. Para isso bastou executar o comando “cuiload” (dentro do AutoCAD) e na janela que abre indicar o ficheiro “C:\Program Files\ArcGIS for AutoCAD\ afaUI.cui” (ou equivalente de acordo com a pasta de instalação).

A partir daqui, o menu e a ribbon ArcGIS ficarão visíveis.

Adicionar um serviço

Para adicionar um serviço ArcGIS, basta usar o botão “Add Map”, e preencher os dados do endereço do servidor, e nome do serviço pretendido. Na imagem seguinte é mostrada a ligação a um servidor interno na EDIA com um serviço que mostra as infra-estruturas do EFMA, usando dados ArcSDE e simbologia ArcMAP:

image

E o resultado depois de aproximar a uma área com dados é (desculpem a qualidade da imagem):

image

Podem ser usados serviços dinâmicos e de cache (em que as imagens são previamente geradas para uma quadrícula e para um conjunto de escalas pré-definidos). Os serviços de cache permitem uma velocidade de interacção muito maior, com a contra-partida de existir alguma desactualização dos dados.

Adicionar o serviço ArcGIS Online com os ortos do IGP

O processo para adicionar os ortos ao AutoCAD é o mesmo, mas agora indicando o endereço do servidor da ESRI: http://services.arcgisonline.com/arcgis/services.

No momento em que fiz este artigo, o AutoCAD não reconheceu o proxy da empresa (que exige autenticação), pelo que não pude capturar imagens… não foi possível determinar se o problema é do AutoCAD ou se é do plugin.

Identificar vectores num serviço ArcGIS Server

O plugin também inclui uma ferramenta de “Identify” que permite consultar os atributos da informação publicada. Por exemplo, identificar um canal no serviço da EDIA daria o seguinte resultado:

image

Conclusões

Esta ferramenta é realmente um passo em frente na interligação SIG-CAD, ou melhor, ESRI-Autodesk. Embora o AutoCAD Map e Civil tenham a capacidade de ligação a serviços WMS, a verdade é que a minha experiência com essa funcionalidade não tem sido a melhor (muitas vezes o mapa não redesenha o serviço WMS, e a impressão não refresca a imagem para ajustar ao tamanho do layout). Por outro lado, a ligação a serviços ESRI em cache é agora possível, o que traz as 2 grandes vantagens destes serviços: 1) são muito mais rápidos; e 2) exigem muito menos esforço por parte do servidor SIG, o que permite servir mais utilizadores com o mesmo servidor.

Neste momento, este plugin está em utilização na EDIA principalmente para visualizar, em AutoCAD, os mosaicos de ortofotomapas residentes em ArcSDE, algo que nunca tinha sido conseguido de forma funcional. E conseguimos mesmo chegar aos utilizadores da versão base do AutoCAD (sem Map nem Civil), que foram também sempre os mais excluídos do SIG. Optou-se por publicar os ortos através de serviços em cache, o que resultou numa óptima performance e numa experiência impressionante para os utilizadores.

No entanto, algumas questões têm suscitado dúvidas e dificuldades: a qualidade das imagens que surgem no AutoCAD têm pouca qualidade quando se utilizam serviços em Cache (principalmente vectores; com ortos não é tão aparente), e não foi ainda possível definir a transformação entre data diferentes (isto é, sobrepor dados WGS84 e Datum73). Também as labels aparecem no AutoCAD mais pequenas do que o esperado, o que obriga a alterar os mxd’s e criar novos serviços no ArcGIS Server especificamente para utilizar em AutoCAD.

Por outro lado, a possibilidade de definir níveis SIG num DWG que depois surgem no ArcMap como Feature Classes, sem necessidade de conversão, é muito apelativa… mais ainda se pensarmos que se podem preparar DWGs vazios com as especificações pretendidas e entregá-los a fornecedores de serviços, projectistas e arquitectos. Estes podem criar a sua informação usando AutoCAD com estes DWGs, trabalhando assim já de acordo com as especificações SIG dos clientes, e sem necessidade de adquirir novo software – bastará usar o plugin gratuito. Mas este é já outro desafio totalmente diferente…

Visualizar CAD online

Publicado em 7 de Março de 2009 em CAD, Intermédio and SIG. 0 Comments Tags: , .

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

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

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

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

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

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

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

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

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

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

dwfviewer_1

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

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

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

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

Vantagens desta solução:

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

Desvantagens:

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

Links de interesse:

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

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

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

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

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

A página ficaria com este aspecto:

dwf_freewheel_1

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

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

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

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

Vantagens desta solução:

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

Desvantagens:

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

Links de interesse:

Conclusão

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

Medindo o Desempenho de Servidores SIG

Publicado em 14 de Fevereiro de 2009 em Gestão, Intermédio and SIG. 0 Comments Tags: , , .

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

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

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

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

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

Configurações dos servidores em comparação

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

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

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

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

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

Software de Testes – JMeter

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

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

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

Gravando um teste

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

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

JMeter_testeinicialopt

Alterar o teste de desempenho

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

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

O teste resultante ficou com o seguinte aspecto:

JMeter_testefinal_opt

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

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

Testando

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

Resultados e análise com 1 utilizador

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

Aggregate Report_1ediasigims_opt

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

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

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

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

Aggregate Report_1ediabeja019_opt

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

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

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

Resultados e análise com 10 utilizadores

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

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

Aggregate Report_1ediasigimsx10_opt

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

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

Aggregate Report_1ediabeja019x10_opt

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

Conclusão

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

 

Mapas/min

KB/s

Mapas/min

KB/s

Xeon P4 3,2GHz

21,3

5,1

51,7

12,4

Xeon Quad 2GHz

39,9

10,2

132

33,7

melhoria %

87%

100%

155%

172%
 

1 utilizador

10 utilizadores

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

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

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

GDAL: Formatos Comprimidos

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

Esta é a parte 3 de uma série de artigos sobre o GDAL, o kit de ferramentas para conversão de imagens SIG. Pode também ler aqui as outras partes da série: parte 1, parte 2.

Principais Formatos

Os formatos geo-espaciais comprimidos mais comuns são: JPEG, JPEG2000, ECW e MrSID.

O formato TIFF foi já tratado na 2ª parte da série, e sabemos que este formato tem uma série de opções de compressão, incluindo compressão JPEG.

Estes formatos podem dividir-se em 2 grupos: JPEG por um lado, e os restantes por outro. O formato JPEG é sobejamente conhecido da fotografia digital e do mundo dos computadores em geral. O grau de compressão de uma imagem em JPEG depende da escolha do utilizador, e quanto maior for mais a imagem é degradada. Uma taxa de compressão 1:10 é comum, apresentando degradação pouco perceptível. Uma taxa de 1:100 resultará num ficheiro muito menor mas com grande degradação. Além disso, imagens de grande dimensão tornam-se lentas de visualizar, ocupando muita memória. Para usar este formato em SIG é necessário um ficheiro adicional contendo as coordenadas reais da imagem, geralmente com a extensão .jgw. Outra limitação prende-se com a necessidade de criar as pirâmides (overviews) em ficheiros separados, se quisermos optimizar a visualização de grandes imagens.

Os formatos JPEG2000, ECW e MrSID usam algoritmos de compressão denominados “wavelet”, e proporcionam taxas de compressão tipicamente entre 1:10 e 1:100, incluêm pirâmides no próprio ficheiro, e ainda metadados sobre a imagem. A grande facilidade com que são usadas em software SIG aliada às enormes taxas de compressão que proporcionam justificam a sua adopção. Um único ficheiro inclui toda a informação de que necessitamos: a imagem original, as pirâmides, a georreferenciação, e o sistema de coordenadas.

Outras vantagens deste grupo de formatos são: grande compatibilidade com o software mais usado, possibilidade de compressão sem degradação perceptível a taxas de compressão elevadas, boas velocidades de visualização (excepto o JPEG2000 como veremos a seguir).

Comparação entre formatos

Para comparar os vários formatos comprimi um ortofotomapa com 465MB usando o GDAL. Na altura, o teste serviu para definir qual a melhor opção para integrar um catálogo de imagens numa arquitectura ESRI, ou seja, para visualizar em ArcGIS e ArcIMS, na versão 9.2. Entretanto, tentarei actualizar a tabela com resultados para gvSIG e para MapServer. Se alguém quiser contribuir por favor deixe as suas conclusões nos comentários.

Formato Compressão Taxa
%		 Taxa c/ Pirâmides ArcGIS ArcIMS gvSIG MapServer
TIF LZW 22,3 -3,3 ok ok ND ND
TIF DEFLATE 31,5 8,94 X ND ND ND
TIF PACKBITS -0,79 -34 ok ND ND ND
JPEG QUALITY=25 97,7 64 sofrível sofrível ND ND
ECW TARGET=80 86,6 86,6 ok n** ND ND
JP2 TARGET=80 80,8 80,8 lento lento ND ND
MrSID COMPRESSION=20 94,7 94,7 ok ok ND ND

**É possível publicar imagens ECW em serviços de imagem (baseados em AXL se o ArcGIS estiver instalado na mesma máquina. Mas o licenciamento não cobre esta abordagem…

Como se pode ver, em TIFF a melhor compressão é DEFLATE, mas como indicado na parte 1, é uma opção pouco compatível. Quem puder usar esta opção fica no entanto bem servido, com imagens não degradadas e poupando mais de 30% de espaço. Considerando a criação de pirâmides com o mesmo formato, poupamos ainda assim cerca de 9% de espaço.

Quanto ao JPEG, obtém-se uma óptima compressão de 98% quando usamos a opção QUALITY=25, embora a qualidade já seja afectada. Mas o pior, pelo menos em ArcGIS e ArcIMS, é a velocidade de visualização que fica realmente muito lenta. Se considerarmos a criação de pirâmides externas ao ficheiro, o espaço poupado em disco cai para 64%.

Quanto aos 3 formatos mais modernos, ECW, JP2 e MrSID, o campeão de compressão é o MrSID com quase 95% de espaço poupado! E isto já com pirâmides incluídas no ficheiro. Os outros 2 formatos ficam muitos próximos, com 81% para o JPEG2000 e 87% para o ECW.

Conclusões do Teste

O problema do formato MrSID é que não existe uma licença gratuita de compressão… por este facto, encontram-se frequentemente relatos em blogs sobre conversões a partir de MrSID para outros formatos, para efectuar alguma manipulação, e depois recompressão para um formato mais barato, como ECW ou JPEG2000. Aliás, nem a descompressão de MrSID usando o GDAL é legal sem uma licença adquirida. Pode-se no entanto descarregar uma ferramenta para esse efeito no site da LizardTech, empresa proprietária do formato. A seu favor, o formato MrSID tem a melhor taxa de compressão conseguida neste ensaio, e uma grande compatibilidade com o software existente, além de uma excelente rapidez de visualização.

Assim, excluindo o formato MrSID por questões de preço, ficamos com as opções ECW e JP2 para criar o nosso catálogo de imagens comprimidas (nesta situação para usar em ArcGIS e ArcIMS).

O ECW é um formato comercial concorrente do MrSID, lançado pela ER Mapper (empresa que comercializa o produto com o mesmo nome e recentemente adquirida pela ERDAS). Este é um formato que me agrada muito, já que tem as vantagens do MrSID e ainda disponibiliza  uma licença gratuita para compressão de imagens até 500MB. Este limite chega para podermos comprimir a grande maioria das imagens que se usam no dia-a-dia num departamento SIG. A única desvantagem que encontro é que o ArcIMS não lê imagens ECW a não ser através de projectos ArcMap (ficheiros *.mxd). E eu evito esta abordagem por questões de performance. Mas uma vez que o mundo ESRI se encontra todo a migrar para ArcGIS Server, que só usa ficheiros mxd, este problema começa a pertencer ao passado.

E quanto a JPEG2000? Este é um formato não proprietário, ou seja, sem limitações de uso. Por isso, seria o candidato ideal, certo? Bem, o problema é que a visualização é demasiado lenta para poder ser uma melhor opção que o ECW. Assim, a não ser que tenha imagens com mais de 500MB, ou o seu software favorito se comporte bem com JPEG2000, eu diria que ECW é o melhor formato comprimido de imagens georreferenciadas.

Compressão não-degradante (lossless)

Outro cenário interessante é saber como criar imagens muito comprimidas mas sem perda de qualidade. Ou seja, comprimir o mais possível as imagens originais, por exemplo para arquivar em DVD, e ainda assim manter a capacidade de ao descomprimir obter as imagens originais inalteradas. Como o formato ECW não suporta esta operação, restam só 2 dos formatos mais comprimidos – MrSID e JPEG2000. Como o MrSID tem de ser adquirido, fica apenas o JPEG2000. Na tabela encontram as taxas de compressão sem degradação para cada formato, e ainda para o TIFF+DEFLATE para comparação. Também se apresenta o resultado obtido usando o ArcGIS para converter para JP2.

Formato Compressão Taxa %
TIF DEFLATE 31,5
JP2 (GDAL) 0 54,2
JP2 (ArcGIS) 100 42

Para arquivo de imagens originais podemos assim usar o formato JP2, desde que usemos o parâmetro de qualidade máxima (ou de compressão mínima consoante o software de compressão). Ficamos ainda com o bónus serem incluídas pirâmides nas imagens , úteis para o caso de as visualizarmos. A única desvantagem é a lentidão de visualização… portanto só mesmo para arquivo. Se usarmos o GDAL para a compressão conseguimos gravar em 1/2 dos DVDs…

Comandos GDAL de compressão

Aqui fica uma cábula de comandos GDAL para compressão de imagens nos diversos formatos, e as respectivas taxas de compressão obtidas no teste. Não se esqueça que na 2ª parte da série encontra um script (.bat) para compressão de todos os ficheiros numa directoria.

Formato Taxa
%		 Comando
TIF com compressão DEFLATE 31,5 gdal_translate -of GTiff -co COMPRESS=DEFLATE -co PREDICTOR=2 in.tif out.tif
TIF com compressão LZW 22,3 gdal_translate -of GTiff -co COMPRESS=LZW -co PREDICTOR=2 in.tif out.tif
JP2, agressivo 80,2 gdal_translate -of JP2ECW -co TARGET=80 in.tif out.jp2
JP2, sem degradação 54,2 gdal_translate -of JP2ECW -co TARGET=0 in.tif out.jp2
ECW, agressivo 86,6 gdal_translate -of ECW -co TARGET=80 in.tif out.ecw
ECW, mínima degradação 59,8 gdal_translate -of ECW -co TARGET=0 in.tif out.ecw
JPEG, agressivo* 97,7* gdal_translate -of JPEG -co QUALITY=25 -co WORLDFILE=YES in.tif out.jpg

* Sem pirâmides. Ao criar pirâmides, a taxa de compressão reduz-se significativamente.

A parte 4 da série será dedicada à criação de catálogos de imagens com o GDAL… até lá.