GIS StackExchange

Last week part of the gvSIG Team attended the Second Latin American and Caribbean gvSIG Conference. It has held in Caracas, Venezuela at Alba Caracas Hotel, organized by the National Information and Technology Centre (CNTI) and the Geographical Institute of Venezuela Simón Bolívar (IGVSB).

First two days there were a pre-conference workshops about gvSIG and SDIs, Vector  features, 3D and Raster features and finally about gvSIG 2.0 development. I’m happy to say that the conference was a complete success, mainly because the organization was amazing. If you’ve managed a +700 people conference along 3 days you can imagine the huge effort is needed to assure that everything works smooth and they did it.

Registration desk

There were some demos and presentations from the gvSIG Team but the conference was mainly run by use cases, some projects developed with gvSIG and so on. I presented the OSGeo Spanish Language Local Chapter with Francisco Palm (Venezuela) and also I had the chance to present OpenStreetMap Project with César Medina (Chile). This presentation was not prepared but as one of the planned presentations failed, well, I was invited to present OSM and the opportunities this project has in South America.

Presenting OSM project

Besides the conference we were able also to do some kind of tourism visiting CatiaTve, a complete community-driven television channel and the 23 de enero community, it’s a suburb of Caracas were they are organizing themselves to try to be as much independent as they can, they have for example their own fish farm and a quite successful radio channel (Radio Arsenal).

At CatiaTve transmission facilities

Free Software has so many opportunities to be applied in geomatic arena that it represents a real alternative to privative solutions. This maybe sounds obvious on this blog or this context but trying to convince of that topic public administrations and private companies is a huge effort. In my opinion we (not just the gvSIG Team but all the Conference presenters) did a good job showcasing the gvSIG and FOSS4G software to the Venezuelan and other Latin American people, let’s see if we have more and more use cases of succesful projects there.

Some gvSIG people with organization team and friends

Recuerdo que fue en las 3as Jornadas de gvSIG cuando finalizando una mesa redonda titulada “Software Libre y Universidad”, uno de los participantes del público que se presentó como profesor universitario lanzó una pregunta del tipo: ¿Por qué tengo que usar yo software libre si a mi me dan el software gratis?

Unos meses después en las II Jornadas SIG Libre de Girona hubo otra mesa redonda “Software libre y Proyectos de Cooperación”. Lorenzo Becchi, en papel de consultor de FAO comentó la importancia de usar software libre en este tipo de proyectos y como, en muchos casos, se utilizaba software privativo pirateado con lo que una de las enseñanzas inherentes al proyecto era la de robar. Una chica (disculparme pero no recuerdo el nombre) que participaba como representante de Ingeniera Sin Fronteras apuntó que gran parte del problema es que los ingenieros no conocían más que las herramientas privativas, que en la universidad nunca les habían formado en software libre. Y como es totalmente lógico, en proyectos de cooperación con tiempos limitados para aportar soluciones, no había tiempo para adquirir esa formación.

La Universidad forma a los trabajadores del futuro, en muchos casos en niveles de decisión relevantes en los más diversos sectores. Los universitarios de hoy serán, sin duda, decisivos en el rumbo del mañana. La Universidad, pues, tiene una gran responsabilidad en las herramientas de software que utiliza. La decisión de propagar dependencia tecnológica entre sus alumnos no es un asunto baladí, sino que tiene consecuencias de todo tipo en la sociedad que estamos construyendo.

Dos mesas redondas, dos jornadas, con una pregunta y respuesta enlazadas. O como cantaba Sabina en los años de La Mandrágora…círculos viciosos.

Así que te estarás preguntando, "Todo esto de OSM es muy bonito y tal, pero
¿qué significa para nosotros, los profesionales del SIG?" Bueno, o no significa nada o lo significa todo. Elige.

Dicho eso, el participar es una elección mía. Puedo ignorar totalmente OSM.
Como un profesional que tiene al alcance de los dedos un SIG maduro de todo
el condado, OSM no tiene nada que yo no tenga ya. ¿Ejes de vía? Por supuesto.
¿Contornos de edificios? Hasta la última caseta del condado. ¿Uso del
terreno? ¿De qué año lo quieres?. Bueno, hay una cosa que yo no tengo. La
comunidad.

A principios de año comenzamos a permitir la distribución de la planimetría de
1997, puesto que había llegado al fin de su vida útil. Después de anunciar la disponibilidad en nuestro sitio web, recibí una petición FOIA [un tipo de solicitud de datos del sector público] de estos datos. Me explicaron que la intención era utilizar esos datos en OpenStreetMap, y que realmente todo lo que querían eran los contornos de edificios. Así que les envié un shapefile comprimido y... bueno, podéis ver el resultado vosotros mismos.

Todo en unas pocas semanas. Todo por alguien que ni siquiera vive en la zona, sólo cree en el proyecto. Impresionante. Definitivamete yo no tengo ese tipo de voluntarios. Por eso OSM tendrá éxito. Por eso es fantástico.

Atualmente temos no Brasil 5561 municípios, de diversos tamanhos. Gerenciar um município e todos os seus serviços é uma tarefa complicada, pela multiplicidade de usuários que devem ser atendidos (a população), e diversidade de serviços oferecidos (educação, saúde, segurança, lazer, moradia).

Como administrar tudo isso, de forma coesa e inteligente? Muito poucos municípios tem hoje a capacidade de construir um sistema de informações geográficas, por diversos motivos: preço do desenvolvimento de um sistema integrado, preço do software (licenças proprietárias), treinamento de mão-de-obra e manutenção deste centro de inteligência espacial.

Enfim, é muito caro coletar e organizar dados geográficos, mas é uma ação municipal que tem retorno imediato, não somente no caixa, mas em agilidade na prestação dos serviços e por conseguinte satisfação da população em geral.

Além disto, os custos para realizar diversas operações diminuem exponencialmente. Ordens de serviço são precisamente direcionadas ao problema, sem desperdícios ou prestando serviços desnecessários.

Iremos abordar em uma série de artigos a construção de um sistema de apoio de decisões para um prefeitura municipal fictícia. Serão utilizados softwares livres para o desenvolvimento desta solução, mas isto não lhe impede de desenvolver este tipo de sistema utilizando um software proprietário - os resultados práticos são os mesmos.

O tema será abordado em paralelo, mostrando tanto o esboço de uma arquitetura sistêmica, o desenho de um pequeno banco de dados espacial e a construção de um ambiente WEB para visualização das informações espaciais no navegador de internet comum.

Os primeiros artigos serão bastante simples e conforme caminharmos, iremos adicionar complexidade ao sistema, com consultas, relatórios e regras de negócio avançadas. Iremos adicionar inteligência ao sistema aos poucos.

Portanto leitor, seja bem vindo à esta série de artigos que estamos escrevendo com o intuito de mostrar o que Geoprocessamento realmente é. Esqueça os "mapinhas", pense em inteligência geográfica. Como sempre, você são encorajados à participarem ativamente deste processo, pelo blog ou via email. Aguardmos ansiosos pelo seu feedback.

1 - Arquitetura do sistema

Primeiramente precisamos pensar o que nosso sistema irá fazer, quem irá atender e como irá atender. Não é possível dentro de um prazo e custos razoáveis, atender todas as demandas de desenvolvimento que uma prefeitura municipal de médio porte terá. Mas é possível limitar este escopo e prever como o sistema deverá crescer. Por isso devemos ter em mente uma arquitetura que possa escalar e seja robusta.

Existem milhares de estudos sobre arquitetura que devemos fazer ANTES de iniciarmos um projeto desse porte. Mas não iremos realizar os estudos. Porque? Vamos construir um sistema pequeno para uma prefeitura pequena e não temos em mente muitos usuários simultâneos. O que quero deixar claro é que esta etapa deve existir e não pode ser descartada em qualquer projeto real e deve ser feito inclusive, por um profissional COMPETENTE.

Bem, o que nosso sistema irá fazer? Irá cartografar alguns temas de nossa cidade fictícia como lotes, quadras, praças, logradouros, bairros entre outros e disponibilizar a consulta destes temas via internet. Inicialmente, este será nosso objetivo. É uma missão bem simples, mas que já pode ajudar um administrador a entender seu espaço, seu município e seus habitantes.

O que precisamos para fazer isto? Logo de início, precisamos ter em mãos os dados espaciais a serem manipulados. Pelo fato de requerer custos elevados, muitas vezes nos deparamos com a falta de informação espacial para manipulação. Isso ocorre por, na maioria das vezes, o orçamento do lugar, cidade, estado, não cobrir a necessidade dos gastos totais local, o que redireciona os investimentos do lugar para problemas mais urgentes, ficando o planejamento do espaço em segundo plano.

Tendo em mãos estes dados, precisamos de uma forma confiável de armazena-los e lê-los, portanto precisamos de um banco de dados, geográfico! Só um banco de dados pode possibilitar multiplos usuários leitores, multiplos usuarios editores sem que haja quebra na consistência de informações. Para isto, a maioria dos bancos de dados relacionais, utiliza alguns princípios chamados de ACID (Atomicidade, Consistência, Isolamento e Durabilidade) detalhar isto aqui, mas fica para um próximo artigo) e são eles que garantem que tudo o que tenho dentro daquele banco de dados é uma informação verdadeira, ou seja, consistente e íntegra.

Como iremos inserir os dados no banco? Utilizaremos um software SIG desktop para a tarefa. Este tipo de software suporta conversão de coordenadas, edição de geometrias, customização de simbologia, geração de mapas temáticas, consultas complexas, entre outras funções. O importante é que este software ficará a disposição, em nosso caso fictício, de uma pequena parcela de funcionários da prefeitura, treinados e compententes para operar um software com toda esta complexidade. Não que todos não pudessem aprender, mas é melhor dividir para conquistar. Com um número reduzido de usuários responsável pela inserção/deleção/atualização de registros, temos maior segurança e podemos prevenir desastres em nossas preciosas bases cartográficas.

Além disso precisaremos de um servidor de mapas. Precisamos publicar nossas informações na internet, através de mapas coloridos. Um servidor de mapas é o responsável por entender os pedidos do navegador de internet ("me dê aquela extensão geográfica ali, com as camadas de logradouros, quadras e hidrografia, para ontem!") e traduzir sua resposta em gráficos. Em alguns casos, o servidor de mapas entende o pedido e gera as imagens, em outros, manda as informações para o navegador interpretar e desenhar aquele lindo mapa em sua tela.

Figura 01 - Arquitetura simplificada do sistema

1.1 - Escolha de ferramentas

Bem, escolhemos como banco de dados o PostgreSQL 8.4 com sua extensão espacial PostGIS 1.5. Porquê? Bem, conforme mencionamos no começo do artigo, iremos trabalhar com ferramentas livres, ao invés de proprietárias, mas existem algumas razões técnicas para isto:

• É o mais completo banco de dados (livre) da atualidade;

• O PostgreSQL é o banco de dados que faz menos extrapolações do padrão SQL. Portanto, desenvolver para PostgreSQL, quase sempre é estar de acordo com o padrão.

• O PostGIS, sua extensão espacial, é a mais madura do mercado. Tem o maior número de funções, funciona muito bem e com certeza dá uma lavada em outras implementações espaciais.

• O PostGIS segue o padrão aberto OGC (Open Geospatial Consortium), ou seja, informação dentro do PostGIS se comunica com todos os softwares de SIG/GIS que implementam o padrão.

• O PostGIS é livre e gratuito.

O PostgreSQL ainda nos permite interação com diversas linguagens de programação, para aumentar sua capacidade de análise espacial, como a pl/R e como a pl/python que nos irá ajudar a criar futuramente um ambiente web completo.

O software SIG desktop escolhido foi o QGIS. A resposta para esta escolha, é que antes de tudo, o Quantum GIS é um software livre! É um projeto que faz parte da OSGeo, e que roda em diferentes plataformas (Unix, Linux, MacOSX e Windows), além de suportar dados vetoriais, raster e formatos de banco de dados. Atrevés do QGIS, é possivel gerenciar, manipular e analisar os dados trabalhados, bem como compor mapas para impressão.

Para o servidor de mapas, iremos utilizar o GeoServer. O GeoServer é um projeto bastante maduro, é utilizado mundo afora e suporta os principais protocolos especificados pela OGC - Web Map Services, Web Feature Services, entre outros. Em conjunto com o GeoServer, usaremos o OpenLayers para trabalhar como cliente do GeoServer e construir nosso mapa - dentro do navegador.

2 - Temas e Feições

Em suma, um SIG armazena informações de forma relacional, da mesma forma que um banco de dados tradicional. A diferença é que o SIG permite e lhe dá
ferramentas para armazenar de forma eficiente informações espaciais: pontos, linhas, polígonos e outras geometrias mais complexas, como coleções de
geometrias, geometrias em três dimensões, etc..

As ferramentas que o sistema lhe fornece são composta basicamente de operações matemáticas sobre objetos dispostos em um plano euclidiano (existem ferramentas
avançadas que se dão em uma esfera, como a superfície da Terra), tais como: intersecção, união, disjunção, soma, subtração, distância, área, entre outras.

Existem diversas operações que podemos realizar com as geometrias dos objetos, e chamamos isto de análise espacial. É através da análise espacial e pesquisa relacional em um banco de dados que conseguimos os fantásticos resultados, que não seriam obtidos de nenhuma outra maneira.

Em nosso pequeno sistema, vamos armazenar algumas informações cruciais para a administração pública: sistema viário, quadras, lotes, bairros, linhas e pontos de ônibus e pontos de táxi. A administração de nossa prefeitura fictícia quer uma atualização cartográfica geral e um controle maior sobre o transporte neste município.

A prefeitura fictícia nos forneceu estas informações e nos mostrou como são armazenadas hoje. À partir daí podemos começar com a modelagem de dados e a construção de nosso banco de dados espacial.

2.1 - Sistema Viário

A prefeitura quer um levantamento e organização completa de seu sistema viário. Atualmente eles não tem nada armazenado em forma digital, mas querem uma solução que seja compatível com geocodificação, roteamento e sirva para construção dos itinerários de linhas de ônibus.

Bem, como temos requisitos funcionais (geocodificação e roteamento) precisamos pensar em uma forma de construir esta base de logradouros de uma forma que nos permite posteriormente, implantar estas funcionalidades para a prefeitura.

Uma estrutura relacional comumente aceita para representar este tipo de informações é criar uma linha por logradouro, de seu ponto inicial ao seu ponto final, indicando as seguintes informações: Código Logradouro,Tipo Logradouro, Nome Logradouro, CEP Logradouro. Mas temos nosso requisitos. Nosso sistema quase nunca teria uma linha de ônibus que segue um logradouro de seu início ao seu final, sem nenhuma virada, por exemplo. Temos ainda a questão de preparar o sistema para o roteamento e geocodificação. É muito mais prático, dividir este elemento "logradouro" em partes atômicas, que nunca irão se alterar (com exceção, claro, de uma alteração do traçado viário) ou ser divididos em pedaços menores por alguma necessidade (como um ônibus virar a esquina, por exemplo).

Definido isto, temos a seguinte estrutura: Código Logradouro, Código Trecho Logradouro, Tipo de Logradouro, Nome Logradouro, CEP Logradouro. Estamos apenas preparando a base para demandas futuras, então lembrem-se, não iremos implementar tudo de uma vez. Esta estrutura será suficiente. O importante é entender a divisão de informações que iremos realizar. Também vamos assumir que todo o traçado dos eixos serão realizados no sentido do tráfego, ou seja, o ponto inicial flui para o ponto final do logradouro ou trecho.

Neste esquema a tabela não está apropriadamente normalizada. Precisamos normalizá-la para um funcionamento eficiente de informações. Mas porque? Note que um logradouro terá um ou mais trechos, e estamos repetindo à cada trecho as informações Tipo de Logradouro e Nome de Logradouro. A normalização permitirá que entremos com esta informação apenas uma vez e referenciemos esta à uma outra tabela.

Em SQL, ficaria assim:

 	CREATE TABLE tp_logradouro
	(
		cd_tp_logradouro SERIAL NOT NULL, -- nossa chave primária
		dc_tp_logradouro VARCHAR(30) NOT NULL, -- a descrição do tipo de logradouro
		CONSTRAINT tp_logradouro_pk PRIMARY KEY (cd_tp_logradouro)
	);

        CREATE TABLE logradouro
	(
		cd_logradouro SERIAL NOT NULL, -- nossa chave primária
		tp_logradouro INTEGER NOT NULL REFERENCES tp_logradouro (cd_tp_logradouro),
		nm_logradouro VARCHAR(75) NOT NULL,
		CONSTRAINT logradouro_pk PRIMARY KEY (cd_logradouro)
	);

	CREATE TABLE trecho_logradouro
	(
		cd_trecho SERIAL NOT NULL, -- nossa chave primária
		cd_logradouro integer NOT NULL REFERENCES logradouro (cd_logradouro), -- aqui estamos referenciando a tabela logradouros.
		no_vias integer NOT NULL,
		no_faixas integer NOT NULL,
		cep_trecho VARCHAR(9) NOT NULL DEFAULT '00000-000',
		CONSTRAINT trecho_logradouro_pk PRIMARY KEY (cd_trecho)
	);

	CREATE TABLE numeracao_trecho_logradouro
	(
		cd_trecho INTEGER NOT NULL REFERENCES trecho_logradouro (cd_trecho),
		no_inicial_esq INTEGER NOT NULL DEFAULT 0,
		no_inicial_dir INTEGER NOT NULL DEFAULT 0,
		no_final_esq INTEGER NOT NULL DEFAULT 0,
		no_final_dir INTEGER NOT NULL DEFAULT 0,
		-- já estamos dizendo que só podemos ter um trecho com estas informações.
		-- não é possível repetir cd_trecho com numerações diferentes
		CONSTRAINT numeracao_trecho_logradouro PRIMARY KEY(cd_trecho)
	);

	CREATE TABLE sentido_trecho_logradouro
	(
		cd_trecho INTEGER NOT NULL REFERENCES trecho_logradouro (cd_trecho),
		dc_sentido VARCHAR(2) NOT NULL DEFAULT 'FT',
                -- os valores possíves de sentido são FT (From To), TF (To From) e FF (From From - duas mãos)
		CONSTRAINT sentido_trecho_logradouro_pk PRIMAKEY KEY (cd_trecho)
	);

	-- vamos adicionar uma coluna geométrica à trecho_logradouro

	SELECT * FROM AddGeometryColumn('public','trecho_logradouro','the_geom',-1,'LINESTRING',2);

Com estas tabelas, modelamos toda a parte de sistema viário para nossa prefeitura. Não foi complicado né? Com estas tabelas, temos informações suficientes para estabelecer rotinas de geocodificação e roteamento parcial. Para estabelecermos um roteamento completo temos ainda de ter tabelas sobre as "viradas" possíves, também chamadas de turn tables.

Modelo Entidade Relacionamento do Sistema Viário

Ainda vamos adicionar suporte para as turn-tables e quem sabe mais para frente, adicionamos em nossa aplicação o pgRouting, extensão do PostGIS responsável para realizar roteamento.

Por que modelar o sistema viário em primeiro lugar? Bem, o sistema viário, é de vital importância para qualquer cidade média do mundo e com uma sólida representação do SV podemos apoiar outras partes de nosso sistema no mesmo. Uma parte que dependerá completamente do "módulo" sistema viário será o módulo de transporte público, pois utilizaremos muito geocoding para construir automáticamente as rotas de ônibus, entre outras coisinhas.

A explicação do código:

A tabela logradouro irá armazenar toda nossa informação estática sobre um conjunto de trechos de mesmo nome. A tabela trecho irá conter as informações que variam de trecho para trecho, mesmo que aqueles dois trechos distintos pertençam ao mesmo logradouro.

O relacionamento descrito pelo código na tabela trecho_logradouro "REFERENCES...", indica que um trecho deve pertencer a apenas um logradouro válido na tabela logradouro. Evitamos assim erros e duplicação de informação. Por enquanto, nossa cidade e base de dados é pequena, mas imagine daqui alguns anos? Seria uma complicação manter isto organizado, caso não utilizassemos este formato.

Por último, adicionamos uma coluna geométrica do tipo LINESTRING à tabela trecho_logradouro. Agora podemos começar inserir informações geográficas nesta tabela.

Nota: o SRID (Spatial Reference ID) -1 foi utilizado pois estamos trabalhando com um município fictício. Aqui deve aparecer o código do seu sistema de referência / datum. Lembre-se disto durante toda série de artigos .

No próximo artigo iremos trabalhar com o transporte público. Iremos modelar toda a parte de linhas, pontos de parada, sentidos de transporte (bairro - centro; centro - bairro), táxis, etc.

O que acharam?

Abraços,

George R. C. Silva

Related posts:

1. Desenvolvendo um SIG para Suporte de Decisões Municipais #2
2. History Tables – pt 1
3. Criação de Templates para PostGIS

Os ficheiros CAD são uma das principais fontes de dados para um SIG.  Este artigo analisa as possibilidades actuais de lidar com CAD no Quantum GIS.

CAD e SIG

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

Simbologia é informação

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

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

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

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

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

CAD	SIG

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

Então qual é o problema?

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

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

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

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

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

Então e agora?

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

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

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

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

QGIS

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

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

O caso DXF

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

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

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

O caso DGN

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

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

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

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

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

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

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

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

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

O caso DWG

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

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

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

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

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

Conclusão

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

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

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

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

Até breve.

Olá Pessoal!

Antes de passar a dica de hoje, quero informar que provavelmente irei diminuir o ritmo da quantidade de postagens, pois iniciei um novo projeto de minha vida profissional esta semana, o qual irá exigir ainda mais de meu tempo. Conto com a colaboração de todos.

Pois bem, a dica de hoje é bem breve e é sobre um mapa interativo que pode servir como excelente fonte de pesquisa e informação para diversas áreas.

A aplicação permite visualizar em tempo real o aumento da população mundial, nascimentos, mortes e emissões de dióxido de carbono (CO2). Também é possível acessar a estas informações por países.

Para acessar este Webmapping, clique aqui.

—
Anderson Maciel Lima de Medeiros
Tecnólogo em Geoprocessamento
Consultor em Geotecnologias Livres
Acesse: www.clickgeo.com.br

Estive em Natal-RN participando de reuniões técnicas e apresentações sobre o i³Geo com os amigos Eduardo e Joaquim do Idema. Iremos adotar o sistema no meu trabalho, portanto, nada melhor que buscar o know-how de pessoal com expertise no tema.

Durante as reuniões, foi-me apresentado como instalar e gerir o sistema. Garanto que preciso estudar um pouco mais, uma vez que nunca tive contato com WMS/WFS.

Como parte do meu aprendizado, disponibilizo aqui, na íntegra, um tutorial existente no Wiki do i³Geo, já que o acesso ao material exige cadastramento no portal.

MANUAL DE INSTALAÇÃO DO I3GEO NO UBUNTU

1. INTRODUÇÃO
O Ubuntu é um sistema operacional baseado em Linux (Debian) e pode ser obtido na página http://www.ubuntu-br.org. Esta distribuição possui uma interface amigável e ferramentas para a montagem de ambientes de fácil manuseio, sendo recomendado para usuários com pouca experiência em sistemas operacionais Linux.
No Ubuntu, você pode configurar o servidor para a utilizar o I3Geo de 3 formas, sendo elas:
a.Gerenciador de Pacotes Synaptic – é uma feramenta de busca e instalação de pacotes disponíveis para o Ubuntu com interface gráfica, recomendada para usuários com pouca experiência em Linux.
b.Linha de Comando – o usuário pode instalar os pacotes digitando a linha de comando no terminal do Ubuntu a partir do comando apt-get.
c.Compilação dos Códigos Fonte – o usuário pode baixar os códigos fontes dos requisitos necessários para o funcionamento do I3Geo e compila-los no Ubuntu. Recomendado apenas para usuários com experiência em Linux.
Este documento tratará da instalação dos pacotes via Gerenciador de Pacotes Synaptic e pelo comando apt-get.

2. CONFIGURANDO O SERVIDOR
2.1 SERVIDOR WEB APACHE
O primeiro passo para fazer o I3Geo funcionar, é instalar o servidor web Apache (www.apache.org), para tanto basta o usuário acessar o Gerenciador de Pacotes Synaptic no menu Sistemas >> Administração e no campo procurar digitar apache2. De um duplo clique na opção apache2, o gerenciador de pacotes irá procurar todas as dependências do apache necessárias para a instalação, clique em marcar e depois em aplicar e o apache será instalado.
Outra forma de instalar o apache é abrir o terminal do Ubuntu e digitar:
sudo apt-get install apache2
2.2 PHP5 e PHP_MapScript
Da mesma forma que a instalação do apache abra o Gerenciador de Pacotes Synaptic e em procurar digite PHP5 (www.php.net). Certifique-se que o Ubuntu instale os seguintes componentes:
-php5
-php5-common
-php5-curl
-php5-dev
-php5-gd
-php5-mapscript
-php5-odbc
-php5-pgsql
-php5-ps
-php5-xmlrpc
-php5-xsl
-libapache2-mod-php5

Linha de comando para instalação via terminal:
sudo apt-get install php5

2.3 MAPSERVER CGI
O MapServer CGI é usado para a criação de webservices cartográficos no padrão WMS e WFS, por este motivo recomendamos sua instalação no servidor. Para instalar o MapServer basta digitar mapserver no Gerenciador, marcar o pacote cgi-mapserver e aplicar a instalação, ou digitar no terminal o comando a seguir:
sudo apt-get install cgi-mapserver

Na instalação do cgi-mapserver o Ubuntu instala as blibliotecas Proj, Geos e Gdal como dependência do mapserver, verifique se estas bibliotecas foram de fato instaladas no servidor, pois elas são necessárias para o funcionamento do I3Geo.

2.4 POSTGRESQL e POSTGIS
O postgreSQL (www.postgresql.org) é um banco de dados livre que possui uma extensão espacial, o PostGis, para armazenar dados geográficos. Se você pretende utilizar o I3Geo com arquivos vetoriais (Shapefile, GML, …) não é necessário instalar o postgresql, caso queira montar um banco de dados espacial, a instalação do postgresql pode ser feita a partir do Gerenciador de Pacotes Synaptic, digitando no campo procurar postgresql-8.1 e o pacote postgis, você pode instalar também o pgadmin para gerenciar os bancos criados. Pela linha de comando é só digitar no terminal:
sudo apt-get install postgresql-8.1 postgis

2.5 R
O R é um pacote estatístico utilizado pelo I3Geo para gerar gráficos e fazer algumas análises espaciais. A não instalação do R prejudica algumas funcionalidades do I3Geo, mas não impede o seu funcionamento. Para instala-lo procure no gerenciador synaptic os pacotes r-base e r-base-core marque-os e mande o gerenciador aplicar, ou digite no terminal:
sudo apt-get install r-base r-base-core

As novas versões da extensão SpatStat (1.12.3 ou mais recentes), necessitam da versão 2.6.0 do R. Se você for instalar estas versões siga os seguintes procedimentos:

a. Baixe o pacote r-base-core 2.6.1-1feisty0 i386.deb, se você usa a versão do Ubuntu Feisty, ou o pacote r-base-core 2.6.1-1gutsy0 i386.deb, se você usa a1. versão do Ubuntu Gutsy, na página http://www.r-project.org.
b1. Instale o programa a partir do seguinte comando dpkg  -i nome do pacote .deb
c1. Siga os procedimentos abaixo para a instalação do spatstat.

Após a instalação do R, você deve instalar a extensão spatstat, para isto baixe o arquivo spatstat_1.12-0.tar.gz da página www.spatstat.org/spatstat no menu download. Depois de baixar o arquivo entre no terminal do Ubuntu, no diretório onde o arquivo foi salvo (ex: /home/download) e digite o comando abaixo:
sudo R CMD INSTALL spatstat_1.12-0.tar.gz

Obs: para instalar o spatstat você precisa ter instalado no Ubuntu as bibliotecas gfortran e g++, que podem ser instaladas pelo gerenciador de pacotes ou pelo comando:
sudo apt-get install gfortran g++

2.6 GHOSTSCRIPT
Por fim instale o ghostscript, necessário para geração de imagens pelo R, a partir do Gerenciador de Pacotes Synaptic, buscando os pacotes gs-common, gs-esp, gs-esp-x, gsfonts e libgs-esp8, ou digitando o comando:
sudo apt-get install gs

3.  CONFIGURANDO O I3GEO
Copie a pasta I3geo (http://mapas.mma.gov.br/download ou do SVN do Portal) para um diretório do apache (padrão do Ubuntu /var/www/) e configure os endereços da aplicação conforme instrução abaixo:

3.1 MS_CONFIGURA.PHP
Abra o arquivo /i3geo/ms_configura.php em um editor e configure os caminhos da aplicação, note que a primeira variável é responsável pela mensagem inicial do I3Geo, você pode colocar uma mensagem personalizada alterando o texto da variável, conforme indica o exemplo abaixo:
$mensagemInicia = “minha aplicação”

O primeiro bloco de código diz respeito a instalação no windows, o segundo bloco é a configuração para o linux, você deve alterar as variáveis conforme indica o exemplo abaixo:

$editores = array(“meu IP”);

Obs: se você não for usar o editor de mapfile deixe o array vazio.

- Diretório temporário

$dir_tmp = “/var/tmp/ms_tmp”;

Obs: certifique-se que este diretório esteja visível pelo apache e que ele tenha permissão de escrita.

Obs: recomenda-se a criação de um link simbólico na pasta /var/www/ direcionado para este diretório, conforme exemplo abaixo:
/var/www/: sudo ln – s /var/tmp/ms_tmp ms_tmp

- Localização do diretório onde estão os arquivos .map

$temasdir = “/var/www/i3geo/temas”;

- Localização do diretório aplicmap

$temasaplic = “/var/www/i3geo/aplicmap”;

- Localização do mapserver cgi

$locmapserv = “/cgi-bin/mapserv”;

Obs: o mapserver cgi no Ubuntu fica no diretório /usr/lib/cgi-bin/mapserv, crie um link simbólico apontando para este diretório, conforme exemplo abaixo:

/var/www/: sudo ln -s  /usr/lib/cgi-bin/mapserv cgi-bin

- Localização da aplicação.

$locaplic = “/var/www/i3geo”;

- Localização do xml que registra os sistemas.

$locsistemas= “http://localhost/i3geo/menutemas/sistemas.xml”;

Obs: se você não for cadastrar nenhum sistema na aplicação deixe essa variável vazia, apenas com “”.

- Localização do xml que registra funções específicas na janela identifica do I3Geo.

$locidentifica = “http://localhost/i3geo/menutemas/identifica.xml”;

Obs: se você não for cadastrar nenhum sistema na aplicação deixe essa variável vazia, apenas com “”.

- Localização do xml que contém as pré configurações de mapas.

$locmapas = “http://localhost/i3geo/menutemas/mapas.xml”;

Obs: se você não for configurar nenhum mapa na aplicação deixe essa variável vazia, apenas com “”.

- Localização do programa R.

$R_path = “R”;

Obs: se vc não instalar o R, deixe essa variável vazia.

- Conexão com o banco PostGis.

$postgis_con = “user=meuusuario password=minhasenha dbname=meubanco host=localhost port=5432″;

Obs: o uso do Postgis nesse caso é opcional e não tem relação com o armazenamento dos dados para usar no I3Geo. O Postgis é utilizado pelo I3Geo em algumas funções de cálculo de geometrias, sendo que a não instalação do Postgis não afetará o restante.

- SRID

$srid_area = 1;

Obs: o uso do Postgis nesse caso é opcional e não tem relação com o armazenamento dos dados para usar no I3Geo. O Postgis é utilizado pelo I3Geo em algumas funções de cálculo de geometrias, sendo que a não instalação do Postgis não afetará o restante.

- Mascara de conexão com bando de dados no arquivo mapfile.

$postgis_mapa =”user=meuusuario password=minhasenha dbname=meubanco host=localhost port=5432″;

Obs: os mapfiles do diretório temas que tiverem CONNECTION ” “, terão a string de conexão substituída, se não for desejado a substituição, deixe essa variável em branco.

3.2 GERAL1.MAP
Abra o arquivo /i3geo/aplicmap/geral1.map em um editor e configure os caminhos no mapfile conforme mostra o exemplo abaixo:

- Caminho para o diretório onde estão as fontes

FONTSET “escreva aqui o caminho da pasta contendo as fontes que serão utilizadas pelo mapserver”

EX.: “/var/www/i3geo/symbols/fontes.txt”

- Caminho para o diretório onde estão os símbolos.

SYMBOLSET “escreva aqui o caminho da pasta contendo os símbolos que serão utilizadas pelo mapserver”

EX.: “/var/www/i3geo/symbols/simbolos.sym”

- Caminho da pasta onde ficam os arquivos ShapeFiles

SHAPEPATH “escreva aqui o caminho da pasta contendo os arquivos Shapefiles que serão utilizadas pelo mapserver”

EX.: “/var/www/geodados”

- Caminho da pasta onde está a imagem do mapa de referência

IMAGE “escreva aqui o caminho da pasta contendo a figura usada como mapa de referência”

EX.: “/var/www/i3geo/imagens/referencia1.png”

- Caminho da pasta onde ficam os arquivos temporários gerados pelo mapserver

IMAGEPATH “escreva aqui o caminho da pasta onde serão gerados os arquivos temporários”

EX.: “/var/tmp/ms_tmp/”

- Caminho da URL da pasta temporária

IMAGEURL “é recomendado que a imageurl seja um link simbólico para a imagepath”

EX.: “/ms_tmp/”

- Caminho da pasta onde esta o arquivo de template

TEMPLATE “escreva aqui o caminho da pasta onde esta o arquivo de template”

EX.: “/var/www/i3geo/aplicmap/geral.htm”

Você deve configurar a tag DATA de todas as LAYERS do arquivo geral1.map conforma o exemplo abaixo:

LAYER

DATA “/var/www/i3geo/aplicmap/dados/zee”

Obs: Você deve alterar a tag DATA do arquivo estadosl.map apontando para a localização correta dos dados.

3.3. GERAL.HTM
Se você alterou o nome da pasta I3Geo, abra o arquivo /Novo Nome/aplicmap/geral.htm em um editor e modifique as variáveis:

g_locaplic = “http://”+window.location.host+”/Novo Nome”;

g_localimg = “http://”+window.location.host+”/Novo Nome/imagens”;

Você já conhece a Revista Espírito Livre? A revista é distribuída gratuitamente no formato PDF.

O número mais recente (N° 15) deste importante periódico sobre tecnologias livres com o tema de capa: Sistemas Gerenciadores de Conteúdo. Os textos são distribuídos segundo os termos da Creative Commons.

Creio que esta é uma boa dica de leitura para os entusiastas do software livre. Você pode baixar a versão mais recente da publicação clicando aqui.

Dentre os artigos da edição N° 15, eis as matérias que mais chamaram minha atenção:

Pág. 14 – Portabilidade de Software
Pág. 73 – Use Software Livre, Não Use “Software Pirata”
Pág. 76 – Software Livre e suas origens

Você pode baixar as edições anteriores da revista acessando este link ou clicando nos títulos abaixo. Vale destacar que cada uma delas apresenta diversos outros assuntos.

N° 01 – Computação em Nuvem
N° 02 – Leveza, estabilidade e Performance
N° 03 – Wiki- E os novos modelos de construção de conhecimento
N° 04 – Games
N° 05 – Linux no Desktop
N° 06 – Edição de Vídeo
N° 07 – Software Livre na Educação
N° 08 – Comunidades e Movimentos Livres
N° 09 – Redes Sociais
N° 10 – Diversão Livre
N° 11 – Computação Gráfica e Software Livre
N° 12 – Liberdade na Internet
N° 13 – Projeto GNU
N° 14 – P2P

Fica ai a dica pessoal. Um Abraço!

–
Anderson Maciel Lima de Medeiros
Tecnólogo em Geoprocessamento
Consultor em Geotecnologias Livres
Acesse: www.clickgeo.com.br

O primeiro software livre de SIG com o qual tive contato foi o Kosmo, isso ainda na época em que ele estava na versão 0.83. Desde então vi o “crescimento” deste programa tanto no que se refere ao aumento de funcionalidades como no número de usuários.

Aproveito esta oportunidade para informar a comunidade que estou preparando uma boa novidade referente ao Kosmo GIS e que deve ser “lançada” antes do fim do ano. Em breve darei mais detalhes sobre este assunto.

Por hora, estou disponibilizando para vocês a apresentação de slides que preparei sobre o  software de SIG Kosmo por ocasião do lançamento da versão 2.0 RC-1.

Espero que gostem do material. No final desta postagem há um link para baixar a publicação no formato PDF.

Então pessoal, fiquem atentos as novidades do Portal ClickGeo e daqui do Blog Anderson Medeiros.

Claro que não é algo obrigatório, mas se for possível, gostaria de pedir que deixem seus comentários sobre esta apresentação para que ela seja aprimorada. O objetivo aqui é uma ajuda mútua.

Você pode baixar a versão em PDF da apresentação clicando aqui.

Um Abraço!

–
Anderson Maciel Lima de Medeiros
Tecnólogo em Geoprocessamento
Consultor em Geotecnologias Livres
Acesse: www.clickgeo.com.br

Minha Cidade, Meu Futuro (MC, MF) é um projeto de mapeamento virtual participativo que promove o empoderamento dos jovens, para que atuem como agentes de mudanças em comunidades com poucos recursos. MC, MF apresenta uma oportunidade para os jovens da comunidade para fazer “uma análise ao longo do tempo” em termos de população crescimento, recursos (água, eletricidade, saneamento), planejamento urbano, questões sociais e  representação política. Através do MC, MF, os jovens vão criar mapas que contenham uma narrativa do passado, presente e futuro das suas comunidades para: 1) desenvolver e promover um sentimento de orgulho da comunidade, legitimidade, e lugar na Cidade; 2) criar um arquivo sobre a comunidade na internet; 3) influenciar mudanças através da criação de visões de um futuro melhor, que a equipe MC, MF irá encaminhar aos formuladores de políticas públicas/tomadores de decisões na cidade.

A primeira fase do projeto consiste em um mini-curso de 3 semanas com jovens de 13-15 anos da favela Santa Marta, no Rio de Janeiro. Nas oficinas, a equipe introduzirá noções de mapeamento e facilitará discussões com os jovens sobre como a juventude pode fazer planos de melhorias para a comunidade, no futuro. Na última semana, os jovens serão capazes de ver como seus mapas feitos à mão podem ser representados no site ao testarem o protótipo de uma ferramenta de mapeamento, desenvolvida no MIT.

MC, MF é uma colaboração entre Andrew Merkin, licenciado na Universidade MIT/Sloan, e as estudantes Alix Beranger e Katarzyna Balug da Faculdade de Desenho e Planejamento Urbano da Universidade Harvard. MC, MF recebeu o prêmio Concorrência ‘MIT IDEAS’ e a concessão de viagens internacionais da Universidade de Harvard. O Programa Rede Jovem atua como parceiro comunitário do projeto MC, MF. A Rede Jovem foi selecionada como responsável pela articulação de parcerias comunitárias  em função da experiência na execução de projetos sociais e de estímulo à participação de jovens através das novas tecnologias, há dez anos, e pela realização do projeto Wikimapa.

Esta semana não haverá muita movimentação aqui pelo Blog uma vez que estou em San Diego na ESRI International User Conference. Podem acompanhar alguns detalhes pelo twitter filtrando por #esriuc. (http://twitter.com/sandrobatista)

Quando voltar, darei a conhecer algumas das novidades!

Algo que se ouve muito é Partilha e Colaboração!

Sandro

Partilhar:        

Olá Pessoal! Hoje li uma notícia muito interessante no Blog Geo.NET e resolvi divulgar aqui neste espaço.

Trata-se do GeoINFO 2010! Será a décima primeira edição do Simpósio Brasileiro de Geoinformática.

O GeoINFO constitui uma série de conferências científicas no formato de fórum para exploração da pesquisa em andamento e do desenvolvimento das novas aplicações em Sistemas de Informação Geográfica (SIG) e áreas afins.

Os artigos devem descrever pesquisas originais, preferencialmente em andamento ou que foram recentemente publicadas. Um comitê internacional científico faz a revisão dos artigos que devem ser submetidos em Inglês em suas versões completas.

O evento proporciona aos participantes o conhecimento das novidades do ramo das Geotecnologias e prever quais serão os tópicos de ponta da pesquisa e desenvolvimento na área.

As temáticas para submissão de trabalhos são:

• Bancos de dados espaciais e espaço-temporais;
• Modelagem de dados espaciais e espaço-temporais;
• Mineração de dados espaciais e espaço-temporais;
• Data warehouses espacias e espaço-temporais;
• Múltiplas representações em bancos de dados espaciais;
• Análise de dados sobre objetos móveis;
• Métodos de acesso espaciais, espaço-temporais e multidimensionais;
• Processamento e otimização de consultas espaciais;
• Estruturas de dados espaciais;
• Geometria computacional aplicada;
• Visualização de dados espaciais;
• Ontologias para dados espaciais;
• Interoperabilidade e padrões para SIG;
• Metadados espaciais;
• Propagação de erros e controle de qualidade;
• Geoestatística;
• Análise espacial e estatística espacial;
• Modelagem dinâmica e aplicações em SIG de autômatas celulares;
• Sistemas espaciais de apoio à decisão;
• Bibliotecas digitais para SIG;
• Projeto e implementação de SIG;
• Novas aplicações de tecnologia de Geoprocessamento;
• Fusão de dados;
• Mapeamento e sensoriamento remoto;
• Integração sensoriamento remoto e SIG;
• Recuperação de imagens baseada em conteúdo;
• Cartografia digital;
• Interfaces Web para SIG;
• Realidade virtual e SIG 3D;
• Serviços de informação geográfica móveis e distribuídos.

Este ano o GeoINFO acontecerá de 28 de novembro a 1° de dezembro, na cidade de Campos do Jordão, São Paulo.

Com certeza este será um interessante evento, do qual vale a pena participar.

Um Abraço!

–
Anderson Maciel Lima de Medeiros
Tecnólogo em Geoprocessamento
Consultor em Geotecnologias Livres
Acesse: www.clickgeo.com.br

Recebi recentemente uma email falando sobre o GeoInfo 2010 - o simpósio brasileiro de GeoInformática.

O GeoInfo é um congresso voltado para desenvolvimento e soluções em geotecnologias, abrangendo diversas áreas. Este ano será realizado em Campos do Jordão, entre 28 de novembro à 01 de dezembro.

Me parece que é um congresso que vale a pena comparecer e publicar. As áreas para publicação são as seguintes:

- Bancos de dados espaciais e espaço-temporais; - Modelagem de dados espaciais e espaço-temporais;
- Mineração de dados espaciais e espaço-temporais;
- Data warehouses espacias e espaço-temporais;
- Múltiplas representações em bancos de dados espaciais;
- Análise de dados sobre objetos móveis; - Métodos de acesso espaciais, espaço-temporais e multidimensionais;
- Processamento e otimização de consultas espaciais;
- Estruturas de dados espaciais;
- Geometria computacional aplicada;
- Visualização de dados espaciais;
- Ontologias para dados espaciais;
- Interoperabilidade e padrões para SIG;
- Metadados espaciais;
- Propagação de erros e controle de qualidade;
- Geoestatística;
- Análise espacial e estatística espacial;
- Modelagem dinâmica e aplicações em SIG de autômatas celulares;
- Sistemas espaciais de apoio à decisão;
- Bibliotecas digitais para SIG;
- Projeto e implementação de SIG;
- Novas aplicações de tecnologia de geoprocessamento;
- Fusão de dados;
- Mapeamento e sensoriamento remoto;
- Integração sensoriamento remoto e SIG;
- Recuperação de imagens baseada em conteúdo;
- Cartografia digital;
- Interfaces web para SIG;
- Realidade virtual e SIG 3D; - Serviços de informação geográfica móveis e distribuídos.
Bastante coisa não? Com certeza conseguiremos encaixar um projeto em algum dos temas.

Confiram o site. É uma boa oportunidade para conhecer mais o pessoal da área, conhecer Campos do Jordão e publicar um artigo!

Fica a dica.

Abraços

George

No related posts.

Aqui no blog já disponibilizei duas coletâneas especiais, sendo uma com referências conceituais sobre Sensoriamento Remoto e outra sobre publicações relacionadas ao software Alov Map.

Dessa vez preparei para vocês uma breve coletânea de publicações, apostilas e outros materiais escritos em português que podem ajudá-los a ter uma boa base conceitual de duas áreas fundamentais para quem trabalha com Geotecnologias: Cartografia e Posicionamento por Satélite.

Vou indicar aqui os links para acesso e/ou downloads dos materiais. É importante destacar que os direitos autorais de cada publicação pertencem aos seus respectivos autores.

Todas as fontes de pesquisa listados abaixo são distribuidas gratuitamente. Então, vamos a lista:

Curso de GPS e Cartografia Básica (Download)

Cartografia para Geoprocessamento (Download)

Fundamentos de Cartografia para Geoprocessamento (Download)

Fundamentos de Cartografia (Download)

Conceitos Cartográficos (Download)

Conceitos e Divisão da Cartografia (Download)

Conceitos Fundamentais Usados no Posicionamento Terrestre (Download)

Fundamentos GPS (Download)

Elementos de Cartografia (Download)

Aplicação do GPS na Coleta de Dados (Download)

Introdução ao Sistema de Posicionamento Global (Download)

Sistema de Posicionamento Global (Download)

Posicionamento por Ponto Preciso: Implementação e Análise (Download)

Introdução ao GNSS (Download)

Integração de Redes GNSS Locais ao SIRGAS (Download)

Com o tempo pretendo adicionar novos links  a lista, então sugiro que sempre acessem esta postagem pra conferir as atualizações.

Você pode dar suas sugestões postando nos comentários. Lembre-se que o objetivo aqui é ajudar a compreender melhor os conceitos ligados a Cartografia e ao Posicionamento por Satélite.

Em uma postagem futura irei indicar alguns artigos que considero especialmente interessantes.

Acredito que essa coletânea será de grande ajuda para os que buscam uma boa base conceitual sobre Cartografia e Posicionamento por Satélite.

Um Abraço!
–
Anderson Medeiros
Consultor em Geotecnologias Livres
Acesse: www.clickgeo.com.br

Para quem trabalha com dados espaciais nunca é demais conhecer novos programas e suas aplicações.

Pois bem aqui estou para compartilhar um programa open source que trabalha única e exclusivamente com Geotagging.

Este é um termo adotado para a função de etiquetar, ou seja, inserir coordenadas geográficas em fotos. Outras pessoas definem esta funcionalidade como o georreferenciamento de fotografias.

No mundo windows existem diversos aplicativos que realmente fazem este tipo de trabalho; mas como este blog é destinado exclusivamente ao mundo Linux; vamos conhecer, aqui, a alternativa que há tanto procurava: GPS Correlate. Existem outros aplicativos que também cumprem este papel, porém, este é o mais popular.

A geolocalização consiste em adquirir dados de posicionamento geográfico através de receptores GPS e inseri-los em fotos digitais dos lugares onde foram feitos tais registros fotográficos.

Este geotagging ocorre através da inserção de uma tag contendo os dados de latitude, longitude e altitude no cabeçalho EXIF (Exchangeable Image File Format) da foto.

Um exemplo básico para melhor compreendermos sua aplicabilidade é a despreocupação em ter que ir à atividades em campo, em dia de chuva, com uma prancheta na mão onde consta uma planilha para associar várias coordenadas geográficas de eventos identificados com as fotos registradas. Sem contar o trabalho depois, no escritório, para lembrar de uma foto sem a devida correlação, que terá de constar no relatório.

Outros exemplos de aplicabilidade profissional poderiam ser citados aqui ou meramente para usos de hobbie e lazer.

Então, vamos ao que interessa.

.

INSTALAÇÃO NO UBUNTU 10.04

Basta apenas ir a Central de Programa do Ubuntu (Aplicativos > Central de Programa do Ubuntu) e no campo de busca digitar: gpscorrelate.

Instale as duas opções que aparecem listadas.

.

RODANDO O PROGRAMA

Ao final da instalação basta apenas executar o seguinte comando no terminal: gpscorrelate-gui.

Em seguida o programa será aberto.

Caso você não queira executar o programa via terminal, basta apenas criar um lançador (ícone) na área de trabalho para chamar o programa (faça tal qual a figura abaixo).

TRABALHANDO COM O PROGRAMA

No campo 1. Add Photos, clique em Add… para adicionar uma ou mais fotos.

No campo 2. GPS Data, clique em Choose… para adicionar o Tracklog baixado do GPS.

ATENÇÃO: Os dados baixados do GPS tem de estar no formato .GPX

No campo 3. Set options, marque as seguintes caixas de seleção: Interpolate, Between Segments e Write DD MM SS.SS.

Ajuste o Time Zone para o seu fuso horário e em GPS Datum deixe-o como WGS-84.

ATENÇÃO: Para que o programa correlacione os dados do GPS às fotos, você terá de, previamente, antes de tirar as fotos, ajustar o horário de sua câmera ao horário do GPS.

Por fim, No campo 4. Correlate!, clique em Correlate Photos para executar a inserção dos dados.

Pronto. Você acabou de inserir as coordenadas às suas fotos. Parabéns.

Agora é só compartilhá-las no Panoramio ou Google Earth. Caso prifira utilizar este último, basta apenas ir em Arquivo>Abrir ou Ctrl+O para carregar suas fotos. Perceba que suas fotos cairão exatamente sobre o local onde elas foram registradas.

Então, é isso pessoal.

The ArcGIS Editor for OpenStreetMap (OSM) is designed to help ArcGIS desktop users to become an active member in the growing community of users building an open and freely available database of geographic data.

The ArcGIS Editor for OpenStreetmap is an extension to the existing editor environment for the desktop.

gvSIG 1.10beta has been released with the aim that the gvSIG Community help us to debug it. Users test the software in multiple and variated scenarios, what let us find errors difficult to find in other way. That’s why we encourage you to test it and report any error you find and any suggestion you have to us.

But how? As you probably know on April gvSIG migrated part of its infrastructure to OSOR and one of the main changes was the new bug / feature request trackers. Now the trackers are public so our users and developers are able to open issues directly to these trackers.

What’s needed? The only requirement is to register in OSOR but, in order to get a really useful information, it’s very important that you follow some instructions and good practices, for example, write the exact steps to reproduce the error, check if the issue is already open (if so, you’ll be able to add more information to it) or, of course, fill in the issue fields correctly. Please, see related documentation.

Probably one of the main differences between privative and free projects is that, in the second ones, the Community is able to participate on them and we think testing is one of the areas on which users participation can be grater. Having public bug / feature request trackers is, with no doubt, a very important step to make Community participation easier. At least this is our aim.

So please, try gvSIG 1.10 and consider using the trackers instead of the lists for reporting issues from now on.

Thanks in advance.