PostgreSQL e ESRI – parte 2

Intermédio, Open Source, PostgreSQL, SIG, ,
Tempo de leitura: 4 min

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.

Cartografia inglesa gratuita

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

Pois é… o Ordnance Survey, autoridade nacional de cartografia inglesa, e produtora de vários produtos cartográficos, vai disponibilizar gratuitamente os seus produtos a partir da escala 1:10.000. Incluíndo para fins comerciais.

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

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

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

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

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

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

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

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

Novo fornecedor de alojamento

Gestão, PlanetaSIG, WordPress, ,
Tempo de leitura: 2 min

Espero que este seja o meu último post sobre alojamento de sites por muitos e bons anos!

Concluí a transferência do domínio viasig.com (blog e planetasig) para um novo fornecedor.  Já relatei aqui a razão que me levou a mudar da Esoterica para outro fornecedor e não desejo voltar a ter problemas deste género…

Mas acabou por ser uma experiência positiva porque acabei por ficar melhor servido. Se não vejamos as condições do novo serviço:

Preço Anual 29,40€
Espaço em disco 1 GB
Tráfego Ilimitado
Domínios 1
Subdomínios Ilimitados
PHP 4 e 5
Python 2.4.3
Tomcat/JSP ok
Ruby ok
MySQL 5.0
PostgreSQL 8.1
Tarefas Agendadas Cron
Acesso Shell JailedShell

Por um preço muito semelhante consigo mais 3 características a que não tinha acesso e que fazem uma grande diferença:

  1. Tarefas agendadas para controlar facilmente o refrescamento das entradas no Planeta SIG;
  2. Acesso Shell para perceber os problemas com os scripts do Planeta SIG (Planet Venus);
  3. e ainda… PostgreSQL!!

Na verdade o meu novo fornecedor – Lefatech – não inclui o acesso à shell de raíz neste pack. Mas bastou-me solicitar, justificando a necessidade, e o acesso foi configurado na hora. Em contraste, quando pedi à Esoterica para criar uma tarefa agendada informaram-me que teria de fazer um upgrade para um plano que custa 108€/ano!

Com este novo alojamento ainda ganho o suporte a PostgreSQL o que poderá ser útil se surgir a oportunidade de criar algum site com mapas dinâmicos. Faltará o módulo PostGIS, mas também faltava o módulo mod_python ao Apache, e foi compilado e configurado pelo suporte técnico em poucos dias. Por isso pode ser que se consiga o PostGIS se for necessário!

A transferência para o novo servidor ficou activada hoje, sem que eu notasse qualquer anomalia. Aproveitei para actualizar o WordPress para a última versão (2.8.6). Se algum leitor notar algum problema por favor avise-me usando os comentários.

A propósito, o WP ganhou o prémio de melhor CMS Open Source de 2009!

Pequeno problema com feeds do Planeta SIG

PlanetaSIG
Tempo de leitura: < 1 min

Enquanto tentava resolver o problema de executar python para refrescar os artigos no Planeta SIG, parece que acabei por baralhar os feeds, entre o Planeta SIG e o meu próprio blog… penso ter tudo resolvido, e ficam aqui as minhas desculpas pelo lapso.

Em breve mudarei o domíno viasig.com para uma nova empresa de hosting para garantir que este tipo de problemas sejam mais fáceis de resolver!!

SASIG II – Notas

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

As 2ªs Jornadas de Software Aberto de Sistemas de Informação Geográfica terminaram, e pensei em escrever um pequeno post sobre o evento.

Em relação à organização, foi consensual – a qualidade do evento foi muito acima da média, mesmo comparando com eventos de muito maior dimensão. O espaço estava bem adaptado e equipado, e o evento social (jantar) foi simplesmente fantástico.

Mas o que mais sobressaiu foi o espírito que se viveu na conferência. Falando com várias pessoas, todas apontavam este sentimento de partilha, entre-ajuda, e camaradagem, como algo de especial, que não se vê noutros congressos. Por isso, aconselho vivamente a quem se interesse pela área dos SIG que assista às próximas SASIG em 2010, que serão em Lisboa (temos de aguardar por mais detalhes).

Convidados

O facto de termos presentes alguns convidados de fora, envolvidos em projectos de grande projecção, também ajudou e muito a elevar o nível de interesse. Estiveram presentes e fizeram apresentações responsáveis dos projectos World Wind (da NASA), do gvSIG, do Sextante. Também foi muito interessante ouvir as experiências e opiniões de pessoas envolvidas no desenvolvimento de comunidades noutros países, havendo representantes da própria OSGeo internacional, e dos capítulos locais Italiano e Espanhol.

Comunicações

Quanto às apresentações, foi apresentado um bom painel de assuntos, muito abrangente. Das apresentações que vi, apreciei muito 2 apresentações de mestrandos, com excelente nível técnico, o que comprova a qualidade do nosso ensino e dos nossos estudantes. Precisamos de mais casos assim, e pessoalmente gostaria de ver mais comunicações universitárias com tão elevado grau de exigência.

Todas as comunicações estão já disponíveis para download (84MB), e parece que teremos o video também em breve:

http://evora.sigaberto.org/downloads/apresentacoes.zip

Uma apresentação que me chamou a atenção em especial foi a do Sapo Mapas. Este site de mapas aparentemente fez tudo bem: tem cartografia temática de grande qualidade, com uma quantidade impressionante de pontos de interesse (200 mil agora, para breve 600 mil), pesquisa de códigos postais 7 dígitos, itinerários, “trânsito em directo”, fotografias panorâmicas, e ainda uma API que qualquer pessoa e empresa pode usar para incluir mapas no seu próprio site, e totalmente gratuita, mesmo em caso de sites com fins comerciais. A continuar assim, esta é uma grande novidade em Portugal, e penso que o é mesmo a nível mundial. Não conheço outra API que tenha uma licença tão livre, ficando Portugal mais bem servido que todos os outros países. É claro que fica o receio da PT alterar o licenciamento e ficarmos com o nosso site ilegalizado, mas para já o facto é que é gratuita.

A API é muito semelhante à do OpenLayers, pelo que será muito familiar a quem conhece. No site do Sapo Mapas há documentação e exemplos para quem quiser aventurar-se. Mas acho algo penoso que tenham reinventado a API do OpenLayers – podiam ter usado o original.

Workshops

Foram realizados diversos worshops, ou sessões práticas de 3-4h, sobre diversos programas: gvSIG, OpenLayers, PostgreSQL/PostGIS, Quantum GIS, World Wind, Linux, Sextante, GISVM, e MapServer.

Pretende-se publicar online os materiais de cada workshop (dados e slides), mas para já temos a possibilidade de obter um zip dos dados de cada workshop no site das jornadas aqui:

http://evora.sigaberto.org/?q=node/85

Uma iniciativa que achei interessante foi a de ter sido criada uma distribuição Linux própria para estes workshops, com todo o software pré-instalado. Poderão ter de ainda copiar os dados dos workshops, mas de resto está tudo lá. Podem obter esta distribuição no mesmo link dos workshops.

Se gravarem o ficheiro (iso ou img) para uma pen usb ou para um DVD, podem ligar o computador a partir destes suportes, ficando com uma máquina Linux funcional, sem necessitar de mais instalações de software. Também se quiserem, podem converter estes ficheiros numa máquina virtual, que pode ser usada mesmo em Windows, novamente sem instalações de software (a não ser, claro, o software para utilização de máquinas virtuais – por exemplo o Virtual Box OSE).

Para breve está prometido um local para descarga dos materiais incluindo os slides.

Resolvido o problema do Planeta SIG

PlanetaSIG,
Tempo de leitura: 3 min

O Planeta SIG deixou de ser actualizado por uns dias. Penso que agora a situação está normalizada. Por agora será actualizado 4h em 4h, e posteriormente pretendo voltar à actualização em intervalos de 1h.

Nunca me tinha defrontado com problemas no relacionamento com a empresa que me fornece o hosting, ou seja, o serviço onde alojo o Planeta SIG.

O serviço funcionou praticamente de forma automática durante quase 1 ano. E um destes dias o site desapareceu completamente… a Esoterica suspendeu o domínio. Ao consultar a minha conta de email pessoal lá estava um email enviado há 5 horas dizendo que havia um problema com o meu domínio, e que estava a comprometer a estabilidade do servidor, onde outros utilizadores teriam os seus sites.

Naturalmente que um só cliente não pode prejudicar tantos outros. E a suspensão não me parece assim tão mal dadas as circunstâncias. O que é lamentável é a forma como o processo de re-activar o Planeta SIG foi executado… levando a uma paragem de 1 semana. Sucedeu que decidiram bloquear algumas das funções necessárias à actualização do Planeta SIG, e por mais que tentasse foi-me impossível executar o script de actualização. O software que uso é o mais utilizado em todo o mundo, sendo a base de outros planetas como o Planet WordPress, o Planet Ubuntu, ou o “nosso” Planet Geospatial. Portanto, não será propriamente software malicioso…

Neste momento, consigo já executar o script. E espero que a situação se mantenha assim.

Qual foi o problema?

O que aconteceu foi um bug no processo de actualização do site. Como não tenho acesso às capacidades de agendamento de tarefas do servidor, usei um serviço que de 1  em 1 h chamava o script de actualização.

Tudo corria muito bem. Mas a dada altura, algo mudou no servidor, e o script começou a devolver erros de timeout. O erro de timeout não impedia que o script concluísse as tarefas de actualização e por isso no Planeta SIG tudo parecia normal. O problema foi que ao receber o erro de timeout, o tal serviço que devia executar o script 1h/1h passou a fazê-lo a cada minuto! Ou seja, o servidor foi inundado de pedidos para executar o meu script de actualização! Oops.

Bom, a solução foi resolver este bug. E a partir daqui ignorar os erros de timeout. E garantir que só se executa o script de actualização no intervalo estabelecido de 1h.

Só que nesta altura a Esoterica começou a dificultar as coisas, apertando as restrições de segurança ao ponto de não conseguir executar o script de actualização. E isto arrastou-se por 1 semana.

Decisões, decisões

O poder negocial dos clientes é realmente muito pequeno frente às empresas que fornecem o alojamento de sites, e a facilidade com que estas podem abusar da sua posição é preocupante, mesmo que nem se apercebam que a atitude que estão a tomar pode ser violenta para o cliente e destruir um projecto.

A hipótese de mudar de fornecedor de alojamento foi a primeira ideia que me ocorreu e tenho já seleccionadas as alternativas que me pareceram melhores. Mas… há sempre a probabilidade do problema voltar a acontecer.

A hipótese de passar a usar um PC em casa como servidor web é por isso muito atractiva, pela independência que oferece. Alguém sabe quanto custará, em electricidade, manter um PC ligado o ano inteiro? E o custo de ter um endereço IP fixo?

Para o custo de electricidade encontrei referências a preços de 2008:

Um PC que consome 200w em tarifa bi-horária, 30 dias por mês, 12 meses por ano, pagou em 2008 13,35€ por mês, num total anual de 160€.

A somar ainda o custo de ter um IP fixo (que não qual é)…

Comparando com o custo de 20€/ano para ter um serviço de hospedagem, a opção caseira é um tudo-nada mais caro.

Conclusão e Futuro

Em resultado destas dificuldades, e por ter a sempre incerteza sobre se o serviço de actualização não voltará a provocar um problema destes, comecei a desenvolver um PlanetaSIG em PHP, baseado na excelente biblioteca SimplePie. Mas o tempo é curto e não sei quando terminarei. A outra coisa a fazer é encontrar um serviço de hospedagem que permita a utilização de tarefas agendadas a um preço baixo. Se alguém souber de um, estou muitíssimo interessado!

Até breve.

O puzzle das patentes de software

Gestão
Tempo de leitura: 2 min

Não percebo grande coisa de patentes de software, mas fiquei mais atento ao assunto desde as campanhas na europa contra e a favor deste tipo de leis que houve há uns anos. É realmente um conceito assustador e difícil de debater… por um lado, penso que deverá haver um mecanismo que proteja os inventores no mundo do software, tal como no mundo mais físico das invenções mais tradicionais. Veja-se o exemplo do inventor do limpa pára-brisas ilustrado no filme “Flash of Genius”, que foi enterrado em anos de luta judicial pelas grande companhias da indústria automóvel dos EUA. Teve de gastar uma vida para poder ver os seus direitos reconhecidos… a postura dos seus usurpadores foi que ele era pequeno demais e seria por isso derrotado pelo esforço da batalha judicial e não por ter ou não razão. Mas por outro lado…

Agora, temos o caso extraordinário da Microsoft ter sido proibida de comercializar o seu Word! Depois de uma pequena firma Canadense ter provado que uma patente sua é usada pelo programa, de forma não autorizada, o juíz  achou por bem mandar parar a venda do programa infractor…

Esta decisão causa-me algum espanto. Estou convencido que a lei de patentes acaba por interessar bem mais aos interesses das grandes empresas do que das pequenas empresas e individuos, tal como é ilustrado no filme. Penso que a situação actual nos EUA é mantida muito pela inércia criada pelas grandes empresas. Afinal, em 100 casos irão ganhar a maioria e assim o balanço custo-benefício será positivo. Mas neste caso da Microsoft, se a decisão de parar a venda do Word for realmente avante, o prejuízo para a MS deverá ser substancial. Muito substancial…

Mas o pasmo aumenta quando lemos o que esta patente protege:

(…)the capability of opening a .XML, .DOCX, or .DOCM file (“an XML file”) containing custom XML.

Será que esta descrição não abrange uma imensidão de programas? Mesmo considerando que foi registada em 1994 e aceite em 1998, parece um pouco oca.

Para além da lição de “provar o seu próprio veneno”, onde uma grande empresa acaba derrotada em tribunal por causa de patentes de 3ros, dá a sensação que esta patente é tão genérica e tão vazia de conteúdo original, que ficamos todos em risco sempre que escrevermos um programita que lide com ficheiros xml.

Como se chegou a este ponto? Onde está o bom senso? Se calhar, para as coisas mudarem, terá de haver algumas grandes empresas a sofrerem grandes rombos financeiros.

Bom, agora tenho de ir. Quero ver se patenteio uma ideia fenomenal… “o acto de ligar um computador meramente por premir um botão cujo aspecto varia com o design do computador”. O que acham? Se calhar pega…

Jornadas SASIG e Mapping Party

Open Source, SIG
Tempo de leitura: 2 min

As II Jornadas de Software Aberto para Sistemas
de Informação Geográfica vão ter lugar em Évora nos dias 2-4 Novembro de 2009.

É o único evento desta temática que conheço em Portugal. Quem se interessa por este tipo de software, já praticante, curioso, ou em fase de investigação, pode agora assistir a esta conferência, ver as apresentações, frequentar os diversos workshops práticos (cursos relâmpago de 1/2 dia), e sobretudo conviver num ambiente descontraído e muito entusiasta!

As inscrições quer na conferência quer nos workshops é feita no site das II Jornadas SASIG aqui:

http://evora.sigaberto.org/

Quero também aproveitar para promover o mais possível este evento incluído nas SASIG:

Vai haver uma OpenStreetMap Mapping Party em Portugal!!

Quem quiser pode participar no levantamento das ruas de Évora, e aprender o processo de publicar essa informação na base de dados do projecto.

Para quem não conhece, o OpenStreetMapping é uma iniciativa que visa construir uma base de dados mundial gratuita com vias de comunicação, e não só: pontos de interesse, zonas verdes, muitos outros dados, e até ortofotomapas (ver o projecto “irmão” OpenAerialMap).

O processo de construção desta bd é o mesmo que criou a Wikipedia: “crowdsourcing”. Todos podemos participar, havendo ferramentas para trabalhar online ou no desktop, mais e menos complexas. Mas nem só de voluntários é feita a bd do OSM, havendo também doações de informação (alô IGP? alô IGeoE?).

Para garantir a liberdade dos dados, não se pode utilizar fontes protegidas por copyright, pelo que vectorizar sobre imagens do Google Maps/Earth não é permitido. Mas podemos usar mapas cujo copyright tenha expirado, ou até a imagem aérea do Yahoo Maps, que deu uma licença especial à OSM, para vectorizar os nossos dados. Mas o método mais interessante e divertido é o levantamento directo com GPS.

E os dados são de quem, depois de carregados? São de Todos! E qualquer pessoa pode obter cópia dos dados para a área de interesse que entender, e usá-los para o que entender (menos comercializar). Para proteger esta liberdade foi criada a OpenStreetMap Foundation.

Para os cépticos, fica aqui uma imagem de Londres dos dados existentes na bd à data de hoje:

Estado dos dados de Londres em Ago/09
Estado dos dados de Londres em Ago/09

E agora uma imagem de Évora (vergonha):

Estado dos dados de Évora em Ago/09
Estado dos dados de Évora em Ago/09

Portanto, quem quiser passar uma boa tarde a conviver com outros geeks geográficos na belíssima cidade de Évora e a contribuir para uma iniciativa histórica, venha daí e inscreva-se no site aqui:

http://evora.sigaberto.org/?q=node/66

Lá nos veremos!

PlanetaSIG com extractos de posts com 500 caracteres

PlanetaSIG
Tempo de leitura: 4 min

A pedido de um dos autores, a partir de hoje, o PlanetaSIG tem a capacidade de mostrar apenas os primeiros N caracteres de cada post. A configuração proposta é mostrar 500 caracteres, permitindo aos leitores do agregador decidir se lhe interessa visitar o blog original para ler o post completo.

O agregador tem funcionado inspirado no PlanetGS e como tal mostra numa única página os posts de forma integral, dos blogs que agrega.

Pessoalmente, leio o PlanetaSIG bem como outros planetas e blogs com o Google Desktop, usando a sidebar onde vejo os títulos dos itens a serem refrescados. Ao clicar num item, é aberto directamente o blog original, sem passar pelo PlanetaSIG (ou outro agregador).

Acontece que o PlanetaSIG pode ser consultado directamente, visitando a página. E nesse caso é bem possível que esse visitante já não irá visitar os blogs originais, reduzindo o tráfego desses blogs. E compreendo perfeitamente os autores que querem evitar esta situação (e mesmo que não concordasse agiria da mesma forma – o autor é soberano).

Com esta nova possibilidade espero resolver a questão de forma simpática para todos.

Portanto, quem tem o seu blog agregado no PlanetaSIG e que assim deseje pode enviar-me um email e eu configurarei o seu feed para mostrar apenas um extracto dos posts. O modo default para quem não se manifestar continuará a ser mostrar os posts integrais, mantendo um pouco a mesma lógica dos planetas mais globais como o PlanetGS e o PlanetOSGeo.

Aproveito para pedir sugestões para blogs que possam ser incluídos no PlanetaSIG!!

Detalhes técnicos

O PlanetaSIG é gerado pelo software Venus, escrito em Python. O Venus não permite de raíz configurar o n.º de caracteres a mostrar em cada post, nem permite usar o sumário ou excerpto incluído nos feeds, em vez de mostrar o conteúdo. Já antes tinha tentado configurar o Venus para fazer esse efeito mas sem sucesso.

Mas o Venus tem a capacidade de aplicar filtros a cada feed RSS, e de forma independente. Ou seja, podemos aplicar um filtro a um feed, e outro filtro diferente noutro feed, e até ter outros feeds sem filtro algum.

Um filtro é um pequeno script escrito em Python (também pode ser um xslt), que vai ser executado para cada item dentro de um feed, podendo transformá-lo da maneira como o programador quiser. Por exemplo, podem retirar-se todas as referências a imagens, ou substituir tags <h1> por <h3> ou outro qualquer, aplicar classes css a determinados tags, etc.

O que acabei por fazer foi criar um filtro que pega no <content> de cada post e o substitui por apenas os primeiros N caracteres do original. Este filtro pode ainda substituir o <content> por outro tag qualquer – por exemplo, copiar o sumário para o content. Como o Venus só consegue mostrar o <content>, passa a mostrar o sumário sem saber…

O código do novo filtro foi baseado num filtro que vem já incluído no Venus – excerpt.py. Fica aqui o código para referência futura.

Até breve.

Cria um novo elemento ou substitui um existente,
com o texto de outro elemento, truncado com X caracteres.
Baseado no filtro excerpt.py e alterado por Duarte Carreira em 16/Julho/2009.

Parameters:
  width:  maximum number of characters in the excerpt.  Default: 500
  omit:   whitespace delimited list of html tags to remove.  Default: none
  target: name of element created.  Default: content
  source: name of element to get data from. Default: summary
  replace: yes to delete duplicate target. Default: yes

Example to test:
python tests/reconstitute.py http://localhost/feedorig.xml
--filters "planetaSIG.py?width=500&source=content&target=content&replace=yes">tes
te3.xml

Notes:
* if you want to avoid duplicate entries use replace=yes.
* Venus does not expose summary in the feeds to tmpl templates. With this filter,
   you cant replace the text inside content with the text from summary. This is
   what the default values do.
* if 'img' is in the list of tags to be omitted <img> tags are replaced with
   hypertext links associated with the value of the 'alt' attribute.  If there
   is no alt attribute value, <img> is used instead.  If the parent element
   of the img tag is already an <a> tag, no additional hypertext links are
   added.
"""

import sys, xml.dom.minidom, textwrap
from xml.dom import Node, minidom

atomNS = 'http://www.w3.org/2005/Atom'
planetNS = 'http://planet.intertwingly.net/'

args = dict(zip([name.lstrip('-') for name in sys.argv[1::2]], sys.argv[2::2]))

wrapper = textwrap.TextWrapper(width=int(args.get('width','500')))
omit = args.get('omit', '').split()
target = args.get('target', 'content')
original = args.get('source', 'summary')
replace = args.get('replace','yes')

class copy:
    """ recursively copy a source to a target, up to a given width """

    def __init__(self, dom, source, target):
        self.dom = dom
        self.full = False
        self.text = []
        self.textlen = 0
        self.copyChildren(source, target)

    def copyChildren(self, source, target):
        """ copy child nodes of a source to the target """
        for child in source.childNodes:
            if child.nodeType == Node.ELEMENT_NODE:
                 self.copyElement(child, target)
            elif child.nodeType == Node.TEXT_NODE:
                 self.copyText(child.data, target)
            if self.full: break

    def copyElement(self, source, target):
        """ copy source element to the target """

        # check the omit list
        if source.nodeName in omit:
            if source.nodeName == 'img':
               return self.elideImage(source, target)
            return self.copyChildren(source, target)

        # copy element, attributes, and children
        child = self.dom.createElementNS(source.namespaceURI, source.nodeName)
        target.appendChild(child)
        for i in range(0, source.attributes.length):
            attr = source.attributes.item(i)
            child.setAttributeNS(attr.namespaceURI, attr.name, attr.value)
        self.copyChildren(source, child)

    def elideImage(self, source, target):
        """ copy an elided form of the image element to the target """
        alt = source.getAttribute('alt') or '<img>'
        src = source.getAttribute('src')

        if target.nodeName == 'a' or not src:
            self.copyText(alt, target)
        else:
            child = self.dom.createElement('a')
            child.setAttribute('href', src)
            self.copyText(alt, child)
            target.appendChild(child)

    def copyText(self, source, target):
        """ copy text to the target, until the point where it would wrap """
        if not source.isspace() and source.strip():
            self.text.append(source.strip())
        lines = wrapper.wrap(' '.join(self.text))
        if len(lines) == 1:
            target.appendChild(self.dom.createTextNode(source))
            self.textlen = len(lines[0])
        elif lines:
            excerpt = source[:len(lines[0])-self.textlen] + u' \u2026'
            target.appendChild(dom.createTextNode(excerpt))
            self.full = True

# select summary or content element
dom = minidom.parse(sys.stdin)

#source = dom.getElementsByTagNameNS(atomNS, 'summary')
#if not source:
#    source = dom.getElementsByTagNameNS(atomNS, 'content')
source = dom.getElementsByTagNameNS(atomNS, original)

# if present, recursively copy it to a planet:excerpt element
if source:
    fonteelem = source[0]
    if target.startswith('planet:'):
        dom.documentElement.setAttribute('xmlns:planet', planetNS)
    if target.startswith('atom:'): target = target.split(':',1)[1]
    excerpt = dom.createElementNS(planetNS, target)
    source[0].parentNode.appendChild(excerpt)
    copy(dom, source[0], excerpt)
    #source[0].parentNode.replaceChild(excerpt, source[0])
    #if source[0].nodeName == excerpt.nodeName:
    #  source[0].parentNode.removeChild(source[0])

#apagar o original
if replace == 'yes':
    source = dom.getElementsByTagName(target)
    fonteelem = source[0]
    if len(source)>1:
        source[0].parentNode.removeChild(source[0])

# print out results
print dom.toxml('utf-8')

PostgreSQL e ESRI – Parte 1

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

A atracção do software Open Source é também sentida pelos utilizadores ESRI. Numa discussão na web li uma vez alguém descrever um utilizador de ArcGIS da seguinte maneira: “a única forma de retirar o ArcGIS das mãos de um utilizador é arrancá-lo das suas mãos mortas e frias”… a crer nisto, no lado de aplicações SIG desktop não será fácil substituir o ArcGIS por qualquer outra alternativa.

Será no entanto mais fácil explorar alternativas para os componentes que se encaixam na área dos servidores SIG, ou seja, bases de dados espaciais e servidores webGIS. Um dos produtos Open Source que tem recebido muita atenção na comunidade ESRI é o par PostgreSQL+PostGIS, que recentemente foi incluída na lista de bases de dados suportadas pela ESRI.

A partir da versão 9.3 a ESRI incluiu a possibilidade de utilizar, com toda a sua família de software ArcGIS, a base de dados PostgreSQL e o seu módulo geoespacial PostGIS, ambos Open Source. Esta possibilidade é muito atraente por vários motivos, sendo para mim os mais importantes:

  • PostgreSQL e PostGIS são produtos de grande qualidade, grande difusão, com utilizadores de referência credíveis, existindo uma comunidade muito activa ao seu redor;
  • São Open Source e gratuitos;
  • Oferecem funções de manipulação e análise geográfica de dados vectoriais através de SQL, ombreando com os melhores produtos existentes, open source ou comerciais;
  • Seguem os standards da indústria para SQL espacial (da OGC, e neste momento está em fase de implementar o standard da ISO), o que é obviamente uma abordagem irrepreensível e de enorme importância;
  • Quase a totalidade das aplicações SIG Open Source são compatíveis com esta bd;
  • O facto da ESRI incluir esta base de dados no grupo de sistemas suportados “oficialmente”, oferece uma segurança aos departamentos de TI que pode ser um factor decisivo na adopção ou não do PostgreSQL na empresa (e eu sei que este ponto gera polémica na comunidade de utilizadores e apoiantes, mas é um facto que existe esta barreira).

Porquê mudar?

Uma plataforma SIG muito comum, e aquela com que mais trabalho, é baseada em Oracle e ArcSDE, onde vários utilizadores de ArcGIS visualizam e editam a informação aí residente, havendo também servidores webGIS e aplicações que utilizam a informação residente em Oracle/ArcSDE. Neste artigo vou frequentemente referir esta arquitectura como ponto de comparação.

Quando já existe, trocar de base de dados não é tarefa fácil, consoante o volume e complexidade da informação existente, da dependência das aplicações desenvolvidas, e das novas competências que será necessário adquirir. Mas, há um  momento fulcral na vida de uma base de dados durante o qual vale tudo: a migração de servidor e upgrade de versão!

Nesta situação, a vantagem de migrar para PostgreSQL/PostGIS é passar a contar com um grande conjunto de aplicações SIG Open Source que podem usar a base de dados sem passar pelo ArcSDE – ou seja, podemos usar software não-ESRI e software ESRI para ler e manter a base de dados geográfica, efectivamente criando um sistema híbrido. (NOTA: uso aqui a expressão “SIG Híbrido” no sentido de integrar componentes comerciais e componentes Open Source num sistema de forma a usufruir das vantagens de cada componente, com as dificuldades inerentes, tal como Dan Dale Lutz tão bem explicou aqui.)

Note-se que esta interoperabilidade já é possível em alguma medida, especialmente com Oracle, desde que os dados sejam armazenados em Oracle Spatial ou Locator (sempre incluído em todas as versões Oracle). Só que neste caso existem muito menos aplicações SIG que lêem este tipo de dados, algumas Open Source. Mas em geral, as opções Open Source têm uma compatibilidade pouco fiável e de instalação nem sempre fácil. Por outro lado, tenho encontrado sistematicamente um desempenho muito inferior ao usar ArcGIS com dados Oracle Spatial quando comparado com o modo tradicional do ArcSDE armazenar dados em Oracle (denominado SDEBINARY). Mais sobre estas opções adiante…

Um sistema híbrido porquê?

O cenário de adoptar o PostgreSQL num SIG baseado em ESRI (ou Autodesk) implica que se pode manter todo o restante ecossistema SIG – ferramentas desktop, servidores webGIS, e aplicações desenvolvidas, bem como o nível de produtividade actual da equipa de edição/análise (que tipicamente é atingido após anos de experiência da equipa técnica com estas ferramentas). E ainda se abrem as portas para alargar o ecossistema a ferramentas  Open Source e de outros vendedores.

No caso da ESRI, todo o seu software comunica com o ArcSDE para chegar aos dados, e não directamente com a base de dados. Por isso a troca por outra bd não tem qualquer impacto sobre a restante plataforma SIG. E isto é uma vantagem. Claro que a desvantagem é o preço do ArcSDE…

No caso em que o ArcSDE já existe, podemos alegremente ignorar este custo (embora o custo de manutenção anual continue a existir)!! Em situações onde não exista ArcSDE deve-se incluir o seu custo de aquisição na análise das alternativas disponíveis.

A vantagem do SQL espacial

Um dos grandes trunfos de usar uma bd que, como o PostgreSQL+PostGIS, oferece funções de manipulação e análise espacial por SQL é podermos usar comandos na própria bd que vão efectuar as análises que estamos habituados a fazer apenas com as nossas ferramentas SIG desktop favoritas.  (Aliás, para ser exacto, o ArcSDE desde a v9.3 adiciona sempre o seu próprio dialecto de SQL espacial à bd onde é instalado, que pode ser usado como alternativa ao SQL nativo da bd. Isto também se aplica ao PostgreSQL. O administrador da bd é que decide se usa o dialecto da ESRI ou o dialecto nativo da bd.)

Por exemplo, com SQL espacial é possível seleccionar as classes de solo intersectadas pelo novo traçado do IP2, recorrendo apenas ao PostgreSQL, e sem usar ArcView. E como a máquina onde se instalam bases de dados é tipicamente muito mais potente que o nosso posto de trabalho, a velocidade de processamento destas análises será também superior. Já para não falar de evitar a transmissão de dados na rede entre a bd e o posto de trabalho. Apenas os resultados são transmitidos à aplicação SIG para visualização.

Então porque é que não estamos todos a usar SQL espacial para fazer análise geográfica?

Porque ainda é preciso que o utilizador saiba escrever estes comandos SQL! E isto não é uma tarefa trivial. Notem que escrevi “ainda é preciso saber…” sendo a palavra chave “ainda“. Isto porque hoje todas as bases de dados comerciais têm suporte a SQL espacial – Oracle, SQL Server, DB2, Informix – umas há mais tempo que outras, umas com SQL mais padronizado que outras, mas a funcionalidade está lá. O que falta são as aplicações que sabem executar essa análise nessas bd’s, facilitando a vida ao utilizador com botões e menus amigáveis, e dispensando assim o conhecimento de SQL espacial!

Por exemplo, quando o ArcView calcula um buffer não utiliza as capacidades da bd de cálculo de buffers, mesmo que elas existam. Apenas lê os dados armazenados na bd, e usa o nosso posto de trabalho para fazer o cálculo. E a esmagadora maioria das aplicações SIG actuais fazem o mesmo, quer comerciais quer Open Source.

Mas parece-me inevitável que ao longo dos próximos anos assistamos à mudança deste paradigma. Até porque desde que a Microsoft incluiu SQL espacial no SQL Server 2008 há toda uma nova geração de programadores que “acordou” para as capacidades do SQL espacial.

Quando uma aplicação SIG com peso no mercado conseguir fazer uma análise 10x mais rapidamente que os seus concorrentes (porque recorre às capacidades do servidor de base de dados) o que acham que vai acontecer?

Opções para utilizadores ESRI

Então que opções existem para os utilizadores ESRI que querem utilizar PostgreSQL+PostGIS?

ArcSDE

A opção standard do ponto de vista da ESRI é, claro, instalar o ArcSDE. Na versão 9.3 existe um setup de instalação que até instala o PostgreSQL e o PostGIS de uma forma muito automatizada. Pode-se encontrar alguns tutoriais de instalação, como este do Adriano Hantequeste: ArcSDE [Passo 1] Instalando o PostgreSQL. Há que ter atenção, no entanto, aos passos opcionais de instalar o PostGIS manualmente, para podermos no fim optar pelas suas capacidades nativas. (No manual de instalação do ArcSDE está tudo bem explicado.)

Mas há mais para além da instalação do ArcSDE. Podemos configurar a forma como o ArcSDE armazena os dados vectoriais no PostGIS. Existem 2 opções:

  • formato proprietário ESRI (ST_GEOMETRY)
  • formato nativo PostGIS (PG_GEOMETRY)

Estas opções definem o formato como as geometrias dos nossos vectores são armazenados na bd. Para o utilizador de ArcGIS é invisível se optamos por uma ou outra, mas há consequências importantes.

O formato ESRI guarda as geometrias no PostgreSQL de forma a que apenas se podem ler ou alterar usando software compatível (leia-se ESRI). Ou seja, o Quantum GIS para ler estes dados terá de usar um plugin ArcSDE (para ser exacto, o plugin é instalado no OGR que por sua vez é usado através do QGIS).

Por sua vez, o formato PostGIS guarda as geometrias usando as capacidades do PostGIS, e isso significa que todo o software compatível com PostGIS as pode ler e alterar. Ou seja, podemos carregar dados na bd usando o ArcCatalog (que passa pelo ArcSDE), e depois usar o QGIS para ler esses dados, sem passar pelo ArcSDE e sem plugins. Confuso? Espero que não… em última análise, esta opção permite ter na empresa aplicações gratuitas como o QGIS a usufruirem da bd central, a fazer impressões, análises, confrontações, etc. sem duplicação de dados ou conversões desconfortáveis.

Como se configura esta opção do formato de armazenamento das geometrias?

Sem querer entrar em grandes detalhes, pode-se dizer que é muito simples. Basta executar um comando que altera uma linha na tabela de configuração do ArcSDE. O comando é o seguinte:

sdedbtune -o alter -i 5151 -k DEFAULTS -P GEOMETRY_STORAGE -v “PG_GEOMETRY” -s <server_name> -D postgis -u sde -p <ArcSDE_admin_password>

Esta opção tem outras configurações e particularidades que terão de ficar para outra oportunidade.

zigGis

zigGIS é uma extensão para ArcGIS que permite ler e escrever em PostGIS, sem usar ArcSDE. É um produto que começou como Open Source, e que evoluiu para uma solução comercial. Embora a fonte do programa esteja disponível, é exigida a compra de licenças na maioria das situações (excepto para uso pessoal e académico que continuam isentos de pagamento – ver licença aqui).

Ora o preço é de apenas US $279! por posto de trabalho. É naturalmente muito apetecível. O cenário em vista é conseguir um SIG, com base de dados geográficos e aplicação desktop de topo, apenas pelo preço de ArcView + $279.  Será que há algum truque, uma armadilha? Parece que não, a ver pelo excelente exemplo da implementação na Câmara Municipal de Albufeira, é uma opção extremamente flexível.

O papel do ArcSDE

Claro que surge a questão óbvia: então para que serve o ArcSDE? Bom, esta questão é debatida há muitos anos, bem antes de existir o zigGIS, e posso apenas manifestar a minha opinião – o ArcSDE é o pivot de dados que serve toda a plataforma ArcGIS – desde o modelo de dados, ao servidor webGIS, às aplicações desktop. Sem o ArcSDE, as várias peças do ArcGIS “descolam”, e temos de recorrer a ficheiros para partilhar informação entre as componentes do sistema. Por outro lado, o ArcSDE permite à ESRI implementar funções para além dos standards. Em geral, os standards na área SIG e SQL são desenvolvidos mais lentamente que as aplicações desenvolvidas pelos maiores fabricantes. Por exemplo, antes de existir WMS já existiam servidores webGIS. Antes de existir standard de SQL espacial, já existiam bases de dados geográficos. Com o ArcSDE a ESRI implementa um modelo de dados com funcionalidade que não está padronizada pela indústria: rasters, terrains (para LIDAR), topologia com regras de validação automática, gestão de versões, gestão de histórico, bd’s distribuídas, sincronização de bd’s… bom, não é o meu papel “defender” o ArcSDE, mas encontro valor acrescentado no produto. Para os casos que não necessitam desta integração ou destas funções, fará menos sentido a sua aquisição. Para os outros casos…

Conclusão

Já vai longo este artigo… contra todas as regras de bom comportamento em blogs 🙂

Nos próximos tempos penso continuar este tema com mais alguns artigos, olhando com mais detalhe para a combinação PostgreSQL+PostGIS<->ArcSDE<->ArcGIS.

Para já, é certo que podemos contar com a possibilidade de criar sistemas híbridos com software ESRI e componentes Open Source, usando o melhor dos 2 mundos. E isso é um passo de gigante  que demorou décadas a chegar ao ArcGIS, mas finalmente aí está.