opus SIG

Notas sobre o Workshop Open Street Map

2012-02-18T07:20:00.002-08:00

Conforme aqui referido anteriormente, decorreu nos dias 11 e 12 de Fevereiro, em Torres Vedras, nas instalações da ALT - Sociedade de História Natural, um Workshop em Open Street Map (OSM) integrado na iniciativa "Vamos mapear Portugal" e orientado pelo Victor Ferreira, veterano do OSM e membro conselheiro da OSGeo-PT.

Embora já haja algum historial de OSM Partys em Portugal, tanto quanto sei foi a primeira vez que se testou um modelo misto - uma componente de aprendizagem e uma outra de aplicação, idêntica a qualquer outra OSM Party.

O workshop contou com 9 intrépidos participantes que corajosamente enfrentaram o frio da rua (e da sala) com vista a melhorar o mapa de Torres Vedras. A animação que aqui deixo, preparada pelo Fernado Ribeiro, dá uma boa ideia dos resultados práticos do workshop:

Para quem quiser experimentar este modelo de convívio OSMiano, aqui deixo algumas notas sobre a forma como correu e as ferramentas e recursos que foram utilizados.

A estrutura do workshop obedeceu a uma lógica de conceito-aplicação. O que é isso? É uma forma diferente de dizer teórico-prático, que se traduziu num primeiro momento teórico (origens, funcionalidades e aplicações do projecto) e num segundo momento de prática (recolha e edição de dados).

Foi dada grande ênfase à qualidade dos dados, ênfase essa que se pode resumir em três máximas:

1 - Digitalizar/vectorizar tendo em atenção a integridade topológica (garantir as conexões);

2 - Utilizar o mínimo de nós possível por segmento de linha (por exemplo, se uma estrada é uma recta perfeita basta dois nós - um no início e outro no fim da linha);

3 - Utilizar as tags (identificadores qualitativos das geometrias) de forma coerente, recorrendo se necessário ao wiki OSM.

Foram também abordadas algumas técnicas e truques úteis para registo de dados no terreno, como por exemplo, sentidos de trânsito e toponímia, aspectos postos em prática nas ruas de Torres Vedras:

Relativamente às ferramentas foram testados dois editores: JOSM e o editor we Potlach, (disponível no portal OSM no separador Edit), tendo ficado evidente que o editor JOSM é uma opção melhor devido às tags que permite e também por disponibilizar centenas de plugins que facilitam o trabalho do mapeador.

Para além da edição em si foram também demonstradas algumas ferramentas interessantes que se desenvolveram em torno do projecto OSM:

OSM Browser - permite pesquisar os dados OSM por tema e filtrar os resultados por zonas;

ITOWorld - disponibiliza várias ferramentas para OSM, nomeadamente pesquisa de edits por utilizador, o que é particularmente útil para encontrarmos outros mapeadores da nossa área de trabalho e assim coordenar esforços;

MapOS Matic - uma aplicação web muito interessante que produz um mapa quadriculado com toponímia indexada a essa mesma quadrícula;

Walking Pappers - ferramenta essencial e muito utilizada no workshop. Dá a possibilidade de imprimir numa folha um segmento da zona que vamos mapear e posteriormente utilizar as anotações e mapa que desenhámos nessa folha para digitalizar e enviar informação para o servidor OSM. Tem a grande vantagem de ser uma forma simples e barata de dispensar o tradicional uso do GPS, tornando assim a actividade mapeadora extremamente acessível do ponto de vista financeiro.

Finalmente resta-me referir o ambiente descontraído e o convívio que disfarçaram o frio glaciar que se viveu. Uma experiência a repetir e que recomendo vivamente!

N.º 4 da revista FOSSGIS Brasil

2012-01-31T16:03:00.017-08:00

Saíu o número 4 da revista FOSSGIS Brasil. O destaque desta edição vai para os metadados - um artigo da autoria de George Silva e André Mendonça que já tive a oportunidade de ler e recomendo. Aqui fica então o link para descarregarem a revista (clicar na imagem).

Workshop Open Street Map

2012-01-26T08:21:00.000-08:00

Irá decorrer, nos dias 11 e 12 de Fevereiro, em Torres Vedras, um workshop dedicado ao Open Street Map (OSM) - projecto que pretende mapear todo o globo com recurso aos contributos de cidadãos de todo o mundo.

O workshop, integrado na iniciativa "Vamos mapear Portugal", é promovido pela OSGeo-PT e pela ALT - Sociedade História Natural (ALT-SHN) que cederá a biblioteca para os trabalhos de edição e sessões teóricas.

O modelo do evento é misto: por um lado é uma OSM party, mas por outro tem uma componente de aprendizagem (daí ser workshop) que pretende que todos os participantes saiam deste fds de convívio com competência e autonomia para começar a mapear.

Há um limite máximo de 16 participantes (contingências da sala).

Mais informações e incrições aqui

wxGIS 0.4 - alternativa aberta ao ArcCatalog

2012-01-20T18:32:00.000-08:00

Foi lançada a versão 0.4 do wxGIS, um software muito útil que permite navegar pelas directorias onde temos armazenados os nossos dados geográficos e visualizá-los e manipulá-los de forma rápida e intuitiva. A grande vantagem de uma aplicação deste género é que permite visualizar e organizar os nossos dados sem precisarmos de os abrir no nosso software SIG Desktop.

O wxGIS é distribuído com uma licença GNU GPL v3, e tem na sua base a inultrapassável e insubstituível biblioteca GDAL - Geospatial Data Abstraction Lybrary, uma colecção de drivers de uso livre (dentro dos termos da licença MIT/X) para abrir, criar e manipular uma longa lista de formatos raster e vectorial.

Uma das características simpáticas do wxGIS é o facto de não requerer instalação, e por isso mesmo ser altamente portátil: basta descomprimir o arquivo .zip disponível na página do projecto para a directoria que desejarmos ou para um pen/disco USB e podemos correr o programa abrindo o aplicativo wxGISCatalog. Existe igualmente uma versão para Linux, mas sem a portabilidade, ou seja tem de ser instalada e não corre a partir de uma simples pen.

Vejamos algumas das coisas interessantes que este programa pode fazer.

INTERFACE

A interface é simples e intuitiva. Existem três paineis: o da esquerda permite navegar pelas directorias do nosso computador; o do meio serve para visualizar os dados e o o da direita apresenta ferramentas e opções adicionais a partir das quais podemos fazer transformação de coordenadas, derivar estatísticas entre outras coisas

VISUALIZAÇÃO DE DADOS

Para visualizar dados basta percorrer as directorias - no painel da esquerda - e clicar no ficheiro que queremos visualizar. No caso dos ficheiros vectoriais (testei com shapefiles; .kml e .dxf), temos a possibilidade de ver as geometrias ou a tabela de atributos bastando para isso escolher a opção Table View (no fundo do painel de visulização). Existe também uma barra de ferramentas de visualização que permite, se estivermos a visualizar no modo Geographic View, fazer zoom, pan e identificar as entidades contidas no vector.

REPROJECTAR (mudar o sistema de coordenadas de um ficheiro)

A reprojecção é igualmente um processo simples mas por enquanto apenas está disponível para vectores. Basta escolher a opção correspondente no painel de ferramentas e fornecer as informações necessárias na janela de diálogo que irá aparecer: ficheiro de entrada (2); Ficheiro de saída (3) e pelo meio escolher o sistema de coordenadas desejado.

ESTATÍSTICA

A partir de Data Management Tools, no painel de ferramentas, temos acesso a algumas ferramentas de estatística. Na minha opinião esta operação poderia ser mais linear uma vez que obriga a dois passos distintos: computar as estatísticas e visualizar o resultado. Começemos por calcular as estatísticas:

Para vermos o resultado desta operação são então necessários mais alguns passos. Primeiro, no painel Toolbox, há que clicar no separador Tool Execute View, seguidamente clicar duas vezes no último Compute statistics - por baixo de Tool Name. Finalmente é aberta uma nova janela e aí, para finalmente vermos as tão desejadas estatísticas, temos ainda de clicar num novo botão!! Definitivamente, isto poderia ser muito mais simples. Porque não aparecer logo o resultado assim que a operação terminasse? Fica a sugestão.

CONVERSÃO DE FORMATOS VECTORIAIS

Já no campo das opções de conversão o wxGIS prima pela simplicidade. No caso dos vectores é possível efectuar operações de exportação entre os seguintes formatos: Shapefile; KML; KMZ MapInfo File e AutoCAD DXF. Para tal basta, no painel das directorias, clicar com o botão direito do rato sobre o ficheiro vectorial que queremos exportar para outro formato e fornecer o input e o output desejados na janela que entretanto surgirá.

OUTRAS FUNCIONALIDADES

Explorando o painel das ferramentas é possível visulizar outras ferramentas interessantes. Destacaria duas. Uma permite exportar para shapefile de pontos os vértices de um outro ficheiro vectorial, e a outra grava para um ficheiro de texto as coordenadas de um shapefile.

Finalmente, quando clicamos duas vezes sobre um determinado ficheiro abre-se uma janela com informações sobre esse mesmo layer - sistema de coordenadas, extensão, resolução e número de células (no caso dos rasters) entre outras coisas.

LIMITAÇÕES

O wxGIS parece ser um projecto com pernas para andar, e julgo que vale a pena experimentar e investir um pouco neste programa. Não obstante, tendo em conta que é sum projecto recente, tem ainda algumas limitações e arestas por limar:

Alguns formatos ainda não são suportados. Exemplos mais flagrantes; GPX; MrSID e ECW;

Durante o teste o programa crashou algumas vezes;

Fraca documentação e material de apoio (contributos precisam-se!)

Já existe uma versão em Português mas que precisa de ser limada (uma contribuição minha que será suficiente para ajudar quem não domina o inglês mas que está ainda muito imperfeita... Fica o desafio!)

No caso das operações de reprojecção de coordenadas estamos limitados à lista de sistemas de coordenadas que vem de raíz. Apesar de os sistemas de coordenadas serem expressos em linguagem WKT da OGC, não é possível importar os parâmetros daqui por exemplo.

Não é possível reprojectar mais do que um ficheiro de uma só vez (batch convert)

No dia em que o wxGIS aumente o leque de formatos em que é possível visualizar e exportar mais formatos, será sem dúvida um programa quase indispensável. Quem quiser contribuir para o desenvolvimento deste projecto, experimente e envie feedback para a equipa de desenvolvimento.

Interpoladores II - QGIS Interpolation Plugin (IDW)

2011-12-13T18:30:00.000-08:00

No primeiro post desta série dedicado ao Interpolation Plugin do Quantum GIS, a interpolação TIN obteve resultados melhores que a interpolação IDW. No entanto, como foi sublinhado, esses resultados foram condicionados pelo facto da interpolação ter sido feita com base em curvas de nível a partir das quais foram derivados os pontos para interpolação. Este segundo estudo irá testar o interpolador IDW para a obtenção de um Modelo Digital de Elevação (MDE) a partir de um conjunto de pontos cotados e não a partir de curvas de nível.

De forma a testar a influência do tipo de paisagem a modelar e a regularidade ou irregularidade de dispersão de pontos no Modelo Digital de Elevação (MDE) segui, no essencial, a mesma metodologia que adoptei anteriormente:

Objectivos e Metodologia

O principal objectivo deste segundo estudo é aferir em que circunstâncias a interpolação IDW poderá ser mais indicada que a interpolação TIN. Para tal confrontou-se o melhor interpolador TIN - segundo o teste anterior - com vários parâmetros de interpolação IDW. O segundo objectivo é perceber até que ponto a regularidade ou irregularidade dos dados de entrada podem influenciar a performance da interpolação.

Mais uma vez, e considerando que os resultados obtidos a partir de interpolação são altamente influenciados pelo tipo de terreno que se está a modelar, foram considerados dois tipos de paisagem: Falésias e Colinas Aplanadas - cuja extensão é exactamente a mesma do estudo anterior de modo a permitir uma comparação de resultados mais segura.

O seguinte esquema ilustra metodologia seguida. A partir de MDE com resolução espacial de 4,12m - um para cada tipo de paisagem, extraí pontos regulares e pontos irregulares ou nuvens de pontos. Cada ponto herdava a cota correspondente no raster do MDE a partir do qual foi extraído. Seguidamente dividi estes conjuntos de dados em dois subconjuntos com sensivelmente o mesmo número de pontos: um conjunto seria utilizado para operações de interpolação, e o segundo para testar o nível de precisão da interpolação. Finalmente procedeu-se à quantificação.

Para cada um dos tipos de paisagem foram testados duas vezes (uma primeira com base em pontos regulares e uma segunda com base em pontos irregulares) os seguintes interpoladores:

- TIN Linear (a partir dos pontos extraídos das curvas de nível)

- TIN Clough-Toucher ou cúbica - modo stuctured lines (no caso da paisagem do tipo colinas aplanadas - foi o melhor tipo de paisagem no teste anterior, que se baseava em curvas de nível)

- TIN Clough-Toucher modo break lines (no caso da paisagem tipo falésias - foi o melhor interpolador para este tipo de paisagem no teste anterior, que se baseava em curvas de nível)

- IDW Coeficiente 2, 4, 6, 8 e 10

Operações

Para obter os dados necessários foram utilizadas as seguintes ferramentas:

GDAL Regular Points e Random Points - para obter os pontos de teste e de interpolação

QGIS Point Sampling Tool - extrai, para a tabela de atributos de um tema de pontos, os valores de célula dos rasters que ocupem a mesma área dos pontos. O resultado é guardado como um novo Shapefile de pontos;

QGIS Interpolation Plugin - para obter os MDE;

OPEN OFFICE Calc - operações de quantificação a partir do ficheiro .dbf do shapefile de pontos resultante das operações com Point Sampling Tool

Resultados

No caso das colinas aplanadas, a interpolação IDW obteve resultados melhores que a interpolação TIN, uma melhoria que é particularmente evidente no caso no caso dos MDE obtidos com base em pontos irregulares onde a interpolação IDW com coeficiente 6 obteve resultados 61,5% mais precisos que a melhor interpolação TIN. A figura seguinte mostra a média de erro, em metros, associada a cada tipo de interpolação. A vermelho destaco os interpoladores que obtiveram melhores resultados:

Já no caso das falésias, a interpolação TIN modo break lines, à semelhança do que já se havia registado no teste anterior, continua a obter resultados muito melhores - independentemente da regularidade ou aleatoriedade dos pontos de entrada. A interpolação IDW fica muito atrás, embora não tanto como nos MDE obtidos a partir de curvas de nível.

Análise

Estes resultados parecem demonstrar que a irregularidade dos dados de entrada parece favorecer a interpolação IDW nos casos de paisagens que não apresentem acidentes topográficos acentuados como colinas, planícies ou vales suaves. Nestes casos, um coeficiente entre 4 e 8 é o ideal.

Já no caso de terrenos acidentados, como é o caso das falésias, a interpolação TIN Cubic em modo break lines é sem dúvida a melhor escolha. E digo sem dúvida porque os resultados obtidos neste segundo teste são consistentes com os obtidos no primeiro teste em que, para o mesmo tipo de paisagem mas tendo por base curvas de nível e não nuvens de pontos, a interpolação TIN Cubic em modo break lines foi igualmente a que obteve melhores resultados.

O que parece ser evidente é que quanto mais dispersos e aleatórios forem os dados de entrada melhores resultados se obtém com a interpolação IDW e que, pelo contrário, a regularidade parece beneficiar a interpolação TIN. Deixo-vos com um último quadro que sintetiza os resultados destes dois estudos e que espero que seja útil a toda a comunidade e possa ser uma base para fundamentar escolhas quando se utiliza o plugin de interpolação do Quantum GIS.

Interpoladores I - QGIS Interpolation Plugin (TIN e IDW)

2011-12-04T15:59:00.000-08:00

Um dos plugins mais interessantes que o Quantum GIS (QGIS) dispobibiliza é o plugin Interpolation, desenvolvido por Marco Hugentobler. Este plugin permite criar um modelo digital de elevação (MDE - um mapa em que o valor de cada célula representa a altitude do terreno) a partir de valores de altitude (Z) que podem estar contidos numa camada vectorial (layer) de pontos ou de linhas. Os valores das células são obtidos a partir de um de dois interpoladores que a ferramenta disponibiliza: TIN (Triangular Irregular Network) e IDW (Inverse Distance Weighting).

Embora o plugin seja extremamente fácil de usar, o modo de tirar o melhor partido possível desta ferramenta é altamente condicionado pelo tipo de paisagem que se está a modelar. Este post é um estudo comparativo dos resultados altimétricos obtidos por interpolação para dois tipos básicos de terreno: acidentado/falésia e aplanado/colinas.

Objectivos e Metodologia

O objectivo deste estudo é comparar os valores obtidos pela interpolação com os valores supostamente reais de altitude. Este comparativo nasceu da necessidade que senti de avaliar a fiabilidade dos modelos de risco paleontológico que desenvolvi para a ALT - Sociedade de História Natural. Estes modelos têm como elemento chave o declive (slope), que é calculado com base num MDE que é precisamente o que o plugin Interpolation permite fazer.

Na impossibilidade de verificar os resultados no terreno com uma estação total, optei por basear este estudo em mapas topográficos de grande escala. Os testes foram feitos com base em excertos do Plano de Ordenamento da Orla Costeira (POOC) disponibilizado pelo Instituto da Água à escala 1:2000, com curvas de nível/isolinhas com uma equidistância de 2m.

Depois de devidamente georeferenciados (Datum Lisboa Militar - EPSG:20790), foram selecionadas duas zonas cada uma com 30.0000m2 (100x300m) - numa dessas zonas predominam as falésias e noutra há uma maior incidência de colinas aplanadas.

Seguidamente foram vectorizadas todas as curvas de nível. Estas curvas foram divididas em dois conjuntos - curvas de nível para interpolação e curvas de nível de teste. Todas estas curvas de nível foram depois utilizadas para derivar pontos, com base no atributo Z, que distam no máximo 2m entre si. A partir dos pontos derivados do conjunto de curvas de nível para interpolação, e para os dois tipos de paisagem, foram testadas as seguintes configurações de interpolação, sempre com uma resolução de célula de 0,33x0,33m:

- TIN Linear (a partir dos pontos extraídos das curvas de nível)

- TIN Linear (a partir dos pontos extraídos das curvas de nível - modo structured lines)

- TIN Linear (a partir dos pontos extraídos das curvas de nível - modo break lines)

- TIN Clough-Toucher ou cúbica (a partir dos pontos extraídos das curvas de nível)

- TIN Clough-Toucher ou cúbica (a partir dos pontos extraídos das curvas de nível - modo stuctured lines)

- TIN Clough-Toucher ou cúbica (a partir dos pontos extraídos das curvas de nível - modo break lines)

- IDW Coeficiente 1 (a partir dos pontos extraídos das curvas de nível)

- IDW Coeficiente 2 (a partir dos pontos extraídos das curvas de nível)

- IDW Coeficiente 4 (a partir dos pontos extraídos das curvas de nível)

- IDW Coeficiente 6 (a partir dos pontos extraídos das curvas de nível)

(Não será abordada a natureza técnico-teórica de cada um destes interpoladores. Quem quiser aprofundar o assunto sugiro a leitura da dissertação de Marco Hugentobler, disponível aqui)

Os pontos derivados a partir do conjunto de curvas de nível de teste serviram para avaliar o grau de exactidão da interpolação - por outras palavras, comparar o valor do ponto (i.e. 24m) com o valor indicado pelo pixel resultante da interpolação (25,172m) e quantificar a discrepância.

Esta quantificação foi precedida de uma comparação visual entre as curvas de nível originais e curvas de nível obtidas a partir dos vários MDE. Apenas se procedeu à quantificação nos casos em que há uma nítida proximidade entre as duas linhas. Confuso? Talvez o esquema ajude:

A última fase do teste consiste em repetir a metodologia acima apresentada mas desta vez com base num mapa com uma escala mais pequena - 1:25.000 e com curvas de nivel com equidistancia de 10m. Uma vez que a escala é mais pequena, a distância mínima entre os pontos derivados a partir das curvas de nível e a resolução são também maiores (10 e 4,12m respectivamente). Nesta segunda experiência apenas foram testadas as duas melhores configurações de interpolação (segundo o primeiro teste) para cada um dos tipos de paisagem serão experimentadas.

Operações

Para obter os dados necessários foram utilizadas as seguintes ferramentas:

GDAL Georeferencer - georeferenciação dos rasters com as curvas de nível;

GRASS v.to.points - módulo do que permite extrair pontos com base numa distância máxima entre os pontos;

QGIS Interpolation Plugin - para obter os MDE;

GDAL contour - gera curvas de nível a partir dos valores de célula de um raster (neste caso dos MDE gerador pelo Interpolation Plugin). Estas curvas de nível serviram para comparação visual com as originais, vectorizadas a partir do raster do POOC;

QGIS Point Sampling Tool - extrai, para a tabela de atributos de um tema de pontos, os valores de célula dos rasters que ocupem a mesma área dos pontos. O resultado é guardado como um novo Shapefile de pontos;

OPEN OFFICE Calc - operações de quantificação a partir do ficheiro .dbf do shapefile de pontos resultante das operações com Point Sampling Tool

Resultados

Para ambos os tipos de paisagem, com uma resolução de 0,33m, a interpolação TIN obteve resultados consideravelmente melhores que a interpolação IDW. No caso das colinas, a interpolação IDW com um coeficiente de 6 obteve valores de exactidão razoáveis mas ainda assim longe dos alcançados pelos outros interpoladores.

No caso da paisagem mais suave - as colinas aplanadas - os três interpoladores que após análise visual justificaram uma análise quantitativa foram os interpoladores TIN Cubic (modo Break e Structured Lines) e IDW com um coeficiente de 6. A interpolação TIN Cubic nas variantes Break e Structured Lines obteve resultados muito próximos um erro médio de 0,64 e 0,60m por por ponto, respectivamente (uma diferença de precisão de apenas 6,25%):

Já no caso das falésias os dois melhores interpoladores foram igualmente TIN na variante Linear e Cubic em modo Break Lines. A análise quantitativa revelou que o melhor interpolador é o TIN Cubic em modo Break Lines, que revelou ser 21,5% mais preciso com um erro médio de 0,11m por ponto, enqaunto que TIN Linear registou um erro médio de 0,14m por ponto:

Tal como referi anteriormente, para verificar a consistência destes resultados repetiu-se toda a metodologia utilizando os dois melhores interpoladores mas desta vez sobre uma área maior, com uma equidistância maior entre os pontos e com uma resolução de célula consideravelmente mais alta - 4,12m.

Para a paisagem do tipo colinas, O interpolador TIN Cubic modo Structured Lines continuou a ter resultados ligeiramente melhores - 15,4% mais preciso - que TIN Cubic modo Break Lines:

Já no caso das falésias, o interpolador TIN Cubic modo Break Lines continua a obter melhores resultados que TIN Linear, mas a diferença de precisão entre os dois interpoladores aumentou bastante - a diminuição da resolução e o aumento da equidistância entre os pontos afectou consideravelmente a precisão do interpolador TIN Linear que se revelou 75,6% menos preciso que TIN Cubic modo Break Lines - 2,58 e 0,89m respectivamente:

Análise

Estes resultados indicam que a interpolação TIN Cubic modo Structured Lines é o interpolador mais fiável para obter um MDE de uma zona sem grandes acidentes topográficos.

Já a interpolação TIN Cubic modo Break Lines é a que obtem melhores resultados em zonas de relevo agreste como vales estreitos, ravinas e falésia - fiabilidade que parece ser constante mesmo com resoluções mais baixas.

Contudo há que ter em conta que estes resultados, especialmente os que dizem respeito à interpolação IDW, foram altamente condicionados pelo tipo de dados de entrada - curvas de nível. Se os nossos dados de entrada forem um conjunto de pontos cotados, os resultados da interpolação IDW poderá ser melhor, como veremos no próximo teste.

Estes resultados podem ser considerados válidos se partirem das mesmas permissas deste estudo: informação de Z retirada a partir de curvas de nível e consequentemente os pontos que estiveram na base da interpolação distribuiem-se ao longo de linhas paralelas entre si e não de forma "aleatória" como aconteceria com uma nuvem de pontos cotados. Se a informação Z provier de pontes cotados, a interpolação IDW apresentará resultados mais interessantes como veremos no proximo post.

Formação em Sistemas de Informação Geográfica com Quantum GIS

2011-11-17T07:13:00.000-08:00

Terminou esta semana uma formação introdutória aos Sistemas de Informação Geográfica (SIG) na Escola Profissional Alsud de Mértola. Consistiu num módulo de 25H integrado no curso de Assistente de Arqueólogo (certificação de Nível Secundário). Esta acção foi uma excelente oportunidade para explorar e divulgar algum do bom software aberto que actualmente existe para SIG, e aproveito para deixar aqui umas notas sobre esta experiência na esperança de poder vir a ser útil a outras pessoas, formadores ou não.

O público consistiu num grupo de 13 adultos que nunca tinham tido qualquer tipo de contacto com sistemas de informação geográfica. Optei portanto pelo Quantum GIS por achar que é, actualmente, um dos programas mais amigáveis e fáceis de utilizar.

Tendo em conta as poucas horas disponíveis para o módulo e a ausência de conhecimentos ou contactos prévios com o mundo SIG por parte dos formandos, defini como objectivos de aprendizagem os seguintes pontos:

Compreender o que é "Informação Geográfica"
Distinguir as diferenças entre o modelo raster e vectorial;
Explorar operações de simbologia e etiquetas;
Fontes de dados online (incluindo serviços WMS e WFS);
Elaborar mapas e criar esquemas de impressão.

Dividi o módulo em três momentos: introdução teórica (3h), exercícios práticos com o apoio de um guião e dados fornecidos por mim (16H) e um projecto final (6H) que consistiu na elaboração de um mapa simples.

No fim do módulo foi distribuído um questionário de avaliação do qual destaco as 5 perguntas directamente relacionadas com o QGIS (clicar para aumentar):

Os resultados do questionário justificam alguns comentários: embora a maioria considere que o nível de dificuldade na aprendizagem do QGIS é razoável (o que me parece natural tendo em conta ter sido o primeiro contacto com um programa SIG), também é verdade que a avaliação global do QGIS é francamente boa e, principalmente, a maioria considera interessante trabalhar com o QGIS e acha que o software que poderá vir a ser "útil" ou "muito útil" no futuro.

Em relação a problemas e dificuldades merecem destaque três aspectos. Em primeiro lugar a falta de conhecimentos de base a nível de informática por parte dos formandos foi sem dúvida a principal dificuldade. A falta de conceitos chave como "directoria" ou "extensão" estiveram na origem da maior parte das dificuldades sentidas, que se traduzem na célebre questão "Onde é que está? Não encontro o ficheiro!"

A segunda dificuldade esteve relacionada com o acesso a informação online, quer através de serviços WMS/WFS, quer através do plugin Open Layers, não por causa do QGIS, mas simplesmente porque a rede disponível não permitia acessos em simultaneo.

A terceira dificuldade é inultrapassável: 25H é manifestamente muito pouco para quem nunca teve nenhum contacto com SIG, e alguns formandos manifestaram isso mesmo. No entanto o Referencial é muito claro e nada há a fazer - 25H!

Digno de nota é a performance do QGIS que foi francamente boa - sem crashes nem problemas de performance. De um .universo de 13 computadores, 4 tinham Windows XP e 9 o Windows 7. O único problema que se registou foi ao nível do Print Composer que, nas máquinas com Windows XP não conseguia desenhar uma legenda a partir dos vectores do projecto - um problema que entretanto já foi reportado à equipa de desenvolvimento do QGIS.

Aqui ficam alguns dos mapas produzidos - nada mau para quem utilizou QGIS pela primeira vez!

Finalmente quero deixar uma nota de agradecimento à Escola Profissional Alsud pelo convite que me dirigiu e em particular à coordenadora do Curso de Assistente de Arqueólogo, professora Ana Carmo, pelo apoio, e abertura demonstrada para integrar curricularmente soluções de software aberto. Uma palavra também para os formandos que se esforçaram por aprender e não colocaram qualquer tipo de objecção à publicação destas notas.

Notas sobre o IV SASIG

2011-11-05T12:31:00.000-07:00

Terminaram ontem as IV Jornadas de Software Aberto para Sistemas de Informação Geográfica que decorreram em Guimarães entre os dias 2 e 4 deste mês. As jornadas, promovidas pela OSGeo Portugal, consituiem um espaço de encontro e convívio entre profissionais e interessados pelas geotecnologias de código aberto. São uma boa oportunidade para conhecer o que se anda a fazer com software aberto na área dos SIG.

Das várias comunicações apresentadas deixo aqui umas breves notas sobre aquelas que me pareceram mais interessantes. Quem quiser saber mais sobre os temas deverá consultar a página da OSGeo Portugal.

A primeira comunicação das Jornadas ficou a cargo de Gonçalo Casaleiro, em representação da Agência para a Modernização Administrativa. A presença de um representante da Administração Central no encontro é, por si só, um dado salutar. A comunicação centrou-se no tema da interoperabilidade dos dados enquanto pré requisito para a integração legislativa e administrativa. A ideia chave desta comunicação é muito interessante e merece destaque para reflexão:

A adopção de normas abertas e a disponiblização de dados pelo Estado irá acrescentar valor a esses mesmos dados por via da cooperação com os cidadãos que essa política permite.

Na área da investigação académica foi apresentada uma comunicação sobre fusão de dados vectoriais heterogéneos com software aberto, tema de doutoramento de Sérgio Freitas. A investigação centra-se em encontrar uma metodologia que, com base na similaridade geográfica, topológica e/ou semântica, permita fundir num único vector um conjunto de dados vectoriais aparentemente redundantes.

Ainda no primeiro dia das Jornadas uma nota para o trabalho notável que o Pedro Venâncio fez na Câmara Municipal de Pinhel. Tendo por base o Quatum GIS e o GRASS, Pedro Venâncio elaborou a Carta de Risco de Incêndio Florestal para o concelho de Pinhel. Os resultados foram alvo de validação que confirma a utilidade da carta produzida: 88% dos incêndios de 2010, no concelho de Pinhel, ocorreram em áreas identificadas como zonas de risco alto ou muito alto!

O primeiro dia terminou com comunicações centradas no Open Street Map, e vou destacar o projecto Clube de Cartografia, uma iniciativa de Cristina Oliveira, professora do 3º Ciclo do Ensino Básico, que, tendo por base Walking Papers, mobilizou um conjunto de alunos no sentido de mapearem a Esgueira e assim explorarem os caminhos da geografia e da cartografia. Um exemplo notável de integração curricular das TIC.

O segundo dia das Jornadas, dia 3, começou com uma comunicação de José Alberto Gonçalves, cujo contributo para as geotecnologias em Portugal, especialmente no que concerne a sistemas de coordenadas é inestimável. A comunicação consistiu numa descrição da biblioteca .proj4. À semelhança do que já havia feito, José Alberto Gonçalves recomendou a adopção definitiva do ETRS89-tm06 em detrimento dos clássicos Hayford-Gauss Militar e Datum 73.

Giovanni Manghi, da Faunalia, apresentou a lista de novidades com que podermos contar no QGIS 2.0. De entre elas destaque para o QGIS Processing Framework que permitirá integrar os módulos de análise de ferramentas poderosas mas que não têm uma interface tão amigável como o Quantum GIS, nomeadamente o Orfeo, GRASS e SAGA. Estamos a falar de centenas de ferramentas de análise que poderão ser usadas em conjunto através de um model builder. Tudo isto poderá significar que deixará de ser necessário criar um Mapset cada vez que queremos utilizar ferramentas GRASS no QGIS!

Da Galiza veio Micho Garcia que, com apresentação divertida e descontraída, deu a conhecer os Xeoinquetos, uma associação informal de apaixonados pelas geotecnologias que se juntam para colaborar em projectos comuns. O grupo Xeoinquetos pode ser descrito como um movimento de cidadania em que os partipantes divulgam conhecimento e técnias geográficas entre si, criando assim um ambiente de aprendizagem que encoraja as pessoas a "sair da sua zona de conforto" pois só assim se aprende...

Finalmente Mota Lopes e Ricardo Sena apresentaram o projecto para uma Plataforma SIARL (Sistema de Informação para apoio à Reposição da Legalidade), cuja face mais visível será um websig que terá a particularidade de ser interactivo, ou seja permite que os utilizadores utilizem informação própria na plataforma. Vale a pena conhecer melhor. A comunicação terminou com um apelo à comunidade (nós todos), para que partilhe os dados que tem para podermos enriquecer o projecto.

O terceiro dia, no campus da Universidade do Minho em Guimarães, foi dedicado aos Workshops - mini cursos práticos sobre determinados softwares. Infelizmente foram altamente condicionados por dificuldades técnicas no acesso à Internet. Não obstante, os workshops são uma excelente oportunidade para aprender em primeira mão com profissionais experientes e são, na minha opinião, a grande mais valia das Jornadas de Software aberto para SIG.

Para terminar nota ainda para os trabalhos e Assembleia Geral da OSgeo-PT, que decorreram no dia 2, e em que foram discutidos assuntos de interesse para a Associação, tendo sido igualmente eleitos novos membros conselheiros, cujos nomes serão divulagados em breve no site da OSGeo-Portugal.

No geral acho que as Jornadas correram bem e a organização - desde a Direcção da OSGeo-Portugal ao secretariado está de parabéns pelo excelente ambiente que se viveu. No entanto não posso deixar de sublinhar um aspecto que tem de melhorar - o cronograma. O programa provisório e as datas das Jornadas devem ser divulgadas com mais antecedência - pelo menos três meses e não apenas uma semana antes, sob pena de muitos interessados não conseguirem organizar as suas agendas de modo a garantirem a sua presença. Sei por experiência própria que estas coisas dão muito trabalho e não são fáceis, por isso este desafio é para toda a comunidade e não apenas para a Direcção da OSGeo-Portugal.

Programa do IV SASIG (Jornadas de Software Aberto para SIG)

2011-10-25T17:35:00.000-07:00

Acabou de ser divulgado o programa detalhado das IV Jornadas de Software Aberto para Sistemas de Informação Geográfica que irá decorrer em Guimarães nos próximos dias 2 e 4 de Novembro.

PROGRAMA:

DIA 2 de Novembro (4ª feira)

09:00 – 09:30 Acreditação
09:30 – 10:00 Sessão de Abertura
10:00 – 10:30 Gonçalo Caseiro, Agência para a Modernização
Administrativa *
10:30 – 10:45 Pausa para café
10:45 – 11:15 Maribel Santos, Universidade do Minho
11:15 – 11:30 Sistema de Apoio ao Licenciamento da ARH Algarve – uma
solução webGIS baseada em tecnologia open source, Hugo Martins
11:30 – 11:45 Mapeamento energético e económico do potencial de
produção de biomassa, Rui Pedro Henriques
11:45 – 12:00 Solução Web SIG aplicada a um sistema de gestão de
informação na saúde, Ana Rita Sousa
12:00 – 12:30 Novageo
12:30 – 14:00 Almoço (livre)
14:00 – 14:30 Rafael Ramos, Junta da Extremadura
14:30 – 14:45 IDE_CIMAC – O OSGeo na disponibilização de informação
geográfica aos municípios do Alentejo Central, Teresa Batista
14:45 – 15:00 Fusão de conjuntos de dados espaciais heterogéneos com
recurso a Software Aberto, Sérgio Freitas
15:00 – 15:15 Cartografia de Risco de Incêndio Florestal com Software
Open Source, Pedro Venâncio
15:15 – 15:45 Edisoft
15:45 – 16:15 Pausa para café
16:15 – 16:45 Acesso e partilha de dados geográficos de
biodiversidade: o desenvolvimento de um portal de metadados, Pedro Castro
16:45 – 17:00 Routing de veículos de emergência no OSM, João Vieira
17:00 – 17:15 Equipamentos de Saúde no OSM, Juliana Pereira
17:15 – 17:30 Clube de Cartografia, Cristina Oliveira
17:30 – 18:00 XLM
18:00 – 18:15 Pausa para café
18:15 – 20:15 Assembleia Geral da OSGeoPT
20:15 – 20:30 Pausa
20:30 – 22:30 Jantar Oferecido pela OSGeoPT

Dia 3 de Novembro (5ª feira)

09:00 – 09:30 José Aberto Gonçalves
09:30 – 09:45 Novidades em QGIS 2.0, Giovanni Manghi
09:45 – 10:00 Localização em Espaços Interiores, Nair Alves
10:00 – 10:30 Micho Garcia, Xeo-Inquedos
10:30 – 11:00 Pausa para café
11:00 – 11:30 KOSMO
11:30 – 11:45 Implementação de um W3DS, Nuno Oliveira
11:45 – 12:15 Plataforma SIARL, Mota Lopes e Ricardo Sena
12:15 – 12:30 Desafio à comunidade, Mota Lopes
12:30 – 12:45 Sessão de Encerramento
12:45 – 14:00 Almoço (livre)
14:00 – 14:30 Tutorial – Introdução ao MapServer, Duarte Carreira
14:30 – 15:00 Tutorial – Introdução ao Geoserver, António José Silva
15:00 – 15:30 Tutorial – Introdução ao Geomoose, Catarina Ferreira
15:30 – 16:00 Pausa para café
16:00 – 18:00 Iniciativas OSGeoPT
18:00 – 20:00 Linux Installation Party (informal)
20:00 – 22:00 Jantar (livre)

Dia 4 de Novembro (6ª feira)

09:00 – 13:00 Workshops
13:00 – 14:00 Almoço (livre)
14:00 – 18:00 Workshops

* não confirmado
NOTA: PROGRAMA SUJEITO A ALTERAÇÕES

Mais informações e inscrições no site das Jornadas

MapCruncher: georeferenciar mapas e visualizá-los com Bing Maps ou Google Earth

2011-09-30T14:51:00.000-07:00

Recentemente publiquei um pequeno tutorial sobre o Maptiler, um programa que gera kml super overlays, ou seja permite visualizar um mapa raster no Google Earth. Um dos comentários recebidos foi do Luís Tavares que aconselhou dar uma olhadela ao MapCruncher, um programa parecido com o Maptiler mas com duas diferenças fundamentais:

1 - Permite georeferenciar mapas de forma bastante intuitiva utilizando as imagens de satélite do Bing Maps como referência;

2 - Gera igualmente tiles, ou segmentos, mas estão associados a um ficheiro .xml para utilizar com o BingMaps.

Primeira Parte - MapCruncher

Descarregar e instalar o MapCruncher a partir daqui. Abrir o a aplicação e carregar um mapa sem georeferenciação. Para o presente exemplo utilizei o Plano de Ordenamento da Orla Costeira de Porto Novo (Torres Vedras), previamente convertido para .tiff, disponibilizado pelo Instituto da Água apenas em formato PDF.

A imagem abaixo ilustra a interface, na minha opinião bastante intuitiva, com que o MapCruncher permite georeferenciar imagens. Primeiro coloca-se a mira sobre o ponto para o qual encontrámos uma boa correspondência nas imagens de satélite - visíveis do lado direito. Definida a primeira correspondência é só clicar em Add. Devem repetir este processo pelo menos três vezes - embora seja aconselhável ter mais pontos de controlo. Quando tivermos os nossos pontos de controlo definidos basta clicar em Lock e, caso a margem de erro seja aceitável para os nossos propósitos, finalizar o processo clicando em render.

Surgirá uma outra janela na qual basta definir a directoria para onde desejamos que as tiles seja criadas. Clicar em resume e aguardar.

O resultado final é uma directoria com uma série de subdirectorias que contêem as tiles, ou segmentos. Para visualizar no nosso navegador de internet basta abrir o ficheiro HTML intitulado SamplePage.

Segunda Parte - CrunchUp2KML

Quem acompanha este blog certamente já percebeu que sou um utilizador regular do Google Earth - continua a ser, na minha opinião, o melhor visualizador de dados .

Através do aplicativo CrunchUp2KML, que pode ser descarregado a partir daqui, podemos transformar o mashup produzido pelo MapCrucher num kml super overlay e assim visualizá-lo no Google Earth. O aplicativo funciona por linha de comandos por isso, se forem como eu - tendencialmente disléxico nestas coisas de linhas de comando - o melhor é copiar o mashup para uma directoria básica tipo c:\Newfolder

O CrunchUP2KML vem sobre a forma de um executável que podemos colocar em qualquer directoria do nosso computador (mais uma vez aconselho colocarem numa directoria simples tipo c:\Cruncher2KML) só funciona se for evocado a partir da consola do Command Prompt do Windows. Uma vez na directoria em que o executável CrunchUP2KML se encontra basta correr o seguinte comando:

CrunchUp2KML \directoria das tiles geradas pelo Mapcruncher\MapCruncherMetadata.xml

Se tudo correr, a vossa janela de prompt deverá ter o seguinte aspecto:

O nosso kml super overlay encontra-se dentro da directoria do mashup criado com o MapCruncher com o nome Layer_NewLayer. Para visualizar as tiles na sua totalidade basta abrir o ficheiro doc.kml

NOTAS:

Ambos os programas estão descontinuados. Tanto o MapCruncher como o CrunchUp2KML não conhecem actualizações desde 2007;

Se o objectivo for apenas visualizar um mapa raster no Google Earth, talvez seja melhor georeferenciar a imagem num software SIG e depois utilizar o Maptiler. A vantagem deste método é a forma bastante intuitiva que o MapCruncher oferece para georeferenciar imagens;

Só funciona no Windows e, no caso do CrunchUp2KML, é necessário ter o .NET Framework instalado;

Não utilizar assentos, cedilhas ou espaços - o CrundhUp2KML pode não digerir bem esses caracteres

Revista FOSSGIS Brasil

2011-08-26T14:00:00.000-07:00

Sendo este um blog dedicado a soluções abertas no campo das geotecnologias, não poderia deixar de fazer referência e uma pequena análise a um projecto editorial recente vindo do outro lado do Atlântico: a revista FOSSGIS Brasil (Free and Open Source Sofware for Geographic Information Systems).

A revista, em português e com uma periodicidade trimestral, pode ser descarregada gratuitamente a partir daqui. Esta revista é um excelente recurso para quem quiser explorar o mundo do FOSSGIS. Das duas edições lançadas até ao momento (Março e Junho), destacaria a forma acessível em que a revista está redigida. A linguagem, não é excessivamente técnica o que a torna acessível ao público não especialista.

De entre os artigos que classificaria de divulgação destacaria os seguintes:

- A História do FOSSGIS por Luís Carlos Madeira, publicado na Edição n.º1 : uma excelente síntese que em poucas páginas apresenta uma retroespectiva da evolução do sofware aberto para SIG.

- O uso de Software Livre no Ensino por Ricardo Pinho, publicado na Edição n.º2 : sendo uma das minhas actividades profissionais a formação profissional, também já tive a oportunidade de explorar software SIG com excelentes resultados. O artigo de Ricardo Pinho é bastante interessante para todos os que trabalham no ensino, especialmente professores de Geografia, mas não só. Numa altura em que os cortes financeiros nem as escolas poupam, é importante que as escolas se consciencializem que não precisam de gastar balúrdios em licencas para atingir os objectivos didáctico-pedagógicos.

- Sopa de Letras Geográfica por Felipe Santos Costa, publicado na Edição n.º1: o artigo explica, de forma muito simples, as várias formas de distribuir informação geográfica através da internet - ou por outras palavras, as várias formas de usufruir de webservices (WMS; WFS; WPS; etc). Inclui um pequeno tutorial sobre como aceder a estes serviços com o Quantum GIS.

Já no campo dos artigos mais técnicos que me parecem ser úteis também para um público mais informado sobre essas temáticas pareceram-me especialmente interessantes os seguintes.

- WKT Raster por George Silva, publicado na Edição n.º2 : oferece uma abordagem técnica sobre o suporte PostGIS para dados raster, uma capacidade que estará definitivamente implantada com o PostGIS 2.0

-WebGIS Geo Ext por Marcello Benigno, publicado na Edição n.º2: um mini tutorial sobre Geo Ext, uma ferramenta de Webmapping.

Poderia destacar outros artigos mas estes são suficientes para sublinhar o que me parece ser o principal mérito da revista: ser um projecto a seguir tanto por especialistas como por não especialistas. Além destes artigos que aqui destaquei, nos dois números poderão encontrar análises a vários programas.

Finalmente gostaria de destacar o carácter aberto da própria revista: é distribuída sob uma licença Wiki Commons 3.0 e está aberta a contributos de qualquer autor de qualquer parte do mundo.

Espreitem! Vale a pena!

MapTiler: visualizar mapas no Google Earth

2011-07-17T13:09:00.000-07:00

MapTiler é um programa aberto que faz uso das bibliotecas GDAL para criar tiles (segmentos em português) de mapas de modo a que possam ser visualizados rapidadamente em função da escala e resolução necessárias no momento da visualização.

Entre outras coisas, o MapTiler permite criar KML Super Overlays, ou por outras palavras, segmentos construídos a partir de um único mapa raster cujos segmentos, escalas e resolução estão definidos num ficheiro .kml que ao ser aberto irá projectar o nosso mapa no Google Earth.

Primeiro Passo

Descarregar e instalar o MapTiler a partir daqui. Quando iniciar o MapTiler surgirá uma janela com 3 opções. Escolhemos Google Earth (KML Super Overlay) e clicamos em Continue.

Segundo Passo

Na segunda janela adicionamos - Add - um mapa em formato raster que esteja georefenciado, neste exemplo a carta geológica de Portugal disponivel no Atlas do Ambiente (isto depois de se preencher um inquérito por cada mapa que se descarregue e, como se não bastasse, o mapa apenas está disponível num formato proprietário (MrSID) e vem com um nome críptico "I_12.sid" - dava muito trabalho mudar para "geologia" ou algo do género - mas não deixa de ser de louvar a iniciativa de disponibilizar os dados)

Terceiro Passo

Para as próximas duas janelas, à partida, não será necessário mudar nada: basta clicar em Continue na janela Spatial Reference System (SRS) - onde será descrita o sistema de coordenadas do raster que adicionámos - e na janela Details About Tile Pyramid.

Quarto Passo

Finalmente basta ir clicando em Continue e ir definindo as opções de saída - directoria e nome do mapa - até chegarmos à última janela onde bastará clicar em Render e aguardar que o proceso termine.

Quando o processo terminar, o resultado será uma directoria subdividida em várias pastas numeradas de 0 a X. Cada uma dessas pastas contem uma segmento (uma tile) do nosso mapa.

Para abrirmos o mapa no seu todo basta ter o Google Earth Instalado e clicar duas vezes no ficheiro .kml que por definição tem o nome de doc.kml - podemos mudar o nome.

A partir daqui podemos visulaizar o nosso mapa com todas as funcionalidades que o Google Earth proporciona, nomeadamente transparências e vista 3D.

Notas: Esta funcionalidade do MapTiler funciona com qualquer mapa raster desde que este esteja georefenciado - não importa o sistema de coordenadas do raster, desde que seja um sistema definido e aceite;

A variedade de formatos de entrada é bastante grande: .jpg; .tiff; .bmp; .png; .gif, no fundo todos os formatos que a biblioteca GDAL suporta. No caso de formatos proprietários como .ecw ou .sid, poderá ser necessário algumas configurações extra, principalmente se forem utilizadores Linux;

Finalmente importa salientar que o MapTiler deixa o ficheiro original intacto - as tiles são criadas numa nova directoria a partir do raster de entrada, mas este permanece inalterado no fim do processo.

Instalar Google Earth no Linux Ubuntu 11.04

2011-07-05T12:26:00.000-07:00

Actualmente o Google Earth é provavelmente o visualizador de informação geográfica mais popular e utilizado em todo o mundo. A facilidade de utilização e a rapidez de rendering das imagens explicam uma grande parte desta popularidade.

Para os utilizadores de Linux a versão mais recente do GE encontra-se disponível sob a forma de um pacote com a extensão .deb que pode ser descarregado a partir daqui.

Apesar desta boa notícia, a instalação não é tão linear como a disponibilização de um pacote .deb poderá fazer supor. Assim, aqui fica um guia passo a passo para a instalação do GE para Ubuntu 11.04

Primeiro Passo: instalar o Linux Standard Base (LSB)

A instalação do LSB é um pré requisito essencial para que o GE funcione. Basta aceder ao Ubuntu Software Center, pesquisar por LSB, e clicar em install.

Segundo Passo: instalar Google Earth

De seguida descarregamos o pacote de instalação do GE a partir daqui

Abrimos uma janela do terminal (consola na versão portuguesa) e começamos por indicar o caminho onde se encontra o pacote de instalação que acabámos de descarregar. À partidao o pacote foi descarrefado para a pasta dos downloads, consequentemente o comando será:

cd /home/nomedeutilizador/Downloads

Uma vez na directoria basta dar ordem de instalação com este comando:

sudo dpkg -i google-earth-stable_current_i386.deb 

No fim da operação o GE está instalado. No entanto, poderá acontecer-vos o que a imagem abaixo ilustra. As letras dos menus do GE são demasiado grandes e desajustadas. Se isto acontecer significa que não têm instalados um pacote de tipos de letra ou fontes chamado MS True Type.

Terceiro Passo: instalar fontes MS True Type

Finalmente, para termos uma visualização correcta dos menus abrimos o terminal e instalamos as fontes que precisamos pa a partir do comando

sudo apt-get install ttf-mscorefonts-installer

No final da operação surgirá um quadro com os termos da licença basta clicar na tecla tab de modo a que o botão de "ok" que surge no fim do texto surja destacado, e pressionar a tecla Enter.Para finalizar basta reiniciar o computador

NOTA: este tutorial nasceu das dificuldades experienciadas por mim, espero que possa ser útil para outros utilizadores que experimentem o mesmo tipo de dificuldades. A solução aqui apresentada poderá funcionar também com outras distribuições Linux mas não testei. Por favor deixem algum feedback caso isto tenha funcionado convosco também.

Quantum GIS 1.7 está aí!

2011-06-20T04:45:00.000-07:00

Conforme anunciado anteriormente, aí está a versão 1.7 do Quantum GIS (QGIS) denominada Wroclaw. Para quem já conhece, e vinha experimentando sob a forma de edições de desenvolvimento ou de teste - este é o resultado final que congrega já algum do trabalho desenvolvido aquando do Developer Meeting de Lisboa. Para quem não conhece, está na altura de conhecer e experimentar. Dificilmente encontrarão um software mais intuitivo e fácil para aprender a explorar o mundo dos Sistemas de Informação Geográfica que o QGIS.

Não me vou prender a enumerar as novidades, uma vez que seria algo redundante pois podem ser consultadas aqui. Nem tampouco irei fazer uma análise ou review. Aproveito o pretexto que o lançamento do QGIS 1.7 me proporciona para chamar a atenção de uma novidade um pouco mais escondida mas de extrema importância: o QGIS Issue Tracking!

Sendo um projecto aberto, a colaboração de todos é fundamental, e não é necessário ser-se especialista ou programador para contribuir. A maioria dos utilizadores está habituada a, quando encontra um erro/bug/crash num dado software, resignar-se e aceitar o erro como uma parte natural das coisas. ERRADO! Os bugs são naturais mas existem para serem destruídos! Se comunicarmos os bugs estamos a contribuir de forma decisiva para o aperfeiçoamento do projecto e é para isso que serve o QGIS Issue Tracking. Para os menos afoitos aqui fica um "mini tutorial" sobre como utilizar esta ferramenta.

Primeiro passo

Criar uma conta de utilizador - Userid - da Open Source Geospatial Foundation - OSGEO.org. Podem fazê-lo a partir daqui. Esta conta será o vosso passaporte para outros projectos patrocinados pela fundação.

Segundo passo

Quando encontramos um erro/bug, devemos reportá-lo a partir desta página utilizando os dados da conta criada no primeiro passo. Depois de fazer o login, devemos deparar com a seguinte página:

Não temos que preencher todos os campos, mas devemos ser objectivos de modo a facilitar a vida da equipa que vai analisar este erro. Devem fazê-lo em inglês. Por exemplo, se colocarmos apenas "Qgis crashes after loading a shapefile" isto é muito vago e não será muito útil. Vou apresentar um exemplo fictício utilizando apenas as informações mínimas que temos de transmitir.

Assim, começando de cima para baixo:

Tipo: Bug

Title: Qgis crashes after loading a shapefile (O título deve ser curto e directo)

Description: Qgis crashes after loading a shapefile of points (3453 features to be exact). I attached the shapefile that is causing the crash. (a descrição deve ser, acima de tudo objectivo e fornecer os pormenores estritamente essenciais).

Estado: New

Prioridade: High (a prioridade poderá ser alterada à posteriori pelo developer que se encarregar deste bug)

Categoria: Build/Install (se não estivermos seguros da categoria, é preferível deixar em branco)

Versão: 1.7.0 (informação essencial! - qual a versão QGIS que estavamos a utilizar quando se deu o erro)

Plattform: Windows (informação essencial! - em que sistema operativo estava o QGIS a correr)

Plattform Version: 7 Home (informação essencial! - em que versão do sistema operativo estava o QGIS a correr)

Finalmente, sempre que possível, devemos anexar o ficheiro associado ao erro. Fornecidas as informações essenciais, juntamente com o ficheiro, acabámos de dar à equipa do QGIS condições para poderem recriar o erro e confirmarem se se trata efectivamente de um erro ou se é um problema associado ao ficheiro ou ao nosso computador.

Se for um erro, e por experiência própria, podemos esperar uma solução no espaço de poucos dias ou até horas! Isso quer dizer que as versões mais recentes do QGIS já não terão este bug!

Não sejam utilizadores passivos! Contribuam - não custa nada e é muito importante ;)

Georeferenciar Fotografias e visualizá-las no Google Earth

2011-05-15T17:48:00.000-07:00

------------------------------------------------
Software necessário:

- GPS Prune
- ExifTool

-----------------------------------------------

Ter um arquivo fotográfico em que cada fotografia tem associada coordenadas geográficas/cartográficas pode ser extremamente útil não só para partilhar informação técnica, turística ou simplesmente pessoal, mas também pode ser uma forma muito interessante de apoio à gestão patrimonial.

É uma tarefa relativamente simples que pode ser feita tirando partido da extensão .exif (abreviatura de extended information) que basicamente é uma tag que anexa informação escrita a uma dada imagem, neste caso geográfica - latitude e longitude.

Vamos começar por instalar os dois programas que precisamos. Descarregamos e guardamos o Runnable Code do GPS Prune a partir daqui e o Windows Executable do ExifTools a partir desta página. O GPS Prune lida com ficheiros geográficos (.gpx; .kml; .kmz;) e o ExifTool permite associar a informação geográfica a uma ou mais imagens.

Para que tudo funcione correctamente temos de proceder da seguinte forma:

Nenhum destes programas necessita instalação. Vamos por isso criar uma pasta para guardar os dois programas (por exemplo C:/GPS Prune)

Para que o GPS Prune consiga evocar o ExifTool, o ExifTool deve estar na mesma directoria do GPS PRune (o que já foi feito passo anterior) - e tamém temos de mudar o nome ao executável do ExifTool. Quando descarregamos o ficheiro ele vem com o nome "exiftool(-k)", temos de alterar para simplesmente "exiftool".

Terminados estes dois passos podemos passar ao que realmente interessa - georreferenciar fotografias!

O cenário ideal - no qual se baseia este post - é que tanto as coordenadas como as fotografias foram registados ao mesmo tempo, ou seja, no momento em que tirávamos a fotografia também estávamos (mais minuto menos minuto) a registar com o GPS o ponto de onde tirámos a fotografia. Para que isto funcione há que ter o cuidado de configurar a hora e data da nossa máquina fotográfica de modo a que seja coincidente com a do GPS - a hora da nossa máquina deve ser configurada em função da hora indicada pelo GPS.

Descarregamos as fotografias que tirámos durante o dia e os pontos registados no GPS (utilizar o formato .gpx) para uma pasta. Neste exemplo irei utilizar um conjunto de dados recolhidos por mim na vila de Odemira, no Sudoeste Alentejano.

Primeiro passo: abrir o GPS Prune e Carregar as fotografias.

Segundo passo: abrir o ficheiro .gpx com os pontos onde foram tiradas as fotografias.

Terceiro passo: conectar um dos pontos à fotografia certa - no exemplo em baixo, o ponto "Chafariz"

Quarto passo: a partir do menu "Foto" seleccionar "correlacionar fotos". Surgirá uma janela com a diferença temporal entre a foto e o ponto que correlacionámos no passo anterior. Essa diferença será assumida como a diferença média para todas as restantes fotos e pontos. Basta clicar em "próximo" para obter um quadro com todas as correlações que foi possível efectuar automaticamente. No fim destas operações deveremos ter uma série de pontos a amarelo assinalando os pontos que foram conectados a determinadas fotografias. Convem verificar algumas para ver se a correlação foi bem feita. Se repararem, a listagem de fotos - no canto inferior direito - é antecedida de um asterisco. Isso significa que estão conectadas/correlacionadas com um dos pontos do nosso projecto.

Quinto passo: Vamos agora guardar tudo num ficheiro .kmz que abrirá os nossos pontos no Google Earth com miniaturas (thumbnails) das nossas fotos associadas aos pontos. A partir do menu "Arquivo" escolhemos a opção "Exportar para .kml". Surge uma janela e temos de ter o cuidado de selecionar as opções"Comprimir para criar kmz" e "Exportar miniaturas de imagem para o kmz". O resultado, neste caso, será um único ficheiro .kmz, com 90kb que abrirá no google earth já com as miniaturas das nossas imagens associadas aos pontos.

Sexto passo (opcional): a partir do menu "Foto" seleccionar "Salvar para exif". Deste modo vamos guardar uma segunda via das nossas fotografias com a informação geográfica já incluída. Estas fotos com informação geográfica anexada serão criadas com o sufixo "_original" e poderá ser necessário definir manualmente a extensão (.jpg).

No fim de todas estas operações temos um conjunto de fotografias georeferenciadas - neste caso referentes a Odemira, e um ficheito .kmz que nos permite ver a localização das fotografias (e uma miniatura das mesmas) no Google Earth.

Há várias opções para calibrar o nível de tolerância entre a diferença da hora do GPS e da máquina fotográfica, no entanto se a data/hora da máquina fotográfica for devidamente acertada antes de começar o trabalho à partida não teremos de nos preocupar com essas opções porque a correlação será feita, teoricamente, sem problemas. Se, mesmo assim, houver uma ou outra foto que não foi correlacionada automaticamente, podemos tratar desses casos isolados através de uma conexão manual (ilustrada no Terceiro Passo) antes de exportar o trabalho para .kmz.

Preparar prospecções com Google Earth e GPS

2011-05-01T14:03:00.000-07:00

------------------------------------------------
Software necessário:

- Google Earth
- GPS Babel
- Easy GPS

(Este post é um aprofundamento de um tema anterior)
-----------------------------------------------

A prospecção arqueológica (ou de outro tipo) de uma dada zona deve ser antecedida de um estudo da cartografia e da paisagem com vista a adquirir uma noção da morfologia da zona - linhas de água, principais declives, acidentes topográficos, etc.

Este estudo (que não ocupa tanto tempo como por se possa pensar), se bem feito, permite melhorar a eficiência e é também um factor de segurança para o prospector (ter noção, por exemplo, da proximidade das estradas caso seja preciso pedir ajuda).

Os métodos clássicos continuam a ser, na minha opinião, extremamente válidos - nada como levar um mapa topográfico (normalmente a carta militar) connosco. No entanto, quando se trata de áreas extensas, como por exemplo um troço de uma estrada ou a bacia de uma futura barragem, poderá ser interessante levar connosco um GPS com alguns pontos de referência.

Levar o GPS com estes "pontos de referência" é especialmente útil em zonas de vegetação cerrada - que facilmente podem ocultar indícios - ou em zonas de planície em que a falta de acidentes topográficos como vales profundos ou morros, dificulta a percepção do espaço e da localização. Estes "pontos de referência" a que me refiro nada mais são que sinais "suspeitos" do ponto de vista dos nossos objectivos (neste caso arqueológicos). A imagem abaixo mostra alguns desses "sinais suspeitos" que são, muitas vezes, perfeitamente visíveis no Google Earth.

O exemplo aqui exposto consiste simplesmente em carregar estes elementos para o nosso GPS de forma a que possamos encontrá-los facilmente quando formos para campo. Para tal iremos proceder por fases:

I - Vectorizar no Google Earth os elementos que desejamos visitar e guardá-los em formato .kml;

II - Converter do formato .kml para formato .gpx (formato universal para receptores de GPS);

III - Carregar o ficheiro .gpx para o receptor GPS;

IV - Iniciar o trabalho de campo.

I - Criar ficheiros .kml no Google Earth

O ficheiro .kml é um formato vectorial nativo do Google Earth que permite armazenar uma série de elementos - coordenadas, altitude, inclinação, direcção e geometrias do tipo ponto, linha e polígono. E aqui reside a primeira armadilha: como o objectivo final é enviar a informação para um GPS (e para tal teremos de converter o .kml para o formato .gpx), não podemos usar polígonos para marcar áreas. Podemos usar uma linha (que no Google Earth é designada por "caminho") e com ela desenhar o perímetro de uma dada área:

Outro cuidado a ter em conta é a estrutura das entidades que queremos vectorizar É recomendável, enquanto estamos a vectorizar objectos no Google Earth, criar pastas diferentes para cada tipo de objecto pois facilita a análise. Neste exemplo foi criada uma pasta para áreas (que como vimos mais não são que linhas que assinalam o perímetro), pontos, e uma terceira e quarta pasta denominada "Rio" e "Caminhos". Estas últimos serão elementos de apoio - que numa situação de prospecção intensiva e extensa poderão vir a ser úteis. Finalmente foi tudo agrupado numa pasta denominada "Prospeccao_A". O último passo é clicar com o botão direito do rato sobre a pasta "Prospecção_A" e guardar com o mesmo nome e com a extensão .kml. Todos os nossos objectos estão agora armazenados no .kml que acabámos de criar.

II. Converter do formato .kml para formato .gpx

Para converter para formato .gpx vamos utilizar o GPS Babel - um software aberto já referido anteriormente. O programa funciona numa base de Input/Output, por isso basta utilizarmos como Input o .kml que acabámos de criar, e como Output um novo ficheiro em formato .gpx. Como o nosso .kml tem pontos e linhas, há que marcar as opções "Waypoints" (pontos) e "Tracks" (Linhas).

III - Carregar o ficheiro .gpx para o receptor GPS

Para finalizar basta enviar o ficheiro gpx para o nosso GPS. Podemos fazê-lo a partir do GPS Babel, ou em alternativa (se por alguma razão o GPS Babel não reconhecer o vosso receptor de GPS) através do EasyGPS , um software freeware que, não sendo tão versátil e muito mais limitado que o GPS Babel no que toca a formatos de ficheiro suportados, tem a vantagem de ter uma interface mais completa que nos permite pré visualizar os elementos que vamos enviar para o GPS e também alterar os nomes das entidades individualmente. Ligamos o nosso GPS ao computador através de um cabo USB e depois basta abrir o ficheiro .gpx, fazer uma última verificação (objectos e respectivos pontos) e clicar no botão "Send":

IV - Iniciar o trabalho de campo!

Temos agora toda no nosso GPS a informação que nos pareceu relevante no Google Earth - resta ir para campo examinar essas informações.

Notas:

1 - Evitem utilizar caracteres típicos das línguas latinas (acentos, cedilhas), assim como espaços para dar nome a objectos ou ficheiros. Isto é válido para este ou para qualquer outro exercício SIG. Muitos problemas advêem do não reconhecimento por parte dos programas de alguns desses caracteres - daí o meu ficheiro se chamar "prospeccao_A" e não "Prospecção A";

2 - Este exercício foi feito com um GPS da série Garmin EtreX. Nalguns receptores poderá ser necessário ir às opções/configurações para que as "tracks" (linhas) se tornem visíveis;

3 - O EasyGPS não tem versão para MacOS ou para Linux.

Quantum GIS (QGIS) 1.7

2011-04-17T07:18:00.000-07:00

Decorreu no passado dia 14 de Abril, na Faculdade de Letras da Universidade de Lisboa, o QGIS Day que antecedeu o Qgis Developer Meeting que deverá culminar no lançamento da versão 1.7 do Quantum GIS(QGIS) , uma das melhores soluções livres disponíveis actualmente.

Para quem não conheça, o QGIS é muito mais que um software para sistemas de informação geográfica, é uma plataforma altamente produtiva para trabalhar dados geográficos. Além das clássicas operações de visualização e edição de dados, o QGIS ofereçe uma interface gráfica para tirar partido das poderosas capacidades de análise do GRASS, pode ser utilizado como aplicação cliente de bases de dados PostGIS, podemos também tirar partido de uma grande fonte de dados (imagens satélite google por exemplo) e a isto tudo ainda acrescem dezenas de plugins desenvolvidos por utilizadores de todo o mundo.

Por muito bom que isto pareça, a verdade é que ainda ficará melhor, pelo menos a julgar pelo que foi anunciado no QGIS Day. As melhorias que serão disponibilizadas pela versão 1.7 (que deverá estar disponível ainda este mês), foram apresentadas por Giovanni Manghi da Faunalia, e, para conhecimento, deixo aqui uma nota das que me parecem mais relevantes.

1. Reprojecção de Rasters

Uma das mais antigas e mais desejadas capacidades que se pedia ao QGIS. A partir da versão 1.7 já será possível sobrepor automaticamente mapas em formato raster e visualizá-los com o sistema de coordenadas do nosso projecto. Isso significa que se o nosso projecto estiver, por exemplo, em WGS84, e adicionarmos um mapa raster cujo sistema de coordenadas seja Datum 73, não precisaremos de transformar o sistema de coordenadas desse mapa porque ele será automaticamente projectado no sistema de coordenadas do nosso projecto.

2. Opções de etiquetagem de objectos vectoriais

Não vale a pena alongar muito este tópico. Basta visitar esta mensagem no blog Linfiniti (editado por um dos programadores do QGIS) para ficar a saber todos os pormenores. Basicamente passará a haver muito mais opções para etiquetas o que certamente será extremamente útil.

A versão 1.7 será a última versão estável antes do lançamento do QGIS 2.0 - que ainda não tem data anunciada mas que já contará com algumas funcionalidades extra, entre as quais um globo tridimensional - tipo goolge earth, mas que permitirá visualizações tridimensionais dos mapas produzidos em QGIS.

Toponímia de Portugal

2011-03-23T15:19:00.000-07:00

Geonames.org é um repositório online de dados toponímicos gratuítos ao abrigo da licença Creative Commons Attribution 3.0. A partir deste repositório podemos descarregar, em formato .txt, a informação toponímica de um dado país. Neste post farei uma demonstração daquela que me parece ser a forma mais simples de transformar estes dados em informação geográfica vectorial.

A partir do endereço http://download.geonames.org/export/dump/ vamos descarregar o ficheiro com as informações toponímicas do país que quisermos, neste caso Portugal (PT.zip). Uma vez extraído o ficheiro, há que converte-lo numa tabela em formato CSV para que possamos posteriormente abrir essa tabela com o QuantumGIS. Para isso abrimos o ficheiro PT com a folha de cálculo do Open Office . Aparecerá uma janela onde nos serão solicitadas algumas opções. Certifiquem-se que a codificação é UTF8 e que o separador é do tipo "tab":

O ficheiro será aberto sob forma de tabela, mas basicamente só nos interessam 3 colunas: o topónimo (coluna B), a Latitude/Y (coluna E) e a Longitude /X (Coluna F). Eliminamos todas as colunas excepto estas três e acrescentamos uma linha no topo de forma a nomearmos as colunas: "Toponimo"; "Y"; "X":

De seguida guardamos o ficheiro com a extensão CSV tendo o cuidado de assinalar a opção de "edit filter settings".

Aparece uma última janela com opções. Certifiquem-se com a codificação é a UTF8 e não se esqueçam do delimitador que vão escolher (neste caso uma vírgula)

Podemos fechar o folha de cálculo do Open Office. Agora vamos abrir o Quantum GIS. Certificamo-nos que o plugin Add Delimited Text Layer está activo (poderão ter de ir a Plugins --> Manage Plugins para tornar o ícone deste plugin visível) e, através desse plugin, vamos importar o CSV e transformá-lo num ficheiro geográfico.

À partida o plugin irá identificar automaticamente o delimitador e as colunas que contêm as coordenadas X e Y, mas convém sempre verificar...

Finalmente clicamos em OK e temos agora um layer com mais de 25.000 topónimos de Portugal Continental e Regiões Autónomas. Para finalizar a operação basta clicar com o botão direito sobre o layer que acabámos de criar e seleccionar Save As e escolher o formato e a directoria onde queremos guardar. Aconselho Shapefile (.shp) ou Keyhole Markup Language (.kml) por serem formatos standard que quase todo o software aceita.

Não é preciso definir o Sistema de Coordenadas (CRS) porque o QGIS assume por default que é o WGS84 e neste caso está correcto - as coordenadas fornecidas no ficheiro .txt original estão neste sistema. Caso contrário teríamos de definir manualmente o CRS antes de salvar o layer.

Relativamente aos dados, confesso que não me deti muito na análise dos mesmos - limitei-me a fazer um zoom sobre a Região Oeste (a que conheço melhor) e pude verificar que os topónimos e respectiva localização estão correctos, sendo de destacar a quantidade de topónimos disponíveis.

Nota: este exercício foi feito em ambiente Linux (Ubuntu 10.10). Mas deverá funcionar igualmente em ambiente Windows. Todo o software utilizado é aberto e também está disponível para Windows.

GPS Babel (Google Earth para GPS e viceversa)

2011-03-18T13:49:00.000-07:00

A oferta de receptores GPS actualmente disponível é imensa - há para todas as necessidades e para quase todas as carteiras. No entanto isto origina um problema (em grande parte criado pelo apego dos fabricantes aos formatos de ficheiro proprietários ou fechados) na hora de enviar e receber ficheiros do GPS para o computador e/ou entre receptores de GPS.

Esta tarefa, teoricamente simples, é dificultada pelo simples facto de cada fabricante GPS ter os seus formatos e, na maioria das vezes, se não tivermos instalado no nosso PC o software desse fabricante não podemos simplesmente retirar a informação do receptor e guardá-la numa directoria no nosso PC.

Suponhamos, por exemplo, que um amigo vos empresta um GPS. Ao longo do dia fazem as vossas medições e, no final do dia, querem descarregar os dados para os visualizar, por exemplo, no Google Earth (GE). Com o software GPS Babel, um projecto open source desenvolvido desde 2002, apenas necessitarão de um cabo USB!

O programa funciona numa lógica de input/output. Neste exemplo, o GPS é um Garmin da série ETreX - será o nosso input (dados de entrada). O output (dados de saída) será um ficheiro do tipo KML (para podermos abrir com o Google Earth). Após esta operação basta abrirmos o ficheiro criado com o Google Earth para visualizar os nossos dados.

O contrário também é possível. Podemos criar trajectos no Google Earth (por exemplo um percurso de uma caminhada), ou pontos de interesse, (por exemplo moínhos, ruínas, manchas "suspeitas"), guardar no formato KML, e depois utilizar o GPS Babel para enviar para o nosso GPS ou, como é o caso na imagem abaixo, converter KML para GDB (formato da Garmin), para editar/visualizar no software da Garmin e/ou enviar para o receptor.

Nota Importante: no caso da conversão KML para GDB (ou possivelmente para outros formatos), a conversão não preserva o nome das geometrias. Por exemplo temos um KML com dois pontos que quando os criámos no GE demos o nome de "ruinas" e "quinta". Depois de convertido para GDB, os pontos assumirão o nome "Waypoint1" e "Waypoint2". Isto obriga a que, depois de feita a conversão, se editem os nomes manualmente caso queiramos que os nomes originais apareçam na hora de utilizarmos o receptor GPS em campo.

Melhorar a precisão das medições GPS em tempo real - 3

2011-03-13T04:47:00.000-07:00

O último deste ciclo de posts dedicados à precisão de medições GPS com aparelhos de gama baixa tratará de alguns conselhos práticos relativos ao acto da recolha em si. Pressupondo que os cuidados descritos anteriormente foram tidos, há que saber tirar partido deles no momento em que temos o aparelho na mão.

O primeiro cuidado, e o mais importante, diz respeito ao tempo que se deve dar ao receptor para aferir a coordenada de um ponto. Uma vez chegados ao ponto que pretendemos registar devemos estabilizar o aparelho na mesma posição e orientação durante pelo menos 30 segundos. Durante esses 30 segundos o receptor irá aferir a coordenada várias vezes e a coordenada final que ficará registada resulta das várias medições efectuadas ao longo desses 30 segundos. Consequentemente quanto mais tempo dermos ao aparelho para fazer medições mais precisa será a coordenada final. Em zonas urbanas de malha estreita, florestas ou em falésias/desfiladeiros, aconselho pelo menos 1 minuto - ou mais se tiverem tempo e paciência.

Este princípio também é válido se quiseremos registar áreas - por exemplo manchas de dispersão de materiais arqueológicos. Uma vez que a maioria dos GPS de gama baixa não permite o registo directo de polígonos, a solução será registar os vértices do polígono como pontos e posteriormente - em ambiente SIG - construir um polígono a partir desses pontos de vértice. Para tal deverão primeiro fazer uma avaliação prévia da forma do polígono de modo a que abranja a área que querem registar, e ficar 30s parados em cada vértice do vosso polígono.

Finalmente há que ter em conta o posicionamento do receptor. No momento de registo de pontos o aparelho não deve estar encostado ao corpo do utilizador e deve estar num angulo de 45º. A antena (normalmente no parte superior do aparelho) deve estar desobstruída e devemos posicionar-nos de modo a garantir uma abóboda celeste o mais desimpedida possível - por exemplo, se, virados para Norte tivermos uma parede, devemos virar-nos para outra direcção cardeal que esteja mais desafogada.

Estas recomendações ergonómicas - sugeridas pelos fabricantes, têm em vista reduzir ao mínimo possível as distorções de reflectância dos sinais rádio emitidos pelo GPS - o corpo humano , à semelhança de outros objectos, é um potencial distorcedor de sinais rádio.

Melhorar a precisão das medições GPS em tempo real - 2

2011-03-10T02:14:00.000-08:00

Independentemente de termos ou não acesso às correcções diferenciais (DGPS) - mas especialmente se o nosso receptor GPS não trabalhar com nenhum tipo de correcção - podemos potenciar a precisão das nossas medições se optarmos pelas alturas do dia em que temos mais satélites visíveis e em que a geometria dos mesmos é favorável.

O índice DOP - Dilution of Precision, indica qual a geometria dos satélites - quanto mais afastados estiverem os satélites uns dos outros no momento da medição, mais precisa será a a triangulação e consequentemente as nossas medições. Se os satélites estiverem próximos uns dos outros a triangulação poderá não ser tão precisa e consequentemente as nossas medições poderão não ser fiáveis. Sintetizando: um índice DOP até 3 é o ideal - dá garantias de boa precisão, até 8/9 poderá ser aceitável e acima disso o melhor é repetir as medições noutra altura porque potencia uma perda de precisão considerável.

Para não corremos o risco de "repetir as medições noutra altura" - situação particularmente desagradável se pensarmos em zonas de dificil acesso ou terrenos dificeis - o ideal é planear o trabalho de campo de forma ir para o terreno nas horas em que teremos mais satélites visíveis e uma geometria mais favorável. Para sabermos qual a altura ideal para ir recolher dados sugiro o software Planning da Trimble. Esta aplicação permite criar uma "estação", ou seja o ponto onde iremos trabalhar, e, a partir daí, calcula a altura mais favorável. Deixo aqui um exemplo:

1 - Após descarregar e instalar o programa, há que descarregar também o almanaque actualizado com as órbitras dos satélites GPS pois só assim o software poderá calcular as horas mais favoráveis. Em http://www.trimble.com/gpsdataresources.shtml faça salvar como/save as o item GPS/GLONASS alamanac in Trimble Planning file format e certifique-se que o ficheiro fica gravado com a extensão .alm;

2 - Vá a Almanaque --> Carregar (irá perguntar se deseja fechar o actual almanaque - confirme)
e seleccione o ficheiro de almanaque. Deverá aparecer uma janela semelhante a esta:

3 - Vamos a Ficheiro --> Estação e vamos criar a estação - ou seja a zona onde pretendemos levar a cabo as nossas missões. Para o presente exemplo usei os seguintes dados:

Latitude e Longitude - coordenadas de Torres Vedras (tiradas a partir do GoogleEarth por exemplo)

Altitude - altitude média da zona de trabalho (estimativa)

Elevação - 10º (o software irá ignorar todos os satélites que se elevem a menos de 10º no horizonte - quanto mais razante à linha do horizonte estiver um determinado satélite mais propícios estarão os sinais desse satélite a sofrer distorções)

Tempo - defino o dia e as horas em que tenho disponibilidade para ir para o terreno (neste caso o dia 15 de Março de 2011 das 10 às 18h).

Finalmente certifico-me que o fuso horário é o da minha área de trabalho e clico em Ok para criar a minha estação.

4 - Agora é só ir a Gráficos --> Número de Satélites (para obter o gráfico com as horas em que mais satélites estarão visíveis) e a Gráficos --> DOP --> DOP - Posição (para obter o gráfico com as horas em que terei a geometria mais favorável ;

Com base nestes dois gráficos podemos ter mais garantias de uma boa qualidade das nossas medições GPS. Assim, a melhor hora será entre as 11:30 e as 13:30 - é quando temos mais satélites visíveis e o melhor índice DOP. Relativamente ao índice DOP, o dia 15 de Março é bastante favorável - apenas por volta das 17H é que o índice DOP é superior a 3, pelo que devemos evitar medições por volta desta hora - não tanto pelo índice DOP mas porque é a altura em que há menos satélites disponíveis.

Este exemplo que aqui trouxe apenas deve ser seguido se a precisão for realmente um desiderarto do vosso trabalho/projecto. Se margens de erro superiores a 4m forem algo aceitávels para os vossos objectivos poderão dispensar-se ao trabalho de fazer este planeamento. Mas pelo contrário se a precisão for importante então é de todo recomendável fazerem-no.

Notas Finais: Este software não faz cálculos para o sistema EGNOS; se o cáclculo da cota/altitude for importante talvez seja aconselhável considerar o gráfico DOP - Vertical (embora para o caso das altitudes o melhor será derivá-las a partir dos pontos projectados sobre uma carta topográfica).

Melhorar a precisão das medições GPS em tempo real - 1

2011-03-09T06:58:00.000-08:00

A democratização que a tecnologia GPS conheceu nos úiltimos anos tornou os receptores GPS um equipamento acessível - por 200€ já é possível adquirir aparelhos que servem para a maioria das necessidades dos utilizadores. Os próximos posts abordarão formas de melhorar a precisão utilizando equipamentos de gama baixa.

As medições em tempo real devem seguir alguns cuidados de forma a garantir margens de erro aceitáveis (menos de 3m). As medições em tempo de real de objectos (árvores, sítios arqueológicos, sítios de interesse, áreas, etc) podem acarretar margens de erro muito grandes se algumas das origens de erro não forem atenuadas.

O sistema GPS assenta num princípio muito simples: o receptor GPS mede o tempo que os sinais de rádio emitidos pelos satélites levam a chegar ao receptor e a partir dai, por triangulação, calcula a posição do receptor. O problema é que os sinais de rádio podem sofrer distorções ao atravessar a atmosfera terrestre e, se estiveremos a trabalhar em zonas urbanas, no fundo de vales apertados/desfiladeiros ou em meio florestal estaremos ainda sujeitos aos erros de reflectância - os sinais de rádio chegam em "segunda mão" ao receptor porque fazem "ricochete" nos objectos mais próximos.

A primeira coisa que temos de fazer para diminuir a margem de erro provocada por estes fenómenos é garantir acesso a um sistema de correcção diferencial ou DGPS. Há vários tipos de correcção diferencial, mas todos eles se passam pelo envio de um segundo sinal a partir do qual o receptor GPS calibra as medições dos sinais enviados pelos satélites GPS.

O sistema DGPS mais fácil de usar e mais comum é o SBAS -Satellite-based augmentation system que para o continente europeu está implementado através da rede EGNOS - European Geostationary Navigation Overlay Service. Em condições ideais permite medições com margens de erro inferior a 2m.

Quase todos os receptores de GPS de mão ou de "trecking" trabalham automaticamente com correcções diferenciais SBAS - se procura precisão, esta é uma característrica indispensável que importa assegurar na hora de comprar um GPS. Contudo é fundamental informar-se junto do fornecedor se o aparelho trabalha com correcções EGNOS ou apenas WAAS -Wide Area Augmentation System - que também é um sistema SBAS tal como o EGNOS, mas pensado para a América do Norte, pelo que não tratá vantagens a um utilizador europeu.

Há ainda mais dois aspectos que importa considerar se quereremos assegurar o máximo de precisão com um equipamento de gama baixa - a geometria dos satélites (índices DOP) e o número de satélites visíveis - tema do próximo post.

Criar Polígonos a partir de pontos com o QGIS

2011-03-08T11:08:00.000-08:00

Quem já utilizou ou utiliza frequentemente um GPS de mão ou de trecking, certamente já reparou que o aparelho permite registar pontos e linhas/trajectos mas não áreas. Podemos registar o ponto central do que geometricamente falando seria um polígono - uma clareira, ruinas dispersas, conjunto de árvores, etc, mas não podemos desenhar directamente o polígono.

Há uma forma de ultrapassar esta limitação. Basta que registemos todos os vértices do que será o nosso polígono como pontos, atribuindo a cada ponto um nome que permite mais tarde distingui-los como vértices do polígono - por exemplo vertice1; vertice2; etc...

Descarregamos o ficheiro para o computador e guardamos no formato gpx. (formato vectorial universal para ficheiros de GPS). Depois abrimos esse ficheiro .gpx com o QGIS a partir do botão Add Vector Layer. Um ficheiro .gpx contem uma série de entidades geometricamente diferentes e surgirá um quadro a perguntar quais dessas entidades queremos acrescentar. Os nossos pontos estão armazenadas na entidade "Waypoints" e bastará essa informação para construir um polígono.

Vamos agora construir o nosso polígono a partir dos pontos. Vamos a Plugins --> Fetch Python Plugins, no separador Repositories clicamos em Add 3rd party repositories de seguida vamos ao separador Plugins e procuramos e instalamos o plugin "Points2One". Este plugin permite construir polígonos a partir de pontos. Um novo botão é adicionado à barra de ferramentas do Qgis - basta confirmar quais os dados de entrada (o layer pontos) e designar um nome para o polígono de saída que será sempre um shapefile. No final da operação basta confirmar que desejamos adicionar o polígono ao TOC (Table of contents)

Uma vez obtido o polígono podemos, por exemplo, clicar com o botão direito no layer do polígono, escolher Save As e guardar o polígono no formato .kml e visualizar o polígono no Google Earth se assim o desejarmos, ou guardar em qualquer outro formato. Não poderemos voltar a gravar em formato .gpx porque este formato não suporta geometrias do tipo polígono.

Nota importante: esta ferramenta constrói o polígono a partir da ordem em que os pontos foram registados, por isso há que seguir uma ordem quando estamos no terreno a registar o polígono, e respeitá-la. Por exemplo não podemos registar vértices no sentido dos ponteiros do relógio e depois invertermos o sentido para registar outro ponto que nos esquecemos. Se o fizermos o polígono construído sairá recortado e topologicamente incoerente.

Google Earth: Identificar zonas ou habitats com base na altitude

2011-03-04T05:07:00.000-08:00

Uma das funcionalidades SIG muito apreciadas por investigadores de várias áreas é a identificação de zonas de estudo ou zonas sensíveis com base em determinados critérios. Quando o critério se resume à altitude - determinada espécie só ocorre acima dos Xm de altitude, determinado período de ocupação humana priviligia zonas abaixo dos Xm - o Google Earth poderá ser suficiente e dispensa-nos de recorrer a software SIG mais complexo. Consideremos uma dada zona com, digamos, 50km2. Nessa zona só nos interessam as áreas que se situem acima dos 250m.

1º - Vamos a Adicionar/Add--> Poligono/Polygon e desenhamos um rectângulo que abranja a área em Estudo

2º - Vamos ao separador Estilo, Cor/Style, Color e escolhemos a cor que nos aprouver (neste caso o preto)

3º No separador altitude/altitude selecionamos a opção absoluto/absolut e definimos a altitude absoluta que queremos considerar. Todas as Zonas situadas abaixo dos 250m estão agora cobertas por um manto negro.

Caso apenas nos interessassem as zonas abaixo dos 250m bastaria alterar a simbologia do polígono aplicando-lhe uma transparência por exemplo. Este tipo de exercício é uma forma muito rápida e simples de identificar zonas inundáveis, obstáculos para a migração de aves ou, como foi o caso, zonas de Habitat.

Finalmente há que ter em conta que as altitudes indicadas pelo GE não tem como referência o mareágrafo de cascais pelo que poderão não ser as mais correctas. No entanto se 10 a 20m de erro for uma margem de erro aceitável poderão apoiar-se neste tipo de exercício.

3D com Google Earth

2011-03-04T04:02:00.000-08:00

O Google Earth é uma ferramenta fantástica que, mesmo, na sua versão gratuita é um excelente visualizador de dados - um tema que será explorado muitas vezes. Por vezes os utilizadores do GE queixam-se que o relevo não é representado realisticamente, ou que não permite uma boa leitura das variações do terreno. A imagem seguinte representaa baixa de Lisboa:

À esquerda temos o Bairro Alto e à direita o Castelo de S. Jorge, separados pela Baixa/Terreiro do Paço. Embora seja perceptível que a Baixa é uma zona de vale, podemos ter interesse em salientar as colinas que a rodeiam. Para tal basta ir a Ferramentas/Tools --> Opções/Options e no separador "Visualização 3D/3D Visualization" modificar o índice de exagero de elevação/vertical exaggeration e modificar o índice que vem por default (normalmente 0,5) para 3 e obtemos uma leitura mais evidente da morfologia da zona:

Esta técnica pode ser especialmente útil se quisermos realçar acidentes topográficos em zonas de planícies onde há poucas dezenas de metros de diferença de altitude entre os objectos.

Finalmente há que ter em conta que nas versões mais antigas do GE (5.x) é necessário activar a camada/layer de terreno/terrain, caso contrário o GE apenas trabalhará em 2D.