ArcSDE e PostGIS – caracteres pt

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:

image

(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…

happy_face_

Clique para partilhar:Tweet about this on TwitterShare on LinkedInShare on Google+Email this to someone

2 pensamentos em “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

Deixar uma resposta

O seu endereço de email não será publicado. Campos obrigatórios marcados com *

Pode usar estas etiquetas HTML e atributos: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>