Arquivo da Categoria: Gestão

Balanço Open Source para SIG

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Google Maps lidera?

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

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

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

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

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

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

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

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

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

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

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

Medindo o Desempenho de Servidores SIG

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

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

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

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

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

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

Configurações dos servidores em comparação

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

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

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

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

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

Software de Testes – JMeter

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

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

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

Gravando um teste

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

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

JMeter_testeinicialopt

Alterar o teste de desempenho

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

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

O teste resultante ficou com o seguinte aspecto:

JMeter_testefinal_opt

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

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

Testando

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

Resultados e análise com 1 utilizador

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

Aggregate Report_1ediasigims_opt

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

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

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

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

Aggregate Report_1ediabeja019_opt

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

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

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

Resultados e análise com 10 utilizadores

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

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

Aggregate Report_1ediasigimsx10_opt

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

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

Aggregate Report_1ediabeja019x10_opt

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

Conclusão

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

 

Mapas/min

KB/s

Mapas/min

KB/s

Xeon P4 3,2GHz

21,3

5,1

51,7

12,4

Xeon Quad 2GHz

39,9

10,2

132

33,7

melhoria %

87%

100%

155%

172%
 

1 utilizador

10 utilizadores

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

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

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

Desenvolver aplicações SIG de forma Agile!

Avançado, Gestão, SIG,
Tempo de leitura: 4 min

Estou a digerir tudo o que vi na formação de 3 dias sobre metodologias Agile e Scrum e este post servirá como bloco de notas.

Esta semana estive 3 dias em formação com o excelente formador Mitch Lacey. Este sr. tem já uma grande experiência em projectos de desenvolvimento de software, e ouvi-lo foi realmente uma experiência enriquecedora.

Não vou entrar em grandes detalhes teóricos sobre Agile/Scrum, porque não sou definitavemente a pessoa indicada para o fazer. Vou em vez disso enumerar os pontos que mais me impressionaram e que mais valor terão se os integrar na forma como a “minha” equipa funciona. Portanto, as afirmações seguintes devem ser encaradas como uma perspectiva muito pessoal…

Agile é um conjunto de práticas que visam desenvolver um projecto de forma iteractiva, com ciclos curtos entre versões intermédias antes de chegar à entrega final, com vista a reduzir os riscos associados a este tipo de projectos – sendo o maior entregar um produto que não se ajusta à visão do cliente!

Scrum é a metodologia Agile mais difundida, e obteve o seu nome do Rugby: scrum é a altura em que os jogadores se reunem para reiniciar o jogo, e ambas as equipas disputam a bola. Em Agile, Scrum é um método em que uma equipa de desenvolvimento se concentra ferozmente em terminar um conjunto de tarefas num prazo curto – tipicamente 14 ou 28 dias – e se compromete a no final do prazo produzir uma versão funcional do produto que está a desenvolver.

Qual é a grande diferença em relação ao processo tradicional (designado “Waterfall” ou “em Cascata“)? É que no processo Waterfall, os requisitos para a aplicação a desenvolver são definidos à partida, na fase de levantamento e definição dos mesmos. Em seguida, esta lista de especificações é trabalhada com o cliente final, e atinge-se um acordo, sendo fechada a lista de itens a implementar. E é aqui que este método tem a sua maior fraqueza: é pouco flexível, e não considera facilmente requisitos que se alteram com o tempo (alguém se identifica com esta experiência??). A analogia de construir uma casa é muito clarificadora: ao olhar para a planta da minha futura casa, posso ficar muito satisfeito com o que está planeado. Mas, mais tarde, ao andar pela estrutura já construída da casa, vou conseguir obter uma visão mais clara do que estava na planta, e consequentemente vou definir melhoramentos e até novas funções que quero ter na versão final da casa. Isto é um processo natural e não deve ser combatido. E é o que os métodos Agile nos oferecem: ao cliente final permite algum controlo durante a vida do projecto, e à equipa de desenvolvimento permite um grande poder de adaptação à mudança, permitindo concluir o projecto dentro do prazo e do orçamento, mesmo absorvendo alterações aos pressupostos iniciais. E para descansar os espíritos mais desconfiados, resta acrescentar que esta metodologia é reconhecida pelo PMI, e é usada pelas maiores empresas de software como Microsoft ou IBM.

Porque é que estas técnicas me interessaram? Os pontos mais importantes:

  • A equipa de desenvolvimento com que trabalho é pequena – podemos contar com 2,5 técnicos (sim, temos realmente uma metade de técnico!), e somos facilmente dispersados por várias solicitações em simultâneo
  • O meio onde nos inserimos é muito dinâmico – as alterações aos requisitos são muito frequentes, e a sua definição inicial é muito difícil de obter e estabilizar
  • Trabalhamos para o “Cliente Interno”, onde as relações informais dominam, e os processos formais inerentes ao método Waterfall dificilmente são aplicados e respeitados

Da abordagem Scrum, estes são os pontos que mais me agradam e que vejo possibilidade de implementar rapidamente:

  1. Definir o “Product Backlog”, que mais não é que uma lista de funções a implementar numa aplicação, ordenada por prioridade
  2. Definir o “Sprint Backlog”, que é a lista prioritizada de funções que vamos implementar no próximo ciclo de 14 dias (o sprint)
  3. Reuniões relâmpago diárias, onde rapidamente (15 min.) cada um dos elementos da equipa percorre estes 3 pontos – o que concretizaste ontem, o que vais fazer hoje, e tens algum ponto crítico?
  4. Estar atento a solicitações de alterações ou novas funções, mas lutar por integrá-las no Product Backlog, que poderá ser re-prioritizado todas as semanas (mas as funções só podem entrar num sprint no seu início)
  5. Consciencializar todos os elementos da equipa de que todos são responsáveis pela equipa! Todos se devem preocupar com a saúde emocional da equipa e com a concretização dos compromissos assumidos com o exterior (notem aqui a grande diferença mental entre cumprir objectivos e cumprir compromissos)
  6. Obter uma versão funcional no final de cada Sprint! E demonstrá-la. Na teoria Scrum, a demo deve ser feita ao cliente. No meu caso, parece-me mais plausível realizar uma demo interna à equipa, para validar a direcção dada ao projecto, detectar incongruências, enfim, andar pela estrutura da casa e ver se é como imaginámos quando fizemos a planta…

É realmente uma forma de trabalhar muito aliciante, e que de alguma forma torna o desenvolvimento de projectos mais humano.

Algumas ferramentas consideradas essenciais a uma boa prática Agile já utilizamos na equipa:

  • Repositório de código e Controle de versões – usamos o SVN, e o AnkhSVN para integrar com o Visual Studio. Não há checkin de código que não compile. Este é um passo fundamental na organização da equipa!
  • Documentação – embora não tenhamos ainda a prática de documentação automática do código, embora já se tenha discutido o assunto várias vezes, usamos um Wiki para documentar quer a vertente técnica quer a vertente de utilização das aplicações

E das peças que nos faltam, o que podemos integrar no nosso caso particular?

  • Teste unitários – é algo que deveremos implementar, mas que está ainda algo longíquo de ser possível… é necessário primeiro re-organizar o código em componentes suficientemente pequenos, modulares, para possibilitar esta técnica. Mas os ganhos são óbvios – rapidez de efectuar testes e na detecção de bugs
  • Test Driven Development – ver ponto anterior, é algo desejável, mas cuja execução obriga a remodelar o repositório de código existente. Talvez a longo prazo seja possível…

Para mais informação recomendo vivamente a leitura deste artigo: “Agile Project Management for GIS“. Muitos mais podem ser encontrados “googlando” a Internet (como por exemplo este na revista PM Network, pp 42). E para aqueles que ficarem convencidos, fica a referência do curso – Fullsix.

Crise chega aos SIG v2

Gestão
Tempo de leitura: < 1 min

Os municípios nos EUA (na realidade os “Mayors”) compilaram uma lista de investimentos preparados para avançar caso sejam financiados pelo governo federal, com o objectivo de estimular a “Economia Real”.

Matt Ball, do blog Spatial Sustain analisou a lista e concluiu que existem projectos SIG no valor total de 31 milhões de dólares. O total de investimentos ronda os 47 biliões de dólares. A grande maioria dos projectos SIG são na área de Estradas e Segurança/Protecção Civil.

A minha reacção inicial foi de contentamento ao ver que a área geo-espacial recebeu uma atenção merecida! Mas ao reflectir melhor, se as contas apresentadas estiverem correctas, a fatia de investimento em SIG representa 0,066% do total! Ouch…

Mesmo assim, a lista de projectos SIG que o Matt mostra no seu artigo ilustra exemplos de aplicações SIG bem aliciantes: sistemas SIG para estradas (400.000$), localização de infra-estruturas construídas (750.000$), construção de um SIG regional (450.000$), sistema SIG de águas e saneamento (2.700.000$)…

Visto assim, com valores individuais, já começa a impressionar: apenas um destes projectos, mesmo o mais pequeno, financiava por alguns anos qualquer das nossas empresas nacionais.

Crise chega aos SIG?

Gestão,
Tempo de leitura: < 1 min

Aparentemente, a crise económica mundial está a ter os seus efeitos nas empresas de software SIG e CAD…

Hoje a Autodesk anunciou o despedimento de 10% da sua força laboral a nível mundial, reduzindo 750 postos de trabalho, e em simultâneo irá re-estruturar a orgânica da empresa.

Por seu lado, ontém a Intergraph também anunciou despedimentos e respectiva re-estruturação… irá despedir 5% da sua força laboral, cerca de 200 postos de trabalho.

A Google, que tem vindo a eliminar vários produtos do seu vasto portfolio, cortou agora o Dodgeball, um site que liga redes sociais à localização, através dos telemóveis (apenas nos EUA). E também anunciou que irá eliminar 100 postos de trabalho… na área de recrutamento (curioso). É uma sequência lógica ao anúncio anterior de abrandamento no recrutamento.

A ESRI (EUA) não anunciou intenções de despedir colaboradores. Mas tem surgido nas notícias de forma mais original: ao promover uma iniciativa para combater a crise nos EUA por meio da criação de um SIG Nacional, que custaria  1,2 biliões de dólares aos contribuintes norte americanos. Há um pdf a circular com a assinatura de Jack Dagermond, presidente e proprietário da ESRI, e de Anne Hale Miglarese e Booz Allen Hamilton, cuja afiliação desconheço.

Esta iniciativa, claro está, tem provocado uma polémica agradável na geo-esfera. Embora a ideia de um SIG nacional me pareça sensata em termos gerais, tenho de concordar que os números são pouco realistas: um cadastro para os EUA por 200 milhões?? O “nosso” pequenino SiNErGIC tem um custo anunciado de 450 350 milhões de Euros. Alguém fez mal as contas…

Falta agora sabermos o que se passa em Portugal. Quais os resultados para 2008 que as empresas portuguesas irão apresentar? Notar-se-ão já as dificuldades, ou ficará para as contas de 2009?

Virtual Earth e SIG nos Municípios

Gestão,
Tempo de leitura: 5 min

No passado dia 4 (portanto este post já vem atrasado) assisti ao Microsoft Solutions Day dedicado ao Virtual Earth, e saí com a sensação de que realmente há algo muito forte em movimento na área de webgis. Uma das principais novidades que ouvi foi o anúncio da revisão ao protocolo entre o Estado Português e a Microsoft, que passou agora a incluir também as Câmaras Municipais no acordo, permitindo-lhes a utilização gratuita do Virtual Earth (exceptuando-se aplicações para fins comerciais: ie venda de algo). Em simultâneo, foi renovada a cobertura da imagem aérea, sendo agora baseada nos ortofotomapas de 2007 e com resolução de 50cm por pixel! Portugal fica assim com uma das melhores coberturas do mundo no VE!

O VE é como se sabe, muito resumidamente, um visualizador da informação geográfica da Microsoft (cartografia base e ortofotomapas) onde por meio de programação podemos sobrepôr a nossa própria informação no mapa. Não me vou alongar aqui na descrição técnica do VE e das suas capacidades, talvez noutro artigo… E outras empresas têm produtos semelhantes, sendo o mais notável o Google Earth e Maps (havendo outros).

Qual é a novidade?

A verdade é que já há muito tempo que os produtores tradicionais de software SIG comercializam produtos deste tipo para publicar e explorar informação geográfica usando um browser via Internet.

Então, qual é a novidade? Que impacto é que podem ter a Microsoft e a Google quando lançam também os seus visualizadores?

É que há 1 factor determinante e que faz uma diferença fracturante em relação ao que tinhamos antes, havendo depois uma miríade de outros factores que ajudam a criar um impacto cada vez maior: informação…

Informação de base e ortos para todo o mundo

Esta é a questão central – já não será necessário adquirir informação geográfica de base! (obviamente que nem sempre será verdade)

Imaginemos uma câmara municipal que decide implementar o seu SIG e começa a colocar as questões habituais:

– que hardware, que software, que técnicos, que informação, que procedimentos?

E qual é a questão mais cara? Isso mesmo – os dados.

Lançar concurso para aquisição de cartografia vectorial e de ortofotomapas para todo o concelho pode custar de dezenas a centenas de milhares de euros, é moroso, complexo, e arriscado. Frequentemente não se consegue obter um produto de qualidade. E depois? Depois continuam as dificuldades: onde armazenar essa informação, como manipulá-la correctamente, como torná-la útil? Quem sabe fazê-lo?

Agora, eliminem-se todas essas questões de uma só pernada: Ao usar uma aplicação baseada em VE, a câmara recebe uma aplicação web que além de ter um aspecto gráfico profissional ainda mostra uma cartografia extraordinária, com nomes de rua actualizados e ortofotomapas de alta resolução. E para terminar o preço é 0! Isso mesmo, zero, nada, zilch!

Hmmm… decisão difícil …

(Atenção que para quem não está incluído no protocolo referido podem existir custos de licenciamento. Há que investigar se somos ou não abrangidos pela licença gratuita do produto que escolhermos.)

Mas não existem grandes limitações e problemas?

É verdade que existem problemas a resolver. Esta abordagem não é uma panaceia para todas as situações. É antes uma nova abordagem a integrar com as já existentes. Há que saber conviver com ela da melhor forma. Por exemplo, é necessário fazer a ligação entre o visualizador e a nossa própria informação. E isso só se faz recorrendo a programação. Simples ou complicada, é sempre necessária. As funções que necessitamos incluir no visualizador e que não venham incluídas de raíz, têm também de ser desenvolvidas à medida. Outro facto incontornável.

Também a impressão é mais difícil. Existem limitações técnicas que é preciso saber rodear, e aprender a aceitar compromissos: se não é possível imprimir tal como se gostaria, então até onde é possível chegar? E isso será suficiente para o meu caso? Eu diria que 90% frequentemente as necessidades de impressão podem ser satisfeitas utilizando visualizadores como o VE. E mais, em aplicações webgis a tarefa de impressão é geralmente muito simplificada.

E se a Microsoft decidir acabar com o VE? Ou começar a cobrar fortunas? Esta é uma questão que não me parece especialmente pertinente. Enquanto nos preocupamos com uma possibilidade mais ou menos remota, desperdiçamos uma boa oportunidade. Se e quando esta situação ocorrer, já teremos usufruido deste sistema durante os anos em que a plataforma esteve activa. Por outro lado, é discutível que todo o software incorre em riscos semelhantes…

Como interligar com a nossa informação?

O que torna um visualizador especialmente útil para cada organização será a sua capacidade de integração com a “nossa” informação geográfica. Existem 2 formas de colocarmos a nossa informação no VE: como imagens ou como vectores.

Para publicar a nossa informação como imagens, é necessário criar uma aplicação que é responsável por ler os nossos dados e criar imagens de mapas com a simbologia que desejamos, sempre de acordo com as regras do VE. Estas imagens são depois sobrepostas à informação do VE usando transparências. Uma pesquisa no Google revela milhares de resultados com exemplos de código para todos os gostos.

Para publicar a informação como vectores, é também necessário criar uma aplicação, mas que converte a nossa informação para um formato aceite pelo VE. Actualmente são aceites os formatos KML, GPX, e o formato próprio do VE.

Aqui também existem problemas para os quais é preciso ajustar a nossa perspectiva… Estes visualizadores usam as capacidades do browser para literalmente desenhar vértice-a-vértice a nossa informação vectorial. E os browsers não oferecem grande performance neste aspecto. Se quisermos representar algumas dezenas de pontos não há problema. Mas se quisermos visualizar o PDM? Ou o cadastro? Ou a rede de águas? Consoante aumenta o número de vértices a desenhar também o desempenho do browser diminui, até ficar inoperante. Podemos optar pela publicação por imagens, mas isso implica perder a interactividade que os vectores oferecem – e.g. colocar o rato sobre um polígono e obter informação adicional. Como sempre, existem soluções também para esta situação (aglomeração, tiles de vectores, generalização, clipping, escalonamento por escalas), e temos que saber explorá-las de forma a obtermos um resultado satisfatório.

Qual o papel do software SIG tradicional?

Uma das discussões que têm surgido frequentemente é sobre o papel das empresas que actuam no mercado de software SIG – ESRI, Intergraph, Autodesk…

Não penso que terão o futuro ameaçado, antes pelo contrário. Acredito que o Virtual Earth e restantes visualizadores vieram abrir novas oportunidades a estas empresas, embora tenham também provocado um enorme aumento de concorrência por parte do sector informático genérico (não SIG).

Isto é, se uma organização pretender implementar uma solução VE, irá procurar quem ofereça esse serviço. E poderá optar não só por uma empresa SIG, mas também por qualquer parceiro Microsoft especializado em Virtual Earth. Confesso que neste aspecto sou tendencioso: acredito que uma empresa SIG oferece vantagens acrescidas, pela experiência e conhecimentos alargados na área – tem contexto!

Ao nível do software também as empresas SIG não ficaram paradas. Uma após outra incluíram nos seus produtos capacidades de integração com as plataformas geográficas dos gigantes Google e Microsoft. Todos lêem o formato KML, que hoje é praticamente o formato universal aceite por todas as plataformas, e alguns conseguem até converter para este formato. Faltará ainda uma boa capacidade de criação e edição de KML… mas lá chegarão.

E recentemente os produtos de servidor começaram a oferecer capacidades de integração com o VE e Google Maps/Earth. Ou seja, em vez de programar aplicações de integração, hoje apenas temos que configurar a forma como queremos publicar a nossa informação para estes visualizadores. E tudo dinamicamente: Se editarmos a nossa informação, ela aparecerá editada no VE. Um exemplo: praticamente todos estes produtos publicam KML directamente a partir dos nossos dados: ArcGIS Server da ESRI, MapGuide da Autodesk, e os principais produtos Open Source – MapServer (por enquanto via plugin), GeoServer, e MapGuide Open Source.

A tendência é assim de alargar a caixa de ferramentas que os técnicos SIG utilizam – o VE e semelhantes são mais uma ferramenta que devemos integrar na nossa actividade profissional.

Conclusão

Assistimos actualmente à trivialização da publicação de informação geográfica para as plataformas de serviços geográficos. E esta capacidade é já um factor diferenciador dos produtos. Quem oferece mais integração, e maior facilidade, tem o melhor produto. Quanto mais estas capacidades aumentam, menor é a necessidade de programar esta interligação tornando-a cada vez mais acessível.

Claro que um departamento SIG que produz cartografia temática de alguma especificidade, executa análises geográficas, e edita informação frequentemente, não pode ser substituído por uma aplicação deste tipo… Um departamento com conhecimento técnico especializado, experiência profissional, e capacidade de execução, não pode ser comparado com uma aplicação webgis.

Nos locais em que não existe uma equipa especializada, e com poucos recursos, a utilização do VE ou GE/GMaps é uma solução rápida e barata para implementar soluções SIG na web. E onde já existe esta equipa, ainda melhor – poderá potenciar a sua utilização em diversas soluções focadas em questões específicas.

Mãos à obra!