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.
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 😉
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…