Pessoal, conforme relatei anteriormente, uma nova comunidade para troca de idéias GIS nasceu. Apesar de ser toda em inglês o pessoal é bastante ágil e focado. A comunidade abriu o beta para o público.

Claro, ela não oferece tantos recursos como nosso fórum Geo.NET - o maior fórum sobre geotecnologias e geoprocessamento da América Latina - mas tem um pessoal interessante.

Confira:

GIS StackExchange

Abraços

George

Related posts:

1. StackOverflow – mas para Sistemas de Informação Geográfica?

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

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

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

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

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

Fica a dica.

Abraços

George

No related posts.

A metodologia aqui utilizada para a realização da delimitação da bacia hidrográfica e a extração das redes de drenagem engloba a utilização do software Arcgis e imagens de radar do programa idealizado pela NASA (National Aeronautics and Space Administration), denominada Shuttle Radar Topography Mission (SRTM).

Ao software Arcgis estão agregados uma família de outros softwares que desempenham funções bem variadas, que vão desde a visualização e edição de mapas, dados gráficos e alfanuméricos, bem como edição de dados, análises espaciais mais complexas e geração de layouts.

Os dados SRTM resultam de uma missão espacial realizada pela NASA, NIMA (National Imagery and Mapping Agency), DLR (Agência Espacial Alemã) e ASI (Agência Espacial Italiana), cujo objetivo foi o de gerar um Modelo Digital de Elevação (MDE) da Terra usando uma técnica denominada interferometria, a qual se utiliza das respostas espectrais na faixa de microondas do espectro eletromagnético, permitindo a obtenção de informações sobre a estrutura tri-dimensional dos alvos na imagem, no caso da SRTM o relevo.

Figura 1 - (a) Direções de fluxo possíveis para um determinado pixel e (b) direção de fluxo escolhida em função da maior declividade entre o pixel central e os vizinhos.Fonte: PAZ e COLLISCHONN (2008, p. 86)

Na imagem raster gerada através das imagens SRTM, para cada pixel, além da posição geográfica “x e y”, também é atribuído um valor altimétrico “y”, o qual servirá de valor base para a extração das redes de drenagem e a delimitação da bacia hidrográfica através, principalmente, de duas ferramentas do software Arcgis: Flow direction (Direção de Fluxo) e Flow acumulation (Fluxo de acumulação).

Segundo Paz e Collischonn (2008, p. 86), as direções de fluxo constituem o plano de informações básico derivado de um MNT em formato raster para suporte a estudos hidrológicos. O procedimento mais comum consiste em considerar uma única direção de fluxo para cada pixel do MNT, sendo essa direção atribuída para um de seus 8 vizinhos (tomando uma janela 3x3). A determinação de qual direção de fluxo atribuir é feita escolhendo a direção que proporcione a maior declividade, calculada como sendo a diferença de elevação entre o pixel vizinho e o pixel central dividida pela distância entre eles (Figura 1).

Esse procedimento é conhecido como D8 ou deterministic eight neighbours (Jenson e Domingue, 1988), e é o mais comumente empregado. Aplicando a regra da maior declividade para cada pixel do MNT, obtém-se a correspondente direção de fluxo e, ao final do processo, gera-se uma imagem raster onde a cada pixel é atribuído um valor ou código que denota para qual dos vizinhos ele drena.

A primeira etapa a ser realizada para a delimitação da bacia hidrográfica e extração de sua rede de drenagem foi a aquisição das imagens SRTM através do site da Embrapa Monitoramento por Satélite (http://www.relevobr.cnpm.embrapa.br/download/index.htm), onde se encontram disponíveis as imagens SRTM, articuladas em folhas topográficas do IBGE. Para a área de estudo foram necessárias duas folhas: SE-23-V-C e SE-23-Y-A.

Figura 2 - Site da Embrapa Brasil em Relevo. Fonte: http://www.relevobr.cnpm.embrapa.br/download/index.htm

De posse destas imagens, foram iniciados os procedimentos metodológicos para a delimitação da bacia hidrográfica  e a extração das redes de drenagem. Inicialmente as imagens SRTM, em formato raster, foram transformadas para o formato GRID, através do comando Data > Export Data.

Figura 3 – Transformação da Imagem SRTM em formato raster para formato GRID. Fonte: Software ArcGis.

Na janela que se abrirá, em Location escolha o local de destino do novo arquivo, em Format selecione GRID e em Name dê um nome ao arquivo. Criado o arquivo formato GRID, abra o ArcToolbox e siga o caminho Spatial Analyst Tools > Hydrology > Fill, onde aparecerá a janela Fill. Insira o arquivo GRID gerado em Input surface raster e em Output surface raster dê um destino ao novo arquivo Fill gerado.

Figura 4 – Transformando o arquivo GRID para arquivo Fill. Fonte: Software ArcGis.

O próximo passo é gerar uma imagem com a direção do fluxo, seguindo o caminho Spatial Analyst Tools > Hydrology > Flow Direction. Na janela Flow Direction insira o arquivo Fill gerado na etapa anterior em Input surface raster e em Output surface raster dê um destino ao novo arquivo que será gerado.

Figura 5 – Gerando direção de fluxo. Fonte: Software ArcGis.

A etapa de geração do arquivo de direção de fluxo é uma das etapas mais importantes para a extração da rede de drenagem e delimitação da bacia hidrográfica, uma vez que é onde são realizados os cálculos dás áreas de maior declividade, por onde o fluxo de drenagem é direcionado no meio ambiente, naturalmente. É sabido, na hidrologia, que a água flui naturalmente pelo caminho de menor esforço, sendo assim quanto maior a declividade existente, menor será o esforço “exercido” pela água e desta forma serão estes valores de célula na imagem gerada que serão selecionados como caminhos das redes drenagem.

A próxima etapa será gerar o fluxo acumulado e para executar esta etapa siga o caminho Spatial Analyst Tools > Hydrology > Flow Accumulation. Na janela Flow Accumulation, insira o arquivo de direção de fluxo gerado anteriormente e dê um destino para o novo arquivo que será gerado.

Figura 6 – Gerando fluxo acumulado. Fonte: Software ArcGis.

O próximo passo para atingirmos o objetivo proposto será gerar uma imagem raster com as drenagens extraídas, para tal de ser realizado os seguintes passos no ArcToolBox: siga o caminho Spatial Analyst Tools > Hydrology > Flow Accumulation e vá até a janela Con.

Figura 7 – Geração de imagem com as drenagens extraídas. Fonte: Software ArcGis.

Na janela Con insira o arquivo de fluxo acumulado gerado na etapa anterior, em Input true raster no Constant value digite 1. Em Output raster de um destino para o arquivo que será gerado e em Expression digite a fórmula value > 100, valor este que quanto menor for, maior será a quantidade de feições de drenagem a serem geradas de forma automática.

A próxima etapa será a de gerar a rede de drenagens em formato vetorial (shapefile), para tal no ArcToolBox siga o caminho Spatial Analyst Tools > Hydrology > Stream to Feature, insira o arquivo Con gerado na etapa anterior em Input stream raster, o arquivo de direção de fluxo em Input flow direction e dê um destino ao novo arquivo shape que será gerado em formato vetorial com a rede de drenagem extraída.

Figura 8 – Geração de drenagem em formato vetorial. Fonte: Software ArcGis.

Para a delimitação da bacia hidrográfica, inicialmente foi criado um shape de pontos para localizarmos na rede de drenagem o exutório da referida área de drenagem, sendo assim, foi criado o shape de ponto determinando o exutório da referida bacia.

Figura 9 – Determinação do exutório. Fonte: Software ArcGis.

Após a determinação do exutório local, abra o ArcToolBox e siga o caminho Spatial Analyst Tools > Hydrology > Watershed, em Input flow direction raster insira o arquivo flow direction gerado anteriormente e em Input raster or feature pour point data insira o shape do exutório. 

Figura 10 – Delimitação da bacia hidrográfica. Fonte: Software ArcGis.

O arquivo gerado com a delimitação da bacia hidrográfica está em formato imagem raster, sendo assim após a obtenção da delimitação, ainda em formato de imagem, deve-se transformar o arquivo para formato shape, como polígono, para que se possam extrair algumas informações úteis, como área da bacia, perímetro, dentre outros dados de grande relevância.

Figura 11 – bacia hidrográfica delimitada. Fonte: Software ArcGis.

Com a delimitação da bacia hidrográfica e a extração da rede de drenagem da referida bacia uma série de informações podem ser geradas auxiliando os estudos base de planejamento e gestão das diversas atividades realizadas na área espacial da bacia e os usos múltiplos da água direcionados às diversas atividades.

A metodologia que foi aqui descrita e aplicada para a extração da rede de drenagem e a delimitação da bacia hidrográfica, utilizou-se de ferramentas do software Arcgis e dentre elas foram duas as principais ferramentas utilizadas, a direção de fluxo (Flow direction) e o fluxo acumulado (Flow acumulation).

A ferramenta flow direction realiza, como ilustrado na figura 1, uma relação entre a célula central e as células adjacentes determinando as áreas de maior declive através dos dados de altimetria, proporcionando o traçado da direção do fluxo do canal hídrico uma vez que a água segue o caminho de menor esforço, neste caso o de maior declividade.

Já a ferramenta flow acumulation determina por onde o fluxo hídrico irá se acumular, permitindo a extração da rede de drenagem e a delimitação automática da bacia hidrográfica. Este processo compara cada célula raster com seus vizinhos e determina através dos dados do flow direction quantas células fluem para a primeira, realizando este cálculo para todas as células e determinando os canais hídricos por onde a água escoa e concentra e delimitando a bacia hidrográfica a partir das células que não recebem fluxo de água, as quais na realidade seriam as cristas e os topos de morro, divisores de bacias hidrográficas.

A gestão dos recursos hídricos em cenário nacional é delineada pela Política Nacional de Recursos Hídricos, a qual foi instituída pela Lei nº 9433, de janeiro de 1997, popularmente conhecida como “Lei das Águas” e que traz como fundamentos da gestão dos recursos hídricos dois pontos importantes para a utilização da metodologia aqui empregada, sendo o primeiro “a adoção da bacia hidrográfica como unidade territorial de implementação da Política Nacional de Recursos Hídricos” e o segundo fundamento é que “a gestão dos recursos hídricos deve ser descentralizada”, ou seja, a adoção de bacias hidrográficas menos abrangentes, ou seja, com menor unidade territorial é defendida, de forma que a participação do poder público e dos diversos usuários nas decisões locais sejam mais fortes e constantes.

A utilização desta metodologia além de permitir a delimitação da bacia hidrográfica, ainda permite extrair a rede de drenagem desta unidade territorial, facilitando o planejamento e a gestão dos usos múltiplos da água, o que também é defendido como fundamento na Política Nacional de Recursos Hídricos. Além disso a elaboração da cartografia base para a bacia hidrográfica irá permitir a utilização destes dados para a obtenção de dados de diversas naturezas e a construção de um banco de dados de informações com várias finalidades quantitativas e qualitativas que permitirá maior agilidade na tomada de decisões e facilitará o processo de planejamento e gestão de recursos hídricos.

Alfredo A. Guimarães

alfredo.arantes@gmail.com

Related posts:

1. Modelos Digitais de Elevação e Hidrologia 2
2. Metadata #1

Continuando naquele nosso projetinho, hoje vamos falar sobre a classe em Python que atualiza nossos dados em um determinado banco de dados. Temos algumas particularidades quando trabalhamos com ArcSDE, (registro de camadas como versionadas/não versionadas), portanto mostrarei como trabalhar com um Geodatabase local. A alteração para ArcSDE não é tão grande, e com um cadinho de pesquisa vocês conseguem fazer.

Lembre-se das outras classes que precisamos, mostradas no post anterior.

Construiremos duas classes, uma chamada GeoprocessorWrapper, um "embrulho" do objeto geoprocessor da ESRI. Isto não necessário, mas facilita, já que facilitamos algumas operações através deste "embrulho". A outra será uma tarefa, que juntará todos os dados e resultados das classes anteriores para atualizar nosso banco de dados.

Vamos começar com a mais simples, geoprocessorWrapper:

import arcgisscripting, logHandler

__toolboxAliases = [
            "analysis",
            "management",
            "3d",
            "cartography",
            "arc",
            "interop",
            "geocoding",
            "ga",
            "lr",
            "md",
            "na",
            "samples",
            "sa",
            "stats"]

class geoprocessorWrapperClass():
    def __init__(self,workspace,toolboxList,overwriteOutput=False):
        self.logs = logHandler.logHandlerClass()
        # Startup logging object
        self.gp = arcgisscripting.create(9.3)
        # Startup ESRI geoprocessing object

        self.gp.Workspace = workspace
        self.gp.OverwriteOutput = overwriteOutput
        # Define overwrite output. Default is to FALSE.

        #lista de toolboxes disponiveis
        self.toolboxList = []
        self.toolboxList += toolboxList

        self.buildGeoprocessorOptions(toolboxList)

    def buildGeoprocessorOptions(self):
        for x in self.toolboxList:
            try:
                if x in __toolboxAliases:
                    self.gp.AddToolbox(x)
            except:
                self.logs.newLogMessage(self, "Error in adding " + x + " toolbox to geoprocessor object. Are you sure this toolbox exists?" + self.gp.GetMessages(), "Geoprocessing Error")
    # adds all toolboxes to current geoprocessing object.

    def changeWorkspace(self,workspace):
        self.gp.Workspace = workspace;
    # changes the current workspace in geoprocessing object

    def removeToolboxes(self,toolboxList):
        for x in self.toolboxList:
            try:
                self.gp.RemoveToolbox(x)
                self.toolboxList.remove(x)
                self.logs.newLogMessage(self,"Removed " + x + "toolbox from geoprocessing object.","Information")
            except:
                self.logs.newLogMessage(self,self.gp.GetMessages(),"Geoprocessing Error")
    # removes unneeded toolboxes from current geoprocessing object

Vamos começar com alguns detalhes desta classe:

Em primeiro lugar, temos os tradicionais import x. Eles são responsáveis por disponibilizar outras bibliotecas ao nosso código. Note que importamos o módulo arcgisscripting.

Logo depois, temos uma lista dos aliases que cada toolbox possui no Python. É necessário adicionar uma toolbox ao objeto geoprocessing para que se tenha acesso às ferramentas da mesma - o que pode ser feito de dois jeitos, pelo caminho da toolbox (C:\Program Files\...\ArcGis\Toolbox.tbx) ou pelo seu apelido. A primeira maneira é útil para adicionar toolboxes customizadas, que não tem apelido. A segunda maneira é mais prática para adicionar as toolboxes tradicionais.

O construtor da classe toma dois parâmetros obrigatórios e um opcional para inicializar a classe. O workspace é a pasta onde iremos trabalhar - ele poderia ser também um geodatabase, mas neste caso, uma pasta. toolboxList é uma lista com os apelidos das toolboxes que queremos adicionar ao nosso objeto de geoprocessing. O parâmetro adicional é se você deseja que os resultados do objeto geoprocessing sejam escritos por cima dos anteriores (caso tenham o mesmo nome) e é por default, falso.

O construtor é bastante simples. Ele cria um objeto geoprocessing, utilizando a versão 9.3 como opção (ajuste para sua versão caso necessário - mas não garanto que funcione na 9.2 - já que vários métodos como ListDatasets, têm uma resposta diferente do que
na versão 9.3), define qual é o workspace inicial e adiciona as toolboxes relevantes.

A forma de uso é a seguinte:

g = geoprocessorWrapper.geoprocessorWrapperClass(r"C:\",["analysis","management","lr"])
#ou
g = geoprocessorWrapper.geoprocessorWrapperClass(r"C:\",["analysis","management","lr"],true)

# para acessar o geoprocessor do nosso wrapper, use:

listaDeFeatureClasses = g.gp.ListFeatureClasses()

for x in listaDeFeatureClasses:
    print x.FeatureType

Bem simples né? Temos um método também para mudar de workspace, sem necessitar de criarmos uma nova ferramenta. O outro método disponível é para remover toolboxes que não precisamos. Um método aqui poderia ser facilmente criado para adicionar novas toolboxes ao objeto. Alguém se arrisca?

Com esta classe podemos fazer quaisquer operações, mas utilizaremos uma outra classe para realizar todo o trabalho sujo. Lembra-se do código do post passado? Temos disponível em nossa máquina um arquivo .zip extraído em uma pasta qualquer, correto?

Vamos à classe geodatabaseUpdateTask.

import os, sys

class geodatabaseOperationClass():
    def __init__(self,geoprocessor,inputShapefile,outputGeodatabase,outputFeatureDataset,outputFeatureClass):

        self.geoprocessorWrapperClass = geoprocessor

        self.inputShapefile = inputShapefile

        self.outputGeodatabase = outputGeodatabase
        self.outputFeatureDataset = outputFeatureDataset
        self.outputFeatureClass = outputFeatureClass

        self.processStage = 0
        self.stages = ["Testes de conformidade",
                       "Deleçãoo de Feature Class",
                       "Cópia de Shapefile",
                       "Atualização Completa"]

    def getProcessStage(self):
        return self.stages[self.processStage]

    def testGeodatabase(self):
        #workspace definido pelo geoprocessor
        return self.outputGeodatabase in self.geoprocessorWrapperClass.gp.ListWorkspaces(self.outputGeodatabase,"ALL")

    def testFeatureDataset(self):
        #adaptando workspace
        self.geoprocessorWrapperClass.gp.Workspace += "\\" + self.outputGeodatabase
        return self.outputFeatureDataset in self.geoprocessorWrapperClass.gp.ListDatasets(self.outputFeatureDataset,"ALL")

    def testFeatureClass(self):
        #adaptando workpace
        self.geoprocessorWrapperClass.gp.Workspace += "\\" + self.outputFeatureDataset
        return self.outputFeatureClass.gp.Workspace in self.geoprocessorWrapperClass.gp.ListFeatureClasses(self.outputFeatureClass,"ALL")

    def testAllObjetcs(self):
        if self.testGeodatabase() and self.testFeatureDataset() and self.testFeatureClass():
            self.processStage = 1
            return True
        else:
            self.processStage = 0
            return False

    def deleteFeatureClass(self,featureClass):
        try:
            self.geoprocessorWrapperClass.gp.Delete_management(featureClass)
        except:
            print self.geoprocessorWrapperClass.gp.getmessages()

    def copyFeatures(self,inputShapefile,outputFeatureClass):
        try:
            self.geoprocessorWrapperClass.gp.CopyFeatures_management(inputShapefile,outputFeatureClass)
        except:
            print self.geoprocessorWrapperClass.gp.getmessages()

    def updateFeatureClass(self):
        try:
            if self.testAllObjects:
                self.processStage += 1
                print self.getProcessStage()

                self.deleteFeatureClass(self.outputFeatureClass)
                self.processStage += 1
                print self.getProcessStage()

                self.copyFeatures(self.inputShapefile,self.outputFeatureClass)
                self.processStage += 1
                print self.getProcessStage()
        except:
            print self.geoprocessorWrapperClass.gp.getmessages()

Temos os tradicionais import no cabeçalho de nosso arquivo e logo depois o construtor da classe.

Nosso construtor tem os seguintes parâmetros: geoprocessor (um objeto do tipo geoprocessorWrapper), o caminho para o shapefile à ser carregado no banco de dados, o geodatabase de destino, o featureDataset de destino e a FeatureClass de destino.

Você pode ver que construí uma lista de estágios que temos de passar antes de atualizar a FeatureClass. O estágio testes de conformidade vão garantir que os objetos existam no geodatabase e não ocorram erros. Esta etapa pode ser customizada, caso a FeatureClass não exista, crie a mesma, somente importando os dados - também deixo isto para o usuário interessado! Lembre-se que temos de passar um objeto geoprocessorWrapper com um workspace, uma pasta. Neste caso em específico, deve-se passar apenas pastas, pois definimos o geodatabase em outras áreas.

Os testes cuidam da mudança de workspace e asseguram que a featureClass exista. Perceba que todo o trabalho é realizado dentro desta classe, nas funções:

• deleteFeatureClass()
• copyFeatureClass()

Uma função resume todo o processo: updateFeatureClass(). Veja que ela não tem parâmetros, pois usa os parâmetros setados no construtor. À medida que a mesma progride, atualiza o status do processo e informa ao usuário.

Forma de uso:

gp = geoprocessorWrapper.geoprocessorWrapperClass(r"C:\",['management'])
geoOperation = geodatabaseOperation.geodatabaseOperationClass(gp,r"C:\shapefile.shp","teste.mdb","dnpm","dnpm_brasil")
geoOperation.updateFeatureClass()

Lembrem-se que o restante do código (buscar o arquivo na net, dezipar, etc) está no post anterior. Como prometi, aqui vai a classe LogHandler.

LogHandler Class

E ae pessoal? Dúvidas?

Podem ver que o Python dá muito poder ao framework de geoprocessing do ArcGIS e é muito simples.

Um abraço

George

Related posts:

1. Usando Python e o Geoprocessing Framework #1
2. #Python – pt2
3. OOP com python – Uma breve introdução.

O ArcGIS 10 finalmente foi lançado para venda oficialmente durante esta semana. Nos Estados Unidos, pelo menos.

O novo ArcGIS promete muita coisa, ArcCatalog integrado com ArcMap, capacidade de edição em três dimensões (dentro do ArcMap!), entre outras coisinhas bastante interessantes.

Temos agora uma nova API para programação em Python, a ArcPy, que pelo visto é bastante poderosa. Criaram novas classes, interfaces e funcionalidades, incluindo a capacidade de automatizar a produção de mapas com Python - o que é uma excelente notícia.

A ESRI já até mudou a cara do site deles para o anúncio. Aqui temos um link com as novas funcionalidades.

George

Related posts:

1. #Python – o que é?
2. ArcObjects #1 – introdução
3. ArcGIS.com lançado

Não podemos criar estas geometrias de alto nível, sem criar antes as geometrias de baixo nível que as compõe. É a maneira na qual o ArcGIS trabalha, e é a mais sã, do ponto de vista de desenvolvimento.

Primeiro vamos construir um polígono. Podemos construir os anéis separadamente, de pontos ou de segmentos e logo depois, adicionar à uma coleção de geometrias, na qual o próprio ArcGIS irá entender como um polígono.

public static IPolygon ConstruirPolígono()
    {
        object _missing = Type.Missing;

        IGeometryCollection poligonoFinal = new PolygonClass();

        // vamos criar primeiro nosso anel exterior
        // perceba com estamos utilizando uma interface IPointCollection

        IPointCollection anelExterior = new RingClass();

        // lembram da função BuildPoint do post anterior?

        anelExterior.AddPoint(BuildPoint(0,0,0),ref _missing, ref _missing);
        anelExterior.AddPoint(BuildPoint(0,1,0),ref _missing, ref _missing);
        anelExterior.AddPoint(BuildPoint(1,1,0),ref _missing, ref _missing);
        anelExterior.AddPoint(BuildPoint(1,0,0),ref _missing, ref _missing);

        // o último ponto deve ser sempre igual ao primeiro - somente assim
        // o polígono está fechado
        // podemos utilizar também uma outra técnica para usar o primeiro ponto
        // sem duplicar o ponto inicial - muito útil se você não sabe de antemão qual é o primeiro ponto.
        // anelExterior.AddPoint(anelExterior.get_Point(0),ref _missing, ref _missing);

        anelExterior.AddPoint(BuildPoint(0,0,0));

        poligono.AddGeometry(anelExterior as IGeometry, ref _missing, ref _missing);

        // definir a referência espacial - sem a referência espacial o ArcGis não realiza operações espaciais direitinho!

        return poligono as IPolygon;
}

Polígono construído com o código anterior

public static IPolygon ConstruirPolígono()
    {
        object _missing = Type.Missing;

        IGeometryCollection poligonoFinal = new PolygonClass();

        // vamos criar primeiro nosso anel exterior
        // perceba com estamos utilizando uma interface IPointCollection

        IPointCollection anelExterior = new RingClass();

        // lembram da função BuildPoint do post anterior?

        anelExterior.AddPoint(BuildPoint(0,0,0),ref _missing, ref _missing);
        anelExterior.AddPoint(BuildPoint(0,10,0),ref _missing, ref _missing);
        anelExterior.AddPoint(BuildPoint(10,10,0),ref _missing, ref _missing);
        anelExterior.AddPoint(BuildPoint(10,0,0),ref _missing, ref _missing);

        // o último ponto deve ser sempre igual ao primeiro - somente assim
        // o polígono está fechado
        // podemos utilizar também uma outra técnica para usar o primeiro ponto
        // sem duplicar o ponto inicial - muito útil se você não sabe de antemão qual é o primeiro ponto.
        anelExterior.AddPoint(anelExterior.get_Point(0),ref _missing, ref _missing);

        IPointCollection anelInterior = new RingClass();
        anelInterior.AddPoint(BuildPoint(1,1,0), ref _missing, ref _missing);
        anelInterior.AddPoint(BuildPoint(1,2,0), ref _missing, ref _missing);
        anelInterior.AddPoint(BuildPoint(2,2,0), ref _missing, ref _missing);
        anelInterior.AddPoint(BuildPoint(2,1,0), ref _missing, ref _missing);
        anelInterior.AddPoint(anelInterior.get_Point(0),ref _missing, ref _missing);

        // nao é permitido sobrepor anéis, à menos que eles tenham orientações contrárias
        // nosso anel exterior tem orientação horária - todos os anéis exteriores devem ter orientação horária!
        // anéis interiores, que descrevem buracos em nossos polígonos devem ter orientação anti-horária!
        ICurve curva = anelInterior as ICurve;
        curva.ReverseOrientation();

        poligono.AddGeometry(anelExterior as IGeometry, ref _missing, ref _missing);
        poligono.AddGeometry(anelInterior as IGeometry, ref _missing, ref _missing);

        // definir a referência espacial - sem a referência espacial o ArcGis não realiza operações espaciais direitinho!

        return poligono as IPolygon;
}

Polígono simples criado pelo código acima (fora de escala)

Bem, é fácil trabalhar com geometrias da ESRI. Claro, quanto mais complexa a geometria, mais complexo deverá ser o código para cuidar da mesma. Mas não é nenhum bixo de 7 cabeças. Um outro detalhe interessante é que revertemos a orientação da geometria interna usando uma outra interface, e adicionamos nosso anel original. Por que funciona? A biblioteca ArcObjects fica responsável por notificar a geometria original de que certa operação ocorreu e a realiza de acordo.

Em geral, os passos para se trabalhar com geometrias complexas é construir anéis ou segmentos, criados através da interface IPointCollection, pois assim podemos ir adicionando os pontos que temos interesse e depois ajeitar a orientação de cada anel para nos dar o resultado desejado.

Certo, mas e um polígono que contenha curvas? O formato shapefile não suporta(va) o desenho delas e estão disponíveis à partir dos geodatabases (as curvas são convertidas em diversos segmentos, aproximando o resultado. Mas podemos criar um polígon com curvas via código? Sim, claro! O segredo, neste caso, é separar cada segmento em um anel, mesmo que ele, no final, seja parte de uma coisa só.

Vamos criar dois anéis, um para nosso segmento curvo e o outro para nossos segmentos retos. Juntaremos os dois em apenas um anel e depois adicionaremos este anel ao polígono.

Para construir segmentos curvos, existem diversas interfaces do tipo IConstruct* (IConstructCircularArc, IConstructBezierCurve, etc.), cada uma com suas particularidades.

object _missing = Type.Missing;

        IGeometryCollection polygon = new PolygonClass();

        // building circular arc

        IPoint p1 = PointPolygonBuilder.BuildPoint(1, 2);
        IPoint p2 = PointPolygonBuilder.BuildPoint(1, 1);
        IPoint p3 = PointPolygonBuilder.BuildPoint(1, 0);
        IPoint p4 = PointPolygonBuilder.BuildPoint(0, 0);
        IPoint p5 = PointPolygonBuilder.BuildPoint(0, 1);

        IConstructCircularArc constructCircularArc = new CircularArcClass();
        constructCircularArc.ConstructThreePoints(p5, p2, p1, true);
        ICircularArc circularArc = constructCircularArc as ICircularArc;
        // end circular Arc

        ISegmentCollection finalRing = new RingClass();
        ISegmentCollection ring1 = new RingClass();
        IPointCollection ring2 = new RingClass();

        ring1.AddSegment(circularArc as ISegment, ref _missing, ref _missing);
        ring2.AddPoint(p1, ref _missing, ref _missing);
        ring2.AddPoint(p3, ref _missing, ref _missing);
        ring2.AddPoint(p4, ref _missing, ref _missing);
        ring2.AddPoint(p5, ref _missing, ref _missing);

        finalRing.AddSegmentCollection(ring1);
        finalRing.AddSegmentCollection(ring2 as ISegmentCollection);
        polygon.AddGeometry(finalRing as IGeometry, ref _missing, ref _missing);

Polígono resultante do código acima

Note que deu um trabalhinho à mais para montar este segmento curvo. É bom deixar claro também, que o ponto (1,1) representado na figura, não entra no anel feito de segmentos retos, ele é apenas utilizado para construir o segmento curvo.

Outra coisa legal é ver que para acessar alguns métodos, você tem que instanciar certas interfaces. Notem que o finalRing e ring1 possuem propriedades semelhantes, pois têm a mesma interface. Já ring2 possui outros membros, pois é de interface diferente. Classes iguais, interfaces diferentes = propriedades diferentes.

E aí, o que acharam?

Abraços pessoal!

George R. C. Silva

Related posts:

1. Brincando com ArcObjects
2. Funções PostGIS #3
3. ArcObjects #1 – introdução

Hoje quero falar um pouquinho do framework de geoprocessamento do ArcGIS, disponível em Python. Python, como sabem, é uma linguagem de alto nível, orientada à objetos e muito - mas muito fácil de se aprender.

Existem tarefas extremamente repetitivas que podem ser facilmente automatizadas com um pouquinho de Python e o tal Geoprocessing. O ArcGIS, basicamente faz uso do Python em toda a command-line e em algumas ferramentas da toolbox. Tudo que é feito no ModelBuilder é convertido em código Python.

Bem, vamos à proposta: imagine que você tenha necessidade de atualizar dados disponibilizados como shapefiles, por um órgão do governo, de forma periódica e em um banco de dados (ArcSDE, Personal GDB, File GDB, etc.). Será possível?

Bem, isto é possível pois o Python conta com milhares de bibliotecas para acesso à páginas da web, compressão/descompressão de arquivos .zip, entre outras. Este foi um requerimento real de um trabalho antigo.

Bem, imaginemos o site do DNPM, que disponibiliza shapefiles dos direitos minerários, de tempos em tempos (o DNPM também publica um serviço web, mas nem sempre é um bom caminho). No site SIGMINE você pode puxar separado por estados o shape atualizado e alimentar um banco. Mas é muito trampo para ser feito toda semana. Ainda mais se tua base não for centralizada. Todo mundo tem atualizar milhares de mxds, mapas, etc.

Quais são nossos passos?

• Fazer o download do shapefile em .zip
• Descompactar nosso arquivo em disco
• Atualizar o banco de dados

Podemos realizar o passo número 3 de várias formas, deletando a Feature Class antiga ou então atualizando registro por registro. Para nosso exercício, vamos deletar todos os registros e inseri-los novamente. Em ambientes mais controlados, com outras necessidades, talvez isto não seja o ideal.

Para contemplar nosso objetivo, iremos criar algumas classes:

• leecherHandler - responsável pelo download de arquivos da web;
• folderHandler - responsável pela criação/deleção de pastas;
• zipHandler - responsável pela compressão/descompressão de arquivos .zip;
• logger - responsável por guardar mensagens importantes para controle do que está acontecendo;
• geoprocessor - responsável por realizar as operações e interfaces com o ArcGIS;

Vamos começar pela classe leecherHandler, que é o coração de nosso pequeno sistema:

import sys, urllib2, logHandler

class leecherHandlerClass():

    def __init__(self,webAddress,tempFolder):
        self.logs = logHandler.logHandlerClass()
        # Startup the log object.

        self.webAddress = webAddress
        self.tempFolder = tempFolder
        self.localFile = self.buildLocalFile(self.downloadWebFile())

    def buildFileName(self,webAddress):
        fileName = "\\" + webAddress.split(r"/")[-1]
        return fileName

    def downloadWebFile(self):
        try:
            self.logs.newLogMessage(self,"Starting download...","Information")
            # @eventoLogged: Start download.
            webFile = urllib2.urlopen(self.webAddress)
            # Opening the URL chosen.
            self.logs.newLogMessage(self,"Finished download.","Information")
            # @eventLogged: Download finished. Return a file object type.
            return webFile
        except:
            self.logs.newLogMessage(self,"It was not possible to download file.\n" + str( sys.exc_info()[0]),"Error")
            # @eventLogged: Error downloading file from URL

    def buildLocalFile(self,webFile):
        try:
            self.logs.newLogMessage(self,"Writing file to disk...","Information")
            # @eventLogged: Start writing to a local file.
            fileName = self.buildFileName(self.webAddress)
            localFile = open(self.tempFolder + fileName,"wb")
            # Get the filename and open a localfile.

            localFile.write(webFile.read())
            # Write to brand new file.
            # @todo: find a better way to write the file to disk

            webFile.close()
            localFile.close()
            # Close both files. Clean-up action.

Esta classe é bastante simples. Ela usa o módulo urllib2 para fazer os downloads, além de construir um novo arquivo em disco, na pasta especificada. Vejam que o código da função downloadWebFile é muito simples. Apenas precisamos apontar qual é o arquivo que queremos puxar e ela já o constrói em disco, com um nome alterado com data - para não nos perdemos.

Você não precisa fazer mais nada, pois no construtor da classe, ela já dispara todas as ações de download e construção de arquivo em disco. Pode levar um tempo para puxar os arquivos, mas em geral é bastante rápido. Caso seja necessário, você terá de montar e inicializar um proxy - que também será mostrado.

A forma de uso é bastante simples:

    shapeLeecher = leecherHandler.leecherHandlerClass('endereco do arquivo web','pasta temporaria de destino')
    # para acessarmos o arquivo local em disco, utilzamos a seguinte sintaxe:
    # shapeLeecher.localFile

Teremos agora um arquivo .zip em disco. Precisamos descompactá-lo. Crie uma nova classe, com a seguinte definição:

import sys, zipfile, logHandler

class zipHandlerClass():

    def __init__(self,tempFolder,zipFilePathname,watchFileFormat="shp"):
        self.logs = logHandler.logHandlerClass()
        # Startup the log object

        self.tempFolder = tempFolder
        self.zipFilePathname = zipFilePathname
        self.watchFileFormat = watchFileFormat
        # Basic properties

        self.containedFiles = []
        # Generated file list inside zip archive
        self.outputWatchFile = watchFileFormat
        # outputInformation

    def testZipFile(self):
        if self.zipFilePathname == None or zipfile.is_zipfile == False:
            self.logs.newLogMessage(self,"File pointed is not a valid zipfile" + str(sys.exc_info()[0]),"Error")
            return False
        else:
            return True

    def readContainedFiles(self,zipFile):
            return zipFile.namelist()

    def extractFiles(self):
        try:
            if self.testZipFile()== True:
                extractingFile = zipfile.ZipFile(self.zipFilePathname,"r")
                self.containedFiles = self.readContainedFiles(extractingFile)
                # Defines a zipFile object using pathname for further manipulation. Read the files inside archive.
                for zippedFile in self.containedFiles:
                    unpackedFile = open(self.tempFolder + "\\" + zippedFile, "wb")
                    unpackedFile.write(extractingFile.read(zippedFile))
                    unpackedFile.close()
                    # Unpack and write file to disk
                    self.logs.newLogMessage(self,"File " + zippedFile + " unpacked and written to disk.","Information")
                    # @eventLogged: Zip file unpacked and written in disk with success.

                    if zippedFile[-3:] == self.watchFileFormat:
                        self.outputWatchFile = zippedFile
                    else:
                        self.outputWatchFile = self.tempFolder
                    # Test to see if any of these files is of type watched.
                    # @todo: make this classe output a list of watched files.
                extractingFile.close()
                # close extracted file. CleanUp.
                return True
            else:
                return False
            # Test to see if it is a valid zipfile. If not, return false.
        except zipfile.BadZipfile:
            self.logs.newLogMessage(self,"Corrupted zipfile. Please download it again.","Error")
            return False

Esta classe é um pouco mais complicada. Temos de monitorar um arquivo mestre (em nosso caso, um shapefile) para que possamos iniciar os próximos passos. Olhem a definição da classe - ela pede uma pasta temporária (a mesma que você usou com o leecher), uma localização do arquivo .zip e um formato. Este formato, tem como default a extensão .shp, mas você pode especificar outro.

    # a idéia é que se use os resultados armazenados na classe leecher para alimentar
    # o construtor da classe zipHandler, criando um processo encadeado
    zipH = zipHandler.zipHandlerClass('pasta temporaria','arquivo.zip');
    zipH.extractFiles()

No frigir dos ovos, esta classe testa o arquivo zip, confere se o mesmo é válido, extrai os arquivos para a pasta selecionada, e guarda uma referência ao arquivo com a extensão escolhida.

Vamos mostrar agora a clase folderHandler. Ela irá criar nossas pastas para nós:

import sys, os,datetime, shutil, logHandler

class folderHandlerClass():
    def __init__(self,tempFolder):
        self.logs = logHandler.logHandlerClass()
        self.tempFolder = tempFolder

    def generateTempFolderName(self):
        dataHora = datetime.date.today()
        folderName = self.tempZipFile[:-4] + "_" + str(dataHora)
        return folderName

    def createTempFolder(self):
        try:
            if os.path.exists(self.tempFolder):
                if os.path.isdir(self.tempFolder):
                    return True
                else:
                    self.logs.newLogMessage(self,"The specified folder is not a valid folder.","Error")
                    # @eventLogged: Folder is not valid.
                    return False
            else:
                os.mkdir(self.tempFolder,222)
                self.logs.newLogMessage(self,"Folder " + self.tempFolder + " created with success.","Information")
                # @eventLogged: Folder create with success.
                return True
        except:
            self.logs.newLogMessage(self,"An unexpected error occurred while creating the specified folder.\n" + str(sys.exc_info()[0]),"Error")
            # @eventLogged: Error while creating folder. More info on sys.exc_info()

    def deleteTempFolder(self):
        try:
            shutil.rmtree(self.tempFolder)
        except:
            self.logs.newLogMessage(self,"An unexpected error occurred while deleting the specified folder.\n" + str(sys.exc_info()[0]),"Error")
            # @eventLogged: Error while deleting folder. More info on sys.exc_info()

Esta classe tem dois métodos principais: um para criar pastas e outro para deletá-las. A classe executa uma verificação básica para saber se a pasta existe ou é uma pasta. Em caso de positivo a pasta não é criada, apenas usada como destino dos arquivos. Caso ela não exista, a classe tenta criá-la. Isto é feito para economizarmos uma operação e evitar de criar uma pasta com um nome já existente, o que nos daria um erro.

O método que deleta a pasta é radical. Ele remove tudo que existe dentro da pasta. Sub-pastas, arquivos, não importa. Ele irá deletar tudo. Cuidado ao usá-lo com outros arquivos. O ideal para se trabalhar com este script é uma pasta separada só para ele. Para usar esta classe, faça assim:

    # como usar:
    folderH = folderHandler.folderHandlerClass('pasta temporaria')
    folderH.createTempFolder()
    # ele irá tentar criar a pasta
    folderH.deleteTempFolder()
    # ele irá tentar deletar a pasta e seu conteúdo

Bem, com estas classes conseguimos construir um pequeno framework para atualizarmos os dados em um banco do ArcGIS. São coisas simples, mas que ajudam bastante. No próximo post, teremos a classe que cuida das operações de geoprocessamento, interfaceando com o ArcGIS - e uma classe "mestra" que faz todas estas classes conversarem.

Como utilizar as três classes juntas?

import sys,folderHandler,zipHandler,leecherHandler

    # primeiro tentamos acessar/criar a pasta que queremos
    # lembrem-se que um r antes de uma string, significa raw
    # não sendo necessário escapar os caracteres \
    folderH = folderHandler.folderHandlerClass(r"C:\temporario")
    folderH.createTempFolder()

    # é só inicializar o leecher Handler. seu construtor cuida do restante para nós
    shpLeecher = leecherHandler.leecherHandlerClass("ftp://sigmine.dnpm.gov.br/Brasil.zip",folderH.tempFolder)

    # podemos inicializar o zipHandler de duas maneiras
    # com uma chamada explícita
    zipH = zipHandler.zipHandlerClass(folderH.tempFolder,shpLeecher.localFile,"shp")

    # ou implicita, caso a extensao seja shapefile - pois é um parametro com uma entrada
    # default. se nada for especificado, .shp irá cair em seu lugar
    # zipH = zipHandler.zipHandlerClass(folderH.tempFolder,shpLeecher.localFile)
    zipH.extractFiles()

Com o código acima e as três classes descritas,  já conseguimos puxar um arquivo da web e descompactá-lo para uma pasta qualquer.

Vocês podem notar que existem outras classes envolvidas aqui, especialmente o tal de LogHandler. Irei disponibilizar todo o projeto no próximo post

Quaisquer dúvidas, estou à disposição!

Abraços

George

Related posts:

1. Usando Python e o geoprocessing framework #2
2. Configure o TerraLib 3.3 no Visual Studio 2003
3. OOP com python – Uma breve introdução.

Vocês conhecem o site StackOverflow? Bem, o StackOverflow é um site para perguntas e respostas sobre programação. O site tem um modelo interessante, onde cada usuário pode postar suas dúvidas, indicar algumas tags e claro, todo mundo pode responder. Existem alguns sites irmãos: SuperUser (perguntas e respostas sobre informática em geral), ServerFault e o Meta (tudo sobre o modelo StackOverflow).

O mais interessante, é que no StackOverflow, as pessoas avaliam as respostas. Quanto melhor a resposta, mais chances de ela ser votada e mais chances de ela ser considerada a escolhida como melhor resposta - tudo isto em troca de pontos de reputação. O site é muito legal.

Algumas semanas atrás, sugeri à um dos criadores do website à criar um StackOverflow, mas no assunto de GIS. O que o site teria como perguntas e respostas? Tudo sobre SIG/GIS, GNSS, topografia, utilização de softwares, metodologias, algoritmos, programação específica para SIG/GIS, enfim, tudo geoespacial.

Bem, ele não apoiou minha idéia, mas me deu um link para um site em que eles (os criadores do StackOverflow) abriram para a comunidade sugerir sites, com um processo todo elaborado, de definição de escopo, votação de perguntas on e off topic e uma fase de commitment.

Não é que o site está vingando? Atualmente estamos na fase de commitment com muitos usuários. Vi nomes de peso da OsGEO, bloggers importantes e diversas pessoas interessadas em colaborar.

Fica a sugestão: conheça o StackOverflow, o SuperUser ou o ServerFault e ajude o GIS StackOverflow à decolar! Lembrando que este projeto de site, logo logo deve estar no ar, não é específico de nenhuma tecnologia. Não estamos no limitando à ESRI ou à OpenSource. É geoespacial? Faz parte

Tão aí os links:

• SIG/GIS StackOverflow
• StackOverflow
• ServerFault
• SuperUser

Abraços

George Silva

Related posts:

1. MNT – O que é? Para que serve?
2. GIS StackExchange Beta público
3. Desenvolvendo um SIG para Suporte de Decisões Municipais