Archive for the 'Avançado' Category

PostgreSQL e ESRI – parte 4

Publicado em 13 de Dezembro de 2012 em Avançado, Open Source and PostgreSQL. 2 Comments Tags: , , , .

O subtítulo deste artigo devia ser “O bom, o mau e o péssimo”…

Depois de ter respondido a um comentário que me perguntava sobre a nossa experiência em cruso de migrar para PostgreSQL, pensei em melhorar a resposta e fazer um artigo – a maior parte da escrita já estava feita de qualquer forma ;)

Responder ao comentário levou-me a pensar mais um pouco sobre a questão… e uma parte que me parecia pouco clara é o porquê de fazermos a migração para PostgreSQL (pgsql prós amigos) e porquê insistir em usar geometrias PostGIS (geometrias pg)? Só para recordar: a ESRI permite 2 formatos de armazenamento das geometrias nas bases de dados que suporta – ou no formato ESRI (que chamou de ST_Geometry) ou no formato “nativo” da bd.

Mas porque insistem!!??

Esta é uma questão velha. Já há muitos anos que a Oracle suporta geometrias, e a ESRI também já há anos que suporta em bd’s Oracle este esquema de 2 possibilidades. A vantagem maior em usar geometrias em formatos “nativos” das bases de dados é o acesso  a um portefólio de software compatível com esses formatos, dentro e para além da esfera SIG. Por exemplo, podemos desenvolver aplicações Oracle que são 99% formulários, mas que mostram de vez em quando uns mapas, sem software adicional. Há software de BI que também faz a representação em mapas dos dados que analisa. E por aí fora. Claro que na esfera SIG é onde está a verdadeira acção. E usar o formato ESRI limita-nos a usar ArcGIS, no desktop e no servidor. Mesmo com a enorme evolução que a ESRI conseguiu no acesso e interoperabilidade via SQL, a verdade é que, para ver, editar e analisar os dados geográficos, se estes estão no formato ESRI então esqueçam outras opções…

Por tudo isto, genericamente, optar pelo formato geográfico nativo da nossa bd é uma opção lógica.

O problema está nos detalhes… por exemplo, quando em 2004 pensei em usar o formato Oracle Spatial, vi com alguma surpresa uma perda de desempenho em cerca de 30% no ArcMap. Depois havia uma série de operações manuais a fazer para manter a compatibilidade entre ESRI-Oracle. E, assim, lá abandonei a ideia.

Anos mais tarde, voltamos ao mesmo. Há a necessidade de mudar de bd. O que escolher?

Por um lado, a ESRI tem um formato próprio com um excelente suporte SQL que segue de perto os standards OGC e ISO. Por outro, o PostgreSQL e PostGIS são uma aposta mais que validada por todo o mundo, e têm o maior portefólio de software SIG compatível. Ponto parágrafo. A escolha fica óbvia. Se vamos mudar, mudamos para o melhor que há! (e ainda por cima é grátis!)

Migrando, round 1

No último ano temos feito um esforço continuado em passar tudo o que temos em Oracle para PostgreSQL e PostGIS. Isto implica dados (geográficos e outros), mas também views, funções PL/SQL (dialecto Oracle), projectos e lyr’s ArcMap, e finalmente, aplicações web. A coisa não é fácil. Migrar de bd é uma maratona…

Pelo lado do pgsql tudo tem corrido bem. Os técnicos que têm experimentado o lado desktop com qgis têm mostrado entusiasmo e estão muito satisfeitos em aprender uma tecnologia nova que funciona… os programadores estão impressionados com a facilidade com que tudo é migrado de Oracle, desde views e funções sql, a aplicações .net, à consola de gestão, e à gestão do próprio servidor.

Pelo lado do ArcGIS, quando tentamos usar geometrias nativas do postgis e não a geometria da esri, os problemas têm vindo a amontoar-se…

Começou com surpresas como o facto de não ser possível apagar renomear feature classes. No help do arcgis dizia que a razão era o facto de a bd não fornecer uma função para apagar renomear tabelas espaciais…??? Ora vejam lá esta pérola:

image

… então isto quer dizer que programar o ArcCatalog para importar, converter, reprojectar, não teve dificuldade. Agora, renomear tabelas e executar um comando adicional SQL para remover um registo da tabela geometry_columns, isso já é demasiado complexo… enfim, é uma “feature” e não um bug. Vamos lá tomar chá calmante e continuar.

…round 2

Depois existe a questão do desempenho. Era espectável alguma perda de desempenho, tudo certo. Mas usar o tipo de geometria postgis é “apenas” 4,75x mais lento no arcmap do que usar a geometria da esri… pelo menos em algumas das nossas fc’s. Imaginem: ligamos um layer no mapa e em vez de 8 segundos, esperamos 38 segundos. Por 1 layer.

Levámos a experiência mais longe. Montámos um mapa típico do nosso dia-a-dia, usando feature classes nos 2 formatos. E medimos o desempenho…

agspreview_tipo_st agspreview_tipo_pg
Geometria ESRI – 4,93 seg Geometria pg – 10 seg

… “portanto, 3 mil milhões de contos, 3 vezes 18, portanto…”

… mas isto é 2x mais lento!!

Bom, fomos experimentar com o QGIS, não fosse a razão estar num problema da bd. E verificámos que o QGIS é muito mais rápido do que o arcmap nesta situação (já vamos ver). Mas o arcmap é ainda mais rápido se usarmos geometria esri. Bizarro… (Há aqui alguma coisa que a esri está a fazer bem com a sua arquitectura e que valia a pena analisar. Talvez compressão das geometrias?)

Como o problema era então do arcmap contactámos o suporte. A 1ª reacção da esri foi informar-nos que era uma limitação do postgis… mais um chazinho para os nervos.

Até que lhes enviei o log do pgsql. O problema está na query que o arcmap emite – o qgis usa um sql mais eficiente. Toda a diferença nos tempos medidos encontra-se na query. O “rendering” na aplicação desktop nem entra na equação. Lá fomos informados que era esperada uma quebra de desempenho, mas que dadas as diferenças entre os 2 formatos iriam registar um “enhancement request”. Óptimo. Para o futuro.

Só para terminar este round, montámos um projecto igual em QGIS – os mesmos layers, as mesmas queries, as mesmas labels, os mesmos símbolos, etc. Usámos uma área de mapa igual, e a mesma escala. Usámos um pequeno comando na consola de Python para medir exactamente o tempo de desenho que estávamos a ver. Deixo aqui apenas a imagem… conseguem descobrir quantos segundos levou o QGIS a gerar o mesmo mapa? Com estes números, nem arrisco contas de cabeça ;)

qgis_preview_timer

Pois é… a vida não está fácil…

… round 3

Os bugs…

Aguardámos com alguma esperança a versão 10.1 SP1 do ArcGIS. Além das novas funções, poderiam existir optimizações que nos fossem úteis.

Mas o que apareceu foi um novo bug: quando apagamos uma feature class com geometria pg, a conexão à geodatabase nunca mais pode ser aberta – dá erro…

Temos de resolver a questão limpando manualmente as tabelas de sistema do sde… Como este bug passou o cq da esri ultrapassa-me. Mas já marcaram como bug e há um “workaround”. A solução é voltar a usar conexões de serviço (3 tier) em vez de conexões directas, para gerir geodatabases que tenham fc’s com geometria postgis. Para apenas leitura das mesmas parece ser seguro usar conexões directas…

E finalmente, a cereja no topo do bolo, o último bug que encontrámos, e que está em análise na esri há 3 semanas, é um polígono que simplesmente é impossível de importar para a geodatabase em formato postgis… a conexão à geodatabase simplesmente desiste, emitindo um último suspiro enigmático de “I/O Network error”.

Este polígono que é importado perfeitamente se usarmos a geometria da esri… e claro, importada também sem problemas para o PostGIS com outras ferramentas…

Aqui, continuamos sem solução. Editámos o polígono manualmente, e fomos tentando importar até o erro desaparecer. Mas, por agora, não sabemos se outras geometrias “tóxicas” irão surgir, já que ainda não existe uma explicação para o fenómeno.

Conclusão (por agora)

Portanto, qual é o saldo? Continuamos a pensar que vale a pena insistir na migração para o formato pg pelo valor que o postgis representa. Abre os nossos dados a um universo de opções, dentro e fora da esfera SIG.

Neste momento decidimos manter 2 cópias dos dados: uma com geometria esri para melhor desempenho no arcgis, e outra cópia com geometria pg para usar com software não-esri.

Isto obriga-nos a um esforço adicional para manter as cópias sincronizadas, que dispensaríamos de bom grado. Para já, usamos scripts python de ArcGIS para o efeito. Afinal, a melhor ferramenta para converter dados em formato esri ainda é o arcgis.

Mas queremos simplificar e ficar com apenas 1 cópia, mesmo sacrificando algum desempenho no arcmap… teremos de esperar até que esta diferença seja aceitável para nós.

Nota final

Há algumas diferenças relativas ao sql que são importantes na recriação de projectos ArcMap e de ficheiros lyr. Mas é tudo muito parecido com Oracle. Temos um script python baseado nos exemplos da esri, que altera as definition queries e as queries sql das classes de labels, e ainda as próprias expressões das labels. Retiramos todas as aspas dos nomes dos campos, e os [], que existam. Como a nossa geodatabase Oracle ainda usava geometria armazenada em binário, tinha ainda campos SHAPE.AREA e SHAPE.LENGTH. Estes campos já não existem e têm de ser substituídos em todas as queries. De resto, não notamos grandes diferenças no sql.

E é isto… as coisas só podem melhorar, certo? ;)

Desenvolver aplicações SIG de forma Agile!

Publicado em 31 de Janeiro de 2009 em Avançado, Gestão and SIG. 0 Comments Tags: , .

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.