Medir o desempenho do PostGIS

Uma das formas de medir o desempenho do PostgreSQL no nosso servidor, é usar o pgbench, a ferramenta padrão incluída com a instalação do pgsql. Há tempos fiz uns testes de comparação de 2 servidores que publiquei aqui: http://blog.viasig.com/2014/08/medir-o-desempenho-do-postgresql/.

Ora, esses testes usam dados alfanuméricos e queries “normais”, de escrita e leitura, usando tabelas relacionadas. Ou seja, o pgbench tenta simular uma utilização usual do pgsql.

No nosso caso, SIGianos, a utilização usual não tem nada a haver – usamos dados espaciais e queries muito próprias. Este artigo mostra uma forma de medirmos o desempenho do PostGIS, usando também a ferramenta pgbench.

Uso “normal” de SIG

Quando um programa “normal”, não geográfico, consulta uma base de dados, em geral, obtém alguns registos, e pode até cruzá-los, para dar um resultado final. Provavelmente, apresenta uma tabela de resultados, paginados, com algumas colunas (menos de 10?). Um bom exemplo, é um programa de facturação ou de gestão de stocks. É este tipo de programas que o pgbench tenta simular.

Há uma enorme diferença para o uso que um programa de SIG faz de uma base de dados. O uso normal SIG é visualizar um mapa. E isso faz toda a diferença.

image

Este simples mapa de enquadramento usa 7 tabelas. A área visível usa um total de 618 registos (1+261+177+1+3+29+146). Se visualizarmos o país inteiro, a conta passa para 5841 registos. É muita informação para uma das operações mais básicas – pan e zoom.

Do ponto de vista da base de dados, o uso SIG é diferente:

  • Um mapa é, tipicamente, composto por diversos temas (facilmente mais de 10);
  • Cada tema é uma tabela espacial diferente na base de dados, logo em cada visualização vamos ler uma série de tabelas;
  • Cada tema/tabela pode ser lido na totalidade (não paginado) se visualizarmos toda a área do tema;
  • Cada tema/tabela pode ter aplicada uma selecção (filtro) logo de início com base nos atributos (e.g. para vermos apenas uma categoria de rios ou estradas);
  • Cada tema/tabela pode ainda ter aplicado um filtro espacial se estivermos a visualizar apenas uma área específica (ou seja, são apenas pedidos os dados relativos ao rectângulo visível no mapa);
  • Mas, principalmente, os dados geográficos são muitos mais “pesados” ou “gordos”: têm uma coluna que contém todos os vértices da geometria! (Cada vértice tem 2 números do tipo double, o que equivale a 2 colunas em dados alfanuméricos.)
  • Para agravar a coisa, os utilizadores nunca escolhem os campos que precisam para trabalhar, e assim quando abrem a tabela de atributos todos os campos são lidos.

Usar o pgbench para simular utilizadores SIG

Uma das capacidades do pgbench é que permite testar queries à base de dados feitas por nós, em vez de usar as pré-definidas. Basta criar um ficheiro sql que contém as nossas queries e passá-lo ao pgbench com o parâmetro –f.

É esta capacidade que usamos para simular queries espaciais e medir o desempenho em Transações por Minuto (TPS), tal com se faz para uma base de dados não espacial.

Assim, configuramos o PostgreSQL para que guarde no log todas as queries que recebe. Depois usamos o QGIS com um mapa típico que utilizamos frequentemente, e fazemos zoom a diversos locais e com diferentes escalas. A partir dos logs do PostgreSQL obtemos as queries SQL de cada zoom, e criamos um ficheiro .sql para cada zoom.

Em resumo, no nosso exemplo, obtivemos 10 ficheiros zoomN.sql que correspondem a 10 visualizações no QGIS do mesmo mapa, a escalas diferentes: zoom1.sql, zoom2.sql, … até zoom10.sql. Ou seja, um ficheiro .sql equivale a 1 mapa:

zoom1 – 1:1M                                                        zoom2 – 1:288.000

imageimage

zoom3 – 1:72.000                                                        zoom4 – 1:18.000

imageimage

Cada visualização criou um ficheiro .sql que podemos usar no pgbench, e simular vários utilizadores simultâneos de QGIS. Aqui,há uma simplificação: cada zoom é feito instantaneamente a seguir ao outro. Ou seja, vamos simular super-utilizadores! Piscar de olho que não fazem pausas entre zooms e pans.

O comando para simular 12 super-utilizadores que fazem 10 zooms/pans é o seguinte:

pgbench -f zoom1.sql -f zoom2.sql -f zoom3.sql -f zoom4.sql -f zoom5.sql -f zoom6.sql -f zoom7.sql -f zoom8.sql zoom9.sql zoom10.sql  -h <servidor> –U <user> -n -l -c 12 -j 2 -T 180 postgis

image

Tal como no artigo anterior sobre pgbench, o significado dos parâmetros é:

  • -n = não fazer vacuum aos dados, porque estamos a usar a bd de produção;
  • -l = log de tempos para um ficheiro;
  • -c 12 = simular 12 conexões simultâneas, ou seja, 12 utilizadores de SIG;
  • -j 2 = simular 2 threads por conexão (pouco impacto tem);
  • -T 180 = simular durante 180 segundos (3min);

Os resultados são:

transaction type: Custom query
scaling factor: 1
query mode: simple
number of clients: 12
number of threads: 2
duration: 180 s
number of transactions actually processed: 4004
tps = 22.148347 (including connections establishing)
tps = 22.188888 (excluding connections establishing)

O que quer isto dizer?

O que interessa é o valor final de 22.18 tps. Isto significa que o nosso PostGIS consegue responder a um ritmo de 22,18 mapas por segundo, em média. Ou seja, deviamos dizer 22,18 MPS (maps per second) Piscar de olho

Este valor é a média para todas as escalas que utilizámos no teste. Podemos testar cada escala em separado, e obter desempenhos por escala. Num outro teste usando dados do OpenStreetMap, fizemos este gráfico:

image

Obviamente, quanto maior a escala, maior o detalhe, e, geralmente, menos dados. Logo, à escala 1:1M temos um poder de processamento de 1,51 MPS, e à escala :1:5600 temos 112,92 MPS.

O que interessa nisto tudo é que podemos comparar agora entre servidores diferentes de PostGIS, e entre configurações diferentes num servidor, para determinarmos a melhor configuração.

Notem que este teste elimina o factor QGIS, ou seja, não se considera o desempenho do QGIS a desenhar o mapa. Uma vez que convertemos cada vizualização num ficheiro .sql, ao executar o teste só usamos o ficheiro .sql. Assim, o desempenho do QGIS não entra na equação, o que é necessário se queremos medir o desempenho do servidor PostGIS.

Outras questões de desempenho

Ao testar o desempenho do PostGIS, acabamos por nos apercebermos de alguns factores que influenciam e muito os resultados e o desempenho observado de um servidor PostGIS.

Por exemplo, se durante o teste verificarmos o que se passa no servidor, podemos ter algumas surpresas:

beja084_2

(Sim, eu sei… é windows…)

O CPU esteve a 91%, para conseguir responder aos nossos 12 QGIS simulados. É perigoso andar tão perto dos 100%, porque o desempenho começa a diminuir. Aqui temos de jogar com o n.º de conexões. Neste caso, baixar de 12 para 10 conexões simultâneas até poderia dar resultados melhores. Cada servidor terá o seu n.º de conexões para o qual se obtém o máximo de tps. Temos de experimentar vários valores e ver o melhor.

Os valores de memória apresentados no Task Manager são inúteis, porque a memória ocupada está sempre perto dos 100%. Teríamos de fazer outro tipo de análise.

Já a ocupação de rede é interessante: é enorme! 769 Mbps! É muito fácil limitar o desempenho do PostGIS por causa de uma má ligação de rede entre o PostGIS e os utilizadores. Se compararmos com o teste de queries “normais” não espaciais, vemos que a ocupação de rede é apenas de 22 Mbps (para o total das 12 conexões simultâneas).

image

Outra questão importante para os resultados dos testes é observar o estado do PC onde corremos o pgbench, principalmente quanto à ocupação do CPU: como o pgbench corre num só processo ocupa só 1 core, e podemos facilmente limitar os resultados porque o nosso CPU não consegue responder. Temos de verificar durante os testes se o processo pgbench.exe ocupa MENOS que 1 core. No meu caso, usei um i5, que tem 4 cores. Logo, o pgbench tinha de ocupar menos de 25% de cpu para que os resultados fossem bem medidos.

Conclusão

Usar o pgbench com dados espaciais dá-nos uma excelente forma de testar o desempenho do PostGIS. Podemos perceber qual o melhor servidor, se físico, se virtual, para o nosso caso particular. Podemos ainda testar configurações alternativas do PostgreSQL e identificar aquela que dá melhores resultados.

Melhor ainda, será criar um pacote de dados OSM e os scripts .sql correspondentes, e usá-los para termos um teste padrão de PostGIS. Se todos usarmos estes dados vamos conseguir partilhar resultados entre toda a comunidade. Hmmm, temos de pensar nisto…

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

MapServer em Windows e IIS

O MapServer é geralmente instalado com Apache, mesmo em Windows. Para este caso, basta um dos vários instaladores existentes, por exemplo, o OSGeo4W.

Mas, no meu caso e imagino muitos outros, como uso mais servidores Windows, precisei de instalar o MapServer de forma a que funcione com IIS. Para além disto, preciso também que o endereço web dos meus mapas não mostre sempre o ficheiro de configuração usado. É feio, e é um risco de segurança. Ninguém devia saber a estrutura das directorias no disco rígido do servidor.

MapServer como aplicação FastCGI – As melhores instruções

A parte inicial de configurar o IIS de forma a executar o MapServer é mais ou menos fácil de encontrar na net. Esta parte consiste em configurar o IIS de forma a considerar o executável mapserv.exe como sendo uma aplicação FastCGI. Isto é mais ou menos padrão nos IIS >7.0 (win7/win8/win2008/win2012). Este link explica bem como fazer isto, usando os ficheiros do MS4W:

https://github.com/mapserver/mapserver/wiki/Installing-Mapserver-under-IIS-7.n-with-FastCGI

Mas melhor ainda é uma instalação automática – sim existe! Preparada pelo nosso grande Tamas Szekeres:

http://www.gisinternals.com/query.html?content=filelist&file=release-1600-gdal-1-11-1-mapserver-6-4-1.zip

Nesta página escolham o ficheiro mapserver-6.4.1-1600-core.msi.

A minha instalação

Eu preferi fazer uma instalação manual, usando ficheiro zip do Tamas Szekeres contendo todo o software, em vez do .msi. Isto dá-me mais flexibilidade para encontrar a configuração que mais se ajusta às minhas necessidades.

Criei uma directoria wwwroot\MapServer, e descomprimi aqui o ficheiro zip. Este ficheiro contém apenas 2 directorias: bin e doc.

E, para facilitar a organização dos ficheiros map e daquilo que serão os serviços web, acrescentei mais 3 directorias: mapfiles, servicos, e tmp.

O aspecto final é este:

image

Ou seja, tudo o que pertence ao MapServer propriamente dito fica dentro da pasta “binarios”. Agora falta configurar o IIS para executar o mapserv.exe como aplicação FastCGI. A receita é curta e é feita na consola de gestão do IIS…

1) Dar permissões de escrita à pasta tmp.

Este passo é apenas necessário para permitir que o MapServer consiga criar ficheiros, o que apenas sucede em alguns cenários. Em princípio, se servirmos apenas WMS, WFS, não será necessário. Mas pelo sim, pelo não, mais vale configurar…

2) Permitir a execução de scripts na pasta MapServer.

Na pasta MapServer, abrir a funcionalidade “Handler Mappings” :

image

e abrir a acção “Edit Feature Permissions”. Nesta janela dar permissões de “Read”, “Script”:

image

3) Definir um documento default a apontar para o executável.

Mais tarde pode ser removido, mas para testar é muito útil. Nas definições básicas da pasta MapServer, escolher a funcionalidade “Default Document”, e escrever o caminho para o executável mapserv.exe (cuidado com as barras /):

image

4) Criar a aplicação FastCGIS para o MapServer.

Esta configuração é feita no nó principal do nosso site. Por isso, selecionamos o nó “Default web site” ou o nome que demos ao nosso site, a abrimos a funcionalidade “Handler Mappings”:

image

Aqui, clicamos na acção “Add Module Mapping” e definimos estas propriedades:

image

Ou seja, definimos que o executável mapserv.exe deve ser executado como uma aplicação FastCGI. Temos ainda de clicar no botão “Request Restrictions” e definir os “verbos” permitidos e o acesso necessário à aplicação:

imageimage

5) Último passo! Temos de definir as variáveis de ambiente que o MapServer necessita.

Estas variáveis estão todas escritas no ficheiro SDKShell.bat que está na pasta do MapServer. Estas variáveis têm de ser definidas ao nível da aplicação FastCGI, e o único sítio onde se pode fazer é ao nível do servidor IIS e não ao nível do site. Por isso, é preciso selecionar o nó raíz do IIS, e selecionar a opção “FastCGI Settings”:

image

Nesta janela, vemos a nossa aplicação FastCGI já criada. Podemos editar a nossa aplicação, e na janela de configuração clicamos na opção “Environment Variables”. Aqui temos de criar 4 variáveis:

image

As 4 variáveis de ambiente são:

  • PATH = C:\Inetpub\wwwroot\MapServer\binarios;C:\Inetpub\wwwroot\MapServer\binarios\gdal\python\osgeo;C:\Inetpub\wwwroot\MapServer\binarios\proj\apps;C:\Inetpub\wwwroot\MapServer\binarios\gdal\apps;C:\Inetpub\wwwroot\MapServer\binarios\ms\apps;C:\Inetpub\wwwroot\MapServer\binarios\gdal\csharp;C:\Inetpub\wwwroot\MapServer\binarios\ms\csharp;C:\Inetpub\wwwroot\MapServer\binarios\curl;%PATH%
  • GDAL_DATA = C:\Inetpub\wwwroot\MapServer\binarios\gdal-data
  • GDAL_DRIVER_PATH = C:\Inetpub\wwwroot\MapServer\binarios\gdal\plugins
  • PROJ_LIB = C:/Inetpub/wwwroot/MapServer/binarios/proj/share

E é tudo.

Depois desta configuração, os pedidos ao MapServer já devem funcionar:

http://localhost/MapServer

image

Parabéns – o MapServer está a funcionar. A partir daqui o uso é o normal. Podemos indicar o mapa que queremos usando o parâmetro mode=map&map=ficheiro. Por exemplo:

image

Agora, a questão é conseguir ter endereços simpáticos, que não mostrem o nome e caminho do ficheiro de configuração… o que queremos são endereços do tipo:

Mas é opcional… já podemos publicar todos os ficheiros map que quisermos. Fica a promessa de outro artigo com esta configuração para breve.

Ah, e já agora – este processo pode-se usar para instalar o QGIS Server. É exactamente a mesma coisa.

Bons web services!

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

Medir o desempenho do PostgreSQL

Não é todos os dias que temos a oportunidade de fazer um upgrade ao nosso velhinho servidor de PostGIS. Quando um servidor usado fica disponível ou, ainda melhor, quando recebemos uma máquina novinha em folha para instalar a nossa base de dados, queremos saber qual a melhoria de desempenho que vamos ter. Pelo menos eu quero Piscar de olho

Por outro lado, se vamos comprar um novo servidor temos de definir as características dentro do preço que podemos pagar. E convém ter uma orientação que nos ajude a perceber que tipo de desempenho podemos obter dentro desse orçamento.

Outra utilidade para este tipo de medição é perceber quais os melhores parâmetros de configuração do PostgreSQL para a nossa nova máquina. Podemos alterar os parâmetros e testar, vendo rapidamente qual a combinação de parâmetros que melhor desempenho consegue.

Este artigo mostra como medir o desempenho do PostgreSQL usando o comando standard para isso – o pgbench. Para outro post fica a proposta de um teste standard para medir o desempenho da componente geográfica – PostGIS – usando o pgbench com dados geográficos disponíveis publicamente. Isto permite que todos os utilizadores de PostGIS possam usar um teste padrão, tal como já existe para dados não-espaciais, e comparar diferentes servidores.

O ideal seria ter uma tabela online onde se pudessem comparar vários servidores, editada pelos utilizadores… isso é que era!

Os 2 servidores em confronto

Ao longo do artigo vão ser feitas comparações de desempenho entre 2 servidores praticamente iguais ao nível do hardware, onde apenas se altera o sistema de disco – o novo servidor promete muito melhor desempenho de disco. Mas há também diferenças no software – a versão do sistema operativo, e as versões do PostgreSQL e PostGIS são mais recentes e passam a 64bit. As características dos servidores são as seguintes:

Servidor CPU RAM Disco SO PostgreSQL PostGIS
velho Xeon E5420, 4cores 2,5GHz 12 GB SAN, 215GB Win 2003 x64 8.4.10, x32 1.4.2
novo Igual Igual SAN, 50GB Win 2008 x64 9.2.8, x64 2.1.1

Ambos os servidores têm a mesma configuração do PostgreSQL:

  • Shared Buffers: 512MB
  • Work Memory: 6MB
  • Effective Cache Size:  256MB

Usar o pgbench

O pgbench é uma ferramenta que vem incluída na instalação do PostgreSQL, e é usada para efectuar testes padronizados de desempenho transacional. Ou seja, é um teste que todos os utilizadores podem fazer e comparar entre si, já que o teste é sempre o mesmo, usando os mesmos dados. Como sempre, a documentação do PostgreSQL é excelente e o manual do pgbench também.

Como o pgbench envia comandos SQL para o servidor tentando levá-lo ao limite das suas capacidades, convém executá-lo a partir de outro computador ligado em rede, como por exemplo, o seu portátil ou desktop.

Para começar, temos de usar o pgbench para criar os dados necessários aos testes. Aqui temos de ter já uma ideia de quantas conexões vamos considerar. Isto depende do(s) processador(es) do nosso servidor. Quanto mais cores mais conexões simultâneas vamos conseguir executar em simultâneo. Podemos jogar pelo seguro e exagerar um pouco. Por exemplo, para o meu processador de 4 cores, vou iniciar os dados para 20 conexões simultâneas, embora saiba de antemão que são demasiadas (vou acabar por fazer os testes com apenas 12 conexões).

Para criar os dados, o pgbench precisa de saber o nome da base de dados a usar (que tem já existir). Se instalámos o PostGIS é provável que tenhamos criado uma bd com o nome “postgis” e é isso que vou usar nos exemplos. Também nos exemplos, o nome do servidor será “pgServer” e o utilizador será “userteste”.

Assim, para começar, executamos o pgbench no nosso computador (não no servidor) com o seguinte comando:

pgbench –i –s 20 –h pgServer –U userteste postgis

Este comando irá criar as tabelas do teste no schema do utilizador “userteste” e criará dados suficientes para testar 20 conexões simultâneas.

Em seguida vamos medir o desempenho do nosso servidor, medido em Transações por segundo, ou TPS.

O pgbench é muito completo, mas vamos simplificar e medir apenas 2 tipos de operações:

  • Transação típica, em que os registos são inseridos em tabelas relacionadas entre elas com chaves primárias e estrangeiras. Este é o desempenho mais típico de uma base de dados. É medida uma mistura de operações de escrita e leitura, com garantia de integridade.
  • Transação apenas de leitura, em que apenas se testa a componente de leitura da bd. Em princípio mede o valor máximo de TPS para o nosso servidor.

Vamos executar todos os testes durante 5 minutos. Assim, para testar a transação típica, vamos usar o comando seguinte:

pgbench –h pgServer –U userteste –c 12 –j 2 –T 300 postgis

A explicação do comando é a seguinte:

  • -c 12 => testar 12 conexões em simultâneo
  • -j 2 => cada conexão em 2 threads
  • -T 300 => testar durante 300 segundos, ou seja, 5 minutos

Já vamos ver os resultados mais à frente… para já temos de discutir como aparecem as 12 conexões…

Um servidor consegue responder a 1 só conexão com uma certa rapidez ou velocidade, medida em TPS. E queremos que seja o mais rápido possível. Ao aumentarmos o número de conexões, em principio, também vai aumentando o número de pedidos à base de dados que são processados por segundo pelo servidor. Até que estagna e começa a reduzir-se. Isto significa que o servidor tem um limite para processar pedidos em simultâneo. O seu máximo de TPS será obtido para um dado número de conexões. Este TPS máximo é um dos melhores indicadores de desempenho de um servidor de base de dados.

A questão que este comando coloca é: como vamos definir o n.º de conexões a testar? De forma geral, o servidor nunca deve ultrapassar os 85% de ocupação de CPU, porque acima deste valor começa a sentir-se contenção no acesso ao processador, ou seja, começa a formar-se uma fila de pedidos que aguardam pela disponibilidade do CPU para serem executados, e o próprio sistema operativo começa a atrapalhar-se. É este o nosso alvo – manter o CPU próximo dos 85% de uso.

Felizmente, podemos perceber rapidamente qual é o n.º de conexões que mantém o CPU perto dos 85%. Em geral, a partir daqui o valor de TPS não aumenta, podendo mesmo baixar.

Isto é muito fácil: basta executar alguns comandos pgbench rápidos, de 30 segundos (usando -T 30 em vez de –T 300), com cada vez mais conexões, e vigiar o CPU do servidor ao mesmo tempo que apontamos os resultados. Há um n.º de conexões que acaba por saturar o processador e partir do qual não se aumenta o desempenho. Por exemplo, podemos usar esta sequência de comandos:

pgbench –h pgServer –U userteste –c 6 –j 2 –T 30 postgis

pgbench –h pgServer –U userteste –c 8 –j 2 –T 30 postgis

pgbench –h pgServer –U userteste –c 10 –j 2 –T 30 postgis

pgbench –h pgServer –U userteste –c 12 –j 2 –T 30 postgis

pgbench –h pgServer –U userteste –c 14 –j 2 –T 30 postgis

No meu caso, as 12 conexões revelaram ser o ideal, o CPU nunca passou os 85%, e o desempenho foi o maior de todos. Já com 14 conexões, o desempenho começou a reduzir ligeiramente.

Resultados do pgbench

Os resultados do comando acima são os seguintes:

starting vacuum...end.
transaction type: TPC-B (sort of)
scaling factor: 20
query mode: simple
number of clients: 12
number of threads: 2
duration: 300 s
number of transactions actually processed: 537417
tps = 1791.328213 (including connections establishing)
tps = 1792.516930 (excluding connections establishing)

Qual a conclusão?

Este servidor conseguiu executar 537.417 transações “normais” do pgbench, em 5 minutos, o que dá um valor de 1.792 transações por segundo (TPS). Com este número já podemos comparar com outros servidores que tenham usado o pgbench.

Em seguida, medimos também o desempenho com transações apenas de leitura, usando um comando quase igual – apenas adicionamos o parâmetro –S:

pgbench –h pgServer –U userteste –c 12 –j 2 –T 300 –S postgis

Os resultados são os seguintes:

starting vacuum...end.
transaction type: SELECT only
scaling factor: 20
query mode: simple
number of clients: 12
number of threads: 2
duration: 300 s
number of transactions actually processed: 6844551
tps = 22815.432028 (including connections establishing)
tps = 22830.845226 (excluding connections establishing)

Ou seja, para queries apenas de leitura, conseguimos um TPS de 22.830, muito mais elevado, como é de esperar.

Assim, a comparação entre o servidor antigo e o novo fica com este aspecto:

Servidor Teste “normal” (TPS) Teste só leitura (TPS)
velho 590 20.944
novo 1.792 22.830

Boas notícias. Tudo aponta que o novo servidor vale a pena… +200% de desempenho em queries mistas, e +9% em queries de leitura apenas. Isto confirma a suspeita inicial: o sistema de discos do novo servidor é muitíssimo melhor, sendo o seu impacto terrivelmente visível no desempenho de escrita na base de dados, e ainda aumentando o desempenho de leitura em 9% (até porque grande parte das queries de leitura são efectuadas em memória). Claro que a introdução de uma nova versão de PostgreSQL também terá a sua influência, e neste caso é impossível determiná-la.

No próximo artigo vamos medir o desempenho do PostGIS, usando o pgbench com dados geográficos.

Até lá, bons desempenhos! Piscar de olho

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

Mosaicos com áreas transparentes

Neste artigo regresso a um assunto já familiar neste blog – criar mosaicos de ortofotomapas usando o GDAL – (sim eu sei, outra vez?) mas como tenho andado às voltas com as áreas sem informação, que surgem negras nos mosaicos pensei em postar o que acabei por fazer. A solução final é usar máscaras, e não bandas alfa como habitual. Vamos ver como e porquê… assume-se já alguma familiaridade com o GDAL, mas pode sempre saltar as partes teóricas aborrecidas e ver os comandos usados no final do artigo ;) Ler artigo completo

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

QGIS – Revisitando ficheiros DXF

O QGIS há muito tempo que lê ficheiros DXF ASCII, aproveitando sempre os melhoramentos que a biblioteca OGR vai trazendo com as novas versões.

Estando a planear introduzir o QGIS na empresa de forma generalizada, tive que revisitar esta função, dado que ler CAD é uma função essencial para muitos utilizadores.

Update 2013-06-05: O problema já foi resolvido. A versão de desenvolvimento já permite abrir ficheiros dxf e escolher que tipo de geometria queremos carregar. Realmente, trabalhar assim é uma maravilha.
Ler artigo completo

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

OSM – We are not alone!

Depois de ser alertado na lista osm pt de que há uma nova ferramenta online para vermos que editores existem no próprio mapa do OSM fiquei curioso em ver como estamos de editores aqui pelo Baixo Alentejo.

O artigo do autor da ferramenta está aqui:
http://neis-one.org/2013/01/oooc/ 

E a própria “The OpenStreetMap Contributors Map” está aqui:
http://resultmaps.neis-one.org/oooc

Depois de umas colagens aqui está o resultado:

OSM_vizinhosBejaCuba

Ainda somos pr’ai uns 6 gandas malucos! Mas já temos um verdinho e 2 laranjas… (os vermelhos não contam porque praticamente só criaram o login).

E só estes fizeram isto tudo?? ;)

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

PostgreSQL e ESRI – parte 4

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 curso 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.
Ler artigo completo

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

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+Pin on PinterestEmail this to someone

Vamos ao GeoCamp

Este Sábado acontece um evento muito especial em Vila Nova da Barquinha: GeoCamp. Uma desconferência sobre SIG e outros assuntos tão (quase) interessantes ;)

Pensem nisso – ao mesmo tempo de convivem aprendem. As inscrições são gratuitas. E se quiserem falar, força! (como dizia o outro na rádio – “queres falar?“)

“O GeoCamp é uma “desconferência”, muito inspirada no conceito de Barcamp, que consiste num encontro aberto a todos e conduzido pelos próprios participantes.”

Mais info: GeoCamp.

Vamos ao GeoCamp

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

QGIS e conflitos com DLLs Qt

Este curto artigo serve como memória para mim e pode ser que seja útil a quem também tenha o mesmo problema…

Como uso o Cartão do Cidadão tenho instalado o software respectivo. Este coloca na pasta \windows\system32 algumas DLLs de Qt que necessita. Inicialmente pensei que seria um bocado desleixado dos autores colocarem aqui e não na pasta do programa, mas hoje penso que será uma necessidade para permitir que o Internet Explorer possa usar a autenticação do CC em sites como os de contratação pública.

O problema é que o QGIS usa também o Qt (pacote de programação de interfaces gráficas), e instala de forma bem comportada, as DLLs que precisa na sua própria pasta. Sucede que o Windows carrega primeiro as DLLs que encontra na pasta system32

Como o Windows encontra as mesmas DLL’s na pasta system32 carrega estas, que são de uma versão mais antiga, em vez das que são incluídas no QGIS. O resultado é um erro críptico de “entry point not found”…



QGIS: Missing Entry Point

QGIS: Missing Entry Point

A solução que tinha encontrado inicialmente era simples: retirava as DLL’s do CC da pasta system32 sempre que usava o QGIS. E voltava a colocá-las lá quando queria usar o CC… very boring…

Mas há outra solução. O Windows obedece a uma ordem de pesquisa de DLL’s e sucede que a pasta onde se encontra o executável é procurada antes da system32. Assim, no caso do QGIS 1.7  basta copiarmos as DLL’s do Qt da pasta C:\OSGeo4W\bin para a pasta C:\OSGeo4W\apps\qgis\bin. E fica resolvido para todo o sempre, amen.

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