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…

Partilhar

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.

Partilhar

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

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.

Partilhar

SIG Open Source? Sim, obrigado.

Como gestor de um Sistema de Informação Geográfica (SIG) tenho especial interesse em analisar a decisão de usar um dado produto num projecto. E em especial quando esse produto pode ser de Código Aberto (CA) quais são as implicações associadas a essa escolha? Além das minhas próprias escolhas, observo com interesse as escolhas de colegas em situações semelhantes, as suas dúvidas e receios. Em geral, a escolha de produtos CA carregam um receio que não surge na escolha de produtos de Código Fechado (CF). É sobre esta questão que espero contribuir construtivamente neste artigo.

Os Suspeitos do Costume

Antes de continuar, devo referir algumas das soluções de Código Aberto actualmente mais usadas na área SIG. Espero com esta lista apresentar soluções que são fiáveis, estáveis, sustentáveis, e duráveis no tempo, para as várias vertentes de um SIG.

Na gestão de informação geográfica (IG), a escolha é indisputada, recaindo na base de dados relacional PostgreSQL (PgSQL) e o seu módulo PostGIS. Juntos são a solução Open Source mais usada para armazenamento e gestão de IG, havendo exemplos impressionantes da sua utilização em todo o mundo. Mais relevante, a meu ver, do que o mérito tecnológico do PgSQL, é a quantidade de produtos que são compatíveis com esta base de dados, abrangendo praticamente todos os produtos na área SIG, Open Source ou de Código Fechado. Esta é, para mim, das maiores virtudes do PgSQL.

Na área dos servidores de webgis, ou seja, de serviços web de informação geográfica, existem duas opções mais usuais: MapServer e GeoServer. Ambos suportam uma enorme lista de padrões de publicação via web (WMs, WFS, WPS, WCS, …), oferecem desempenhos excelentes, e têm comunidades enormes. Assim, a escolha aqui é uma questão de preferência pessoal. Curiosamente, todos os anos é organizada uma competição de desempenho, onde uma equipa MapServer e uma equipa GeoServer se confrontam numa série de testes. Este embate de titãs acontece na conferência anual FOSS4G, organizada pela Open Source Geospatial Foundation (OSGeo), e as conclusões são usadas para planear melhoramentos futuros.

Ainda na área webgis, falta referir a área de programação, ou seja, a tecnologia para criar aplicações web com mapas. A resposta é também muito fácil – OpenLayers. Este produto nasceu em 2005, tendo um crescimento explosivo desde então. É compatível com um enorme conjunto de servidores, não apenas Open Source, sendo usado directamente ou incorporado noutros produtos. Se costuma usar um mapa online, há uma grande probabilidade que esteja a usar OpenLayers. Por exemplo, sabe qual é a base tecnológica dos mapas do Sapo? Pois é…

Existem ainda outros produtos que permitem criar sites com mapas exigindo menores capacidades de programação, entre eles o MapFish, a OpenGeo Suite, e o p.mapper.

No posto de trabalho temos também opções excelentes, sendo as mais conceituadas o gvSIG e o Quantum GIS. Ambos oferecem as funções que todos esperamos de um programa SIG: visualização, edição, análise, impressão, e gestão de informação geográfica; e claro tudo via interface gráfica, nada de comandos de linha. Ambos são modulares, com diversos módulos que adicionam novas capacidades, como visualização 3D, modelação geoestatística, edição tipo CAD, gestão de PostGIS, publicação de serviços WMS, entre muitos, muitos outros. Tanto o gvSIG como o QGIS integram-se com dois outros produtos Open Source especializados em análise geográfica: o gvSIG recorre ao Sextante, e o QGIS recorre ao GRASS. Com esta integração, a capacidade de análise que fica ao nosso dispor é nada menos que extraordinária.

A lista de opções dignas de nota é bem mais vasta, mas espero que esta curta lista possa ser útil como ponto de partida.

Usa a Comunidade, Luke

Quando se opta por um produto de Código Aberto, à partida não há um contrato de manutenção com um contacto telefónico ou de email a que podemos recorrer quando encontramos um problema que não conseguimos solucionar sozinhos. Mas há outros mecanismos de suporte, diferentes mas tão ou mais eficazes, como veremos.

Por definição, num produto Código Aberto, temos acesso ao código fonte do software, sendo possível alterá-lo de acordo com as nossas necessidades. Mas também é óbvio que esta não é uma tarefa exequível na maioria das organizações. O que temos, que é ainda melhor que o acesso ao código fonte, é acesso aos programadores desse produto. Via email ou irc (vulgo chat), podemos discutir as nossas dificuldades directamente com os programadores. Mais, temos acesso ao site onde os programadores registam os problemas detectados, que usam para planear as suas próximas tarefas. Melhor ainda, podemos nós mesmos registar nesse site melhoramentos e problemas que julgamos mais importantes, influenciando a sua prioridade. Esta capacidade de intervir e ver solucionados problemas rapidamente é um aspecto fulcral das comunidades de software livre.

Claro que a comunidade que rodeia um produto Open Source não se limita aos seus programadores. A maioria dos membros dessa comunidade são utilizadores como nós, em diversos graus de maturidade e experiência de utilização. De início, seremos consumidores de conselhos e de ajuda. Gradualmente, seremos contribuidores, mais activos em fornecer essa mesma ajuda e conselhos a quem se iniciou depois de nós.

Este processo de construção de comunidades não é exclusiva de produtos de Código Aberto, mas é aqui um processo mais intenso, uma vez que os programadores e mentores do produto estão muito presentes, certamente mais do que é habitual em produtos de Código Fechado.

Uma organização que decida implementar um projecto SIG baseado em tecnologia de Código Aberto não deve olhar apenas para o preço de aquisição e manutenção, embora este seja sempre um factor fundamental de selecção. Há todo um modo de actuar que lhe está associado, uma nova postura, talvez mais proactiva e mais participativa, que é, na minha opinião, profissionalmente mais estimulante.

Dúvidas Existenciais

Havendo um conjunto de produtos de Código Aberto com qualidade que abrange todas as áreas de um SIG, então o pode fazer hesitar um gestor na altura de seleccionar um deles para um novo projecto?

Para além de outras, existem duas razões muito comuns para para hesitações na implementação de produtos Open Source. Uma é a percepção de não existirem empresas a operar no mercado que possam oferecer serviços de desenvolvimento, de formação, e de suporte técnico. Outra é o receio de que o produto possa desaparecer a qualquer momento.

Na verdade, Open Source é um termo muito lato, que abrange um vasto leque de situações. Apenas num dos sites de Open Source mais conceituados (Source Forge) encontramos 280 mil projectos disponíveis.

O que se pode argumentar quanto a estes receios? Que certos produtos são escolhas seguras e que outros são escolhas mais arriscadas. Que a sensatez ainda é a nossa melhor ferramenta de decisão. E nada disto é novo, com Código Aberto ou Código Fechado a situação é em tudo semelhante.

Quanto a empresas, hoje é fácil encontrar quem nos suporte no nosso projecto de Software Aberto SIG (SASIG). Não vou aqui enunciar nomes, mas alguma pesquisa na Internet, alguns telefonemas e mensagens de email, resolvem a questão certamente, incluindo formação e suporte contratualizado. Se extraordinariamente não encontrar alguém em Portugal, hoje em dia isso não é obrigatoriamente impeditivo, dada a facilidade de, remotamente, empresas noutro local do mundo nos apoiarem nos nossos esforços.

O Futuro

O futuro é brilhante. E só pode melhorar. Pelo menos no mundo de Código Aberto.

Os melhores produtos continuarão a fortalecer-se, obtendo ainda maior aceitação. A construção da comunidade nacional está em marcha. No final de 2010 foi formalizada a OSGeoPT – Associação Software Aberto para Sistemas de Informação Geográfica, à qual honradamente pertenço, com o intuito de mobilizar a comunidade portuguesa de SIG de Código Aberto. E a 4ª Conferência SASIG está já agendada para Novembro, em Guimarães. Todos estão convidados a participar, a partilhar experiências, sucessos e dificuldades, a aprender e ensinar.

Procure a sua comunidade, o wiki da OSGeo PT e lista de email, envolva-se, e acabe de vez com as suas dúvidas existenciais.

Partilhar

Separador OSM

Só uma nota rápida para quem não conhece, e fico sempre surpreendido com a quantidade de pessoas que me vão dizendo que não conhecem, o OSM é um projecto internacional, comunitário, de levantamento de dados cartográficos por hobbyistas (chamados pomposamente de voluntários). E tem sido um fenómeno enorme de popularidade, e vale muito a pena investigar. Até porque a sua qualidade é tal que é usado em vários produtos para navegação pessoal. Um dos últimos convertidos é a MapQuest - faça uma visita se quiser ficar impressionado. O OSM começou por levantar a rede rodoviária, e abrange hoje uma série de outras categorias de dados, especialmente pontos de interesse. Mas fiquemos por aqui sobre o projecto OSM em si.

Continuando…

Dizia eu, Beja praticamente não tinha dados levantados, e eu como iniciado entusiasta, lá vectorizei algumas vias principais: usando o OSMTracker andei de carro com o meu telemóvel, que tem GPS, passei os dados para o PC, e usei o JOSM para “limpar” os dados e preencher os nomes das ruas, e finalmente passei tudo para o servidor. “Charân” – cidade de Beja online! (Mas muito poucochinho…). Note-se que agora as coisas estão bem mais simples – vectorizamos por cima dos ortos do Bing usando o excelente Potlatch2, e falta só atribuir nomes às vias. Para isso podemos usar o Walking Papers. (isto porque não podemos copiar os nomes das ruas do Bing.)

Andei distraído algum tempo, e agora que tenho um tablet Android, comecei a testar programas de navegação que usam dados OSM (que são muitos). E é quando vejo a cidade de Beja completamente cartografada! Vias, Pontos de Interesse, áreas verdes, cemitério… farmácias, parques de estacionamento, supermercados… impressionante.

Mas de quem é a criança? Quero dizer, quem foi o cartógrafo de serviço?

Histórico do OSM

Devem existir outras formas de fazer isto, mas eu usei o ITO OSM Mapper, e deixo aqui a dica.

Este site permite visualizar para uma dada zona quais as edições feitas nos últimos 3 anos, identificando os utilizadores, as datas de edição, e o n.º de vias editadas em cada sessão. Espectáculo.

Então, observem. Esta imagem mostra as sessões de edição feitas em Beja no último ano. Podemos assim perceber as sessões de edição que mais contribuíram para o mapa(cada sessão terá uma cor).

Começa a ser claro, que um dos editores sobressai… alterando a caixa “View”, passamos a ver as edições por utilizador:

Olá… Sr. Luís Coentro!! Quero aqui deixar os meus parabéns!! Se um dia nos encontrarmos, faço questão de lhe oferecer uma imperial no Pulo do Lobo, para me contar a história de como mapeou a cidade de Beja!

Mais a sério

O OSM é um projecto com um potencial incrível. As organizações que necessitam de uma rede viária cartografada, fácil de usar, e de manter, podem contribuir e usufruir deste repositório, beneficiando dele e beneficiando todos os co-cidadãos pelo caminho. As câmaras municipais são potenciais utilizadores/produtores óbvios. As escolas com cursos técnico-profissionais podem também usufruir imenso deste projecto, enquanto ao mesmo tempo contribuem para o mesmo. Aliás, projectos de cooperação câmaras-escolas teriam toda a lógica, e seriam duplamente úteis. Sabendo das dificuldades em obter dados geográficos utilizáveis, e da dificuldade em encontrar projectos escolares úteis, aqui fica a sugestão.

Já agora ficam aqui alguns contactos para a malta tuga do OSM: lista de email osm-pt, páginas pt no wiki OSM, página no wiki da OSGeo-PT sobre o OSM, lista de email OSGeo-PT.

Bons mapas.

Partilhar

O Problema Base

No mundo SIG há uma vertente de desenvolvimento de aplicações, das mais simples, como scripts que automatizam pequenos processos, até aplicações complexas web ou desktop.

Várias dificuldades mundanas se levantam ao longo de um projecto deste tipo, e talvez a mais importante seja: onde está a última versão?

Pessoalmente, uma questão com que me confronto frequentemente, quando preciso de voltar a trabalhar num programa/script/aplicação é bem simples: onde raio a tenho guardada, de entre os PCs e contas de utilizador que uso??? Raios!

A Gestão de Versões

Uma breve nota sobre gestão de versões… Para quem não conhece esta abordagem, o SVN é um programa que consegue manter o histórico de todas as alterações feitas a um conjunto de ficheiros. Existem depois ferramentas em cada PC que a partir de uma directoria detectam os ficheiros alterados e enviam-nos para o servidor, que os armazena. Ou seja, consegue-se assim um repositório central de ficheiros, actualizados, e ainda com um histórico de alterações – denominando-se este processo Gestão de Versões. Mais info na net, por exemplo aqui em português. Há outras opções para além do SVN que têm vindo a ganhar popularidade, principalmente porque usam o conceito de repositórios distribuídos (ver o Mercurial).

A nível empresarial, tenho as coisas mais organizadas – usamos um servidor central com o Visual SVN Server, e cada técnico que desenvolve aplicações tem a obrigação de lhe fazer chegar todas as alterações que vai fazendo. Cada PC tem instalado o TortoiseSVN. Para garantir que há disciplina (coisa estranha a portugueses, e muito mais a portugueses programadores!!), basta estabelecer a regra de que é apenas permitido colocar aplicações no servidor através do SVN (não há copy/paste!). Como o SVN coloca um pequeno ícone nas pastas a indicar se estão sincronizadas com a última versão, é fácil detectar pastas mal-comportadas, e assim chegar rapidamente ao culpado. (excelente incentivo à disciplina portanto)

Repositórios Online

Mas o que me levou a escrever este artigo não foi o meu interesse em Gestão de Versões, por mais interessante que seja… mas sim repositórios online gratuitos. Esta é a forma, para mim, mais fácil e simples de manter estes pequenos projectos pessoais reunidos, organizados, e acessíveis em qualquer PC e local.

A ideia é escolher um dos vários serviços gratuitos disponíveis, criar uma conta, e carregar as nossa aplicações. A partir daqui, usamos a nossa ferramenta SVN/Git/??? favorita nos nossos PCs, para manter o repositório actualizado com um simples clique do rato. Alguns sites até oferecem ferramentas de gestão de bugs, objectivos a desenvolver, wiki, etc. Atenção: refiro-me a repositórios privados. Os gigantes públicos não contam…

Os sites que prefiro são os seguintes:

• Assembla – para quem quer espaço acima de tudo. A conta gratuita oferece 2GB! Mas é limitada ao repositório, sem mais funcionalidade (wiki, tickets, gestão de projecto). Tem muito bom aspecto, profissional.
• Unfuddle – para quem precisa de menos espaço e valoriza outras funções. Oferece 300MB de espaço, com todas as funções – Milestones, Tickects, Mensagens, Equipa… Excelente, embora com um design menos conseguido. Limita o n.º de projectos a 1, mas com repositórios ilimitados. E só 2 pessoas na equipa.
• ProjectLocker – idem, mas com 500MB de espaço, limitando o n.º de projectos a 3.

Há várias outras opções, mas são variações do mesmo. A escolha dependerá claro das preferências de cada um e da qualidade do serviço. Faça o favor de partilhar a sua escolha nos comentários para conhecermos as melhores alternativas.

Update 1: o Luís Carlos Maderia sugeriu o BitBucket, que oferece disco ilimitado, ferramentas de gestão, gratuito até 5 users. Embora baseado no Mercurial, tem suporte para SVN (ainda em beta).

Update 2: neste site encontramos uma tabela comparativa de fornecedores de hosting de código, gratuitos e pagos, para SVN.

Partilhar

Alguém descobriu que no topo do edifício da sede da Força Aérea do Irão está uma estrela de David gigante! E agora, vão demolir??  :-)))

A imagem é do Google Earth, como sempre, e é desavergonhadamente retirada do Google Earth Blog onde podem ler a estória melhor, e ver outras descobertas (como a suástica no Pentágono):

Partilhar

CAD e SIG

Existe uma rivalidade antiga entre quem trabalha com software CAD e quem trabalha com software SIG – é comum ouvirmos dizer coisas como “o CAD é menos avançado”, ou “os tipos do SIG têm a mania de complicar as coisas”, entre outros mimos. Na realidade CAD e SIG são ferramentas usadas para fazer coisas diferentes, com métodos de trabalho diferentes, e que (infelizmente) têm de conviver de forma muito próxima, sem se compreenderem muito bem… (Aviso: tentei ser isento, mas acho que desisti a meio do texto…)

Simbologia é informação

No CAD esta afirmação é verdadeira. No SIG não.

No CAD eu desenho os meus elementos gráficos com o objectivo principal de obter uma visualização – para ver no monitor ou para imprimir. Quanto mais produtivo for a criar a minha visualização melhor técnico CAD serei. Os elementos que crio no ficheiro CAD representam exactamente o que preciso de ver: uma árvore é constituída por uma copa, um poste de iluminação tem um pé e uma lâmpada, uma área ajardinada tem vários pequenos arbustos. Eu posso seleccionar cada um destes elementos e alterá-los para obter a visualização exacta que pretendo. Quando gravo um DWG ou um DGN gravo tudo isto – uma linha com dada cor, espessura, tipo de tracejado – gravo no ficheiro as geometrias que são também a simbologia em simultâneo. A estrutura do meu desenho é constituída pela forma como eu organizo os meus elementos por camadas (layers ou levels), e como crio os meus elementos (blocos ou elementos simples).

No SIG a situação é muito, muito semelhante. Mas 2 ligeiras diferenças são suficientes para tornar o diálogo entre as equipas CAD e SIG difícil e por vezes até antagónico.

1) No SIG eu desenho apenas geometrias. Recolho vértices XY. E recolho características das geometrias, que armazeno em atributos. Todas as geometrias que recolho num ficheiro têm sempre os mesmos atributos, e por isso descrevo-as de forma sistemática, formando uma tabela. Não há simbologia envolvida no processo. Ao gravar o trabalho num ficheiro de dados, guardo apenas vértices XY e atributos, sendo uma das razões por que grande parte do trabalho é focada em organizar informação, em decidir que atributos cada ficheiro terá. Mas esta obsessão organizativa vai mais longe! Cada ficheiro tem apenas um tipo de geometria – ponto, linha ou polígono – que nunca se misturam no mesmo ficheiro.

2) No SIG a simbologia é aplicada por regras a um ficheiro – não se define a simbologia de um só elemento. Usam-se os atributos para seleccionar um conjunto de geometrias a que depois aplicamos uma certa simbologia. Por exemplo, podemos representar especificamente as cidades com população maior que 1 milhão de habitantes como círculos pretos, as restantes cidades com um quadrado.  Se todos os pontos que são as cidades tiverem um atributo com a sua população, o software SIG aplica esta simbologia facilmente. Uma consequência desta abordagem à simbologia é que passa a ser dinâmica. Se quisermos alterar a simbologia, não alteramos as geometrias – alteramos as regras da simbologia. Para guardar a simbologia usam-se ficheiros de projecto, que não têm dados, apenas regras e definições de como representar a informação e como a imprimir (formato da página, orientação, seta do norte, título, ou seja, o layout).

CAD	SIG

Exemplo de informação CAD original, e quando convertida para SIG.

Então qual é o problema?

Como dizem os políticos, ainda bem que fez essa pergunta…

Pois é, o problema é na conversão de CAD para SIG. Este é um assunto muito extenso e interessante, mas como é Verão apetece mais uma bejeca… Mas ainda consigo lembrar-me de 3 grandes problemas nesta conversão:

1) Seleccionar num ficheiro CAD elementos que têm o mesmo significado é geralmente difícil. Se todos pontos que são as cidades estiverem num único layer, e nesse layer não existir outro tipo de pontos, então a sua selecção é facílima. Mas isso raramente acontece… geralmente elementos gráficos com diferentes significados coexistem no mesmo layer.

2) Determinar a posição correcta de um elemento é muitas vezes difícil – a cidade está no ponto de inserção do bloco, ou é o ponto central do bloco? O ponto cotado é o ponto de inserção, ou é a virgula decimal do texto da cota? E aqui junta-se a dificuldade de evitar as tramas ou “hatches”. (As tramas são linhas que representam simbologia mas não representam uma entidade no terreno. Geralmente aplicadas a polígonos, servem de arranjo gráfico, e não devem ser convertidas para SIG.) Outro exemplo são marcas quilométricas em eixos de infra-estruturas… no CAD são importantes, no SIG são considerados erros de conversão. Outro grupo de problemas pode ser aqui incluído – questões como converter linhas fechadas do CAD para polígonos no SIG, reconhecer vazios, e outras questões semelhantes…

3) E finalmente, recolher atributos juntamente com as geometrias é muitas vezes… … … difícil (novamente)! e para o SIG os atributos são fundamentais. Por exemplo, qual é a cota de cada ponto cotado ou curva de nível? Ou qual é o nome de cada eixo de rua? A verdade é que já foi feito o trabalho de recolha e digitalização desta informação pela equipa CAD, mas mesmo assim não é possível muitas vezes usá-la num SIG (ou noutro sistema qualquer). No CAD, o texto que mostra o nome de uma rua é uma entidade gráfica  independente da linha, e por isso não existem métodos automáticos fiáveis para associar cada linha a cada texto. A não ser que se crie o ficheiro CAD já com a preocupação de permitir este tipo de interoperabilidade, e assim avançamos para tópicos de CAD avançados que (na minha experiência) escapam à maioria dos desenhadores.

Então e agora?

Pois é… agora estamos todos numa grande alhada. Ao fim de dias a tentar converter ficheiros CAD, o pessoal do SIG está pronto a abraçar uma vida de crime, começando por cometer uma série de homicídios lá para as bandas do CAD.

A única solução é conhecer bem o software que usamos. Com o tempo vamos aprendendo as técnicas que o software suporta para conseguir conversões cada vez mais automáticas. Mas tudo depende dos ficheiros originais CAD. E é muito importante poder contar com alguém no “lado” CAD que possa alterar os ficheiros CAD de forma a facilitar o processo de conversão.

Outra via de facilitar a vida a todos os técnicos envolvidos num processo que passe por CAD e SIG, é estabelecer regras para os ficheiros CAD que facilitem depois um processo menos manual de conversão. E isso novamente vai depender da informação em causa, e do tipo de AutoCAD em uso (“normal”, Map, Civil…). Por exemplo, no AutoCAD Map podemos criar Object Data, Object Class, ou até ligar os nossos elementos gráficos a tabelas de atributos externos, mas em AutoCAD “simples” isso já não é possível…

Portanto, não há regras infalíveis. Cada caso é um caso, como se diz. Mas há regras de bom senso que resultam sempre bem – agrupar elementos gráficos com o mesmo significado num só layer é uma dessas regras: só eixos de via num layer, e todos os eixos de via estão nesse layer (não há outros tantos eixos noutros tantos layers); cada layer tem um nome claro e intuitivo (nada de layers com nomes do tipo “ev_de” – que quereria dizer “eixos de via do distrito de évora”…); para layers de polígonos criar também o respectivo layer de anotação ou blocos de atributos (onde também marcamos os vazios), e outras regras deste género. Bom senso é muito subestimado hoje em dia…

QGIS

E finalmente chegamos à parte principal do artigo, que originou o seu nome…

O QGIS usa como leitor de dados as bibliotecas do GDAL (imagens) e OGR (vectores). Este facto não é muito visível para o utilizador, mas é importante para compreender as capacidades do QGIS. Estas bibliotecas têm drivers que são responsáveis por cada formato que o GDAL/OGR suporta. No caso de ficheiros CAD só 2 formatos são suportados – DXF e DGN. Está já pronto um novo driver para DXF e que lê também DWG, mas ainda não é incluído no QGIS (nem mesmo na versão 1.5 a lançar já em Julho).

O caso DXF

O OGR converte DXF para qualquer outro formato que suporte, como o shapefile. E mantém alguns atributos, como o layer, o que é muitas vezes suficiente para converter e organizar a informação CAD. Mas enquanto o QGIS não usar uma versão de OGR que inclua o driver DXF não vamos conseguir ler estes ficheiros directamente no QGIS. Temos assim de usar comandos de linha…

Assim, para evitar usar a linha de comandos do OGR, podemos fazer esta conversão no QGIS usando o plugin Dxf2Shapefile (incluído na instalação do QGIS). Mas surpreendentemente este plugin não mantém quaisquer atributos quando converte ficheiros DXF, e ficamos com pontos, linhas e polígonos sem sabermos o que representam. O que é muito desapontante.  A sua utilização é muito fácil, mas os resultados são pobres dada a flagrante ausência de atributos.

Conversão de DXF para Shapefile no QGIS – perdem-se os atributos.

O caso DGN

Há uma outra opção – o QGIS lê directamente ficheiros DGN, e carrega-os para o mapa sem ser necessário uma conversão prévia. E melhor ainda, vários atributos são visíveis, e assim, tendo o ficheiro CAD no nosso mapa, podemos aplicar selecções de acordo com o level (equivalente ao layer dos DXF), e gravar para ficheiros shapefile.

O QGIS consegue ler DGN directamente e mantém atributos como o level, permitindo fazer selecções e gravar para shapefile.

Uma surpresa é que o DGN é carregado com todas as geometrias misturadas num só tema. O que é invulgar. Temos de nos habituar a esta ideia e encontrar forma de filtrar cada tipo de geometria para as conseguirmos separar e exportar para shapefile. Isto é, vamos criar um filtro (Query) no QGIS para ficar apenas com pontos, e exportá-los para um shapefile. E fazemos o mesmo depois para isolarmos as linhas e os polígonos.

Como o QGIS usa o OGR para ler ficheiros DGN, basta uma consulta à página do driver DGN do OGR, para ficarmos a saber quais os atributos a que temos acesso com ficheiros DGN. E vemos que o atributo “Type” indica o tipo de geometria:
Line (3): Line geometry.
Line String (4): Multi segment line geometry.
Curve (11): Approximated as a line geometry.
B-Spline (21): Treated (inaccurately) as a line geometry.
Arc (16): Approximated as a line geometry.
Ellipse (15): Approximated as a line geometry.
Shape (6): Polygon geometry.
Text (17): Treated as a point geometry.
Ou seja, para no QGIS seleccionar todas as linhas num DGN, podemos usar a seguinte query (usando a opção “Query” no menu de contexto do tema DGN, acedido clicando com o botão direito sobre o tema DGN):

Type = 3 OR Type = 4 OR Type=11 OR Type = 21 OR Type = 16 OR Type = 15

No QGIS filtramos o DGN com uma query, para isolar um só tipo de geometria (ponto, linha ou polígono).

Depois de fazer a query todos os elementos que restam visíveis no QGIS serão linhas, e podem ser gravados para um shapefile usando a opção “Save as” do menu de contexto do tema.

Depois de termos a informação dividida por 3 shapefiles, um por tipo de geometria, podemos então fazer selecções por level para tentar isolar objectos com determinados significados.

Na verdade nem é preciso exportar para shapefile. Podemos simplesmente carregar o ficheiro DGN, filtrar as geometrias, e aplicar depois a simbologia que queremos. Será necessário converter quando, por exemplo, quisermos converter uma série de ficheiros DGN  num único shapefile com toda a informação (ou para outro formato como PostGIS ou SpatiaLite).

O caso DWG

Este é o pior formato de informação geográfica do mundo. Ponto.

Além de ser alterado a cada 3 anos, é completamente fechado, isto é, para poder ler e escrever este formato é necessário pagar a terceiros, como a Autodesk ou a Open Design Alliance. A propósito da ODA e da má fama do DWG, podem ler esta novela espantosa relatada pelo 1º presidente desta ilustre fundação. Mas pode ser que as coisas estejam a mudar. Recentemente, a ODA chegou a acordo com a Autodesk e lá resolveram as disputas sobre marcas comerciais, e por coincidência (ou não) em Junho publicaram as especificações actualizadas que desenvolveram para ler e escrever DWG. É melhor aproveitar e fazer o download, não vá a situação alterar-se… Estas especificações têm sido insuficientes para criar programas que consigam escrever ficheiros DWG válidos, mas pelo menos para ler estes ficheiros já foram suficientes. Esta nova actualização não sei se virá alterar esta situação, mas terá nova informação sobre o formato DWG 2010…

Não vou alongar-me mais sobre o formato, interessa apenas frisar que até agora o software Open Source teve de criar bibliotecas para ler (ou escrever) ficheiros DWG fazendo um enorme esforço de “reverse engineering”. Que além de ser um trabalho muito pouco interessante, tem de ser revisto a cada 3 anos.

Assim, o QGIS não lê DWG. É possível que o venha a fazer no futuro próximo, havendo avanços no OGR nesse sentido. A ver vamos…

Mesmo a terminar este assunto, tenho de referir que o gvSIG lê DWG até à versão 2004…

Conclusão

Dadas as dificuldades actuais de interoperabilidade do formato DWG, este não é viável de momento com QGIS.

A opção DGN é muitíssimo funcional, e até muito fácil de trabalhar no QGIS. Para utilizadores de Microstation é óptimo. Para utilizadores de AutoCAD há a possibilidade de exportar para DGN a partir do AutoCAD 2008. Para os outros produtos baseados em DWG/DXF já não se pode dizer o mesmo.

Finalmente, o formato DXF é de momento uma má opção, a não ser que façamos a conversão pela linha de comando do OGR para shapefile ou semelhante. Mas espera-se em breve ter no QGIS um suporte ao nível do DGN. Mesmo assim, também obriga à exportação para DXF (a partir do formato CAD nativo), sendo um passo extra que é mais uma pedra na engrenagem para os técnicos CAD.

Se souberem de outras possibilidades aproveitem a secção de comentários.

Até breve.

Partilhar

Parece-me que esta venda até foi das melhores coisas que se podiam esperar de um “grupo de investidores”. Afinal venderam a Intergraph a uma empresa que até aparenta ter um interesse “legítimo” nos produtos e capacidades da Intergraph. As opiniões mais pessimistas não se verificaram, quando temiam a revenda das peças mais apetitosas da Intergraph e a dispersão das restantes, na procura de lucro, acabando de vez com esta empresa emblemática. Desta vez a venda parece fazer sentido dada a área de negócio da Hexagon.

Quanto a nós, utilizadores SIG, o que significará isto? Qual será o futuro do GeoMedia? Ou do ImageStation? Ou do novo produto para SDI’s (IDE’s). Ou de todos os outros produtos virados para as Utilities e Água?

A ver vamos… comentários apreciam-se.

Partilhar

Para quem não sabe, a MetaCarta é uma empresa privada nos EUA, que se especializou em software para a localização geográfica de conteúdos, dirigido especialmente ao mercado de agências noticiosas/jornais. Mas é também a empresa onde se originaram alguns produtos notáveis Open Source na área SIG, sendo o mais difundido o OpenLayers, inicialmente desenvolvido por Christopher Schmidt, para além do FeatureServer, do TileCache, e ainda o WPServer (servidor WPS da OGC). Christopher é/tem sido extremamente activo no suporte às comunidades em redor destes produtos, e foi nomeado “membro gestor” (board member) da OSGeo, a fundação internacional para o desenvolvimento colaborativo de software Open Source na área SIG.

Para além das reflexões sobre os objectivos na base desta decisão, parece-me que poderá haver implicações nos produtos desenvolvidos pelo Christopher Schmidt. Teremos de aguardar para ver o que sucederá. Mas, para já a reacção do Christopher parece entusiástica – MetaCarta Acquired by Nokia. Na verdade, sendo Open Source, a liberdade dos produtos não está em causa. O que falta saber é se o Christopher continuará a poder oferecer-nos o seu entusiasmo fantástico. Esperemos que sim!

Partilhar