2 thoughts on “ArcSDE e PostGIS – caracteres pt”

1. Boa noite,

   Antes demais muitos parabéns para o site que tem conteúdos bastantes úteis.

   Gostaria de receber o feedback se a mudança para PostGIS da plataforma ESRI é relativamente fácil, na passagem dos dados de anterior plataforma (não sei se seria SQL Server, Oracle).

   Qual a vossa opinião face a se usar como base o PostGIS? em relação a query é igual ao SQL?

   Obrigado

2. Pedro, a mudança para pgsql tem sido uma experiência esquizofrénica… 😉

   Pelo lado do pgsql tudo corre 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 acumular-se…

   Começou com surpresas como o facto de não ser possível apagar 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 tabelas espaciais…??? Isto passou, e agora já podemos apagar fc’s com geometria postgis no arcgis. Mas, na v10.1 apareceu um novo bug: quando apagamos uma fc destas 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. A solução actual é voltar a usar conexões de serviço (3 tier) em vez de conexões directas, se quisermos gerir a geodatabase com fc’s com geometria postgis. Para apenas leitura parece ser seguro usar conexões directas…

   Depois existe a questão do desempenho. Usar o tipo de geometria postgis é “apenas” 3,5x mais lento no arcmap do que usar a geometria da esri… pelo menos em algumas das nossas fc’s. O QGIS é bastante mais rápido do que o arcmap nesta situação. Já se usarmos geometria esri o arcmap é mais rápido que o qgis. Bizarro… A 1ª reacção da esri foi dizer que era uma limitação do postgis… até que lhes enviei o log do pgsql a provar o contrário. O problema está na query que o arcmap emite – o qgis usa um sql bem melhor.

   E finalmente, a cereja no topo do bolo, o último erro que encontrámos, e que está em análise na esri há 2 semanas, é um polígono que simplesmente é impossível de importar para a geodatabase em formato postgis… a conexão à geodatabase simplesmente “crasha”, com um erro enigmático de “I/O Network error”. Um polígono que é importado perfeitamente se usarmos a geometria da esri…

   Portanto, qual é o saldo? Continuamos a pensar que vale a pena pelo valor que o postgis representa. Neste momento decidimos manter 2 cópias das fc’s: uma com geometria esri para melhor desempenho no arcgis, e outra cópia com geometria pg para usar com software não-esri. Mas queremos simplificar e ficar com apenas 1 cópia, mesmo sacrificando o desempenho no arcmap…

   E finalmente, quanto ao sql. Tudo é muito parecido com Oracle. Temos um script baseado nos exemplos da esri que altera as definition queries e as queries sql das classes de labels, e ainda as 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 que existam. De resto, não notamos grandes diferenças no sql.

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

   Abraço.
   Duarte