PORTAL COLABORATIVO PARA CONSTRUÇÃO DE MAPAS SOBRE EVOLUÇÃO DE DOENÇAS

EPIDEMIOLÓGICAS 1

Robson Bresolin Jardim <r_bresolin@hotmail.com> Stanley Loh <sloh@terra.com.br> - Orientador

Universidade Luterana do Brasil (ULBRA) – Curso de Sistemas de Informação – Câmpus Canoas

Av. Farroupilha, 8.001 – Bairro São José – CEP 92425-900 – Canoas - RS

22 de junho de 2011

RESUMO

O presente trabalho tem por objetivo utilizar os conceitos de Sistemas de Informações Geográficas (SIG)

para criar um portal colaborativo onde os usuários terão autonomia para criar pontos de referência para os principais

focos de doenças epidemiológicas. Inicialmente serão apresentados alguns marcos históricos sobre SIG bem como

definições que são seguidas nos dias atuais para criação de sistemas baseados em SIG, após serão apresentados os

mapas mais robustos do mercado em suas principais características apresentando principalmente suas API's, estas

são disponibilizadas a seus utilizadores a fim de popularizar e facilitar seu uso e distribuição. Serão apresentados

ainda aplicações existentes no mercado que utilizam as API's destes mapas e também suas principais funcionalidades

e beneficios. Com base na utilização de sistemas de informação será apresentado uma proposta de solução onde será

construido um projeto de software para criação deste portal colaborativo. Na definição das macro atividades será

possível dimensionar o tamanho do projeto bem como as metodologias para o desenvolvimento do sistema em

destaque para Domain Driven Design que tem por objetivo auxiliar na criação de um modelo de negócio com

linguagem ubíqua para aproximar o conhecimento técnico da linguagem utilizada pelos usuários do sistema. Para

finalizar será apresentado o sistema com todos os recursos desenvolvidos.

Palavras-chave: Sistemas de Informação Geográfica, Geoprocessamento, API.

ABSTRACT

Title: “Collaborative Portal for constructing maps for the prevention of Epidemiological illnesses”

The present work has the objective of using the Geographic Information Systems (GIS) concepts to create a

collaborative portal where users will have autonomy to create points of reference for the main focuses of

epidemiological illnesses. Initially some historical landmarks will be presented about GIS as well as definitions that

are followed in current times for creating the systems based on GIS, following will be presented the most robust maps

of the market in their main characteristics presenting mainly their API`s,these are made available to their users to

make popular and facilitate the use and distribution. Along with these will be presented existent applications in the

market that use the API`s of these maps and also their functions and benefits. Based on the use of information

systems there will be presented a solution proposal where there will be built a software project for the creation of this

colaborative portal. In the definition of macro activities it will be possible to give the dimension of the size of the

project as well as the methodologies for the development of the system in focus to Domain Driven Design which has

as its objective to assist in the creation of a business model with ubiquitous language to proximate the technical

1 Proposta de Trabalho de Conclusão de Curso em Sistemas de Informação, submetida ao Curso de Sistemas de Informação da Universidade Luterana do Brasil, Câmpus Canoas.

knowledge of the the language used by the users of the system. In conclusion will be presented the system with all

the resources developed.

Key words: Geographic Information Systems, Geoprocessing, API.

1. INTRODUÇÃO

Este trabalho apresenta o referencial teórico de um portal colaborativo utilizando sistemas de

informação geográfica para criação de um mapa contendo informações de focos de doenças

epidemiológicas. O projeto consiste em utilizar recursos disponiveis em API’s de mapas conhecidos

como Google Maps e OpenStreetMaps, estas permitem a seus consumidores incorporar os mapas em

suas páginas web de forma fácil, ágil e robusta. O acesso as API’s são realizados através de rotinas e

funções que serão demontrados no decorrer do artigo.

2. SISTEMAS DE INFORMAÇÃO GEOGRÁFICA (SIG)

2.1. Conceitos

O conceito SIG foi desenvolvido inicialmente na década de 60 como um meio de combinar diversos

tipos de dados em um mesmo mapa. (Paredes, 1994, p.19). Anteriormente o conceito existente era apenas o

de automatizar a função de desenho como no sistema CAD (Computer Aided Design). O sistema CAD

possibilita a criação de desenhos, curvas e figuras em duas dimensões e três dimensões, em contrapartida o

SIG associa atributos gráficos e não-gráficos destes recursos cartográficos tendo como resultado a exibição

de mapas com dados demográficos, geográficos ou ambientais que podem ser separados ou ainda

combinados para uma melhor visualização.

Com a grande evolução da tecnologia de informações podemos afirmar que o processo de

desenvolvimento de um SIG sofreu inúmeras mudanças para se adequar as atuais necessidades, porém alguns

conceitos devem ser seguidos para a criação de um SIG e podem ser destacados a seguir:

“... conjunto de ferramentas para a coleta, o armazenamento, a recuperação, transformação e

reprodução gráfica dos dados espaciais do mundo real para um conjunto particular de finalidades.”

(Clarke, 1986, p. 35).

“... Os SIGs são sistemas ou ferramentas assistidas por computador para captura, armazenamento,

transformação, análise e reprodução gráfica de dados espaciais” (Star e Estes, 1990, p. 56).

“Uma tecnologia de informação que armazena, analisa e mostra dados espaciais e/ou não

espaciais. Entendendo-se por tecnologia, o conjunto de métodos e materiais usados para alcançar objetivos,

e por sistema, o conjunto de componentes que interagem para alcançar um objetivo comum” (Goodchild,

Maguire e Rhind, 1991, p.28).

Segundo Dias (1991) podemos definir os seguintes recursos básicos para um SIG, lembrando que

novos recursos podem ser adicionados e/ou alterados constantemente.

2.1.1. Endereçamento

É a capacidade de ampliação de um mapa também conhecido com “zoom” este é o recurso mais

utilizado do SIG, podemos, por exemplo, visualizar o mapa do Brasil em sua plenitude e a partir do “zoom”

exibir a cidade de Porto Alegre.

2.1.2. Tematização

Através da tematização podemos visualizar os mapas de SIG em diversas visões, produzindo assim

um tema ideal com vários níveis de desenho, lembrando que continuaremos com nossa base completa e com

todos os níveis existentes.

2.1.3. Medição

Possibilitar aos recursos retirar dimensões lineares e coordenadas da área que está sendo analisada.

2.1.4. Edição Gráfica

É a capacidade de edição dos dados armazenados no banco de dados de um SIG, possibilita o

redesenho de mapas, criação de novas ruas, rotas.

2.1.5. Características

Podemos destacar como macro características de um SIG:

2.1.6. Aquisição

É a conversão dos dados analógicos em digitais, estes podem ser resgatados de fontes como

fotografias aéreas, levantamentos topográficos e imagens de satélite.

2.1.7. Gerenciamento

Função de manipulação dos dados que são armazenados a partir de um Sistema Gerenciador de

Banco de Dados.

2.1.8. Análise

Processamento dos dados existentes a fim de gerar novas informações para o sistema como, por

exemplo, extração de informações estatísticas.

2.1.9. Exibição de Resultados

Representa a exibição dos resultados de todos os dados manipulados em dados não-gráficos. O SIG

possibilita união de dados gráficos e dados não-gráficos para um melhor entendimento dos resultados

extraídos.

3. SISTEMAS DE MAPAS E GEOPROCESSAMENTO NA WEB

O Geoprocessamento é um termo amplo que engloba técnicas de tecnologia de tratamento e

manipulação de dados geográficos através de programas computacionais. (Carvalho, Pina e Santos, 2000, p.

14). Utilizando técnicas de Geoprocessamento algumas empresas desenvolveram sistemas que utilizam

mapas como base de informações. A importância destes sistemas é basicamente possibilitar ao usuário

encontrar rapidamente o que procura e ainda sugerir rotas para chegar a algum lugar desejado sem a

necessidade de um amplo conhecimento em cartografia.

3.1. Google Maps

O Google Maps surgiu no ano de 2005 inicialmente nos EUA. Sua expansão deu-se posteriormente a

várias localidades do globo inclusive no Brasil. Passou então a servir de referência para busca de endereços e

principalmente como referência ponto a ponto, ou seja, chegar de um determinado local a outro por meio de

cálculo de rotas que são desenhadas no mapa. Com o passar do tempo novas funcionalidades foram

agregadas ao produto como, por exemplo, visualização 3D de ruas, edificações, informações sobre tráfego e

transporte público.

Após o lançamento e o aceite por seus utilizadores foi lançada sua API sem custo para seus usuários,

possibilitando assim, a inserção de mapas em suas aplicações web, contando ainda com a personalização e

customização dos mapas.

3.2. OpenStreetMap

O OpenStreetMap é um portal colaborativo para a criação de mapas que surgiu no ano de 2004, que

com o decorrer dos tempos foi criando forma, atualmente o sistema possui 245 mil usuários que apóiam o

projeto gerando um nível de detalhamento que mesmo portais como o Google Maps não conseguem

alcançar.

Com a colaboração do projeto do OpenStreetMap desenvolvedores não precisam esperar por

empresas como o Google lançar novas versões de sua API do Google Maps para obter as mais diferenciadas

funcionalidades o que torna o projeto muito mais atraente e requisitado pois quando um usuário contribui

com o projeto suas informações são abertamente disponíveis para todos. O que torna o projeto mais

interessante é que para colaborar com o OpenStreetMap o usuário não precisar ser um desenvolvedor com

grandes conhecimentos em programação, nem um engenheiro com grandes conhecimentos em informação

cartográficas e sim apenas um usuário comum que deseja colaborar enviando a comunidade apenas um ícone

que possa ser usado como marcador do mapa, de ruas, de rodovias, entre outros.

A empresa americana Cloud Made desenvolveu uma gama de API’s para ser utilizado para

desenvolvimento de aplicações com base nos dados inseridos no OpenStreetMap alguns projetos

desenvolvidos pela empresa como o toolkit para IPhone que permite aos desenvolvedores criar uma

aplicação com mapas personalizados e com funções de dirigir, caminhar e andar de bicicleta. Alguns dos

aplicativos desenvolvidos são totalmente gratuitos, a empresa tem como meta apoiar o projeto

OpenStreetMap para criar os melhores dados de Geoprocessamento do mundo.

4. DISPONIBILIZANDO SISTEMAS DE MAPAS ATRAVÉS DE API

API é a sigla para Application Programming Interface, ou na sua versão traduzida Interface de

Programação de Aplicativos, esta é um conjunto de funções e métodos que uma aplicação disponibiliza para

manipulação de suas funcionalidades sem a necessidade de distribuição de seu código fonte.

O modo mais comum de uso de API’s é a utilização da API disponibilizada pelo sistema operacional

do Windows XP que contém 6500 funções dentre elas gerência de memórias, criação de menus, pastas,

arquivos, entre outros.

4.1. Google Maps API

O Google Maps disponibiliza atualmente aos seus utilizadores uma API denominada Google Maps

API V3, esta biblioteca contém todas as funções necessárias para incorporar um mapa a uma página da web.

Como o código da API não é carregado na aplicação do usuário se faz necessário o uso de

referências, para acessar este serviço o Google disponibiliza a geração de uma chave de utilização. A chave

gerada é única para o domínio onde está hospedado a aplicação e deve ser obtido por inscrição online.

Depois de gerada a chave deve ser inserida no código fonte da aplicação, este é o único modo de utilizar a

API do Google Maps atualmente.

O utilizador da API do Google necessita principalmente de conhecimentos em Javascript e

programação orientada a objetos para utilizar o máximo das funcionalidades oferecidas pela ferramenta. O

Google disponibiliza uma documentação completa e detalhada para os desenvolvedores mostrando e

ilustrando passo a passo as funcionalidades desta ferramenta.

4.1.1. Funcionalidades

Basicamente podemos definir como principal funcionalidade do Maps a exibição de um mapa em

nossa aplicação web, devemos para isso, sempre partir de uma coordenada que será exibida de forma

centralizada na tela. A partir deste ponto podemos explorar diversas regiões do mapa utilizando de seus

controladores, como por exemplo, mover para a esquerda, mover para direita, zoom, entre outros.

Um dos recursos muito útil e que será bastante aplicado neste projeto é a utilização de Mashups

(marcadores), esta funcionalidade permite ao usuário colocar ícones no mapa a partir de suas coordenadas,

estes ícones podem ser customizados a fim de criar um mapa interativo para seus usuários.

Através do “DirectionsService”, objeto disponibilizado pelo Google API também conhecido como

serviço de cálculo de rotas, o desenvolvedor poderá traçar rotas de direcionamento entre pontos distintos

para isto apenas é necessário informar as coordenadas do ponto inicial e final, na versão atual da API ainda

podemos informar qual o meio de transporte que será utilizado que podem ser carro, bicicleta ou andando. O

serviço de cálculo de rotas também permite ao desenvolvedor através do “DirectionRequest” definir rotas

alternativas para o caminho a ser percorrido a fim de desviar de barreiras, pedágios, entre outros.

Segundo o Google a visualização dos mapas pode ser obtida de dois modos. O modo cartográfico

exibe ilustrações de ruas e quadras que são fornecidas pela TeleAtlas. O modo satélite exibe uma imagem

área do local selecionado, este é obtido, em sua maioria pela DigitalGlobe e pela MDA Federal.

4.2. OpenStreetMap API

O projeto OpenStreetMap a cada dia tenta criar uma poderosa e atualizada fonte de dados de

geoprocessamento, por outro lado, empresas como Cloud Made® adotam estas informações para criação de

API’s a fim de disponibilizar rotinas de fácil utilização para os seus usuários.

As API’s possibilitam aos seus usuários a personalização de mapas em um nível de detalhamento

que nem mesmo o Google Maps API atinge na em sua atual versão V3.

4.2.1. Funcionalidades

A customização de mapas permite ao usuário alterar os estilos, cor de fundo, cor das linhas, estilo de

rotas bem como a utilização do banco de imagens existente ou ainda a personalização das imagens. Através

da geocodificação é possível de forma prática a localização de endereços ou empresas que estão mapeados

no projeto, permitindo também marcar no mapa a localização atual do usuário.

A rotina para cálculo de rotas (turn-by-turn) pode ser utilizada para orientação de um ponto a outro

no mapa, este serviço pode ser comparado com o “DirectionService” do Google Maps API. A ferramenta

permite aos usuários verificar quais as rotas estão bloqueadas além de vias alternativas para desvios a fim de

evitar engarrafamentos.

O OpenStreetMaps possui diversas imagens para ser utilizada em suas aplicações. Estas imagens

podem ser utilizadas como marcadores para criação de mapas interativos para seus utilizadores, além das

imagens disponibilizadas é possível incluir imagens customizadas de acordo com a necessidade de cada

usuário.

Figura 1 – Estilos do OpenStreetMaps

A API pode ser utilizada através das linguagens de programação Ruby, Phiton, PHP e Java e suporta

diversas plataformas com destaque para dispositivos móveis como IPhone e Android gerando mais facilidade

e portabilidade para o usuário.

5. APLICAÇÕES BASEADAS EM APIS DE SISTEMAS DE MAPAS

5.1. Mappyfriends

O projeto utiliza a API do Google Maps para criar uma comunidade onde são registradas as viagens

feitas em todo o mundo por seus integrantes, assim todos compartilham suas experiências em pontos

turísticos já visitados. A rede Mappyfriends oferece recomendações de viagens de seus amigos o que

aumenta a confiabilidade das informações consultadas.

Ao entrar na comunidade Mappyfriends o usuário deve criar seu perfil no mesmo padrão utilizado

em redes de relacionamentos como Orkut e Facebook, após criar seu perfil o usuário ingressa na rede e

poderá adicionar amigos e compartilhar experiências de viagens. O aplicativo permite integração com o

Twitter, em apenas alguns cliques o usuário poderá importar os dados de seus amigos que também utilizam

este aplicativo.

5.2. Mapa Crime

“Mapacrime.com.br surgiu com a finalidade de gerar estatísticas acerca de furtos e roubos

de bens pessoais, bem como de identificar a localização geográfica onde estes eventos ocorrem.” (Mapa

Crime)

O sistema possibilita aos usuários registrar todas as ocorrências de crimes ocorridas em sua região

através da API do Google Maps, o projeto é um portal colaborativo onde os usuários registram os fatos

ocorridos sem a necessidade de um cadastro oficial.

São disponibilizados aos usuários apenas oito tipos de objetos de furto/roubo são eles: Dinheiro,

Celular, Carteiras, Veículo, Objetos, Estepe Automotivo, Som Automotivo e Bicicleta, cada um dos tipos de

registro corresponde a um ícone personalizado.

5.3. WikiMapia

O projeto do WikiMapia utiliza a API do Google Maps para criar um mapa colaborativo que pode

ser atualizado ao redor do mundo. Com ele seus usuário podem realizar várias tarefas de manutenção do

grande mapa, o sistema tem automia de criação de novos lugares, estradas e rios, com ele é possivel alterar

lugares já cadastrados, o sistema possibilita também a exclusão de lugares já cadastrados. O Resultado final

deste projeto é criar um mapa atualizado com informações de rodovias, cidades, hotéis, escolas, restaurantes,

casas semelhante ao OpenStreetMaps, porém utilizando recursos disponibilizados pela API do Google Maps.

Ao iniciar o sistema um mapa é exibido utilizando a função de marcadores da API para exibir os

pontos já cadastrados, ao clicar sobre um marcador o sistema exibe uma janela de informações com detalhes

do local selecionado, dentre estes detalhes podemos destacar latitude, longitude, população, área e referência

para o local no Wikipédia. Esta janela de informações possibiliza aos seus utilizadores a criação de

comentários sobre o local que está sendo visualizado e a data da última atualização destes locais.

6. APRESENTAÇÃO DO SISTEMA PROPOSTO

A motivação deste trabalho foi a necessidade de se criar uma ferramenta de fácil utilização para o

mapeamento de doenças em qualquer local do mapa mundial. Atualmente a falta de informações na evolução

das doenças tem sido um problema principalmente na criação de campanhas para prevenção de doenças, a

necessidade de um acompanhamento da evolução destas doenças se faz necessário para verificarmos

geográficamente qual o caminho que infestações epidemiológicas estão seguindo.

A principal caracteristica do sistema é a criação de um portal colaborativo onde seus utilizadores tem

acesso as informações evolutivas das doenças epidemiológicas, com base em informações geográficas seus

usuários compartilham os casos de doenças ocorridos em qualquer ponto do mapa através de coordenadas de

latitude e longitude. Como o foco do sistema é um portal colaborativo qualquer pessoa pode incluir

informações, estas podem ser adicionadas por usuários anônimos ou por usuários cadastrados no portal tendo

em vista que as informações inseridas por usuário cadastrados tem maior relevância no momento da análise

destes dados.

O sistema possibilita a extração de dados detalhados de cada doença, bem como a data em que esta

foi incluída, a fim de ser criar um histórico evolutivo. Podemos gerar scores por tipo de doença, por sexo e

por faixa etária com estas análises é possível criar campanhas de prevenção bem específicas para cada nível

dos problemas existentes nas regiões acompanhadas.

A proposta de criar um portal colaborativo é atrativo aos seus usuários, pois possibilita o acesso e

criação desta base de dados por todos seus utilizadores. Com base em ferramentas já existentes no mercado,

porém em outras áreas de atuação foram coletadas as informações necessárias para criação do projeto de

software desenvolvido.

Após a apresentação dos componentes de geoprocessamento existentes atualmente o projeto será

centralizado na utilização do Google Maps API, este foi considerado o mais completo e com documentação

mais abrangente que irá suprir todas as necessidades para desenvolvimento do sistema proposto.

6.1. Funcionamento do Sistema

O acesso ao sistema pode ser efetuado através do link http://maps.hospitalmoinhos.org.br/,ao

acessar esta URL o usuário é redirecinado para a tela inicial do sistema como podemos exemplificar na

figura 2.

Figura 2 - Tela Inicial

No canto superior direito da tela inicial podemos identificar o usuário que está logado no sistema, se

este usuário não se indentificar o sistema irá considerar como Anônimo. Usuários anônimos também poderão

registrar ocorrências de doenças no sistema, por outro lado, estes usuários não terão acesso a alguns

módulos, como por exemplo a geração de gráficos e ainda não poderão excluir nenhuma ocorrência

registrada. No canto inferior direito podemos identificar a legenda de todos os tipos de doenças cadastrados

no sistema, estes são identificados pelo ícone presente na legenda.

6.2. Cadastros Básicos

Os processos denominados básicos para o funcionamento do sistema devem ser incluídos por um

usuário administrador, este é responsável pela manutenção destas informações a fim de registrar apenas o

que realmente é de interesse de todos no portal.

6.2.1. Doenças

Ao cadastrar uma doença o usuário deve acessar no menu a opção “ILLNESS” onde inicialmente

serão exibidos todas as doenças cadastradas no portal, para incluir uma nova doença é necessário clicar sobre

o botão “New Record” onde será exibida a tela de cadastro, apenas dois campos são necessários, o campo

“Description” onde é armazenado o nome da doença e o campo “Icon” onde armazenamos o ícone de

referência para esta doença no mapa, ao selecionar um ícone o sistema salva este arquivo no servidor para ser

utilizado posteriormente.

6.2.2. Faixa Etária

As faixas etárias podem ser acessadas da página de doenças no menu central direito clicamos sobre a

opção “Age”, para incluir uma nova faixa etária é necessário clicar sobre o botão “New Record”, ao exibir a

tela de cadastro é necessário apenas informar o campo “Description”.

6.3. Adicionando Ocorrências

Ao clicar com o botão direito do mouse em qualquer local do mapa o sistema possibilita a inclusão

de um registro de doença. A tela de cadastro de doenças (Figura 3) é exibida, após informar os campos

obrigatórios Doença e Data é possível salvar os dados, para uma melhor identifição do caso cadastrados o

sistema disponibiliza a entrade de informações como Faixa Etária, Sexo e Observações. Após salvar o ponto

é exibido no mapa conforme as coordenadas (Latitude e Longitude) que foram clicadas.

Ao instânciar um mapa podemos adicionar alguns eventos a este controle, dentre estes eventos

utilizamos o evento “mousemove” que possibilita ao mover do mouser buscar as coordenadas do local, ao

clicar com botão direito do mouse será exibido o menu "ADD" neste momento o sistema busca as

coordenadas (latitude e longitude) em que está posicionado o cursor do mouse através da função

"Google.maps.LatLng" e em seguida é exibida a tela de cadastro. Após o preenchimento dos campos na tela

de cadastro o usuário deverá clicar em salvar neste momento o sistema chama o serviço que armazena os

dados da doença no banco de dados, ao executar este método além dos dados selecionados na tela é

necessário passar por parâmetro as coordenadas que foram selecionadas no mapa, estas coordenadas foram

capturadas antes da abertura da tela de cadastro.

Figura 3 - Cadastro

Para adicionar um marcador no mapa o sistema utiliza um serviço disponibilizado pela API do

Google Maps chamado de “Google.Maps.Marker”. Dentre os parâmetros que devem ser passados para este

serviço o sistema utiliza a Latitude e Longitude do ponto de interesse e ainda o ícone que deve ser exibido no

mapa. Outro serviço utilizado no momento de criação de um registro é o “Google.Maps.Geocoder” este

serviço permite a visualização estruturada do endereço, através da latitude e longitude podemos resgatar o

pais, estado, bairro do ponto selecionado. Na figura 4 podemos visualizar os códigos que exemplificam a

utilização das rotinas de Marcadores e Endereço disponiblizada pela API. A seguir duas rotinas que o

sistema deve atualizar no momento em que o usuário clica em “Salvar”.

6.3.1. Buscando um Endereço (Geocoder)

Na linha 1 devemos instanciar uma nova classe “Geocoder”, ao passarmos para linha 2 devemos

passar o parâmetro “location” (Latitude e Longitude) do endereço que necessitamos localizar, caso o status

for igual a “OK” significa que o endereço foi localizado, deste modo na linha 4 retornamos o endereço

requisitado para salvar no banco de dados.

6.3.2. Adicionando Marcadores (Marker)

Ao adicionar um novo marcador no mapa inicialmente devemos localizar o ícone de referência para

esta doença, ao localizar este ícone no servidor, necessitamos criar um novo “MarkerImage” que retorna

uma classe do típo Ícone. Na linha 2 devemos instanciar um novo ‘LatLng” com referência na latitude e

longitude armazenadas no banco de dados, ao obtermos estas informações podemos criar um novo marcador

conforme linha 3, os marcadores aceitam alguns parâmetros, como por exemplo, ID onde podemos

acrescentar o identificador da classe de doenças na linha 4. Os marcadores aceitam eventos, na linha 5

adicionamos o evento “click’, ao clicar sobre algum ícone exibimos os detalhes da doença utilizando por

base os ID cadastrado no parâmetro da linha 4.

Figura 4 - Exemplo de Codificação

6.4. Inicializando o Mapa e Ícones

Na tela inicial do sistema inicialmente foi definida a região do Rio Grande Sul / Brasil como ponto

inicial de visualização, as coordenadas utilizadas foram (-30.030466, -51.193215) em latitude e longitude

respectivamente, ao inicializar o mapa o sistema exibe todas as ocorrências cadastradas no banco de dados

exibindo seus ícones conforme os pontos de latitude e longitude salvos, na legenda são exibidos os dados de

cada tipo de doença cadastrada bem como seu ícone de referência a fim de ilustrar cada doença em pontos do

mapa. Após a abertura do mapa é possível navegar em qualquer parte do globo sendo possível adicionar

ocorrências em qualquer local para visualizar o local atual do usuário é utilizado o serviço

“navigator.geolocation” ao utilizar este serviço o browser exibe mensagem para o usuário se deseja

compartilhar a localização atual, no momento da confirmação do usuário o sistema busca a latitude e

longitude e centraliza o mapa neste ponto.

6.5. Overlay

A opção Overlay permite ao usuário agrupar diversos ícones (pontos) que estão próximos a fim de

criar uma melhor visualização dos pontos no mapa, esta opção possibilita unir diversos ícones próximos a

apenas um ícone, este ícone identifica o número de ocorrências existentes naquela proximidade, a figura 5

exemplifica a utilização de Overlays, que podem ser acessados pela opção “filters” existente no centro

direito da tela inicial.

Figura 5 - Overlays

6.6. Relatório

A extração de relatórios não necessita de registro no sistema, um usuário anônimo tem acesso total

aos dados incluídos a fim de facilitar o acesso as informações disponibilizadas pelo software. Ao iniciar a

tela de extração dos dados o usuário necessita selecionar dois pontos iniciais, após selecionar estes

marcadores o sistema irá gerar um retângulo com base nas coordenadas de latitude e longitude marcadas.

A classe Google.Maps.LatLngBounds é utilizada para a representação de um retângulo através de

duas coordenadas uma noroeste e outra sudeste. A função para adicionar este retângulo no mapa é chamada

de Google.Maps.Rectangle, ao arrastar os pontos selecionados no mapa podemos desenhar um retângulo ou

ainda apenas ajustar suas coordenadas de modo que seja redesenhado no mapa, a figura 6 representa o

retângulo que podemos selecionar para a geração do relatório, bem como o código utilizado para sua criação.

Figura 6 - Retângulos

Ao clicar sobre o botão de geração do relatório o sistema verifica quais coordenadas estão entre as

coordenadas noroeste e sudeste selecionadas, a função utilizada para verificar se uma coordenada está

contida neste retângulo é “LatLngBounds.Contains” que retorna verdadeiro se uma latitude e longitude está

nos limites do retângulo. Para filtrar quais registros estão dentro dos limites do selecionado no relatório é

necessário comparar cada registro no banco de dados com as coordenadas “LatLngBounds”, ao comparar os

registros o sistema retorna verdadeiro se a coordenada existir dentro dos limites e falso caso não exista, por

fim o sistema exibe no relatórios todos os registros com status de verdadeiro.

6.7. Gráficos

O sistema possibilita gerar gráficos que demonstram quantidades por região, as informações geradas

são por Tipo de Doença, por Sexo e por Faixa Etária conforme figura 7, ao selecionar o país é possível

verificar a quantidade total de registros conforme segue.

Figura 7 - Gráficos

6.8. Modelo de Dados

O modelo de dados apresentado a seguir foi desenvolvido utilizando a ferramenta de designer

disponibilizado pelo SQL Server®, este apresenta a estrutura dos dados que serão desenvolvidos conforme

Figura 8 a seguir.

Figura 1 – Modelo de Dados

6.8.1. USUARIO

A tabela de usuários é responsável por armazenar informações essenciais para o login no sistema,

esta identificação é realizada através do e-mail e senha cadastrados no momento do registro. O campo Nome

será utilizado na tela de boas-vindas e ainda na indentificação do usuário na extração dos dados. O campo

IndAdm identifica permissões especiais para o usuário, entre elas está o cadastro de tipos de doenças e de

faixas etárias, bem como a liberação para exclusão de todos os marcadores inseridos por qualquer usuário.

6.8.2. FAIXAETARIA

A faixa etária é uma tabela simples de cadastro básico para classificação dos casos de doenças

cadastrados, esta possibilita dividir os pacientes a fim de criar campanhas para prevenção das doenças por

idade.

6.8.3. TIPODOENCA

Permite a criação de todos os tipos de doenças que devem ser mapeados pelo sistema, ao criar um

tipo de doença este já é disponibilizado para todos os usuários do sistema, o campo Icone identifica qual

imagem deve ser exibida no mapa para ilustração deste tipo de doença.

6.8.4. DOENCAS

Armazena os principais dados do sistema, esta tabela tem por finalidade cadastrar as ocorrências de

todas as doenças cadastradas. O campo DataInclusao armazena a data em que o registro foi incluído no

sistema por outro lado o campo DataColeta armazena a data em que aconteceu a ocorrência, o campos

latitude e longitude exibem as coordenadas do ponto a ser marcado no mapa e estes são bases para qualquer

informação sobre esta ocorrência, dentre elas a possibilidade de identificar o endereço do registro.

6.9. Estrutura e Implementação do Sistema

Com base em orientação a objetos este projeto foi desenvolvimento utilizando técnicas de ORM

(Object-relational mapping). Segundo Ambler esta técnica sugere como devemos persistir o estado de um

objeto em tabelas de um banco de dados relacional. A utilização do Fluent NHibernate facilitou a geração

dos códigos ao fato que oferece uma alternativa de mapeamento utilizando códigos C# uma vez que o

Nhibernate utiliza como padrão o XML. O sistema utiliza como banco de dados o SQL Server® 2008 R2 e

foi desenvolvido utilizando o Microsoft Visual Studio® 2010 com linguagem de programação C#, a

manipulação da API do Google Maps foi desenvolvida utilizando códigos em Javascript.

O projeto foi estruturado a fim de subdividir em várias camadas, com isto podemos criar níveis no

desenvolvimento de um sistema, a camada de negócio pode ser criada por desenvolvedores de negócio e a

camada de interfaces pode ser desenvolvidas por designers. O projeto atual foi subdivido em 11 projetos

conforme segue:

6.9.1. Maps.Consult

As consultas do sistema em vários objetos do domínio são criadas neste projeto a fim de obtermos

uma maior organização e facilidade no momento de manutenção e/ou alteração de uma regra de negócio.

6.9.2. Maps.DTO

Ao executar uma consulta necessitamos retornar objetos que não fazem parte do domínio, ou seja,

objetos que não agregam valor a regra de negócio que por sua vez são necessários principalmente na

exibição de relatórios. A utilização do DTO (Data Transfer Object) é necessária para não criarmos estes

objetos desnecessários na regra de negócio.

6.9.3. Maps.Services

Os serviços são responsáveis pelo vínculo entre a regra de negócio e a interface final para o usuário,

neste projeto podemos definir as chamadas para os repositórios existentes na aplicação. Para um melhor

entendimento do funcionamento de serviços, podemos exemplificar da seguinte forma, ao salvar os dados

existentes na classe de faixa etária devemos chamar um método existente no serviço chamado Save, ao

passar a classe FaixaEtaria como parâmetro para este método o serviço será responsável por chamar todas as

validações necessárias para que a classe seja criada.

6.9.4. Maps.Domain

O domínio da aplicação onde estão contidas todas as classes do sistema, os objetos com suas

propriedades e métodos são implementados neste projeto. Alguns métodos, como validações, podem ser

adicionados em cada objeto que é responsável por persistir suas regras de negócio.

6.9.5. Maps.DomainMap

O mapeamento do domínio que consiste em vincular o objeto com suas tabelas de referência na base

de dados, ao utilizarmos uma propriedade de qualquer classe existente o ORM utilizará estes mapeamentos

para identificar as colunas nas tabelas do banco de dados.

6.9.6. Maps.DataAccess

Responsável pela conexão entre a aplicação e o banco de dados, mantém a sessão que está sendo

utilizada no banco.

6.9.7. Maps.Framework

O projeto agrega funções genéricas que podem ser utilizadas em toda a aplicação a fim de organizar

e prevenir a repetição desnecessária de código.

6.9.8. Maps.IoC

O projeto de Inversão de Controle é responsável por vincular uma Interface a um Service de

implementação, por exemplo, se criarmos um serviço de Login o responsável pela chamada deste serviço

apenas terá acesso a classe Interface e não a sua implementação.

6.9.9. Maps.NH.Repository

Seguindo os conceitos de DDD(Domain Drive Design) os repositórios são responsáveis por persistir

e destruir objetos, outra finalidade deste projeto é consultar e filtrar os objetos, retornando uma lista deste

objeto, o repositório é utillizado para executar tarefas com um objeto que está presente no domínio, ou seja,

por objetos que agregam valor ao negócio.

6.9.10. Maps.Tests

Utilizando as técnicas de TDD (Test Driven Develpment) este projeto faz com que a toda a aplicação

seja validada de modo que seja possível testar a regra de negócio antes mesmo de criar as interfaces para os

usuários finais. Ao criar um teste podemos validas as regras da aplicação, no momento de manutenção ou

alteração de escopo do projeto basta rodarmos todos os testes para saber se esta alteração não gerou

inconsistência em pontos que possam ser esquecido no momento da definição. Quando utilizamos testes

podemos codificar com mais segurança e a qualquer momento refatorar o código sem receios, em caso de

dúvida apenas rodamos todos os testes para validar a aplicação.

6.9.11. Maps.Site

O projeto final UI (User Interfaces) responsável em armazenar todas as interfaces (telas) que serão

apresentadas para o usuário final, este projeto além das telas deve apenas possuir chamadas para os serviços,

criando assim um desacoplamento entre a regra de negócio e a camada de apresentação.

Podemos ainda agrupar estes onze projetos em cinco grupos. O responsável pela regra de negócio da

aplicação tem accesso aos quatro primeiros grupos (Application, Domain, Infra, Tests), por outro lado o

responsável pela camada de apresentação do sistema acessa somente dois destes grupos (Application e UI).

7. EVOLUÇÃO DE DOENÇAS

Para acompanhar a evolução de doenças a partir da tela inicial podemos gerar filtros que facilitam a

captação e acompanhamento destes dados, através da caixa “Filters”, conforme figura 9 podemos executar

filtros no mapa principal por data da ocorrência e por tipo de doença.

Figura 9 - Filters

Ao executar estes filtros podemos acompanhar a evolução de doenças, a figura 10 nos exemplifica

hipotéticamente a evolução da doença H1N1 no estado do Rio Grande do Sul nos anos de 2010 e 2011

respectivamente. A comparação das imagens permite verificar a evolução das doenças tanto em número de

casos quanto à deslocamento ou aparição geográfica.

Figura 20 - Evolução

8. CONCLUSÃO

O desenvolvimento de aplicações na área de geoprocessamento é um verdadeiro desafio, visto que os

conceitos e metodologias utilizadas para manipulação de mapas não é usual como a maioria dos sistemas

conhecidos. A criação de API`s para manipulação dos dados geográficos de mapas vem como grande aliado

para o desenvolvimento destas aplicações de modo que, além de diminuir a curva de aprendizando,

estabelece uma linguagem padrão para a criação destes sistemas de informação. O crescimento destas

tecnologias é reconhecido por grandes empresas que buscam aperfeiçoar cada vez mais suas API`s a fim de

adquirirem um nível competitivo e compatível com o mercado atual, o que é muito interessante para quem

utiliza destas API`s, pois cada empresa disponibiliza atualizações constantes e ainda aperfeiçoamentos a cada

atualização gerada, com isto, seus utilizadores conseguem criar aplicações ricas utilizando os novos recursos.

Embasado no uso das interfaces disponibilizadas por estas empresas é possível criarmos este portal

colaborativo onde os usuários poderão utilizar as informações disponibilizadas principalmente para

prevenção bem como visualizar um mapa global de todas as doenças conhecidas.

Ao utilizarmos um portal colaborativo para a criação de uma base de conhecimento disponibilizamos

a seus usuários um grande controle e principalmente base para criação de campanhas focadas, a fim de

diminuir custos com projetos muitos vezes realizados sem um adequado nível de maturidade nos locais em

que estas ocorrem. Ao utilizarmos mapas para este controle também obtemos uma aceitação melhor de seus

utilizadores devido a disponibilizarmos uma visualização mais amigável e interativa. O sistema foi

desenvolvido para atender a necessidade de mapeamentos de doenças, porém pode ser utilizado como via de

comunicação para outras áreas, como por exemplo, área de marketing ao apontarmos os estabelecimentos de

uma cidade, área criminal ao montarmos um mapa de criminalidade de uma determinada região ou ainda

utilizarmos o mapa para demonstrar geograficamente pontos turísticos em todo o mundo.

Durante o desenvolvimento e a maturidade deste projeto além de melhorias nos processos existentes

podemos constatar a criação de novos módulos que podem facilitar a utilização e aceitação de seus usuários,

destes processos podemos destacar a busca por determindados endereços a fim de agilizar o processo de

inclusão de doenças, na extração de dados podemos adicionar a exportação de arquivos a fim de integrar os

dados com outros sistemas já existentes no mercado.

O nível de importância de sistemas focados em áreas da saúde é bastante satisfatório visto que a

informação deve ser direcionada e de fácil acesso à população, de modo que, os meios de prevenção a estas

doenças seja cada vez mais focados nas regiões emergenciais.

O sistema foi desenvolvimento para ser utilizado pela populção em geral, tendo como princípio os

conceitos de um portal colaborativo, ao ser utilizado por pessoas das áreas epidemiológicas é muito benéfico

a fim de disponibilizar a informação de maneira simples e objetiva, além dos estudos geográficos da

disseminação das doenças pode-se obter a evolução desta doença a nível de quantidade e deslocamento.

As implementações futuras a serem desenvolvidas destacam-se a criação de busca por endereços

para facilitar a localização por parte dos usuários, no módulo de gráficos podemos adicionar o modelo de

barras para gerar indicadores de quantidade cruzando as informações de doenças por tipo, sexo ou faixa

etária. No módulo de usuários podemos adicionar algumas informações que ajudem a identificar o perfil do

usuário que está inserindo as informações.

Com a realização deste estudo, percebe-se que este foi leal a seus objetivos, visto que utilizamos de

forma satisfatória os recursos disponibilizados pela API do Google Maps a ainda foi possível demonstrar

geograficamente a evolução das doenças.

AGRADECIMENTOS

Agradeço e dedico este trabalho à minha família que sempre me apoiaram em todos as minhas

decisões, aos verdadeiros amigos que deixaram de estar comigo para que este trabalho fosse concluído.

Agradeço especialmente a minha irmã que apesar da sua adolescência me ensina muitos valores que levarei

para toda a vida, pelo seu carinho, amizade e cumplicidade.

Um “Muito Obrigado” a todos que testaram o sistema e me ajudaram com suas dicas e conselhos

também a meu orientador pela paciência, acompanhamento e direção nesta jornada.

REFERÊNCIAS BIBLIOGRÁFICAS

CARVALHO, Marilia Sá PINA, Maria de Fátima SANTOS, Simone Maria. Conceitos básicos de sistemas de informação geográfica e cartografia aplicados à saúde. Brasilia, Ministério da Saúde, 2000.

CLARKE, Keith.C. Analytical and Computer Cartography. Englewood Cliffs, NJ. Prentice Hall, 1990.

CLOUD MADE. Makes maps Differently. Disponível em: < http://cloudmade.com/> Acessado em Setembro de 2010.

GOOGLE. Google Maps API Family. Disponível em:<http://code.google.com/intl/pt-BR/apis/maps/> Acessado em Março de 2011.

MAGUIRE, David J. & GOODCHILD, Michael F. e RHIND, David W. Geographical Information Systems. New York, Iogman Scientific & technical, 1991. Vol. 1.

MAPA CRIME. Disponível em: <http://www.mapacrime.com.br/> Acessado em Setembro de 2010.

MARTIN, Dias. Geographical Information Systems and socioeconomic applications. London, 1991

PAREDES, Evaristo Atencio. Sistemas de Informação Geográfica Princípios e Aplicações. São Paulo, 1994.

STAR, Jeffrey ESTES, John. Geographic Information Systems. London, Prentice-Hall International, 1990.

AMBLER, Scott W. Mapping Objects to Relational Databases. Disponível em: <http://www.agiledata.org/essays/mappingObjects.html> Acessado em março de 2011.