Todos os artigos de duarte

Novo MDT global de 30m disponível

Dados, Inicial, SIG,
Tempo de leitura: 2 min

Há uns anos criei um mdt único de 90 m de resolução para a Península Ibérica, que uso desde então em mapas regionais. Este mdt foi criado a partir da SRTM, missão efectuada em 2000 pelo Space Shuttle Endeavour.

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?

Balanço Open Source para SIG

Gestão, Inicial, Open Source, SIG, , , ,
Tempo de leitura: 3 min

Já há algum tempo que tenho planeado escrever sobre a integração entre Postgresql e ArcSDE, agora que a ESRI suporta esta combinação. Mas ao começar esse artigo dei por mim a reflectir sobre a utilização que faço de ambos os mundos – open e closed source…

Sou utilizador de software ESRI há muitos anos, e sou também utilizador de software Open Source em tempo igual. Curiosamente.

Sucede que comecei a trabalhar em SIG num projecto de investigação na universidade (no Instituto Superior de Agronomia, “antigo” Dept. de Eng.ª Rural), e em simultâneo iniciei o mestrado. No projecto de investigação trabalhei com Linux, aprendendo as bases deste SO que ainda hoje me servem – na altura não havia sistemas de distribuição de pacotes de software já pré-configurados… por exemplo, o sistema de email que usava tive que o compilar… outros tempos (sou tão velho “informaticamente” que a minha mulher quer oferecer-me pelo aniversário uma tshirt do ZX Spectrum). Para a tese de mestrado usei ArcInfo numa estação de trabalho IBM com o SO AIX, uma variante de Unix desenvolvido por este fabricante. Desde aí mantive o gosto por Open Source, e continuei utilizador ESRI.

Para um utilizador ESRI, a integração com software Open Source é uma questão muito pertinente, por vários motivos – anoto aqui apenas alguns. Afinal, e não o escondo, o ArcGIS é o meu software SIG favorito, mas não faz tudo o que preciso, e nem tudo o que faz é feito da melhor forma. Nada melhor do que complementá-lo com pérolas de software gratuito. Por outro lado, existem tarefas para as quais prefiro utilizar um programa mais ligeiro, como o QGIS. E claro, para tarefas relacionadas com outro software Open Source também não é o mais indicado. Por exemplo, exportar um ficheiro .map para o MapServer a partir de um mapa devidamente simbolizado. Também a interoperabilidade e capacidade de interagir com os diversos standards OGC são limitadas no ArcGIS em alguns aspectos. Por exemplo, criar ficheiros SLD (de simbologia) para uso no GeoServer. Mas para os críticos do ArcGIS não se ficarem a rir, não conheço nenhum outro programa que crie ficheiros KML tão facilmente e com tanta funcionalidade como o ArcGIS. E o KML também é um standard OGC…

A situação com o Software Aberto na área SIG (SASIG) teve uma evolução explosiva nos últimos anos. Na minha opinião, devido em grande parte à publicidade positiva que a área recebeu da Google e a Microsoft. E hoje o panorama de software no lado do servidor e no lado do desktop é extraordinário. O software Open Source não serve só como complemento, e terá todo o mérito e capacidade em ser utilizado como peça central de um SIG. Tudo depende dos objectivos, necessidades, e processos de trabalhos escolhidos.

No servidor, temos 3 players fenomenais: MapServer, GeoServer (web), e Postgresql+PostGIS (bd).

No desktop, podemos também escolher facilmente 3 campeões da causa: gvSIG, Kosmo, e Quantum GIS – embora existam muitos mais.

Na categoria de ferramentas para conversão de dados, que tanto são usadas no lado servidor como no lado desktop, temos o incontestável par GDAL/OGR para raster e vector. Outras iniciativas mais recentes que poderão ser interessantes são o FeatureServer, o Spatial Data Integrator e o GeoKettle (ambos semelhantes ao FME).

Para o desenvolvimento de aplicações web também temos óptimos produtos: OpenLayers, pmapper, MapFish, e vários outros.

Já para desenvolver aplicações desktop o cenário é muito diferente, e não será uma tarefa fácil tentar criar uma aplicação SIG baseada em componentes Open Source. Pessoalmente, a minha opção seria sempre pela facilidade de utilização, e assim optaria pelo objecto ActiveX do MapWindow GIS, ou o extraordinário SharpMap para .NET (cujo desenvolvimento tem sido extremamente lento, para grande desencanto da comunidade… o jovem Morten foi contratado pela… (suspense)… ESRI!). Estas seriam as opções mais simpáticas, com menor exigência técnica e de tempo para criar uma aplicação SIG desktop adaptada a um objectivo específico.

Para adeptos Java existem também várias opções, embora mais complexas. As opções mais proeminentes serão a GeoTools (sem mecanismo de visualização?), GISToolkit (última versão de 2003), e OpenMap (apenas visualização). O mundo Java é para mim mais desconhecido, e agradeço contribuições de quem tenha mais prática com esta tecnologia para esclarecer a situação actual face a componentes SIG.

A área continua a evoluir e é difícil manter uma noção actualizada do que vai acontecendo nos vários domínios. Têm vindo a ser publicados artigos com o diagnóstico da “situação actual”:

Faltará talvez uma página web fixa onde se possam actualizar os vários produtos, talvez num wiki? Para nós lusófonos, seria excelente manter uma página destas no wiki do OSGeo PT. Há voluntários???

Serviços SIG no AutoCAD

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

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…

Criar KML de Pontos no ArcGIS

Inicial, SIG, , ,
Tempo de leitura: 6 min

Um amigo que também anda nestas lides geoespaciais, pediu-me ajuda para perceber a melhor forma de passar um shapefile de pontos para KML, de preferência de forma a que os pontos tivessem “balões” de informação e com símbolos minimamente aceitáveis.

O shapefile contém pontos com alguns atributos em português, como Nome, Categoria, e outros. O aspecto inicial no ArcMap é este:

image

E o objectivo é chegarmos ao Google Earth com este aspecto:

image

Filtrar os dados

Como apenas alguns pontos interessam passar ao KML, vamos definir uma expressão de pesquisa. Nas propriedades do layer, no separador “Definition Query” construimos a query. Neste exemplo, queremos apenas os pontos cuja Categoria é igual a “Hotelaria”.

image

Ficamos assim com menos pontos a converter. É claro que este passo é opcional…

image

Sistema de Coordenadas

Os dados num ficheiro KML devem estar no sistema de coordenadas WGS84, indicando as coordenadas em graus de latitude e longitude.

Em vez de projectar o nosso shapefile, vamos em vez disso configurar a Data Frame para usar o sistema de coordenadas WGS84. O ArcMap permite definir também a transformação de Datum, e com isso ao exportar dados podemos optar por usar o sistema de coordenadas original ou usar o que está activo na Data Frame. Esta abordagem tem a vantagem de reduzir o n.º de ficheiros intermédios que criamos em disco.

Assim, para definir o sistema de coordenadas, basta abrir as propriedades da Data Frame (botão direito em “Layers” na árvore de temas, e clicar na opção “Properties“), e abrir o separador “Coordinate System”.

Aqui, selecionar na parte inferior da janela a opção Predefined -> Geographic Coordinate Systems -> World -> WGS 84.

Temos ainda de selecionar a transformação de datum que queremos usar. Na parte superior da mesma janela, clicamos no botão “Transformations“, e na janela que abre selecionamos na última opção em baixo, a transformação “Datum_73_To_WGS_1984_4“. Esta transformação usa os parâmetros de nível nacional publicados pelo IGP.

image

O resultado desta definição é obtermos um mapa já em coordenadas WGS84, que podemos ver no ArcMap na barra inferior onde são mostradas as coordenadas do cursor.

image

Usar simbologia apropriada

Uma das coisas a que a Google nos habituou foi a vermos uma simbologia mais imaginativa, usando icones grandes e coloridos para representar pontos.

Em geral, os técnicos de SIG não usam este tipo de simbologia, mas o ArcMap inclui um conjunto de símbolos deste género que poderemos usar. Basta ligar o estilo “ArcGIS_Explorer” para vermos as opções disponíveis. Para vermos estes símbolos basta clicar no botão “More Symbols” no editor de simbologia dos pontos:

image

E assim podemos escolher um símbolo mais ajustado à utilização em Google Earth. O ArcGIS ao converter o layer para KML vai criar um pequeno ficheiro png que incluirá no nosso KML, e que será usado pelo Google Earth.

Para exemplificar escolhi o simbolo de uma cama de hotel e o aspecto do mapa ficou assim:

image image

Incluir atributos

O KML é uma linguagem muito flexível, permitindo associar informação descritiva aos elementos vectoriais. O ArcGIS facilita o processo de passar atributos para o KML, automatizando o processo. Claro que o processo automático tem limitações, mas para quem não quer ou não sabe editar KML manualmente, este automatismo é muito útil, e pode dar bons resultados.

Vários elementos passam do ArcMap para o KML automaticamente:

  1. O nome do layer passa como nome da pasta que contém os pontos
  2. A descrição do layer no ArcMap (nas propriedades, separador “General“), passa para o “Snippet” que descreve o layer no Google Earth
  3. As Labels do ArcMap são usadas para dar um nome a cada vector no Google Earth, e a própria label vai surgir na imagem no Google Earth
  4. Se no ArcMap definirmos as propriedades de “HTML Popup“, o Google Earth vai mostrar essa informação quando clicarmos sobre um ponto
  5. Se houver uma legenda no Layout do ArcMap, será passada ao KML e mostrada no Google Earth como uma imagem sobreposta à imagem do terreno (“screen overlay“), podendo no processo de exportação escolher o canto no ecrã onde surgirá

A ferramenta HTML Popup é uma variante da ferramenta de Identify, mas que mostra os atributos do vector clicado numa janela HTML que podemos configurar. Na sua forma pré-definida os campos são mostrados de acordo com as definições do separador “Fields“. Por exemplo, podemos esconder campos, e alterar a “Caption” para mostrar nomes de campos em português ou mais perceptíveis para o utilizador.

Portanto, para começar temos de definir as propriedades do HTML Popup do nosso layer de pontos no ArcMap. Para isso, nas propriedades do layer, separador “HTML Popup“, basta ligar a opção de usar a ferramenta de HTML Popup, e ao clicar no botão Verify podemos ver como ficará a janela de popup.

image

Podemos ainda melhorar o aspecto da janela se mudarmos as “Captions” dos campos e escondermos os campos que não nos interessa mostrar (usando o separador “Fields“). O aspecto final ficaria assim:

image

Rótulos ou Labels

Se definirmos labels no nosso layer de pontos, estes textos serão usados como o nome de cada ponto no KML final, e serão também visíveis no mapa junto a cada ponto. Portanto será uma questão de se querer ou não ligar as labels do layer e escolher o campo, a fonte, tamanho, cor, efeitos, etc. Mais importante será definir a escala a partir da qual os textos são mostrados, e que será respeitada pelo Google Earth. Se tiver muitos pontos aglutinados esta opção é praticamente obrigatória.

Executar a ferramenta “Layer To KML“

Esta ferramenta encontra-se na Toolbox de Conversão, toolset “To KML“:

image

Uma vez que queremos exportar a nossa informação como pontos e não como uma imagem, a questão mais importante nesta ferramenta é *não* ligar a opção de “Return single composite image“. Na caixa de “Output File” temos de indicar o caminho para o ficheiro a criar que deve ter obrigatoriamente a extensão KMZ (o ArcMap irá criar uma pequena imagem .png para mostrar o nosso símbolo no Google Earth que será incluída no ficheiro KMZ). Por fim, é obrigatório indicar a escala máxima de visualização. Ou seja, só a partir desta escala é que a informação será mostrada pelo Google Earth.

Resultado Final

E é tudo. Basta agora que no Google Earth usemos a opção File->Open para abrir o nosso ficheiro KMZ e ver o resultado final.

image

Existem ainda alguns melhoramentos que poderemos fazer: alterar o nome do layer no ArcMap irá alterar o nome do layer no Google Earth. Podemos também criar um ficheiro xsl para criar uma visualização alternativa com melhor estilo e até incluir imagens nas nossas janelas de popup (O ArcGIS inclui alguns exemplos na «directoria de instalação\ArcGIS\Styles» que podemos usar como base).

Existem muitas ferramentas de criação de KML a partir do ArcGIS que começaram a aparecer já há alguns anos, quando o ArcGIS não oferecia qualquer possibilidade de conversão. Com o tempo, a ESRI foi incluindo mais capacidades de conversão. Hoje, já na versão 9.3, fiquei impressionado com as capacidades nativas do ArcGIS – conseguimos obter um KML já com alguma sofisticação, e usando um processo de conversão bastante simples recorrendo a ferramentas e definições familiares a qualquer utilizador de ArcGIS.

Ortofotomapas do IGP no ArcGIS Online

Inicial, SIG, ,
Tempo de leitura: 2 min

Como é natural, durante o EUE09 foram feitos alguns anúncios sobre as próximas versões do ArcGIS e sobre a direcção que os produtos irão seguir no futuro próximo(2009-2010).

Um dos pontos frisados pela Linda Hecht, Directora de Marketing da ESRI Inc., e depois pelo Sandro Batista, Director de IDI na ESRI Portugal, foi o serviço ArcGIS Online, onde têm vindo a ser publicados alguns recursos para utilizar em ArcMap, ArcGlobe, e em aplicações ArcGIS Server. Estes recursos são projectos .mxd ou temas em formato .lyr que se podem acrescentar aos nossos próprios mapas, e que fazem ligação a dados remotos residentes nos servidores da ESRI.
A intenção da ESRI é fazer evoluir este serviço para uma plataforma mais colaborativa, integrando o site com ferramentas do próprio ArcGIS. Será interessante ver como o conjunto irá funcionar e até que ponto os utilizadores serão receptivos a esta abordagem.

Mas foi feito um outro anúncio pelo Sandro, relativo ao ArcGIS Online e que para mim caiu como uma bomba, mas no bom sentido! Os ortofotomapas do IGP, do ano 2004, e com resolução de 1m, estão publicados no ArcGIS Online na forma de .mxd e .lyr para o ArcGIS, e na forma de serviços REST para integração nas aplicações ArcGIS Server.

Ou seja, os utilizadores de ArcGIS podem abrir uma nova sessão de ArcMap e adicionar um tema com ortofotomapas para todo o País e sem custos. E isto é realmente algo significativo para todo o sector SIG e até para o sector da informação cartográfica… deixo a cada um o exercício de reflexão sobre o impacto desta iniciativa. (Estes são os mesmos ortofotomapas que foram disponibilizados via Virtual Earth.)

Na minha perspectiva, peca apenas por ser limitada aos utilizadores ESRI. Mas disponibilizar a mesma informação de forma mais abrangente caberá naturalmente ao IGP e não à ESRI, que neste momento oferece aos seus utilizadores um brinde fantástico. Aliás, se alguém da ESRI estiver a ler isto pode ser que coloquem um link logo na página principal do vosso site para informar todos os seus utilizadores desta oferta. Para se fazer justiça, obviamente que o IGP está de parabéns porque é o detentor dos dados.

Portanto, para usufruirem desta prenda de Natal atrasada, basta irem ao site arcgisonline.esri.com, e seguirem os links “Free maps” e “World User Imagery”. Nesta página podem ver os metadados da informação, bem como vários links para utilização nos produtos ArcGIS, incluindo um link de um .mxd e outro de um ficheiro .lyr.

Se gravarem o ficheiro .lyr numa partilha em rede, todos os utilizadores de ArcGIS na vossa organização poderão adicionar os ortofotomapas aos seus projectos.

Cuidado no entanto com o sistema de coordenadas, que é WGS 84. Para que os ortos se alinhem com a vossa informação é necessário definir o sistema de coordenadas da Data Frame e também a transformação de datum que querem usar. Por exemplo, se os vossos dados seguirem o sistema Hayford-Gauss, datum 73 (vulgo IGP), então definam o sistema da Data Frame para “Datum 73 Hayford Gauss IPCC”, e nas Transformações escolham transformar de WGS 84 para Datum 73, usando a transformação #4 que corresponde aos parâmetros publicados pelo IGP. Claro que o melhor será seguir as excelentes instruções do Prof. José Alberto Gonçalves que permitem reduzir os erros de conversão para uns míseros centímetros!

Visualizar CAD online

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

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

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

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

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

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

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

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

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

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

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

dwfviewer_1

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

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

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

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

Vantagens desta solução:

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

Desvantagens:

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

Links de interesse:

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

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

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

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

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

A página ficaria com este aspecto:

dwf_freewheel_1

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

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

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

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

Vantagens desta solução:

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

Desvantagens:

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

Links de interesse:

Conclusão

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

Google Maps lidera?

Gestão, SIG, , ,
Tempo de leitura: 2 min

Lembro-me da surpresa que foi em 2006, quando preparava slides para uma apresentação no curso pós-graduação sobre SIG leccionado no ISA, ao ver as estimativas sobre o número de visitas que as plataformas de mapas online recebiam só nos EUA.

A grande surpresa, além claro da enormidade dos números (42 milhões de visitas por mês! num só site), foi que a MapQuest era a #1 incontestável, com mais do dobro de visitas que o n.º 2 contabilizava. E o n.º 2 era o Google Maps…

Se pensarmos no facto de ter sido o Google Maps a primeira experiência com mapas na web para a maioria dos Internautas, e se considerarmos que a MapQuest é praticamente desconhecida do público em Portugal, a surpresa ainda é maior. E parecia ainda mais impossível a diferença do n.º de visitas ser tão gigantesca… Mas era um facto irrefutável, a MapQuest era a líder dos serviços online que apresentavam mapas com rotas/percursos.

Agora, 3 anos depois, surgem números que indicam que o Google Maps superou a MapQuest no mês de Janeiro de 2009. Embora se encontrem números discordantes quanto à liderança, o que ninguém discorda é que estes 2 sistemas estão a lutar lado-a-lado pela liderança.

Interessante também é analisar os 2 gráficos apresentados pelo Web Mapper, que ilustram como a vantagem da MapQuest foi desbaratada em  apenas 12 meses: não foi só o Google Maps que conseguiu aumentar a sua quota de visitas mensais de forma significativa (30% a 70% consoante a fonte), mas a MapQuest também foi responsável pelo seu próprio desaire, perdendo 9% de visitantes no último ano.

Quais as razões para a subida da Google e descida da MapQuest?

Em relação à Google podemos dizer que é mais do mesmo – melhoria dos serviços aliada à visibilidade da marca e imagem positiva que tem junto do público. É natural que os utilizadores do motor de busca, do GMail, Google News e outros, que estando satisfeitos usem também o Google Maps. Aliás, há dados que indicam que 61% das visitas no Google Maps vieram dos links apresentados nas pesquisas do Google.

Por seu lado, a MapQuest é criticada pela agressividade dos seus serviços de publicidade, que colocam os anúncios no centro de atenção das páginas. Ou seja, são demasiado intrusivos, e os utilizadores não se têm mostrado agradados com isso… a isto soma-se a lentidão em investir na plataforma para a modernizar e aproximar das plataformas concorrentes da Google e Microsoft. Mas é discutível se haveria algo que a MapQuest pudesse fazer para combater aquilo que os recursos imensos dos seus 2 concorrentes lhes permite fazer (novas funções, dados recentes e de excelente qualidade,…).

A ver vamos o que o futuro nos reserva. Pessoalmente, gosto que haja concorrência entre os serviços que utilizo. Por isso, desejo melhores dias e mais sabedoria à MapQuest.

PS – Para quem tiver curiosidade em conhecer o percurso da MapQuest, pode ver aqui um artigo sobre a sua história – de uma empresa tradicional de mapas a líder mundial de mapas online.

Medindo o Desempenho de Servidores SIG

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

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

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

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

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

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

Configurações dos servidores em comparação

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

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

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

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

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

Software de Testes – JMeter

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

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

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

Gravando um teste

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

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

JMeter_testeinicialopt

Alterar o teste de desempenho

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

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

O teste resultante ficou com o seguinte aspecto:

JMeter_testefinal_opt

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

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

Testando

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

Resultados e análise com 1 utilizador

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

Aggregate Report_1ediasigims_opt

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

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

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

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

Aggregate Report_1ediabeja019_opt

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

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

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

Resultados e análise com 10 utilizadores

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

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

Aggregate Report_1ediasigimsx10_opt

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

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

Aggregate Report_1ediabeja019x10_opt

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

Conclusão

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

 

Mapas/min

KB/s

Mapas/min

KB/s

Xeon P4 3,2GHz

21,3

5,1

51,7

12,4

Xeon Quad 2GHz

39,9

10,2

132

33,7

melhoria %

87%

100%

155%

172%
 

1 utilizador

10 utilizadores

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

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

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

Planeta SIG – problemas com alguns feeds

SIG
Tempo de leitura: < 1 min

Nas últimas semanas verifiquei que alguns blogs começaram a não ser actualizados no Planeta SIG. Depois de investigar, percebi que certos blogs provocavam erros devido a carateres portugueses nos títulos ou à codificação (encoding) das datas… Para facilitar pesquisas no Google, aqui fica o erro:
ERROR:planet.runner:UnicodeDecodeError: 'utf8' codec can't decode bytes in position 3-5: invalid data
(...)
ERROR:planet.runner: File "C:\...\planet\reconstitute.py", line 110, in date
     xdate.setAttribute('planet:format', formatted.decode('utf-8'))
ERROR:planet.runner: File "c:\python25\lib\encodings\utf_8.py", line 16, in decode
Depois de muitas tentativas, lá consegui chegar à solução, e mais uma vez vi-me forçado a alterar o código, o que vai dificultar ainda mais a actualização do Planeta quando sairem novas versões do software “Venus”.
Para ficar registado, aqui fica a alteração mágica que resolveu o problema. No ficheiro reconstitute.py, comentar a linha 110:
#xdate.setAttribute('planet:format', formatted.decode('utf-8'))

E adicionar em seu lugar as seguintes linhas:
try:
      xdate.setAttribute('planet:format', formatted.decode('utf-8'))
except:
      xdate.setAttribute('planet:format', formatted.decode('iso-8859-1'))

Suspeito que esta alteração deveria ser feita em todas as ocorrências de decode(‘utf-8’), mas isso ficará para quando encontrar mais erros e houver tempo. Em jeito de remate, aumentei também o tempo máximo de espera de 20 para 60s para que não haja tantos casos de erros de “timeout” (quando os servidores onde estão alojados os blogs demoram demasiado a responder).

Aos blogs afectados (Georden e Geo:metrik) as minhas desculpas.

Até breve.