( PDF ) Definição de modelo espaço-temporal para redes de drenagem

Download PDF

ads:

UNIVERSIDADE FEDERAL DO PARANÁ

ALUÍZIO CARLOS WANDERLEY GROCHOCKI

DEFINIÇÃO DE UM MODELO ESPAÇO-TEMPORAL

DE REDES DE DRENAGEM

Curitiba

2008

ads:

Livros Grátis

http://www.livrosgratis.com.br

Milhares de livros grátis para download.

ALUÍZIO CARLOS WANDERLEY GROCHOCKI

DEFINIÇÃO DE UM MODELO ESPAÇO-TEMPORAL DE REDES DE DRENAGEM

Dissertação apresentada ao Curso de Pós-

Graduação em Ciências Geodésicas, Setor de

Ciências da Terra, Universidade Federal do

Paraná, como requisito parcial à obtenção do título

de Mestre em Ciências Geodésicas.

Orientador: Prof. Dr. Antônio José Berutti Vieira

Curitiba

2008

ads:

À Mônica, minha esposa e amiga.

Aos meus filhos Pedro, Bernardo, Marina e Tiago.

Pelo amor e carinho.

AGRADECIMENTOS

Aos meus pais (in memorian) pelo exemplo de vida e dedicação. Mesmo na

ausência deles, seus ensinamentos continuam presentes norteando minha vida.

Ao meu irmão Luiz Henrique pela amizade e dedicação de todas as horas, sempre

me auxiliando nesta e em outras empreitadas.

À minha família pelo amor, compreensão, apoio e incentivo recebidos ao longo de

todo este tempo.

Aos amigos e professores João Fernando (JF) Custódio da Silva, da UNESP de

Presidente Prudente e Vóldi Zambenedetti, do LACTEC, pelo incentivo na realização

deste Curso.

Ao meu orientador, professor Antônio José Berutti Vieira, pela oportunidade, ajuda e

discussões valiosas durante o Curso e ao longo deste trabalho.

À professora Cláudia Robbi Sluter, ao professor Henrique Firkowski e ao professor

Jorge Antônio Silva Centeno pela amizade, paciência e dedicação nas explicações

às dúvidas em aulas e nos trabalhos das disciplinas.

Aos professores membros da banca do Seminário, professor Hélio Pedrini, do

Departamento de Informática da UFPR, professor Quintino Dalmolin e professora

Luciene Stamato Delazari, pelo tempo dispendido e pelas valiosas sugestões.

A todos os colegas do Curso, obrigado pela amizade e colaboração. Em especial, ao

colega de trabalho, analista de sistemas Luiz Dias Pereira, pelo auxílio e sugestões

nos códigos da interface gráfica e leitura de arquivos do protótipo.

Ao Tribunal de Justiça do Paraná, pela possibilidade de compensar os horários de

aulas e reuniões, que me deixaram ausente do meu local de trabalho.

À Coordenação do CPGCG da UFPR, pela oportunidade conferida e à secretária do

Curso, sra. Mônica, pela atenção recebida.

RESUMO

Redes de drenagem são fenômenos terrestres estudados em ciências como

Cartografia, Hidrologia, Florestal, Geologia e Geografia. Em Hidrologia, redes de

drenagem, juntamente com outros elementos como forma, relevo, tipo de solo e

cobertura vegetal, desempenham importante papel no estudo do comportamento

hidrológico de uma bacia hidrográfica e formam a base na qual a morfologia e

paisagens são caracterizadas ao longo do tempo. Em Geologia, muitas conclusões

geológicas são fundamentadas em inferências derivadas das redes de drenagem.

Em Cartografia, quase todos os mapas representam-nas como um fenômeno

terrestre de referência. Dados advindos desta referência descrevem, em geral, a

estrutura e relacionamentos espaciais do fenômeno em instantes distintos do tempo,

caracterizados pela geometria e topologia, além da semântica definida pelo

observador. Estes dados, quando estruturados adequadamente num modelo de

dados, formam o que é visto como núcleo conceitual do sistema de informação. É

possível expressar este modelo de dados num modelo correspondente de classes

de objetos, conferindo maior poder de abstração e melhor aproximação semântica

com o fenômeno investigado. Assim, além de capturar atributos geométricos e

topológicos do fenômeno, é possível definir operadores que modelam

comportamento de objetos. Este modelo de classes também pode ser estendido

para expressar novos fenômenos especializados ou advindos de uma combinação

entre eles, muito comuns em estudos que envolvam múltiplas disciplinas. A falta de

um modelo próprio de classes de objetos que formalize redes de drenagem foi a

motivação deste trabalho. Partindo-se do princípio de que redes de drenagem

podem ser formadas por redes de pontos e linhas, representadas por meio de

grafos, neste trabalho utilizou-se a UML (Unified Modeling Language) para expressar

estes fenômenos terrestres. Uma metodologia é proposta para a construção do

modelo que resultou numa estrutura de dez classes de objetos: RedeDeDrenagem,

Canal, TrechoDeCanal, No, Polilinha, PontoTopografico, TipoRede,

TipoFenomenoTerrestre, TipoOrdenamento e REM. Um protótipo de software foi

desenvolvido que utiliza o modelo proposto e alguns operadores de classes foram

implementados. Um conjunto de experimentos com dados de três redes de

drenagem foi conduzido, apresentando resultados que confirmaram o modelo ser

adequado segundo os objetivos e premissas estabelecidos. Uma análise dos

resultados é discutida e recomendações são sugeridas para prosseguimento desta

pesquisa.

Palavras-chave: Fenômeno terrestre. Rede de drenagem. Modelagem. UML. Classe.

Objeto.

ABSTRACT

Drainage networks are earth’s phenomena studied in sciences like Cartography,

Hydrology, Forest, Geology and Geography. Among other geomorphic elements as

form, relief, soil type and vegetation coverage, drainage networks play an important

role in the study of hydrologic behavior of a hydrographical basin and are the basis

for characterizing morphology and landscape patterns along the time. Many

geological conclusions are based on inferences drawn from drainage networks. In

Cartography, almost all the maps represent them as terrestrial phenomenon of

reference. In general, drainage networks data describe them as a spatial structure

and relationship in distinct instants of the time, featured by the geometry, topology

and semantic observer’s view. When adequately structured in a data model, these

data form what is understood as a conceptual core of the information system. It is

possible to express this model in a corresponding object class model, providing

better abstraction power and better semantic approach with the investigated

phenomenon. Thus, beyond capturing phenomenon geometric and topological

attributes, it is possible to define operators that model object behaviors, extending

the classes to express new specialized phenomena or a combination of them, very

common when carrying out multidisciplinary studies. The lack of an object class

model that formalizes a pattern for draining networks was the motivation of this work.

Knowing that draining networks can be built by sets of points and lines, represented

by graphs, this work uses the UML (Unified Modeling Language) to formalize a

pattern for these terrestrial phenomena. A methodology is proposed for the

construction of a model which resulted in a structure of ten object classes:

RedeDeDrenagem, Canal, TrechoDeCanal, No, Polilinha, PontoTopografico,

TipoRede, TipoFenomenoTerrestre, TipoOrdenamento e REM. A software prototype

was built to apply the proposed model and some class operators had been

developed. A set of data experiments with three drainage networks was conducted,

presenting results that had confirmed the model being suited and in accordance with

the objectives and established premises. An analysis of the results is discussed and

recommendations suggested for further works.

Key words: Earth´s phenomena. Drainage networks. Modeling. UML. Classes.

Objects.

LISTA DE ILUSTRAÇÕES

FIGURA 1 - EXEMPLO DE REDE DE DRENAGEM ............................................................................ 12

FIGURA 2 - VISÃO GERAL SOBRE ESTRATÉGIA DE DESENVOLVIMENTO DO SNIRH ............... 15

FIGURA 3 - DIAGRAMA DE ETAPAS DO PROCESSO DE ESTUDO DE UM FATO ......................... 19

FIGURA 4 - EXEMPLO DE DIAGRAMA DE GRAFO ........................................................................... 26

FIGURA 5 - GRAFO PLANAR E NÃO-PLANAR .................................................................................. 26

FIGURA 6 - GRAFO, MATRIZ DE INCIDÊNCIA E MATRIZ DE ADJACÊNCIA .................................. 28

FIGURA 7 - LISTA DE ADJACÊNCIA PARA CADA NÓ (GRAFOS ESPARSOS): (a) GRAFO

ORIENTADO; (b) GRAFO NÃO-ORIENTADO ................................................................. 29

FIGURA 8 - EXEMPLO DE POLILINHAS ............................................................................................. 30

FIGURA 9 - VISUALIZAÇÃO DE UMA POLILINHA NO SOFTWARE ArcMap

.................................. 31

FIGURA 10 - INTERSEÇÃO DE REMs (a) REMs DISJUNTOS (b) .................................................. 32

FIGURA 11 - USO DE REMS DE POLILINHAS PARA A DETERMINAÇÃO DE INTERSEÇÕES ..... 33

FIGURA 12 - ESTRUTURA TEMPORAL .............................................................................................. 35

FIGURA 13 - DIAGRAMA DE CLASSES DE OBJETOS PARA FENOMENOS TERRESTRES ......... 38

FIGURA 14 - AS ESPECIALIZAÇÕES DA CLASSE FenomenoTerrestre ........................................... 39

FIGURA 15 - CLASSE AreaLevantamento E FENÔMENOS TERRESTRES LEVANTADOS ............ 39

FIGURA 16 - ÁREAS DE LEVANTAMENTO COM O PASSAR DO TEMPO ...................................... 40

FIGURA 17 - MEMBROS DA CLASSE Recobrimento E DA CLASSE AreaLevantamento ................. 40

FIGURA 18 - ELEMENTOS DE REDE DE DRENAGEM ..................................................................... 42

FIGURA 19 - PADRÕES DE DRENAGEM ........................................................................................... 44

FIGURA 20 - MÉTODOS DE ORDENAMENTO HIDROLÓGICO ........................................................ 48

FIGURA 21 - AS CINCO VISÕES DE UM SISTEMA DE SOFTWARE ................................................ 54

FIGURA 22 - DIAGRAMAS DA UML .................................................................................................... 56

FIGURA 23 - EXEMPLO DE DIAGRAMA DE CASOS DE USO .......................................................... 58

FIGURA 24 - EXEMPLO DE UM DIAGRAMA DE CLASSES .............................................................. 59

FIGURA 25 - EXEMPLO DE CLASSE EM UML ................................................................................... 60

FIGURA 26 - EXEMPLO DE DIAGRAMA DE ATIVIDADES ................................................................ 62

FIGURA 27 - TIPOS DE MULTIPLICIDADE ......................................................................................... 65

FIGURA 28 - TIPOS DE ASSOCIAÇÕES: (a) SIMPLES; (b) POR COMPOSIÇÃO ........................... 66

FIGURA 29 - EXEMPLO DE GENERALIZAÇÃO ................................................................................. 66

FIGURA 30 - EXEMPLOS DE DEFINIÇÕES DE LISTAS .................................................................... 68

FIGURA 31 - EXEMPLO DE UTILIZAÇÃO DE MÉTODOS GRÁFICOS DA BIBLIOTECA AWT ........ 69

FIGURA 32 - EXEMPLO DE PARTE DE ARQUIVO DE DADOS DE REDE DE DRENAGEM ........... 73

FIGURA 33 - LOCALIZAÇÃO (a) E BACIA HIDROGRÁFICA (b) DA REDE DE DRENAGEM Nº 1 ... 74

FIGURA 34 - LOCALIZAÇÃO (a) E BACIA HIDROGRÁFICA (b) DA REDE DE DRENAGEM Nº 2 ... 75

FIGURA 35 - LOCALIZAÇÃO (a) E BACIA HIDROGRÁFICA (b) DA REDE DE DRENAGEM Nº 3 ... 75

FIGURA 36 - DIAGRAMA DE ATIVIDADES DO TRABALHO REALIZADO ........................................ 78

FIGURA 37 - DIAGRAMA DE CASO DE USO GERAL “REDE DE DRENAGEM” .............................. 79

FIGURA 38 - ERROS COMUNS ENCONTRADOS EM POLILINHAS DIGITALIZADAS ..................... 81

FIGURA 39 - MODELO DE CLASSES DE OBJETOS PROPOSTO .................................................... 90

FIGURA 40 - CLASSE Recobrimento ................................................................................................... 93

FIGURA 41 - CLASSE AreaLevantamento ........................................................................................... 93

FIGURA 42 - CLASSE FenomenoTerrestre ......................................................................................... 94

FIGURA 43 - CLASSE RedeDeDrenagem ........................................................................................... 94

FIGURA 44 - CLASSE TrechoDeCanal ................................................................................................ 95

FIGURA 45 - CLASSE Canal ................................................................................................................ 95

FIGURA 46 - PACOTES (Packages) DAS CLASSES DO PROTÓTIPO ............................................. 98

FIGURA 47 - JANELA PRINCIPAL E JANELA DA REDE DE DRENAGEM DO PROTÓTIPO ........... 99

FIGURA 48 - DIÁLOGO DE PROCURA DO ARQUIVO DE DADOS DE ENTRADA ........................... 99

FIGURA 49 - RETÂNGULOS ENVOLVENTES MÍNIMOS DOS TRECHOS DE CANAIS ................. 100

FIGURA 50 - VISUALIZAÇÃO DA REDE E CURVAS DE NÍVEIS ..................................................... 101

FIGURA 51 - EXPLORADOR DOS MÉTODOS DOS OBJETOS DA REDE...................................... 102

FIGURA 52 - ROLAGEM DA TELA DA FIGURA ANTERIOR ............................................................ 102

FIGURA 53 - REDE Nº 1 E SEUS ELEMENTOS VISUALIZADOS NO PROTÓTIPO ....................... 105

FIGURA 54 - REDE Nº 2 E SEUS ELEMENTOS VISUALIZADOS NO PROTÓTIPO ....................... 108

FIGURA 55 - REDE Nº 3 E SEUS ELEMENTOS VISUALIZADOS NO PROTÓTIPO ....................... 111

FIGURA 56 - ORDENAMENTO DE STRAHLER PARA A REDE Nº 1 .............................................. 117

FIGURA 57 - ORDENAMENTO DE STRAHLER PARA A REDE Nº 2 .............................................. 117

FIGURA 58 - ORDENAMENTO DE STRAHLER PARA A REDE Nº 3 .............................................. 118

FIGURA 59 - SÉRIE TEMPORAL DE LEVANTAMENTOS PARA UMA MESMA REGIÃO ............... 119

FIGURA 60 - REDE Nº 1 VISUALIZADA NO GOOGLE EARTH

(TOPO) ........................................ 120

FIGURA 61 - REDE Nº 1 VISUALIZADA NO GOOGLE EARTH

(PERSPECTIVA) ......................... 120

FIGURA 62 - REDE Nº 2 VISUALIZADA NO GOOGLE EARTH© (TOPO) ....................................... 121

FIGURA 63 - REDE Nº 2 VISUALIZADA NO GOOGLE EARTH© (PERSPECTIVA) ........................ 121

FIGURA 64 - REDE Nº 3 VISUALIZADA NO GOOGLE EARTH© (TOPO) ....................................... 122

FIGURA 65 - REDE Nº 3 VISUALIZADA NO GOOGLE EARTH© (PERSPECTIVA) ........................ 122

FIGURA 66 - CAIXA DE SELEÇÃO DE EXTENSÕES DO ArcGIS

.................................................. 140

FIGURA 67 - MENU ARCTOOLBOX DO ArcMAP

........................................................................... 141

FIGURA 68 - LAYER DA GRADE DE PONTOS PARA O PROCESSO ............................................ 142

FIGURA 69 - TABELA DE ATRIBUTOS DOS PONTOS DO MODELO ............................................. 143

FIGURA 70 - MENU DE INVOCAÇÃO DE FUNÇÕES GERAIS SOBRE DADOS ............................ 143

FIGURA 71 - JANELA DOS RESULTADOS ESTATÍSTICOS DOS DADOS ..................................... 144

FIGURA 72 - VISUALIZAÇÃO DE PARTE DAS PROPRIEDADES DA LAYER DE PONTOS .......... 145

FIGURA 73 - CRIAÇÃO DA TIN INICIAL VAZIA ................................................................................ 146

FIGURA 74 - PROPRIEDADE DA REFERÊNCIA ESPACIAL ........................................................... 147

FIGURA 75 - PESQUISA PELO SISTEMA DE COORDENADAS ..................................................... 147

FIGURA 76 - SISTEMAS DE COORDENADAS ................................................................................. 148

FIGURA 77 - SELEÇÃO DO MERIDIANO .......................................................................................... 148

FIGURA 78 - APRESENTAÇÃO DO SISTEMA SELECIONADO ...................................................... 149

FIGURA 79 - RETORNO A CAIXA DE DIÁLOGO INICIAL ................................................................ 149

FIGURA 80 - PARÂMETROS PARA A EDIÇÃO DA TIN ................................................................... 150

FIGURA 81 - VISUALIZAÇÃO DA TIN PRODUZIDA ......................................................................... 151

FIGURA 82 - RAMPA DE CORES PARA OS VALORES DE ALTITUDES ........................................ 151

FIGURA 83 - LAYER APÓS APLICAÇÃO DA CLASSE DE CORES ................................................. 152

FIGURA 84 - AJUSTE DE DEPRESSÕES POR CORTES (SUPRESSÕES) ADJACENTES ........... 153

FIGURA 85 - AJUSTE DE DEPRESSÕES POR PREENCHIMENTOS ADJACENTES .................... 153

FIGURA 86 - JANELA DE DIÁLOGO PARA A GERAÇÃO DA IMAGEM RASTER ........................... 153

FIGURA 87 - IMAGEM RASTER CRIADA A PARTIR DA TIN ........................................................... 154

FIGURA 88 - DIÁLOGO PARA PREENCHIMENTO DAS DEPRESSÕES ........................................ 154

FIGURA 89 - VALORES DOS SENTIDOS EM RELAÇÃO A CÉLULA CENTRAL ............................ 155

FIGURA 90 - VALOR AFIXADO APÓS ANÁLISE .............................................................................. 155

FIGURA 91 - JANELA DE DIÁLOGO "FLOW DIRECTION" ............................................................... 156

FIGURA 92 - LAYER DOS SENTIDOS DE FLUXO DETERMINADOS ............................................. 156

FIGURA 93 - JANELA DE DIÁLOGO DO "FLOW ACCUMULATION ................................................ 157

FIGURA 94 - LAYER REPRESENTANDO A CONTRIBUIÇÃO OBTIDA........................................... 158

FIGURA 95 - LAYER MODIFICADA REPRESENTANDO A CONTRIBUIÇÃO OBTIDA ................... 158

FIGURA 96 - SOBREPOSIÇÃO DE LAYERS .................................................................................... 159

FIGURA 97 - DIÁLOGO PARA DELIMITAÇÃO E PRODUÇÃO DO ARQUIVO "STREAM" .............. 160

FIGURA 98 - IMAGEM OBTIDA DO ARQUIVO "STREAM" GERADO NO ARCGIS

....................... 160

FIGURA 99 - DIÁLOGO DE PASSAGEM PARA ARQUIVO "FEATURE" .......................................... 161

FIGURA 100 - IMAGEM OBTIDA VETORIZADA ............................................................................... 161

FIGURA 101 - RESULTADO DA VETORIZAÇÃO COM POLILINHA SELECIONADA ..................... 162

FIGURA 102 - VALORES DOS NÓS DA POLILINHA SELECIONADA ............................................. 162

FIGURA 103 - MENU DO ARCTOOLBOX PARA EXPORTAÇÃO EM ARQUIVOS DE TEXTOS .... 163

FIGURA 104 - EXEMPLO DE ARQUIVO DE DADOS EXPORTADO ................................................ 163

LISTA DE TABELAS

TABELA 1 - COMPARAÇÃO ENTRE OS MODELOS ESPAÇO-TEMPORAIS PARA SIG ................. 23

TABELA 2 - INTERVALOS DE DECLIVIDADE DO TERRENO ........................................................... 46

TABELA 3 - COMPONENTES PRINCIPAIS DA BIBLIOTECA SWING ............................................... 70

TABELA 4 - RESUMO DOS RESULTADOS DOS EXPERIMENTOS ................................................ 104

TABELA 5 - LEITURAS OBTIDAS PARA A REDE DE DRENAGEM Nº 1 ......................................... 114

TABELA 6 - LEITURAS OBTIDAS PARA A REDE DE DRENAGEM Nº 2 ......................................... 115

TABELA 7 - LEITURAS OBTIDAS PARA A REDE DE DRENAGEM Nº 3 ......................................... 115

LISTA DE SIGLAS

ANA - Agência Nacional de Águas

ASCII - American Standard Code for Information Interchange

AWT - Abstract Windowing Toolkit

CAD - Computer Aided Design

CASE - Computer-Aided Software Engineering

DDL - Data Description Language

DML - Data Manipulation Language

DXF - Drawing Exchange Format

EMBRAPA - Empresa Brasileira de Pesquisa Agropecuária

IDE - Integrated Development Environment

JDBC - Java Data Base Connectivity

JSE - Java Standard Edition

MDT - Modelo Digital de Terreno

OMG - Object Management Group

PNRH - Plano Nacional de Recursos Hídricos

REM - Retângulo Envolvente Mínimo

SGBD - Sistema Gerenciador de Banco de Dados

SIG - Sistema de Informação Geográfica

SINGREH - Sistema Nacional de Gerenciamento de Recursos Hídricos

SQL - Structured Query Language

TIN - Triangulated Irregular Network

UFPR - Universidade Federal do Paraná

UML - Unified Modeling Language

SUMÁRIO

INTRODUÇÃO ...................................................................................................... 12

1.1

JUSTIFICATIVA .............................................................................................. 14

1.2

OBJETIVO GERAL ......................................................................................... 16

1.3

OBJETIVOS ESPECÍFICOS ........................................................................... 16

1.4

PREMISSAS E RESTRIÇÕES ........................................................................ 17

1.5

ORGANIZAÇÃO DO TRABALHO .................................................................. 18

REVISÃO DE LITERATURA ................................................................................ 19

2.1

FENÔMENOS TERRESTRES E SUAS PROPRIEDADES............................. 19

2.2

ORGANIZAÇÃO E REPRESENTAÇÃO DE DADOS ESPACIAIS ................. 25

2.2.1

Conceituação de grafo ................................................................................. 25

2.2.2

Grafos e suas propriedades ......................................................................... 26

2.2.3

Topologia ..................................................................................................... 27

2.2.4

Representação da estrutura topológica ........................................................ 28

2.2.5

Polilinhas ...................................................................................................... 29

2.2.6

Polilinhas e interseção de retângulos ........................................................... 31

2.2.7

Interseção de dois segmentos de reta ......................................................... 33

2.3

ORGANIZAÇÃO E REPRESENTAÇÃO DE DADOS TEMPORAIS ............... 34

2.3.1

Estrutura temporal ........................................................................................ 35

2.3.2

Modelo de “retratos sequenciais” ou snapshots ........................................... 36

2.4

O MODELO DE FENÔMENOS TERRESTRES .............................................. 36

2.5

ELEMENTOS E CARACTERÍSTICAS DE REDES DE DRENAGEM ............. 40

2.5.1

Elementos de redes de drenagem ............................................................... 41

2.5.2

Características físicas de redes de drenagem ............................................. 42

2.5.3

Hierarquização da rede de drenagem e métodos de ordenamento ............. 47

2.5.4

Extração de redes de drenagem .................................................................. 49

2.5.5

Aplicações que empregam redes de drenagem ........................................... 49

2.6

CARACTERÍSTICAS DA MODELAGEM ORIENTADA A OBJETOS ............ 51

2.6.1

Modelos de dados ........................................................................................ 52

2.6.2

Orientação a objetos .................................................................................... 53

2.6.3

A linguagem de modelagem unificada (UML) .............................................. 54

2.6.4

Diagramas da UML ...................................................................................... 55

2.6.5

Vantagens no emprego da UML para a construção de modelos ................. 56

2.6.6

Diagramas de casos de uso ......................................................................... 57

2.6.7

Diagramas de classes .................................................................................. 58

2.6.8

Diagramas de atividades .............................................................................. 61

2.6.9

Modelo de classes do domínio ..................................................................... 63

2.6.10

Visibilidade e acessibilidade ......................................................................... 64

2.6.11

Relacionamentos, navegabilidade e multiplicidade ...................................... 64

2.6.12

Associação, agregação e composição ......................................................... 65

2.6.13

Heranças, subclasses e superclasse ........................................................... 66

2.7

CARACTERÍSTICAS DA LINGUAGEM DE PROGRAMAÇÃO JAVA ........... 67

MATERIAL E MÉTODOS ..................................................................................... 71

3.1

MATERIAL UTILIZADO .................................................................................. 71

3.1.1

Arquivos de dados........................................................................................ 72

3.1.2

Redes de drenagem ..................................................................................... 74

3.1.3

Ambientes de software ................................................................................. 76

3.2

METODOLOGIA ............................................................................................. 77

3.2.1

Adaptação da terminologia ........................................................................... 77

3.2.2

Fluxo geral do trabalho ................................................................................. 78

3.2.3

Determinação do escopo do modelo ............................................................ 79

3.2.4

Estudo e preparação dos dados .................................................................. 80

3.2.5

Construção do modelo de classes de objetos .............................................. 82

3.2.6

Desenvolvimento do protótipo de software .................................................. 85

RESULTADOS E DISCUSSÕES .......................................................................... 89

4.1

DIAGRAMA DE CLASSES DE OBJETOS DE REDE DE DRENAGEM ........ 89

4.2

O PROTÓTIPO DE SOFTWARE DESENVOLVIDO ....................................... 96

4.3

EXPERIMENTOS E RESULTADOS ............................................................. 103

4.4

DISCUSSÃO DO MODELO PROPOSTO ..................................................... 123

CONCLUSÕES ................................................................................................... 124

REFERÊNCIAS ....................................................................................................... 128

APÊNDICES ........................................................................................................... 134

1 INTRODUÇÃO

Keates (1973, p. 20) divide o conjunto total de fenômenos visíveis possíveis

de representação na cartografia topográfica em dois grandes grupos: meio físico e

meio humano. Segundo o autor, o meio físico é “composto dos elementos naturais

ou dependentes destes, mesmo quando modificados ou influenciados pelo homem”;

meio humano é “composto de todas as feições construídas pelo homem”.

Fenômenos identificáveis da superfície terrestre, contendo uma posição

específica sobre esta superfície, podem ser agrupados quanto à natureza, quanto à

forma de ocorrência, distribuição ou comportamento e quanto à estrutura de

atributos que capturam características associadas com cada semântica,

estabelecendo-se classes de fenômenos terrestres. Entre os diversos fenômenos do

meio físico, encontram-se os corpos hídricos. Exemplos destes corpos são oceanos,

lagos e rios. Segundo Pinto et al. (1976, p. 36), estes corpos são formados pelo

escoamento superficial das águas que têm origem fundamentalmente nas

precipitações. Este escoamento de águas é visto como o segmento do ciclo

hidrológico que estuda o deslocamento das águas na superfície da Terra. À medida

que as águas vão atingindo os pontos mais baixos do terreno, passam a escoar em

canalículos que formam a microrrede de drenagem. A dimensão destes pequenos

canais vai aumentando com a ação da erosão e o escoamento se processa, cada

vez mais, por caminhos preferenciais. “Chama-se rede de drenagem ao conjunto

dos cursos de água desde os pequenos córregos formadores até o rio principal”

(PINTO et al., 1976, p. 37). A figura 1 ilustra uma típica rede de drenagem.

FIGURA 1 - EXEMPLO DE REDE DE DRENAGEM

FONTE: O autor (2008)

Segundo Ichoku et al. (1996, p. 4), redes de drenagem são basicamente

fenômenos associados a morfologia terrestre e têm sido indispensáveis em ciências

cartográficas, geológicas, entre outras. Elas normalmente formam a base na qual a

morfologia e as paisagens são caracterizadas e muitas conclusões geológicas são

fundamentadas em inferências derivadas delas, segundo os autores. Quase todos

os mapas representam-nas como um fenômeno terrestre de referência.

Se em épocas distintas, dois ou mais levantamentos topográficos

apresentarem um recobrimento para uma determinada região, é possível se obter

“versões temporais” da rede de drenagem. Como estes levantamentos sobre uma

região acontecem normalmente em tempos distintos e em intervalos de tempos

variáveis, toda a geometria da rede fica indexada àquela base de tempo do

levantamento, caracterizando-se como uma série temporal discreta e não-uniforme.

A representação espaço-temporal de redes de drenagem num modelo

formal pode ter especial utilidade em certas aplicações de SIG que necessitem

associar e extrair informações de cada trecho de canal. Esta representação pode ter

utilidade em diversas atividades, tais como: estudo de relevo, determinação de áreas

com risco de erosão do solo, transporte de poluentes, delimitação de áreas

inundadas e estudo de bacias hidrográficas (ROSIM; PELLEGRINO, 1999, p. 1),

gestão de recursos hídricos (TEIXEIRA et al., 2007), em outorgas de bacias

hidrográficas (ZEILHOFER et al., 2007) e em estudos da determinação e distribuição

espacial de doenças (ROCHA et al., 2007). Aplicações destas naturezas podem ser

beneficiadas se um modelo de dados puder ser utilizado para expressar

computacionalmente estes fenômenos.

O poder e a capacidade dos sistemas de informação dependem largamente

de cuidadoso projeto de seu modelo de dados, esse visto como núcleo conceitual do

sistema (YUAN et al., 2004). Um modelo de classes de objetos procura estender

este modelo de dados, aumentando o poder de abstração e conferindo maior

aproximação semântica com o fenômeno investigado, pois além de capturar

atributos do fenômeno, possibilita definir operadores que modelam comportamento.

O modelo de classes de objetos também pode ser estendido para expressar novos

fenômenos especializados ou advindos de uma combinação entre eles.

Vieira (2004) define as bases de um arcabouço de classes gerais de objetos

para modelar fenômenos terrestres. Esta estrutura de classes foi modelada com o

auxílio da UML (Unified Modeling Language) e aponta algumas perspectivas para se

realizar extensões futuras ao seu modelo. Entre as principais classes, o autor define

as classes AreaLevantamento, Recobrimento e FenomenoTerrestre e classes

especializadas desta última, como por exemplo, CorpoHidrico, AfloramentoRochoso,

CoberturaVegetal, entre outras, recomendando novos estudos para estas

especializações.

A falta de um modelo próprio de classes de objetos que definisse

conceitualmente no espaço e no tempo redes de drenagem motivou a realização

deste trabalho. Partindo-se de algumas premissas e restrições adiante enumeradas,

este trabalho procura estender por meio da UML aquele modelo a partir das classes

citadas, para definir um modelo de classes de objetos para redes de drenagem. Para

o escopo desta pesquisa, o estudo se concentrou nos requisitos espaciais

(geométricos e topológicos) e temporais de redes de drenagem encontradas

naturalmente sobre a superfície terrestre.

1.1 JUSTIFICATIVA

A Lei Federal Nº 9.433/07 instituiu a Política Nacional de Recursos Hídricos

(PNRH) e criou o Sistema Nacional de Gerenciamento de Recursos Hídricos

(SINGREH), além de tratar de outras regulamentações (BRASIL, 2007). Entre os

objetivos deste sistema está a formação de um banco de dados geoespacial

nacional de redes hidrográficas. Este evento certamente trouxe desafios adicionais

para instituições como a ANA - Agência Nacional de Águas e pesquisadores, como

na formulação da estratégia de desenvolvimento do SINGREH (fig. 2) e na formação

do mencionado banco, especificamente no trabalho referente à modelagem e ao

tratamento dos dados geoespaciais da hidrografia. Neste sentido, Holtz (2005)

enfatiza a necessidade de planejamento integrado de recursos hídricos, capacitado

com “instrumentos adequados, inclusive modelagem sofisticada e que permita

interação entre os vários atores das bacias hidrográficas”.

FIGURA 2 - VISÃO GERAL SOBRE ESTRATÉGIA DE DESENVOLVIMENTO DO SNIRH

FONTE: AGÊNCIA NACIONAL DE ÁGUAS (2007)

Esta pesquisa procura atender parcialmente esta demanda, trazendo os

seguintes benefícios:

a) definição do processo de composição da geometria da rede de

drenagem a partir de elementos geométricos como pontos e linhas;

b) definição do modelo de classes de objetos de redes de drenagem

associando estas classes com os seus elementos;

c) definição dos principais atributos e operadores das classes de objetos

sob o ponto de vista geométrico e temporal;

d) desenvolvimento de software, na forma de um protótipo, que utilize este

modelo de classes de objetos, a partir da leitura de um arquivo de dados

de redes de drenagem.

Como principais beneficiários deste trabalho, pode-se elencar:

a) usuários de SIG;

b) usuários e gestores de recursos hídricos;

c) desenvolvedores de software e de extensões para ambientes de SIG;

d) pesquisadores, professores e estudantes.

1.2 OBJETIVO GERAL

Definir um modelo espaço-temporal para representar redes de drenagem

sob o ponto de vista geométrico e topológico, tendo por base o modelo

FenomenoTerrestre proposto por Vieira (2004). Para esta definição, necessita-se

entender o conceito de rede de drenagem e como expressá-la por meio de classes

de objetos modeladas em UML.

1.3 OBJETIVOS ESPECÍFICOS

Para atingir o objetivo geral proposto, os seguintes objetivos específicos

foram arrolados:

a) pesquisar informações essenciais inerentes à estrutura de redes de

drenagem como: nomenclatura, termos, expressões, padrões de

distribuição espacial, principais características físicas, ordenamento de

elementos, entre outras informações. Este objetivo possibilitará ganhar

conhecimento do fenômeno investigado;

b) analisar o modelo de fenômenos terrestres existente e a possibilidade de

integrar o modelo proposto com o modelo de fenômenos terrestres. Este

objetivo deverá indicar em quais aspectos e em que grau os modelos se

integrarão;

c) estudar os dados inerentes às redes de drenagem. Este objetivo

permitirá descobrir como os dados se relacionam aos elementos de

redes de drenagem;

d) desenvolver um protótipo de software utilizando uma linguagem

orientada a objetos no qual será implementado o modelo espaço-

temporal de redes de drenagem. Este objetivo permitirá aplicar o modelo

de redes de drenagem numa aplicação de software, possiblitando

visualização gráfica da rede e produção de resultados;

e) verificar se o modelo proposto permite representar, espacialmente e

temporalmente, redes de drenagem e seus elementos. Este objetivo

permitirá concluir se o modelo é capaz de responder satisfatoriamente

questões sobre métricas e de topologia de redes de drenagem, ao longo

de séries históricas.

1.4 PREMISSAS E RESTRIÇÕES

Para viabilizar esta pesquisa no tempo determinado, e melhor definir o

escopo dos trabalhos, as seguintes premissas e restrições foram definidas:

a) a ênfase do modelo de rede de drenagem está em aspectos

geométricos e topológicos, não se considerando a influência do ciclo

hidrológico e fatores como cobertura vegetal, entre outros. A geometria

considerada emprega pontos e retas. Trechos da rede de drenagem

são considerados unicamente ao longo da superfície terrestre sem

considerar o desaparecimento e ressurgências deles;

b) os dados serão homogêneos em termos de escala e em relação a

origem deles. Isto significa que os dados de uma série histórica, para

uma mesma rede de drenagem, serão considerados sem variação de

escala ou de sistema referencial de coordenadas;

c) a ordem dos dados espaciais de redes de drenagem produzidos pelos

processos de aquisição segue o sentido de montante a jusante da rede.

Isto permite que arquivos de dados de redes de drenagem possam ser

utilizados, mesmo que os dados de altitude dos pontos não existam ou

estejam incompletos;

d) a temporalidade é discreta, não uniforme, associada à rede de

drenagem completa e indexada por diferentes levantamentos;

e) as razões das variações espaciais dos elementos de uma dada rede de

drenagem, ao longo da série temporal, são irrelevantes neste trabalho.

1.5 ORGANIZAÇÃO DO TRABALHO

O capítulo 2 apresenta uma revisão de literatura e está organizado em seis

partes: (i) propriedades de fenômenos terrestres; (ii) organização e representação de

dados espaciais; (iii) organização e representação de dados temporais; (iv) o modelo

de fenômenos terrestres; (v) elementos e principais características de redes de

drenagem; (vi) características da modelagem orientada a objetos.

O capítulo 3 descreve os recursos e arquivos de dados utilizados.

Apresenta a metodologia empregada, explicando os passos realizados para a

construção do modelo de rede de drenagem. Descreve também algumas

particularidades do protótipo de software.

O capítulo 4 apresenta os resultados alcançados e discussões, explicando

em detalhes o diagrama de classes de objetos de redes de drenagem. Na sequência

são apresentados os resultados da execução do protótipo desenvolvido, para alguns

exemplos de redes de drenagem.

O capítulo 5 relata as conclusões obtidas e sugere uma lista de

recomendações e melhoramentos que podem ser estendidos ao modelo de classes

de objetos proposto e ao protótipo desenvolvido.

Os apêndices apresentam alguns trechos de programação desenvolvidos

para o protótipo, uma revisão do processo de extração de rede de drenagem, a partir

de um conjunto de pontos topográficos, e um resumo de utilização de um conversor

bidirecional entre arquivos shapefiles e arquivos em formato de textos (ASCII).

2 REVISÃO DE LITERATURA

Para auxiliar na busca pelo cumprimento dos objetivos propostos, o estudo

de revisão foi organizado nos seguintes tópicos: fenômenos terrestres e suas

propriedades, organização e representação de dados espaciais, organização e

representação de dados temporais, o modelo de fenômenos terrestres, elementos e

características de redes de drenagem, características da modelagem orientada a

objetos e características da linguagem de programação Java.

2.1 FENÔMENOS TERRESTRES E SUAS PROPRIEDADES

O entendimento que um observador tem sobre um fato pode ser capturado

num modelo semântico que simplifica e sistematiza o fato idealizando-o num ato de

abstração da realidade. Esta abstração, realizada por meio da seleção de alguns

aspectos do fenômeno e de interesse do observador, pode ser representada para

estudos e resolução de problemas associados ao fato. Corretamente construído, o

observador pode realizar análises que conduzirão a resultados. A interpretação

destes resultados, quando o modelo e o fenômeno forem apropriados possibilitarão

fazer inferência sobre o fato (VIEIRA, CARVALHO e SLUTER, 2002). Este processo

de estudo de um fato é ilustrado pela figura 3.

FIGURA 3 - DIAGRAMA DE ETAPAS DO PROCESSO DE ESTUDO DE UM FATO

FONTE: VIEIRA (2004)

Fenômeno terrestre pode ser definido como sendo um fato observado sobre

uma superfície terrestre. Citam-se como exemplos: vegetação, afloramento rochoso,

edificação, estrada, rio, lago, entre outros. Define-se feição como o fenômeno

terrestre representado em mapas ou como sendo o elemento de um conjunto de

fenômenos com atributos comuns de função e de posição (ROBINSON et al., 1995,

p. 178). “Feições são a soma de nossas interpretações de fenômenos geográficos”

(ROBINSON et al., 1995, p. 169).

Dados de fenômenos terrestres em aplicações espaço-temporais de SIG

podem ser classificados em cinco tipos diferentes, segundo Price et al.

(1999, apud

Souza, 2004):

• dados espaciais: são dados que possuem somente um domínio espacial,

por exemplo, limites de uma propriedade;

• dados temporais: são dados que possuem somente um domínio

temporal, por exemplo, hora do vôo;

• dados espaço-temporais: são dados espaciais cuja geometria se altera

com o tempo (forma, tamanho, posição ou orientação);

• variação espacial, temporal ou espaço-temporal dos dados

alfanuméricos: são dados que têm somente um domínio semântico, ou

seja, não são nem espaciais e nem temporais (acidez do solo, por

exemplo), e cujos valores se alteram com o tempo e/ou no espaço;

• dados compostos espaciais, temporais ou espaço-temporais: são dados

cujos componentes que os formam mudam temporal ou espacialmente.

Nos três últimos casos, os atributos se alteram com o passar do tempo e/ou

espacialmente, e portanto é necessário armazenar tanto o valor inicial quanto as

variações que ocorrem.

No estudo de fenômenos terrestres, algumas características devem ser

investigadas, tendo em vista a necessidade de se definir um modelo destes

fenômenos que formalize a dimensionalidade espacial e a dimensionalidade

PRICE, R.; SRINIVASAN, B.; RAMAMOHANARAO, K. Extending the Unified Modeling

Language to Support Spatiotemporal Applications. Asia Technology of object Oriented

Languages and Systems. 1999. p. 163-174.

temporal. Laurini e Thompson (1998, p. 38-49) exemplificam algumas propriedades

espaciais em função do fenômeno, de forma individual ou coletiva. De forma

individual, pode-se citar:

a) comprimento, como por exemplo, de um canal de drenagem ou o

comprimento do trecho ou parte de um canal;

b) área da superfície, como de um lago, de uma ilha ou de um lote;

c) volume, como em cortes e aterros;

d) forma, regular ou não, como por exemplo, um polígono definindo um

município;

e) orientação;

f) linha central imaginária ou de possível simetria de um polígono;

g) declividade, como no caso de uma encosta ou de um canal.

Quando os fenômenos são agrupados entre si, outras propriedades

espaciais podem ser evidenciadas. São exemplos:

a) padrão de distribuição (concentrado ou disperso);

b) disposição (layout) de regiões (compacta ou fragmentada);

c) distanciamento relativo (de um ponto para outro) ou acumulado;

d) número de países vizinhos de um país;

e) densidade de drenagem numa bacia hidrográfica;

f) fluxo predominante de emigrantes num continente;

g) sequenciamento de fenômenos.

É importante diferenciar entre as propriedades que requerem medidas por

meio da utilização de coordenadas, ou seja, com informação métrica, das

propriedades fundamentadas na informação não-métrica, que definem qualidade do

espaço ou do relacionamento espacial, como conexões entre locais. Estas

propriedades, ditas topológicas, são:

a) conectividade;

b) orientação (de, para);

c) adjacência ou vizinhança;

d) continência

Observa-se que alguns conceitos espaciais podem ser medidos tanto no

domínio geométrico como no topológico. Por exemplo, a distância entre o início e

término de uma cadeia de segmentos de retas interconectados pode ser medida

pela soma das distâncias de cada segmento consecutivo, ou simplesmente pelo

número de segmentos da cadeia total. Além disso, a identificação ou medida das

propriedades dos relacionamentos espaciais, como distância ou conectividade,

requer o uso de uma classe de entidade especial formada por um par de objetos ou

díade. Por exemplo, um trecho de canal de drenagem referido como um arco, requer

um nó inicial e um nó final. Propriedades espaciais adicionais também podem ser

encontradas quando diferentes fenômenos são estendidos, tendo ocorrências

espaciais similares, favorecendo comparações entre distribuições e dando

surgimento a conceitos como sobreposição e interseção.

É possível afirmar que o fenômeno terrestre é percebido pelo observador

por meio de uma “superfície”. No contexto de uma aplicação, a dimensionalidade

está associada à idealização desta “superfície” do fenômeno. Assim, é possível que

fenômenos possam ser representados numa dimensionalidade menor: 2D

(superfície como uma poligonal plana), 1D (superfície degenerada como uma

sequência de pontos) ou 0D (reduzida a um único ponto). Tomando-se como

exemplo uma rede de drenagem, para uma aplicação específica, a dimensionalidade

1D poderia ser adequada, representando-se as conexões e caminhos pela rede. Já

em outra aplicação, além das conexões e caminhos, as margens da rede e suas

declividades poderiam ser necessárias elevando-se a dimensionalidade para 3D

(VIEIRA, 2004, p. 44-45).

Fenômenos terrestres podem ser percebidos como mutáveis ao longo de

um determinado período de tempo. Embora desconsiderada em muitos estudos de

Esta propriedade também pode ser encontrada na literatura com as denominações: pertinência,

circunscrividade ou contenção.

SIG, Hadzilacos e Tryfona

(1996, apud Lisboa Filho e Iochpe, 1999) consideram

que a temporalidade no estudo de fenômenos terrestres é necessária no sentido que

o tempo torna-se uma propriedade obrigatória para se armazenar séries históricas

de dados para efeitos de estudos de evolução dos fenômenos, e não tanto pela

frequência de atualização dos dados. Yuan (1996, p. 7) reconhece que o

acompanhamento das identidades dos fenômenos terrestres, propriedades

geométricas e seus relacionamentos topológicos ao longo do tempo, é de alta

complexidade, fato este que vem merecendo a atenção de diversos pesquisadores.

Souza (2004, p. 31-32) apresenta um resumo (tab. 1) comparando as características

dos diversos métodos temporais estudados ao longo das últimas décadas.

TABELA 1 - COMPARAÇÃO ENTRE OS MODELOS ESPAÇO-TEMPORAIS PARA SIG

FONTE: SOUZA (2004)

HADZILACOS, T.; TRYFONA, N. Logical data modelling for geographical applications. International

Journal of Geographical Information Sciences, 10(2): 179-203, 1996.

De acordo com Yuan (1996, p. 8), as mudanças podem ocorrer nos

atributos do fenômeno terrestre, nas características do ambiente, nos

comportamentos de um evento ou nos mecanismos dos processos. Segundo o

autor, existem seis tipos principais de mudanças na informação geográfica:

I. para um dado local geográfico onde ocorrências e a duração de eventos

ou atributos podem variar de tempos em tempos, a análise é feita fixando

o local, controlando o atributo e medindo o tempo;

II. para um dado ponto no tempo onde um certo fenômeno pode variar suas

características de um local para outro, a análise é feita fixando-se o

tempo, controlando o atributo e medindo o local;

III. para um dado período de tempo onde os atributos podem variar de um

local para outro através do tempo, a análise é feita fixando-se o tempo,

controlando os locais e medindo-se os atributos;

IV. para um dado evento onde suas características ou processos podem

variar em locais através do tempo, a análise é feita fixando-se os

atributos, controlando os locais e medindo-se o tempo;

V. para uma dada área onde atributos podem variar de local para local, a

análise é feita fixando-se o local, controlando o tempo e medindo-se os

atributos;

VI. para um dado evento onde seu local pode variar de tempos em tempos,

a análise é feita fixando-se os atributos, controlando-se o tempo e

medindo-se os locais.

Segundo Yuan (1995), mudanças do tipo I envolvem variações nos atributos

ao longo do tempo e não há variação das propriedades espaciais e a modelagem e

análise pode ser realizada totalmente no domínio semântico como transações

históricas num sistema de gerenciamento de banco de dados. Mudanças do tipo II

descrevem distribuições espaciais estáticas de um fenômeno, como por exemplo o

relevo e técnicas de construção de curvas de nível ou de mapas coropléticos podem

ser empregadas para apresentar tais informações. Mudanças do tipo III ao tipo VI

alteram a geometria e a topologia de propriedades espaciais e temporiais.

2.2 ORGANIZAÇÃO E REPRESENTAÇÃO DE DADOS ESPACIAIS

McAllister (1999, p.14-15) considera que grafos planares e orientados são

representações convenientes para redes de drenagem e lembra que algumas

análises tratam-nas como estruturas em “árvore”, com o ponto mais a jusante da

rede sendo a sua “raiz”. Estas considerações trazem importante contribuição no

modo de como representar e dar ordenamento aos elementos de redes de

drenagem.

2.2.1 Conceituação de grafo

Grafo pode ser entendido como um conjunto de pontos e linhas, estas

linhas unindo certos pares de pontos deste conjunto. McAllister (1999, p. 6) define

informalmente grafo como sendo uma relação entre dois ou mais objetos ou

conceitos. Os objetos são os vértices ou nós, e a presença de uma relação entre

dois objetos aparece como uma aresta entre os dois vértices para os objetos. Grafos

podem ser representados por meio de um diagrama, de forma que o interesse do

observador possa estar em quais pontos estão conectados ou não. A forma na qual

eles são conectados é irrelevante (BONDY; MURTY, 1982, p. 1). Um grafo G é uma

tripla ordenada (V(G), E(G), ψ

), onde V(G) é um conjunto não-vazio de vértices em

G, E(G) é um conjunto de arestas (edges) disjunto em V(G) e ψ

uma função

incidência que associa cada aresta de G a um par não-ordenado de vértices (não

necessariamente distintos) de G. Se e é uma aresta e u e v são vértices tais que

(e) = uv, então e é dito que conecta u e v; os vértices u e v são extremos de e.

Por meio de um exemplo (figura 4) pode-se expressar:

G = (V(G), E(G), ψ

)

V(G) = { v

, v

}

E(G) = { e

, e

}

e ψ

definido por:

) = v

, ψ

) = v

, ψ

) = v

, ψ

) = v

, ψ

) = v

, ψ

) = v

, ψ

) = v

FIGURA 4 - EXEMPLO DE DIAGRAMA DE GRAFO

FONTE: BONDY e MURTY (1982)

2.2.2 Grafos e suas propriedades

Observa-se que não existe uma única maneira de se desenhar um grafo e a

posição relativa dos pontos e linhas não tem significância. É possível que duas

arestas se interceptem num ponto, como no exemplo da figura 3 (e

e e

), mas este

ponto não é necessariamente um vértice. Grafos são planares quando todas as

arestas se interceptam somente em suas extremidades, caso contrário, quando se

interceptam em pontos que não são vértices, os grafos são ditos não-planares. Se

as arestas possuírem uma orientação (de-para) são ditos grafos orientados. Na

figura 5, a ilustração (a) é um grafo planar, pois o arranjo dos vértices pode conduzir

a não-interceptação das arestas e (b) é não-planar, pois não apresenta distribuição

possível para as arestas se interceptarem somente nos vértices.

FIGURA 5 - GRAFO PLANAR E NÃO-PLANAR

FONTE: BONDY e MURTY (1982)

Dois grafos são ditos isomórficos se há uma correspondência um-para-um

entre os vértices e suas arestas (DIESTEL, 2005, p. 3, 83). Em outras palavras, as

condições de conectividade e adjacência correspondem mesmo que as formas entre

eles variem. Grafos podem ser cíclicos se suas arestas ou parte delas formam um

ciclo ou um laço e acíclicos quando não possuem ciclos, sendo neste último caso

denominados grafos em árvores (DIESTEL, 2005, p. 13-14). Uma seleção de certas

arestas contíguas num grafo produzem um caminho.

Considerando-se um diagrama de uma rede de transporte, por exemplo, é

possível se desconsiderar informações como forma das linhas e comprimentos

lineares, concentrando-se nos componentes estruturais, as junções e conexões. Os

principais elementos passam a ser a conectividade e a orientação, este último termo

significando o conhecimento das direções de início e fim de uma linha (LAURINI;

THOMPSON, 1998, p. 176). Entretanto, para uma rede de drenagem, os vértices e

arestas estão associados a elementos do mundo real e portanto, espacialmente

determinados.

2.2.3 Topologia

Em bases de dados digitais, Laurini e Thompson (1998, p. 212-214)

evidenciam a importância de reconhecer que algumas propriedades geométricas e

topológicas podem não estar diretamente codificadas, tendo que ser derivadas de

outros dados existentes. Assim, é importante identificar a topologia explícita, aquela

que está registrada em tabelas de números. Algumas formas de organização de

dados espaciais não codificam nenhuma propriedade topológica. No modelo

geométrico, entidades podem ser manipuladas completamente isoladas, não sendo

derivadas de outras entidades desconectadas. Este modelo codifica uma

correspondência um-para-um entre uma entidade e um ponto, linha ou região e um

registro na tabela. Somente a informação posicional é registrada. Assim, entidades

são geometricamente definidas, mas nenhuma relação espacial é gravada. Por outro

lado, no modelo topológico, dados estruturados podem ser manipulados

algebricamente e aritmeticamente para produzir estatísticas, para revelar

propriedades de grafos e de superfície ou para facilitar detecção de erros.

Propriedades topológicas são custosas de serem produzidas a partir de geometria,

mas podem ser vantajosas na obtenção de alguns relacionamentos espaciais.

2.2.4 Representação da estrutura topológica

Para cada grafo G existe uma matriz n x e chamada matriz de incidência de

G ou M(G) = [ m

], onde m

é o número de vezes (0, 1 ou 2) que n

e e

são

incidentes, sendo a matriz uma forma diferente de representar o diagrama do grafo.

Uma outra matriz associada a G é a matriz de adjacência. Esta é uma matriz A(G) =

[ a

] de ordem n x n, na qual a

é o número de arestas unindo n

a n

(fig. 6).

A forma de representação de uma estrutura topológica pode variar

convenientemente em função do tipo de densidade verificado pelas conexões entre

seus nós. Se grafos apresentam uma densidade de conexões muito alta, a matriz de

adjacência pode ser empregada. Essa matriz armazena as ligações existentes entre

os nós de um grafo. Se o grafo for orientado, onde o sentido da ligação entre os

pares de nós é relevante, a matriz poderá ser assimétrica.

FIGURA 6 - GRAFO, MATRIZ DE INCIDÊNCIA E MATRIZ DE ADJACÊNCIA

FONTE: BONDY e MURTY (1982)

As arestas também podem receber um valor que represente o custo, tempo

de percurso ou outro valor relacionado com o deslocamento de um nó para outro

(WORBOYS, 1995, p. 232-233). Por outro lado, numa situação de grafos esparsos,

onde poucas conexões acontecem entre os nós, uma lista de adjacência pode ser a

mais indicada.

A utilização desta lista de adjacência é ilustrada na figura 7 para dois tipos

de grafos: grafos orientados e não-orientados. Para cada um dos tipos de grafos,

três listas são mantidas: a primeira informa qual a conectividade entre as arestas

(links), a segunda indica com qual nó uma dada aresta se conecta e a terceira

registra quais arestas se conectam a um dado nó.

FIGURA 7 - LISTA DE ADJACÊNCIA PARA CADA NÓ (GRAFOS ESPARSOS):

(a) GRAFO ORIENTADO; (b) GRAFO NÃO-ORIENTADO

FONTE: LAURINI e THOMPSON (1998)

2.2.5 Polilinhas

Um grafo pode ser construído por meio de um conjunto de polilinhas.

Worboys (1995, p. 100) define polilinha como sendo um conjunto finito de

segmentos lineares, chamados arestas, tais que o ponto final de cada aresta é

compartilhado exatamente por duas arestas, exceto possivelmente para dois pontos,

chamados de extremos da polilinha. Pela própria definição, uma polilinha guarda

uma relação ordenada de pontos, mas ela não indica necessariamente uma

orientação. Ela pode representar um lugar ou coisa que tem comprimento mas não

área, em qualquer escala. A figura 8 ilustra alguns exemplos de polilinhas.

FIGURA 8 - EXEMPLO DE POLILINHAS

FONTE: WORBOYS (1995)

Existem basicamente dois métodos de se codificar feições uni-dimensionais

de mapas topográficos como uma cadeia de dados. A primeira consiste de se

registrar segmentos lineares de comprimento e direções fixos. Exemplo deste

método é a codificação encadeada (chain encoding). Neste processo, cada novo

ponto final do segmento linear segue uma das oito direções possíveis em relação a

seu ponto inicial, e uma melhor aproximação com o objeto cartográfico é obtida

reduzindo-se o comprimento fixo unitário com consequente aumento do

armazenamento de dados. Este método é mais apropriado para representação

matricial de resolução fixa. O segundo método representa uma linha por uma cadeia

de segmentos de linhas com direção e comprimentos variáveis. Cada ponto na

cadeia é dado pelas coordenadas absolutas num sistema de coordenadas

cartesiano. Este método é o usualmente utilizado na codificação de polilinhas

(CROWLEY, 1992, p. 128-130).

Uma polilinha pode ter uma ou mais partes (ESRI, 1998). Por exemplo, um

canal simples a céu aberto é tipicamente uma feição de polilinha com uma parte.

Mas se o fluxo do canal prossegue de forma subterrânea e posteriormente ressurge,

ele pode ser representado como uma feição de polilinha multiparte com partes

descontínuas. A figura 9 apresenta um exemplo de polilinha simples:

FIGURA 9 - VISUALIZAÇÃO DE UMA POLILINHA NO SOFTWARE ArcMap

FONTE: O autor (2008)

Se o fluxo diverge ao redor de uma ilha e então reconverge, ele pode ser

representado como uma feição polilinha multiparte com partes ramificadas. Uma

feição polilinha multiparte está associada com um único registro numa tabela de

atributos.

2.2.6 Polilinhas e interseção de retângulos

As polilinhas são elementos resultantes do processo de captura da rede de

drenagem utilizado. Cada polilinha é representada por uma lista ordenada de pontos

coordenados. Para uma mesma rede de drenagem, elas podem variar em

quantidade e forma, conforme o processo manual de digitalização empregado ou do

algoritmo utilizado no processo de extração e vetorização, não sendo

necessariamente pré-definidas ou representando necessariamente um trecho de

canal completo da rede de drenagem. Por esta razão, processos de simplificação

que analisem e simplifiquem as relações entre elas, podem ser úteis antes da

determinação das confluências.

Polilinhas entre si não guardam uma relação topológica explícita. Dadas

duas polilinhas quaisquer, uma das seguintes relações pode ser observada: (a)

conectividade, quando um dos pontos extremos de uma delas se conecta a um dos

pontos extremos da outra; (b) interseção, quando um dos segmentos de uma delas

se intercepta com um dos segmentos de outra, ou um dos extremos de uma “toca”

um dos segmentos da outra; (c) disjuntas, quando nenhuma das relações anteriores

é verificada. Faz-se necessário determinar as relações entre elas para que a

topologia na forma de arco-nó seja definida. As interseções entre duas ou mais

polilinhas determinam as confluências de uma rede.

Dependendo do tamanho da rede, o custo computacional de determinações

de interseções de polilinhas pode ser muito alto. De modo a diminuir este esforço,

estratégias podem ser empregadas. Uma dessas estratégias é a utilização de

retângulo envolvente mínimo ou REM (DAVIS JUNIOR; QUEIROZ, 2005, p. 49). O

REM é o menor retângulo com lados paralelos aos eixos coordenados que contém a

geometria da polilinha. Por comparação direta entre REMs de polilinhas, procura-se

pelos REMs que se interceptam. A partir dessas interseções, é possível que as

polilinhas possam se interceptar (fig. 10). Só então, nestas interseções de REMs, o

algoritmo completo de determinação da possível interseção das polilinhas é

executado.

FIGURA 10 - INTERSEÇÃO DE REMs (a) REMs DISJUNTOS (b)

FONTE: DAVIS JUNIOR e QUEIROZ (2005)

Um exemplo deste emprego pode ser visto na figura 11, obtida pela

execução do protótipo deste trabalho. As linhas tracejadas mostram os REMs

verificados para cada polilinha encontrada da rede de drenagem, cada qual com sua

identificação numérica automaticamente atribuída pelo software e afixada próxima

ao canto inferior esquerdo. Conforme comentado anteriormente, os processos de

captura, extração, vetorização e simplificação utilizados podem conduzir a diferentes

conjuntos de polilinhas para a mesma rede de drenagem, produzindo-se

consequentemente diferentes REMs.

A utilização de REM para cada polilinha facilita o trabalho computacional,

pois ao se fazer a determinação de interseções, os REM 2 e 6, por exemplo, não

precisarão do algoritmo completo de determinação, pois os mesmos não se

interceptam. Por outro lado, tomando-se outros dois casos, os REMs 10 e 11, na

parte inferior da figura 11, e os REM 16 e 17, ao centro da figura: no primeiro caso,

os REMs se interceptam, então o algoritmo completo de determinação de interseção

é utilizado e é determinada a intersecção das respectivas polilinhas. Já no segundo

caso, apesar dos REMs se interceptarem, o algoritmo também é utilizado, mas a

intersecção das polilinhas respectivas não poderá ser obtida.

FIGURA 11 - USO DE REMS DE POLILINHAS PARA A DETERMINAÇÃO DE INTERSEÇÕES

FONTE: O AUTOR (2008)

2.2.7 Interseção de dois segmentos de reta

Da geometria analítica sabe-se que uma forma de determinação do ponto

de interseção entre dois segmentos de reta pode ser pela solução de um sistema de

duas equações de retas a duas incógnitas, provenientes da igualdade entre duas

equações paramétricas dos segmentos. Seja um segmento formado pelos pontos

p1p2 e outro pelos pontos p3p4, com p1=(x1,y1), p2=(x2,y2), p3=(x3,y3) e

p4=(x4,y4), a interseção é dada por:

p1 + u(p2 – p1) = p3 + v(p4 – p3)

Dessa igualdade surge o sistema de equações:

Desenvolvendo, chega-se a:

que substituídos nas equações (2), resolvem a interseção. Nota-se que os

denominadores das expressões u e v são os mesmos, portanto um só cálculo faz-se

necessário numa implementação computacional. Se estes denominadores forem

zero, os segmentos são paralelos. Se além dos denominadores, os numeradores em

u e v forem zero, os dois segmentos são coincidentes.

2.3 ORGANIZAÇÃO E REPRESENTAÇÃO DE DADOS TEMPORAIS

O tempo em sistemas de informação pode ser medido em pelo menos duas

dimensões distintas (WORBOYS, 1995, p. 309): dimensão do tempo de transação

(“T-interval”), também chamado de tempo do banco de dados ou tempo do sistema e

dimensão do tempo de validade (“V-interval”), também chamado de tempo do evento

ou tempo do mundo real. A primeira registra o momento em que a informação

referente ao fenômeno foi inserido na base de dados. A segunda indica o tempo

durante o qual a informação registrada representa adequadamente a realidade

modelada. Estas variáveis podem ser utilizadas isoladamente ou em conjunto em

(3)

(2)

(1)

sistemas de informação para acompanhar temporalmente um fenômeno, mediante o

emprego de rótulos temporais ou timestamps.

2.3.1 Estrutura temporal

De uma forma geral, Worboys distingue diferentes tipos de estruturas

temporais para cada dimensão temporal, ilustrando a classificação proposta

segundo a figura 12:

FIGURA 12 - ESTRUTURA TEMPORAL

FONTE: Worboys (1995, p. 309)

O tempo pode ser medido segundo uma variável discreta ou variável

contínua. A variável discreta é utilizada onde a variação dos fenômenos é

descontínua e ocorre na forma de “saltos” discretos. Para estes casos, o tempo pode

ser medido em certos instantes temporais ou em intervalos de tempos, e a variação

entre estes instantes ou intervalos é descontínua. Tomando-se a evolução dos

limites de uma propriedade rural ao longo do tempo, por exemplo, é improvável que

a demarcação da gleba de terras possa ocupar alguma posição intermediária ou que

assuma uma interpolação entre os tempos t

e t

, mas que a evolução da

demarcação ocorra em saltos discretos. A segunda variável, de forma contínua, é

utilizada onde fenômenos podem estar associados a medidas de tempo, em

diferentes níveis de precisão. Como exemplo, pode-se citar a precipitação de

chuvas, onde as medidas de precipitação podem ser tomadas por um pluviômetro

em instantes de tempo e por meio de alguma teoria de interpolação, obter os demais

valores. Na estrutura temporal da figura 12, o tempo também pode receber uma

classificação de acordo com o ordenamento temporal, podendo ser do tipo linear,

ramificado com possíveis futuros, ramificado com possíveis passados e cíclico,

quando se modela eventos repetitivos. De forma geral, a linha de tempo pode ser

vista como formada por um conjunto de intervalos de tempos discretos, indivisíveis,

chamados de chronons. Num sistema de informação que envolva representação de

dados temporal, é importante também estabelecer a duração deste chronon,

denominada de granularidade, que deve ser adequadamente definida para registrar

temporalmente o fenômeno, variável conforme a aplicação. Exemplos de

granularidades podem ser: “dia, mês e ano”, podendo ser simbolizada pela notação

“DD/MM/AAAA” e “dia, mês, ano, hora, minuto e segundo”, podendo ser simbolizada

pelo valor “DD/MM/AAAA hh:mm:ss”.

2.3.2 Modelo de “retratos sequenciais” ou snapshots

Entre os modelos temporais citados por Souza (2004), o modelo de “retratos

sequenciais” ou snapshots é o mais simples de se implementar apesar de sua

ineficiência em termos de armazenamento, resultando em grande volume e

redundância de dados (FREELAN, 2003, p. 15). Neste método, todos os fenômenos

são registrados espacialmente em cada instante da série temporal discreta e não

uniforme. Estes registros armazenam completamente todos os fenômenos, mesmo

os fenômenos que não foram alterados entre um instante e o próximo. Este método

possibilita a identificação e o estado de um fenômeno num determinado instante

registrado, porém não é possível de se conhecer quando um determinado evento

ocorreu, modificando espacialmente o fenômeno. O método de “retratos

sequenciais” é o método adotado no modelo de fenômenos terrestres.

2.4 O MODELO DE FENÔMENOS TERRESTRES

Diversos trabalhos podem ser encontrados na literatura que modelam

recursos hídricos (ZEILHOFER et al., 2006), (TEIXEIRA et al., 2007), (SOUZA,

2004) e (MAIDMENT, 2001). Estes modelos são apresentados, em geral, por meio

de diagramas de entidade-relacionamento, por diagramas de classes de objetos,

lançando-se mão da UML, ou por meio de extensões gráficas destes diagramas

tradicionais. A maioria dos modelos, no entanto, descrevem os elementos sendo

representados espacial e temporalmente de forma simples e superficial,

concentrando-se nos aspectos principais do trabalho. Outros modelos ignoram a

temporalidade ou esta encontra-se presente somente na temática principal do

estudo, tratando o fenômeno em si como imutável ao longo do tempo. Por outro

lado, modelos mais sofisticados como o ArcGIS Hydro Data Model© (MAIDMENT,

2001), permitem descrever a hidrografia de águas superficiais de uma região, por

meio de um conjunto complexo de dezenas de classes de objetos. Assim, este

modelo incorpora outras questões além da definição espacial e temporal dos

elementos constituintes do modelo, levando-se em conta aspectos relacionados com

a aplicação, como ciclo hidrológico, aspectos operacionais, como conversão e

transformação de dados, e aspectos de visualização como a representação em

várias camadas (layers). Além disso, o modelo pode ser intrinsicamente dependente

de um software de SIG ou de um arcabouço de classes específico, além de

necessitar de treinamento especializado.

Por outro lado, o modelo de fenômenos terrestres proposto por Vieira (2006)

representa fenômenos terrestres observados na cartografia topográfica e os

contextualiza num arcabouço de não mais que três classes principais:

FenomenoTerrestre, AreaLevantamento e Recobrimento. Este arcabouço formaliza

os atributos espaciais, temporais e demais atributos desses fenômenos, por meio da

notação universal da UML. A classe abstrata para fenômenos terrestres é

especializada em subclasses para cada grupo de objetos semelhantes observados

na superfície terrestre.

A figura 13 apresenta parte do diagrama de classes de objetos de

fenômenos terrestres que define os objetos da classe FenomenoTerrestre no

espaço, por meio da classe Superficie, e no tempo, por meio das classes

AreaLevantamento e Recobrimento. Em função da dimensionalidade do fenômeno

terrestre, a classe Superficie pode ser especializada. No exemplo da figura, para

fenômenos que possuam uma só dimensão, a classe Superficie1D é utilizada, a qual

por sua vez, define uma lista de pontos que compõem o fenômeno. Para outras

dimensionalidades, outras classes são sugeridas.

FIGURA 13 - DIAGRAMA DE CLASSES DE OBJETOS PARA FENOMENOS TERRESTRES

FONTE: Adatado de VIEIRA (2006)

Ao analisar a classe abstrata FenomenoTerrestre (fig. 14) daquele modelo,

observa-se que foi proposto a especialização desta classe em onze subclasses

denominadas essenciais. Entre estas subclasses, algumas foram implementadas

naquele trabalho para a realização dos experimentos, como SuperficieTerrestre,

SuperficieTopografica, Arvore, Luminaria e Edificacao. As demais subclasses são

sugeridas para implementações em trabalhos futuros (VIEIRA, 2006, p. 104), entre

elas a subclasse CorpoHidrico. Corpos hídricos são definidos como:

“... contendo uma massa amórfica em estado líquido que assume a

forma do talvegue (ou depressão) em que está contida. Esta massa líquida pode fluir

livremente de acordo com o desnível do talvegue, ou então pode estar represada

sobre parte da superfície terrestre. Exemplos de corpos hídricos são os oceanos, os

lagos e os rios.” (VIEIRA, 2006, p. 46)

Assim, as futuras implementações de subclasses devem redefinir os

atributos e operadores da classe abstrata FenomenoTerrestre. Complementarmente,

novos membros poderão ser adicionados, em função da natureza do fenômeno a ser

estudado, para cada subclasse especializada.

FIGURA 14 - AS ESPECIALIZAÇÕES DA CLASSE FenomenoTerrestre

FONTE: VIEIRA (2004)

Quando a questão temporal é levada para a modelagem para representar a

variabilidade de fenômenos ao longo do tempo, duas classes se destacam: classe

AreaLevantamento e classe Recobrimento. A primeira congrega fenômenos

observados num mesmo tempo e numa mesma escala e o levantamento apresenta

um retângulo envolvente mínimo que contém todos os fenômenos observados (fig.

15). A segunda reúne um conjunto de objetos da classe AreaLevantamento em

diferentes instantes. Assim, é importante observar que o tempo e a escala estão

associados ao levantamento e não aos fenômenos em si, não necessitando de se

explicitar estas duas grandezas para cada fenômeno individualmente.

FIGURA 15 - CLASSE AreaLevantamento E FENÔMENOS TERRESTRES LEVANTADOS

FONTE: VIEIRA (2004)

Um conjunto de objetos da classe AreaLevantamento para uma mesma

região geográfica (fig. 16) forma uma série histórica de dados de levantamentos.

Esta série histórica é formada por levantamentos instântaneos e não uniformes.

FIGURA 16 - ÁREAS DE LEVANTAMENTO COM O PASSAR DO TEMPO

FONTE: VIEIRA (2004)

As classes Recobrimento e AreaLevantamento estão representadas na

figura 17 com os seus respectivos membros. Observa-se que o membro

areasLevantamento na classe Recobrimento abriga um conjunto de objetos da

classe areaLevantamento e esta classe define, entre outros, os membros escala,

instanteObservacao e conjuntoFenomenos.

FIGURA 17 - MEMBROS DA CLASSE Recobrimento E DA CLASSE AreaLevantamento

FONTE: VIEIRA, 2004

2.5 ELEMENTOS E CARACTERÍSTICAS DE REDES DE DRENAGEM

Segundo Pinto et al. (1976, p. 36), corpos hídricos são formados pelo

escoamento superficial das águas que tem origem fundamentalmente nas

precipitações. Segundo os autores, este escoamento de águas é visto como uma

parte do ciclo hidrológico que estuda o deslocamento das águas na superfície da

Terra. Este deslocamento ocorre por caminhos preferenciais, iniciando-se em

canalículos até ganhar dimensões maiores na forma de pequenos córregos. É

possível de se decompor uma rede de drenagem em alguns elementos e que,

quando reunidos em formas interconectadas e distribuídos espacialmente, podem

conferir algumas características que auxliam na determinação e classificação de

redes de drenagem.

2.5.1 Elementos de redes de drenagem

Laurini e Thompson (1998, p. 175) observam que conceitos de topologia e

da teoria de grafos são valiosos para revelar a estrutura espacial de entidades vistas

como pontos, linhas, áreas e sólidos, após considerados os detalhes de geometria.

Estas relações não variam ao se aplicar transformações como escala e rotação. Ao

se estudar redes, como as de drenagem e de transportes, os elementos dominantes

são os objetos de dimensionalidade 0D que se restringem a um sub-conjunto de

posições pré-determinadas.

Algumas propostas para a descrição dos elementos de redes de drenagem

podem ser encontradas como em Scheidegger

(1970, apud Gontijo Junior e Koide,

2006) e Teixeira et al. (2007). Tomando-se por base, a descrição sugerida pelos

últimos autores que posteriormente será adaptada na condução metodológica deste

trabalho, tem-se:

Nascente: representação das nascentes dos cursos d’água;

Foz: representação das fozes de cursos d’água que deságuam no mar;

Confluência: representação das fozes de cursos d’água que não deságuam

no mar;

Confluência-foz: representação de todas as fozes de cursos d’água;

SCHEIDEGGER, A. E. Theoretical Geomorphology. 2ª ed. New York: Springer-Verlag, 1970, 435p.

Curso d’água: junção de trechos de curso d’água que segue da foz à

cabeceira utilizando como critério a maior área a montante a partir de cada

confluência;

Trecho de curso d’água: segmento entre uma foz e sua confluência, ou

segmento entre confluências, ou segmento entre uma confluência e sua nascente;

Rio: junção de trechos de curso d’água contínuos que possuem a mesma

toponímia.

Para ilustrar as definições anteriores, a figura 18 apresenta os elementos de

uma rede de drenagem com a seguinte simbologia: os círculos (azul) representam

as nascentes dos trechos de cursos d’água (total de quatro), os quadrados (verdes)

representam as confluências (total de três) e o triângulo (vermelho) indica a foz da

rede. Neste exemplo contabiliza-se também um total de sete trechos de cursos

d’água e quatro cursos d’água (caminhos contínuos entre uma nascente e a foz), um

deles representado em tom laranja.

FIGURA 18 - ELEMENTOS DE REDE DE DRENAGEM

FONTE: O autor (2008)

2.5.2 Características físicas de redes de drenagem

Ao se estudar redes de drenagem, algumas características se destacam em

função de seus elementos e de seus relacionamentos com a superfície topográfica

onde ocorrem e entre si. Estas características auxiliam na percepção da localização

espacial, na classificação de seus elementos e na comparação de parâmetros

físicos entre as redes de drenagem ou mesmo entre a própria rede de drenagem e

sua série temporal. De acordo com Cristofoletti

(1974, apud LIMA, 1996, p. 57), a

distribuição espacial das redes de drenagem propicia a existência de padrões de

drenagem, sendo que a maior parte desses padrões é condicionada à geologia da

região. Estes padrões (fig. 19) podem ser assim classificados:

a) dendrítico: (tree-like) ocorrem em terras altas nas quais o regolito e a

rocha mãe oferecem uma resistência relativamente uniforme à erosão.

As encostas não têm orientação dominante;

b) treliça: em regiões onde rochas de resistência desigual estão dispostas

em dobras ou colinas longas ou em áreas de topografia pouco

acentuada e resistência relativamente uniforme (planícies costeiras). Os

canais de drenagem longos fazem confluências com tributários de

canais curtos em ângulos retos com o curso maior;

c) retangular: é uma modificação da drenagem em treliça. É o padrão de

áreas de falhas onde os cursos seguem as linhas de falha. A drenagem

é condicionada pelas estruturas das rochas;

d) paralelo: lembra a forma dendrítica mas os ramos pouco antes de suas

junções com os canais principais seguem por caminho paralelo boa

parte dos trechos;

e) radial: caracterizado por talvegues que se dispõe radialmente a uma

estrutura ou região mais elevada. Ocorre em estruturas vulcânicas.

f) anelar: padrão caracterizado por um drenagem radial e alguns cursos

que se colocam como segmentos de arcos ao redor de um ponto mais

elevado a montante da drenagem radial. É um padrão onde uma

drenagem radial se associa a uma drenagem concêntrica devidos a

estruturas concêntricas.

CHRISTOFOLETTI, A. Geomorfologia. São Paulo: Edgard Blucher e EDUSP, 1974. 149 p.

FIGURA 19 - PADRÕES DE DRENAGEM

FONTE: CRISTOFOLETTI (1974)

Na literatura são encontrados diversos índices e relações empíricas que

procuram caracterizar uma bacia de drenagem. Entre as principais características

fisiográficas de uma bacia, estão: área da bacia de drenagem, comprimento e

declividade do canal mais longo ou canal principal, declividade e comprimento dos

afluentes, rugosidade do canal, tipo do recobrimento vegetal e distância entre o fim

do canal e o espigão (PINTO et al., 1976, p. 139-140). Lima (1996, p. 58) descreve

também outras características: compacidade, densidade de drenagem, altitude

média, declividade média, orientação, rugosidade dos canais e índice de

circularidade.

Na literatura, os termos “bacia de drenagem” e “bacia hidrográfica” são

utilizados de forma intercambiável e não há, a princípio, uma diferenciação para

estes termos. Uma bacia de drenagem pode ser definida como “a área de drenagem

de um curso d’água ou lago” (BACIA HIDROGRÁFICA, 2006). A área de drenagem

de uma bacia (A), relacionada a um determinado ponto de um canal ou em relação

ao nó foz, pode ser definida como a área projetada sobre uma superfície horizontal

plana delimitada pelos seus divisores topográficos a montante do ponto considerado.

É o elemento básico para o cálculo de outras características físicas e normalmente é

expressa em km² ou hectares.

Uma indicação do grau de desenvolvimento de um sistema de drenagem é

a densidade de drenagem (Dd). Este parâmetro físico é importante, pois está

relacionado com o grau de influência da geologia, topografia, cobertura vegetal e

com o tempo gasto para o escoamento superficial da área de drenagem. Pode ser

definida como:

em ,

drenagem de área

águad' cursos dos totalcomp.

drenagem de densidadeD ==

Aparentemente, parece não haver um consenso na literatura quanto à

classificação de regiões segundo a densidade de drenagem. Segundo Villela e

Mattos

(1975, apud TONELLO et al., 2006), esse índice pode variar de 0,5 km/km2

para regiões com drenagem pobre a 3,5 km/km2 ou mais, para regiões

excepcionalmente bem drenadas. Por outro lado, Strahler

(1957, apud LIMA, 1996,

p. 62) emprega outra classificação: baixa (até 5.0 km/km

), média (entre 5,0 e 13,5

km/km

), alta (entre 13,5 e 155,5 km/km

) e muito alta (acima de 155,5 km/km

De uma outra forma, a densidade de confluências (Dc) pode ser expressa

como a razão entre o número de confluências encontradas na rede de drenagem

pela área da bacia de drenagem. Esta medida caracteriza o grau de ramificação de

uma rede de drenagem.

Outra grandeza importante presente nas características físicas de uma

bacia hidrográfica é o comprimento de um canal (L), que pode ser expresso como a

soma dos comprimentos de trechos de canais. Esta grandeza, juntamente com a

declividade, é utilizada em Hidrologia para o cálculo da determinação do tempo de

VILLELA, S. M.; MATTOS, A. Hidrologia aplicada. São Paulo: McGraw-Hill do Brasil, 1975. 245 p.

STRAHLER, A. N. Quantitative analysis of watershed geomorphology. Trans. American

Geophysical Union, 38, 1957. p. 913-920.

(4)

concentração de uma bacia, ou seja, o tempo necessário para que toda a área de

drenagem passe a contribuir para a vazão na seção estudada da rede de drenagem

(PINTO et al., 1976, p. 139-140).

A declividade do terreno é expressa como a variação de altitude entre dois

pontos do terreno, em relação à distância que os separa. Esta declividade pode ser

expressa em percentual (%) ou numa relação entre unidades de comprimento entre

altitude e distância, como (m/km). EMBRAPA

(1979, apud TONELLO et al., 2006)

preconiza seis intervalos distintos de declividades, de acordo com a tabela 2:

TABELA 2 - INTERVALOS DE DECLIVIDADE DO TERRENO

Declividade (%) Descrição

0 – < 3 Relevo plano

3 – < 8 Relevo suave ondulado

8 – < 20 Relevo ondulado

20 – < 45 Relevo forte ondulado

45 – < 75 Relevo montanhoso

>= 75 Relevo forte montanhoso

FONTE: EMBRAPA (1979)

Alguns índices de formas de bacias hidrográficas são encontrados na

literatura e normalmente sugerem a tendência de inundação que uma bacia pode

ter. Entre eles, citam-se dois: o Fator de Forma (Ff) proposto por Horton

(1932,

apud LIMA, 1996, p. 53) e o Índice de Circularidade (IC) proposto por Miller

(1953,

apud LIMA, 1996, p. 62). O primeiro relaciona a área da bacia (A) com o

comprimento do maior eixo da bacia (Lmax), medido como a distância entre o nó foz

e o ponto mais longínquo do espigão. Este índice pode dar indicações sobre a

EMPRESA BRASILEIRA DE PESQUISA AGROPECUÁRIA. Serviço Nacional de Levantamento e

Conservação de Solos. In: REUNIÃO TÉCNICA DE LEVANTAMENTO DE SOLOS, 10., 1979, Rio

de Janeiro. 83 p.

HORTON, R.E., 1932. Drainage Basin Characteristics. Trans. American Geophysical Union, 13:

350-361.

tendência de inundações numa bacia. Assim, quanto maior for o fator de forma,

maior a possibilidade de inundações. Esta relação é dada pela seguinte expressão:

O segundo estabelece a relação da área da bacia com o seu perímetro (P).

Quanto mais próximo de 1,0 estiver este índice, mais próximo da forma circular

estará a bacia de drenagem. É expresso pela fórmula:

sendo 12,57 o parâmetro de conversão área/perímetro.

2.5.3 Hierarquização da rede de drenagem e métodos de ordenamento

Análises de redes de drenagem consideram uma rede como uma “árvore”

com a sua “raiz” tomada no ponto mais a jusante do fluxo da rede considerada.

Estas análises usam a quantidade de trechos a montante deste ponto, como uma

medida da importância dos trechos nesta “árvore”. Teixeira et al. (2007) comentam

que a hierarquização fluvial estabelece a classificação de determinado curso d’água

ou da área drenada que lhe pertence, no conjunto total de sua bacia hidrográfica. O

ordenamento de redes de drenagem confere um nível de significado a cada canal,

possibilitando uma sistematização da codificação de seus elementos.

De acordo com McAllister (1999, p. 16-17), três métodos de ordenamento

de redes de drenagem se destacam: método de Strahler, método de Horton e o

método de Shreve (fig. 20). No método de Strahler, o canal principal não mantém

sempre a mesma ordem ao longo de toda a sua extensão e a rede de canais pode

ser decomposta em segmentos discretos cujas áreas de contribuição formam a

própria bacia de drenagem. A ordem dos canais de drenagem pode ser definida

como a hierarquização dos vales de uma bacia de drenagem em 1

ordem (vales

MILLER, V.C. A quantitative geomorphic study or drainage basins characteristics in the Clinc

Mountain area. Technical Report (3). Dept.' Geology Columbia University, 1953.

max

Ff =

(5)

57,12

IC =

(6)

mais elevados e sem tributários), 2

ordem (a jusante da confluência de 2 ou mais

tributários de 1

ordem), 3

ordem (a jusante da confluência de 2 ou mais tributários

de 2

ordem) e, assim, sucessivamente, sendo que um tributário de ordem "n" pode

desembocar em outro de ordem maior que "n+1”.

FIGURA 20 - MÉTODOS DE ORDENAMENTO HIDROLÓGICO

FONTE: McALLISTER, 1999.

No método de Strahler, o ordenamento confere grau “1” para os trechos de

canais que partem dos nós nascentes e este valor é alterado quando dois trechos se

encontram numa confluência, recebendo novo valor. Algebricamente, se o encontro

de dois trechos de graus N e P for denotado por “&” segue-se (GONTIJO JUNIOR;

KOIDE, 2006, p. 4):

N & P = N + 1 se N = P

N & P = max (N, P) se N ≠ P

O método de Horton utiliza o mesmo método de Strahler, a fim de identificar

a maior ordem de trecho de canal de drenagem. No entanto, após esta

determinação, o algoritmo segue no sentido inverso, a montante, renumerando o

próximo trecho do canal com o valor da mais alta ordem obtida para o trecho

pertencente ao caminho mais longo a montante. Caso o trecho a montante não

pertença ao caminho mais longo, este trecho permanece com a ordem de Strahler.

Todos os trechos de canais que receberam a mais alta ordem formam o canal de

drenagem principal.

(7)

(8)

No método de Shreve, a ordem de cada trecho de canal de drenagem é

obtida somando-se a ordem dos trechos de canais a montante que contribuíram

para o trecho em questão. Algebricamente, a relação pode ser expressa como:

N & P = N + P, para quaisquer N e P

Shreve chamou esta ordem de magnitude (M) da rede de drenagem, em

relação a um determinado nó foz, como sendo o número de nós nascentes da rede.

No entanto, na literatura é possível identificar diferentes métodos para definição da

magnitude (GONTIJO JUNIOR; KOIDE, 2006, p. 5).

2.5.4 Extração de redes de drenagem

Delazari (1996, p. 35-49) cita o desenvolvimento de técnicas automáticas

para extrair, armazenar e prover medidas a respeito das redes de drenagem

diretamente a partir dos modelos digitais de terreno (MDT). Segundo Weibel e Heller

(1991, p. 269-297) os MDT se constituem de elementos fundamentais em SIG,

auxiliando na modelagem, análise e visualização da superfície da Terra.

A extração de redes de drenagem é um processo que pode empregar

diferentes abordagens, conforme a natureza da entrada seja proveniente de

modelos digitais, imagens de satélites, imagem radar, imagem fotogramétrica, mapa

digitalizado, entre outras. Alguns anos atrás, o processo de extração era bastante

trabalhoso pois como não havia num só produto a solução completa, vários

softwares eram utilizados num sequenciamento manual de etapas (DELAZARI,

1996, p. 50-87). Atualmente, é possível encontrar softwares de SIG com o processo

de extração consolidado num único ambiente. No apêndice 2 encontra-se um

resumo dos passos do processo de extração de uma rede de drenagem no ambiente

ArcGIS

, que foi utilizado como opção para a obtenção de dados para a realização

de um dos experimentos deste trabalho.

2.5.5 Aplicações que empregam redes de drenagem

Modelos de redes de drenagem podem ter especial utilidade em aplicações

como:

(9)

a) gestão de recursos hídricos (TEIXEIRA et al., 2007);

b) manejo de recursos hídricos (HOTT et al., 2007);

c) outorgas de bacias hidrográficas (ZEILHOFER et al., 2007);

d) na identificação de problemas ambientais;

e) no diagnóstico de condições de qualidade da água (SOUZA, 2004);

f) na execução de obras hidráulicas (PINTO et al., 1976);

g) nas relacionadas com geologia para determinação de nível de

permeabilidade do solo;

h) na agricultura para estudo no transporte de poluentes;

i) em ecologia e geotecnia no estudo de erosão de solo a partir de cálculo

de tamanho de rampas.

Um possível grupo de aplicações, que necessitam de um modelo de redes

de drenagem, é aquele que utiliza além dos atributos não-espaciais, a topologia

(conexões e caminhos pela rede), formando-se o que é chamado de unifilar

topologicamente consistente (TEIXEIRA et al., 2007). Estudos detalhados sobre a

determinação deste unifilar equivalente podem ser encontrados em (McALLISTER,

1999, p. 21-23). Assim, essa consistência é assegurada com todos os segmentos de

drenagem conectados (o nó sendo o elemento de conexão) em seus afluentes ou

efluentes. Esta topologia linearmente conectada é definida por uma relação arco-nó

representada vetorialmente. Estes segmentos lineares são formados por um par de

coordenadas. Se for considerada a questão hidrológica, algumas simplificações no

entanto podem ser necessárias, por exemplo: se parte desta rede de drenagem

apresentar uma forma de polígono (caso de um lago, de uma represa ou rio com

margens duplas), esta deve ser substituída por um arco passando preferencialmente

de modo equidistante ao longo de seu eixo maior. Em outros tipos de aplicações,

além da topologia, podem ser necessárias características e fatores como seção

transversal, grupo hidrológico do solo, tipo de cobertura superficial, tipo de

tratamento e condição de umidade antecedente, declividade, rugosidade e

delimitação das margens. Isto implica na necessária compatibilização com o nível de

detalhe requerido elevando-se o problema para uma complexidade ainda maior

(BARRETO NETO; SOUZA FILHO, 2007, p. 3288).

2.6 CARACTERÍSTICAS DA MODELAGEM ORIENTADA A OBJETOS

Segundo Navathe (1992, p. 112-123) um modelo de dados semântico deve

possuir características como:

a) expressividade: o modelo deve permitir distinguir tipos de dados,

relacionamentos e restrições, incluindo os três mecanismos de

abstração: classificação, agregação e generalização;

b) simplicidade: o modelo deve permitir a construção de diagramas em

diferentes níveis de detalhe, facilitando o entendimento e usabilidade;

c) minimalidade: nenhum conceito do modelo pode ser descrito pelos

demais. O modelo deve expressar conceitos básicos, diretos e distintos;

d) formalidade: o modelo deve ter seus conceitos formalmente definidos,

com interpretação única, precisa e bem-definida.

Booch, Rumbaugh e Jacobson (2006, p. 6, 11) enumeram quatro objetivos

que a modelagem pode atingir: (1) os modelos ajudam a visualizar o sistema como

ele é ou como se deseja que seja; (2) os modelos permitem especificar a estrutura

ou o comportamento de um sistema; (3) os modelos proporcionam um guia para a

construção do sistema; (4) os modelos documentam as decisões tomadas.

Segundo os mesmos autores, pode-se definir um modelo de software de

várias maneiras. As duas mais comuns são provenientes da perspectiva da

execução de um algoritmo ou da perspectiva orientada a objetos. Na primeira visão,

o principal bloco de construção do software é o procedimento ou a função que

descreve passos de execução controlada. O foco neste tipo de construção está na

atenção dada ao controle e à decomposição funcional de procedimentos. À medida

que os requisitos se alteram e o sistema cresce em complexidade, a manutenção se

torna mais difícil podendo o sistema se tornar instável. Na segunda visão, a de

orientação a objetos, o principal bloco de construção é o objeto ou a classe do

objeto. De forma resumida, um objeto é visto como algo estruturado a partir da

semântica do espaço do problema ou do espaço da solução; uma classe é vista

como um “molde” que constrói aquele objeto, permitindo-se criar vários objetos a

partir da mesma classe. Estes objetos possuem: (a) uma identificação que o tornam

únicos em relação aos outros; (b) um estado do objeto na forma de um conjunto de

atributos associados a ele e (c) um comportamento regulando o que se pode fazer

com o objeto ou o que o objeto pode fazer com outros objetos. Na visão de

orientação a objetos, se persegue baixo acoplamento (loose coupling), definido

como responsabilidade comparativamente pequena e bem definida que os objetos

que interagem têm um para com o outro (METSKER, 2004, p. 385) e, ao mesmo

tempo, a alta coesão, ou seja, baixa diversidade de “tópicos” abordados na mesma

classe, possibilitando aumentar o grau de clareza e compreensão do projeto,

conferindo grau de independência maior e o grau de usabilidade de uma classe,

além de diminuir a instabilidade no sistema decorrentes de manutenção.

2.6.1 Modelos de dados

Aspecto fundamental no projeto de um SIG, o modelo de dados descreve

como a realidade geográfica será representada no computador. Um modelo de

dados é um conjunto de ferramentas conceituais utilizado para estruturar dados num

sistema computacional e unificar diferentes visões sobre os dados (CHEN, 1976, p.

9). Chen propôs um modelo de dados que denominou “Modelo de Entidade-

Relacionamento” (entity-relationship model), com a finalidade de capturar

informações importantes da semântica do mundo real. Esta semântica é

evidenciada na estrutura de entidades e de seus atributos, assim como nas relações

entre as próprias entidades. Este modelo deve ser projetado com extremo cuidado,

pois sendo a base estrutural para os dados de um sistema, poderá permitir o

crescimento futuro do sistema, como também ser um fator limitante para tal

evolução.

Kösters, Pagel e Six (1996, p. 5) ponderam que um modelo adequado para

trabalhos com redes envolvendo uma grande quantidade de dados é um

compromisso entre precisão e completude (capacidade de expressar sucintamente o

fato de forma completa) por um lado, com a legibilidade (facilidade de leitura pelo

usuário) e entendimento, de outro.

2.6.2 Orientação a objetos

Resumidamente, cada entidade de um modelo de dados pode ser vista

como um objeto. Um objeto é criado a partir de uma classe e é dito que ele é uma

instância de uma classe. Uma classe pode ser vista como uma definição de um novo

tipo de dados. A definição de uma classe consiste de um nome de identificação da

classe e de um corpo que contêm um conjunto de membros. Os membros de uma

classe podem incluir dados (atributos) que são armazenados em campos e estão

fortemente associados a procedimentos codificados organizados em métodos que

descrevem operações ou comportamentos. Uma classe pode ser dita abstrata

quando a classe for definida de forma que seus membros serão utilizados por outras

classes mais especializadas, ditas subclasses. Uma classe abstrata não pode ser

instanciada mas estendida por outras classes. Uma das vantagens do uso de

objetos é que objetos encapsulam campos e métodos. Assim, objetos podem

esconder detalhes da implementação de outros objetos, mantendo apenas interfaces

bem-definidas para comunicação entre eles (DEITEL; DEITEL, 2003, p. 68). Estes

detalhes de implementação podem ser modificados ou evoluídos ao longo do tempo

sem que impactem nos demais objetos de outras classes, desde que as interfaces

de comunicação mantenham-se as mesmas. Estes campos e métodos apresentam

dois tipos distintos: membros de classe (conhecidos também como membros

estáticos) associados à própria classe e membros de instância associados a

instâncias individuais da classe. Membros de classes definem campos e operações

que são comuns a todas as instâncias da classe e há somente uma cópia deles para

compartilhamento geral. Membros de instância, ao contrário, pertencem a cada

instância da classe e existem tantas cópias deles quantas as instâncias criadas. As

definições de campo podem também incluir modificadores de acesso. Esses

modificadores especificam se e onde um campo pode ser utilizado fora da classe

que o define, e são fundamentais para prover ocultamento e encapsulamento de

dados. Classes podem ter um ou mais construtores para inicializar campos de uma

instância criada. Um construtor nada mais é que um método de mesmo nome da

classe, definindo uma lista de parâmetros para a inicialização de campos da

instância (FLANAGAN, 2006, p. 110-116).

2.6.3 A linguagem de modelagem unificada (UML)

A UML é uma linguagem-padrão que define as regras e notação para

especificar sistemas de software orientado a objetos. Especificar, neste contexto,

significa construir modelos precisos, sem ambiguidades e completos (BOOCH;

RUMBAUGH; JACOBSON, 2006, p. 15). A UML não é um processo prescritivo para

o desenvolvimento de software. Ela não fornece um método ou processo, mas

simplesmente uma linguagem que pode ser empregada numa variedade de modos e

combinações de diagramas para especificar e desenvolver um projeto de software,

possibilitando oferecer comunicação entre o projetista do modelo e o usuário, e entre

o projetista e o implementador do modelo. A UML independe de linguagens de

programação e independe de métodos de desenvolvimento A notação oferece um

conjunto rico de elementos gráficos para a modelagem de elementos orientados a

objetos e as regras informam como estes elementos podem se conectar entre si e

como podem ser utilizados (SPARX SYSTEMS, 2006).

O processo de desenvolvimento de software pode ser visualizado em

diferentes perspectivas para facilitar o exame e estudo por parte dos

desenvolvedores e demais participantes do projeto. Estas perspectivas poderão ser

utilizadas na medida que a complexidade do software as determine. A arquitetura de

um sistema complexo de software pode ser descrita mais adequadamente por cinco

visões interligadas (fig.21), cada visão enfatizando aspectos diferentes, como

estruturais e comportamentais, do mesmo sistema de software (BOOCH;

RUMBAUGH; JACOBSON, 2006, p. 10, 34-35).

FIGURA 21 - AS CINCO VISÕES DE UM SISTEMA DE SOFTWARE

FONTE: BOOCH; RUMBAUGH; JACOBSON (2006)

VISÃO DE

PROJETO

VISÃO DE

IMPLEMENTAÇÃO

VISÃO DE

PROCESSO

VISÃO DE

IMPLANTAÇÃO

VISÃO DE

CASO DE USO

Em geral, a primeira visão trabalhada ao se estudar um sistema é a visão de

caso de uso e direciona o desenvolvimento das outras visões do sistema. Ela

abrange os casos de usos que descrevem o comportamento do sistema conforme é

visto pelos seus usuários finais. Ela também ajuda na elaboração de casos de testes

a serem desenvolvidos posteriormente para se validar o sistema. Esta visão

responde a pergunta “o que será tratado?”. Esta visão define um “contrato” entre os

desenvolvedores e os demais interessados no projeto, relacionando o que será

desenvolvido e o que ficará de fora do sistema. A visão de projeto abrange as

classes, interfaces e colaborações que formam o vocabulário do problema e de sua

solução. Ela descreve os aspectos que dão suporte tecnológico, estrutural e

comportamental às funcionalidades externamente visíveis do sistema. A visão de

implementação trata do modo de como o sistema será estruturado, versionado e

gerenciado. A visão de implantação descreve o plano de como o sistema será

distribuído fisicamente e liberado nas plataformas de operação, incluindo as

conexões entre as diversas partes. Finalmente, a visão de processo realça as

características internas de desempenho, sincronização e concorrência do sistema.

2.6.4 Diagramas da UML

De acordo com o Object Management Group (2005), a UML apresenta 13

tipos de diagramas diferentes classificados em dois grandes grupos (fig. 22):

diagramas estruturais (Structure diagrams) e diagramas comportamentais (Behavior

diagrams). Os elementos num diagrama estrutural representam conceitos relevantes

de uma aplicação e podem incluir conceitos abstratos, do mundo real e de

implementação. Diagramas comportamentais apresentam o comportamento

dinâmico de objetos num sistema, incluindo seus métodos, colaborações, atividades

e histórico de mudança de estados. O comportamento dinâmico de um sistema pode

ser descrito como uma série de mudanças ocorridas no sistema ao longo do tempo.

Esta taxonomia fornece uma organização lógica dos vários tipos de diagramas

(OBJECT MANAGEMENT GROUP, 2005). Dependendo do domínio do tipo de

sistema que se precise modelar, o projetista pode lançar mão de uma combinação

destes diagramas que não inclua necessariamente todos, para o entendimento do

sistema, a captura de requisitos e a proposição do modelo para construção.

FIGURA 22 - DIAGRAMAS DA UML

FONTE: OBJECT MANAGEMENT GROUP (2005)

NOTA: UML 2.1.1 Superstructure, ap.A-5 The taxonomy of structure and behavior diagram, pg. 694

2.6.5 Vantagens no emprego da UML para a construção de modelos

A UML é uma linguagem recomendada na modelagem de sistemas e

diversas ferramentas de CASE (Computer Aided Software Engineering) a

implementam para oferecer, além da modelagem, um meio de comunicação entre os

interessados no projeto e os desenvolvedores do sistema, e um meio de ligação

bidirecional entre o modelo e a implementação. Assim, diz-se que a ferramenta pode

gerar código básico de programação na linguagem de programação alvo

(preferivelmente orientada a objetos) da escolha do implementador e por

reengenharia reversa, a partir do código alterado, atualizar partes do modelo

(BOOCH; RUMBAUGH; JACOBSON, 2006, p. 16). Outra funcionalidade útil destas

ferramentas é a capacidade de geração de diagramas de entidades-relacionamentos

a partir de diagramas de classes de objetos e consequente geração de scripts,

blocos de códigos escritos em linguagem DDL (Data Descriptor Language) para a

criação e manutenção de tabelas em bancos de dados relacionais (SPARX

SYSTEMS, 2006).

A seleção pela UML como linguagem de modelagem neste trabalho, foi

considerada pelas seguintes razões:

a) linguagem e notação simbólica simples, universal, além de ser

extensível;

b) conjunto de diagramas que cobrem aspectos estáticos e dinâmicos da

modelagem;

c) utilização tradicional no desenvolvimento de software utilizando

programação orientada a objetos;

d) independente de métodos de desenvolvimento e de linguagens de

programação específicos;

e) treinamento e suporte continuados pela comunidade;

f) existência de diversas ferramentas de software que implementam muitas

das características preconizadas na UML.

2.6.6 Diagramas de casos de uso

Diagramas de casos de uso são diagramas da UML que procuram

representar o que será tratado no sistema. Eles têm um papel central para a

modelagem do comportamento de um sistema (BOOCH; RUMBAUGH; JACOBSON,

2006, p. 98, 241-242) e formam a base para o desenvolvimento dos demais

diagramas. Os diagramas de casos de uso auxiliam na comunicação entre usuários

finais do sistema, especialistas de domínio e desenvolvedores para a visualização,

especificação, construção e documentação de decisões sobre requisitos funcionais

do sistema. Um diagrama de casos de uso normalmente é representado por um

retângulo mais externo que define a fronteira do sistema. No interior deste retângulo,

os demais casos de uso integrantes do caso de uso maior são representados em

forma de elipses. Na parte exterior ao retângulo, representam-se os atores que irão

interagir com o sistema, sobre os quais não se tem controle, podendo ser uma

classe de pessoas, instituições ou mesmo outro sistema ou processo externo.

Descrevem-se também neste diagrama, na forma de linhas, os relacionamentos que

podem existir entre atores e casos de uso, e entre os próprios casos de uso. A figura

23 ilustra este tipo de diagrama.

FIGURA 23 - EXEMPLO DE DIAGRAMA DE CASOS DE USO

FONTE: BOOCH; RUMBAUGH; JACOBSON, 2006

Em modelagem de sistemas mais complexos, acima de uma dúzia de casos

de uso, estes podem ser expandidos separadamente para sucessivamente

descrever a funcionalidade, mantendo-se a legibilidade (BEZERRA, 2003, p. 64).

Eles não devem procurar descrever uma possível solução do problema, mas sim

descrever o escopo levantado do sistema.

2.6.7 Diagramas de classes

Diagramas de classes são diagramas da UML que procuram representar os

aspectos estáticos e estruturais das classes, interfaces, colaborações e seus

relacionamentos (BOOCH; RUMBAUGH; JACOBSON, 2006, p. 96). Estes

diagramas são utilizados na construção do modelo de classes desde o nível de

análise até o nível de especificação. De todos os diagramas da UML, esse é o mais

rico em termos de notação (BEZERRA, 2003, p. 97). A figura 24 ilustra este tipo de

diagrama.

FIGURA 24 - EXEMPLO DE UM DIAGRAMA DE CLASSES

FONTE: BOOCH; RUMBAUGH; JACOBSON, 2006

Uma classe é uma descrição de uma coleção de dados e de um código para

operar sobre esses dados. Os dados são armazenados em campos e o código é

organizado em métodos. Campos e métodos são chamados genericamente de

membros. Membros podem ser de dois tipos distintos: membros de classe e

membros de instância. Os primeiros estão associados à própria classe em si, são

ditos estáticos e são comuns a todos os objetos instâncias dessa classe. Por esta

razão são chamados de membros globais. Os segundos estão associados

individualmente a cada instância de objeto da classe e não são em geral

compartilhados com outros objetos da mesma classe (FLANAGAN, 2006, p. 110-

116). De acordo com Booch, Rumbaugh e Jacobson (2006, p. 52-53), campos e

métodos também são denominados atributos e operações respectivamente.

Conforme exemplo da figura 25, as classes são representadas na UML por

retângulos e são divididos, na forma completa de visualização, em três blocos: no

bloco superior representa-se o nome da classe, no bloco intermediário os atributos

da classe e no bloco inferior as operações da classe (BOOCH; RUMBAUGH;

JACOBSON, 2006, p. 49-55).

FIGURA 25 - EXEMPLO DE CLASSE EM UML

FONTE: O autor (2008)

De acordo ainda com este exemplo, todo objeto canal tem como atributos,

um id ou identificador, um comprimento e uma declividade. Na simbologia da figura

21, notam-se dois sinais de prefixos que qualificam a visibilidade dos membros. O

sinal de menos (“-“) denota que o membro é privado (private) e portanto visível

somente ao objeto em particular da classe. O sinal de mais (“+”) torna o membro

público (public) e portanto visível a qualquer outro objeto, tanto da mesma classe

como de outra classe qualquer (BOOCH; RUMBAUGH; JACOBSON, 2006, p. 122,

125-126). O nome da classe, em geral, é o nome de um substantivo colhido a partir

do vocabulário do sistema, cuja modelagem está sendo feita. Tipicamente começa

com uma letra maiúscula e pode ser um nome composto de mais de uma palavra,

como por exemplo TrechoDeCanal. Um campo é uma propriedade nomeada de uma

classe, que descreve o intervalo de valores que a propriedade pode apresentar nas

instâncias de objetos daquela classe. Pode-se dizer que o campo é uma abstração

do tipo de dados ou estados que os objetos da classe podem abranger. Campos

também podem guardar semânticas de agregação (relacionamentos) existentes

entre classes. A UML possibilita que se especifique a maneira de como o campo

pode ser lido, escrito e compartilhado com todos os objetos da classe ou por outros

objetos de classes diferentes.

Em geral, os campos da classe não devem estar visíveis diretamente para

leitura ou gravação a partir de outros objetos, mas sim por meio de métodos da

classe do objeto. Campos são normalmente definidos com a primeira letra em

minúscula. Uma operação é a implementação de um serviço que pode ser solicitado

por algum objeto da classe para modificar o comportamento. Muitas vezes, é pela

chamada a uma operação de um objeto, que dados do objeto ou do estado do objeto

podem ser alterados. Operações tipicamente referem-se a um verbo ou a uma

locução verbal, podem ser parametrizadas e aparece como maiúsculo o primeiro

caractere de cada palavra existente no nome da operação, exceto a primeira letra. A

UML possibilita que se especifique outras características da operação, como

visibilidade e assinatura, esta contendo o nome, o tipo e o valor-padrão de todos os

parâmetros e o tipo a ser retornado, no caso da operação ser uma função. Booch,

Rumbaugh e Jacobson (2006, p. 54) notam que não é preciso exibir todos os

atributos e operações ao mesmo tempo na figura da classe. Na maioria das vezes,

isto não é possível numa mesma figura e nem adequado (subconjunto relevante

para uma determinada visão).

2.6.8 Diagramas de atividades

Diagramas de atividades são diagramas da UML que retratam o fluxo de

controle de uma atividade para a outra sendo portanto utilizados para a modelagem

de aspectos dinâmicos do sistema. Uma atividade é definida como uma execução

não-atômica em andamento em uma máquina de estados, que resulta em uma

mudança de estado do sistema ou o retorno de um valor (BOOCH; RUMBAUGH;

JACOBSON, 2006, p. 270). Exemplo deste diagrama é dado pela figura 26. Estes

diagramas são úteis para modelar membros operadores de uma classe.

FIGURA 26 - EXEMPLO DE DIAGRAMA DE ATIVIDADES

FONTE: O autor (2008)

NOTA: Captura de tela do Enterprise Arquitecture

2.6.9 Modelo de classes do domínio

Num sistema orientado a objetos, a funcionalidade externa é fornecida por

meio da colaboração entre objetos. Os participantes na operação do sistema

(atores) interagem com o sistema e visualizam resultados de cálculos, mensagens

recebidas, relatórios produzidos, entre outras atividades. Internamente os objetos do

sistema colaboram entre si para produzir os resultados visíveis. Esta colaboração

pode ser vista sob o aspecto estrutural estático e sob o aspecto dinâmico, onde a

construção de um serve para adicionar detalhes no outro. No primeiro caso, diz-se

estrutural pois a estrutura das classes de objetos e as relações entre elas são

representadas e diz-se estático, pois não leva em conta a interação dos objetos no

tempo. No segundo caso, diz-se dinâmico pois são representadas as interações

entre os objetos ao longo do tempo, por meio da troca de mensagens entre eles,

assim como as mudanças de estado destes objetos (BEZERRA, 2003, p. 95-96).

O modelo de classes de um sistema evolui durante as iterações do

desenvolvimento do sistemas. À medida que o desenvolvimento acontece, novos

detalhes podem ser incorporados ao modelo de classes. Bezerra (2003, p. 96) cita

três níveis sucessivos de abstração pelos quais o modelo passa:

a) o modelo de classes de domínio representa as classes no domínio do

negócio em questão e é construído na fase de análise e não leva em conta

restrições tecnológicas a serem utilizadas na solução de um problema.

b) o modelo de classes de especificação é uma extensão do nível de

domínio acrescentando-se detalhes específicos conforme a solução do software

escolhida e é construído ou aperfeiçoado nas iterações da atividade de projeto do

desenvolvimento.

c) o modelo de classes de implementação é uma extensão do modelo de

especificação e corresponde à implementação das classes em alguma linguagem de

programação. Este modelo é construído ou aperfeiçoado nas iterações da atividade

de implementação do desenvolvimento.

2.6.10 Visibilidade e acessibilidade

Classes e membros de uma classe podem ter modificadores de acesso que

indicam sua visibilidade e acessibilidade por parte de outras classes e objetos,

permitindo que se possa ocultar classes e membros que não necessitem ser

públicos e de oferecer membros que poderão ser vistos e utilizados externamente ao

objeto. Esta técnica aplicada a membros do tipo atributo é conhecida como

encapsulamento de dados (DEITEL; DEITEL, 2003, p. 418). São exemplos destes

modificadores: public, protected e private. O primeiro declara que o membro estará

acessível em qualquer lugar em que a classe estiver acessível; o segundo

estabelece que o membro estará acessível a todas as classes dentro do pacote mas

também às subclasses derivadas da classe em questão, mesmo que definidas em

outro pacote; o terceiro define acessibilidade restrita somente dentro da classe em

questão.

2.6.11 Relacionamentos, navegabilidade e multiplicidade

Um relacionamento é uma conexão entre classes. Outra questão importante

diz respeito a navegabilidade entre objetos, ou a definição de como um objeto pode

obter acesso a outro objeto. O sentido desta navegabilidade é que determina a

dependência de um objeto em relação a outro ou a prioridade na sequência de

construção dos objetos. A navegabilidade pode ser: unidirecional, bidirecional ou

não especificada. No relacionamento entre classes, objetos de uma classe podem

se associar com uma certa quantidade de objetos de uma outra classe ou a objetos

da própria classe (auto-relacionamento ou reflexiva). Esta quantidade é definida

como multiplicidade e cada associação entre objetos possui duas multiplicidades,

uma em cada extremo da linha de associação. A multiplicidade define o número de

instâncias que uma classe pode ter (BOOCH; RUMBAUGH; JACOBSON, 2006, p.

129). A figura 27 exemplifica alguns tipos de multiplicidade.

Nome Simbologia

Apenas um 1

Zero ou muitos 0..*

Um ou muitos 1..*

Zero ou um 0..1

Intervalo específico li..ls

FIGURA 27 - TIPOS DE MULTIPLICIDADE

FONTE: BEZERRA (2003)

2.6.12 Associação, agregação e composição

Segundo Booch, Rumbaugh e Jacobson (2006, p. 146-150), uma

associação é um relacionamento estrutural, informando que objetos de uma classe

se relacionam com objetos de outra classe (fig. 28). Esta conexão entre classes

pressupõe algumas informações adicionais à associação em si: um nome, o papel

em cada extremidade da associação, direção de navegação e a agregação. A

agregação simples (fig. 28a) possibilita associar e diferenciar o “todo” da “parte” não

modificando o significado da navegação e sem vincular o tempo de vida do todo e

suas partes.

Outra forma de agregação é a composição, que adiciona semântica

importante, com propriedade bem-definida. A agregação por composição é aquela

quando o tempo de vida do todo é igual ao tempo das partes, sendo assim

considerada uma relação “forte” (fig. 28b). A destruição do todo se propaga para as

partes. Em contrapartida, a agregação simples se apresenta quando os tempos de

vida podem ser diferentes entre a classe “todo” e as classes “partes”, sendo assim

considerada uma relação mais “fraca” que a agregação por composição.

FIGURA 28 - TIPOS DE ASSOCIAÇÕES: (a) SIMPLES; (b) POR COMPOSIÇÃO

FONTE: BEZERRA (2003, p. 104, 179)

2.6.13 Heranças, subclasses e superclasse

A classe estendida é dita superclasse e a extensão é conhecida como

subclasse. A subclasse portanto é uma especialização da superclasse. A

superclasse é portanto uma generalização da subclasse. A subclasse herda os

membros da superclasse e pode sobrescrever métodos herdados ou declarar novos

membros. Este mecanismo é chamado de herança (FLANAGAN, 2006, p. 122-125,

149). Diz-se que ocorre uma generalização (fig. 29) quando uma classe pode ser

utilizada como “modelo” para outras classes mais especializadas ou derivadas.

FIGURA 29 - EXEMPLO DE GENERALIZAÇÃO

FONTE: O autor (2008)

Assim, as classes “filhas” desta generalização herdam membros (atributos e

métodos) da classe “mãe”.

2.7 CARACTERÍSTICAS DA LINGUAGEM DE PROGRAMAÇÃO JAVA

Segundo Flanagan (2006, p. 28-30), Java é uma linguagem de programação

de propósito geral e fortemente associada a visão de orientação a objetos. Ela é

voltada para múltiplas plataformas de equipamentos possibilitando portabilidade e

para diferentes tipos de aplicações, como aplicação web para utilização com

navegadores Internet (browsers), aplicações desktop para utilização isolada em

computadores pessoais e aplicações em equipamentos portáteis como celulares e

PDAs (Personal Digital Assistants). Para cada plataforma, uma arquitetura de CPU

chamada JVM (Java Virtual Machine) deve estar previamente instalada para

possibilitar a compilação do programa Java numa sequência de código intermediário

chamado bytecodes. Este código é então interpretado e executado. Esta execução é

apoiada por um conjunto predefinido e extenso de classes que formam o que é

conhecido como plataforma Java ou “core Java APIs” (Application Programming

Interfaces). Para escrever programas em Java é preciso obter o JDK (Java

Development Kit) que contém as ferramentas básicas para o desenvolvimento. Este

produto não deve ser confundido com o JRE (Java Runtime Environment) que é o

ambiente disponibilizado para a simples execução dos programas Java. A literatura

nesta área é extensa e para a implementação do protótipo desta pesquisa foram

revisados partes dos textos dos trabalhos de Deitel e Deitel (2003), Flanagan (2006)

e Horstmann (2005). Entre as principais características da plataforma e linguagem

Java, algumas foram revistas para o emprego no desenvolvimento do protótipo

desta pesquisa.

Para a realização da leitura de arquivos sequenciais são utilizados os

métodos FileInputStream, BufferedReader e readLine. Para a gravação de arquivos

sequenciais é possível utilizar os métodos FileOutputStream, PrintWriter e println.

Exemplo de uso destes comandos pode ser visto no apêndice 1.

O método de recursão ou recursivo é uma técnica poderosa para

transformar problemas computacionais complexos em problemas mais simples

(HORSTMANN, 2005, p. 619). O método recursivo é um método que chama a si

próprio diretamente ou indiretamente, por meio de outro método, de forma que cada

chamada recursiva simplifica de alguma forma o problema original, até que, por

convergência, o método identifica o caso mais básico, resolve-o e retorna a solução

para ser utilizada na solução da chamada anterior e assim por diante (DEITEL;

DEITEL, 2003, p. 286). Tanto o método de recursão como o de iteração se baseiam

em uma estrutura de controle, envolvem repetição e um teste de terminação. No

entanto, uma solução recursiva é mais fácil de entender e implementar corretamente

do que uma solução iterativa, embora a primeira possa ter uma performance

levemente mais lenta (HORSTMANN, 2005, p. 643). Um exemplo de estrutura de

recursão pode ser encontrado no apêndice 1.

Outra característica muito útil para armazenamento de uma coleção de itens

em memória e explorada neste trabalho é a classe List. Uma List é uma coleção

ordenada de objetos. Cada elemento de uma lista tem uma posição nessa lista. Ela

define os métodos para ler e gravar itens de coleção, respectivamente get() e set()

baseados em índice, assim como métodos para adicionar e remover um elemento

com índice em particular, respectivamente add(i, item) e remove(i), com i sendo o

índice ordenado da coleção e item o objeto a ser adicionado à lista (FLANAGAN,

2006, p. 220). A figura 30 exemplifica a definição de três listas: lista de canais, de

pontos e de trechos de canais. A linguagem Java permite a definição de listas

“fortemente tipadas” como no exemplo citado. Este recurso é obtido acrescentando-

se um sufixo chamado “marcador de lugar” após o tipo de variável; no primeiro

exemplo da figura 30, “<Canal>” após o tipo “List”. Este recurso permite que se

restrinja a possibilidade de acidentalmente se adicionar outro tipo de objeto, que não

seja da classe definida, à lista em questão, no caso Canal. Este recurso é

denominado de genérico (generics).

FIGURA 30 - EXEMPLOS DE DEFINIÇÕES DE LISTAS

FONTE: O autor (2008)

Para a construção de rotinas de visualização gráfica de formas

bidimensionais, a linguagem Java dispõe de uma biblioteca extensa de métodos. O

List<Canal> canais;

List<Ponto> pontos = new ArrayList<Ponto>();

List<TrechoDeCanal> trechos = new ArrayList<TrechoDeCanal>();

sistema de coordenadas padrão desta biblioteca tem sua origem no canto superior

esquerdo da região definida para o desenho, com a coordenada x sendo a distância

horizontal para a direita e a coordenada y a distância vertical para baixo. As

unidades de coordenadas são medidas em pixels. O pixel é a menor unidade de

resolução do monitor de vídeo (DEITEL; DEITEL, 2003, p. 564-566). A figura 31

ilustra uma utilização desta biblioteca.

FIGURA 31 - EXEMPLO DE UTILIZAÇÃO DE MÉTODOS GRÁFICOS DA BIBLIOTECA AWT

FONTE: O autor (2008)

De acordo com a figura 31, uma sequência de linhas definidas por pontos

pode ser desenhada por meio de métodos como moveTo(xi, yi) para posicionamento

e lineTo(xj, yj) para desenho da linhas entre as últimas coordenadas e as atuais (xj,

yj). Estes métodos normalmente utilizam um objeto da classe GeneralPath, o qual é

passado como parâmetro para o método draw(). Este método, por sua vez, faz parte

da API Java 2D e necessita um suporte de contexto gráfico da classe Graphics2D

que é uma subclasse da classe Graphics. Toda a rotina de desenho gráfico

normalmente é chamada por meio da ocorrência de um evento, como por exemplo,

quando da ocorrência da exibição, translação ou alteração de tamanho do

componente. Por ocasião do evento, uma chamada é realizada ao método paint()

que deve ser sobrescrito com a rotina de tratamento codificada pelo programador.

public void paint(Graphics g) {

super.paint(g);

g2 = (Graphics2D) g;

GeneralPath drawingPath = new GeneralPath();

drawingPath.moveTo(100, 100);

drawingPath.lineTo(110,105);

drawingPath.lineTo(150,120);

drawingPath.lineTo(130,80);

g2.setColor(Color.BLUE);

g2.setStroke(new BasicStroke(2.0f));

g2.draw(drawingPath);

}

A biblioteca Swing, integrante da plataforma Java, oferece componentes

para utilização na construção de interfaces gráficas em programas Java, como

caixas de diálogo, seleção de arquivos, botões, barras de ferramentas, entre outros.

A tabela 3 apresenta uma descrição breve de alguns componentes desta biblioteca.

TABELA 3 - COMPONENTES PRINCIPAIS DA BIBLIOTECA SWING

Componente Descrição

JDialog Classe para construir janela de diálogo

JFileChooser Classe para diálogo de escolha de arquivos

JFrame

Classe para criar uma janela com barra de título e

botões para minimizar, maximizar e fechar a janela

JOptionPane

Classe para criar caixas de diálogos predefinidas que

permitem exibição de mensagens em geral

UIManager

Classe para manter as informações sobre aparência

e comportamento

JToolBar Classe para definir região que receberá botões

JLabel

Área em que podem ser exibidos texto não-editável

ou ícones

JButton

Classe para criar botão que aciona um evento

quando o objeto recebe um clique do mouse

FONTE: DEITEL e DEITEL (2003)

3 MATERIAL E MÉTODOS

Neste trabalho foram utilizados arquivos de dados, em formato texto, alguns

com disposição dos registros própria ao software de onde foram produzidos e outros

arquivos complementares definidos pelo autor do trabalho. Estes arquivos de dados

definem uma rede de drenagem por meio de um grupo de registros de pontos,

formando estruturas básicas de polilinhas e sem conferir caráter topológico à rede

de drenagem. A quantidade e disposição destas polilinhas variam segundo alguns

fatores como o processo de captura utilizado, a experiência do operador no

processo de digitalização ou o algoritmo empregado no processo de extração e

vetorização. Como as redes de drenagem utilizadas nos experimentos são de

pequeno porte, com o número de nós abaixo de 100, é possível que uma variação

da quantidade e disposição das polilinhas não fôsse influenciar significativamente a

performance do algoritmo de determinação das confluências pelo método de

interseção de REMs.

Três redes de drenagem foram consideradas a partir destes arquivos, sendo

uma delas adotada para o preparo manual da simulação temporal em três épocas.

Alguns ambientes de software foram utilizados como ferramentas e, por serem de

uso comum, não foram detalhados neste trabalho. Uma metodologia foi proposta

para a construção do modelo de classes de objetos, por meio da UML, e para o

desenvolvimento do protótipo de software.

3.1 MATERIAL UTILIZADO

Os arquivos de dados de redes de drenagem cumpriram os seguintes

propósitos: (1) ganhar conhecimento de qual é a estrutura interna de

armazenamento da rede de drenagem, obtida pelos processos de digitalização e de

extração; (2) servir de entrada de dados para o protótipo desenvolvido; (3) ter

portabilidade entre o protótipo e o software ArcGIS

, para auxiliar em testes e na

verificação de valores calculados.

Das três redes de drenagem utilizadas, duas foram obtidas por meio de

digitalização de cartas topográficas e uma pelo processo de extração descrito no

apêndice 2. Para uma das redes, o arquivo de dados foi trabalhado manualmente

para simular dois outros levantamentos temporais distintos, obtendo-se três épocas

distintas.

Quatro ambientes de software foram empregados como ferramentas para

visualização, conversão, modelagem e prototipação. A metodologia desenvolvida

contemplou o processo de modelagem das classes de objetos em UML, que resultou

no modelo de classes de objetos para redes de drenagem, e o processo de

desenvolvimento do protótipo de software, no qual foi implementado o modelo.

3.1.1 Arquivos de dados

Inicialmente, procurou-se obter dados de redes de drenagem a partir de

cartas do IBGE. No entanto, algumas dificuldades surgiram ao analisar tais produtos:

(a) descontinuidade nas linhas representativas das redes de drenagem; (b)

densidades de linhas variáveis para a mesma rede hidrográfica, entre cartas

articuladas, provavelmente pelo emprego de diferentes metodologias em diferentes

épocas e por diferentes equipes de profissionais; (c) dados de altimetria separados

dos dados planimétricos.

Para a leitura de dados de redes de drenagem, dois tipos de arquivos são

utilizados: um que armazena os valores de área e perímetro da rede, obtidos pela

leitura no ArcGIS

e em disposição definida pelo autor do trabalho, e outro contendo

as polilinhas da rede de drenagem, num padrão que guarda uma relação direta com

o padrão aberto shapefile, cuja documentação pode ser encontrada em ESRI (1998).

Foi definida uma nomenclatura própria para os nomes de arquivos dos

experimentos. O primeiro tipo foi padronizado com o nome geral “rNNdados.txt” e ao

segundo tipo foi atribuído o nome geral “rNNTK.txt”, onde NN é o número de

identificação da rede de drenagem e K é o índice sequencial de tempo a que se

refere a rede de drenagem.

O primeiro tipo de arquivo contêm três registros: o primeiro expressa a área

da bacia de drenagem, definido como “area=NNNNN”; o segundo fornece o valor do

perímetro da bacia de drenagem, definido como “perimetro=NNNNN”, e o último

define o comprimento do eixo maior da bacia de drenagem, definido como

“lmax=NNNNN”. O valor “NNNNN” é um valor de ponto flutuante, com as unidades

, km e km respectivamente. A ordem de entrada destes registros no arquivo é

irrelevante. Nos experimentos, os valores obtidos para o arquivo foram obtidos de

leitura manual no ArcGIS

, para cada rede de drenagem.

Para o segundo tipo de arquivo, os dados originais dos experimentos foram

importados do formato DXF do ambiente AutoCAD e do formato shapefile, ambos

tratados no ambiente ArcGIS

e convertidos para arquivos de texto. Este tipo de

arquivo convertido foi analisado com o objetivo de entender a estrutura básica de

armazenamento dos dados e de estabelecer um processo de leitura compatível para

a construção das classes de objetos da rede de drenagem. O método de

armazenamento dos dados se faz por cadeias de segmentos de linhas com direção

e comprimento variáveis. Um exemplo deste tipo de arquivo pode ser visto na figura

32.

FIGURA 32 - EXEMPLO DE PARTE DE ARQUIVO DE DADOS DE REDE DE DRENAGEM

FONTE: O autor (2008)

O arquivo de dados apresenta basicamente quatro tipos de registros

diferentes, descritos a seguir. O primeiro tipo de registro é utilizado para declarar o

tipo de dados a que se refere o arquivo de dados. No caso, o primeiro registro

declara que seguem-se dados de uma ou mais polilinhas, por meio da expressão

“Polyline”. O segundo tipo de registro contêm duas colunas numéricas separadas

por um espaço em branco, declarando a identificação da polilinha e do trecho parcial

da polilinha, quando esta for segmentada com trechos de ressurgência. Esta

segunda coluna não é tratada neste trabalho, tendo em vista a premissa de que

canais com ressurgências não são considerados. O terceiro tipo de registro informa

um ponto da polilinha contendo a identificação sequencial do ponto na polilinha,

iniciando-se em zero, e as coordenadas x, y e z em formato de ponto flutuante,

separadas por um espaço em branco. As unidades das coordenadas estão em

metros. Adicionalmente, uma quinta coluna pode descrever um valor numérico

associado ao ponto e na semântica definida pelo pesquisador. Quando não

empregada, a expressão “#QNAN” é utilizada por padrão. Finalmente, o quarto tipo

de registro informa o término do arquivo, mediante o emprego da expressão “END”.

3.1.2 Redes de drenagem

A primeira rede, digitalizada a partir de carta topográfica, foi a referência

para o desenvolvimento do modelo e do protótipo. Ela também serviu para os

experimentos temporais, uma vez que dela se originaram outros dois conjuntos de

dados simulados, perfazendo-se assim três levantamentos de tempos distintos. Esta

rede está localizada no estado do Paraná, no município de Guaraqueçaba, entre as

coordenadas (25º 05' S, 48º 22' W) e (25º 06' S, 48º 20' W) (fig. 33).

(a)

(b)

FIGURA 33 - LOCALIZAÇÃO (a) E BACIA HIDROGRÁFICA (b) DA REDE DE DRENAGEM Nº 1

FONTE: Wikipédia (2008) (a); o autor (2008) (b)

A segunda rede de drenagem utilizada também foi obtida por digitalização

de carta topográfica. Esta rede está localizada no estado do Rio de Janeiro, no

município de Rio das Flores, entre as coordenadas (22º 10’ S, 43º 27’ W) e (22º 11’

S, 43º 26’ W) (fig. 34).

(a)

(b)

FIGURA 34 - LOCALIZAÇÃO (a) E BACIA HIDROGRÁFICA (b) DA REDE DE DRENAGEM Nº 2

FONTE: Wikipédia (2008) (a); o autor (2008) (b)

A terceira rede de drenagem foi obtida pelo processo de extração descrito

no apêndice 2, a partir de uma rede de 2.501 pontos altimétricos, proveniente de um

exemplo que acompanha o software ArcGIS

. Esta rede se localiza no sul do

condado de Hart, no estado do Kentucky, Estados Unidos, entre as

coordenadas ( 37º 11’ N, 85º 55’ W) e ( 37º 10’ N, 85º 54’ W) (fig. 35).

(a)

(b)

FIGURA 35 - LOCALIZAÇÃO (a) E BACIA HIDROGRÁFICA (b) DA REDE DE DRENAGEM Nº 3

FONTE: Wikipédia (2008) (a); o autor (2008) (b)

3.1.3 Ambientes de software

Este trabalho utilizou os seguintes ambientes: software para leitura,

visualização gráfica e conversão de dados ESRI ArcGIS

9.2, software para

construção de diagramas em UML Sparx Enterprise Architecture

6.5, o ambiente de

desenvolvimento de software SUN NetBeans

6.1 e o software Google Earth

para

visualização da rede de drenagem integrada com o relevo.

O software ESRI ArcGIS

9.2 é constituído por um família de softwares,

entre os quais o ArcMap

, utilizado neste trabalho para os seguintes propósitos: (1)

ferramenta para visualização, edição de polilinhas e conversões de dados; (2)

extração de redes de drenagem a partir de uma grade de pontos altimétricos,

utilizando as extensões do ArcToolbox “Spatial Analyst” e “3D Analyst Tools”; (3)

leitura e comprovação dos resultados obtidos.

O software Sparx Enterprise Architecture

6.5 oferece um ambiente gráfico

para o desenvolvimento de diagramas na notação UML, como os diagramas de

casos de uso, diagramas de classes de objetos e diagramas de atividades. Este

ambiente permite exportar as definições de classes e seus relacionamentos,

atributos e operadores codificadas para a linguagem Java.

O ambiente SUN NetBeans

6.1 foi utilizado para o desenvolvimento do

protótipo, codificado em linguagem Java. Neste protótipo foi implementado o modelo

de classes de objetos com os operadores necessários para a análise dos dados e

síntese da rede de drenagem. A visualização gráfica da rede de drenagem foi

produzida utilizando-se a biblioteca gráfica AWT. Os demais componentes da

interface gráfica foram desenvolvidos com auxílio da biblioteca Swing. Ambas as

bibliotecas são integrantes da plataforma Java.

Para ilustrar a integração das redes de drenagem dos experimentos ao

relevo das regiões consideradas, o software Google Earth

foi empregado. Para tal,

os dados da rede de drenagem foram exportados, mediante conversão pelo software

ArcMap

, para o formato nativo deste ambiente, Keyhole Markup Language ou KML.

A conversão do arquivo no ArcMap

é obtida por meio da função Data

Interoperability Tools da ferramenta ArcToolbox (arquivo destino em formato KML).

O trabalho desta pesquisa se desenvolveu a partir da utilização dos

ambientes citados neste item. A interconexão destes ambientes e o contexto de

utilização nas atividades desenvolvidas são abordados no item de metodologia.

3.2 METODOLOGIA

A metodologia da pesquisa foi conduzida segundo um fluxo de trabalho que

consistiu na determinação do escopo do modelo, estudo e preparação de dados,

modelagem do diagrama de classes de objetos, desenvolvimento do protótipo e

execução e análise dos experimentos. Uma adaptação da terminologia estudada foi

necessária para dar independência e maior proximidade com o tema.

3.2.1 Adaptação da terminologia

Foi visto que rede de drenagem de uma região geográfica define os

caminhos de escoamento de líquidos na superfície topográfica, de acordo com o

relevo da região (ROSIM; PELLEGRINO, 1999, p. 1), (PINTO et al., 1976, p. 36).

Como as redes de drenagem podem existir, mesmo que não haja temporariamente o

líquido para o escoamento superficial, os termos: nascente, foz, confluência, trecho

de curso d’água, curso d’água e rio (TEIXEIRA et al., 2007) foram adaptados. As

seguintes denominações são sugeridas e adotadas neste trabalho:

• nó nascente: nó que representa o surgimento do canal de drenagem;

• nó foz: nó final do canal de drenagem;

• nó de confluência: nó resultante da convergência de dois ou mais trechos

de canais;

• trecho de canal: sequência de segmentos interligados que conectam um

nó foz ao seu nó de confluência vizinho, ou que ligam sucessivos nós de

confluência, ou que ligam um nó de confluência e o nó nascente vizinho;

• canal de drenagem: sequência de trechos interligados que conectam um

nó nascente a um nó foz;

• rede de drenagem: conjunto de canais de drenagem que têm o mesmo

nó foz.

3.2.2 Fluxo geral do trabalho

O fluxo de trabalho se desenvolveu conforme ilustra a figura 36. O diagrama

da figura apresenta quatro blocos maiores que agrupam atividades afins:

modelagem de redes de drenagem, preparação de dados, desenvolvimento do

protótipo e execução dos experimentos.

FIGURA 36 - DIAGRAMA DE ATIVIDADES DO TRABALHO REALIZADO

FONTE: O autor (2008)

3.2.3 Determinação do escopo do modelo

Em função do objetivo geral deste trabalho, determinou-se o escopo da

modelagem de rede de drenagem a ser desenvolvida, definindo-se na terminologia

UML os atores e casos de uso deste escopo (fig. 37). Três atores foram

identificados: Usuário, AutoCAD e ArcGIS. O ator Usuário, por sua vez, pode ser

especializado no ator Pesquisador e no ator Gestor. Ambos utilizam o sistema como

ferramenta básica para empregar redes de drenagem, sob o ponto de vista

geométrico e topológico. Os atores AutoCAD e ArcGIS possibilitam o preparo e

conversão de dados por meio de procedimentos manuais indicados pelo ator

Usuário.

FIGURA 37 - DIAGRAMA DE CASO DE USO GERAL “REDE DE DRENAGEM”

FONTE: O autor (2008)

O diagrama da figura 37 contém dez casos de uso. Os três primeiros tratam

de operações manuais para obter arquivos de dados prontos para a geração de

redes de drenagem: “Digitalização de Cartas Topográficas”, “Extração e Vetorização

da Rede” e “Preparação de Dados”, No primeiro, o ator Usuário interage com o ator

AutoCAD para produzir arquivos de digitalização de cartas, que posteriormente

serão lidos pelo ator ArcGIS para continuação no preparo de dados. O segundo

caso de uso tem por escopo a extração e vetorização de uma rede de drenagem, a

partir de um arquivo de pontos altimétricos. Este caso de uso está descrito no

apêndice 2. O terceiro caso de uso tem por escopo a preparação dos dados, quando

o ator Usuário interage com o ator ArcGIS para definir uma sub-região geográfica,

filtrar elementos indesejáveis entre as feições, corrigir erros e posteriormente realizar

a conversão de dados para arquivos de textos, esta parte descrita no apêndice 3.

Estes casos de uso são chamados aqui de complementares e foram representados

no diagrama em tom verde claro.

Os casos de uso principais e que foram desenvolvidos no protótipo de

software neste trabalho encontram-se destacados em tom cinza-escuro. Eles são:

“Seleção de Dados”, “Geração de Rede de Drenagem” e “Consultas a Rede de

Drenagem”. O caso de uso “Seleção de dados” tem por escopo o tratamento de

escolha de arquivos para trabalho com uma rede de drenagem. O segundo caso de

uso principal tem por escopo a geração, propriamente dita, de objetos da rede de

drenagem. Este caso de uso foi dividido nos seguintes subcasos de uso: “Leitura de

Dados”, “Determinação da Topologia”, “Determinação métrica” e “Apresentação

Gráfica da Rede”, cada qual com seu escopo delimitado. O caso de uso “Consulta

de Valores da Rede” realiza a exploração dos objetos da rede instanciados pelo

caso de uso principal anterior, fornecendo valores numéricos e demais resultados da

topologia obtida. Esta separação dos casos de uso propiciou melhor definição das

etapas necessárias para a construção dos objetos da rede de drenagem,

respondendo à pergunta “o que será trabalhado?”.

3.2.4 Estudo e preparação dos dados

Na sequência da pesquisa estudou-se o processo de extração de redes de

drenagem a partir de um exemplo de uma grade de 2.501 pontos altimétricos, até a

vetorização final, com produção de saída em arquivo do tipo shapefile por meio da

utilização do software ArcGIS

(apêndice 2). Isto possibilitou melhorar o

conhecimento do processo e o formato padrão do arquivo de dados de saída,

auxiliando a análise e projeto do modelo de classes de objetos. Em seguida, por

operações de seleção e recorte (clipping) procurou-se identificar e isolar parte dos

dados num agrupamento de dados menor, com o intuito de eliminar polilinhas

espúrias e de ganhar maior controle sobre os dados.

A documentação sobre arquivos shapefile foi consultada para verificar a

estrutura interna do arquivo (ESRI, 1998). Alternativamente, foram também

estudados alguns arquivos produzidos por digitalização manual sobre cartas

topográficas. Na análise destes arquivos, algumas observações importantes

puderam ser registradas: (a) descontinuidade entre polilinhas que deveriam estar

encadeadas; (b) erros de junção nas extremidades das polilinhas; (c) polilinhas

digitalizadas duas ou mais vezes para um mesmo trecho da rede; (d) ocorrência de

polilinhas digitalizadas, ora no sentido a montante, ora a jusante da rede. Dois tipos

de erros comuns encontrados em polilinhas digitalizadas estão exemplificados na

figura 38. A fim de se evitar estes tipos de erros, softwares de CAD e de SIG, em

geral, possuem um recurso chamado snapping que, quando ativado, permite

conectar inequivocamente os segmentos em operações manuais, sem que haja

cruzamento ou pontas extras nas conexões. Estes erros e ocorrências foram

levantados quando da realização dos primeiros testes com o protótipo desenvolvido

e foram tratados por meio de edição no software ArcMap

FIGURA 38 - ERROS COMUNS ENCONTRADOS EM POLILINHAS DIGITALIZADAS

FONTE: O autor (2008)

Em seguida, estudaram-se formas de ler arquivos shapefile, para deles

iniciar a sequência de instanciação de objetos segundo o modelo de classes de

objetos proposto. Algumas possibilidades de leitura de arquivo do tipo shapefile

foram estudadas: (a) diretamente a partir de rotinas já existentes e codificadas em

linguagem JAVA (PEREIRA, 2001). No entanto, esta alternativa se mostrou

dispendiosa pela necessidade de manutenção e adaptações necessárias para

contemplar shapefiles modificados por sucessivas edições no ambiente ArcGIS

decorrentes de eliminação de erros de digitalização, supressão de ruídos de

polilinhas disjuntas, entre outras ocorrências. Três outras alternativas foram

estudadas: (b) fazer o carregamento dos arquivos shapefile para um banco de dados

espacial SQL/PostGIS (PEREIRA NETO, 2003 e MITCHELL, 2005) para a partir

dele, fazer a leitura pelo programa Java, mediante a utilização de comandos da

linguagem SQL (Structured Query Language). A grande vantagem desta alternativa

seria a abertura de outras possibilidades para a pesquisa, uma vez que a extensão

espacial deste banco permite a utilização de diversos operadores espaciais; (c)

utilizar um conjunto de funções da biblioteca “GeoTools” (ZEILHOFER et al., 2007),

(GEOTOOLS, 2007). Uma possível desvantagem se apresentou na complexidade

introduzida para o aprendizado desta biblioteca; (d) converter o arquivo shapefile

para arquivo em formato de texto a partir do software ArcGIS

. Esta última

alternativa foi a mais promissora, pois não desviou o foco da pesquisa e possibilitou

a busca por resultados de forma mais direta. A alternativa de conversão também se

mostrou mais universal, pela razão de se utilizar um arquivo comum, em formato de

texto, disposto num certo padrão, além de possibilitar o controle sobre os dados.

Esta conversão é apresentada no apêndice 3.

3.2.5 Construção do modelo de classes de objetos

Para a construção do modelo de classes, a análise iniciou-se com o estudo

das três principais classes propostas por Vieira (2004): Recobrimento,

AreaLevantamento e FenomenoTerrestre. A classe RedeDeDrenagem foi

desenvolvida, especializando-se a classe CorpoHidrico, derivada da classe

FenomenoTerrestre. Enumerou-se uma seleção de possíveis substantivos

referentes ao tema e uma análise de possíveis ligações semânticas entre eles,

considerando-se que redes de drenagem podem ser representadas por grafos

acíclicos em árvore. Desta seleção inicial, as primeiras classes começaram a ser

desenvolvidas, partindo-se de agrupamentos espaciais maiores para objetos

espacialmente menores. Paralelamente a este processo de criação investigou-se a

estrutura dos arquivos de dados produzidos nos processos de extração e captura de

redes de drenagem. Nesta investigação, a análise partiu de forma inversa, ou seja,

iniciando-se dos pontos ordenados das polilinhas para então examinar as polilinhas

individualmente e, em seguida, coletivamente.

Algumas interseções de polilinhas foram estudadas visualmente no editor do

ArcMap

e verificou-se a necessidade de criar novo ponto na polilinha que

recebesse a contribuição das demais polilinhas em cada interseção. Neste processo,

a polilinha receptora do novo ponto recebeu o nome de polilinha alvo. O ponto de

interseção recebeu a denominação de nó de confluência.

Como resultado das duas atividades de análise complementares, algumas

classes candidatas foram arroladas: RedeDeDrenagem, Canal, TrechoDeCanal, No,

Segmento e Ponto. A ideia inicial indicava para a seguinte ordem: rede de drenagem

é composta de canais, cada canal composto de trechos de canais, cada trecho de

canal composto por dois nós extremos e um conjunto de segmentos de retas e cada

segmento de reta formado por dois pontos topográficos. Constatou-se que, um

trecho de canal não era formado necessariamente por uma única polilinha, podendo

o trecho recair num dos seguintes casos: ser parte de uma polilinha, ser coincidente

com uma polilinha completa ou ainda ser formado por um grupo de polilinhas. Outra

dificuldade se relacionou com o fato de aparentemente não haver uma ordem ou lei

de formação das polilinhas com a distribuição da rede de drenagem. Cada polilinha,

por sua vez, já contemplava um conjunto ordenado de pontos, com sentido jusante

ou montante, dependendo de como foi realizado o processo construtivo. Evidenciou-

se também que a classe Segmento de certa forma não fornecia contribuição ao

modelo, por já haver sustentação destes nas próprias polilinhas e não representar,

topologicamente, relevância. A classe Segmento foi abandonada. Verificou-se que a

classe inicialmente denominada de Ponto neste trabalho não refletia a mesma

semântica adotada na classe Ponto do trabalho de Vieira (2004). Esta é mais geral,

podendo representar pontos espaciais não presentes na superfície topográfica,

enquanto aquela empregaria somente pontos topográficos, ou seja, pontos sobre a

superfície terrestre. Para esta distinção entre dois estados o autor daquele trabalho

adicionou um atributo booleano discriminador, de nome tipoTopografico. Para

aumentar a coesão, a classe Ponto deste trabalho foi então renomeada para

PontoTopografico e definida como uma subclasse da classe Ponto. A programação

que trata esta extensão é apresentada num dos itens do apêndice 1. Também ficou

evidenciado que um ponto topográfico não é necessariamente um nó, mas todo nó

está associado a um único ponto topográfico.

Comprovou-se pelo estudo a necessidade da criação dos nós de

confluência a partir das interseções entre polilinhas, adicionando-se o ponto assim

formado por este nó na lista de pontos da polilinha alvo. Como diferentes tipos de

nós surgiram, uma nova classe do tipo enumeração foi adicionada ao modelo e um

membro foi adicionado a classe No para permitir identificar o tipo de nó. Esta classe

recebeu o nome TipoDeNo.

Observa-se que as classes originais AreaLevantamento,

FenomenoTerrestre e Recobrimento possuem um atributo denominado

retanguloEnvolvente. Este atributo abriga o retângulo necessário para envolver cada

um dos objetos de cada classe e auxilia na determinação de possíveis interseções

com outros objetos, otimizando o esforço computacional desta determinação. Neste

trabalho, e de acordo com a revisão de literatura efetuada, este termo foi

denominado de retangulo envolvente mínimo ou simplesmente “REM”, mantendo o

significado original do termo. Assim, uma classe adicional de nome REM foi incluída

no modelo de classes. De forma análoga, a classe Polilinha também foi relacionada

com a classe REM e recebeu um novo operador de nome

REMsInterceptam(Polilinha polilinhaPara). Este operador tem a finalidade de indicar

se o REM do objeto polilinha em questão intercepta o REM da polilinha indicada pelo

parâmetro. Assim, esta classe REM passou a estar associada às quatro classes do

modelo: AreaLevantamento, FenomenoTerrestre, Recobrimento e Polilinha.

Com a rede de drenagem espacialmente caracterizada, a questão temporal

passou a ser a preocupação seguinte. Na classe Recobrimento, adicionou-se um

operador para possibilitar comparações de grandezas de um mesmo fenômeno

presente, em áreas de levantamento de instantes de tempos distintos. Como um

recobrimento é formado por duas ou mais áreas de levantamento, de instantes

diferentes para uma mesma região geográfica, a classe Recobrimento recebeu um

operador para comparações temporais, denominado variacaoDensidadeDrenagem()

que operando sobre diferentes instâncias da classe AreaLevantamento devolve

como resultado a variação da densidade de drenagem de diferentes épocas.

3.2.6 Desenvolvimento do protótipo de software

Para demonstrar o emprego efetivo do modelo de classes de objetos,

imaginou-se o desenvolvimento de um protótipo de software que implementasse o

modelo de classes e pudesse ler arquivos de dados, determinasse a topologia

necessária, visualizasse graficamente a rede instanciada e apresentasse resultados

numéricos de operadores que seriam confrontados com as leituras no ArcGIS

. Para

tal desenvolvimento, os seguintes passos foram seguidos:

1) definir os requisitos mínimos do protótipo de software, tendo em vista o

modelo de classes definido, o tipo de arquivo de dados de entrada, a

visualização gráfica requerida e os operadores a serem utilizados;

2) desenvolver o protótipo de software por meio de refinamentos

sucessivos, utilizando a linguagem Java e o ambiente de

desenvolvimento definido;

3) testar o protótipo de software para cada etapa de desenvolvimento,

adotando-se a rede de drenagem nº 1 como piloto;

4) modificar eventualmente tanto o software quanto o modelo de classes de

objetos em função das correções detectadas no passo anterior;

5) testar o protótipo para as duas outras redes consideradas.

O desenvolvimento do protótipo de software, que implementa o modelo de

classes de objetos, seguiu a metodologia de desenvolvimento por etapas de

refinamentos sucessivos: a cada final de etapa, testes eram realizados e novas

funcionalidades introduzidas sucessivamente. Para garantir independência e

desacoplamento de classes de naturezas diferentes na implementação do protótipo,

procurou-se separar em pacotes (packages) as classes diretamente envolvidas com

o modelo de redes de drenagem das demais classes auxiliares, tais como: classes

de leitura de arquivo de dados, de visualização da rede de drenagem e de

construção e gerenciamento da interface de visualização. Isto possivelmente

melhorou a robustez do modelo, frente a manutenção de um dos pacotes e numa

possível troca tecnológica futura. Neste processo iterativo de construção e na

execução de testes, o modelo inicialmente concebido foi alterado algumas vezes em

alguns detalhes, para melhoramentos sobre os membros das classes (atributos,

operadores e assinaturas dos parâmetros). Durante a consecução de testes, o

depurador de erros, oferecido pelo ambiente de desenvolvimento utilizado, se

provou de grande auxílio.

A construção dos objetos das classes do modelo de redes de drenagem, a

partir da execução do protótipo, segue um processo de construção “de baixo para

cima” (bottom-up). A partir das polilinhas de pontos lidas do arquivo de dados de

entrada, que não guardam relação topológica, determinam-se os nós nascentes e,

pela interseção das polilinhas, os nós de confluência.

Os passos utilizados para a construção dos objetos das classes do modelo

são os seguintes:

1) Com a seleção do arquivo de dados contendo as descrições das

polilinhas da rede de drenagem, uma leitura é realizada. Esta leitura faz

uma consistência prévia para verificar se o arquivo selecionado está no

formato padrão esperado. Um objeto da classe Recobrimento, um

objeto da classe AreaLevantamento e um objeto da classe

RedeDeDrenagem são instanciados. Nesta leitura, as polilinhas são

criadas já se estabelecendo os nós iniciais e finais de cada uma.

Associado a este arquivo, um outro arquivo contendo valores da área e

perímetro da rede é lido e os valores são atribuídos aos respectivos

membros do objeto da classe RedeDeDrenagem;

2) A partir da pasta onde o arquivo de dados é encontrado, verifica-se se a

rede de drenagem apresenta mais de uma área de levantamento

temporal para o mesmo recobrimento, pela busca de sucessivos

arquivos que representem a mesmo fenômeno terrestre em tempos

distintos. Para cada novo arquivo existente, dois objetos são

inicialmente instanciados: objeto da classe AreaLevantamento

associados ao objeto da classe Recobrimento e objeto de classe

RedeDeDrenagem em questão;

3) o processamento segue com um tratamento de simplificação dos

objetos da classe Polilinha procurando unir polilinhas que possuem nós

iniciais coincidentes com nós finais de outras polilinhas e eliminando

eventuais pontos de coordenadas redundantes;

4) como as polilinhas são construídas no sentido jusante, por premissa, os

nós iniciais das polilinhas que não se conectaram são associados a um

objeto da clase TipoNo instanciado como nó NASCENTE;

5) em seguida, o fluxo instancia os objetos da classe REM (Retângulo

Envolvente Mínimo) obtendo-se os atributos xmin, ymin, xmax e ymax

de cada objeto da classe Polilinha;

6) de posse dos objetos da classe REM, o próximo algoritmo determina as

interseções geométricas entre objetos polilinhas obtendo os objetos nós

que recebem um objeto da classe TipoNo instanciado como nó

CONFLUÊNCIA;

7) com os objetos de nós de confluências determinados, o objeto nó foz é

determinado e recebe um objeto da classe TipoNo instanciado como nó

FOZ;

8) com todos os objetos nós determinados, inicia-se o processo recursivo

de descoberta dos trechos de canais. Os objetos da classe

TrechoDeCanal são obtidos. A partir do nó foz, são determinados

sucessivamente os diversos trechos de canais e seus respectivos

comprimentos, empregando-se a capacidade da linguagem Java de

poder expressar o algoritmo de forma recursiva (apêndice 1). Cada

objeto desta classe pode ser uma combinação entre um nó nascente e

um nó de confluência vizinho, ou entre um nó nascente e um nó foz

vizinho, ou entre dois nós de confluências vizinhos ou ainda entre um nó

de confluência e um nó foz vizinho. Estes objetos possuem um

direcionamento determinado, por apresentar um nó inicial e um nó final

do trecho. Esta característica é importante, pois permite o

caminhamento iniciando-se num nó nascente, sem se deparar com uma

finalização em outro nó nascente. Nesta determinação, o comprimento

de cada trecho é calculado, tornando-se atributo do respectivo trecho;

9) com os objetos da classe TrechoDeCanal determinados, inicia-se o

processo de criação dos diversos objetos da classe Canal mediante a

utilização do operador determinaCanais(). Cada objeto da classe Canal

coleciona os objetos de trechos de canais, percorrendo-se

recursivamente todos os objetos a partir de cada objeto nó nascente.

Neste caminhamento, o cálculo do comprimento do canal e sua

declividade são calculados e tornam-se valores dos respectivos

atributos destes objetos. Com o conjunto de objetos da classe Canal

instanciados, operadores de rede como getCanalMaiorExtensao() e

getCanalMaiorDeclividade() podem ser utilizados;

10) em seguida, o objeto da classe RedeDeDrenagem inicia o processo

para determinação dos diversos canais. Neste caminhamento, o cálculo

de comprimento dos canais é efetuado por meio do operador

apropriado;

11) operadores do objeto da classe RedeDeDrenagem são chamados para

determinar o canal de maior comprimento e o canal de maior

declividade;

12) finalmente, se um histórico de levantamentos foi obtido, o operador

varDensidadeDrenagem() é chamado para obter as variações de

densidade entre os levantamentos temporais sucessivos;

13) a rede obtida é visualizada por meio de funções da biblioteca AWT.

4 RESULTADOS E DISCUSSÕES

O principal resultado obtido com este trabalho foi o modelo de classes de

objetos que expressa formalmente redes de drenagem e seus aspectos geométricos

e topológicos ao longo de uma série temporal (fig. 39). Por meio da UML, foi

possível desenvolver o modelo proposto, partindo-se de uma especialização da

subclasse CorpoHidrico da classe abstrata FenomenoTerrestre proposta por Vieira

(2004). Adicionalmente, foi desenvolvido um protótipo de software, em linguagem

Java, com o propósito de aplicar o modelo proposto, instanciando-se

ordenadamente os diversos objetos a partir da leitura de arquivos de pontos de

redes de drenagem. O protótipo foi estruturado numa arquitetura de classes de

objetos, organizadas em três pacotes distintos: de classes de interface gráfica, de

classes de leitura de arquivos e registros e de classes de rede de drenagem

propriamente dito. Com o desenvolvimento de operadores de classes previstos no

modelo, foi possível resolver topologicamente a construção da rede de drenagem,

demonstrar a utilidade das classes e de seus relacionamentos, apresentar

graficamente a rede de drenagem, e acompanhar a variabilidade espacial da rede de

drenagem, ao longo do tempo. Experimentos foram realizados com três redes de

drenagem e os resultados da instanciação dos objetos do modelo foram reunidos

junto à visualização da respectiva rede de drenagem. Os valores numéricos de

medidas destes resultados puderam ser comparados e confirmados com as leituras

obtidas das redes de drenagem no editor do ArcGIS

4.1 DIAGRAMA DE CLASSES DE OBJETOS DE REDE DE DRENAGEM

O diagrama de classes proposto (fig. 39) apresenta o conjunto de classes

que expressa conceitualmente redes de drenagem identificando as classes e seus

relacionamentos.

FIGURA 39 - MODELO DE CLASSES DE OBJETOS PROPOSTO

FONTE: O autor (2008)

As classes que foram utilizadas do trabalho de Vieira (2004) estão

representadas neste diagrama em tom verde claro, e as específicas de redes de

drenagem, desenvolvidas neste trabalho, em bege. Da classe CorpoHidrico, derivou-

se a classe RedeDeDrenagem e todas as demais classes relacionadas do modelo

de rede de drenagem. Este diagrama reúne os principais membros de cada classe

de objetos, tendo como escopo as características geométricas, topológicas e

temporais de redes de drenagem. Foram omitidas do diagrama as classes auxiliares

e que não se enquadram no escopo direto do projeto.

Pelo diagrama, observa-se que a classe Recobrimento possui uma coleção

de objetos da classe AreaLevantamento e esta por sua vez, se relaciona com uma

coleção de objetos da classe FenomenoTerrestre. A classe AreaLevantamento

define o membro instanteObservacao, que indexa no tempo e com a granularidade

no formato “DD/MM/AAAA” toda a coleção de objetos da classe FenomenoTerrestre

associados a um objeto da classe AreaLevantamento. Assim, a temporalidade no

modelo é obtida para todos os objetos de classes e seus descendentes, que venham

a especializar a classe FenomenoTerrestre. Resultados desta temporalidade são

apresentados adiante neste capítulo.

A classe RedeDeDrenagem é uma especialização da classe CorpoHidrico e

o modelo de redes de drenagem se desenvolve a partir da classe

RedeDeDrenagem. Na sequência de leitura do diagrama de classes, um objeto da

classe RedeDeDrenagem se relaciona com três coleções de objetos de classes

diferentes por meio de uma associação do tipo agregação: uma coleção de objetos

da classe Canal, uma coleção de objetos da classe Polilinha e uma coleção de

objetos da classe TrechoDeCanal.

Cada objeto da classe Canal, por sua vez, possui uma coleção de objetos

da classe TrechoDeCanal e uma associação com “n” objetos da classe No. Cada

objeto da classe TrechoDeCanal tem dois relacionamentos com objetos da classe

No, um para o nó inicial e outro para o nó final do trecho. Inversamente, cada objeto

da classe No pode fazer parte de alguns objetos da classe TrechoDeCanal. Estes

detalhes é que tornam a rede um grafo esparso orientado, com os trechos e nós

implementados na forma de uma lista de adjacência e possibilita realizar o

caminhamento ao longo dos trechos. Cada objeto da classe No possui um único

objeto associado da classe PontoTopografico, mas cada objeto da classe

PontoTopografico não tem necessariamente um objeto da classe No. A classe No

pode ser especializada em três outras classes denominadas NoNascente,

NoConfluente e NoFoz.

Um objeto da classe Polilinha tem uma coleção ordenada de objetos da

classe PontoTopografico e contêm uma coleção de objetos da classe No. Cada

objeto da classe Polilinha também possui um único objeto da classe REM

(Retângulo Envolvente Mínimo). Um objeto da classe RedeDeDrenagem está

preparado para tratar o ordenamento dos trechos de canais, por meio do operador

ordenaRede(TipoOrdenamento tipoOrdem). Em função do tipo de ordenamento, que

define o método aplicável, o operador realiza a classificação dos diversos trechos de

canais da rede de drenagem.

Em seguida, as principais classes do modelo obtido são apresentadas,

seguindo-se uma discussão sobre suas estruturas de atributos e operadores:

a) Classe Recobrimento: Um objeto desta classe tem por responsabilidade

manter as diversas associações com os objetos da classe

AreaLevantamento por meio de uma lista de objetos. Um objeto da

classe Recobrimento também se relaciona com um único objeto da

classe REM, o qual lhe confere o retângulo envolvente mínimo do

recobrimento. Como o modelo temporal de retratos sequencias captura o

fenômeno terrestre completo num instante de tempo, por meio de um

objeto da classe AreaLevantamento, a cronologia de uma sequência de

instantes é capturada por um conjunto de objetos desta classe. O objeto

que se associa a múltiplos objetos desta classe é o objeto da classe

Recobrimento. Logo, a classe Recobrimento é a classe mais indicada

para receber operadores temporais. Um operador temporal, que calcula

a variação da densidade de drenagem de uma rede de drenagem ao

longo de diversos levantamentos registrados no tempo, foi criado e

denominou-se “varDensidadeDrenagem()” (fig. 40).

FIGURA 40 - CLASSE Recobrimento

Fonte: VIEIRA (2004)

NOTA: Adaptado de VIEIRA (2004)

b) A classe AreaLevantamento fornece a estrutura que descreve os objetos

relativos às áreas de levantamento, referidas a uma região geográfica e

delimitada pelo objeto da classe REM, para um instante de observação

instanteObservacao, para uma certa escala escala e num certo sistema

de projeção. Os objetos da classe AreaLevantamento possuem uma lista

de objetos da classe FenomenoTerrestre associados ao objeto da classe

AreaLevantamento (fig. 41).

FIGURA 41 - CLASSE AreaLevantamento

Fonte: O autor (2008)

NOTA: Adaptado de VIEIRA (2004)

c) A classe FenomenoTerrestre é uma classe abstrata que fornece os

membros que descrevem um fenômeno terrestre de forma geral. A partir

dela, especializações em classes distintas devem ser realizadas para as

diversas classes de fenômenos em que o pesquisador tem interesse. É o

caso de corpos hídricos e redes de drenagem. Classes que herdam da

classe FenomenoTerrestre implementam os membros descritos por ela.

Objetos destas novas classes especializadas passam, por

consequência, a compor a lista de objetos do objeto da classe

AreaLevantamento (fig. 42).

FIGURA 42 - CLASSE FenomenoTerrestre

Fonte: VIEIRA (2004)

NOTA: Adaptado de VIEIRA (2004)

d) A classe RedeDeDrenagem é uma especialização da classe

CorpoHidrico e incorpora, além dos membros descritos por esta, novos

membros advindos da necessidade desta especialização (fig. 43).

FIGURA 43 - CLASSE RedeDeDrenagem

FONTE: O autor (2008)

e) A classe TrechoDeCanal forma uma associação “todo-parte” com a

classe RedeDeDrenagem e é responsável pela produção dos

ordenamentos para cada um dos três métodos vistos anteriormente (fig.

44).

FIGURA 44 - CLASSE TrechoDeCanal

FONTE: O autor (2008)

f) A classe Canal é responsável por estabelecer a lista de trechos de

canais compreendida entre o nó nascente e o nó foz da rede de

drenagem. Esta classe tem um operador que facilita a descoberta do

próximo trecho de canal de um determinado objeto da classe

TrechoDeCanal (fig. 45).

FIGURA 45 - CLASSE Canal

FONTE: O autor (2008)

4.2 O PROTÓTIPO DE SOFTWARE DESENVOLVIDO

Um protótipo em linguagem Java foi desenvolvido utilizando-se o ambiente

NetBeans

com o intuito de exercitar o modelo de classes, a partir de dados

provenientes de digitalização de cartas topográficas e de processo de extração de

redes de drenagem. Tomou-se como parte da preocupação no desenvolvimento a

separação em pacotes de classes conforme a natureza delas: objetos de entidades

da aplicação (cujo domínio é rede de drenagem), objetos de controle (manuseio e

leitura de arquivos) e objetos de fronteira (navegação e visualização). Esta

separação propiciou robustez ao protótipo quanto à manutenção e independência

entre as naturezas das classes. O desenvolvimento deste protótipo possibilitou

aperfeiçoar o modelo de classes inicialmente concebido, introduzindo-se correções

na especificação de atributos, nos operadores, nas assinaturas dos parâmetros dos

operadores e em relacionamentos das classes.

Um dos recursos fundamentais do protótipo foi possibilitar a determinação

da topologia da rede, a partir de polilinhas disjuntas. Conforme proposto na

metodologia descrita, logo após a leitura de todas as polilinhas de uma rede de

drenagem, o protótipo realiza uma simplificação de polilinhas, procurando unir

polilinhas disjuntas a partir da verificação da coincidência dos seus pontos extremos.

Em seguida, o protótipo determina os retângulos mínimos envolventes e procede

com as determinações dos nós de nascentes, confluências e foz. Finalmente, os

trechos de canais e os canais em si são determinados, obtendo-se a rede de

drenagem completa.

A interface gráfica do protótipo permitiu ativar e desativar seletivamente a

visualização gráfica de elementos da rede de drenagem, obtida pela instanciação

dos objetos do modelo. Ela também auxiliou na visualização temporal de uma

mesma rede em épocas de levantamentos distintas, utilizando-se de variáveis

visuais do tipo tamanho e valor de cor, associado ao tom de cor azul. Com outra

funcionalidade denominada “explorador de objetos”, foi possível verificar, na forma

de saída textual, a lista de objetos instanciados, seus valores métricos, como

comprimento e declividade de canais e de topologia, como a indicação da ordem dos

trechos de canais, obtidos ao longo dos canais da rede de drenagem. O protótipo

possibilitou a realização de testes práticos sobre os objetos das classes do modelo,

algumas vezes favorecendo melhorias no próprio modelo inicialmente criado. Os

valores obtidos pela execução dos operadores dos objetos das classes puderam ser

comparados e confirmados com a leitura direta nas cartas topográficas pelo

software ArcGIS

Um conjunto mínimo de requisitos foi estabelecido para o protótipo. Estes

requisitos foram:

1) interface gráfica para uso de componentes gráficos, como janelas,

botões, caixas de listas de itens, entre outros;

2) uso de janela de busca e seleção de arquivos de dados;

3) leitura de arquivos de dados, na forma de textos (ASCII);

4) interpretação e crítica de dados;

5) operadores de classes para geração da rede, incluindo determinação de

interseções e determinação de topologia;

6) um operador para exercitar a temporalidade do modelo;

7) um operador para implementar um método de ordenamento estudado;

8) explorador de objetos da rede;

9) desenhador de elementos 2D de rede de drenagem para uma rede de

drenagem com possibilidade de visualização seletiva destes elementos,

ou para até três redes provenientes do experimento de temporalidade.

O projeto foi dividido em três pacotes de classes (packages), com a

finalidade de agrupar funcionalidades semelhantes e de prover maior independência

entre elas. Os três pacotes receberam os nomes de: app, drenagem e layout (fig.

46). Desta forma, o pacote app reuniu as classes e métodos gerais da aplicação,

como operadores de manipulação de arquivos e leitura de registros. O pacote

drenagem contemplou as classes diretamente relacionadas ao modelo de rede de

drenagem. Finalmente, o pacote layout isolou as classes de montagem e tratamento

da interface gráfica.

FIGURA 46 - PACOTES (Packages) DAS CLASSES DO PROTÓTIPO

FONTE: O autor (2008)

Para a leitura dos arquivos de dados, alguns operadores específicos foram

desenvolvidos. Para a manipulação do arquivo, tratamento do tipo de registro e

leitura dos dados foram criados os operadores na classe Main:

lerPolilinhasDoArquivo(String inputFile), tratarRegistro(String registro),

getNovaPolilinha() e getPontoTopografico(). Para a obtenção dos valores de área,

perímetro e comprimento do eixo maior da bacia, foram desenvolvidos os

operadores na classe RedeDeDrenagem: getAreaDrenagem(),

getPerimetroDrenagem() e getEixoMaiorDrenagem(). Uma vez lido o arquivo e os

diversos objetos da rede de drenagem determinados, a rede é desenhada na janela

apropriada (fig. 47). Na janela principal, mais externa, existem dois botões na barra

horizontal superior. O primeiro botão, com o título “Selecionar...”, abre uma nova

janela, a mais interna na figura.

FIGURA 47 - JANELA PRINCIPAL E JANELA DA REDE DE DRENAGEM DO PROTÓTIPO

FONTE: O autor (2008)

Pressionando-se o botão “Ler arquivo da rede” desta janela, abre-se uma

janela de diálogo (fig. 48) para selecionar um novo conjunto de arquivos de uma

rede de drenagem. Navega-se então até a pasta de arquivos de dados, seleciona-se

um arquivo específico e pressiona-se o botão “Open” para iniciar a leitura dos dados.

FIGURA 48 - DIÁLOGO DE PROCURA DO ARQUIVO DE DADOS DE ENTRADA

FONTE: O autor (2008)

100

É possível ativar a visualização dos objetos da classe REM (Retângulos

Envolventes Mínimos) no protótipo. Para isso, na janela de visualização da rede de

drenagem, marca-se a caixa de seleção para visualização dos REMs dos trechos de

canais da rede de drenagem atualmente selecionada. O protótipo responde com

uma nova visualização, conforme a figura 49.

FIGURA 49 - RETÂNGULOS ENVOLVENTES MÍNIMOS DOS TRECHOS DE CANAIS

FONTE: O autor (2008)

A determinação da topologia da rede de drenagem, a partir de polilinhas

disjuntas, é uma das funcionalidades fundamentais do protótipo. O processo desta

determinação está detalhado na metodologia apresentada.

Outra funcionalidade possível é a de apresentar as curvas de níveis

juntamente com a visualização dos objetos da rede de drenagem produzidos. Por

meio do botão “Ler curvas de níveis”, o protótipo solicita, por meio de uma janela de

diálogo, o arquivo que contém as curvas de níveis para a leitura. Para se visualizar

as isolinhas lidas, marca-se a caixa de seleção respectiva (fig. 50).

101

FIGURA 50 - VISUALIZAÇÃO DA REDE E CURVAS DE NÍVEIS

FONTE: O autor (2008)

O segundo botão da janela principal (fig. 47), de título “Explorar...”, realiza

consulta sobre os objetos da rede de drenagem, apresentando os valores

geométricos e de topologia da rede de drenagem atualmente selecionada (fig. 51 e

52). Os resultados dos valores dos objetos para as redes de drenagem dos

experimentos foram obtidos por meio desta funcionalidade e foram transcritos nos

resultados obtidos deste trabalho.

102

FIGURA 51 - EXPLORADOR DOS MÉTODOS DOS OBJETOS DA REDE

FONTE: O autor (2008)

FIGURA 52 - ROLAGEM DA TELA DA FIGURA ANTERIOR

FONTE: O autor (2008)

103

4.3 EXPERIMENTOS E RESULTADOS

Foram realizados três experimentos tomando-se como entrada redes de

drenagem distintas: as duas primeiras provenientes de processos de digitalização

manual e a terceira por extração automatizada, a partir de um conjunto de pontos

altimétricos. Os dois primeiros arquivos de dados apresentaram dados de altimetria

e puderam testar os métodos que calculam declividades. Já o terceiro arquivo,

produzido pela vetorização do processo de extração de redes, não conteve dados de

altitudes e a geração de informações de declividades não pôde ser obtida.

Para os três experimentos, os nós nascentes são apresentados por círculos

em vermelho; os nós de confluência por círculos em magenta; o nó foz por um

círculo verde. Os trechos de canais são identificados com a toponíma formada pela

letra “T” concatenada com a numeração sequencial produzida na determinação dos

trechos pelo software. Para efeito de acompanhamento nas imagens com os

resultados das listas de valores obtidos, o número do nó nascente em vermelho de

cada canal coincide com o número do respectivo canal na lista de valores obtidos,

lembrando que cada canal inicia-se num nó nascente e termina no nó foz.

A tabela 4 apresenta o resumo dos resultados dos experimentos para as

principais características das redes de drenagem. Os valores e a lista de canais e

seus respectivos trechos foram obtidos após os diversos objetos da rede de

drenagem terem sidos instanciados, para um determinado arquivo de dados

utilizado, e foram capturados da janela de resultados criada pela utilização do botão

“Explorar...” da janela principal do protótipo. A visualização das redes de drenagem

obtidas está nas figuras 53, 54 e 55.

104

TABELA 4 - RESUMO DOS RESULTADOS DOS EXPERIMENTOS

Característica Rede de Drenagem

Número da rede 1 2 3

Escala aprox. 1:20.000 1:5.000 1:10.000

L Total (km) 25,56 3,61 11,06

L max. (km) 3,89 0,56 1,61

A (km

) 8,14 0,25 1,32

Dd (km/km2) 3,14 14,35 8,36

P (km) 18,741 3,568 8,108

0,46 0,80 0,51

0,29 0,25 0,25

Total de canais 23 19 33

Total de trechos 45 37 65

Total de nós 46 38 66

Declividade máxima (em %) 21,2 24,7 ND

FONTE: O autor (2008)

105

Para o conjunto de dados da rede de drenagem nº 1, o protótipo apresentou

a visualização ilustrada pela figura 53:

FIGURA 53 - REDE Nº 1 E SEUS ELEMENTOS VISUALIZADOS NO PROTÓTIPO

FONTE: O autor (2008)

Resultados produzidos pelo protótipo para a rede de drenagem nº 1:

Objetos da rede de drenagem instanciados:

Total de objetos da classe 'Polilinhas' = 23

Total de objetos da classe 'Nós' = 46

Total de objetos da classe 'Trechos de canais' = 45

Total de objetos da classe 'Canais' = 23

Nó de maior altitude = 2, H= 700,00m

Canal 1, L= 3374,69m, I= 18,37%

Trechos:T-1 T-2 T-3 T-4 T-5 T-6 T-7 T-8 T-9 T-10

Canal 2, L= 3500,72m, I= 19,71%

Trechos:T-11 T-2 T-3 T-4 T-5 T-6 T-7 T-8 T-9 T-10

Canal 3, L= 3533,36m, I= 19,53%

Trechos:T-12 T-13 T-3 T-4 T-5 T-6 T-7 T-8 T-9 T-10

Canal 4, L= 3427,84m, I= 20,13%

Trechos:T-14 T-13 T-3 T-4 T-5 T-6 T-7 T-8 T-9 T-10

Canal 5, L= 3461,67m, I= 17,91%

Trechos:T-15 T-16 T-4 T-5 T-6 T-7 T-8 T-9 T-10

106

Canal 6, L= 3435,10m, I= 17,18%

Trechos:T-17 T-16 T-4 T-5 T-6 T-7 T-8 T-9 T-10

Canal 7, L= 2535,11m, I= 15,38%

Trechos:T-18 T-5 T-6 T-7 T-8 T-9 T-10

Canal 8, L= 2741,48m, I= 14,23%

Trechos:T-19 T-6 T-7 T-8 T-9 T-10

Canal 9, L= 1830,19m, I= 10,38%

Trechos:T-20 T-21 T-7 T-8 T-9 T-10

Canal 10, L= 1001,31m, I= 14,98%

Trechos:T-22 T-10

Canal 11, L= 3613,18m, I= 13,56%

Trechos:T-23 T-24 T-25 T-26 T-27 T-9 T-10

Canal 12, L= 1836,18m, I= 21,24%

Trechos:T-28 T-27 T-9 T-10

Canal 13, L= 3753,14m, I= 15,72%

Trechos:T-29 T-24 T-25 T-26 T-27 T-9 T-10

Canal 14, L= 3841,56m, I= 15,36%

Trechos:T-30 T-25 T-26 T-27 T-9 T-10

Canal 15, L= 3009,73m, I= 16,95%

Trechos:T-31 T-26 T-27 T-9 T-10

Canal 16, L= 4190,12m, I= 15,27%

Trechos:T-32 T-33 T-34 T-35 T-36 T-37 T-8 T-9 T-10

Canal 17, L= 2392,37m, I= 12,12%

Trechos:T-38 T-37 T-8 T-9 T-10

Canal 18, L= 2746,49m, I= 13,47%

Trechos:T-39 T-36 T-37 T-8 T-9 T-10

Canal 19, L= 3037,12m, I= 12,18%

Trechos:T-40 T-35 T-36 T-37 T-8 T-9 T-10

Canal 20, L= 3920,51m, I= 17,60%

Trechos:T-41 T-42 T-34 T-35 T-36 T-37 T-8 T-9 T-10

Canal 21, L= 3992,50m, I= 17,28%

Trechos:T-43 T-42 T-34 T-35 T-36 T-37 T-8 T-9 T-10

107

Canal 22, L= 4072,85m, I= 14,49%

Trechos:T-44 T-33 T-34 T-35 T-36 T-37 T-8 T-9 T-10

Canal 23, L= 1905,36m, I= 15,75%

Trechos:T-45 T-21 T-7 T-8 T-9 T-10

Canal com maior número de trechos: 1. Quantidade = 10

Canal de maior extensão: 16. Comprimento = 4190,12m

Canal de maior declividade: 12. Declividade = 21,24%

Rede com extensão total = 25,56km

Área da bacia de drenagem = 8,14km2

Densidade de drenagem = 3,14km/km2

Perímetro da bacia de drenagem = 18,74km

Maior eixo da bacia de drenagem = 3,89km

Índice de Circularidade = 0,29

Fator de Forma = 0,46

108

A segunda rede de drenagem submetida ao protótipo também foi obtida por

digitalização de carta topográfica e é apresentada na figura 54.

FIGURA 54 - REDE Nº 2 E SEUS ELEMENTOS VISUALIZADOS NO PROTÓTIPO

FONTE: O autor (2008)

Resultados produzidos pelo protótipo para a rede de drenagem nº 2:

Objetos da rede de drenagem instanciados:

Total de objetos da classe 'Polilinhas' = 19

Total de objetos da classe 'Nós' = 38

Total de objetos da classe 'Trechos de canais' = 37

Total de objetos da classe 'Canais' = 19

Nó de maior altitude = 19, H= 650,54m

Canal 1, L= 672,13m, I= 12,88%

Trechos:T-1 T-2 T-3 T-4 T-5 T-6 T-7

Canal 2, L= 577,15m, I= 12,24%

Trechos:T-8 T-3 T-4 T-5 T-6 T-7

Canal 3, L= 506,52m, I= 11,79%

Trechos:T-9 T-4 T-5 T-6 T-7

Canal 4, L= 603,83m, I= 15,95%

Trechos:T-10 T-11 T-12 T-13 T-14 T-15 T-16 T-17 T-7

Canal 5, L= 580,34m, I= 23,38%

Trechos:T-18 T-19 T-16 T-17 T-7

109

Canal 6, L= 507,87m, I= 15,18%

Trechos:T-20 T-15 T-16 T-17 T-7

Canal 7, L= 494,86m, I= 16,17%

Trechos:T-21 T-14 T-15 T-16 T-17 T-7

Canal 8, L= 568,30m, I= 20,89%

Trechos:T-22 T-11 T-12 T-13 T-14 T-15 T-16 T-17 T-7

Canal 9, L= 513,47m, I= 17,64%

Trechos:T-23 T-12 T-13 T-14 T-15 T-16 T-17 T-7

Canal 10, L= 495,36m, I= 17,25%

Trechos:T-24 T-13 T-14 T-15 T-16 T-17 T-7

Canal 11, L= 669,37m, I= 19,36%

Trechos:T-25 T-26 T-27 T-6 T-7

Canal 12, L= 677,25m, I= 19,52%

Trechos:T-28 T-26 T-27 T-6 T-7

Canal 13, L= 711,92m, I= 15,11%

Trechos:T-29 T-30 T-31 T-27 T-6 T-7

Canal 14, L= 621,63m, I= 11,49%

Trechos:T-32 T-30 T-31 T-27 T-6 T-7

Canal 15, L= 627,35m, I= 7,07%

Trechos:T-33 T-2 T-3 T-4 T-5 T-6 T-7

Canal 16, L= 536,17m, I= 7,93%

Trechos:T-34 T-5 T-6 T-7

Canal 17, L= 502,40m, I= 7,00%

Trechos:T-35 T-31 T-27 T-6 T-7

Canal 18, L= 397,19m, I= 19,41%

Trechos:T-36 T-17 T-7

Canal 19, L= 562,89m, I= 24,71%

Trechos:T-37 T-19 T-16 T-17 T-7

Canal com maior número de trechos: 4. Quantidade = 9

Canal de maior extensão: 13. Comprimento = 711,92m

Canal de maior declividade: 19. Declividade = 24,71%

Rede com extensão total = 3,61km

Área da bacia de drenagem = 0,25km2

Densidade de drenagem = 14,35km/km2

Perímetro da bacia de drenagem = 3,57km

110

Maior eixo da bacia de drenagem = 0,56km

Índice de Circularidade = 0,25

Fator de Forma = 0,80

111

A terceira rede de drenagem dos experimentos é uma rede resultante do

processo de extração descrito no apêndice 2. No protótipo, a rede de drenagem Nº 3

foi visualizada conforme a figura 55.

FIGURA 55 - REDE Nº 3 E SEUS ELEMENTOS VISUALIZADOS NO PROTÓTIPO

FONTE: O autor (2008)

Resultados produzidos pelo protótipo para a rede de drenagem nº 3:

Objetos da rede de drenagem instanciados:

Total de objetos da classe 'Polilinhas' = 33

Total de objetos da classe 'Nós' = 66

Total de objetos da classe 'Trechos de canais' = 65

Total de objetos da classe 'Canais' = 33

Canal 1, L= 971,26m, I= 0,00%

Trechos:T-1 T-2 T-27 T-28 T-29

Canal 2, L= 1084,76m, I= 0,00%

Trechos:T-3 T-5 T-6 T-26 T-27 T-28 T-29

Canal 3, L= 1048,64m, I= 0,00%

Trechos:T-4 T-5 T-6 T-26 T-27 T-28 T-29

Canal 4, L= 929,26m, I= 0,00%

Trechos:T-7 T-2 T-27 T-28 T-29

Canal 5, L= 1142,04m, I= 0,00%

Trechos:T-8 T-11 T-6 T-26 T-27 T-28 T-29

112

Canal 6, L= 287,57m, I= 0,00%

Trechos:T-9 T-29

Canal 7, L= 975,79m, I= 0,00%

Trechos:T-10 T-11 T-6 T-26 T-27 T-28 T-29

Canal 8, L= 1424,88m, I= 0,00%

Trechos:T-12 T-14 T-15 T-24 T-25 T-26 T-27 T-28 T-29

Canal 9, L= 1430,68m, I= 0,00%

Trechos:T-13 T-14 T-15 T-24 T-25 T-26 T-27 T-28 T-29

Canal 10, L= 761,64m, I= 0,00%

Trechos:T-16 T-17 T-18 T-19 T-20 T-21 T-28 T-29

Canal 11, L= 455,66m, I= 0,00%

Trechos:T-22 T-21 T-28 T-29

Canal 12, L= 1144,15m, I= 0,00%

Trechos:T-23 T-24 T-25 T-26 T-27 T-28 T-29

Canal 13, L= 880,27m, I= 0,00%

Trechos:T-30 T-25 T-26 T-27 T-28 T-29

Canal 14, L= 683,13m, I= 0,00%

Trechos:T-31 T-18 T-19 T-20 T-21 T-28 T-29

Canal 15, L= 1340,07m, I= 0,00%

Trechos:T-32 T-15 T-24 T-25 T-26 T-27 T-28 T-29

Canal 16, L= 2473,27m, I= 0,00%

Trechos:T-33 T-45 T-46 T-47 T-48 T-49 T-50 T-51 T-56 T-57 T-58 T-17 T-18 T-19 T-

20 T-21 T-28 T-29

Canal 17, L= 1289,81m, I= 0,00%

Trechos:T-34 T-35 T-20 T-21 T-28 T-29

Canal 18, L= 1205,30m, I= 0,00%

Trechos:T-36 T-58 T-17 T-18 T-19 T-20 T-21 T-28 T-29

Canal 19, L= 1399,64m, I= 0,00%

Trechos:T-37 T-38 T-19 T-20 T-21 T-28 T-29

Canal 20, L= 1059,16m, I= 0,00%

Trechos:T-39 T-38 T-19 T-20 T-21 T-28 T-29

Canal 21, L= 2676,89m, I= 0,00%

113

Trechos:T-40 T-41 T-42 T-46 T-47 T-48 T-49 T-50 T-51 T-56 T-57 T-58 T-17 T-18 T-

19 T-20 T-21 T-28 T-29

Canal 22, L= 1187,56m, I= 0,00%

Trechos:T-43 T-57 T-58 T-17 T-18 T-19 T-20 T-21 T-28 T-29

Canal 23, L= 2211,67m, I= 0,00%

Trechos:T-44 T-45 T-46 T-47 T-48 T-49 T-50 T-51 T-56 T-57 T-58 T-17 T-18 T-19 T-

20 T-21 T-28 T-29

Canal 24, L= 2478,80m, I= 0,00%

Trechos:T-52 T-42 T-46 T-47 T-48 T-49 T-50 T-51 T-56 T-57 T-58 T-17 T-18 T-19 T-

20 T-21 T-28 T-29

Canal 25, L= 2587,35m, I= 0,00%

Trechos:T-53 T-41 T-42 T-46 T-47 T-48 T-49 T-50 T-51 T-56 T-57 T-58 T-17 T-18 T-

19 T-20 T-21 T-28 T-29

Canal 26, L= 1482,40m, I= 0,00%

Trechos:T-54 T-51 T-56 T-57 T-58 T-17 T-18 T-19 T-20 T-21 T-28 T-29

Canal 27, L= 1394,69m, I= 0,00%

Trechos:T-55 T-56 T-57 T-58 T-17 T-18 T-19 T-20 T-21 T-28 T-29

Canal 28, L= 1210,63m, I= 0,00%

Trechos:T-59 T-35 T-20 T-21 T-28 T-29

Canal 29, L= 1483,96m, I= 0,00%

Trechos:T-60 T-50 T-51 T-56 T-57 T-58 T-17 T-18 T-19 T-20 T-21 T-28 T-29

Canal 30, L= 1869,76m, I= 0,00%

Trechos:T-61 T-63 T-47 T-48 T-49 T-50 T-51 T-56 T-57 T-58 T-17 T-18 T-19 T-20 T-

21 T-28 T-29

Canal 31, L= 2083,01m, I= 0,00%

Trechos:T-62 T-63 T-47 T-48 T-49 T-50 T-51 T-56 T-57 T-58 T-17 T-18 T-19 T-20 T-

21 T-28 T-29

Canal 32, L= 1682,70m, I= 0,00%

Trechos:T-64 T-48 T-49 T-50 T-51 T-56 T-57 T-58 T-17 T-18 T-19 T-20 T-21 T-28 T-

Canal 33, L= 1710,58m, I= 0,00%

Trechos:T-65 T-49 T-50 T-51 T-56 T-57 T-58 T-17 T-18 T-19 T-20 T-21 T-28 T-29

Canal com maior número de trechos: 21. Quantidade = 19

Canal de maior extensão: 21. Comprimento = 2676,89m

Rede com extensão total = 11,06km

Área da bacia de drenagem = 1,32km2

114

Densidade de drenagem = 8,36km/km2

Perímetro da bacia de drenagem = 8,11km

Maior eixo da bacia de drenagem = 1,61km

Índice de Circularidade = 0,25

Fator de Forma = 0,51

As medidas lineares de uma amostra de canais obtidas pelo modelo

implementado no protótipo de software foram confrontadas com as leituras obtidas

TABELA 5 - LEITURAS OBTIDAS PARA A REDE DE DRENAGEM Nº 1

1 3.374,69 3.374,68 0,00

6 3.435,10 3.408,78 -0,77

10 1.001,31 1.001,10 -0,02

12 1.836,18 1.811,98 -1,32

14 3841,56 3.812,46 -0,76

16 4.190,12 4.152,23 -0,90

FONTE: O autor (2008)

115

TABELA 6 - LEITURAS OBTIDAS PARA A REDE DE DRENAGEM Nº 2

1 672,13 672,12 0,00

4 603,83 603,82 0,00

5 580,34 579,9 -0,08

14 621,63 620,73 -0,14

19 562,89 562,21 -0,12

FONTE: O autor (2008)

TABELA 7 - LEITURAS OBTIDAS PARA A REDE DE DRENAGEM Nº 3

1 971,26 971,23 0,00

12 1.144,15 1.144,14 0,00

21 2.676,89 2.675,5 -0,05

33 1.710,58 1.709,18 -0,08

28 1.210,63 1.209,52 -0,09

FONTE: O autor (2008)

116

O modelo proposto oferece suporte para o ordenamento de trechos de

canais, segundo os métodos de Strahler, Horton e Shreve. Este ordenamento é um

importante pré-requisito para atribuir e classificar graus de importância aos canais de

uma rede de drenagem. Por meio desta classificação, é possível realizar a

determinação do canal principal, sendo este um dos elementos indispensáveis para

a obtenção de outras características físicas de uma bacia hidrográfica.

Para ilustrar esta possibilidade de ordenamento no modelo, foi

implementado no protótipo o algoritmo do método de Strahler (fig. 20, equações 7 e

8, apêndice 1, item f), por meio de dois operadores definidos na classe

RedeDeDrenagem (fig. 43):

- inicializaTrechosPrimeiraOrdem (TipoOrdenamento tipoOrdem): tem por

responsabilidade definir os trechos de primeira ordem a partir dos nós nascentes da

rede de drenagem. Este operador pode ser comum a mais de um método de

ordenamento;

- ordenaTrechosSTRAHLER(): tem por finalidade determinar a ordem dos

demais trechos de canais até o nó foz, segundo o método de Strahler.

Embora este método não determine diretamente o canal principal de uma

rede de drenagem, este método foi o escolhido para implementação no protótipo,

por ser um dos métodos mais simples e por se tratar do método que é base para o

método de Horton, este último possibilitando a determinação do canal principal.

Os resultados encontrados do ordenamento, para as três redes dos

experimentos, estão ilustrados pelos numerais em negrito, na toponímia de cada

trecho de canal (fig. 56, 57 e 58).

117

FIGURA 56 - ORDENAMENTO DE STRAHLER PARA A REDE Nº 1

FONTE: O autor (2008)

FIGURA 57 - ORDENAMENTO DE STRAHLER PARA A REDE Nº 2

FONTE: O autor (2008)

118

FIGURA 58 - ORDENAMENTO DE STRAHLER PARA A REDE Nº 3

FONTE: O autor (2008)

Para a série temporal, utilizou-se os dados da rede de drenagem Nº 1 para

o tempo T1 e dois outros arquivos de dados simulados para os tempos T2 e T3. A

simulação trabalhou principalmente com os trechos próximos às nascentes dos

canais, simulando diferentes levantamentos para a mesma região geográfica. A

visualização da rede de drenagem nos três instantes pode ser visualizada segundo a

figura 59. Esta figura foi capturada da tela do protótipo, após pressionar o botão “Ler

Série Temporal”. O desenho gráfico desta cronologia de três instantes utilizou-se de

duas variáveis visuais: tamanho e valor de cor, associado a um tom de cor azul. O

tamanho maior e valor de cor mais claro representam o tempo T1, o tamanho e valor

de cor intermediários, o tempo T2, e o tamanho menor e valor de cor mais escuro, o

tempo T3. O operador temporal varDensidadeDrenagem(), definido na classe

Recobrimento (fig. 40), calculou a variação de densidade entre os instantes T2 e T1

e entre os instantes T3 e T2, apresentando valores decrescentes de densidade: 0,97

e 0,93, respectivamente. Parte do código de programação da classe Recobrimento

encontra-se no apêndice 1.

119

FIGURA 59 - SÉRIE TEMPORAL DE LEVANTAMENTOS PARA UMA MESMA REGIÃO

FONTE: O autor (2008)

120

Uma forma alternativa de visualização da rede de drenagem, de caráter

ilustrativo, pode ser vista nas figuras 60 a 65, onde os arquivos de redes de

drenagem foram convertidos para o formato KML e importados para o software

de topo e outra em perspectiva.

FIGURA 60 - REDE Nº 1 VISUALIZADA NO GOOGLE EARTH

(TOPO)

FONTE: O autor (2008)

FIGURA 61 - REDE Nº 1 VISUALIZADA NO GOOGLE EARTH

(PERSPECTIVA)

FONTE: O autor (2008)

121

FONTE: O autor (2008)

122

FONTE: O autor (2008)

123

4.4 DISCUSSÃO DO MODELO PROPOSTO

Partindo-se do princípio de que redes de drenagem podem ser modeladas

por um conjunto de classes de objetos, e que as primitivas gráficas ponto e linha

podem representá-las como grafos acíclicos, o modelo possibilitou formalizar redes

de drenagem como fenômenos terrestres, sob o ponto de vista da cartografia

topográfica. Por se tratar de um modelo que estende o modelo mais geral e temporal

de classes de objetos de fenômenos terrestres do trabalho de Vieira (2004), o

modelo de redes de drenagem proposto herdou associações com levantamentos em

instantes de tempo distintos, para um determinado recobrimento, possibilitando o

emprego de temporalidade.

A estrutura de classes de objetos do modelo proposto atendeu à

decomposição dos elementos de uma rede de drenagem, representando as

associações entre eles, algumas delas do tipo “todo-parte”. Os diversos membros de

classes abrigaram, segundo suas responsabilidades, as características de cada tipo

de elemento da rede e os operadores para obtenção de valores métricos, de

topologia, de ordenamento de trechos de canais e de temporalidade. O modelo foi

utilizado no protótipo de software desenvolvido, totalizando cerca de 3.500 linhas de

programação em Java. Com o recurso de uma função denominada “explorador de

objetos” no protótipo, foi possível verificar a instanciação dos objetos das classes do

modelo e dos relacionamentos de associações entre objetos de classes diferentes.

O modelo contemplou o tratamento do ordenamento de canais, por meio de

operadores inseridos na classe RedeDeDrenagem, possibilitando o ordenamento

segundo os três métodos clássicos de ordenamento estudados. Estes operadores

definidos foram: ordenaRede(TipoOrdenamento tipoOrdem),

inicializaTrechosPrimeiraOrdem (tipoOrdem), ordenaTrechosSTRAHLER(),

ordenaTrechosHORTON() e ordenaTrechosSHREVE(). No protótipo foi

implementado o método de ordenamento de Strahler, e resultados deste

ordenamento foram obtidos e visualizados para as três redes de drenagem.

124

5 CONCLUSÕES

O modelo espaço-temporal de classes de objetos proposto possibilitou

representar com sucesso a estrutura e comportamento de redes de drenagem e

seus elementos sob o ponto de vista da cartografia topográfica. O modelo foi

implementado por meio de um protótipo de software e permitiu atender às

expectativas quanto à decomposição e síntese de redes de drenagem, com base

nos resultados obtidos para as três redes de drenagem estudadas. O modelo

proposto em notação UML especializou parte do modelo de fenômenos terrestres

proposto por Vieira (2004), a partir das classes Recobrimento, AreaLevantamento,

FenomenoTerrestre e CorpoHidrico. O modelo assim integrado definiu as seguintes

classes principais:

• RedeDeDrenagem

• Canal

• TrechoDeCanal

• TipoOrdenamento

• No, NoNascente, NoConfluente, NoFoz

• PontoTopografico

• Polilinha

• REM

• TipoRede

• TipoFenomenoTerrestre

A classe Recobrimento ganhou neste trabalho a definição de um operador

temporal, denominado varDensidadeDrenagem(), com o intuito de demonstrar a

capacidade do modelo de acompanhar propriedades de redes de drenagem ao

longo do tempo. Em função de uma simulação de dois outros levantamentos em

épocas distintas, e por meio deste operador temporal, foi possível apresentar

resultados tratando variabilidades numa das propriedades físicas da rede de

drenagem, denominada “densidade de drenagem”, ao longo de uma série histórica.

A definição do modelo contemplou a previsão para o tratamento do

ordenamento de canais de drenagem por meio de atributos e métodos definidos nas

classes RedeDeDrenagem e TrechoDeCanal, segundo os três métodos clássicos:

de Strahler, de Horton e de Shreve. De forma análoga ao desenvolvimento do

125

método de Strahler, o protótipo de software poderia ser estendido para se

implementar o método de Horton, possibilitando a determinação dos canais

principais das redes de drenagem.

Com este modelo obtido, torna-se viável aplicá-lo em áreas como gestão de

recursos hídricos, em outorgas de recursos hídricos e em projetos de redes

fluviométricas. No primeiro caso, os sistemas de informação de gestão de recursos

hídricos requerem que as bacias hidrográficas sejam classificadas mediante uma

codificação especial, estabelecendo uma hierarquia entre bacias. Esta codificação

especial necessita que o curso d’água principal de cada bacia esteja definido e os

diversos trechos de cada bacia e seus nós iniciais e finais estejam numerados,

assim como conhecidos os comprimentos de cada trecho e as áreas de contribuição

respectivas. Com estes dados persistidos num banco de dados espacial e com um

conjunto de regras de negócio de gestão hídrica, é possível, por exemplo, a

realização de consultas para seleção de bacias a montante e jusante de um

determinado trecho, auxiliando na tomada de decisões sobre a divisão de unidades

de gestão. No segundo caso, o da gestão de outorgas de recursos hídricos, também

há necessidade de se manter uma base de dados espacial sobre canais e trechos

de canais para efetivar o controle de emissão de licenças para uso da água.

Associando-se os objetos caracterizados no modelo proposto de redes de

drenagem, com outros atributos como dados do usuário, localização espacial do

usuário, vazões consumidas e lançadas e concentração de lançamentos de

efluentes, é possível controlar a qualidade resultante da água em função do usuário.

Para o terceiro caso, o de projetos de redes fluviométricas, o modelo proposto pode

contribuir no estudo da distribuição dos trechos e confluências de uma rede de

drenagem, ambos elementos presentes no modelo proposto, para o planejamento

da instalação progressiva de estações de monitoramento da qualidade d’água.

Como recomendações para o aperfeiçoamento do modelo obtido, sugere-

se:

1) incluir tratamento para trechos de canais com margem dupla e outros

elementos com poligonais fechadas. Isto possibilitaria a representação

de feições mais complexas do que as representadas de forma

unidimensional;

126

2) incluir novos atributos e operadores para contemplar a determinação

das demais características físicas de uma rede de drenagem e sua

bacia hidrográfica;

3) incluir tratamento de generalização cartográfica.

Para o melhoramento do protótipo desenvolvido, destacam-se as seguintes

recomendações:

1) inserir os aspectos de visualização do protótipo no contexto de um

projeto cartográfico. Esta recomendação possibilitaria definir uma

linguagem cartográfica apropriada, aumentando a eficiência em termos

de comunicação cartográfica;

2) desenvolver filtros para correção de erros de digitalização e supressão

de dados expúrios, encontrados nos arquivos de entrada. Esta

funcionalidade possibilitaria diminuir a quantidade de intervenções

manuais sobre os dados;

3) desenvolver tratamento para possibilitar trabalhar com mais de uma

rede de drenagem para uma mesma área de levantamento. Esta

recomendação aumentaria a capacidade do protótipo para tratar

diversas redes, usualmente encontradas numa mesma área de

levantamento;

4) incluir rotinas de tratamentos de arquivos do tipo shapefile para

possibilitar este tipo de entrada padrão. O desenvolvimento deste item

possibilitaria que o protótipo operasse diretamente sobre este tipo de

arquivo, usualmente encontrado em ambiente SIG;

5) desenvolver operadores para reconhecimento de padrões de

distribuição espacial dos canais de redes de drenagem. O

desenvolvimento deste item poderia conferir ao protótipo recursos de

classificação de redes para emprego em outras ciências, como

Geologia;

127

6) desenvolver operadores para o cálculo de áreas e perímetros de

bacias e microbacias. O desenvolvimento deste item possibilitaria que

estes atributos fossem calculados pelo protótipo, sem a necessidade

de se recorrer a arquivo de dados externos;

7) desenvolver operadores para ordenamento de trechos de canais para

os métodos Horton e Shreve, em complementação aos operadores

implementados para o método de Strahler. O desenvolvimento deste

item possibilitaria melhorar a funcionalidade sobre ordenamentos,

contribuindo com a determinação do canal principal e auxiliando em

rotinas de classificação toponímica dos canais de drenagem;

8) estender o tratamento temporal para uma sequência de levantamentos

maiores que 3. A execução deste item possibilitaria a análise temporal

de redes de drenagem num maior número de eventos;

9) criar o modelo de Entidade-Relacionamento para possibilitar a

transformação de objetos do modelo de classes proposto para

entidades relacionais de um banco de dados geoespacial, como

componente para persistência destes objetos e aproveitamento da

funcionalidade de tratamento espacial oferecida por estes tipos de

bancos de dados.

Para facilitar e ampliar a aquisição de arquivos de dados de rede

hidrográfica contendo valores de altitudes no mesmo arquivo, provenientes do site

de Internet do IBGE, recomenda-se um estudo para realizar esta integração, de

forma a obter num só arquivo, dados planialtimétricos, e um estudo de como corrigir

as descontinuidades verificadas nas linhas de canais das redes hidrográficas.

Finalmente, sugere-se o desenvolvimento de pesquisa para comprovar a

possibilidade de extensão do modelo proposto, na utilização por outras disciplinas e

ciências, que tenham redes de drenagem como tema de seus estudos.

128

REFERÊNCIAS

AGÊNCIA NACIONAL DE ÁGUAS. Cadernos de Recursos Hídricos –

Aproveitamento do Potencial Hidráulico para Geração de Energia, 2007.

Disponível em < http://www.ana.gov.br/AcoesAdministrativas/RelatorioGestao

/_docs/Relatorio2006/portugues/index.html>. Acesso em: 10/01/2008.

BACIA HIDROGRÁFICA. In: AGÊNCIA NACIONAL DE ÁGUAS. Glossário de

Termos Hidrográficos. Brasília: 2006. 74p. Disponível em

<http://www.ana.gov.br/bibliotecavirtual/arquivos/Glossario%20de%20Termo__15-

09-06.pdf>. Acesso em: 21/03/2008.

BARRETO NETO, A. A.; SOUZA FILHO, C. R. Modelagem hidrológica utilizando

lógica Fuzzy, SIG e dados de Sensoriamento Remoto. In: Simpósio Brasileiro de

Sensoriamento Remoto, 13., 2007, Florianópolis. Anais XIII Simpósio Brasileiro de

Sensoriamento Remoto. Brasília: INPE, 2007, p. 3288

BEZERRA, E. Princípios de análise e projeto de sistemas com UML. Rio de

Janeiro: Campus, 2002. 286 p.

BONDY, J.A.; MURTY, U.S.R. Graph theory with aplications. Department of

Combinatorics and Optimization, University of Waterloo, Ontario, Canada: North

Holland, 1982. 264 p.

BOOCH, G.; RUMBAUGH, J.; JACOBSON, I. UML: Guia do usuário. Rio de

Janeiro: Campus, 2006. 474 p.

BRASIL. Lei Federal Nº 9433, de 08 de janeiro de 2007. Institui a Política Nacional

de Recursos Hídricos, cria o Sistema Nacional de Gerenciamento de Recursos

Hídricos. Diário Oficial [da] República Federativa do Brasil, Brasília, DF, 09 jan.

2007. Disponível em: <http://www.aneel.gov.br/cedoc/blei19979433.pdf>. Acesso

em: 12/12/2007.

CHEN, P. P. S. The entity-relationship model: towards a unified view of data. New

York: ACM Transactions on Database System, 1, 1976.

CROWLEY, R.G. Digital Cartography. New Jersey: Prentice Hall, 1992. 317 p.

129

DAVIS JUNIOR, C. A.; QUEIROZ, G. R. Algoritmos geométricos e relacionamentos

topológicos. Bancos de dados geográficos. Instituto Nacional de Pesquisas

Espaciais, 2005. 83 p.

DEITEL, H. M.; DEITEL, P. J. Java, como programar. 4 ed. Porto Alegre: Bookman,

2003. 1386 p.

DELAZARI, L. S. Extração automática de redes de drenagem a partir de

modelos digitais de terrenos. 155 f. Dissertação (Mestrado em Ciências

Geodésicas) – Setor de Ciências da Terra, Universidade Federal do Paraná,

Curitiba, 1996.

DIESTEL, R. Graph theory. New York: Spring-Verlag, 2005. Edição eletrônica.

Disponível em: <http://www.math.uni-hamburg.de/home/diestel/books/graph.theory/

GraphTheoryIII.counted.pdf>. Acesso em: 20/10/2007.

ESRI - ENVIRONMENTAL SYSTEMS RESEARCH INSTITUTE, INC. Shapefile

Technical Description, July, 1998.

FLANAGAN, D. Java: o guia essencial. 5. ed. Porto Alegre: Bookman, 2006.

1100 p.

FREELAN, S. Developing a quasi-temporal GIS for archival map data.

Washington: Western Washington University, 2003. 71 p.

GEOTOOLS. GeoTools users guide: How to read a shapefile. Disponível em:

<http://docs.codehaus.org/display/GEOTDOC/04+How+to+Read+a+Shapefile>.

Acesso em: 23/10/2007.

GONTIJO JUNIOR, W. C.; KOIDE, S. Projeto de redes fluviométricas utilizando o

método Sharp – Estudos de casos na bacia hidrográfica do Rio São Francisco. In:

XVII Simpósio Brasileiro de Recursos Hídricos, 2006, São Paulo. Anais XVII Simpósio

Brasileiro de Recursos Hídricos. São Paulo: 2006. Disponível em: <http://www.ana.

gov.br/AcoesAdministrativas/CDOC/ProducaoAcademica/Wilde%20Cardoso%20Gontijo

%20Junior/3_METODOS%20SHARP.pdf>. Acesso em 15/12/2007.

HOLTZ, A. C. T. Estudo de Cenários para 2020 - Avaliação dos Cenários

Prováveis para o PNRH - Síntese, Comentários e Recomendações: versão

Internet. Brasília: Agência Nacional de Águas, 2005. 20p.

Disponível em: <http://www.ana.gov.br/pnrh_novo/docs/Cenarios_PNRH_2020.pdf>.

Acesso em 13/01/2008.

130

HORSTMANN, C. Conceitos de computação com o essencial de Java. 3.ed.

Porto Alegre: Bookman, 2005. 780 p.

HOTT, M. C.; FURTADO, A. L. S.; RIBEIRO, C. A. A. S. Determinação automática

de parâmetros morfométricos de bacias hidrográficas no município de Campinas,

SP. In: Simpósio Brasileiro de Sensoriamento Remoto, 13., 2007, Florianópolis.

Anais XIII Simpósio Brasileiro de Sensoriamento Remoto. Brasília: INPE, 2007,

p. 3381-3388.

ICHOKU, C.; KARNIELI, A.; MEISELS, A.; CHOROWICZ, J. Detection of drainage

channel networks on digital satellite images. International Journal of Remote

Sensing, v. 17, n. 9, p. 1659–1678, jun 1996.

KEATES, J. S. Cartographic design and production,

Longman, London,

1. ed.,

1973, 240 p.

KÖSTERS, G.; PAGEL, B.; SIX, H. GeoOOA: object-oriented analysis for

geographical information systems. Germany: University of Hagen, 1996. 9 p.

LANGRAN, G.; CHRISMAN, N. R. A framework for temporal geographic information.

Cartographica, 25., 1988.

LANGRAN, G. Time in geographic information system. London: Taylor & Francis,

1992. 189 p.

LAURINI, R.; THOMPSON, D. Fundamentals of spatial information systems. The

APIC series n. 37, London: Academic Press. 1998.

LIMA, W. de P. Análise física da bacia hidrográfica. In: Introdução ao manejo de

bacias hidrográficas. São Paulo: USP - Departamento de Ciências Florestais,

1996. p. 55-76.

LISBOA FILHO, J.; IOCHPE, C. Um estudo sobre modelos conceituais de dados

para projeto de bancos de dados geográficos. Informática Pública, v. 1, n.2, 1999.

p. 67-90.

MAIDMENT, D. ArcGIS Hydro Data Model, Center for Research in Water

Resources, University of Texas at Austin, 2001. Disponível em:

<http://www.crwr.utexas.edu/giswr/hydro/data/DataModel/archydromodel.pdf>.

Acesso em: 12/09/2008.

131

McALLISTER, M. The computational geometry of hydrology data in geographic

information systems. Tese (Doctor of Philosophy Thesis) - The University of British

Columbia, Columbia, 1999.

METSKER, S. J. Padrões de projeto em Java. Porto Alegre, Bookman, 2004, 407

MITCHELL, T. Web mapping illustrated: using open source GIS toolkits. 1. ed.

USA: OReilly, 2005. 367 p.

NAVATHE, S. B. Evolution for data modeling for databases. Communications of

the ACM, v.35, n.9, p.112-123, 1992.

OBJECT MANAGEMENT GROUP, OMG Unified Modeling Language

Superstructure Specification. 2005. 732 p.

PEREIRA, L. D. Visualização de camadas de informação em ambiente internet.

Dissertação (Mestrado em Informática) – Setor de Ciências Exatas, Universidade

Federal do Paraná, Curitiba, 2001.

PEREIRA NETO, A. PostgreSQL: técnicas avançadas. 2 ed. São Paulo: Érica,

2003. 284 p.

PEUQUET, D. J. Time in GIS and geographical databases. In: LONGLEY, P.;

GOODCHILD, M.; MAGUIRE, D.; RHIND, D. (eds.) Geographical information

systems: principles and technical issues. 2. ed. New York: J. Wiley & Sons, v. 2,

1999. p. 91-103.

PINTO, N. L. de S.; HOLTZ, A. C. T.; MARTINS, J. A.; GOMIDE, F. L. S. Hidrologia

básica. São Paulo: Edgard Blucher, 1976. 279 p.

ROBINSON, A. H.; MORRISON, J. L.; MUEHRCKE, P. C.; KIMERLING, A. J.;

GUPTILL, S. C. Elements of cartography. Wiley, 6th ed., 1995, 674 p.

ROCHA, L. S. S.; MOURA, A. C. M.; FREITAS, C. R.; DUTRA, L. V.;, CARVALHO,

O.; FREITAS, C. DA C.; GUIMARÃES, R. J.; AMARAL, R. S.; DRUMOND, S.

Desenvolvimento de modelo de rede de drenagem como subsìdio na análise

espacial e distribuição da Esquistossomose no estado de Minas Gerais. In: XXIII

Congresso Brasileiro de Cartografia. Rio de Janeiro, Brasil, 2007, p. 32-36.

Disponível em: <http://www.dpi.inpe.br/geoschisto/publicacoes/XXIII-CBC-

Leonardo.pdf> . Acesso em: 21/05/2008.

132

ROSIM, S.; PELLEGRINO, S. Extração de rede de drenagem de imagem de radar

usando modelos digitais de terreno. GIS Brasil 99; 1999; 1; 1; 352; 358; GIS

Brasil 99; Salvador.

SOUZA, J. D. de. Modelo espaço-temporal em SIG para análise da qualidade da

água em uma bacia hidrográfica. 177 f. Dissertação (Mestrado em Ciências

Geodésicas) – Setor de Ciências da Terra, Universidade Federal do Paraná,

Curitiba, 2004.

SPARX SYSTEMS. Sparx systems enterprise architect user guide, 2006.

TEIXEIRA, A. A.; PRADO, A.; SILVA, M.A.; SCHERER-WARREN, M.; HAUSCHILD,

R. M.; SOUSA, F.; CAMPOS NETO, V. S. Topologia hídrica: uma proposta para

gestão de recursos hídricos utilizando sistema de informações geográficas. In:

SIMPÓSIO BRASILEIRO DE SENSORIAMENTO REMOTO, 13., Florianópolis.

Anais XIII Simpósio Brasileiro de Sensoriamento Remoto, Florianópolis: INPE,

2007, p. 3597-3605.

TONELLO, K. C. ; DIAS, H. C. T. ; SOUZA, A.L. ; RIBEIRO, C. A. A. S. ; LEITE, F. P.

Morfometria da bacia hidrográfica da Cachoeira das Pombas, Guanhães, MG.

Revista Árvore, v. 5, p. 849-857, 2006.

VIEIRA, A. J. B. Fenômenos terrestres como classes de objetos: um modelo

espaço-temporal. 113 f. Tese (Doutorado em Ciências Geodésicas) – Setor de

Ciências da Terra, Universidade Federal do Paraná, Curitiba, 2004.

WEIBEL, R.; HELLER, M. Digital terrain modelling. In: MAGUIRE, D. J.;

GOODCHILD, M. F.; RHIND, D. W. Geographical information systems: principles

and applications. New York: John Wiley and Sons, 1991.

WORBOYS, M. F. A model for spatio-temporal information. Proceedings: the 5

International Symposium on Spatial Data Handling, 2:602-611, 1992.

WORBOYS, M. F. GIS: a computing perspective. London: Taylor & Francis. 1995.

396 p.

YUAN, M.; MARK, D. M.; EGENHOFER, M.; PEUQUET, D. Extensions to

geographic representation. In: McMASTER , R. B.; USERY, E. L. (eds). A research

agenda for geographic information science, Florida: CRC Press, p. 129-156 ,

2004.

133

YUAN, M. Temporal GIS and spatio-temporal modeling. Department of

Geography, The University of Oklahoma, 1996. Disponível em

<http://www.ncgia.ucsb.edu/conf/SANTA_FE_CD-ROM/sf_papers/yuan_may/may.

html>. Acesso em 29/08/2006.

ZEILHOFER, P.; ARRAES NETO, P.; FONSECA, D. C.; LOPES, R. R. F. Um

componente de arquitetura orientada a objetos para subsidiar a concessão de

outorga de RH em um ambiente SIG. In: SIMPÓSIO BRASILEIRO DE

SENSORIAMENTO REMOTO, 13., 2007, Florianópolis. Anais XIII Simpósio

Brasileiro de Sensoriamento Remoto. INPE, 2007. p. 3615-3622.

134

APÊNDICES

APÊNDICE 1 - ALGUNS TRECHOS DE OPERADORES DESENVOLVIDOS PARA

O PROTÓTIPO..................................................................................135

APÊNDICE 2 - PROCESSO DE EXTRAÇÃO DE REDES DE DRENAGEM............140

APÊNDICE 3 - CONVERSÃO ENTRE FORMATOS DE ARQUIVOS DE DADOS...163

135

APÊNDICE 1 – ALGUNS TRECHOS DE OPERADORES DESENVOLVIDOS PARA

O PROTÓTIPO

Este apêndice reúne alguns exemplos de operadores ou trechos de

operadores de classes de objetos e fazem parte do protótipo de software

desenvolvido em linguagem Java.

a) Trecho da declaração da classe Ponto:

public class Ponto {

private Double x;

private Double y;

private Double z;

private Boolean tipoTopografico;

public Ponto(Double x, Double y, Double z, Boolean tipo) {

this.x = x;

this.y = y;

this.z = z;

this.tipoTopografico = tipo;

}

@SuppressWarnings("empty-statement")

public Ponto() {

;

}

:::::

}

b) Trecho da declaração da classe PontoTopografico, como subclasse da

classe Ponto e definindo três construtores:

public class PontoTopografico extends Ponto implements Cloneable {

private Integer id;

public PontoTopografico(Double x, Double y, Double z) {

super(x, y, z, true); // Atributo tipoTopografico na classe Ponto é sempre true

this.setId(ContadorID.addCt(ContadorID.POINT_ID));

}

public PontoTopografico(Integer id, Double x, Double y, Double z) {

super(x, y, z, true);

ContadorID.addCt(ContadorID.POINT_ID);

this.setId(id);

}

public PontoTopografico() {

this.setId(ContadorID.addCt(ContadorID.POINT_ID));

}

:::::

}

136

c) Verificação se os REMs de objetos da classe Polilinha se interceptam:

Este método retorna true se o REM do objeto da polilinha atual intercepta o

REM do objeto da polilinah polPara. Este operador foi adaptado de algoritmo

estudado (DAVIS JUNIOR; QUEIROZ, 2005, p. 49).

public boolean REMsInterceptam(Polilinha polPara) {

PontoTopografico a, b, c, d;

PontoTopografico p, q, p1, q1;

a = new PontoTopografico(); b = new PontoTopografico();

c = new PontoTopografico(); d = new PontoTopografico();

p = new PontoTopografico(); q = new PontoTopografico();

p1 = new PontoTopografico(); q1 = new PontoTopografico();

a.setX( this.getRem().getXMin() );

a.setY( this.getRem().getYMin() );

b.setX( this.getRem().getXMax() );

b.setY( this.getRem().getYMax() );

c.setX( polPara.getRem().getXMin() );

c.setY( polPara.getRem().getYMin() );

d.setX( polPara.getRem().getXMax() );

d.setY( polPara.getRem().getYMax() );

p.setX( Math.min(a.getX(), b.getX()) );

p.setY( Math.min(a.getY(), b.getY()) );

q.setX( Math.max(a.getX(), b.getX()) );

q.setY( Math.max(a.getY(), b.getY()) );

p1.setX( Math.min(c.getX(), d.getX()) );

p1.setY( Math.min(c.getY(), d.getY()) );

q1.setX( Math.max(c.getX(), d.getX()) );

q1.setY( Math.max(c.getY(), d.getY()) );

return ( (q.getX() >= p1.getX()) && (q1.getX() >= p.getX()) &&

(q.getY() >= p1.getY()) && (q1.getY() >= p.getY()) );

}

d) Obtenção dos diversos trechos de canais a partir de um nó inicial

nodeFrom:

O método getNextTrecho() percorre uma lista de trechos de canais a partir

de um nó inicial nodeFrom. Este método explora a possibilidade de recursão da

linguagem Java e o fato de que um trecho de canal é um item ordenado no sentido

do nó-de para o nó-para. Este exemplo do uso de recursão utiliza o método

getNextTrecho() da classe Canal, para se obter os diversos trechos do canal.

Enquanto o método getTrecho() consegue obter um próximo trecho de canal, este é

adicionado a lista de trechos do canal e o próprio método getNextTrecho() é

novamente chamado, passando-se agora o nó seguinte do trecho como o nó inicial

de busca do próximo trecho. O caso básico é reconhecido quando um próximo

trecho de canal não é mais obtido ( trecho == null ).

137

:::::::::::::::

public void getNextTrecho(No nodeFrom, List<TrechoDeCanal> trechos) {

TrechoDeCanal trecho = new TrechoDeCanal();

trecho = getTrecho(nodeFrom, trechos);

if (trecho == null) {

return;

}

this.addTrecho(trecho);

this.setComprimento(this.getComprimento() + trecho.getComprimento());

this.getNextTrecho(trecho.getNoPara(), trechos);

}

private TrechoDeCanal getTrecho(No nodeFrom, List<TrechoDeCanal> trechos) {

for (TrechoDeCanal trecho: trechos) {

if (trecho.getNoDe().equals(nodeFrom)) {

return trecho;

}

return null;

}

::::::::::::::

e) Trechos para leitura e gravação de arquivos sequenciais utilizados no

protótipo:

// LEITURA

String inputFile = “C:\\Drenagem\\Dados\\r01.txt”;

FileInputStream fis = new FileInputStream(inputFile);

BufferedReader br = new BufferedReader(new InputStreamReader(fis));

String rec = br.readLine();

while (rec != null) {

::::::::::::::::::

rec = br.readLine();

}

::::::::::::::::::

//GRAVAÇÃO

String outputFile = “C:\\Drenagem\\Dados\\Saida.txt”;

pw = new PrintWriter(new FileOutputStream(outputfile, false), false);

pw.println("Polilinha");

pw.close();

f) Ordenamento de trechos de canais pelo método de Strahler:

O ordenamento da rede de drenagem pelo método Strahler utiliza dois

operadores da classe RedeDeDrenagem. O primeiro a ser invocado é o

inicializaTrechosPrimeiraOrdem() que determina os trechos de primeira ordem a

partir dos nós nascentes. Em seguida, o operador ordenaTrechosSTRAHLER() é

chamado, para o ordenamento dos demais trechos da rede de drenagem.

138

private void inicializaTrechosPrimeiraOrdem(TipoOrdenamento tipoOrdem) {

List<Ordenamento> ords = new ArrayList<Ordenamento>();

Nos nos = new Nos();

nos.addNos(this.getAllNodes());

nos = nos.getNosPorTipo(TipoNo.NASCENTE);

List<TrechoDeCanal> trechos = this.getTrechos();

// Determine os trechos de 1a. ordem (independe do método de ordenamento)

for (int iNo=0; iNo<nos.size();iNo++) {

No nodeDe = nos.get(iNo);

for (TrechoDeCanal t: trechos) {

No noDe = t.getNoDe();

if (noDe.getId() == nodeDe.getId()) {

t.setOrdemDoTrechoByTipo(tipoOrdem, 1);

}

private void ordenaTrechosSTRAHLER() {

Nos nos = new Nos();

nos.addNos(this.getAllNodes());

nos = nos.getNosPorTipo(TipoNo.CONFLUENTE);

Boolean ficouPendente = true;

while (ficouPendente) {

ficouPendente = false;

for (int iNo=0; iNo<nos.size();iNo++) {

No nodePara = nos.get(iNo);

List<Integer> ordensConfluencia = new ArrayList<Integer>();

List<TrechoDeCanal> trechosConfluentes = this.getTrechosMontanteByNo(nodePara);

for (TrechoDeCanal trecho: trechosConfluentes) {

Integer ordem = trecho.getOrdemDoTrechoByTipo(TipoOrdenamento.STRAHLER);

if (ordem == 0) {

ficouPendente = true;

break; //Abandone esta confluencia

}

ordensConfluencia.add(ordem);

}

if ((ordensConfluencia.size() == trechosConfluentes.size()) &&

(ordensConfluencia.size() > 1)) {

Boolean difere = true;

Integer ordemMax = ordensConfluencia.get(0);

for (int i=1; i<ordensConfluencia.size();i++) {

difere = (ordensConfluencia.get(i) != ordensConfluencia.get(i-1));

ordemMax = Math.max(ordemMax, ordensConfluencia.get(i));

}

if (!difere) ordemMax++;

TrechoDeCanal trechoCurr = new TrechoDeCanal();

trechoCurr = this.getTrechoJusanteByNo(nodePara);

if (trechoCurr != null) {

Integer k = this.trechos.lastIndexOf(trechoCurr);

this.trechos.get(k).setOrdemDoTrechoByTipo(TipoOrdenamento.STRAHLER, ordemMax);

}

} // for

} // while

return;

}

139

g) Classe Recobrimento e o operador temporal utilizado:

Este trecho do código apresenta parte da definição da classe Recobrimento,

na qual o operador temporal varDensidadeDrenagem() foi utilizado.

package drenagem;

import java.util.ArrayList;

import java.util.List;

public class Recobrimento {

public Recobrimento() {

}

public Recobrimento(Integer id) {

this.setId(id);

this.setAreasLevantamento(new ArrayList<AreaLevantamento>());

this.setRem(new REM());

}

private Integer id;

private REM rem;

private List<AreaLevantamento> areasLevantamento;

//::::::::

public List<AreaLevantamento> getAreasLevantamento() {

return areasLevantamento;

}

public void setAreasLevantamento(List<AreaLevantamento> areasLevantamento) {

this.areasLevantamento = areasLevantamento;

}

* varDensidadeDrenagem: determina as variações de densidade de uma

* rede de drenagem para diferentes tempos de areas de levantamento

public Float[] varDensidadeDrenagem() {

Float varDens[] = new Float[this.areasLevantamento.size()-1];

Float dens[] = new Float[this.areasLevantamento.size()];

// Para cada epoca de areas de levantamento de um mesmo recobrimento

// obtenha a rede de drenagem (assumindo aqui que existe uma só rede

// por area de levantamento), calcule a densidade de drenagem e

// armazene no vetor de densidades obtidas

for (int i=0;i<this.areasLevantamento.size();i++) {

RedeDeDrenagem rede = this.areasLevantamento.get(i).getRedes().get(0);

rede.setDensidadeDrenagem(rede.calculaDensidadeDrenagem());

dens[i] = rede.getDensidadeDrenagem();

}

// Calcule a variação da densidade de drenagem para todos os instantes

for (int i=1;i<this.areasLevantamento.size();i++) {

varDens[i-1] = dens[i] / dens[i-1];

}

return varDens;

}

140

APÊNDICE 2 – PROCESSO DE EXTRAÇÃO DE REDES DE DRENAGEM

Este apêndice apresenta o processo de extração de rede de drenagem

utilizado, quando os dados existentes provinham de uma grade de pontos

altimétricos, utilizando-se as extensões do software ArcGIS

Na realização deste procedimento, o termo "menu de pop-up" se refere ao

menu apresentado ao se clicar com o botão direito do mouse sobre um item da

interface gráfica do software em questão. Todos os softwares e extensões

mencionados neste apêndice, salvo indicação ao contrário, são de propriedade da

ESRI. Todas as figuras deste apêndice foram obtidas por captura das telas do

ArcMap

1) Preparação do ambiente

O ArcMap

é um software integrante da família ArcGIS

da ESRI e possui

algumas extensões que oferecem facilidades de análise. Estas facilidades estão

classificadas e funcionalmente agrupadas na interface. Entre estas extensões, duas

serão utilizadas para o propósito deste exercício: 3D Analyst e Spatial Analyst. Para

que estas extensões possam ser utilizadas pela primeira vez numa instalação nova,

a partir do ArcMap

, é necessário habilitá-las no menu “Tools/Extensions” (fig.66).

FIGURA 66 - CAIXA DE SELEÇÃO DE EXTENSÕES DO ArcGIS

FONTE: O autor (2008)

Estas ferramentas podem ser utilizadas a partir da janela de diálogo do

ArcMap

denominada ArcToolbox (fig. 67).

141

FIGURA 67 - MENU ARCTOOLBOX DO ArcMAP

FONTE: O autor (2008)

2) Dados para o processo

Para este processo, utilizou-se uma grade de 2501 pontos proveniente da

pasta “exercícios 4” de um dos tutoriais do ArcGIS

. Estes pontos estão no arquivo

chamado "vipoints" no formato coverage. Este formato de arquivo permite armazenar

feições de uma mesma natureza, por exemplo, pontos ou polígonos e que

apresentem um mesmo conjunto de atributos não-espaciais. Adiciona-se este

arquivo no ArcMap

a partir do ícone "Add data" localizado na barra principal de

ícones. Esta função abre uma janela de diálogo para a localização e seleção do

arquivo. Uma vez lido este arquivo, o ArcMap

o incorpora na lista de layers atuais

localizado no painel da extrema esquerda da interface e o apresenta numa

visualização padrão dos pontos lidos (fig. 68).

142

FIGURA 68 - LAYER DA GRADE DE PONTOS PARA O PROCESSO

FONTE: O autor (2008)

Visualiza-se a tabela de atributos da layer a partir do menu de pop-up

disparado sobre a layer da coluna de layers, selecionando-se "Open Attributes

Table". Parte da tabela de atributos do arquivo (fig. 69) é apresentada, onde duas

colunas se destacam: FID e SPOT. A primeira armazena a identificação de cada

ponto e a coluna SPOT suas respectivas altitudes.

143

FIGURA 69 - TABELA DE ATRIBUTOS DOS PONTOS DO MODELO

FONTE: O autor (2008)

A distribuição de frequência dos dados de altitudes e alguns valores de

estatística como número da amostra, valores mínimos e máximos, soma, média e

desvio-padrão, são apresentados ao se chamar o menu de pop-up (fig. 70) e

visualizados segundo a figura 71.

FIGURA 70 - MENU DE INVOCAÇÃO DE FUNÇÕES GERAIS SOBRE DADOS

FONTE: O autor (2008)

144

FIGURA 71 - JANELA DOS RESULTADOS ESTATÍSTICOS DOS DADOS

FONTE: O autor (2008)

De posse dessa distribuição, é possível inferir que a grade de pontos do

terreno pode ser grosseiramente separada para este caso em três patamares de

altitudes dos pontos: abaixo de 210,0m (inferior), maior que 210,0m e menor que

270,0m (médio) e acima de 270,0m (superior). Observa-se pela distribuição de

frequência deste exemplo, uma predominância de pontos de altitudes menores e

poucos pontos com altitudes maiores. Este sentimento inicial a respeito dos dados é

simples de obtê-lo, e tem um custo de aquisição muito pequeno, uma vez que até

aqui não foi necessário a execução intensiva de algoritmos de geração de malha

superficial para visualização. Outro fator importante, é que a determinação de redes

de drenagem, por sua própria natureza, melhor se presta em terrenos não muito

planos.

Complementarmente, o ArcMap

também oferece uma janela de diálogo

obtida pela escolha do item "Propriedades" no menu de "pop-up" sobre a layer de

pontos. Esta seleção apresenta as propriedades da layer, organizadas numa série

de guias ou abas. Entre elas, pode-se visualizar o sistema de projeção e o envelope

de coordenadas da massa de dados (fig. 72).

145

FIGURA 72 - VISUALIZAÇÃO DE PARTE DAS PROPRIEDADES DA LAYER DE PONTOS

FONTE: O autor (2008)

3) Passos para a determinação da rede de drenagem

Para a geração do MDT (Modelo Digital do Terreno) a partir da grade de

pontos, utiliza-se uma rede irregular de triângulos (TIN).

3.1) Criação da TIN

A função "Create TIN" é disparada pelo menu "3D Analyst Tools / TIN

Creation" do ArcToolbox. Ela prepara uma estrutura de arquivos para receber a rede

triangulada gerada mais tarde (fig. 73). Esta função solicita dois parâmetros pela

janela de diálogo: o arquivo de saída para a TIN e a referência espacial que será

utilizada na geração.

146

FIGURA 73 - CRIAÇÃO DA TIN INICIAL VAZIA

FONTE: O autor (2008)

Para a seleção da referência espacial, pressiona-se o botão

correspondente. A caixa de diálogo da figura 74 é apresentada.

147

FIGURA 74 - PROPRIEDADE DA REFERÊNCIA ESPACIAL

FONTE: O autor (2008)

Clica-se em "Select..." e procede-se com a seleção do sistema de

coordenadas mediante escolha das pastas disponíveis na janela de diálogo (fig. 75).

FIGURA 75 - PESQUISA PELO SISTEMA DE COORDENADAS

FONTE: O autor (2008)

148

Para o presente caso, seleciona-se a pasta “Projected Coordinate Systems”

e em seguida a pasta “Utm” (fig. 76).

FIGURA 76 - SISTEMAS DE COORDENADAS

FONTE: O autor (2008)

Para os dados do exemplo, seleciona-se o meridiano 16N, conforme

visualizado nas figuras 77 e 79.

FIGURA 77 - SELEÇÃO DO MERIDIANO

FONTE: O autor (2008)

149

FIGURA 78 - APRESENTAÇÃO DO SISTEMA SELECIONADO

FONTE: O autor (2008)

FIGURA 79 - RETORNO A CAIXA DE DIÁLOGO INICIAL

FONTE: O autor (2008)

150

Verifica-se também que uma nova layer com o nome fornecido, no caso,

TIN, é criada na coluna de layers.

3.2) Edição da TIN

Neste passo, seleciona-se a grade de pontos que será utilizada para a

efetiva geração da TIN. Para isso, fornece-se a TIN inicial criada no passo anterior,

que será utilizada para a geração e qual o arquivo de feições e atributo que será

utilizado para as altitudes dos pontos (fig. 80).

FIGURA 80 - PARÂMETROS PARA A EDIÇÃO DA TIN

FONTE: O autor (2008)

Fecha-se a janela de diálogo e observa-se que sob a layer de pontos a rede

de triângulos é visualizada (fig. 81).

151

FIGURA 81 - VISUALIZAÇÃO DA TIN PRODUZIDA

FONTE: O autor (2008)

Opcionalmente é possível estratificar o conjunto de altitudes em classes

discretas obtendo-se diferente visualização (fig. 82).

FIGURA 82 - RAMPA DE CORES PARA OS VALORES DE ALTITUDES

FONTE: O autor (2008)

152

FIGURA 83 - LAYER APÓS APLICAÇÃO DA CLASSE DE CORES

FONTE: O autor (2008)

3.3) Preenchimento de depressões

Neste passo determina-se o preenchimento de depressões. Este

procedimento é necessário como pré-requisito para a execução dos passos

seguintes. O procedimento consiste em determinar as regiões que não drenam

adiante (sinks). Para tal, o procedimento emprega um algoritmo para a determinação

da direção de fluxo em cada célula, levando-se em conta a condição de uma célula

não apontar para a outra de forma indeterminada (em loop). O custo da operação

será diretamente proporcional ao tamanho da grade de pontos.

Dois tipos de "preenchimento" podem ser encontrados conforme as figuras

84 e 85, e ambos serão tratados neste passo. Para a realização do preenchimento,

a TIN deverá ser convertida para uma imagem raster, a partir da qual o

preenchimento propriamente dito será realizado. Esta conversão em matriz regular

de pixels é necessária pois, o método de determinação de fluxo que se seguirá,

utiliza os valor de altitude de cada célula comparado com os valores de altitudes das

células vizinhas, conforme adiante detalhado. Este preenchimento é uma

preparação para aquele método.

153

FIGURA 84 - AJUSTE DE DEPRESSÕES POR CORTES (SUPRESSÕES) ADJACENTES

FONTE: O autor (2008)

FIGURA 85 - AJUSTE DE DEPRESSÕES POR PREENCHIMENTOS ADJACENTES

FONTE: O autor (2008)

Seleciona-se a opção "TIN to Raster" a partir da ferramenta "3D Analyst

Tools/Conversion" no menu do ArcToolbox, cujo diálogo é apresentado na figura 86.

FIGURA 86 - JANELA DE DIÁLOGO PARA A GERAÇÃO DA IMAGEM RASTER

FONTE: O autor (2008)

Como resultado, uma nova layer é gerada com a imagem raster criada (fig.

87).

154

FIGURA 87 - IMAGEM RASTER CRIADA A PARTIR DA TIN

FONTE: O autor (2008)

Em seguida, realiza-se o preenchimento por meio do menu do "Spatial

Analyst Tool", ferramenta "Hydrology / Fill" do ArcToolbox. A função invoca a janela

de diálogo da figura 88.

FIGURA 88 - DIÁLOGO PARA PREENCHIMENTO DAS DEPRESSÕES

FONTE: O autor (2008)

155

3.4) Determinação do sentido do fluxo

O determinação da rede de drenagem é ditada pelo sentido do fluxo. Este

sentido é determinado tomando-se um bloco de nove células (uma célula central e

oito células vizinhas). Cada sentido em relação à célula central recebe um valor pré-

determinado (fig. 89). Este valor não tem nenhuma relação com qualquer outro valor

físico das células. O sentido do fluxo descendente é determinado pela análise de

cada célula central em relação as suas vizinhas. Por comparação dos valores das

altitudes entre a célula central e suas vizinhas, a célula central recebe o valor do

sentido da célula vizinha mais íngreme do fluxo descendente.

FIGURA 89 - VALORES DOS SENTIDOS EM RELAÇÃO A CÉLULA CENTRAL

FONTE: O autor (2008)

Assim, por exemplo, se o sentido mais íngreme aponta para a célula ao

norte, a célula em questão recebe o valor 64 (fig. 90) e o procedimento é repetido

com a célula ao norte como sendo a nova célula central.

FIGURA 90 - VALOR AFIXADO APÓS ANÁLISE

FONTE: O autor (2008)

Para este procedimento, a função "Flow Direction" é chamada passando-se

os parâmetros abaixo (fig. 91) e produzindo-se o resultado segundo a figura 92.

156

FIGURA 91 - JANELA DE DIÁLOGO "FLOW DIRECTION"

FONTE: O autor (2008)

FIGURA 92 - LAYER DOS SENTIDOS DE FLUXO DETERMINADOS

FONTE: O autor (2008)

157

3.5) Determinação do acúmulo do fluxo

O passo seguinte consiste em se determinar o acúmulo (ou contribuição) do

fluxo da rede de drenagem. Em outras palavras, para cada célula, calcula-se qual foi

a contribuição dos fluxos ascendentes. Para tal, a função "Flow Accumulation" é

chamada a partir do ArcToolBox (fig. 93). Esta função calcula o somatório das

contribuições dos fluxos provenientes das células vizinhas em relação a célula atual.

Quanto maior for a contribuição, maior será a luminosidade atribuída a célula em

questão.

FIGURA 93 - JANELA DE DIÁLOGO DO "FLOW ACCUMULATION

FONTE: O autor (2008)

Como resultado, uma nova layer é gerada no formato raster representando

numa ordem crescente de luminosidade o acúmulo obtido (fig. 94). O tom de cor

pode ser modificado manualmente (fig. 95).

158

FIGURA 94 - LAYER REPRESENTANDO A CONTRIBUIÇÃO OBTIDA

FONTE: O autor (2008)

FIGURA 95 - LAYER MODIFICADA REPRESENTANDO A CONTRIBUIÇÃO OBTIDA

FONTE: O autor (2008)

Pode-se sobrepor as duas layers produzidas: o que representa a TIN e o da

contribuição. Para melhor visualização, optou-se em dar um certo grau de

transparência à layer da TIN resultando na figura 96.

159

FIGURA 96 - SOBREPOSIÇÃO DE LAYERS

FONTE: O autor (2008)

3.6) Vetorização da rede de drenagem

Até aqui, a rede de drenagem obtida apresenta-se na forma matricial.

Observa-se que o tom de cor e a intensidade produzidas em cada célula

determinam o grau de contribuição que células anteriores deram no fluxo

descendente pelo terreno. Células que não apresentam contribuição são chamadas

de "NODATA" no sentido de que não recebem valor algum. Para obter-se o arquivo

vetorizado em polilinha, delimita-se a imagem matricial para um certo grau de

contribuição das células e com este arquivo delimitado gera-se o arquivo do tipo

"Shapefile feature class".

3.7) Delimitação da rede de drenagem

Para que a rede de drenagem possa ser vetorizada, pode-se delimitá-la

mediante a utilização de funções de álgebra de mapas ou pela ferramenta Con por

meio da chamada ao menu "Spatial Analyst Tool/Map Algebra/Single Output Map

Algebra" (fig. 97). Neste diálogo, insere-se a expressão que realizará a delimitação.

Duas expressões podem ser utilizadas que produzirão resultados semelhantes:

160

con ( c:\Drenagem\flowacc > 100, 1 )

ou ainda,

setnull (c:\Drenagem\flowacc < 100, 1)

As expressões acima produzirão uma saída onde "c:\Drenagem\flowacc" é

o arquivo do fluxo acumulado obtido em passo anterior, “100” é o limite de

contribuição de células e "1" é o valor que as células terão ao satisfazer a condição

estabelecida resultando nas demais células o valor "NODATA". Em outras palavras,

somente serão consideradas as contribuições superiores a 100 células. Células com

valores menores de contribuição serão atribuídas o valor "NODATA".

FIGURA 97 - DIÁLOGO PARA DELIMITAÇÃO E PRODUÇÃO DO ARQUIVO "STREAM"

FONTE: O autor (2008)

A imagem produzida toma a forma ilustrada pela figura 98.

FIGURA 98 - IMAGEM OBTIDA DO ARQUIVO "STREAM" GERADO NO ARCGIS

FONTE: O autor (2008)

161

3.8) Passagem da rede matricial delineada para vetorizada (shapefile)

Finalmente, recorre-se à ferramenta "Spatial Analyst Tools / Hydrology /

Stream to Feature". A janela de diálogo (fig. 99) é apresentada:

FIGURA 99 - DIÁLOGO DE PASSAGEM PARA ARQUIVO "FEATURE"

FONTE: O autor (2008)

FIGURA 100 - IMAGEM OBTIDA VETORIZADA

FONTE: O autor (2008)

162

É possível ver um detalhe do resultado da vetorização (fig. 101), onde uma

polilinha foi selecionada (em vermelho, de ARCID=136) com os valores dos seus

atributos:

FIGURA 101 - RESULTADO DA VETORIZAÇÃO COM POLILINHA SELECIONADA

FONTE: O autor (2008)

Com ferramenta de edição é possível observar os nós e suas respectivas

coordenadas conforme figura 102:

FIGURA 102 - VALORES DOS NÓS DA POLILINHA SELECIONADA

FONTE: O autor (2008)

163

APÊNDICE 3 – CONVERSÃO ENTRE FORMATOS DE ARQUIVOS DE DADOS

Para conversões recíprocas entre os formatos Texto e shapefile, localiza-se

no ArcToolbox do ArcMap

a pasta “Samples”, o item “Data Management”,

“Features” e seleciona-se uma das funções conforme o sentido de conversão

requerido (fig. 103). Preenche-se em seguida os dados solicitados na janela de

diálogo.

FIGURA 103 - MENU DO ARCTOOLBOX PARA EXPORTAÇÃO EM ARQUIVOS DE TEXTOS

FONTE: O autor (2008)

A figura 104 ilustra parte do conteúdo de um arquivo gerado na conversão

de uma feature para arquivo texto.

FIGURA 104 - EXEMPLO DE ARQUIVO DE DADOS EXPORTADO

FONTE: O autor (2008)

Livros Grátis
( http://www.livrosgratis.com.br )
 
Milhares de Livros para Download:
 
Baixar livros de Administração
Baixar livros de Agronomia
Baixar livros de Arquitetura
Baixar livros de Artes
Baixar livros de Astronomia
Baixar livros de Biologia Geral
Baixar livros de Ciência da Computação
Baixar livros de Ciência da Informação
Baixar livros de Ciência Política
Baixar livros de Ciências da Saúde
Baixar livros de Comunicação
Baixar livros do Conselho Nacional de Educação - CNE
Baixar livros de Defesa civil
Baixar livros de Direito
Baixar livros de Direitos humanos
Baixar livros de Economia
Baixar livros de Economia Doméstica
Baixar livros de Educação
Baixar livros de Educação - Trânsito
Baixar livros de Educação Física
Baixar livros de Engenharia Aeroespacial
Baixar livros de Farmácia
Baixar livros de Filosofia
Baixar livros de Física
Baixar livros de Geociências
Baixar livros de Geografia
Baixar livros de História
Baixar livros de Línguas

Baixar livros de Literatura
Baixar livros de Literatura de Cordel
Baixar livros de Literatura Infantil
Baixar livros de Matemática
Baixar livros de Medicina
Baixar livros de Medicina Veterinária
Baixar livros de Meio Ambiente
Baixar livros de Meteorologia
Baixar Monografias e TCC
Baixar livros Multidisciplinar
Baixar livros de Música
Baixar livros de Psicologia
Baixar livros de Química
Baixar livros de Saúde Coletiva
Baixar livros de Serviço Social
Baixar livros de Sociologia
Baixar livros de Teologia
Baixar livros de Trabalho
Baixar livros de Turismo
 
 