Concepção e Implementação de um Sistema de Controle de Arborização Urbana através da Integração de Softwares Livres e de Código Aberto

(1)

“J ´

ULIO DE MESQUITA FILHO”

Cˆampus de Presidente Prudente

Bruno C´

esar Vani

Concep¸

c˜

ao e Implementa¸

c˜

ao de um Sistema de

Controle de Arboriza¸

c˜

ao Urbana atrav´

es da

Integra¸

c˜

ao de Softwares Livres e de C´

odigo Aberto

(2)

Concep¸

c˜

ao e Implementa¸

c˜

ao de um

Sistema de Controle de Arboriza¸

c˜

ao

Urbana atrav´

es da Integra¸

c˜

ao de Softwares

Livres e de C´

odigo Aberto

Trabalho de conclusão de curso apresentada ao Departamento de Matemática, Estat´ıstica e Computa¸cão (DMEC), da Universidade Es-tadual Paulista “Júlio de Mesquita Filho”, sob o t´ıtulo“Constru¸cão de um Sistema de Controle de Arboriza¸cão Urbana através da Integra¸cão de Ferramentas Livres”.

Orientador:

Prof. Dr. Milton Hirokazu Shimabukuro

Presidente Prudente

(3)

Aluno Bruno C´

esar Vani

Concep¸

c˜

ao e Implementa¸

c˜

ao de um Sistema de

Controle de Arboriza¸

c˜

ao Urbana atrav´

es da

Integra¸

c˜

ao de Softwares Livres e de C´

odigo Aberto

Monografia sob o t´ıtulo“Concep¸cão e Implementa¸cão de um Sistema de Con-trole de Arboriza¸cão Urbana através da Integra¸cão de Softwares Livres e de Código Aberto”, defendida por Bruno César Vani e aprovada em 15 de Dezembro de

2011, em Presidente Prudente, Estado de S˜ao Paulo, pela banca examinadora constitu´ıda pelos doutores:

Prof. Dr. Milton Hirokazu Shimabukuro FCT Unesp

Prof. Dr. Marco Antonio Piteri FCT Unesp

Prof. Dr. Edilson Ferreira Flores FCT Unesp

(4)

Agrade¸co primeiramente a Deus pela oportunidade de concluir este curso, superando todas as dificuldades.

Agrade¸co ao Professor Dr. Milton Hirokazu Shimabukuro e Me. ´Italo Tsuchya, pelo apoio e incentivo nos projetos que me possibilitaram grande aprendizado extracurricular.

Agrade¸co tamb´em aos amigos Vinicius Akira Suyama e Dallan Augusto Toledo Reis, pela parceria nos trabalhos em equipe ao longo do curso.

(5)

Ferramentas computacionais adequadas permitem construir aplica¸cões capazes de vin-cular informa¸cões à sua localiza¸cão f´ısica, bem como representá-la em um esquema visual e interativo, atingindo eficientemente o poder de comunica¸cão visual. Isso faz com que o usuário sintetize informa¸cões de maneira simples e eficiente. A estas aplica¸cões podemos atrelar a defini¸cão de Sistema de Informa¸cão Geográfica (SIG). Os SIG’s abrangem di-versos conceitos e disciplinas, com a finalidade principal de coletar, armazenar, visualizar e processar dados espaciais, obtendo assim as informa¸cões necessárias para tomada de decisões.

Em meio a este contexto, apresentamos neste trabalho a Concep¸cão e a Implementa¸cão de um Sistema de Controle de Arboriza¸cão Urbana através da Integra¸cão de Softwares Livres e de Código Aberto. Esta concep¸cão surgiu a partir da necessidade de um Projeto Ambiental desenvolvido pela Casa da Agricultura do munic´ıpio de Regente Feijó, que tem como objetivos principais a cataloga¸cão e gerenciamento da arboriza¸cão urbana do munic´ıpio.

Por abordar esta diversidade de conceitos, o desafio na constru¸cão deste sistema está na integra¸cão das plataformas que estão envolvidas em todas as suas etapas: coleta e armazenamento de dados, inclusão de mapas e demais informa¸cões espaciais, opera¸cões sobre as informa¸cões armazenadas, obten¸cão de resultados e visualiza¸cão gráfica dos mes-mos.

Após a implementa¸cão, foi poss´ıvel propiciar ao usuário do sistema um aumento na capacidade de percep¸cão na análise das informa¸cões, bem como facilitar o processo de tomada de decisões.

(6)

Suitable computacional tools allow to build applications that can link information to its physical location, and represent them into visual and interactive schemes, effectively reaching the power of visual comunication. This leads the user to synthesize information in a simple and efficient way. These applications are linked to the definition of Geographic Information System (GIS). GIS are comprised by many concepts and tools, which have the main purpose of collecting, storing, viewing and processing spatial data, obtaining the information needed for decision making.

Within this context, this paper presents the Conception and Implementation of a Control System for Urban Forestry through Integration of Free and Open Source Soft-ware. This conception arose from the need of an Environmental Project developed by the Agriculture’s House of the city of Regente Feij´o, which has as main objectives cataloging and management of urban afforestation of the municipality.

Due to this diversity of concepts, the challenge in building this system is the integra-tion of platforms that are involved in all stages: collecting and storage of data, including maps and other spatial information, operations on the stored information, obtaining re-sults and graphical visualization of the same.

After implementation, it was possible to provide for the system users an improvement in the capacity of perception in the information analysis and facilitate the process of decision making.

(7)

1 Introdu¸c˜ao p. 12

1.1 Vis˜ao Geral . . . p. 12

1.2 Objetivos do Trabalho . . . p. 13

1.3 Organiza¸c˜ao do Trabalho . . . p. 13

2 Conceitos e Ferramentas Computacionais p. 14

2.1 Informa¸c˜oes Espaciais . . . p. 14

2.2 Dados Espaciais . . . p. 15

2.3 Geoprocessamento e Sistema de Informa¸c˜ao Geogr´afica . . . p. 16

2.4 Banco de Dados (BD) e Banco de Dados Geogr´afico . . . p. 18

2.4.1 Sistema Gerenciador de Banco de Dados (SGBD) . . . p. 18

2.4.2 PostgreSQL e PostGIS . . . p. 18

2.5 Arquitetura Cliente-Servidor . . . p. 19

2.5.1 Cliente e Servidor Web . . . p. 19

2.5.2 Servidor Web Apache . . . p. 20

2.6 Servidor de Mapas . . . p. 20

2.7 Web mapping . . . p. 21

2.8 Software Livre e de C´odigo Aberto . . . p. 21

(8)

2.9.2 MapServer MapScript . . . p. 24

2.9.3 Mapfile . . . p. 24

2.10 Shapefile . . . p. 26

2.11 p.mapper . . . p. 26

2.12 PHP . . . p. 27

2.13 Javascript e jQuery . . . p. 27

2.14 PHPlot . . . p. 27

3 Concep¸c˜ao do Projeto p. 28

3.1 Obten¸c˜ao e An´alise de Requisitos . . . p. 28

3.2 Modelagem . . . p. 32

4 Integra¸c˜ao das Ferramentas p. 33

4.1 Estrutura da Aplica¸c˜ao . . . p. 33

4.2 Banco de Dados e MapServer . . . p. 33

4.2.1 Criando um banco de dados espacial com PostgreSQL/PostGIS p. 34

4.2.2 Garantindo a Interoperabilidade com o MapServer . . . p. 35

4.2.3 Inser¸c˜ao de dados de natureza espacial . . . p. 36

4.2.4 Consulta a dados de natureza espacial . . . p. 37

4.3 Interface de Navega¸c˜ao e Edi¸c˜ao - PHP/mapscript . . . p. 37

4.3.1 Mapa dinˆamico . . . p. 37

4.3.2 Propriedade “EXTENT” de um mapa . . . p. 38

4.3.3 Zoom . . . p. 41

4.3.3.1 Zoom pontual . . . p. 42

4.3.3.2 Zoom por rolagem de mouse . . . p. 42

(9)

4.3.5 Op¸c˜ao novo ponto de referˆencia . . . p. 46

4.3.6 Op¸cão de Edi¸cão de Ponto de Referência . . . p. 46

4.3.7 Op¸c˜ao Nova ´Arvore . . . p. 49

4.3.8 Ajuste de ´Arvore . . . p. 50

4.3.9 Listar ´Arvore . . . p. 50

4.3.10 Op¸c˜ao Atualizar/Limpar . . . p. 51

4.3.11 Op¸c˜ao Home . . . p. 51

4.3.12 Interface de sele¸c˜ao de Layers e Legendas . . . p. 51

4.3.13 Mapa de Referˆencia e Barra de Escala . . . p. 51

4.4 Interface para Dados Descritivos . . . p. 52

4.4.1 Gerenciamento de Esp´ecies e Cat´alogos de Origem . . . p. 53

4.4.2 Exibi¸c˜ao das Vistorias . . . p. 53

4.4.3 Upload de imagens . . . p. 54

4.4.4 Relat´orios e Gr´aficos . . . p. 55

4.4.4.1 Gráfico de Distribui¸cão de Espécies e de Sanidade . . . p. 56

4.4.4.2 M´edias dos parˆametros espec´ıficos . . . p. 57

4.4.4.3 Estimativa de ´Area Verde . . . p. 57

4.4.4.4 Rela¸c˜ao de Substitui¸c˜oes . . . p. 57

4.5 Experimentos e Retorno dos Usu´arios . . . p. 58

5 Conclus˜ao p. 59

5.1 Considera¸c˜oes Finais . . . p. 59

5.2 Futuros Trabalhos . . . p. 60

(10)

1 Representa¸c˜ao das estruturas matricial (a) e vetorial (b) . . . p. 16

2 Arquitetura de Sistema de Informa¸c˜ao Geogr´afica. Fonte: (CAMARA et

al., 1996). . . p. 17 3 Arquitetura Cliente-Servidor. Fonte: (KUROSE; ROSS, 2006). . . p. 19 4 Arquitetura de uma aplica¸c˜ao MapServer. Fonte: (MAPSERVER, 2010). p. 23 5 Visualizador p.mapper. Fonte:(P.MAPPER, 2011). . . p. 26 6 Diagrama de classes do Sistema . . . p. 32

7 Arquitetura da aplica¸c˜ao MapServer para este contexto. Adaptada de

(MAPSERVER, 2010). . . p. 34 8 Interface de navega¸c˜ao e edi¸c˜ao implementada . . . p. 38

9 Demonstra¸c˜ao da propriedade extent . . . p. 39

10 Comportamento da funcionalidade pan numa posi¸c˜ao clicada . . . p. 44

11 Comportamento da funcionalidade pan na coordenada de destino . . . p. 45

12 Opera¸c˜oes de deslocamento para satisfazer a funcionalidade pan . . . . p. 46

13 Op¸c˜ao de novo ponto de referˆencia . . . p. 47

14 Op¸c˜ao de ajuste de ponto de referˆencia . . . p. 48

15 Op¸c˜ao de nova ´arvore com ajuste manual de coordenadas . . . p. 50

16 Interface de sele¸c˜ao de layers . . . p. 52

(11)

19 Interface de cria¸c˜ao de esp´ecies - seletor de cores . . . p. 53

20 Interface de vistorias de uma ´arvore . . . p. 54

21 Interface de sele¸cão para relatórios e gráficos . . . p. 55

(12)

1 Exemplo de Mapfile . . . p. 24 2 Instru¸c˜ao SQL para cria¸c˜ao de um banco de dados espacial . . . p. 34

3 Instru¸cão SQL para cria¸cão de uma tabela com dado espacial . . . p. 35 4 Instru¸cão SQL para cria¸cão de uma tabela com dado espacial . . . p. 36 5 Instru¸cão SQL para cria¸cão de uma tabela com dado espacial . . . p. 37 6 Execu¸cão do utilitário para obten¸cão da extensão de um mapa . . . p. 39

7 Fun¸c˜ao para convers˜ao de coordenadas de imagem em coordenadas

ge-ogr´aficas . . . p. 40 8 Fun¸c˜ao atualizar extent . . . p. 40

9 Bloco de execu¸c˜ao de zoom pontual . . . p. 42 10 Javascript imgAreaSelect . . . p. 43 11 Consultas para sele¸c˜ao de ponto . . . p. 48 12 Uso da biblioteca WideImage . . . p. 54

13 Consulta para distribui¸cão de espécies . . . p. 56 14 Consulta para distribui¸cão de sanidade . . . p. 56 15 Consulta para obten¸cão de médias . . . p. 57 16 Consulta estimativa de área verde . . . p. 57

(13)

Cap´ıtulo

1

Introdu¸c˜

ao

1.1 Vis˜

ao Geral

A manipula¸cão de informa¸cões espaciais está presente em parte das aplica¸cões envol-vendo banco de dados em geral. Como o volume de informa¸cões desse tipo cresce a todo tempo, o oferecimento de mecanismos complementares na manipula¸cão de dados auxilia nos processos de tomada de decisão.

Ferramentas computacionais adequadas permitem construir aplica¸cões capazes de vin-cular a informa¸cão à sua localiza¸cão f´ısica, bem como representá-la em um esquema visual

e interativo, atingindo eficientemente o poder de comunica¸cão visual. Isso faz com que o usuário sintetize informa¸cões de maneira simples e eficiente.

A estas aplica¸cões pode-se atrelar a defini¸cão de Sistema de Informa¸cão Geográfica (SIG). Os Sistemas de Informa¸cões Geográficas abrangem diversos conceitos e disciplinas, com a finalidade principal de coletar, armazenar, visualizar e processar dados espaciais,

obtendo assim as informa¸cões necessárias para tomada de decisões. Além de trabalhar com estruturas capazes de armazenar as fei¸cões geométricas (pol´ıgonos, por exemplo) e localiza¸cões dos dados, um SIG deve também ser capaz de trabalhar com os atributos convencionais (alfanuméricos) que completam a descri¸cão das informa¸cões, propiciando

(14)

1.2 Objetivos do Trabalho

Em meio a este contexto de informa¸cão versus localiza¸cão, utilizamos a idéia de construir um sistema de controle de arboriza¸cão urbana, que surgiu a partir da necessidade

de um Projeto Ambiental desenvolvido pela Casa da Agricultura do munic´ıpio de Regente Feijó/SP. Um grande trabalho de campo foi realizado, tendo como resultado um catálogo com informa¸cões espec´ıficas, de localiza¸cão e fotos das árvores do per´ımetro urbano da cidade.

Com base neste cat´alogo, o foce deste trabalho ´e conceber e implementar um sistema

de controle, representando as ´arvores visualmente no mapa da cidade. As funcionalidades requeridas pelo mesmo foram elaboradas a partir da necessidade do Projeto.

Por abordar esta diversidade de conceitos, o desafio na constru¸cão deste sistema está na integra¸cão das plataformas que estão envolvidas em todas as suas etapas: ar-mazenamento e manipula¸cão dos dados, inclusão de mapas e demais informa¸cões espaci-ais, obten¸cão de resultados e visualiza¸cão gráfica dos mesmos. Todas estas etapas aqui

resumidas fazem partes do problema a ser solucionado como proposta deste trabalho de conclus˜ao de curso.

1.3 Organiza¸c˜

ao do Trabalho

O Cap´ıtulo 2 contém a revisão teórica e prática, no qual são definidos conceitos e ferramentas importantes para a implementa¸cão do sistema proposto.

O Cap´ıtulo 3 destina-se à defini¸cão do projeto: obten¸cão e análise dos requisitos e

modelagem.

O Cap´ıtulo 4 exibe as solu¸c˜oes encontradas para a resolu¸c˜ao do problema proposto.

Por fim, no Cap´ıtulo 5, uma conclus˜ao ´e apresentada, destacando-se os resultados

(15)

Cap´ıtulo

2

Conceitos e Ferramentas Computacionais

Neste Cap´ıtulo, os conceitos e ferramentas computacionais para a solu¸cão do pro-blema proposto como tema deste Trabalho de Conclusão de Curso são apresentados. São

explanados alguns conceitos espec´ıficos para se compreender o uso de banco de dados es-paciais. Também são definidas algumas ferramentas utilizadas na manipula¸cão deste tipo de dado, bem como alguns conceitos acerca de arquiteturas de aplica¸cões que os utilizam.

2.1 Informa¸c˜

oes Espaciais

Inicialmente, cabe ressaltar que os termos informa¸c˜oes geoespaciais e informa¸c˜oes

geográficas também são utilizados. Conforme trechos publicados pela Comunica¸cão Social do Instituto Brasileiro de Geografia e Estat´ıstica (IBGE) em seu site oficial, obtem-se uma boa defini¸cão para o conceito e uso de informa¸cões espaciais:

(16)

de Posicionamento Global. Informa¸cões geoespaciais são necessárias em quase toda atividade de planejamento e administra¸cão. Mapas e dados associados a localiza¸cões são usados no cotidiano para planejamento e gestão de recursos, oferta de servi¸cos nos setores público e privado; e também na elabora¸cão de pol´ıticas públicas. É por esta razão que o uso do Geoprocessamento e da Geotecnologia torna-se essen-cial para gestão, análise, tomada de decisão em uma imensa gama de atividades. Os dados digitais são o pré-requisito para o manejo de grandes volumes de dados, em diversas formas, e para o uso de técnicas de visualiza¸cão que permitam o en-tendimento do passado e do presente, e a proje¸cão do futuro. Estando em formato digital, os dados espaciais podem ser armazenados, manipulados, integrados, edita-dos, gerar novas informa¸cões por processamento, e distribu´ıdos entre pesquisadores e cidadãos.(IBGE, 2010).

Como se percebe, a dissemina¸cão das informa¸cões espaciais reflete diretamente em variadas áreas de interesse geral da popula¸cão, expandindo o acesso à informa¸cão.

2.2 Dados Espaciais

Dados espaciais, também chamados de geoespaciais ou geográficos, são utilizados para representa¸cão de informa¸cões espaciais. Este tipo de dado pode ser dividido em dois

com-ponentes, conforme definem Rigaux, Scholl e Voisard (2002): um componente descritivo (para informa¸cões tais como nome e popula¸cão de uma cidade, dentre outros) e um com-ponente espacial (localiza¸cão em certo espa¸co geográfico e sua forma geométrica).

Pode-se citar duas classes de representa¸c˜ao para este tipo de informa¸c˜ao, conforme descrevem Camara, Davis e Monteiro (2004):

• Estrutura Matricial: também conhecida como raster, este tipo de estrutura uti-liza uma matriz de duas dimensões para representa¸cão de uma informa¸cão espacial. Cada célula (ou pixel, para o caso da tela) desta matriz representa uma coordenada da informa¸cão representada, logo, o elemento da célula mantém um valor capaz

de identificar a informa¸cão mapeada naquele ponto. Estes valores que as células armazenam podem ser, por exemplo, números inteiros limitados em um intervalo (como exemplo, valores entre 0 e 255 para representa¸cão de imagens em 8 bits). Pode-se destacar como vantagens deste tipo de estrutura a sua simplicidade e

(17)

e a perda de qualidade pode ser significante. Como alternativa, pode-se aumentar a quantidade de células. Neste caso, as perdas serão menores, contudo, mais espa¸co de armazenamento será utilizado, resultando-se em mais custo de processamento;

• Estrutura Vetorial: este tipo de estrutura utiliza basicamente pontos, linhas e

pol´ıgonos para representa¸cão. Os pontos representam entidades por um par de coordenadas. As linhas são formadas por segmentos originados por pelo menos dois pontos. Já os pol´ıgonos, são formados por linhas que delimitam uma área. Como vantagens da representa¸cão vetorial, são destacadas a maior precisão e a facilidade

para representa¸cão de objetos de naturezas variadas e irregulares, tais como a de-limita¸cão de uma cidade ou de um rio. Cabe ressaltar que a implementa¸cão de opera¸cões sobre este tipo de dado são complexas.

A seguir, a imagem de um mesmo pol´ıgono criado utilizando-se as estruturas matricial - Figura 1 a) - e vetorial - Figura 1 b) -, evidenciando-se as caracter´ısticas citadas:

Figura 1: Representa¸c˜ao das estruturas matricial (a) e vetorial (b)

2.3 Geoprocessamento e Sistema de Informa¸c˜

ao

Ge-ogr´

afica

Camara, Davis e Monteiro (2004) definem que “o termo Geoprocessamento denota a disciplina do conhecimento que utiliza técnicas matemáticas e computacionais para o tratamento da informa¸cão geográfica[...]”.

(18)

ser utilizado em diversas áreas, tais como: Geografia, Sensoriamento Remoto, Planeja-mento Urbano, Seguran¸ca Pública e Engenharia de Tráfego. Esta abordagem interdis-ciplinar de um SIG possibilita o surgimento de novas tecnologias e aplica¸cões, possibil-itando ao usuário obter maneiras mais aprofundadas de interagir com as informa¸cões

armazenadas, al´em de destacar uma importante caracter´ıstica inerente ao ser humano: a comunica¸c˜ao visual.

Os componentes da estrutura b´asica de um SIG propostos por Camara et al. (1996) s˜ao mostrados na Figura 2.

Figura 2: Arquitetura de Sistema de Informa¸c˜ao Geogr´afica. Fonte: (CAMARA et al.,

1996).

Na camada base (Banco de Dados Geográfico), há o repositório dos dados espaci-ais, cujas defini¸cões serão detalhadas adiante. As opera¸cões sobre estes dados são de responsabilidade da camada superior (Gerência de Dados Espaciais), através do Sistema Gerenciador de Banco de Dados (SGBD) utilizado. Logo acima, aparecem as opera¸cões

realizadas no SIG, que envolvem a entrada e edi¸cão dos dados, realiza¸cão de consultas e análises, bem como os esquemas de visualiza¸cão dos mesmos. Por fim, no topo da estrutura, é apresentada a interface na qual as opera¸cões são realizadas pelo usuário. Atualmente, há diversas plataformas livres que possibilitam a cria¸cão de um SIG.

(19)

2.4 Banco de Dados (BD) e Banco de Dados

Ge-ogr´

afico

Em Date (2000), pode-se abstrair que um banco de dados ´e um conjunto de dados

persistentes que servem de base para uma aplica¸cão. O termo “persistente” define que estes dados são mantidos em certo repositório para estarem à disposi¸cão do usuário da aplica¸cão a qualquer tempo. A capacidade de armazenamento e manipula¸cão de dados

geográficos é o componente adicional que caracteriza umbanco de dados geográfico.

2.4.1 Sistema Gerenciador de Banco de Dados (SGBD)

Date (2000) também define SGBD como um sistema que permite ao usuário ar-mazenar, consultar e alterar dados no Banco de Dados. A arquitetura básica de um SGBD envolve basicamente quatro componentes:

1. Dados: informa¸c˜oes representadas do mundo real;

2. Hardware: dispositivos de armazenamento permanente onde ficar˜ao armazenados os dados;

3. Software: elo entre os dados e o hardware, e realiza¸cão das opera¸cões sobre os dados que estão armazenados no dispositivo de armazenamento permanente;

4. Usu´arios: desenvolvedores e demais utilizadores da aplica¸c˜ao final.

2.4.2 PostgreSQL e PostGIS

O PostgreSQL é um SGBD de código-fonte aberto muito utilizado no meio acadêmico e cient´ıfico. Seu projeto foi lan¸cado há mais de quinze anos e novas versões vêm sendo

incorporadas, propiciando suporte a novas tecnologias e melhorias de desempenho. Seu projeto colaborativo permite que usu´arios de todo o mundo contribuam para seu desen-volvimento e suporte.

O PostGIS é um projeto que “adiciona suporte a dados espaciais ao PostgreSQL, possibilitando então utilizá-lo como um Banco de Dados Geográfico em um Sistema de

(20)

2.5 Arquitetura Cliente-Servidor

Considerando um ambiente de rede de computadores, Kurose e Ross (2006) definem que neste tipo de arquitetura h´a uma aplica¸c˜ao servidora que deve estar sempre em

funcionamento. Ela será responsável por receber requisi¸cões de aplica¸cões cliente (que não necessitam se manter em funcionamento o tempo todo) e enviar as respostas a estas requisi¸cões. Cabe ressaltar que cliente e servidor funcionam em sistemas finais diferentes.

No contexto da web, há uma aplica¸cão cliente, à qual é denominada cliente web, e uma aplica¸cão servidora, à qual é denominada servidor web. A maneira pela qual estas aplica¸cões se comunicam está definida no Protocolo de Transferência de Hipertexto (HTTP), que define a estrutura das mensagens que são trocadas pelos programas cliente e servidor. A troca de mensagens é a maneira com que estes programas se comunicam, num ciclo de requisi¸cões e respostas. Na Figura 3, a representa¸cão desta estrutura proposta por

Kurose e Ross (2006) ´e apresentada, onde um servidor recebe requisi¸c˜oes de dois clientes:

Figura 3: Arquitetura Cliente-Servidor. Fonte: (KUROSE; ROSS, 2006).

2.5.1 Cliente e Servidor Web

Kurose e Ross (2006) também definem que o cliente web é o responsável por enviar ao servidor as mensagens de requisi¸cão HTTP. Um navegador de internet, também co-nhecido como browser, é um programa que, além de exibir conteúdos de uma página

(21)

“Apache’ e o “Microsoft Internet Information Server”. No contexto daweb, o objeto final destas requisi¸cões e respostas são arquivos (comumente, páginas HTML, imagens, dentre outros).

2.5.2 Servidor Web Apache

O “Apache HTTP Server Project”, conforme denomina¸cão oficial, é um “projeto de software desenvolvido através de esfor¸co colaborativo que visa a cria¸cão de um servidor

web robusto, de grau comercial, com mais recursos e de código-fonte aberto” (APACHE, 2011). Este projeto é gerenciado em conjunto por um grupo de voluntários espalhados pelo mundo, e faz parte da “Apache Software Fundation”. Os usuários comuns também contribuem para o desenvolvimento do projeto, através do envio de sugestões, código ou

documenta¸c˜ao.

2.6 Servidor de Mapas

Conforme Peng e Tsou (2003), um servidor de mapas é o componente capaz de gerar mapas através da realiza¸cão de consultas espaciais baseadas em requisi¸cões do usuário. Algumas caracter´ısticas podem ser citadas, tais como:

• Gera¸cão de mapas através de requisi¸cões do usuário;

• Realiza¸cão de consultas básicas acerca do conteúdo do mapa e de atributos de ca-racter´ısticas espaciais;

• Comunica¸c˜ao com outros programas e servi¸cos, tais como SGBD’s ou outros

servi-dores de mapa;

• Extra¸c˜ao de dados que estejam armazenados em um Banco de Dados para gera¸c˜ao de mapas;

• Interface gráfica e simbologia que permitam aos usuários um resultado satisfatório;

• O mapa produzido, normalmente, tem uma das formas que seguem:

(22)

2. Uma composi¸c˜ao gr´afica mais complexa, envolvendo estilos, legendas, camadas, s´ımbolos, dentre outros componentes;

3. Um componente em formato vetorial ou raster, de forma que possa ser ma-nipulado pelo cliente, com funcionalidades extras, como consultas, zoom, de-marca¸c˜oes, dentre outras.

2.7 Web mapping

O conceito de web mapping está relacionado à publica¸cão de mapas através da Inter-net. Peng e Tsou (2003) apresentam um breve histórico:

1. Publica¸c˜ao de Mapas Est´aticos (arquivo de imagem em formato “jpg”, “png”, dentre

outros);

2. Web mapping estático — Interatividade básica através de formulários HTML (im-agem e HTML);

3. Web mapping dinâmico — DHTML (HTML dinâmico) — adi¸cão de recursos que incrementam o dinamismo do mapa.

2.8 Software Livre e de C´

odigo Aberto

No site oficial da Free Software Foundation (Funda¸cão para oSoftware Livre -http://www.fsf.org/ - Acesso em 15/05/2011) é definido como livre o software que pode ser compartilhado, copiado, adaptado, estudado e usado livremente e sem restri¸cões.

Já em OSI (2011), são apresentadas as caracter´ısticas de um Software de código-aberto, que não estão associadas somente à disponibiliza¸cão do código-fonte:

1. Livre distribui¸c˜ao;

2. C´odigo-fonte incluso;

3. Modifica¸c˜oes e trabalhos derivados s˜ao permitidos;

4. A integridade do Autor deve ser preservada;

(23)

6. Sem restri¸c˜oes de uso a campos de trabalho;

7. Distribui¸c˜ao da licensa a todos que utilizem;

8. Sub-componentes dosoftware sob a mesma licen¸ca;

9. Licen¸ca sem restri¸c˜oes a outros softwares;

10. Licen¸ca de tecnologia neutra - sem embasamento em tecnologias ou estilos de inter-faces individuais.

Al´em das facilidades relacionadas ao uso e distribui¸c˜ao dos Softwares Livres, optou-se neste trabalho pela escolha de ferramentas que perten¸cam a este contexto para propiciar o desenvolvimento e compartilhamento de novas tecnologias e linhas de pesquisa.

2.9 MapServer

O MapServer ´e um projeto de servidor de mapas de c´odigo-fonte aberto que tem como

objetivo principal a cria¸cão dinâmica de mapas para serem visualizados através de um navegador de Internet. Abaixo, são descritas algumas de suas caracter´ısticas principais, conforme descreve MapServer (2010):

• Visualiza¸c˜ao e consultas a dados matriciais, vetoriais e descritivos;

• Interface com SGBD’s, tais como o PostgreSQL e outras fontes de dados (tais como

web services e shapefiles);

• Suporte a v´arios sistemas operacionais (Windows, Linux, Mac OS X, etc);

• Suporte a v´arias linguagens de programa¸c˜ao (PHP, Python, Perl, Ruby, Java,

.NET);

• Alta qualidade de processamento e sa´ıdas personaliz´aveis.

A Figura 4, adaptada de MapServer (2010), ilustra a arquitetura b´asica de uma

aplica¸c˜ao MapServer, com os diversos tipos de tecnologias que podem ser inclu´ıdas.

(24)

Figura 4: Arquitetura de uma aplica¸c˜ao MapServer. Fonte: (MAPSERVER, 2010).

Na camada central da arquitetura aparece a configura¸cão do mapfile - arquivo texto de configura¸cão que serve de base para a aplica¸cão MapServer - a aplica¸cão MapServer im-plementada em modo CGI ou modo MapScript, cujas defini¸cões serão abordadas adiante, rodando em um servidorweb, como o “Apache” ou o “IIS (Microsoft Internet Information Service)”.

Por fim, na camada inferior, aparece a sa´ıda, que pode ser uma imagem (v´arias

extensões de arquivo são suportadas), uma composi¸cão de página HTML e imagem ou até mesmo interfaces WMS, WFS e WCS (Web Map Services, Web Feature Services e Web Coverage Server, respectivamente). As defini¸cões e padrões para desenvolvimento destas interfaces são definidos pelo OGC (Open Geospatial Consortium), consórcio internacional que define padrões para cria¸cão de objetos espaciais e servi¸cos baseados em localiza¸cão. As defini¸cões podem ser encontradas no site da entidade - http://www.opengeospatial.org (Acesso em 10/09/2011).

2.9.1 MapServer CGI

Numa aplica¸cão em modo CGI (Common Gateway Interface), um programa exe-cutável fica à disposi¸cão no servidorweb da aplica¸cão, e recebe parâmetros para a gera¸cão de uma sa´ıda.

(25)

mapas e dados de sa´ıda. A aplica¸cão requisita a cria¸cão de um mapa, para tanto, envia os parâmetros necessários para gera¸cão do mesmo através de um endere¸co pelo URL (Uniform Resource Locator - em português, localizador universal de recurso). Em um URL, o endere¸co de um recurso em certo servidor é informado pelo lado cliente de uma

aplica¸cão, bem como os parâmetros para a execu¸cão deste recurso. Por fim, o programa executável recebe os parâmetros e gera a respectiva sa´ıda.

2.9.2 MapServer MapScript

No modo MapScript (que funciona sem interven¸cão do modo CGI), o MapServer é utilizado em conjunto com outras linguagens de programa¸cão, tais como PHP, Perl, Python, Ruby, Tcl, Java e .NET, através da inclusão de módulos e bibliotecas. Neste

modo, é poss´ıvel explorar recursos adicionais da linguagem de programa¸cão utilizada, sendo poss´ıvel se obter aplica¸cões mais dinâmicas e complexas.

2.9.3 Mapfile

O mapfile é um arquivo texto de configura¸cão (deve ter a extensão “.map”) que serve de base para a aplica¸cão MapServer. Este arquivo descreve todos os atributos que serão

dispostos no mapa, tais como layers, cores, legendas, formato do arquivo de sa´ıda, dentre outros, bem como onde estão os dados que servirão de base para cria¸cão deste mapa. Este arquivo define os atributos de um mapa estruturados como objetos, o que mantém a implementa¸cão organizada e facilmente personalizável.

Na Listagem 1, um exemplo de mapfile ´e apresentado.

Listagem 1: Exemplo de Mapfile

1 MAP#i n´ıc i o do o b j e t o mapa

2

3 #o p ¸c ˜o e s do mapa e do a r q u i v o de s a´ıd a

4 EXTENT −73.99 −33.75 −28.83 5 . 2 7 5 SIZE 600 400

6 IMAGECOLOR 200 200 230 7 SHAPEPATH " ../ shapefiles " 8

9 LAYER

(26)

13 DATA "55 BR2500gc_SIR " 14

15 CLASS

16 NAME " Limite nacional "

17 STYLE

18 COLOR 250 250 190

19 OUTLINECOLOR 0 0 0

20 END

21 END

22 END

23

24 END #f i n a l do o b j e t o mapa

No mapfile da Listagem 1, pode-se observar os aspectos do respectivo mapa de sa´ıda. Inicialmente, a defini¸cão do objeto principal “MAP”, delimitado ao final por “END”. Em seu escopo, são definidos parâmetros espec´ıficos, como a extensão do mapa em

coorde-nadas, tamanho da imagem de sa´ıda, cor de fundo e caminho dos dados (“EXTENT”, “SIZE”, “IMAGECOLOR” e “SHAPEPATH”, respectivamente). Dentro do objeto prin-cipal ocorre a defini¸cão de um “LAYER”. Em um mapa, pode-se ter a representa¸cão de várias informa¸cões. Por exemplo, consideremos uma cidade: pode-se ter num mapa que

a represente, além da delimita¸cão geográfica, as ruas, as quadras, as casas, os pontos tur´ısticos, os hospitais, etc. Como há várias categorias de informa¸cões, pode-se dividi-las em camadas, também chamadas de layers. Esta divisão é utilizada no MapServer, e ap-resenta várias vantagens, dentre as quais pode-se citar a possibilidade de programa¸cão

estruturada (códigos-fonte mais leg´ıveis), reuso de informa¸cões e aplica¸cões com rep-resenta¸cões visuais bem definidas, onde o usuário pode optar por visualizar os layers individualmente ou agrupados a seu critério. No layer da Listagem 1, são definidos parâmetros espec´ıficos, tais como nome, tipo de dado, visibilidade e arquivo de origem (“NAME”, “TYPE”, “STATUS” e “DATA”, respectivamente). Por fim, em um layer

deve-se definir uma ou mais classes de representa¸cões temáticas, onde são definidos estilos de representa¸cão temática. No exemplo já citado, é definida uma classe de representa¸cão

(27)

2.10 Shapefile

Regulamentado pela “Environmental Systems Research Institute, Inc.” (ESRI), o shapefile é um tipo de arquivo bastante utilizado para Sistemas de Informa¸cão Geográfica.

Embora perten¸ca a uma corpora¸cão privada, sua especifica¸cão, está dispon´ıvel gratuita-mente, e permite que outras ferramentas o implementem. Este tipo de arquivo representa as estruturas espaciais através de um conjunto de dados em vários formatos, cujos prin-cipais possuem a extensão “.shp”, “.dbf” e “.shx”. Estes arquivos indicam seus atributos

n˜ao-espaciais e suas geometrias, conforme definido em ESRI (1998).

2.11 p.mapper

O p.mapper é uma ferramenta para visualiza¸cão de aplica¸cões MapServer baseado em php/mapscript, com recursos javascript. Possui diversosplugins configuráveis, dentre eles, para realiza¸cão de consultas de atributos descritivos. Sua configura¸cão com o MapServer

é realizada através de um arquivo XML (Extensible Markup Language) - uma linguagem de demarca¸cão destinada principalmente a compartilhamento de informa¸cões. É poss´ıvel editar a interface de acordo com os layers utilizados na aplia¸cão desejada, basta efetuar as configura¸cões de acordo com o mapfile utilizado. De natureza livre, pode ser baixado

gratuitamente em seu site oficial (http://www.pmapper.net/ - Acesso em 12/11/2011). Na Figura 5, uma demonstra¸c˜ao de interface do p.mapper ´e apresentada.

(28)

2.12 PHP

PHP é uma linguagem de scripting de ampla utiliza¸cão, interpretada, que é especial-mente interessante para desenvolvimento para aweb e pode ser mesclada dentro do código HTML (PHP, 2011). Sua sintaxe se assemelha à de outras linguagens de programa¸cão, tais como C e Java. Esta linguagem é interpretada no lado servidor da aplica¸cão (server-side), e, com seus recursos, é poss´ıvel criar páginaswebatravés de técnicas e recursos avan¸cados de programa¸cão, obtendo resultados rapidamente.

2.13 Javascript e jQuery

Javascript é uma linguagem de scripting utilizada para incrementar aplica¸cões web. Assim como em PHP, seu código pode ser embutido em páginas HTML. A principal diferen¸ca está no modo de funcionamento: enquanto PHP é interpretada no lado servi-dor, Javascript é executada no lado cliente (client-side), sendo então interpretada por navegadores de internet. Cabe observar que Javascript e Java são duas linguagens de programa¸cão distintas.

Com seu uso, é poss´ıvel a obten¸cão de caracter´ısticas mais dinâmicas às páginas, tais como: a¸cões por movimentos do mouse, navega¸cão entre janelas personalizadas, efeitos visuais, dentre outras op¸cões. A biblioteca jQuery é constru´ıda sobre a linguagem

Javascript, e adiciona ainda mais recursos de dinamismo no lado cliente de uma aplica¸c˜ao

web.

2.14 PHPlot

PHPlot é uma biblioteca gráfica que permite a cria¸cão de gráficos dinâmicos para a linguagem PHP. Ela oferece a cria¸cão dos principais tipos de gráficos, tais como gráficos de linha, barras, pontos e pizza. Seu uso, resumidamente, consiste na inclusão dos pacotes

(29)

Cap´ıtulo

3

Concep¸c˜

ao do Projeto

Antes da concep¸cão do projeto, foi evidenciado junto à equipe do projeto ambiental que a constru¸cão de um sistema de controle de arboriza¸cão faz parte do propósito deste

Trabalho de Conclusão de Curso, sendo um subproduto do mesmo, e que o foco principal do trabalho é a realiza¸cão de pesquisa e integra¸cão acerca de tecnologias livres existentes de modo a alcan¸car os objetivos propostos neste Cap´ıtulo.

3.1 Obten¸c˜

ao e An´

alise de Requisitos

A defini¸c˜ao de requisitos para este sistema foi definida em conjunto com os

respon-sáveis pelo projeto ambiental. Foram realizadas duas reuniões. Na primeira reunião, foi realizada uma entrevista com a Engenheira Agrônoma responsável pelo projeto, onde foram respondidas as seguintes questões:

1. Qual o objetivo do projeto?

O objetivo é saber a situa¸cão real da arboriza¸cão na cidade, quais espécies estão presentes, quais árvores e espécies serão substitu´ıdas e/ou introduzidas (o objetivo é ter o m´ınimo 10 espécies no munic´ıpio) e quais locais carecem de mais arboriza¸cão.

Uma melhor arboriza¸cão pode influenciar no clima (já que a cidade é muito quente) e é também uma questão de saúde pública. A ideia é futuramente centralizar também as solicita¸cões de corte e poda, no entanto, ainda não há estrutura para tal finalidade.

2. Como vem sendo feita a cataloga¸c˜ao das ´arvores?

Um mapa da cidade foi setorizado em quadras identificadas por n´umeros. Uma

(30)

tirando uma foto de cada uma.

3. Quais as informa¸cões das árvores estão sendo coletadas?

• Coordenadas - obtida com GPS (coordenadas em quilˆometros, proje¸c˜ao: UTM);

• Nome popular da esp´ecie da ´arvore;

• Nome cient´ıfico da esp´ecie da ´arvore;

• DAP - diˆametro na altura do peito;

• Fuste - altura do tronco da árvore até as primeiras ramifica¸cões;

• Proje¸cão de copa - área de sombra da árvore, tendo como parâmetro de medi¸cão o horário do meio dia;

• Sanidade - estado de saúda da árvore. Existem equipamentos capazes de “es-canear” a árvore para verificar a integridade do seu interior. No entanto, a equipe ainda não dispõe desta tecnologia, e a sanidade foi definida visualmente;

• Foto - uma foto para cada ´arvore, tirada em alta resolu¸c˜ao (cinco megapixels).

4. Quais árvores são objeto desta cataloga¸cão? Cal¸cadas, canteiros centrais, pra¸cas públicas, quintais?

Somente as árvores das cal¸cadas das quadras e das pra¸cas e áreas públicas livres.

Para as árvores dos canteiros centrais, houve um in´ıcio de trabalho semelhante, mas não houve conclusão. A ideia é que futuramente, estas árvores também sejam objeto de catálogo.

5. Poss´ıveis novas ruas e/ou ´areas/quadras ser˜ao adicionadas no mapa da cidade?

Por enquanto não, pois o projeto servirá de base para elabora¸cão de um novo plano de plantio na cidade, e nesta etapa de trabalho, o mapa existente é suficiente para tal fim.

6. Quais as caracter´ısticas do mapa e do GPS utilizados?

Foi utilizado um mapa constru´ıdo em software de desenho assistido por computa-dor (computer aided design - CAD), em escala 1:5000 e formato “DWG”. O GPS utilizado possui baixa precis˜ao.

7. O projeto tem ciˆencia da falta de precis˜ao do mapa e do GPS utilizados?

(31)

8. O sistema será acess´ıvel à popula¸cão?

Inicialmente, a ideia é que o sistema seja utilizado pela equipe do projeto. Futura-mente, a ideia é que a popula¸cão possa visualizar estas árvores no mapa da cidade através da Internet, e também realizar os pedidos de poda e corte através do sistema.

No entanto, ainda n˜ao temos estrutura suficiente para tal (espa¸co, equipamentos e funcion´arios).

9. Serão realizadas novas “vistorias” nas árvores? Existirá uma equipe para tal fun¸cão? Atualmente está sendo feita uma única vistoria em cada árvore, através do percurso

inicial da equipe de campo pelas quadras da cidade. Com o apoio do sistema, o objetivo é que novas vistorias em árvores já catalogadas sejam realizadas, princi-palmente em árvores mais antigas e que estão em sanidade ruim, inclusive, tirando novas fotos das mesmas.

10. E quando uma ´arvore for arrancada?

Quando uma árvore é arrancada, a responsabilidade do morador ou responsável é de se plantar pelo menos uma nova espécie. Na impossibilidade de se plantar no mesmo lugar, o plantio pode ser feito em outro local indicado pelo mesmo.

11. Existe a ideia de armazenar outras informa¸cões além das árvores? Ex: focos de

dengue, acidentes, etc.?

Por enquanto, somente a arboriza¸c˜ao. Existe a expectativa de trabalhos futuros para mapeamento das nascentes do munic´ıpio.

12. Existe um esquema de visualiza¸cão desejado? A ideia é que as árvores sejam

rep-resentadas por pontos no mapa, e as esp´ecies sejam identificadas por cores. Desta forma, ao simplesmente visualizar o mapa, a equipe poder´a identificar alguns dos aspectos desejados, por exemplo:

• Quadras ou ´areas com poucas ´arvores;

• Quadras ou ´areas com pouca diversidade de esp´ecies;

• Ausência de certas espécies em áreas potenciais.

13. Quais tipos de relatórios e/ou gráficos são desejados? ´

E desej´avel que seja poss´ıvel obter, a princ´ıpio:

• Distribui¸c˜ao de esp´ecies;

(32)

• Somatório da proje¸cão de copa, para estimar a área verde;

• Rela¸c˜ao de substitui¸c˜oes pendentes.

A partir desta entrevista, foi poss´ıvel extrair um aspecto importante. Devido à im-precisão do mapa e também do GPS, a localiza¸cão das árvores será distorcida, logo, serão necessários mecanismos de corre¸cão manual. Com base nesta entrevista e na imprecisão do mapa e das coordenadas, foram definidos os seguintes requisitos:

1. O sistema deve manter as informa¸c˜oes coletadas sobre as ´arvores em um banco de dados;

2. O sistema deve representar as árvores como pontos sobre o mapa da cidade, identificando-as por pontos de referênciidentificando-as (como quadridentificando-as e pra¸cidentificando-as), sendo que identificando-as espécies devem

ser diferenciadas por cores;

3. O sistema deve permitir a corre¸cão manual de posicionamento das árvores, devido a poss´ıveis distor¸cões causadas pela falta de precisão do GPS e do mapa;

4. O sistema deve armazenar as informa¸c˜oes obtidas nas vistorias das ´arvores,

man-tendo os parˆametros espec´ıficos (DAP, Fuste, Proje¸c˜ao de Copa e Sanidade) e a foto da mesma em um banco de dados;

5. O sistema deve manter as informa¸cões de uma árvore arrancada, bem como a defini¸cão da(s) árvore(s) substituta(s);

6. O sistema deve identificar quais as ´arvores pertencem a um certo cat´alogo, com a

finalidade de quantificar o plantio de ´arvores realizado em certo per´ıodo de tempo ou categoria de origem, sendo poss´ıvel obter os seguintes parˆametros:

• Distribui¸c˜ao de esp´ecies;

• Médias sobre os parâmetros espec´ıficos das árvores;

• Somatório da proje¸cão de copa, para estimar a área verde;

• Rela¸cão de substitui¸cões de árvores pendentes.

(33)

3.2 Modelagem

Ap´os a defini¸c˜ao dos requisitos, o projeto foi definido e modelado e um diagrama de classes - mostrado na Figura 6 - foi elaborado.

Figura 6: Diagrama de classes do Sistema

O MapServer e suas funcionalidades foram resumidos na classe “php-mapscript”. Isto

se deve ao fato de que a ferramenta pode ser embutida em uma linguagem de programa¸c˜ao (no caso, PHP), desta forma, pode-se explorar os seus recursos e funcionalidades, em conjunto com os recursos da linguagem de programa¸c˜ao escolhida.

Ao centro, a classe “Arvore”, tendo como atributos sua localiza¸cão real (obtida pelo GPS), sua coordenada ajustada (em caso de distor¸cão) e o status, para identificar se trata-se de árvore viva ou arrancada/substitu´ıda, conforme rela¸cão com a classe

“Substi-tui¸cão”. A classe “PontoReferência” representa as quadras e pra¸cas as quais as árvores estão vinculadas. Da mesma forma, há v´ınculos com a espécie e catálogo de origem da árvore - classes “Espécie” e “Catalogo” - todas rela¸cões de cardinalidade 1 para 1. Por fim, a classe “Vistoria” foi criada para representar os dados das árvores coletados pela

(34)

Cap´ıtulo

4

Integra¸c˜

ao das Ferramentas

Neste Cap´ıtulo, será mostrada a integra¸cão das ferramentas utilizadas para a solu¸cão do problema proposto. Algumas peculiaridades podem ser observadas, principalmente na

se¸cão referente à integra¸cão do banco de dados com o MapServer.

4.1 Estrutura da Aplica¸c˜

ao

Após a defini¸cão do projeto, passamos então ao principal propósito deste trabalho, a integra¸cão das ferramentas utilizadas. Simplificando a arquitetura de uma aplica¸cão

MapServer conforme descrito na Se¸c˜ao 2.9 (p. 22) para o contexto deste trabalho, obtemos o esquema da Figura 7.

Na camada de entrada, temos o mapa da cidade em formato “shapefile”, além dos novos dados adicionados para representa¸cão das árvores, através do banco de dados PostgreSQL e sua extensão espacial PostGIS. Em seguida, na camada central, temos

a configura¸cão e ambiente de execu¸cão: configura¸cão do mapfile que define a sa´ıda gráfica do mapa, e a aplica¸cão constru´ıda com o MapServer modo mapscript rodando sobre o servidor web Apache. Por fim, na sa´ıda, temos a interface DHTML (mapa e editor de dados espaciais e descritivos).

4.2 Banco de Dados e MapServer

(35)

Figura 7: Arquitetura da aplica¸c˜ao MapServer para este contexto. Adaptada de (MAPSERVER, 2010).

4.2.1 Criando um banco de dados espacial com

PostgreSQL/-PostGIS

Com o PostgreSQL e sua extensão espacial PostGIS, é poss´ıvel armazenar e manipular tanto os componentes descritivos e espaciais da informa¸cão. É necessária a cria¸cão de uma instância de banco de dados PostgreSQL e habilita¸cão de sua extensão espacial PostGIS, obtendo um banco de dados“spatially enabled”. Dentre as várias op¸cões a seguir, pode-se, primeiramente, criar um banco de dados convencional. Em seguida, basta associá-lo ao PostGIS e às suas fun¸cões pré-definidas através do uso do “template postgis” . Este template funciona como um modelo que pode ser associado a uma instância de banco de dados no ato da cria¸cão do mesma, com um simples comando visto na Listagem 2.

Listagem 2: Instru¸c˜ao SQL para cria¸c˜ao de um banco de dados espacial

1 create d a t a b a s e exemplo db t e m p l a t e = t e m p l a t e p o s t g i s

Este comando cria o banco de dados “exemplo db” e já o habilita a trabalhar com dados espaciais (spatially enabled), associando-o ao “template postgis”. Ao habilitar o PostGIS em uma instância de banco de dados, duas tabelas são criadas automaticamente: “spatial ref sys” e “geometry columns”.

(36)

re-ferência espaciais definidos pela institui¸cão “European Petroleon Survey Group” (EPSG), que os mantém e os publica.

Já a tabela “geometry columns” mantém registros de tabelas com colunas espaciais. Estes registros são utilizados por outras aplica¸cões que acessam o banco de dados (como o MapServer).

Estas tabelas são denominadas “tabelas de metadados” e são criadas de acordo com as especifica¸cões definidas pelo OGC. São essenciais para a consistência dos dados e

in-teroperabilidade.

4.2.2 Garantindo a Interoperabilidade com o MapServer

Para cria¸cão de uma tabela espacial destinada a receber consultas de aplica¸cões MapServer, é necessário que se utilize a fun¸cão do PostGIS “AddGeometryColumn” para especificar colunas espaciais. A justificativa é que esta fun¸cão adiciona automaticamente registros com parâmetros espec´ıficos na tabela de metadados “geometry columns”, que

é utilizada por outras ferramentas que utilizam o PostGIS, dentre elas, o MapServer, e também por fun¸cões do próprio PostGIS. Caso o usuário não utilize esta fun¸cão, a comu-nica¸cão entre o MapServer e o banco de dados PostgreSql/PostGIS pode ser prejudicada, resultando em erros na aplica¸cão final. É importante também que se utilize a primeira

coluna da tabela para armazenar o identificador de cada registro, pois algumas fun¸c˜oes de consulta espacial do MapServer retornam somente a primeira coluna como resultado.

Na Listagem 3, um exemplo de cria¸c˜ao de tabela.

Listagem 3: Instru¸c˜ao SQL para cria¸c˜ao de uma tabela com dado espacial

1 create table v i a s (

2 ID s e r i a l not n u l l PRIMARY KEY, 3 nome varchar( 2 5 ) ,

4 t i p o varchar( 2 5 ) 5 ) ;

6 s e l e c t AddGeometryColumn (’vias ’, ’vias_geom ’, −1, ’ LINESTRING ’, 2 ) ;

O comando acima cria a tabela vias com as colunas especificadas (ID, nome e tipo), em seguida, adiciona a esta tabela uma coluna espacial denominada ’vias geom’. Os parâmetros da fun¸cão “AddGeometryColumn” são:

(37)

• TABLE NAME - nome da tabela em que ser´a inserida coluna do tipo geometry;

• COLUMN NAME - nome da coluna que receber´a os dados tipo geometry;

• SRID - identificador do SRS para a tabela;

• TYPE - tipo de dado (POLYGON, POINT, LINESTRING, etc.);

• DIMENSION - dimensão da coluna (2, 3 ou 4 dimensões são suportadas).

4.2.3 Inser¸c˜

ao de dados de natureza espacial

Para inser¸c˜ao de dados em grande quantidade num banco de dados espacial no

Post-greSQL/PostGIS, pode-se utilizar o utilitário para carga de shapefiles “shp2pgsql”. O utilitário converte os shapefiles em comandos SQL adequados para a inser¸cão dos da-dos no banco, excluindo-se a necessidade de inser¸cão manual de cada registro. Ele possui várias configura¸cões de execu¸cão, pelas quais é poss´ıvel optar pela cria¸cão de novas tabelas

para os dados ou inser¸cão dos dados em tabelas existentes. O programa é executado via linha de comando, e as op¸cões são escolhidas através de “flags”, que são conjuntos de caracteres que identificam cada op¸cão. Contudo, neste trabalho, devido à imprecisão de coordenadas já citada anteriormente, a inser¸cão dos dados através do utilitário de carga

não foi pertinente. Desta forma, houve a necessidade de se proceder à inser¸cão manual de cada registro.

Para a inser¸cão de dados em tabela espacial, deve-se utilizar comandos SQL INSERT (assim como nas tabelas de atributos não espaciais), e, o único diferencial está na utiliza¸cão da fun¸cão do PostGIS “St GeomFromText”. Esta fun¸cão é utilizada para se criar objetos

de tipos espaciais aceitos pelo PostGIS à partir da representa¸cão OGC WKT (WKT vem do inglês “well-known-text” - descri¸cão textual). Um exemplo é mostrado na Listagem 4.

1 i n s e r t into p o n t o o n i b u s ( ID , b a i r r o , the geom ) values ( 1 0 , ’Centro ’,

St GeomFromText (’POINT (7543533 467721) ’,−1) ) ;

(38)

4.2.4 Consulta a dados de natureza espacial

Se, para adicionar um dado de natureza espacial no banco de dados à partir de uma representa¸cão textual é necessário convertê-lo em um objeto espacial, para consultá-lo,

deve-se fazer o inverso, ou seja, converter o objeto espacial em representa¸cão textual. Para esta a¸cão utiliza-se a fun¸cão “St asText”. Na Listagem 5, um exemplo é mostrado.

1 s e l e c t ID , b a i r r o , S t a s T e x t ( the geom ) from p o n t o o n i b u s

A defini¸cão dos parâmetros destas fun¸cões pode ser consultada na documenta¸cão do PostGIS.

4.3 Interface de Navega¸c˜

ao e Edi¸c˜

ao -

PHP/map-script

O p.mapper, conforme descrito na Se¸cão 2.11 (p. 26), é um poderoso visualizador que permite, inclusive, a realiza¸cão de consultas aos dados descritivos das informa¸cões espaci-ais. No entanto, para manipula¸cão destes dados (inser¸cão, exclusão ou atualiza¸cão), não

há suporte nativo nesta ferramenta (de fato, sua natureza sugere apenas a visualiza¸cão). Logo, no contexto de nosso trabalho, considerando-se também a necessidade de se realizar opera¸cões de ajustes de coordenadas, optou-se então pelo desenvolvimento de uma nova interface que abrangesse navega¸cão e edi¸cão. Desta forma, foi necessário integrar

fun-cionalidades de navega¸cão pelo mapa, tais como zoom e pan, e também de manipula¸cão de dados descritivos e espaciais.

4.3.1 Mapa dinˆ

amico

Conforme citado na Se¸cão 2.7 (p. 21), o web mapping dinâmico está relacionado à interatividade através de recursos DHTML. E conforme pode-se observar na Se¸cão 2.5 (p.

19), a estrutura de uma aplica¸c˜ao baseia-se no formato de requisi¸c˜oes e respostas.

Desta forma, para propiciar um mapa dinˆamico, seguindo estes preceitos, a solu¸c˜ao

(39)

formulário por algum botão definido. Quando uma destas a¸cões ocorre, os parâmetros são enviados ao MapServer (requisi¸cão) para que seja retornado um novo mapa (resposta), obtendo o aspecto de dinamismo esperado.

A Figura 8 exibe a interface constru´ıda: à esquerda, a barra de ferramentas cujas op¸cões serão definidas neste Cap´ıtulo. Ao centro, o mapa navegável com suporte à adi¸cão de dados espaciais (pontos de referência e árvores). À direita, a interface de sele¸cão de

layers e o mapa em miniatura para referência de visualiza¸cão. Abaixo, a interface de exibi¸cão e edi¸cão de atributos descritivos.

Figura 8: Interface de navega¸c˜ao e edi¸c˜ao implementada

4.3.2 Propriedade “EXTENT” de um mapa

Em um mapfile, deve-se definir a propriedade “EXTENT” (extensão), conforme pode ser visto na Listagem 1 (p. 24). Esta propriedade indica ao MapServer qual a extensão geográfica do mapa que será projetado, tomando como base a unidade de medida em que

o mapa se encontra (por exemplo, kilômetros ou graus decimais) e também o sistema de referência espacial utilizado. A extensão é definida por um retângulo que envolve toda a área do mapa, e é delimitado pelos pontos [min x, min y] e [max x, max y]. Pode-se verificar na Figura 9 como seria a delimita¸cão para o pol´ıgono em azul:

Concluindo, o valor para o parˆametro “EXTENT” que seja suficiente para exibir todo

(40)

Figura 9: Demonstra¸c˜ao da propriedade extent

medidas de “EXTENT”, a imagem pode ser cortada ou aproximada (retˆangulo menor que

a imagem) ou receber um aspecto de distanciamento (retângulo maior que a imagem). Cabe notar que, em um mapa com muitas camadas, esta propriedade deve ser definida de acordo com a extensão da maior delas, para não causar preju´ızo de informa¸cão.

Pode-se obter a extensão de um mapa armazenado no banco de dados PostGIS aplicando a fun¸cão “ST Extent”, que retornará o menor retângulo delimitador de um

pol´ıgono. Também é poss´ıvel obter a propriedade a partir de shapefiles com o utilitário “ogrinfo”, sem a necessidade de carregá-los no banco de dados para obten¸cão de tal parâmetro. Este utilitário é provido pela biblioteca GDAL, e mais detalhes podem ser consultados em seu site http://www.gdal.org/ - Acesso em 12/11/2011. Na Listagem 6,

o resultado da execu¸cão do utilitário “ogrinfo” para obten¸cão da extensão do mapa da cidade utilizado.

Listagem 6: Execu¸cão do utilitário para obten¸cão da extensão de um mapa

1 C:\ms4w\t o o l s\gdal−ogr>o g r i n f o −s o c : / ms4w/ apps / r e g e n t e / m a p f i l e s / shape /mapa

. shp mapa

2 INFO : Open o f ‘ c : / ms4w/ apps / r e g e n t e / m a p f i l e s / shape /mapa . shp’ 3 using driver ‘ESRI Shapefile ’ s u c c e s s f u l .

4

5 Layer name : mapa 6 Geometry : Li ne S t r i n g 7 F e a t u r e Count : 262

8 Extent : ( 4 6 6 8 5 2 . 7 5 5 5 1 6 , 7 5 4 0 6 3 1 . 9 1 3 1 3 2 ) − ( 4 6 9 6 8 6 . 6 4 9 2 9 9 , 7 5 4 4 8 4 1 . 6 7 1 8 2 2 ) 9 Layer SRS WKT:

10 ( unknown )

(41)

14 i d : I n t e g e r ( 4 . 0 )

Concluindo, o parâmetro “EXTENT” é essencial para opera¸cões de navega¸cão em

um mapa. Estas opera¸cões foram criadas através de a¸cões do mouse sobre o mesmo. Ao clicar numa posi¸cão do mapa, as coordenadas da posi¸cão (em pixels) são enviadas através do formulário HTML. Muitas das funcionalidades do MapServer requerem que estas co-ordenadas (em pixels) sejam convertidas na mesma unidade de medida do mapa. Esta

conversão é feita com base numa regra de três simples, tomando-se como base o tamanho da imagem (em pixels) e o valor “EXTENT” do mapa atual. A fun¸cão “click2map” -mostrada na Listagem 7 - adaptada à partir da sugestão dispon´ıvel na documenta¸cão do MapServer, efetua esta conversão.

Listagem 7: Fun¸cão para conversão de coordenadas de imagem em coordenadas ge-ográficas

1 f u n c t i o n c l i c k 2 m a p ( $map , $ c l i c k f i g ) { 2 $ex = ms newRectObj ( ) ;

3 $ex = $map−>e x t e n t ; 4

5 $ x p c t = ( $ c l i c k f i g−>x / $map−>width ) ; 6 $ y p c t = 1 − ( $ c l i c k f i g−>y / $map−>h e i g h t ) ; 7

8 $x map = $ex−>minx + ( ( $ex−>maxx − $ex−>minx ) ∗ $ x p c t ) ; 9 $y map = $ex−>miny + ( ( $ex−>maxy − $ex−>miny ) ∗ $ y p c t ) ; 10

11 $ p o i n t g e o = ms newPointObj ( ) ;

12 $ p o i n t g e o−>setXY ( ( i n t ) $x map , ( i n t ) $y map ) ; 13

14 r e t u r n $ p o i n t g e o ; 15 }

Na ocorrência de aplica¸cões de zoom ou pan sobre o mapa, um novo valor “EX-TENT” é calculado com base no mesmo parâmetro do mapa em tela. Desta forma, para cada atualiza¸cão do formulário, o referido parâmetro deve ser armazendo para garantir a integridade destes cálculos. Para tanto, foi utilizado um campo de formulário oculto

(“hidden”) para armazenar tal valor, e, na ocorrência de opera¸cões de deslocamento sobre o mapa, uma fun¸cão foi utilizada para obter o parâmetro do formulário e atualizar no novo mapa. Esta fun¸cão é definida na Listagem 8.

Listagem 8: Fun¸c˜ao atualizar extent

(42)

2

3 #s e p a r a v a l o r num v e t o r

4 $aux = explode(" ", $ n o v o e x t e n t ) ; 5

6 #a t u a l i z a o e x t e n t do mapa a t u a l

7 $mapa−>s e t e x t e n t ( $aux [ 0 ] , $aux [ 1 ] , $aux [ 2 ] , $aux [ 3 ] ) ; 8

9 r e t u r n $mapa ; 10

11 }

4.3.3 Zoom

A implementa¸cão das funcionalidades zoom in e zoom out foi baseada na fun¸cão do MapServer “zoomPoint”. Esta fun¸cão realiza uma opera¸cão que calcula uma nova ex-tensão para o mapa, resultando em um aspecto de aproxima¸cão (zoom in), distanciamento (zoom out), ou ainda, a recentraliza¸cão. São parâmetros desta fun¸cão:

• Fator de zoom: valor 1 resulta em centraliza¸cão (utilizado em opera¸cões de fun-cionalidade pan), valores positivos e maiores que um resultarão em opera¸cão zoom in, e negativos resultarão em zoom out;

• Posi¸c˜ao do clique: coordenadas da imagem (em pixels) que receberam o clique;

• Largura e Altura: medidas da imagem do mapa em pixels;

• Extens˜ao: parˆametro “extent” do mapa atual.

´

E conveniente em aplica¸c˜oes com mapas fixar limites para aproxima¸c˜ao ou

distancia-mento, para evitar visualiza¸cões exageradas e processamento desnecessário. Para efetuar esta limita¸cão, foram fixados valores m´ınimos e máximos de escala, desta forma, ao aplicar uma opera¸cão de zoom, deve-se verificar se os limites fixados foram ultrapassados. Caso isso ocorra, a opera¸cão não deve ser realizada. A escala atual de um mapa pode ser obtida

pelo parˆametro “SCALEDENOM”.

(43)

4.3.3.1 Zoom pontual

Ozoom pontual foi implementado na forma original da fun¸cão “zoomPoint”. Ao clicar sobre o mapa, é aplicado zoom sobre aquela posi¸cão. A Listagem 9 mostra o trecho de código referente à aplica¸cão dozoom pontual.

Listagem 9: Bloco de execu¸c˜ao de zoom pontual

1 case ’zoom_in ’:{ // a p l i c a zoom f a t o r 2

2 $map−>zoompoint ( 2 , $ c l i c k f i g u r a , $map−>width , $map−>h e i g h t

, $map−>e x t e n t ) ; // a p l i c a zoom

3 i f( $map−>scaledenom < MAX SCALE){ // c a s o u l t r a p a s s e a

e s c a l a l i m i t e

4 $map=a t u a l i z a r E x t e n t ( $map , $ REQUEST [’extent ’] ) ; //

d e s f a z operacao , r e t o r n a n d o ao u l t i m o v a l o r e x t e n t

5 $ w a r n i n g s [ ] =" Limite de zoom m´aximo atingido .";

6 }

7 i n c l u d e o n c e ’ redesenha_selecao ’; // mantem e v e n t u a i s

componentes s e l e c i o n a d o s

8 }break; 9

10 case ’zoom_out ’:{ // a p l i c a zoom f a t o r −2

11 $map−>zoompoint (−2 , $ c l i c k f i g u r a , $map−>width , $map−>h e i g h t

, $map−>e x t e n t ) ;

12 i f( $map−>scaledenom > MIN SCALE){

13 $map=a t u a l i z a r E x t e n t ( $map , $ REQUEST [’extent ’] ) ; 14 $ w a r n i n g s [ ] =" Limite de zoom m´ınimo atingido .";

15 }

16 i n c l u d e o n c e ’ reposiciona_mapa . php ’; 17 }break;

Após a execu¸cão de opera¸cões de zoom, é desejável que eventuais sele¸cões (de árvores ou pontos) feitas pelo usuário sejam mantidas. Esta propriedade foi implementada de maneira simples, obedecendo-se a seguinte lógica: caso houvesse uma sele¸cão ativa na

interface anterior, desenha-se a mesma sele¸c˜ao no novo mapa.

4.3.3.2 Zoom por rolagem de mouse

(44)

• Obter a dire¸cão da rolagem do mouse para determinar se a opera¸cão será de zoom in ouzoom out;

• Obter as coordenadas da imagem no ato da rolagem do mouse, para executar a opera¸c˜ao de zoom naquela posi¸c˜ao.

Para implementa¸cão desta funcionalidade, foi necessário utilizar recursos Javascript - definidos na Se¸cão 2.13. Foi utilizada a biblioteca jQuery “Mousewheel”, que atribui

um valor delta à rolagem do mouse, onde a dire¸cão da rolagem é diferenciada por delta positivo ou delta negativo. Em seguida, basta se seguir o procedimento do zoom pontual de acordo com o resultado do valor delta.

4.3.3.3 Zoom por retˆangulo

Foi verificada também a necessidade de se implementar uma opera¸cão de zoom por sele¸cão de área, através do recurso de clicar, arrastar e soltar do mouse, delimitando um retângulo. De fato, esta opera¸cão agiliza a navega¸cão pelo mapa.

O MapServer possui uma fun¸cão para realiza¸cão de zoom por retângulo -

“zoomRect-angle”. A fun¸cão é similar à “zoomPoint”, e a única diferen¸ca deve se ao fato de que, ao invés de se passar como parâmetro a posi¸cão clicada, deve-se passar como parâmetro a delimita¸cão do retângulo. Este retângulo deve ser definido pelas coordenadas limites [min x, min y] e [max x, max y], empixels.

Logo, para implementa¸cão desta funcionalidade, também foi necessário utilizar Javascript para habilitar os recursos de arrastar e soltar do mouse, que não são nativos aos

naveg-adores web atuais. Foi utilizada a bibliteca jQuery “imgAreaSelect”, que, dentre outras funcionalidades, permite a sele¸cão de uma área em um componente de imagem definido em uma páginaweb. A Listagem 10 demonstra o uso da biblioteca.

Listagem 10: Javascript imgAreaSelect

1 $ (’input # mapa ’) . i m g A r e a S e l e c t ({ 2 autoHide : true,

3 f a d e S p e e d : 3 0 0 , 4

5 o n S e l e c t S t a r t : f u n c t i o n ( input , s e l e c t i o n ){ 6 i n i x=s e l e c t i o n . x1 ;

7 i n i y=s e l e c t i o n . y1 ;

8 },

(45)

10 i f ( s e l e c t i o n . x1 == i n i x ) f i n a l x = s e l e c t i o n . x2 ; 11 e l s e f i n a l x=s e l e c t i o n . x1 ;

12

13 i f( s e l e c t i o n . y1 == i n i y ) f i n a l y = s e l e c t i o n . y2 ; 14 e l s e f i n a l y = s e l e c t i o n . y1 ;

15

16 g e t (" rect_zoom ") . v a l u e=i n i x+’ ’+ i n i y+ ’ ’+f i n a l x + ’ ’ +

f i n a l y ;

17 // g e t (” w a r n i n g s ”) . innerHTML=i n i x +’ ’+ i n i y+ ’ ’+ f i n a l x + ’ ’ +

f i n a l y ;

18 submit ( ) ;

19 } // on s e l e c t end

20 }) ;

4.3.4 Pan

Esta opera¸cão foi a mais complexa de ser implementada, já que não há fun¸cão “na-tiva” ao MapServer para realiza¸cão desta funcionalidade (também chamada de ferramenta

“mão”). Em solu¸cão proposta em MapServer (2010), a funcionalidade de recentraliza¸cão é proposta, baseada na fun¸cão “zoomPoint” com fator 1, conforme descrito na Se¸cão 4.3.3.

Primeiramente, observemos na Figura 10 a funcionalidade aplicada a um ponto clicado P1.

Figura 10: Comportamento da funcionalidade pan numa posi¸c˜ao clicada

Pode-se observar o aspecto de recentraliza¸cão: ao clicar numa posi¸cão P1 - Figura 10 a), a mesma é deslocada para o centro da imagem - Figura 10 b). Neste cenário, todo o restante de um mapa também seria deslocado.

(46)

semelhantes, a funcionalidade é ativada através dos recursos de arrastar e soltar do mouse sobre a imagem (assim como na funcionalidade de zoom por retângulo), no qual espera-se que o usuário clique numa posi¸cão de origem e arraste até uma posi¸cão de destino.

Logo, a biblioteca jQuery “imgAreaSelect” também pode ser utilizada para capturar as posi¸cões de origem e de destino. Aplicando-se a fun¸cão “zoomPoint” com fator 1 na coordenada de destino, a solu¸cão desejada para a funcionalidade pan não é satisfeita, conforme pode-se observar na Figura 11, onde P1 é origem e P2 é destino.

Figura 11: Comportamento da funcionalidade pan na coordenada de destino

Conclui-se que para o sucesso da opera¸c˜ao, pelo menos duas opera¸c˜oes de

desloca-mento através da fun¸cão “zoomPoint” com fator 1 são necessários. A solu¸cão foi en-contrada, e é exibida na Figura 12, onde a sequência de imagens ilustra as seguintes opera¸cões:

• Obter o ponto inicial P1 (onde o mouse foi clicado) e o ponto final P2 (onde o mouse foi soltado) - Figura 12 a);

• Aplicar a funcionalidade pan no ponto inicial - Figura 12 b);

• Obter o ponto P2A com coordenadas reversas de P2 - Figura 12 c);

• Aplicar a funcionalidade pan neste ponto - Figura 12 d).

(47)

Figura 12: Opera¸c˜oes de deslocamento para satisfazer a funcionalidade pan

4.3.5 Op¸c˜

ao novo ponto de referˆ

encia

Para inser¸cão de um novo ponto de referência (como quadras ou pra¸cas), a seguinte lógica foi idealizada:

1. Clicar na posi¸cão desejada, suas coordenadas numéricas serão exibidas em campos de texto e um novo ponto virtual com a legenda “new” aparecerá no mapa;

2. Definir um rótulo identificador para o ponto (por exemplo, número da quadra ou nome da pra¸ca), através de um campo de texto;

3. Salvar o ponto no banco de dados atrav´es de um bot˜ao “salvar”.

Para exibir o ponto clicado como um novo elemento no mapa, deve-se instanciar este

ponto como um novo objeto do MapServer tipo “point” e aplicar a fun¸c˜ao “draw”, que recebe como parˆametros:

• Mapa: o objeto mapa de destino;

• Layer: o objeto layer em que o ponto ser´a renderizado;

• Classe: o objeto classe de estilo para representa¸c˜ao do ponto;

• Texto: representa¸c˜ao textual para anotar o ponto.

Na Figura 13, o detalhe da interface para cria¸c˜ao de um novo ponto de referˆencia.

4.3.6 Op¸c˜

ao de Edi¸c˜

ao de Ponto de Referˆ

encia

(48)

Figura 13: Op¸c˜ao de novo ponto de referˆencia

1. Clicar sobre o ponto desejado para selecion´a-lo, um c´ırculo de sele¸c˜ao deve aparecer;

2. Clicar em uma nova posi¸c˜ao, caso se trate de ajuste de coordenadas, e/ou editar componentes descritivos no campo de texto;

3. Atualizar os dados, atrav´es de um bot˜ao “atualizar”.

Para selecionar um ponto de referência existente para posteriormente editá-lo ou ex-clu´ı-lo, foi utilizada como forma de sele¸cão o clique do mouse sobre o mesmo. Para tanto, foi utilizada a fun¸cão do MapServer “queryByPoint”.

Esta fun¸c˜ao recebe como parˆametros:

• Objeto do tipo ponto: o ponto clicado em coordenadas de mapa;

• Modo: resultado singular ou resultado m´ultiplo - em nosso caso, o modo singular foi utilizado, pois espera-se apenas um ponto por posi¸c˜ao;

• Tolerˆancia: especifica¸c˜ao em certa unidade de medida (por exemplo, pixels ou met-ros) para retorno de resultados adjacentes.

Por exemplo, utilizando-se o modo de resultados múltiplos e uma tolerância de dez metros, o MapServer retornará todos os resultados sobre o layer consultado que estejam a uma distância de até dez metros do ponto clicado.