Para quem não sabe, a MetaCarta é uma empresa privada nos EUA, que se especializou em software para a localização geográfica de conteúdos, dirigido especialmente ao mercado de agências noticiosas/jornais. Mas é também a empresa onde se originaram alguns produtos notáveis Open Source na área SIG, sendo o mais difundido o OpenLayers, inicialmente desenvolvido por Christopher Schmidt, para além do FeatureServer, do TileCache, e ainda o WPServer (servidor WPS da OGC). Christopher é/tem sido extremamente activo no suporte às comunidades em redor destes produtos, e foi nomeado “membro gestor” (board member) da OSGeo, a fundação internacional para o desenvolvimento colaborativo de software Open Source na área SIG.

Para além das reflexões sobre os objectivos na base desta decisão, parece-me que poderá haver implicações nos produtos desenvolvidos pelo Christopher Schmidt. Teremos de aguardar para ver o que sucederá. Mas, para já a reacção do Christopher parece entusiástica – MetaCarta Acquired by Nokia. Na verdade, sendo Open Source, a liberdade dos produtos não está em causa. O que falta saber é se o Christopher continuará a poder oferecer-nos o seu entusiasmo fantástico. Esperemos que sim!

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

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

Bases de Dados e Utilizadores

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

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

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

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

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

Utilizadores e Schemas

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

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

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

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

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

Criar Utilizadores

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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.

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:

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!

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.

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…

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

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

• o recente “An Overview on Current Free and Open Source Desktop GIS Developments” publicado no International Journal  of GIS em Setembro de 2008.
• a apresentação feita nas II Jornadas de SIG Libre, Girona, em 2008 “Un modelo para evaluar el futuro de Proyectos Open Source“.
• o levantamento feito pelo Paul Ramsey em 2007 “Survey of Open Source Projects“.

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???

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.

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

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:

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

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:

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:

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:

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:

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…