Apenas uma nota rápida sobre a utilização de ArcSDE e PostGIS…
Finalmente, estamos a iniciar a transição para PostGIS na nossa plataforma ESRI. Ao copiar um conjunto de tabelas espaciais (com Copy/Paste no ArcCatalog), aparecia uma mensagem de erro de que algo grave se passaria:
(duplicate key violates unique constraint “colregistry_pk”)
Afinal, o problema é provocado por campos que têm nomes com caracteres portugueses (que é aliás uma proibição que temos há muito tempo na casa).
Mais o susto que outra coisa… e a mensagem de erro não ajuda nada…
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
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