Me desculpem pela demora em postar coisas novas no blog. Não esqueço deste espaço não, mas o tempo, continua difícil.

Hoje quero falar um pouco sobre o GeoDjango, um framework MVC (Model, View, Controller) - na verdade, MTV (Model, Template, View) para programarmos aplicações web com grande agilidade.

O lema do framework é The Web Framework for Perfectionist, ou seja: o framework web para perfeccionistas. Parece bom né?

Quais são as vantagens de se ter um framework deste tipo (MVC/MTV)?

• Código de qualidade;
• Aplicações prontas altamente configuráveis;
• Aplicação do princípio DRY - Don't Repeat Yourself - coisa que na web, é bastante comum;
• Total separação de responsabilidades: os modelos conversam com os bancos de dados, os templates desenham nossas páginas e as views representam a camada de negócios - ou seja: código (re)usável;
• Entre outras;

O MTV/MVC é apenas uma forma de se trabalhar/arquitetar uma solução. Este tipo de desenho de solução se encaixa muito bem para desenvolvimento web, pelos motivos acima. É muito menos trabalho, com alto reuso de código - ou seja, um ganho de produtividade tremendo para quem desenvolve e aumento da qualidade para os usuários.

Existem diversos frameworks deste tipo por aí, muitos deles são bons e na verdade conheço dois: Django/GeoDjango e ASP.MVC. Não quero comparar os dois, pois são classes de softwares diferentes, ambos muito bons e cada um com suas particularidades. O GeoDjango é muito atrativo pelo fato de trabalhar nativamente com vários bancos de dados, inclusive com PostGIS e outros bancos de dados espaciais menos conhecidos (MySql Spatial, Spatial Lite - por exemplo) e de conter pacotes específicos para o desenvolvimento de aplicações SIG.

O que precisamos para brincar com o tal do GeoDjango/Django?

Bem, o Django, projeto pai, que contém o código do GeoDjango é feito todo em Python. Novamente, uma linguagem fácil, tranquila de se aprender e muito flexível. Web e flexibilidade combinam. É tudo Python. Até os templates contém código Python, da mesma maneira que código .asp pode conter código C#.

Pré-requisitos (sempre existem, não?):

• Python 2.5 ou maior;
• Django 1.x;
• GeOS;
• PROJ;
• GDAL;

Para os que desejam utilizar o banco de dados PostgreSQL/PostGIS (altamente recomendado!):

• pyscopg2;

Pode parecer muita coisa, mas não é. Você precisa das bilbiotecas e os python bindings para fazer toda essa máquina de guerra funcionar. Uma dica: quem usa/usará PostgreSQL já tem o GeOS instalado (que é o mais complicado de obter/compilar). As outras são facéis de se arrumar e configurar.

Chega de papo. O que o Django/GeoDjango pode fazer por mim? Vamos à uma demonstração de código dos models espaciais:

from django.contrib.gis.db import models

# note que aqui herdamos em nossa classe
# a classe Models. Ela contém toda a funcionalidade que precisamos.
class Setor(models.Model):
    nome_setor = models.CharField(max_length=100,unique=True)
    poligono_setor = models.PolygonField(srid=29192)

    objects = models.GeoManager()

class Bairro(models.Model):
    nome_bairro = models.CharField(max_length=100,unique=True)
    setor = models.ForeignKey(Setor)
    poligono_bairro = models.PolygonField(srid=29192)

    # vamos dizer ao admin do python que usaremos mapas
    # para editar o poligono_bairro
    objects = models.GeoManager()

Só isso? Só isso. O Django já sabe o que fazer com nossos modelos. Note que  não definimos de forma explícita uma chave primária, mas podemos caso precisarmos. O Django dá suporte para diversos tipos de dados, incluindo imagens, arquivos, datas, entre outros e suporta herança entre modelos. Isso significa que podemos economizar muito código utilizando os simples conceitos da programação orientada à objetos.

Todos os modelos devem ter tabelas no banco de dados que correspondam à ele, com exceção do caso de modelos abstratos, os quais não possuem tabela nos bancos de dados. Eles servem basicamente para usarmos as funcionalidades da OOP.

from django.contrib.gis.db import models

class TipoLogradouro(models.Model)
    descricao_tipo_logradouro = models.CharField(max_length=30)

class ResultadoGeocodificacao(models.Model):
    tipo_logradouro = models.ForeignKey(TipoLogradouro)
    nome_logradouro = models.CharField(max_length=100)
    numero = models.Integer()
    # se não especificarmos o srid, o default é WGS84
    ponto_geocodificado = models.PointField()

    objects = models.GeoManager()

    class Meta:
        abstract = True

class AcidenteGeocodificado(models.Model,ResultadoGeocodificacao):
    numero_feridos = models.IntegerField()
    numero_veiculos = models.IntegerField()

A única diferença entre o primeiro e o segundo exemplo é a adição da classe interna Meta, em ResultadoGeocodificacao, com o atributo abstract = True. Esta única linha diz ao Django que ele não deve criar uma tabela correspondente para ResultadoGeocodificacao, mas, AcidenteGeocodificado irá herdar toda informação de ResultadoGeocodificado e terá sua própria tabela no banco de dados, com todos os campos especificados em ResultadoGeocodificado e AcidenteGeocodificado. Divertido não?

Lembram dos nossos posts sobre a administração pública e modelos de dados? Quero continuar a série, terminar a modelagem de dados (que é bastante simples) e iniciar no desenvolvimento desta aplicação em GeoDjango.

Django, o poderoso framework!

O que acharam do GeoDjango/Django?

Um abraço,

George R. C. Silva

Related posts:

1. OOP com python – Uma breve introdução.
2. #Python – o que é?
3. #Python – pt4

Em tese, se o raster está armazenado no banco e conseguimos determinar o valor de cada pixel, poderíamos usar a SQL para realizar álgebra de mapas? A resposta é sim, podemos. É claro, já existem softwares especializados em realizar álgebra de mapas, como o IDRISI, ENVI, SPRING, ArcGIS (com Spatial Analyst), o módulo Sextante do gvSIG, WhiteBox, entre outros.

A vantagem de fazermos isto no PostGIS é que podemos aproveitar de algumas funcionalidades do banco de dados para realizar atualizações automáticas (funciona, mas a perfomance não deve ser das melhores), controlar melhor o acesso aos rasters - centralizando tudo em uma única localização, backup, etc.

Existem diversas funções para análise espacial de rasters, incluindo as matemáticas, lógicas, entre outras. Hoje irei mostrar apenas algumas matemáticas, que são bem simples. O módulo WKT Raster já planeja construir em C (linguagem nativa do PostgreSQL) algumas funções para análise espacial, mas enquanto isto não acontece, vamos levando com estas aqui.

Importante: estas funções só operam com rasters de uma única banda. Todas as operações são realizadas na banda 1. Nenhuma operação é realizada na banda 2 ou 3 - se bem que o suporte para tal é simples de ser construído.

Cuidado ao utilizar estas funções. Caso você sobreescreva seu raster, não o conseguirá de volta - caso precise.

ST_Plus

Esta função adiciona um valor double precision ao nosso raster de interesse. Se o pixel tem valor 1 e nosso argumento é 1, o resultado daquele pixel será 2. Esta função tem como entrada um raster e um valor numérico. O retorno da função é um objeto raster completo.

CREATE OR REPLACE FUNCTION ST_Plus(p_grid raster, z double precision)
	RETURNS raster AS
$$
DECLARE
	w integer;
	h integer;
	z1 integer;

	grid raster;
BEGIN

	SELECT
		ST_Width(p_grid),
		ST_Height(p_grid)
	 into w,h;

	-- realizar cópia do raster original
	grid := p_grid;

	for i in 1..h loop
		for j in 1..w loop

			-- selecting cell value
			z1 := ST_Value(p_grid,i,j);
			grid := st_setvalue(grid,1,i,j,z1 + z);

		end loop;
	end loop;

	return grid;
END
$$
language 'plpgsql';

A função é bem simples. Ela copia o raster original em memória e adiciona o valor à cada pixel. Sem segredos. Como usá-la? Recomendo primeiramente, duplicar sua coluna do tipo raster, pois a função de adição de colunas raster é bastante longa e com parâmetros meio obscuros. Procure o arquivo SQL gerado pelo gdal2wktraster e ache a linha que adiciona a coluna. Modifique o nome da coluna e execute este comando novamente. Depois disso popule a coluna com os novos valores.

SELECT AddRasterColumn('public','teste_raster','grid_stplus',-1, ARRAY['16BUI'], false,
       true, null, 0.000833, -0.000833, 9, 9,
           ST_Envelope(
               ST_SetSRID('POLYGON((-49.500416 -18.000416,-49.500416 -19.000416,-48.000416 -18.000416,-48.000416 -19.000416,-49.500416 -18.000416))'::geometry, -1)));

UPDATE teste_raster SET grid_stplus = ST_Plus('nome_da_coluna_raster_original',10);

Faça um teste com ST_Value para identificar se tudo correu bem. Neste teste, somamos 10 unidades ao valor de cada pixel da coluna original raster. Por que estamos criando uma coluna extra para armazenar nosso novo raster? Se alterarmos o raster original, não conseguiremos ele de volta, portanto, cuidado ao utilizar as funções.

ST_Minus

De forma similar à ST_Plus, ST_Minus vai subtrair determinado valor de cada pixel de nosso raster e nos trará como resultado o raster modificado.

CREATE OR REPLACE FUNCTION ST_Minus(p_grid raster, z double precision)
	RETURNS raster AS
$$
DECLARE
	w integer;
	h integer;
	z1 integer;

	grid raster;
BEGIN

	SELECT
		ST_Width(p_grid),
		ST_Height(p_grid)
	 into w,h;

	-- realizar cópia do raster original
	grid := p_grid;

	for i in 1..h loop
		for j in 1..w loop

			-- selecting cell value
			z1 := ST_Value(p_grid,i,j);
			grid := st_setvalue(grid,1,i,j,z1 - z);

		end loop;
	end loop;

	return grid;
END
$$
language 'plpgsql';

Recomendo testar da mesma maneira que a função anterior. O uso é o mesmo - modificando o nome da função.

ST_Plus

Esta função realiza a multiplicação do valor do pixel. Simples e direta.

CREATE OR REPLACE FUNCTION ST_Times(p_grid raster, z double precision)
	RETURNS raster AS
$$
DECLARE
	w integer;
	h integer;
	z1 integer;

	grid raster;
BEGIN

	SELECT
		ST_Width(p_grid),
		ST_Height(p_grid)
	 into w,h;

	-- realizar cópia do raster original
	grid := p_grid;

	for i in 1..h loop
		for j in 1..w loop

			-- selecting cell value
			z1 := ST_Value(p_grid,i,j);
			grid := st_setvalue(grid,1,i,j,z1 * z);

		end loop;
	end loop;

	return grid;
END
$$
language 'plpgsql';

Use-a do mesmo jeito que as anteriores.

ST_Divide

CREATE OR REPLACE FUNCTION ST_Divide(p_grid raster, z double precision)
	RETURNS raster AS
$$
DECLARE
	w integer;
	h integer;
	z1 integer;

	grid raster;
BEGIN
	if (z = 0) then
		return p_grid;
	end if;

	SELECT
		ST_Width(p_grid),
		ST_Height(p_grid)
	 into w,h;

	-- realizar cópia do raster original
	grid := p_grid;

	for i in 1..h loop
		for j in 1..w loop

			-- selecting cell value
			z1 := ST_Value(p_grid,i,j);
			grid := st_setvalue(grid,1,i,j,z1 / z);

		end loop;
	end loop;

	return grid;
END
$$
language 'plpgsql';

ST_Power

Esta função eleva o valor da célula ao valor passado como parâmetro na função. Se temos uma célula de valor 2, e passamos 2 como parâmetro, teremos o 4 como resultado (2^2);

CREATE OR REPLACE FUNCTION ST_Power(p_grid raster, z double precision)
	RETURNS raster AS
$$
DECLARE
	w integer;
	h integer;
	z1 integer;

	grid raster;
BEGIN

	SELECT
		ST_Width(p_grid),
		ST_Height(p_grid)
	 into w,h;

	-- realizar cópia do raster original
	grid := p_grid;

	for i in 1..h loop
		for j in 1..w loop

			-- selecting cell value
			if z = 0 then
				grid := st_setvalue(grid,1,i,j,1);
			else
				z1 := st_value(p_grid,i,j);
				grid := st_setvalue(grid,1,i,j,z1 ^ z);
			end if;

		end loop;
	end loop;

	return grid;
END
$$
language 'plpgsql';

E assim podemos construir funções que alterem nossos rasters originais. São funções simples, praticamente demonstrativas. Na sequência demonstraremos algumas funções mais interessantes, como declividade, cálculo de fluxo de direção, identificação de depressões, eliminação de depressões, entre outras.

Um abraço,

George R. C. Silva

Related posts:

1. PostGIS WKT Raster
2. Funções PostGIS #2
3. Funções PostGIS #1

Como estão as coisas? Hoje vamos conversar um pouquinho sobre o WKT Raster.

O WKT Raster é um projeto para implementar suporte aos famosos grids, rasters, imagens ao PostGIS. WKT vem de Well Known Text (algo como "texto bem conhecido").

O projeto já tem código compilado e funcionando e tomei a semana para testá-lo de acordo. A implementação veio da especificação desenvolvida por Pierre Racine. O projeto tem como objetivo integrar-se perfeitamente ao engine do PostGIS já existente, sendo possível executar operações espaciais / álgebra de mapas, carregar rasters multi-bandas, entre outras coisas deliciosas.

Este projeto é muito interessante, pois podemos armazenar os rasters dentro do banco de dados, garantindo ou excluindo acesso à quem realmente precisa, ao invés de ficarmos com milhares de cópias por aí (imagine um escritório com 20 analistas GIS - qual é quantidade de informações duplicadas), sem saber ao certo qual é a mais atual ou com melhor qualidade - enfim, nos garante todas as vantagens do armazenamento centralizado em banco de dados. Não necessariamente precisamos armazenar os dados no PostgreSQL, podemos deixá-los em HD e adicionar somente os metadados e acessá-los da mesma forma, caso você esteja preocupado com disco . Em suma, é demais!

Vamos comentar com instalar essa belezinha no seu PostgreSQL - em Windows XP. Linux users, sorry.

Pré-requisitos

Sempre existem né?

• PostgreSQL/PostGIS instalado. O PostGIS deve 1.4 ou maior, determinando também a versão do PostgreSQL: 8.3 ou maior;
• Python;
• GDAL/python;
• WKT Raster;

Instalação

1) Instale o Python, 2.5 ou 2.6. Estou usando o 2.5, que foi instalado junto com o ArcGIS. Portanto, se você tem esta instação específica, não se preocupe. Esta instalação é bem simples. Dois cliques, pá pum, está instalado.

2) Instale os GDAL bindings. Para fazer isso é só descompactar a pasta zipada e colocá-la no diretório que mais lhe agradar. Coloquei a minha pasta (gdalwin32-1.6) no diretório C:\.

2.1) Vá em Painel de Controle > Sistema > Avançado > Variáveis de Ambiente. Procure a variável PATH. Ela é composta de vários diretórios separados por um ponto-e-vírgula, correto? Adicione o diretório C:\gdalwin32-1.6\bin nesta listinha e adicione um ; no final. Claro, se você pos a pasta do gdal em outro diretório, faça as alterações pertinentes.

2.2 ) Ainda em variáveis de ambiente, adicione uma nova variável, chamada GDAL_DATA e adicione o caminho C:\gdalwin32-1.6\data como caminho. Como esta variável de ambiente é usada somente pelo GDAL, não se preocupe em colocar o ;. Mas se colocar também não faz mal. Dê OK para salvar as variáveis de ambiente. Os bindings do GDAL para Python já estão instalados. Você pode acessá-los e utilizar o GDAL para um monte de coisas, como converter coordenadas de rasters, reprojetá-los, etc. tudo usando uma linha de comando.

3) Descompacte o pacote do WKT Raster.

3.1) Copie o arquivo rtpostgis.dll para a pasta lib do PostgreSQL. Geralmente é algo como C:\Program Files\PostgreSQL\8.x\lib;

3.2) Copie os arquivos gdal2wktraster.py e libgdal.dll para a pasta bin da sua instalação do PostgreSQL. Fácil né?

3.3) Vamos instalar os comandos e funções do Wkt Raster no nosso banco agora. Abra o PgAdmin3 ou o console sql do Postgres e conecte-se ao banco de dados alvo. Feito isso, rode os comandos que se encontram na pasta share\contrib\ do pacote WktRaster. Feito isso, teste se o WKT Raster está funcionando apropriadamente usando o comando SQL:

SELECT postgis_raster_lib_build_date(),postgis_raster_lib_version();

Caso o comando tenha sucesso, tudo foi instalado com sucesso.

A instalação termina aqui. Mas como carregar um raster para dentro de nosso banco de dados? Podemos utilizar a ferramenta em Python desenvolvida para este propósito, o script gdal2wktraster.py

Carregar um raster para o banco de dados

Esta ferramenta é uma aplicação em linha de comando, bastante fácil de utilizar. O resultado dela é um script .sql que você pode rodar pelo console sql ou pelo PgAdmin3.

Abra um console DOS e digite:

python "CaminhoParaOArquivo\gdal2wktraster.py" --help

Isto lhe deve dar todas as opções da ferramenta.

Algumas:

• -t nome da tabela à ser criada no PostGIS, e.g. -t teste_raster;
• -o nome do arquivo de saída, e.g. -o srtm.sql;
• -k especifica o tamanho tile. Esta opção é muito importante, pois divide seu raster original em diversos registros cada um com este tamanho, em pixels. e.g. -k 90x90; Caso você não utilize esta opção, seu raster original ocupará apenas um único registro da tabela. Se você utilizá-la, você diz ao PostGIS: pegue este raster, fatie-o em pedaços de tal tamanho e insira-os nesta tabela!
• -f especifica o nome da coluna do tipo raster. e.g. -f grid;
• -r esta é a opção mais importante de todas, com ela especificamos o arquivo original à ser carregado. e.g. -r "CaminhoDoArquivoRaster\arquivo.tif";

Exemplo de um comando completo

C:\Python25\python.exe "C:\Program Files\PostgreSQL\8.3\bin\gdal2wktraster.py" - r "C:\srtm.tif" -k 90x90 -f grid -t srtm -o srtm.sql

Esta ferramenta é bem fácil de utilizar e gera um SQL limpinho, só faltando rodá-lo dentro do banco de dados.

Estou desenvolvendo algumas ferramentinhas de análise espacial, em especial ferramentas para extração automática de feições - algumas já estão prontas, outras ainda no forno, mas logo logo falo sobre elas! Esta é a página oficial do WKT Raster.

O que acharam?

Abraços!

George R. C. Silva

Related posts:

1. Construindo funcionalidades para o WKT Raster
2. #Python – pt4
3. #Python – pt2

No post anterior falamos sobre a modelagem de um sistema que atendesse as necessidades de uma prefeitura e mostramos como modelar a parte de sistema viário. O sistema viário foi modelado primeiro pois ele é de fato, o coração de uma cidade e muita coisa acontence "em torno" do sistema viário.

Estamos assumindo com nosso modelo, que construíremos um sistema de geocoding, capaz de localizar endereços em nossa base de logradouros. Através deste sistema construíremos localizadores de diversos tipos de feição, como acidentes de trânsito, pontos de ônibus, focos de dengue, entre outras.

Hoje iremos conversar sobre a modelagem do sistema de transportes. Obviamente é um modelo simples, que não atende todas as necessidades de uma empresa/prefeitura para administrar o sistema de transporte público, mas já ajuda. Bem, do que é feito um sistema de transporte público? Falaremos aqui somente de linhas, pontos de parada, sentidos (bairro-centro, centro-bairro) e horários. Poderíamos muito bem falar de localização em tempo real, relatórios de viagem, etc., mas foge um pouco do objetivo da série - de ser uma introdução à modelagem de um sistema completo.

2.2 - Sistema de Transporte Público

Vamos começar com a modelagem do nosso sistema de Transporte. Vamos modelar Pontos de Parada, Linhas, Sentidos, e Horários.

CREATE TABLE tp_ponto_parada
    (
        id_tp_ponto_parada serial not null,
        dc_tp_ponto_parada varchar(50) not null,
        constraint tp_ponto_parada_pk PRIMARY KEY (id_tp_ponto_parada),
        constraint tp_ponto_parada_un UNIQUE (dc_tp_ponto_parada)
    );

    CREATE TABLE ponto_parada
    (
        id_ponto_parada serial not null,
        dc_ponto_parada varchar(255) not null, -- descricao do ponto
        tp_ponto_parada integer not null references tp_ponto_parada (id_tp_ponto_parada),
        constraint ponto_parada_pk PRIMARY KEY (id_ponto)
    );

    -- vamos adicionar nossa coluna geométrica a ponto_parada
    SELECT * FROM AddGeometryColumn('public','ponto_parada','the_geom',-1,'POINT',2);

    CREATE TABLE linha
    (
        id_linha serial not null,
        nm_linha varchar(50) not null,
        dc_linha varchar(255) not null,
        constraint linha_pk PRIMARY KEY (id_linha),
        constraint linha_nm_linha_un UNIQUE (nm_linha) -- o nosso nome de linha deve ser único.
    );

Bem, modelos nossas entidades básicas, pontos e linhas. Mas como descobrir qual linha serve à cada ponto? Ou como dizer se um ponto de parada pertence à determinada linha? Temos neste momento, uma relação de muitos para muitos. Porque? Bem, um ponto pode servir à mais de uma linha. E uma linha, com certeza abrange vários pontos. Para isto ser feito de maneira correta, temos de criar uma entidade intermediária, decompondo nosso relacionamento em 1:M, de cada um dos lados.

    CREATE TABLE sentido
    (
        id_sentido serial not null,
        dc_sentido varchar(50) not null,
        constraint sentido_pk primary key (id_sentido)
    );

    -- vamos aproveitar e inserir os sentidos possíveis!

    INSERT INTO sentido(id_sentido,dc_sentido) VALUES (DEFAULT,'CENTRO - BAIRRO');
    INSERT INTO sentido(id_sentido,dc_sentido) VALUES (DEFAULT,'BAIRRO - CENTRO');

    CREATE TABLE linha_possui_ponto
    (
        id_linha integer not null references linha (id_linha),
        id_ponto_parada integer not null references ponto_parada (id_ponto_parada),
        id_sentido integer not null references sentido (id_sentido),
        constraint lpp_pk primary key (id_linha,id_ponto_parada,id_sentido)
    );

Através desta tabela intermediária, conseguimos modelar quem pertence à quem. Podem ver, que as chaves estrangeiras em linha_possui_ponto, não permite o cadastro de linhas inexistentes ou de pontos inexistentes, nem de pontos duplicados que partilhem do mesmo sentido. Desta forma, podemos construir um cadastro básico de linhas e pontos, bem como de quais pontos são servidos por quais linhas.

Agora, precisamos de uma maneira inteligente de desenhar as linhas de ônibus que operam na cidade fictícia. Precisamos criar algo com uma coluna geométrica, correto? Errado. Como temos uma tabela geométrica com nossos logradouros, podemos facilmente utilizá-la para construir nossos trajetos de linha.

Por que fazer desta maneira?

• Não repita informação.
• Não repita informação.
• Não repita informação.

É um motivo forte o bastante. Imagine se temos milhares de linhas, com milhares de trechos servidos. Se alterarmos nossos logradouros, teremos de alterar também nossas linhas - configurando um problema em potencial. Por isso iremos utilizar as geometrias da tabela logradouros para desenharmos nossas linhas.

Esta tabela tomará a forma de uma tabela intermediária, informando ordem e sentido. Desta maneira, utilizando uma view construíremos nossa tabela virtual de linhas.

    CREATE TABLE linha_possui_trecho
    (
        id_lpt serial not null,
        id_linha integer not null references linha (id_linha),
        id_trecho_logradouro not null references trecho_logradouro (id_trecho_logradouro),
        id_sentido not null references sentido (id_sentido),
        ordem integer not null default 0,
        constraint lpt_pk primary key (id_lpt),
        constraint lpt_un_linha_lpt unique (id_linha,id_trecho_logradouro,id_sentido,ordem)
    );

Através desta tabela intermediária, conseguimos informar à nosso sistema quais são os trechos de logradouro que formam uma linha específica. Realmente é algo à mais para monitorarmos e inserir no banco de dados, mas atualmente é a única maneira. A idéia aqui é construir uma ferramenta específica, que seleciona trechos de logradouros, e em memória armazena estas informações, bem como sua ordem (de seleção). Após a seleção, o ideal é o usuário executar o comando de "inserir", e nosso sistema, cuide do restante para o mesmo. Nada de editar tabelas como esta na mão.

Já temos nosso modelo preliminar, mas como vamos mostrar as linhas em um cliente web? Necessitamos gerar as linhas em tempo de execução, com as informações pertinentes. Para isto, iremos utilizar uma view e adicionar os registros apropriados à tabela geometry_columns para que esta fique transparente para o usuário/serviço de mapas.

CREATE OR REPLACE VIEW linhas_transporte_publico AS
SELECT
	id_linha,
	nm_linha,
	ST_Collect((SELECT the_geom from logradouros where gid = id_trecho_logradouro)) as "the_geom"
FROM linha
	LEFT OUTER JOIN linha_possui_trecho
		ON (linha.id_linha = linha_possui_trecho.id_linha)
	LEFT OUTER JOIN trecho_logradouro
		ON (linha_possui_trecho.id_trecho_logradouro = trecho_logradouro.id_trecho_logradouro)
	GROUP BY id_linha,nm_linha

Esta view nos possibilitará disponibilizar as informações de linha como um todo, sem diversos registros. O segredo está na função ST_Collect, responsável por unir os trechos de logradouros em nossa tabela trecho_logradouro. Veja que não estamos duplicando informação, apenas reutilizando os dados já existentes em nosso modelo.

Existem outras tabelas interessantes em se disponibilizar, tais como pontos de táxi, linhas de metrô/trem, transportes marítimos, aeroportos, terminais de embarque, etc. Deixo este exercício para o leitor. O objetivo aqui é mostrar como a modelagem de dados preliminar do sistema viário é importante e como podemos simplificar nosso trabalho futuro.

No próximo artigo falaremos sobre setores administrativos, bairros, quadras, lotes, etc. Estes dados são muito importantes para a administração pública e com certeza devem estar presentes em nosso sisteminha.

O que acharam?

Abraços

George R. C. Silva

Related posts:

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

Continuando nossa peregrinação pelas funções do PostGIS, irei começar explicar a que usamos no post anterior e não expliquei.

ST_AsText()

Esta função retorna o valor WKT (Well Known Text - especificação OGC) da geometria. Esta função é útil pois lhe mostra algo um pouco mais inteligível do que o WKB (Well Known Byte).

Ela tem como retorno o WKT sem o código SRID da geometria especificada. Se utilizada em um comando SELECT, ela irá realizar esta conversão em todos os objetos válidos da coluna especificada. Ela é uma função de output.

-- assinatura
-- SELECT ST_AsText(the_geom)

SELECT nm_equipamento_urbano, ST_AsText(the_geom);

Vamos falar um pouco das funções construtoras de geometria. Por que elas são importantes? É uma maneira de se converter dados de coordenadas, em objetos geográficos, representados no banco de dados por uma string com o valor WKB. Vamos começar pela mais simples: ST_Point()

ST_Point()

Esta é a mais simples das funções construtoras. Ela tem como entrada apenas um X e Y. Esta função esta de acordo com a norma OGC. Na verdade, o que ela faz é chamar a função ST_MakePoint() passando como entrada apenas os eixos X e Y.

-- assinatura
-- SELECT ST_Point(coordenada_x, coordenada_y);

SELECT ST_Point(-42.5,-19.2);

O resultado é retornado em WKB. Veja:

Função ST_Point() retornando o valor em WKB

ST_MakePoint()

A função MakePoint é mais completa que a ST_Point, pois permite a utilização de até quatro eixos de coordenadas, X, Y, Z e M. Esta função não está de acordo com a norma OGC mas é uma forma de se trabalhar no PostGIS. O problema do uso da mesma é no momento de integração com outros softwares OGC compliant. Fique atento!

-- assinaturas
-- SELECT ST_MakePoint(x,y);
-- SELECT ST_MakePoint(x,y,z);
-- SELECT ST_MakePoint(x,y,z,m);

SELECT ST_MakePoint(-10,-1,300,1);

O resultado desta função também é trazido em WKB.

Função ST_MakePoint() retornando o valor em WKB

Existem funções deste tipo para todos os tipos de geometria. Vamos mostrar as outras:

ST_MakeLine()

Vamos complicar um pouquinho. Da mesma maneira que podemos construir pontos, podemos construir linhas. Existem três maneiras de se utilizar esta função: uma é com o resultado agregado de uma consulta, um array de pontos, ou dois pontos. Vou mostrar as três maneiras.

-- assinatura
-- SELECT ST_MakeLine(geometry_set);
-- SELECT ST_MakeLine(ponto1,ponto2);
-- SELECT ST_MakeLine(array_pontos);

-- resultado agregado de consulta
SELECT l.setor, ST_AsText(ST_MakeLine(l.the_geom)) FROM
	(SELECT codsetor as "setor", the_geom FROM equipamento_urbano) as l GROUP BY l.setor;

-- dois pontos
SELECT ST_AsText(ST_MakeLine(ST_MakePoint(-1,-1),ST_MakePoint(-2,-2)))

-- array de pontos
SELECT ST_AsText(ST_MakeLine(ARRAY[ST_MakePoint(-10,-1),ST_MakePoint(-5,0),ST_MakePoint(-10,2),ST_MakePoint(-19,-20),ST_MakePoint(-1,0)]));

-- note que a abertura do array se faz com os colchetes!

Vejamos os resultados, respectivamente: agregado, dois pontos e array de pontos. Uma nota: utilizei ST_AsText nas funções para facilitar a visualização do resultado. Todos os resultados podem ser facilmente testados, com exceção do agregado. Caso alguém tenha interesse, posso lhe enviar a tabela em formato .sql para conferência

Resultado de ST_MakeLine com pontos agregados

Resultado de ST_MakeLine com dois pontos

Resultado da função ST_MakeLine com um array de pontos

Vamos complicar mais um pouquinho?

ST_MakePolygon()

Esta função constrói polígonos. Para um polígono ser um polígono ele deve ter uma clara distinção de seu interior com seu exterior. A única maneira de delimitarmos isto é tenho uma LINESTRING fechada, ou seja, o último vértico deve ser igual ao primeiro. Um polígono também pode ter holes ou seja, buracos. Eles também podem ser construídos aqui. Veja só:

-- assinatura
-- SELECT ST_MakePolygon(linestring_fechada);
-- SELECT ST_MakePolygon(linestring_fechada,array_poligonos_interiores);

SELECT ST_AsText(ST_MakePolygon(
	ST_MakeLine(ARRAY[
		ST_MakePoint(0,0),
		ST_MakePoint(1,0),
		ST_MakePoint(1,1),
		ST_MakePoint(0,1),
		ST_MakePoint(0,0)])))

Veja o resultado:

Resultado de ST_MakePolygon

Todas estas funções são extremamente úteis, permitindo o usuário à manipular as geometrias de diversas tabelas para construir objetos temporários ou views para visualização em softwares de SIG. Lembrem-se que você não precisa utilizar ST_MakePoint() para construir polígonos ou linhas. Você pode utilizar a agregados e resultados de consultas como parâmetros de entrada para estas funções.

ST_GeomFromText

Esta é a rainha das funções construtoras de geometria. Com ela é possível construir qualquer geometria, desde que você tenha o WKT das mesmas. Mão na roda. A segunda assinatura lhe permite especificar um SRID.

-- assinatura
-- SELECT ST_GeomFromText('wkt');
-- SELECT ST_GeomFromText('wkt',srid);

SELECT ST_AsText(ST_GeomFromText('LINESTRING(0 0, 1 0, 2 1, 2 2, 3 1, 3 3, 0 1, 0 0)'))

SELECT ST_AsText(ST_GeomFromText('POLYGON((0 0, 1 0,1 1,0 1,0 0))'));

Resultado da função ST_GeomFromText, construindo uma linha.

Resultado da função ST_GeomFromText, construindo um polígono.

Agora vem a pergunta: porque utilizamos dois pares de parênteses quando construímos um polígono e apenas um quando construímos uma linestring? Lembra quando construímos um polígono, temos a opção de passar uma array de polígonos internos, os famosos holes? Então, o segundo set de parênteses corresponde à possibilidade de inserir este array de polígonos. Não se esqueça, para polígonos e geometrias multi*, dois sets de parênteses são necessários.

Hoje vimos um pouco sobre as funções construtoras de geometrias no PostGIS. O que acharam?

Abraços

George R. C. Silva

Related posts:

1. Funções PostGIS #3
2. Funções PostGIS #1
3. Construindo funcionalidades para o WKT Raster

Me desculpem o tempo parado, mas é que a correria está grande!

Gostaria de mostrar um pouco as funções do PostGIS e as maravilhas que podemos fazer com elas. Vamos começar devagar, com as básicas e ir aumentando o grau de complexidade destes posts. Algumas idéias aqui surgirão, como a criação de indíces específicos com o uso destas funções, uma prática comum para aumentar a perfomance do banco de dados. Espero que gostem. O PostGIS utilizado é o 1.4.0.

PostGIS_Full_Version()

Esta função não faz muita coisa, ela apenas te diz a versão do PostGIS instalada, bem como quais as versões das bibliotecas das quais o PostGIS depende (Proj4 e GEOS). Ela é importante pois é uma das primeiras perguntas que irão lhe fazer quando você encontrar dificuldades ou bugs. Guarde-a num cantinho da sua mente .

SELECT * FROM PostGis_Full_Version()

AddGeometryColumn()

Esta sim é importante. Aprenda-a usar logo.  Ela é responsável por adicionar corretamente as colunas geométricas à uma tabela. Ela não só adiciona a coluna à tabela, como cria as constraints definidas e popula a tabela geometry_columns. Se você adicionar uma coluna geométrica e não popular a tabela geometry_columns diversos softwares SIG podem não reconhecer aquela tabela como espacial. Portanto atenção nas duas.

CREATE TABLE teste(
id serial not nuLl,
atributo1 varchar(20) not null default 'abc',
constraint teste_pk primary key (id)
);

-- assinaturas
-- SELECT * FROM AddGeometryColumn('tabela','nome_da_coluna_a_ser_criada',srid,'TIPO_DE_GEOMETRIA',dimensao);
-- SELECT * FROM AddGeometryColumn('esquema','tabela','nome_da_coluna_a_ser_criada',srid,'TIPO_DE_GEOMETRIA',dimensao);

SELECT * FROM AddGeometryColumn('teste','the_geom',29192,'POINT',2);
-- QUALQUER UM DESSES FORMATOS FUNCIONAM

Qualquer um das assinaturas é válida.

DropGeometryColumn()

Esta função faz o inverso da AddGeometryColumn(). Ela remove a coluna espacial e limpa o registro na tabela geometry_columns.

-- assinaturas
-- SELECT * FROM DropGeometryColumn('tabela','nome_da_coluna');
-- SELECT * FROM DropGeometryColumn('esquema','tabela','nome_da_coluna');

SELECT * FROM DropGeometryColumn('teste','the_geom');

Populate_Geometry_Columns()

Esta função escaneia todas as tabelas que contenham colunas do tipo geometry e as popula com as constraints apropriadas: tipo de geometria, número de dimensões e SRID especificado.

-- assinaturas
-- SELECT * FROM Populate_Geometry_Columns();
-- SELECT * FROM Populate_Geometry_Columns(oid_tabela);

SELECT * FROM Populate_Geometry_Columns();

Esta função sem argumentos, irá escanear todas as tabelas do banco e tentar criar as constraints para cada uma. Se você especificar um oid a função tentará fazer isto somente para a tabela especificada.

Probe_Geometry_Columns()

Esta função escaneia todas as tabelas do banco com constraints espaciais e as adiciona à tabela geometry_columns. Mão na roda para garantir que todas suas tabelas estejam de acordo para uso em softwares de SIG. Esta função não escaneia views que têm de ser populadas na tabela geometry_columns na mão.

-- assinatura
-- SELECT * FROM Probe_Geometry_Columns();

SELECT * FROM Probe_Geometry_Columns();

UpdateGeometrySRID

Esta belezinha aqui realiza o trabalho de atualizar as constraints e as geometrias para determinado SRID. Cuidado, esta função não converte coordenadas. Apenas atualiza a tabela geometry_columns e as constraints correspondentes!

-- assinatura
-- SELECT * FROM UpdateGeometryColumn('nome_tabela','nome_coluna_espacial',novo_srid);
-- SELECT * FROM UpdateGeometryColumn('esquema','nome_tabela','nome_coluna_espacial',novo_srid);

SELECT * FROM UpdateGeometryColumn('public','teste','the_geom',-1);

ST_Transform

Iniciando nas funções realmente espaciais, temos a função ST_Transform. Você notará que todas as funções espaciais contém o prefixo ST. As anteriores não possuem o prefixo pois são funções administrativas. Esta função, realmente converte as coordenadas de um SRID para outro.

-- assinatura
-- ST_Transform(geometria,novo_srid);

-- sem transformacao
SELECT cd_equipamento_urbano, ST_AsText(the_geom) FROM equipamento_urbano;

-- transformada
SELECT cd_equipamento_urbano, ST_AsText(ST_Transform(the_geom,4618)) FROM equipamento_urbano;

Nesta seção vemos duas funções. ST_AsText que será explicada mais tarde, e a ST_Transform. Veja como podemos embrulhar funções dentro de funções, que são avaliadas de dentro para fora. Os resultados das queires acima são.

Tabela de pontos original em UTM Zona 22S

Esta é o resultado transformado:

Tabela de pontos transformada em SAD69 Lat/Long

Existem muiiiitas funções úteis no PostGIS que são realmente uma mão na roda. Próximo post falaremos de funções modificadoras de geometria e construção de geometrias.

Espero que tenham gostado.

Abraços

George R. C. Silva

Related posts:

1. Funções PostGIS #2
2. Funções PostGIS #3
3. Desenvolvendo um SIG para Suporte de Decisões Municipais #2

Hoje gostaria de comentar com vocês sobre um trabalho elaborado pela também Tecnóloga em Geoprocessamento, Julie Eugênio.

Há algum tempo ela preparou um projeto de gerenciamento de atividades de agricultura familiar fazendo uso de técnicas de Geoprocessamento.

O objetivo principal da pesquisa dela foi o desenvolvimento de uma aplicação, com base em técnicas de Geoprocessamento, para apoiar as atividades de um projeto voltado à agricultura familiar sustentável denominado “Cinturão Verde”, inserido no programa de microcrédito “Empreender-JP”, no município de João Pessoa, capital do Estado da Paraíba.

O mapa abaixo mostra a localização da área de estudo.

Durante a construção da aplicação SIG integrada a um Banco de Dados Geográficos deu-se ênfase ao uso de tecnologias livres, com destaque para o Quantum Gis (QGis) e PostgreSQL/PostGis.

Na parte escrita do trabalho desenvolvido foi detalhada toda a metodologia empregada. A qual está resumida na figura abaixo.

O trabalho foi extremamente elogiado pelos responsáveis técnicos da prefeitura de João Pessoa. Você pode fazer o download do trabalho completo a partir do link abaixo, que traz o tema da monografia escrita com base nesse projeto.

Gerenciamento de Atividades de Agricultura Familiar Sustentável com Base em Técnicas de Geoprocessamento, no Município de João Pessoa - PB

Espero que tirem proveito de mais essa demonstração da potencialidade do uso de tecnologias livres para Geoprocessamento.

Abraços.

--

Anderson Medeiros

Tecnólogo em Geoprocessamento

Related posts:

1. Monografias Geoprocessamento – IFPB
2. O Geoprocessamento e Suas Tecnologias – Parte 2
3. O Geoprocessamento e Suas Tecnologias – Parte 1

Hoje vou falar para vocês de um assunto que na minha graduação o Prof. Marcello Benigno[1] sempre "enchia o saco" repetindo e repetindo e repetindo... a criação de templates para o banco de dados (no nosso caso, PostgreSQL[2]). Templates nada mais são que modelos pré-definidos de banco de dados, que aumentam a produtividade na criação de novos bancos. Neles nós colocamos características comuns aos bancos de dados que serão criados e só associamos os novos bancos a eles.

Como exemplo, hoje a tarde precisei recriar um template_postgis para que pudesse sincronizar uma aplicação geodjango a ele (A aplicação poderá ser vista em breve na edição número 1 da revista Geo.NET), então fiz da seguinte forma:

Como root chamei o postgres:

# su postgres

Após entrar no root postgres, mandei criar um novo banco de dados chamado template_postgis:

$ createdb -U postgres template_postgis

A opção "-U" do comando createdb se refere ao usuário que será dono do banco, ou do template, como é nosso caso (Para maiores informações sobre outras opções do comando createdb digite $ man createdb). Para esta versão, o root postgres é por default o dono das tabelas, bancos e templates criados, por tanto, não faz necessário informá-lo como usuário.

Para que seja possível rodar as funções da extensão espacial postgis, é necessário a criação da linguagem procedural plpgsql. Por meio desta, é possível rodar as funções contidas nos arquivos lwpostgis.sql e ref_spatial_sys.sql, arquivos estes que contem funções que resolvem referência espacial, tipos de geometrias, sistemas de coordenadas e etc. Para criar a linguagem, basta usar o comando:

$ createlang -d template_postgis -U postgres plpgsql

A opção "-d" informa para qual banco de dados, ou template será criada a nova linguagem procedural (Para maiores informações, consulte $ man createlang).

Depois de ter criado a linguagem, basta importar os arquivos lwpostgis.sql, lwpostgis_upgrade.sql e spatial_ref_sys.sql. Para isso usaremos o terminal interativo do pgsql através do comando:

$ psql -d template_postgis -f lwpostgis.sql

$ psql -d template_postgis -f lwpostgis_upgrde.sql

$ psql -d template_postgis -f spatial_ref_sys.sql

Neste ponto é importante tomar nota de que, se o usuário não estiver no path onde estão os arquivos acima, lhe será retornado um erro. Para evitar tal erro, consulte a documentação para a sua distribuição.

Para confirmar se tudo correu bem, entre no template e faça uma consulta às tabelas da seguinte forma:

$ psql -d template_postgis

template_postgis=# \dt
Lista de relações
Esquema |       Nome       |  Tipo  |   Dono
---------+------------------+--------+----------
public  | geometry_columns | tabela | postgres
public  | spatial_ref_sys  | tabela | postgres
(2 registros)

Observe que dentro do template_postgis foram criadas as tabelas espaciais, e que por default o dono das mesmas é o root postgres. Agora ficou simples, pois sempre que for preciso criar um db com extensão espacial, basta rodar o comando:

$ psql -T template_postgis <nome_novo_db>

Este novo db será criado, e dentro dele já estarão inseridas as tabelas espaciais.

Fácil não é?

Abraço a todos.

Referencias:

[1] Prof. Marcello

[2] PostgreSQL

Vicente Martins.

Related posts:

1. PostGIS WKT Raster
2. Construindo funcionalidades para o WKT Raster
3. shp2pgsql: Você conhece esta fantástica ferramenta?

Conforme vimos na primeira parte deste post, o Geoprocessamento é um conjunto de tecnologias dinâmicas com alto potencial de aplicação.

Até aqui vimos que Geoprocessamento e SIG não são as mesma coisa. O SIG é apenas uma importante tecnologia dentre as diversas incluídas no Geoprocessamento.

Vimos também que programas como o gvSIG e ArcGis não são "SIGs" mas softwares para SIG. Assim como o Geoprocessamento possui várias ramificações tecnológicas o SIG é um sistema composto por softwares, hardwares, metodologias, recursos humanos e dados.

Ficamos de ver o que são e pra servem tecnologias como o Banco de Dados Geográfico e o WebMapping.

Banco de Dados Geográficos

Bom, vamos por partes. O que é um Banco de Dados (BD)?

Todo local, físico ou virtual onde estão armazenados dados, pode em certo sentido, ser chamado de banco de dados. Por exemplo, uma enciclopédia pode ser considerada um banco de dados. Mas para nós aqui da área de Geoprocessamento é mais importante o conceito especial de banco ou base de dados relacional. Ou seja um banco onde dados são armazenados na forma de tabelas relacionáveis entre si através campos chaves.

As mais diversas facetas de atividades, desde locadoras de DVD até grandes indústrias metalúrgicas usam-se deste tipo de base para ter um maior controle sobre fatores como cadastro de clientes e sua condição em relação à empresa (Inadimplência, por exemplo).

Neste ponto, é importante evitar confundir o BD em sí (conjunto de tabelas relacionáveis) com o programa que o gerenciará, o Sistema Gerenciador de Banco de Dados (SGBD). EM outras palavras, softwares como Access, MySQL, Oracle, PostgreSQL não são BD, mas sim SGBD.

Mas ainda não falamos no assunto deste tópico. O que é e para que serve um Banco de Dados Geográfico (BDG)?

O BDG, também chamado de Banco de Dados Espacial (BDE), é semelhante ao descrito acima (relacional), com a grande e importante diferença de suportar feições geométricas em suas tabelas.

Este tipo de base com geometria oferece a possibilidade de análise e consultas espaciais. É possível calcular nestes casos, por exemplo, áreas, distâncias e centróides, além de realizar a geração de buffers e outras operações entre as geometrias.

Como dica de estudos para você obter uma boa base conceitual sobre BDG, indico o livro "Banco de Dados Geográficos" do INPE, que está disponível para download em PDF aqui.

Atualmente, alguns programas de SGBD desenvolveram extensões que inserem no software características de Sistemas Gerenciadores de Banco de Dados Geográficos (SGBDG) o PostgreSQL, MySQL, e Oracle, sendo os dois primeiros softwares livres e o último proprietário.

Vamos falar um pouco mais do PostgreSQL e como ele passa a agir como SGBDG. O PostgreSQL é desenvolvido atualmente pela PostgreSQL Global Development Group. Quando se percebeu a necessidade de extender este SBGD para suportar dados espaciais desenvolveu-se a extensão conhecida como PostGis.

Sendo assim, vamos entender que o PostGis não é um BDG ou um SGBDG, ele é apenas uma extensão, um plugin, do PostgreSQL que lhe confere funções para armazenamento e manipulação de dados geográficos.

A figura abaixo procura mostrar a diferença entre o PostgreSQL e "seu filho". Note que para termos um BDG no PostgreSQL faz-se necessária a devida instalação da extensão PostGis.

Você pode importar arquivos vetoriais shapefile (*.shp) para dentro de um "Banco PostGis" utilizando recursos oferecidos pelo próprio programa ou utilizando algum software de SIG com essa funcionalidade. O shapefile será convertido em uma tabela espacial que pode ser integrada com as convencionais contidas na base, além de poder ser visualizada e manipulada através de programas como o gvSIG, Kosmo, Quantum Gis, Udig e muitos outros desta safra. Para baixar tutoriais sobre como realizar esta operação com alguns destes softwares, clique aqui.

Para baixar a versão mais recente do PostgreSQL e sua extensão espacial PostGis, acesse os links abaixo.

• PostgreSQL
• PostGis

Para finalizar este post vamos considerar outra tecnologia do Geoprocessamento, a saber, WebMapping.

WebMapping (WebGis)

A internet vem se destacando nos últimos anos como uma excelente ferramenta para disponibilização e interligação de dados das mais diversas fontes e naturezas.

A geomática, como área do conhecimento, também encontrou na internet um nicho para suas atividades. A disponibilização de mapas digitais, os chamados WebGis ou WebMapping, tem-se tornado comum, permitindo que um maior número de usuários tenha acesso a dados espacializados, de forma hábil e atraente.

Talvez o estopim para o crescimento das aplicações SIG para internet tenha sido a popularização de serviços online gratuitos de localização como o Google Earth e Google Maps.

Os mapas na web se apresentam de três formas princiapais:

1) Mapas Estáticos - Mapas no formato de imagem (*.jpg, *.gif, *.png, etc) integrados à páginas da internet.

2) Mapas Gerados à partir de formulários - Fornece-se parâmetros para geração de mapas na forma de imagem.

3) Mapas Dinâmicos - O usuário seleciona uma área de seu interesse em um mapa geral, gerando uma navegação para outro mapa ou imagem mais específico com informações mais detalhadas desta região. Em geral apresentam interface atraente com ícones para consulta espacial calculo de distância e etc.

Para mais detalhes sobre tipos de mapas veja a publicação disponibilizada neste link.

Há muitos softwares e frameworks livres para o desenvolvimento de aplicações WebGis. Podemos destacar alguns: MapServer, GeoServer, i3Geo, Alov Map, Time Map, Open Layers e P.Mapper.

Diversos órgãos públicos fazem uso destas ferramentas para divulgação dos resultados de seus trabalhos.

A imagem abaixo mostra um exemplo de aplicação desenvolvida com MapServer e o framework P.Mapper. Clique aqui para acessar a página da aplicação (Este é um exemplo de mapa dinâmico).

Nesta visão geral sobre algumas das tecnologias do Geoprocessamento, pudemos dissipar alguns falsos conceitos em torno de termos como SIG, BDG, SGBDG, WebGis, etc. Espero que tenham gostado do que leram.

Fiquem à vontade para deixar sua sugestão de tema, críticas e impressões através do e-mail anderson[@]geoprocessamento.net

Anderson Medeiros

Tecnólogo em Geoprocessamento

Related posts:

1. O Geoprocessamento e Suas Tecnologias – Parte 1
2. Agricultura Familiar e Geoprocessamento
3. Monografias Geoprocessamento – IFPB

Related posts:

1. Monografia
2. Acidentes de Trânsito e Geoprocessamento
3. Desenvolvendo um SIG para Suporte de Decisões Municipais #2