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