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 – pt4
3. History Tables – pt 1

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

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

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

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

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

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

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

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

1 - Arquitetura do sistema

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

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

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

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

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

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

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

Figura 01 - Arquitetura simplificada do sistema

1.1 - Escolha de ferramentas

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

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

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

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

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

• O PostGIS é livre e gratuito.

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

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

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

2 - Temas e Feições

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

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

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

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

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

2.1 - Sistema Viário

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

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

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

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

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

Em SQL, ficaria assim:

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

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

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

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

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

	-- vamos adicionar uma coluna geométrica à trecho_logradouro

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

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

Modelo Entidade Relacionamento do Sistema Viário

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

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

A explicação do código:

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

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

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

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

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

O que acharam?

Abraços,

George R. C. Silva

Related posts:

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