Instrutores
Pessoal,
Buenas noches de Porto Velho.
Tenho trabalhado muito e a consequência disso é um blog um cado "largado". Me desculpem por isso!
Hoje venho oferecer uma oportunidade: estou precisando de três instrutores em áreas diferentes.
Preciso de um instrutor em:
- Python
- PostGIS
- MapServer
Estamos implantando uma solução corporativa para um órgão público e preciso destes três instrutores. Caso alguém conheça alguém, ou se vocês mesmos tiverem disponibilidade, me avisem! Mais detalhes, por email.
Abraços,
George
OpenGeo Suite
Bom domingo pessoal, tudo bom?
Não tenho tido muito tempo ultimamente, mas vamos para uma rapidinha:
A OpenGeo lançou uma coleção de camisetas legais sobre alguns produtos open source dos quais eles trabalham. Ficaram muito legais e eu mesmo pedi duas, PostGIS e OpenLayers. As camisetas foram feitas especialmente para o FOSS4G Barcelona (Free and Open Source Software for Geomatics Conference).
São de cor única, com o logo do produto e uma frasezinha de efeito. A do PostGIS diz: PostGIS never forgets; a do OpenLayers: OpenLayers zooms.
Falando nisso, a OpenGeo está com a suite OpenGeo. É um servidor "pronto" com diversos componentes interessantes e uma edição community. É a soma do GeoServer, GeoExt, OpenLayers e PostGIS em um só pacotão - disponível para Linux, Mac OSX e Windows. Ainda não testei, mas pode valer a pena!
Vou ficando por aqui, porque já tenho que ir para o trabalho!
Abraços
George R. C. Silva
Introdução ao GeoDjango
Boa noite pessoal,
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?):
Para os que desejam utilizar o banco de dados PostgreSQL/PostGIS (altamente recomendado!):
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
Construindo funcionalidades para o WKT Raster
No post anterior, falamos um pouquinho sobre como o WKT Raster funciona. Hoje gostaria de mostrar um pouquinho sobre as maquinações que ando desenvolvendo para o PostGIS e WKT Raster.
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
PostGIS WKT Raster
Buenas pessoal,
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
Desenvolvendo um SIG para Suporte de Decisões Municipais #2
Olá pessoal, boa noite.
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
Desenvolvendo um SIG para Suporte de Decisões Municipais
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
Funções PostGIS #3
Boa tarde pessoal!
Vamos falar um pouco hoje das funções de análise espacial e medições. Antes disso, o blog alcançou +50 postagens essa semana. Parabéns para nós!
ST_Area()
Esta função é bastante simples. Ela retorna a área de um polígono ou multipolígono.
-- assinatura
-- SELECT ST_Area(geometria)
SELECT ST_Area(
ST_GeomFromText(('POLYGON((0 0, 1 0,1 1,0 1,0 0))')))
ST_Perimeter()
Outra função bastante simples, de um único argumento. O argumento deve ser uma geometria do tipo polígono. Se você passar uma LINESTRING, o PostGIS irá retornar 0. Veja ST_Length() para LINESTRINGs.
-- assinatura
-- SELECT ST_Area(geometria)
SELECT ST_Perimeter(
ST_GeomFromText(('POLYGON((0 0, 1 0,1 1,0 1,0 0))')));
-- só funciona com polígonos. user ST_Length()
SELECT ST_Perimeter(
ST_GeomFromText('LINESTRING(0 0, 1 0, 2 1, 2 2, 3 2)'));
ST_Perimeter2D()
Calcula o perímetro considerando apenas as coordenadas X e Y de um polígono.
-- assinatura
-- SELECT ST_Perimeter2D(geometria)
-- note que nosso polígono é 3D, possui Z.
SELECT ST_Perimeter2D(
ST_GeomFromText(('POLYGON((0 0 1, 1 0 1,1 1 2,0 1 3,0 0 1))')));
ST_Perimeter3D()
Calcula o perímetro de um polígono levando em conta as coordenadas Z. Veja que nosso polígono anterior, com a coordenada Z, ST_Perimeter3D() nos dá um retorno diferente.
-- assinatura
-- SELECT ST_Perimeter3D(geometria)
-- note que o polígono é 3D, possui Z.
SELECT ST_Perimeter3d(
ST_GeomFromText(('POLYGON((0 0 1, 1 0 1,1 1 2,0 1 3,0 0 1))')));
ST_Length()
Calcula o comprimento de uma LINESTRING. Simples e direto 
. Esta função calcula o comprimento de uma linha em duas dimensões.
-- assinatura
-- SELECT ST_Length(geometria)
SELECT ST_Length(
ST_GeomFromText('LINESTRING(0 0, 1 0, 2 1, 3 3)'));
ST_Length2D()
Exatamente igual à função acima. É apenas um apelido para ST_Length().
ST_Length3D()
Esta função funciona exatamente como ST_Perimeter3D. Mas para LINESTRINGs. Esta função leva em conta as coordenadas no eixo Z de uma geometria.
-- assinatura
-- SELECT ST_Length3D(geometria)
SELECT ST_Length3D(
ST_GeomFromText('LINESTRING(0 0 1, 0 0 0, 1 0 2, 2 3 1)'));
ST_Centroid()
Esta função calcula o centro de massa de uma geometria. Para pontos é apenas uma média aritmética de seus conjuntos de coordenadas. Para LINESTRINGS, é o resultado de uma média ponderada do comprimento de seus segmentos e para polígonos o centro de massa do mesmo.
É possível aplicar esta função em qualquer tipo de geometria e em coleções genéricas (GEOMETRY_COLLECTIONs - conjuntos de geometrias de diversos tipos), sendo o resultado equivalente ao centróide do conjunto de geometrias de maior dimensionalidade (pontos são 0-dimensionais, linhas unidimensionais, polígonos bidimensionais). Ou seja, se temos um conjunto de pontos, linhas e polígonos, o centróide será igual ao centróide do conjunto de polígonos.
Esta função é importante. Diversas vezes a maneira mais prática e fácil de se transformar dados é através do centróide e preparar dados para estatísticas espaciais.
-- assinatura
-- SELECT ST_Centroid(geometria)
SELECT ST_AsText(
ST_CENTROID(
ST_GeomFromText('POLYGON((0 0, 1 0, 1 1, 0 1, 0 0))')));
SELECT ST_AsText(
ST_CENTROID(
ST_GeomFromText('LINESTRING(0 0, 1 0, 1 1)')));
SELECT ST_AsText(
ST_CENTROID(
ST_GeomFromText('MULTIPOINT((0 0),(5 8),(10 1))')));
Aqui estão os resultados das chamadas acima.
Resultado da função ST_Centroid utilizando um polígono como argumento
Resultado da função ST_Centroid utilizando uma linestring como argumento
Resultado da função ST_Centroid utilizando um multipoint como argumento
ST_Intersects()
Outra função importante. Esta função simplesmente teste se geometria A interseciona geometria B. Esta função não retorna a real interseção das duas partes, mas somente se elas se intersecionam ou não, true ou false. ST_Intersects pode ser utilizado com qualquer par de geometrias.
-- assinatura
-- SELECT ST_Intersercts(geometria_A,geometria_B);
-- retorna true
SELECT ST_Intersects(
ST_GeomFromText('POLYGON((0 0, 1 1, 1 0, 0 1, 0 0))'),ST_GeomFromText('LINESTRING(0 0, 2 2, 1 1)'));
-- retorna false
SELECT ST_Intersects(
ST_GeomFromText('POLYGON((0 0, 1 1, 1 0, 0 1, 0 0))'),ST_GeomFromText('LINESTRING(10 10, 20 10)'));
ST_Intersection()
Esta função é parecida com a ST_Intersects, mas esta retorna de fato a interseção entre as duas geometrias. Ambas as funções são computacionalmente intensivas, portanto cuidado ao utilizá-la em um sistema em produção, em views e outras coisas deste tipo. Esta função tem uma particularidade: podemos usar como parametro qualquer tipo de geometria, mas o resultado sempre virá no formato de geometria com menor dimensionalidade.
Exemplo: se computarmos a interseção entre dois polígonos, teremos como resultado um polígono (ou nulo). Se computarmos a interseção entre um polígono e diversas linhas, o resultado será uma LINESTRING obrigatoriamente. Porque? É matemático, a interseção de um polígono com um ponto sempre terá como resultado um ponto. Os resultados estão em verde.
Veja:
Resultado gráfico da interseção de duas LINESTRINGs
Podemos ter como resultado da interseção entre duas LINESTRINGs um conjunto de pontos ou uma LINESTRING (quando dois segmentos são coincidentes).
Resultado gráfico da interseção de um conjunto de pontos e um polígono
Resultado gráfico de ST_Intersection entre um conjunto de LINESTRINGs e um polígono
Resultado gráfico de ST_Intersection entre dois polígonos
Vamos à assinatura da função:
-- assinatura
-- SELECT ST_Intersection(geometria_A,geometria_B);
-- POLYGON e LINESTRING
SELECT ST_AsText(ST_Intersection(
ST_GeomFromText('POLYGON((0 0,1 0, 1 1,0 1,0 0))'),
ST_GeomFromText('LINESTRING(0 0,.5 .5,2 2,3 3)')));
-- POLYGON E PONTO
SELECT ST_AsText(ST_Intersection(
ST_GeomFromText('POLYGON((0 0,1 0, 1 1,0 1,0 0))'),
ST_GeomFromText('POINT(.2 .2)')))
-- POLYGON e POLYGON
SELECT ST_AsText(ST_Intersection(
ST_GeomFromText('POLYGON((0 0,1 0, 1 1,0 1,0 0))'),
ST_GeomFromText('POLYGON((.5 .5,1.5 .5,1.5 1.5,.5 1.5,.5 .5))')))
-- LINESTRING e LINESTRING
SELECT ST_AsText(ST_Intersection(
ST_GeomFromText('LINESTRING(0 0,1 1,3 2,6 6)'),
ST_GeomFromText('LINESTRING(-1 -1,.5 .5,3 4,5 6)')))
Os resultados em formato texto são os seguintes:
Resultado textual de ST_Intersection entre um polígono e uma linestring
Resultado textual de ST_Intersection entre um polígono e um ponto
Resultado textual de ST_Intersection entre dois polígonos
Resultado textual de ST_Intersection entre duas LINESTRINGs
Uma nota importante: pontos não se intersecionam. Ou eles são coincidentes ou não.
ST_Overlaps
Esta função é parecida em funcionamento com a ST_Intersects. Na verdade ela realiza a mesma operação que ST_Intersects, mas leva em consideração se um objeto não está contido plenamente dentro do outro. Esta função opera com qualquer tipo de geometria, mas presta atenção na dimensionalidade de cada uma: uma geometria de menor dimensionalidade está sempre contida na geometria de maior dimensionalidade, portanto, não sobrepõe a de maior dimensionalidade.
Exemplo: geometria_a é um ponto e geometria_b é um polígono. Se perguntado se ST_Overlaps(geometria_a,geometria_b), o PostGIS vai retornar falso, pois não são da mesma dimensionalidade. Se geometria_a é um polígono e geometria_b também, a operação pode retornar verdadeiro, caso a sobreposição ocorra.
-- assinatura
-- SELECT ST_Overlaps(geometria_a,geometria_b)
-- [1]
-- mesma dimensionalidade: estas geometrias podem se sobrepor.
SELECT ST_Overlaps(
ST_GeomFromText('LINESTRING(0 0,1 1,3 2,6 6)'),
ST_GeomFromText('LINESTRING(-1 -1,.5 .5,3 4,5 6)'))
-- [2]
-- mesma dimensionalidade: estas geometrias podem se sobrepor.
SELECT ST_Overlaps(
ST_GeomFromText('POLYGON((0 0,1 0,1 1,0 1,0 0))'),
ST_GeomFromText('POLYGON((.5 .5,1.5 .5,1.5 1.5,.5 1.5,.5 .5))'))
-- [3]
-- dimensionalidade diferente: estas geometrias não podem se sobrepor (mesmo que se intersecionem)
SELECT ST_Overlaps(
ST_GeomFromText('LINESTRING(0 0,1 1,3 2,6 6)'),
ST_GeomFromText('POINT(0 0)'));
-- [4]
-- dimensionalidade diferente: estas geometrias não podem se sobrepor (mesmo que se intersecionem)
SELECT ST_Overlaps(
ST_GeomFromText('POLYGON((0 0,1 0,1 1,0 1,0 0))'),
ST_GeomFromText('POINT(0 0)'));
Resultado da função ST_Overlaps nos exemplos 1 e 2 de ST_Overlaps
Resultado da função ST_Overlaps nos exemplos 3 e 4 de ST_Overlaps
ST_Covers()
Esta função retorna verdadeiro caso nenhum ponto da geometria_b se encontre fora da geometria_a.
-- assinatura
-- SELECT ST_Covers(geometria_a,geomtria_b);
-- geometria_a cobre geometria_b? verdadeiro
SELECT ST_Covers(
ST_GeomFromText('POLYGON((0 0,10 0,10 10,0 10,0 0))'),
ST_GeomFromText('POLYGON((.5 .5,1.5 .5,1.5 1.5,.5 1.5,.5 .5))'));
-- geometria_a cobre geometria_b? verdadeiro, todos os pontos de geometria_b estão contidos em a
SELECT ST_Covers(
ST_GeomFromText('POLYGON((0 0,10 0,10 10,0 10,0 0))'),
ST_GeomFromText('POINT(1 1)'));
-- geometria_a cobre geometria_b? falso. geometria_a é menor que geometria_a.
SELECT ST_Covers(
ST_GeomFromText('POLYGON((.5 .5,1.5 .5,1.5 1.5,.5 1.5,.5 .5))'),
ST_GeomFromText('POLYGON((0 0,10 0,10 10,0 10,0 0))'));
-- geometria_a cobre geometria_b? falso. geometria_a cobre geometria_b parcialmente (note o segundo ponto, em 100 100)
SELECT ST_Covers(
ST_GeomFromText('POLYGON((0 0,10 0,10 10,0 10,0 0))'),
ST_GeomFromText('MULTIPOINT((1 1),(100 100))'));
Resultado da função ST_Covers utilizando com dois polígonos
Resultado da função ST_Covers entre um polígono e multipontos
ST_Within()
Esta função é similar em funcionamento à ST_Covers(). A diferença aqui é que esta retorna positivo se estiver completamente dentro de B.
-- assinatura
-- SELECT ST_Within(geometria_a,geometria_b)
-- [1]
-- geometria_a está completamente dentro de geometria_b? verdadeiro
SELECT ST_Within(
ST_GeomFromText('POINT(5 5)'),
ST_GeomFromText('POLYGON((0 0,10 0,10 10,0 10,0 0))'));
-- [2]
-- geometria_a está completamente dentro de geometria_b? verdadeiro
SELECT ST_Within(
ST_GeomFromText('LINESTRING(5 5, 2 3, 1 0)'),
ST_GeomFromText('POLYGON((0 0,10 0,10 10,0 10,0 0))'));
-- [3]
-- geometria_a está completamente dentro de geometria_b? verdadeiro
SELECT ST_Within(
ST_GeomFromText('POLYGON((1 1,2 1,2 2,1 2,1 1))'),
ST_GeomFromText('POLYGON((0 0,10 0,10 10,0 10,0 0))'));
-- [4]
-- geometria_a está completamente dentro de geometria_b? falso. geometrias de dimensionalidade menor não contém geometrias de maior
-- dimensionalidade
SELECT ST_Within(
ST_GeomFromText('POLYGON((1 1,2 1,2 2,1 2,1 1))'),
ST_GeomFromText('MULTIPOINT((0 0),(10 0),(10 10),(0 10),(0 0))'));
-- [5]
-- geometria_a está completamente dentro de geometria_b? falso. A não está inteiramente dentro de B
SELECT ST_Within(
ST_GeomFromText('MULTIPOINT((5 5),(100 100))'),
ST_GeomFromText('POLYGON((0 0,10 0,10 10,0 10,0 0))'));
Resultado da função ST_Within(), exemplos de 1 à 3
Resultado da função ST_Within, exemplos 4 e 5
Por agora é só pessoal. No próximo post vou tentar explicar melhor sobre a dimensionalidade de cada tipo de geometria e os porquês estas funções se comportam desta maneira.
Espero que tenham gostado.
Abraços
George R. C. Silva
Funções PostGIS #2
Boa tarde senhores e senhoras,
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
Funções PostGIS #1
Boa tarde pessoal,
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
