QGIS – Revisitando ficheiros DXF

Publicado em 26 de Março de 2013 em CAD and SIG. 1 Comment Tags: , , .

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.

Sucede que, não sei bem a partir de que momento, o QGIS perdeu aqui alguma funcionalidade. Se por um lado consegue ler ficheiros DXF modernos, o facto é que junta todos os vectores num único layer sem simbologia:

image

Um ficheiro DXF lido no QGIS – um único layer sem simbologia

O truque para corrigir esta situação, e que funcionou em tempos, era definir uma query para limitar o tipo de geometria a um único tipo: pontos, linhas ou polígonos. Desta forma, já o QGIS conseguiria aplicar uma simbologia e mostrar os vectores do dxf no mapa.

Acontece que, nas versões mais recentes, o QGIS crasha ao definir uma query para um dxf… uma questão em aberto que podemos acompanhar no ticket respectivo - uma das vantagens de trabalhar com open source.

Não querendo desistir ou aguardar que a versão 2.0 seja lançada, podemos usar a seguinte solução que passa pela utilização de ficheiros virtuais do OGR e da sua implementação SQL que permite filtrar o tipo de geometria através de um campo virtual designado OGR_GEOMETRY.

Assim, criamos um ficheiro VRT que aplica um filtro ao tipo de geometria. Por exemplo, para o tipo Linhas criamos um ficheiro chamado dxf_linhas.vrt com este conteúdo:

<OGRVRTDataSource>
<OGRVRTLayer name="dxf_linhas">
<SrcDataSource relativeToVRT="1">T34834D01-01-R0.dxf</SrcDataSource>
<GeometryType>wkbLineString</GeometryType>
<LayerSRS>EPSG:27493</LayerSRS>
<SrcSQL>SELECT * FROM entities  WHERE OGR_GEOMETRY='LINESTRING'</SrcSQL>
</OGRVRTLayer>
</OGRVRTDataSource>

O essencial deste ficheiro é:

  1. o nome do ficheiro original (T34834D01-01-R0.dxf); o ficheiro vrt deve estar na mesma pasta que este dxf;
  2. o tipo de geometria do tema (wkbLineString);
  3. o sistema de coordenadas que, embora não seja necessário, aproveitamos para definir;
  4. o filtro que selecciona o tipo de geometria que queremos (OGR_GEOMETRY=’LINESTRING’)

Se no QGIS carregarmos este ficheiro vrt ele surge perfeito no mapa e podemos simbolizá-lo por layer ou outro campo, e até excluir vectores que não interessem:

image

DXF carregado no QGIS usando um ficheiro .VRT

Para Polígonos o ficheiro vrt seria:

<OGRVRTDataSource>
<OGRVRTLayer name="dxf_poligonos">
<SrcDataSource relativeToVRT="1">T34834D01-01-R0.dxf</SrcDataSource>
<GeometryType>wkbPolygon</GeometryType>
<LayerSRS>EPSG:27493</LayerSRS>
<SrcSQL>SELECT * FROM entities  WHERE OGR_GEOMETRY='POLYGON'</SrcSQL>
</OGRVRTLayer>
</OGRVRTDataSource>

E para Pontos:

<OGRVRTDataSource>
<OGRVRTLayer name="dxf_pontos">
<SrcDataSource relativeToVRT="1">T34834D01-01-R0.dxf</SrcDataSource>
<GeometryType>wkbPoint</GeometryType>
<LayerSRS>EPSG:27493</LayerSRS>
<SrcSQL>SELECT * FROM entities  WHERE OGR_GEOMETRY='POINT'</SrcSQL>
</OGRVRTLayer>
</OGRVRTDataSource>

E agora é só esperar que o QGIS 2.0 chegue!

Bom mesmo era um plugin que automatizasse este processo… ora aqui está uma ideia!

Para terminar, apenas para referência futura: o conversor de dwg->dxf que uso actualmente é o Teigha File Converter, porque é gratuito, relativamente compacto, e permite converter pastas com dwg’s de uma só vez. (não é open source, apenas “free as in free beer”)

OSM – We are not alone!

Publicado em 8 de Janeiro de 2013 em Open Source, SIG and WebGIS. 0 Comments Tags: .

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?? ;)

PostgreSQL e ESRI – parte 4

Publicado em 13 de Dezembro de 2012 em Avançado, Open Source and PostgreSQL. 2 Comments Tags: , , , .

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 cruso 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.

Mas porque insistem!!??

Esta é uma questão velha. Já há muitos anos que a Oracle suporta geometrias, e a ESRI também já há anos que suporta em bd’s Oracle este esquema de 2 possibilidades. A vantagem maior em usar geometrias em formatos “nativos” das bases de dados é o acesso  a um portefólio de software compatível com esses formatos, dentro e para além da esfera SIG. Por exemplo, podemos desenvolver aplicações Oracle que são 99% formulários, mas que mostram de vez em quando uns mapas, sem software adicional. Há software de BI que também faz a representação em mapas dos dados que analisa. E por aí fora. Claro que na esfera SIG é onde está a verdadeira acção. E usar o formato ESRI limita-nos a usar ArcGIS, no desktop e no servidor. Mesmo com a enorme evolução que a ESRI conseguiu no acesso e interoperabilidade via SQL, a verdade é que, para ver, editar e analisar os dados geográficos, se estes estão no formato ESRI então esqueçam outras opções…

Por tudo isto, genericamente, optar pelo formato geográfico nativo da nossa bd é uma opção lógica.

O problema está nos detalhes… por exemplo, quando em 2004 pensei em usar o formato Oracle Spatial, vi com alguma surpresa uma perda de desempenho em cerca de 30% no ArcMap. Depois havia uma série de operações manuais a fazer para manter a compatibilidade entre ESRI-Oracle. E, assim, lá abandonei a ideia.

Anos mais tarde, voltamos ao mesmo. Há a necessidade de mudar de bd. O que escolher?

Por um lado, a ESRI tem um formato próprio com um excelente suporte SQL que segue de perto os standards OGC e ISO. Por outro, o PostgreSQL e PostGIS são uma aposta mais que validada por todo o mundo, e têm o maior portefólio de software SIG compatível. Ponto parágrafo. A escolha fica óbvia. Se vamos mudar, mudamos para o melhor que há! (e ainda por cima é grátis!)

Migrando, round 1

No último ano temos feito um esforço continuado em passar tudo o que temos em Oracle para PostgreSQL e PostGIS. Isto implica dados (geográficos e outros), mas também views, funções PL/SQL (dialecto Oracle), projectos e lyr’s ArcMap, e finalmente, aplicações web. A coisa não é fácil. Migrar de bd é uma maratona…

Pelo lado do pgsql tudo tem corrido 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 amontoar-se…

Começou com surpresas como o facto de não ser possível apagar renomear 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 renomear tabelas espaciais…??? Ora vejam lá esta pérola:

image

… então isto quer dizer que programar o ArcCatalog para importar, converter, reprojectar, não teve dificuldade. Agora, renomear tabelas e executar um comando adicional SQL para remover um registo da tabela geometry_columns, isso já é demasiado complexo… enfim, é uma “feature” e não um bug. Vamos lá tomar chá calmante e continuar.

…round 2

Depois existe a questão do desempenho. Era espectável alguma perda de desempenho, tudo certo. Mas usar o tipo de geometria postgis é “apenas” 4,75x mais lento no arcmap do que usar a geometria da esri… pelo menos em algumas das nossas fc’s. Imaginem: ligamos um layer no mapa e em vez de 8 segundos, esperamos 38 segundos. Por 1 layer.

Levámos a experiência mais longe. Montámos um mapa típico do nosso dia-a-dia, usando feature classes nos 2 formatos. E medimos o desempenho…

agspreview_tipo_st agspreview_tipo_pg
Geometria ESRI – 4,93 seg Geometria pg – 10 seg

… “portanto, 3 mil milhões de contos, 3 vezes 18, portanto…”

… mas isto é 2x mais lento!!

Bom, fomos experimentar com o QGIS, não fosse a razão estar num problema da bd. E verificámos que o QGIS é muito mais rápido do que o arcmap nesta situação (já vamos ver). Mas o arcmap é ainda mais rápido se usarmos geometria esri. Bizarro… (Há aqui alguma coisa que a esri está a fazer bem com a sua arquitectura e que valia a pena analisar. Talvez compressão das geometrias?)

Como o problema era então do arcmap contactámos o suporte. A 1ª reacção da esri foi informar-nos que era uma limitação do postgis… mais um chazinho para os nervos.

Até que lhes enviei o log do pgsql. O problema está na query que o arcmap emite – o qgis usa um sql mais eficiente. Toda a diferença nos tempos medidos encontra-se na query. O “rendering” na aplicação desktop nem entra na equação. Lá fomos informados que era esperada uma quebra de desempenho, mas que dadas as diferenças entre os 2 formatos iriam registar um “enhancement request”. Óptimo. Para o futuro.

Só para terminar este round, montámos um projecto igual em QGIS – os mesmos layers, as mesmas queries, as mesmas labels, os mesmos símbolos, etc. Usámos uma área de mapa igual, e a mesma escala. Usámos um pequeno comando na consola de Python para medir exactamente o tempo de desenho que estávamos a ver. Deixo aqui apenas a imagem… conseguem descobrir quantos segundos levou o QGIS a gerar o mesmo mapa? Com estes números, nem arrisco contas de cabeça ;)

qgis_preview_timer

Pois é… a vida não está fácil…

… round 3

Os bugs…

Aguardámos com alguma esperança a versão 10.1 SP1 do ArcGIS. Além das novas funções, poderiam existir optimizações que nos fossem úteis.

Mas o que apareceu foi um novo bug: quando apagamos uma feature class com geometria pg, 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 e há um “workaround”. A solução é voltar a usar conexões de serviço (3 tier) em vez de conexões directas, para gerir geodatabases que tenham fc’s com geometria postgis. Para apenas leitura das mesmas parece ser seguro usar conexões directas…

E finalmente, a cereja no topo do bolo, o último bug que encontrámos, e que está em análise na esri há 3 semanas, é um polígono que simplesmente é impossível de importar para a geodatabase em formato postgis… a conexão à geodatabase simplesmente desiste, emitindo um último suspiro enigmático de “I/O Network error”.

Este polígono que é importado perfeitamente se usarmos a geometria da esri… e claro, importada também sem problemas para o PostGIS com outras ferramentas…

Aqui, continuamos sem solução. Editámos o polígono manualmente, e fomos tentando importar até o erro desaparecer. Mas, por agora, não sabemos se outras geometrias “tóxicas” irão surgir, já que ainda não existe uma explicação para o fenómeno.

Conclusão (por agora)

Portanto, qual é o saldo? Continuamos a pensar que vale a pena insistir na migração para o formato pg pelo valor que o postgis representa. Abre os nossos dados a um universo de opções, dentro e fora da esfera SIG.

Neste momento decidimos manter 2 cópias dos dados: uma com geometria esri para melhor desempenho no arcgis, e outra cópia com geometria pg para usar com software não-esri.

Isto obriga-nos a um esforço adicional para manter as cópias sincronizadas, que dispensaríamos de bom grado. Para já, usamos scripts python de ArcGIS para o efeito. Afinal, a melhor ferramenta para converter dados em formato esri ainda é o arcgis.

Mas queremos simplificar e ficar com apenas 1 cópia, mesmo sacrificando algum desempenho no arcmap… teremos de esperar até que esta diferença seja aceitável para nós.

Nota final

Há algumas diferenças relativas ao sql que são importantes na recriação de projectos ArcMap e de ficheiros lyr. Mas é tudo muito parecido com Oracle. Temos um script python baseado nos exemplos da esri, que altera as definition queries e as queries sql das classes de labels, e ainda as próprias 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. De resto, não notamos grandes diferenças no sql.

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

ArcSDE e PostGIS – caracteres pt

Publicado em 6 de Fevereiro de 2012 em PostgreSQL. 2 Comments Tags: , .

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_

Vamos ao GeoCamp

Publicado em 20 de Setembro de 2011 em Sem categoria. 0 Comments Tags: , .

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

QGIS e conflitos com DLLs Qt

Publicado em 19 de Setembro de 2011 em Inicial, Open Source and SIG. 4 Comments Tags: , .

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.

Usa a Comunidade, Luke

Publicado em 6 de Abril de 2011 em Gestão, Inicial and Open Source. 0 Comments Tags: , , , .

Nota: Este artigo foi publicado originalmente no último iGov DOC, sobre SIG na Administração Pública, páginas 21-23. Resisti à tentação de fazer alterações que agora me parecem óbvias, e apenas corrigi algumas gralhas. (Aqui no blog fica pesquisável na web…)

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.

OSM: quem anda aqui?

Publicado em 6 de Março de 2011 em Dados, Gestão, Inicial and Open Source. 3 Comments Tags: , , , , .

A cidade de Beja há um ano atrás não tinha quase presença no OpenStreetMap. Hoje deve ser uma das cidades mais completas… (é verdade que também é das mais pequenas, mas isso agora não interessa nada!)

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).

image

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

image

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.

Gerir Projectos de Código

Publicado em 18 de Dezembro de 2010 em Gestão and Intermédio. 2 Comments Tags: , .

Este artigo é um pouco periférico ao assunto central deste blog – a gestão de versões em projectos de programação.

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.

Mas quem descobre estas coisas?

Publicado em 3 de Dezembro de 2010 em SIG. 0 Comments

Há muito que não publico nada, indo contra as minhas próprias regras do PlanetaSIG… mas não resisto a deixar aqui um repost!!

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):