Embed Size (px)
Citation preview
UNIVERSIDADE REGIONAL DE BLUMENAU
CENTRO DE CIÊNCIAS EXATAS E NATURAIS
CURSO DE CIÊNCIA DA COMPUTAÇÃO – BACHARELADO
APLICAÇÃO WEB PARA CONSULTA DE ITINERÁRIOS DE
TRANSPORTE PÚBLICO COM VISUALIZAÇÃO NO
GOOGLE MAPS
KELLY CRISTINA BOECK
BLUMENAU
2012
2012/1-18
KELLY CRISTINA BOECK
APLICAÇÃO WEB PARA CONSULTA DE ITINERÁRIOS DE
TRANSPORTE PÚBLICO COM VISUALIZAÇÃO NO
GOOGLE MAPS
Trabalho de Conclusão de Curso submetido à
Universidade Regional de Blumenau para a
obtenção dos créditos na disciplina Trabalho
de Conclusão de Curso II do curso de Ciência
da Computação — Bacharelado.
Prof. Dalton Solano dos Reis, M. Sc. - Orientador
BLUMENAU
2012
2012/1-18
APLICAÇÃO WEB PARA CONSULTA DE ITINERÁRIOS DE
TRANSPORTE PÚBLICO COM VISUALIZAÇÃO NO
GOOGLE MAPS
Por
KELLY CRISTINA BOECK
Trabalho aprovado para obtenção dos créditos
na disciplina de Trabalho de Conclusão de
Curso II, pela banca examinadora formada
por:
______________________________________________________
Presidente: Prof. Dalton Solano dos Reis, M. Sc – Orientador, FURB
______________________________________________________
Membro: Prof. Aurélio Faustino Hoppe, M. Sc – FURB
______________________________________________________
Membro: Prof. Everaldo Artur Grahl, M. Sc – FURB
Blumenau, 24 de julho de 2012.
Dedico este trabalho a Celira, Lauro, Solange,
Moacir e Eliane.
AGRADECIMENTOS
Aos meus amigos!
Eu às vezes acho que sou um Dom Quixote: divagante, entusiasmada e passional. E
entro nas maiores aventuras de carona com o acaso, a oportunidade, e sempre na companhia
de grandes amigos.
Na aventura de agora, na minha batalha contra os moinhos de vento, cheios de braços
carregados de API, classes, métodos, prazos, dúvidas, fundamentações teóricas, me descobri
um Dom Quixote, precisando de amigos Sancho Pança, sensatos, presentes, ponderados e
fiéis. E quero agradecer neste momento para estes grandes amigos, familiares e professores,
amigos que me apoiaram, incentivaram a voltar, a permanecer, a não desistir, a tentar, a
seguir, a sonhar. Agradeço a Deus pela existência de vocês, e presença em minha vida...
Moinhos de vento não me venceram, pois nesta história, eu tinha vocês junto comigo.
E mais um ciclo foi concluído! Obrigada: Solange, Moacir, Eliane, Fernanda, Leandro,
Vinícius, Rebecca, Andreia, Fabrício. E ao Professor Roque, Professor Dalton. Obrigada pelo
apoio, incentivo, ajuda e força. Não tenho palavras que possam representar o apreço e ordem
que os tenho.
E Deus, obrigada! Por ter feito tudo ser do jeito que é!
Um mapa é o maior de todos os poemas
épicos. Suas linhas e cores mostram a
realização de grandes sonhos.
Gilbert H. Grosvenor
RESUMO
Este trabalho apresenta uma aplicação que permite consultar linhas, horários e itinerários de
transporte coletivo urbano. A aplicação permite o cadastro de linhas, horários e ruas, que
armazenados em um banco de dados, farão a composição do itinerário que as linhas atendem.
Este itinerário é representado graficamente utilizando a API (Application Programming
Interface) do Google Maps. Para aplicação utilizou-se o ASP NET, linguagem C#, em
conjunto com .Net Framework 4. Juntamente com HTML, JavaScript para as páginas de
consulta. A aplicação foi desenvolvida em ambiente Visual Studio 2010.
Palavras-chave: Geoprocessamento. Entity Framework. API do Google Maps.
ABSTRACT
This paper presents an application to see lines, schedules and routes of urban public
transportation. The application allows the registration of lines, timetables and streets, stored in
a database, make the composition of the route that the lines meet. This route is plotted using
the API (Application Programming Interface) Google Maps. For implementation we used the
ASP NET, C #, together with .Net Framework 4. Along with HTML, JavaScript for the query
pages. The application was developed in Visual Studio 2010 environment.
Key-words: GIS. Entity Framework. Google Maps API.
LISTA DE ILUSTRAÇÕES
Figura 1 – Bing Maps ............................................................................................................... 23
Figura 2 – Open Street Maps .................................................................................................... 25
Figura 3 – Google Maps ........................................................................................................... 27
Quadro 4 – Google Maps – Exemplo de definição do recipiente do mapa .............................. 29
Quadro 5 – Google Maps – Exemplo da chamada da API do Google Maps ........................... 30
Quadro 6 – Google Maps – Exemplo das definições para construção do mapa ...................... 30
Quadro 7 – Google Maps – Exemplo da classe google.maps.Map .......................................... 31
Quadro 8 – Google Maps – Exemplo Carregamento Initialize() ............................................. 31
Quadro 9 – Google Maps – Resultados do objeto GeocodeRequest ........................................ 35
Figura 10 – TMB Virtual .......................................................................................................... 43
Figura 11 – TRANSPORLIS - Consulta .................................................................................. 44
Figura 12 – TRANSPORLIS – Resultado da consulta ............................................................. 45
Figura 13 – SPTRANS – Consulta e Resultado ....................................................................... 46
Figura 14 – Tabela comparativa entre os trabalhos correlatos ................................................. 47
Figura 15 – Diagrama de casos de uso do cadastro da aplicação ............................................. 50
Quadro 16 – Detalhamento do Cadastro das localizações adjacentes ...................................... 51
Quadro 17 – Detalhamento do Cadastro os pontos de parada .................................................. 52
Quadro 18 – Detalhamento do Cadastro das linhas .................................................................. 52
Figura 19 – Diagrama de casos de uso da consulta .................................................................. 53
Figura 20 – Detalhamento da consulta web.............................................................................. 53
Figura 21 – Diagrama de Classes ............................................................................................. 54
Figura 22 – Diagrama modelo entidade-relacionamento ......................................................... 56
Quadro 23 – Aplicação – chamada API Google Maps ............................................................. 57
Quadro 24 – Aplicação – função de inicialização .................................................................... 58
Quadro 25 – Aplicação – função de marcação no mapa .......................................................... 59
Quadro 26 – Aplicação – função para geocodificação reversa ................................................ 60
Quadro 27 – Aplicação – consultar Pontos .............................................................................. 61
Quadro 28 – Aplicação – obter de linhas que atendem os pontos ............................................ 61
Quadro 29 – Aplicação – obter ordem...................................................................................... 62
Quadro 30 – Aplicação – obter ruas ......................................................................................... 62
Quadro 31 – Aplicação – função AbrirConsulta – resultado da consulta ........................ 63
Figura 32 – Aplicação – apresentação dos cadastros ............................................................... 64
Figura 33 – Aplicação – cadastro de ruas ................................................................................. 65
Figura 34 – Aplicação – alteração de pontos ............................................................................ 65
Figura 35 – Consulta – apresentação ........................................................................................ 66
Figura 36 – Consulta – endereço origem .................................................................................. 67
Figura 37 – Consulta – endereço destino.................................................................................. 67
Figura 38 – Consulta – características do mapa apresentado ................................................... 68
Figura 39 – Consulta – resultado .............................................................................................. 68
Figura 40 – Consulta de testes com dois marcadores de pontos de parada .............................. 69
Quadro 41 – Resultados de testes com doic marcadores de pontos de parada ......................... 70
Figura 42 – Consulta de testes com três marcadores de pontos de parada ............................... 70
Quadro 43 – Resultados de testes com três marcadores de pontos de parada .......................... 71
Figura 44 – Consulta de testes com cinco marcadores de pontos de parada e adjacente ......... 71
Quadro 45 – Resultado de testes com cinco marcadores de pontos de parada e adjacente ...... 72
Quadro 46 – Tabela comparativa deste trabalho e aplicações disponíveis no mercado ........... 73
LISTA DE TABELAS
Tabela 1 – Espaço para armazenamento................................................................................... 72
LISTA DE SIGLAS
API – Application Programming Interface
CSS - Cascading Style Sheets
EDM – Entity Data Model
EF – Entity Framework
GPS - Global Position System
HTML - HyperText Markup Language
LINQ - Language INtegrated Query
MER – Modelo Entidade Relacionamento
MVC – Model View Controller
ORM - Object-Relational Mapping
OSM – Open Street Maps
REST - Representational State Transfe
SIB - Sistema Integrado de Transporte Coletivo Urbano de Blumenau
SIG – Sistemas de Informações Geográficas
SOAP - Simple Object Access Protocol
UML - Unified Modeling Language
URL - Uniform Resource Locator
XML - eXtensible Markup Language
WPF - Windows Presentation Foundation
SUMÁRIO
1 INTRODUÇÃO .................................................................................................................. 13
1.1 OBJETIVOS DO TRABALHO ........................................................................................ 14
1.2 ESTRUTURA DO TRABALHO ...................................................................................... 15
2 FUNDAMENTAÇÃO TEÓRICA .................................................................................... 16
2.1 CARTOGRAFIA ............................................................................................................... 16
2.2 GEOPROCESSAMENTO E GEOTECNOLOGIAS ........................................................ 20
2.3 WEB MAPPING ............................................................................................................... 21
2.3.1 Bing Maps ....................................................................................................................... 23
2.3.2 Open Street Maps ............................................................................................................ 24
2.3.3 Google Maps ................................................................................................................... 26
2.3.3.1 API do Google Maps .................................................................................................... 28
2.3.3.1.1 Objetos de Mapas Básicos ....................................................................................... 29
2.3.3.1.2 Objetos de Eventos de Mapa .................................................................................... 31
2.3.3.1.3 Controles de Mapa ................................................................................................... 32
2.3.3.1.4 Sobreposições de Mapas .......................................................................................... 33
2.3.3.1.5 Serviços de Mapas ................................................................................................... 34
2.4 ENTITY FRAMEWORK .................................................................................................. 39
2.4.1 LINQ ............................................................................................................................... 41
2.4.2 Entity SQL ...................................................................................................................... 42
2.5 TRABALHOS CORRELATOS ........................................................................................ 42
2.5.1 TMB Virtual .................................................................................................................... 42
2.5.2 TransporLis ..................................................................................................................... 43
2.5.3 SPTRANS ....................................................................................................................... 45
3 DESENVOLVIMENTO DA APLICAÇÃO .................................................................... 48
3.1 REQUISITOS PRINCIPAIS DO PROBLEMA A SER TRABALHADO ....................... 48
3.2 ESPECIFICAÇÃO ............................................................................................................ 49
3.2.1 Diagrama de Casos de Uso ............................................................................................. 49
3.2.2 Casos de Uso ................................................................................................................... 49
3.2.2.1 Cadastrar localizações adjacentes ................................................................................. 50
3.2.2.2 Cadastrar pontos de paradas ......................................................................................... 51
3.2.2.3 Cadastrar linhas ............................................................................................................ 52
3.2.3 Diagrama de Classes ....................................................................................................... 54
3.2.4 Modelo Entidade Relacionamento .................................................................................. 55
3.3 IMPLEMENTAÇÃO ........................................................................................................ 56
3.3.1 Técnicas e ferramentas utilizadas.................................................................................... 57
3.3.2 Operacionalidade da implementação .............................................................................. 64
3.4 RESULTADOS E DISCUSSÃO ...................................................................................... 69
4 CONCLUSÕES .................................................................................................................. 75
4.1 EXTENSÕES .................................................................................................................... 76
REFERÊNCIAS BIBLIOGRÁFICAS ................................................................................. 77
13
1 INTRODUÇÃO
Desde os primórdios da história da existência da humanidade têm-se registros do uso
de mapas pelas sociedades. Eram mapas diferentes do que se conhece atualmente, feitos em
diferentes materiais, mas os objetivos eram basicamente os mesmos de hoje: localização,
orientação e movimentação.
De acordo com Almeida, Guerrero e Fiori (2007, p. 21), o surgimento do mapa
precede a invenção da escrita. Esses eram confeccionados para mostrar as áreas onde havia
caça e pesca ou marcar o caminho para casa. Da antiguidade até os dias de hoje o mapa
sempre esteve presente no cotidiano das pessoas, passando pelos contínuos processos de
transformação que o conhecimento possibilitou à humanidade.
O mapa é uma imagem convencionada, codificada que representa feições e
características da realidade geográfica. O mapa não reproduz fielmente o terreno. Ele é a
construção que seleciona alguns aspectos e os representa, fazendo uso de um sistema de
símbolos. Os elementos espaciais da superfície terrestre escolhidos para serem representados
no mapa (como objetos, fatos e relações) são transformados em símbolos e localizados no
mapa a partir de um sistema de coordenadas que considera distâncias e direções (ALMEIDA;
GUERRERO; FIORI, 2007, p. 20).
Conforme Labtate (2011) todos os mapas possuem características básicas como
escalas, projeções cartográficas, legenda, título, porém podem variar muito na aparência.
Existem tipos de mapas diferentes de acordo com a finalidade de uso. De modo geral, pode-se
agrupá-los em dois grandes conjuntos:
a) mapas de propósitos gerais ou mapas de base: geralmente mostram objetos
naturais ou culturais do meio ambiente, priorizando a localização e mostrando
algumas feições genéricas do mundo ou parte dele como vias de comunicação,
corpos d’água, linhas costeiras e limites políticos-administrativos. Como exemplo
podem ser citados os mapas topográficos, mapas políticos e mapas viários;
b) mapas temáticos: mostram a classificação de fenômenos que interessam a um
determinado ramo específico de estudo ou de atividades humanas.
Conforme Catalogeo (2011), a cartografia é a arte e a ciência de desenho de mapas. Ela
permite a representação geográfica de elementos naturais e artificiais de um território.
Hoje, após várias evoluções tecnológicas a cartografia é precisa e conta com tecnologia
digital através de inúmeros recursos como imagens orbitais, sistema de posicionamento por
14
satélites, programas e computadores que facilitam as atividades cartográficas e também
proporcionam uma rápida divulgação e utilização de informações (LABTATE, 2011).
Assim, as informações cartográficas disponíveis atualmente são mais precisas e
confiáveis e são resultados de ferramentas e sistemas computacionais. Os Sistemas de
Informações Geográficas (SIG) ou as ferramentas computacionais de geoprocessamento
permitem realizar análises complexas ao integrar dados de diversas fontes e ao criar banco de
dados geo-referenciados. Neste contexto, o termo geoprocessamento denota a disciplina do
conhecimento que utiliza técnicas matemáticas e computacionais para o tratamento de
informação geográfica e que vem influenciando de maneira crescente as áreas de análise de
recursos naturais, transportes, comunicações, energia e planejamento urbano e regional
(CÂMARA; DAVIS; MONTEIRO, 2001).
Conforme Carvalho (2002), um SIG no segmento dos transportes pode relacionar uma
informação importante de infraestrutura do transporte como condições de estradas, volume de
tráfego, taxa de acidentes e capacidade de uma ponte. Através de mapas digitalizados é
possível identificar a necessidade e a viabilidade de adoção de critérios consistentes para a
subdivisão do espaço urbano, de representar redes de tráfego e de avaliar a condição de
utilização do transporte público.
Pode-se citar como aplicações do geoprocessamento em transporte o planejamento da
capacidade e manutenção de vias, manutenção de sinalização, agrupamentos de pontos de
entrega e coleta para maximização de eficiência de frota de veículos, acompanhamento
estatístico de acidentes de tráfego, acompanhamentos estatísticos de transporte público,
criação de rotas para cargas intermunicipais e interestaduais e acompanhamento por GPS
(Global Position System) (CARVALHO, 2002).
1.1 OBJETIVOS DO TRABALHO
O objetivo principal deste trabalho é a especificação e implementação de um aplicativo
web para a consulta de itinerários e horários de transporte público urbano.
a) os itinerários deverão ser disponibilizados para visualização no Google Maps.
15
1.2 ESTRUTURA DO TRABALHO
Este trabalho está dividido em quatro capítulos, sendo que o segundo apresenta a
fundamentação teórica com conceitos de cartografia, mapas, geoprocessamento e web
mapping, Google Maps API, Entity Framework. Além disso, apresenta trabalhos correlatos
sobre o assunto.
O terceiro capítulo trata das tecnologias utilizadas para o desenvolvimento deste
trabalho, a utilização da API do Google Maps, linguagens, ferramentas e tecnologias. Fazem
parte desta especificação os diagramas de classes, de atividades, modelo entidade-
relacionamento e modelo conceitual. Também são comentados os resultados, problemas e
dificuldades encontrados durante a implementação da aplicação. O quarto capítulo apresenta
conclusões e extensões.
16
2 FUNDAMENTAÇÃO TEÓRICA
Para o entendimento deste trabalho são apresentados aspectos e conceitos da
cartografia e mapas. Em seguida são explicados conceitos de Sistema de Informações
Geográficas e web mapping. Na sequência são apontadas e relacionadas ferramentas
proprietárias disponíveis atualmente na Internet para integração com mapas, e a utilização
destas ferramentas em aplicações para transportes. Posteriormente são apresentadas as
tecnologias utilizadas neste trabalho, incluindo Entity Framework. Ao final são mencionados
os trabalhos correlatos.
2.1 CARTOGRAFIA
A comunicação entre os seres humanos permite o compartilhamento de informações,
ideias, emoções e habilidades. Assim, utilizam palavras, imagens, figuras, gestos, gráficos
dentre outros, para alcançar este propósito (BARBOSA; RABAÇA, 2001).
Conforme Loch (2006) ao estudar o progresso da civilização, o homem se depara com
esforços no sentido de como representar, por gráficos, as coisas importantes do meio ambiente
que permitem sua sobrevivência.
São do tempo das populações nômades das cavernas, os desenhos ou inscrições
rupestres, que lembram animais. Também é da antiguidade a informação dos primeiros mapas
marcando itinerários. Ainda não aparecia a estrutura espacial do ambiente; somente
marcavam uma rota que comunicava um conhecimento essencial à sobrevivência (LOCH
2006).
De acordo com Almeida, Guerrero e Fiori (2007) e Labtate (2011), o surgimento do
mapa precede da invenção da escrita. No tempo das cavernas, os mapas eram utilizados como
registro de deslocamentos, representando pontos importantes (matas, rios, possibilidades de
casa e de pesca, retornos para casa) por meio de imagens desenhadas. Eles apresentavam uma
relação direta entre a realidade e sua respectiva representação. Um dos mapas mais antigos já
encontrados foi confeccionado na Suméria (atual Iraque), em uma pequena tábua de argila
cozida. Data de aproximadamente 2.500 a.C., representa duas cadeias de montanhas, e ao
centro, um rio, provavelmente o Eufrates. Trate-se de um mapa simples, sem título, sem
17
legenda e sem escala, mas de valor histórico inestimável.
Conforme Labtate (2011) com o desenvolvimento de conceitos geométricos, novos
instrumentos de medição da superfície foram desenvolvidos: os egípcios (cerca de 1300 a.C.)
inventaram o côvado, instrumento para demarcar terras; os gregos usaram as teorias da
geometria para inferir a forma da terra, seu tamanho e os conceitos de latitude e longitude.
Apesar de os antigos chineses terem um sistema bem definido para mapeamento, a
Cartografia atual vem das técnicas e conhecimentos estabelecidos pelos gregos, onde a ênfase
eram as relações espaciais. Os romanos herdaram e ampliaram esse conhecimento, aplicando-
os na construção dos seus mapas. Na Idade Média houve um retrocesso científico. Porém, na
Era dos Descobrimentos, com a tecnologia manual associada à tecnologia magnética,
representada pela Bússola, surgiram as Cartas De Marear, que serviam para as navegações
marítimas na época. No mapeamento moderno o foco é o lugar, tratado nos mapas de
referência geral para a localização. As representações dos fenômenos geográficos como clima,
vegetação, uso do solo, densidade populacional, por exemplo, deu origem aos mapas
temáticos no século XVIII.
Atualmente, na era da informação, o desenvolvimento humano requer cada vez mais
exatidão nas medidas, e a teoria de sistemas aparece forte na metade do século XX. O
ambiente precisa ser entendido e administrado como um sistema de processos inter-
relacionados. A complexidade do mundo atual exige mapas especializados e rigorosos, pois a
informação é uma ferramenta poderosa em questões de inventário e manejo do planeta. A
produção de mapas é digital. A partir da década de 1960 o mapeamento por computador passa
a ser operacional tanto na produção de mapas de base quanto na produção de mapas
temáticos, com a análise matemática e a estatística de massa de dados, em programas
computacionais denominados de SIG (Sistemas de Informação Geográfica) (LABTATE,
2011).
Na história da Cartografia e da humanidade, Loch (2006) aponta que os mapas antigos
eram vistos como veículos de orientação no espaço geográfico. A principal característica dos
mapas era a estocagem dos dados geográficos que serviam para análise dos lugares e de como
chegar até eles. Com a evolução humana e também da Cartografia, os mapas passaram a ser
considerados também como uma forma de comunicação de dados e mais recentemente, como
um instrumento de visualização científica. Entretanto a Cartografia pode ligar igualmente a
análise, a visualização e a comunicação de dados.
Para os cartógrafos, os mapas são veículos de transmissão do conhecimento. Eles são
representações gráficas de determinado espaço geográfico, concebidos para transmitir a visão
18
subjetiva ou conhecimento de alguém para alguns ou para muitos. Esse conhecimento pode
ser o mais amplo e variado possível ou o mais restrito e objetivo possível. Assim, cada mapa
tem um autor, uma questão e um tema.
Se os mapas são modelos da realidade (representação gráfica) e a realidade é vista de
maneira individual, então eles são subjetivos e não podem ser considerados como fotografias
da realidade ou a própria realidade reduzida (LOCH 2006).
Ainda conforme Loch (2006), um mapa como modelo da realidade pode tudo:
representar o passado, o futuro desconhecido ou imaginado, considerando o científico e a arte,
os fatos e a ficção.
Um mapa pode ser considerado como um Sistema de Informação Espacial que fornece
respostas para muitas questões referentes à área representada, por exemplo:
a) a distância entre dois pontos, a posição de pontos com relação a outro;
b) o tamanho das áreas;
c) a distribuição de certos padrões.
Essas respostas podem ser retiradas diretamente de um mapa sem necessidade de ajuda
de implementações.
Assim sendo, Loch (2006) afirma que o objetivo da Cartografia, consiste na
representação da superfície terrestre ou parte dela, de forma gráfica e bidimensional, que
recebe o nome genérico de mapa ou carta. Atualmente algumas definições ampliam esse
significado inicial, e incluem aspectos da confecção e uso de mapas e cartas e seus produtos
tais como, maquetes, visualizações 3-D da superfície, etc.
As características básicas dos mapas são:
a) localização e atributos: os mapas são concebidos a partir desses dois elementos da
realidade. Onde localização é dada por suas posições no espaço (coordenadas)
bidimensional e tridimensional. Os atributos são as qualidades e as magnitudes, ou
ainda variáveis temáticas: temperatura, clima, tipo de solo e tipos de religiões;
b) escala: caracteriza-se pela representação dimensional entre a realidade gráfica e a
realidade, a representação reduzida do mundo real;
c) projeção cartográfica: nas plantas, pode-se desconsiderar a curvatura da Terra
porque são representadas pequenas áreas. Nos mapas, a representação da Terra se
restringe a um problema, que é a construção de um mapa com uma figura de
imagem adequada, semelhante ao que se seja representar: uma esfera. Como não há
possibilidade de uma representação absolutamente rigorosa, o homem procurou
soluções cartográficas aproximadas, as quais são conhecidas como projeções
19
cartográficas. Almeida, Guerrero e Fiori (2007) resumem que projeções
cartográficas são operações matemáticas utilizadas para representar a superfície
esférica da Terra em uma superfície plana;
d) abstração: os mapas são abstrações da realidade. Pois é impossível reduzir o mundo
real, tal como ele é representa-lo em um mapa. Ele é tão complexo que o resultado
ficaria elegível, confuso e provavelmente não aproveitável. Portanto, os mapas
mostram somente informações selecionadas do mundo real para serem
representadas. Essa informação é subjetiva e depende de uma variedade de
operações, tais como simplificação e classificação que procuram facilitar o
entendimento;
e) simbolismo: os dados que descrevem um fenômeno de um determinado espaço
geográfico (seja um país, estado, município, bacia hidrográfica ou outro qualquer)
podem ser mostrados com o uso de uma variedade de signos gráficos. As
características gráficas dos traços relacionados aos atributos dos dados conduzem a
uma ideia de signos, os quais são designados os símbolos. Os símbolos dotados de
significado geográfico, quando arranjados num plano formam o que se chama de
Mapa. Todos os mapas usam signos para representar elementos da realidade. O
significado dos signos caracteriza o simbolismo da Cartografia.
De acordo com Loch (2006) a evolução humana na construção de gráficos e mapas
aconteceu paralela à evolução das ideias e da tecnologia. O mapa foi uma maneira que o
homem encontrou para representar o que era importante ou de interesse de um grupo
dominante. Era preciso comunicar o conhecimento existente sobre o mundo e isto envolvia o
espaço e sua percepção e as imagens construídas pela mente humana. Neste processo, o
homem desenvolveu habilidades em descrever um cenário geográfico usando a simbologia
gráfica para construir o que se designa “mapa”. Conforme as necessidades e a tecnologias
disponíveis, os mapas evoluíram de simples representações do meio, para complicadas
representações considerando a esfericidade da Terra.
Onde, após várias evoluções tecnológicas a cartografia é precisa e conta com a
tecnologia digital através de inúmeros recursos, ferramentas e serviços: sistemas de
posicionamento por satélites, programas e computadores que facilitam as atividades
cartográficas e também proporcionam uma rápida divulgação de informação bem como sua
utilização (LABTATE, 2011).
Para Almeida, Guerrero e Fiori (2007) essas ferramentas tecnológicas permitem para a
cartografia sofisticação e precisão de dados até então jamais apresentados nos mapas.
20
2.2 GEOPROCESSAMENTO E GEOTECNOLOGIAS
Conforme Faria (2008) durante toda a história as civilizações se ocuparam em estudar
e registrar através de mapas ou cartas dados sobre o relevo, fauna, flora, rotas comerciais,
limites políticos, clima, entre outros. Com o avanço da tecnologia surgiu a possibilidade de se
integrar vários dados e mapas e analisá-los em conjunto, possibilitando, através de análises
complexas e a criação de bancos de dados georreferenciados (dados ou objetos referenciados
com base em sua localização geográfica), o desenvolvimento de diversas áreas como a
cartografia, o planejamento urbano, comunicações, transportes e até a análise de recursos
naturais.
Nos últimos anos tem-se presenciado a massificação do geoprocessamento. Com o
lançamento de diversas ferramentas, proprietárias ou não. Atualmente, qualquer pessoa
mesmo que não entenda nada de geoprocessamento pode ter acesso a mapas de qualquer
região do mundo que aliam imagens de satélite, GPS e modelos em 3D.
Conceitualmente, geoprocessamento é o tratamento das informações geográficas, ou de
dados georreferenciados, por meio de softwares específicos e cálculos. Ou, ainda, o conjunto
de técnicas relacionadas ao tratamento da informação espacial (FARIA 2008).
Moura (2005) acredita que o termo Geoprocessamento, oriundo do sentido de
processamento de dados georreferenciados, significa implantar um processo que traga um
progresso, um andar avante na grafia ou representação da Terra. Não é somente representar,
mas é associar a esse ato um novo olhar sobre o espaço, um ganho de conhecimento, que é a
informação.
O geoprocessamento engloba processamento digital de imagens, cartografia digital e
os sistemas de informações geográficos, ou sistemas de informação geográfica, ou mesmo
sistema geográfico de informação.
A cartografia digital refere-se à automação de projetos, captação, organização e
desenho de mapas; enquanto o sistema de informações geográficas refere-se à aquisição,
armazenamento, manipulação e apresentação dos dados georreferenciados (MOURA, 2005).
Medeiros (2011) explica geotecnologias, como as tecnologias relacionadas com as
diferentes etapas do Geoprocessamento. Geoprocessamento é o termo usado para definir o
conjunto de tecnologias utilizadas para o tratamento da informação espacial. Sempre que em
um projeto o componente espacial de um dado pode/deve ser considerada, há condições de se
aplicar técnicas de Geoprocessamento.
21
De forma geral, o Geoprocessamento apresenta as etapas descritas a seguir, com os
respectivos conjuntos de técnicas (geotecnologias) relacionadas ao tratamento da informação
espacial:
a) coleta: cartografia, sensoriamento remoto, fotometria, GPS (Global Positioning
System), dados alfanuméricos;
b) armazenamento: banco de dados;
c) tratamento e análise: modelagem de dados, geoestática e análise espacial;
d) uso Integrado: Sistemas de Informações Geográficas (SIG) e WebGis (web
mapping).
Estas tecnologias têm sido aplicadas em estudos ambientais, planejamento urbano,
cadastro multifinalitário, saúde pública, agricultura, entre outras áreas (MEDEIROS, 2011).
2.3 WEB MAPPING
Web mapping, também conhecida como WebGis, está relacionada ao
Geoprocessamento. De forma simplificada, pode-se definir como a publicação na internet de
mapas interativos ou dados espaciais. Diversos softwares, tanto de origem proprietária como
de código aberto podem ser utilizados para o desenvolvimento de uma aplicação web mapping
(MEDEIROS, 2009).
Esta disponibilização de recursos e ferramentas permite facilidades nas construções de
aplicações ou projetos simples e por vezes complexos.
Geralmente através do uso de Application Programming Interface (API), que é
composta por uma série de funções acessíveis por programação, e que permitem utilizar
características do software menos evidentes ao utilizador tradicional (WIKIPEDIA, 2012a),
aplicações web mapping permitem o uso ou criação de mapas, consultas, criação de rotas sem
que essa atividade fique sob a responsabilidade do desenvolvedor. Ao desenvolvedor cabe à
implementação específica do projeto e suas regras de negócio. Além é claro, da escolha de
qual ferramenta disponível melhor se adequa as necessidades do projeto: compatibilidade,
visualização, documentação, etc.
Para Medeiros (2009) destacam-se três tipos de mapas básicos disponibilizados na web
com dados geográficos:
a) mapas estáticos: são mapas na forma de imagem (nos formatos JPEG e PNG, por
22
exemplo) que são inseridas em páginas da internet. Essa é a forma mais básica de
publicar um mapa na internet, e por consequência, este tipo de mapa apresenta
baixa interatividade com o usuário. Assim, o foco principal deste tipo de mapa é
portar a representação de algum tipo de informação espacial para o usuário
possibilitando, exclusivamente, sua visualização. Uma das vantagens deste método
é que havendo grande quantidade desses mapas representando diferentes épocas
pode-se fazer um estudo temporal comparativo;
b) mapas gerados a partir de formulários: consiste em disponibilizar ao usuário um
formulário onde são solicitadas informações quanto à área geográfica de interesse.
Quando o usuário termina de preencher o formulário, as informações são
transmitidas a um servidor, que recupera os dados fornecidos e transforma o mapa
final exibindo-o em um formato de imagem. A escolha por esse tipo de ferramenta
deve levar em consideração certas limitações. Por exemplo, há pouca versatilidade
sobre esse mapa resultante, uma vez que a ação de arrastar o mapa requer a geração
de uma nova imagem;
c) navegação baseada em mapas dinâmicos: neste tipo de web mapping, o usuário
seleciona uma área de seu interesse em um mapa geral, o que resulta na navegação
para outro mapa ou imagem mais específico, ou seja, com informações mais
detalhadas desta região. Em algumas aplicações, existem ícones que ativam funções
mais elaboradas, como cálculo de distâncias na tela, consulta aos atributos de
elementos ou ativação e desativação de camadas de informação.
Conforme Medeiros (2011), a grande popularização no uso de web mapping, devido a
grande quantidade de serviços gratuitos, também apresenta as vantagens:
a) facilidades de manuseio pelo usuário final (aplicações amigáveis);
b) independência de sistema operacional;
c) o usuário só precisa de um computador com navegador e acesso à internet;
d) dependendo da arquitetura da qual se fez uso, não é necessário carregar, instalar ou
manter qualquer software ou dados no cliente;
e) interoperabilidade (podem interagir com sistemas desktop ou outros sistemas da
internet);
f) permite diferentes tipos de acesso aos dados.
Entre as desvantagens, Medeiros (2011) aponta:
a) tempo de carga de dados;
b) limitações das análises espaciais;
23
c) não substitui um programa de SIG por completo.
2.3.1 Bing Maps
Bing Maps, representado na Figura 1, anteriormente conhecido por de Live Search
Maps, Windows Live Maps e Windows Live Local, é um sistema desenvolvido pela
Microsoft para visualização interativa dos mapas e imagens de satélite como parte das
aplicações online (WIKIPEDIA, 2012b).
Fonte: Bing Maps (2012).
Figura 1 – Bing Maps
O Bing é um serviço de mapas online, que permite aos usuários pesquisar, descobrir,
planejar e compartilhar informações sobre locais específicos usando mapas rodoviários
tradicionais, vistas fotográficas áreas de alta resolução, e capacidades de busca por
aproximação (MICROSOFT, 2012).
As principais características da plataforma incluem (MICROSOFT, 2011):
a) imagens fotorrealistas;
b) geocodificação para mais de 70 milhões de endereços;
c) opções de suporte disponíveis;
d) robusto conjunto de APIs, disponível para desenvolvedores, para construção de
novas aplicações.
Entre o conjunto de API’s destacam-se (MICROSOFT, 2012):
24
a) Bing Maps SOAP (Simple Object Access Protocol) Services: é um conjunto de
serviços que permitem integrar mapas e imagens, direções de condução, cálculos de
distâncias, etc;
b) Bing Maps REST (Representational State Transfer) Services: estes serviços
utilizam URLs Rest para executar tarefas de criação de um mapa com picos,
geocodificação de um endereço, e recuperação de metadados de imagens ou
cálculos de percurso;
c) Bing Maps WPF Control: permite ao desenvolvedor integrar o Bing Maps ao WPF.
O Bing Maps WPF controla e recupera as últimas imagens Bing Maps para o
aplicativo desenvolvido usando a arquitetura baseada em nuvem.
2.3.2 Open Street Maps
Open Street Maps, conhecido pela sigla OSM, é um projeto colaborativo para criar um
mapa livre e editável do mundo, representado na Figura 2. De código aberto, os mapas são
criados usando dados de receptores GPS portáteis, fotografias aéreas e outras fontes livres e
são disponibilizados para qualquer uso, incluindo fins comerciais. Tanto as imagens obtidas
por processamento dos dados quanto os dados estão disponíveis sob uma licença Creative
Commons Attribution-ShareAlike 2.0. Utilizadores registrados podem carregar os históricos
dos GPS e editar os dados usando as ferramentas disponíveis (OPEN STREET MAP WIKI,
2012).
25
Fonte: Open Street Map (2012).
Figura 2 – Open Street Maps
No Brasil o projeto apresenta poucas informações, apenas algumas cidades tem um
considerável número de bairros mapeados.
A principal distinção entre Open Street Maps e outros mapas disponíveis, além da
proposta de ser um projeto colaborativo, é que estes outros têm ferramentas que permitem ao
utilizador sobrepor seus próprios dados no mapa, e exibi-los de forma particular. Ao contrário
destes sistemas, a finalidade primária do Open Street Maps, é fornecer ao usuário os dados de
mapas subjacentes. Qualquer pessoa pode utilizar estes dados de diferentes formas em seus
projetos (OPEN STREET MAP WIKI, 2012).
De forma resumida, o modelo de dados do Open Street Maps, apresenta as seguintes
características:
a) tags: são etiquetas, valores chave, ligados a cada elemento geográfico do Open
Street Maps (com um máximo de 255 caracteres, incluindo espaços), a restrição é
que devem ser únicas no interior do elemento. E ainda, se não houver tags
associadas a um recurso, não há como exibir esses dados em renderizadores;
b) nós: pontos na Terra são chamados de nós e são representados por uma latitude,
longitude e quantas marcas podem ser necessárias. São usados para representar
lojas, paradas de ônibus, bancos e caixas de correios. Um nó não etiquetado (sem
tags) será sempre um subelemento de outro elemento;
c) caminhos: uma lista ordenada de nodos é chamada de caminho. Um caminho tem
no máximo 2.000 nós para assegurar que as ferramentas e utilizadores não sejam
26
sobrecarregados com estruturas muito grande e de difícil manipulação. São usados
para representar as características lineares como caminho, estradas, linhas de
transporte ferroviário;
d) relações: são ordenados, listas de nós, formas ou relações. Cada membro de uma
relação tem um papel opcional que dá uma informação adicional sobre esse
subelemento. Esses papéis são sequências de até 225 caracteres, como valores de
marca. Podem representar estradas ou ciclovias, limites administrativos,
dependendo do conjunto de etiquetas associadas;
e) identificadores: qualquer elemento de dados Open Street Map (nós, caminhos,
relações) é identificado por um único identificador numérico, cujo propósito é
permitir a referência de características individuais. Uma relação ou um caminho
usam esses identificadores para fazer referência aos subelementos;
f) formatos de arquivo: arquivos de dados são tradicionalmente distribuídos em um
formato XML (eXtensible Markup Language), que representa o nó, caminhos e
relação de um esquema simples. Porém sem compressão, este formato XML pode
ser extremamente grande, assim sendo geralmente é distribuído usando um
algoritmo de compressão como GZIP ou BZ2. A maioria das ferramentas
desenvolvidas para trabalhar com o formato XML do OSM também pode
manipular o XML compactado. Para resolver o problema do tamanho do XML e
velocidade de análise, um formato separado usando o protocolo do Google Projeto
Buffers foi criado para embalar o máximo possível de dados OSM em um arquivo
binário (OPEN STREET MAP WIKI, 2012).
2.3.3 Google Maps
Google Maps, conforme Figura 3, é um serviço de pesquisa e visualização de mapas e
imagens de satélite da Terra na web fornecido e desenvolvido pela Google (GOOGLE MAPS,
2012).
27
Fonte: Google Maps (2012).
Figura 3 – Google Maps
Atualmente, o serviço disponibiliza mapas e rotas para qualquer ponto nos Estados
Unidos, Canadá, União Europeia, Austrália e Brasil, entre outros. Disponibiliza também
imagens de satélite do mundo todo, e apresenta imagens detalhadas de grandes cidades, como
Nova Iorque, Paris, São Paulo e Rio de Janeiro (GOOGLE MAPS, 2012).
O Google Maps oferece uma grande capacidade de resposta, interface intuitiva,
mapeamento da rua e imagens. O principal motor por trás de sua rápida aceitação para
visualização de mapas na internet é a capacidade de personalizar o mapa para atender às
necessidades específicas da aplicação. A possibilidade de visualização do mapa com a adição
de dados específicos do aplicativo é o verdadeiro motor de sua aceitação como uma
ferramenta de visualização geoespacial (GHELMAN, 2009).
O sistema de transporte coletivo de Blumenau integra suas consultas ao Google Maps.
O sistema objetiva facilitar o deslocamento pela cidade através de transporte coletivo.
Informando o ponto de saída, o destino e o horário da saída, o mapa traça as opções de pontos
de ônibus, de linha do transporte urbano e do trajeto a ser feito a pé até o ponto e deste para o
destino. O tempo total é calculado de acordo com as informações repassadas pelo Consórcio
Siga (FRESARD, 2011).
O Sistema Integrado de Transporte Coletivo Urbano de Blumenau (SIB) oferece
noventa e sete linhas com integração em seis terminais urbanos, que permitem o
deslocamento da população para os mais diversos locais pagando uma tarifa única.
Diariamente duzentos e sessenta e sete ônibus do sistema circulam por duzentas e setenta e
28
sete ruas, oferecendo cinco mil, quatrocentos e trinta e sete viagens e percorrendo cerca de
cinquenta e cinco mil quilômetros. Atendendo assim, uma população usuária deste transporte
de cento e vinte cinco mil passageiros (SETERB, 2012).
O Google Maps apresenta uma série de APIs que são apresentadas na seção a seguir,
bem como um maior detalhamento deste serviço.
2.3.3.1 API do Google Maps
Conforme Google Developers (2012a), a Google Maps API é um serviço gratuito,
disponível para qualquer site que o público possa usar gratuitamente.
Existe uma restrição de uso para empresas que cobram taxas pelo acesso, rastreiam
recursos ou constroem aplicativos internos, estas são orientadas a usar a Google Maps API
Premier, que fornece suporte técnico, recursos avançados e um acordo de nível de serviço.
A Google Maps possui várias APIs que permitem que seja incorporada a
funcionalidade do Google Maps nos aplicativos e ainda adicionar dados da própria aplicação
desenvolvida sobre os mapas:
a) Google Maps Java Script API: Permite a incorporação de um mapa na página web
desenvolvida usando Java Script. Disponibilizada na Versão 3. Ainda conforme
Google Developers (2012a), a Versão 2 foi oficialmente removida e continuará a
funcionar de acordo com a política de remoção da Google, orientando que as
aplicações sejam migradas para a Versão 3;
b) Google Maps API for flash: Permite a incorporação de um mapa na página web
baseada em Flash,
c) Google Earth API: Permite a incorporação de mapas em 3D;
d) Serviços da web: Permite o uso de solicitações de URL para acessar informações
de geocodificação, rotas, elevação e lugares dos aplicativos cliente e manipule os
resultados em JSON (JavaScript Object Notation) ou XML;
e) Google Maps Data API: Permite a visualização, armazenagem e atualização de
dados do mapa por meio de feeds da Google Data API, usando um modelo de
elementos (marcadores, linhas e formas) e coleção de elementos (GOOGLE 2012).
Conforme Google Developers (2012b), a versão 3 da API do Google Maps é
implementada usando uma estrutura modificada de MVC (Model-view-controller).
Todas as alterações de um estado de um objeto MVC são manipuladas por meio das
29
funções set e get de um formato específico. Todos os estados dos objetos MVC são
armazenados como propriedades deste objeto, e todas as observações sobre as alterações de
estado feitas por meio de manipuladores de eventos também são em um formato específico.
Ainda conforme Google 2012 B, esta versão da API Java Script do Google Maps não
faz uso de chaves de API.
Conceitualmente, na API há uma divisão em áreas, as quais são:
a) objetos de mapas básicos;
b) objetos eventos de mapa;
c) controles de mapa;
d) sobreposições de mapa;
e) serviços de mapa.
2.3.3.1.1 Objetos de Mapas Básicos
Conforme Google Developers (2012c) o elemento fundamental da API do Google
Maps V3 é o próprio mapa. O objeto fundamental é google.maps.Map.
Na aplicação web deve ser declarado um verdadeiro DOCTYPE. Alguns CSS que
funcionam no modo quirks não são válidos no modo padrão. Especificamente, todos os
tamanhos baseados em porcentagem devem ser herdados de elementos de bloco pai. Se algum
dos ancestrais não especificar um tamanho, eles são atribuídos o tamanho de 0 x 0 pixels. Por
esse motivo, inclui-se a declaração <style> conforme Quadro 4.
<style type="text/css">
html { height: 100% }
body { height: 100%; margin: 0px; padding: 0px }
#map_canvas { height: 100% }
</style>
Fonte: Google Developers (2012c).
Quadro 4 – Google Maps – Exemplo de definição do recipiente do mapa
A declaração CSS indica que o recipiente do mapa <div> (denominado map_canvas)
deverá ocupar 100% da altura do corpo HTML. Observe que é necessário declarar
especificamente essas percentagens tanto para <body>quanto para <html> conforme
representação do Quadro 4.
<html>
<head>
<meta name="viewport" content="initial-scale=1.0, user-scalable=no" />
30
<script type="text/javascript"
src="https://maps.google.com/maps/api/js?sensor=set_to_true_or_false">
</script>
Fonte: Google Developers (2012c).
Quadro 5 – Google Maps – Exemplo da chamada da API do Google Maps
O URL http://maps.google.com/maps/api/js aponta para o local de um arquivo
JavaScript que carrega todos os símbolos e as definições necessárias ao uso da API do Google
Maps V3. A página deve conter uma tag script que aponte para esse URL.
Também deve-se definir um parâmetro sensor para indicar se esse aplicativo usa um
sensor para determinar a localização do usuário. No Quadro 5, verifica-se uma variável
set_to_true_or_false, que deve ser explicita true ou false.
Precisa-se reservar um lugar para que o mapa seja exibido em uma página da web,
normalmente é feito criando-se um elemento chamado <div> e obtendo uma referência a ele
no DOM (Modelo de Objeto do Documento) do navegador.
Para inicializar um mapa, cria-se um objeto Map options para conter as variáveis de
inicialização do mapa. Esse objeto não é construído; em vez disso, ele é criado como um
literal de objeto. Para centralizar o mapa em um ponto específico, cria-se o valor latlng para
conter esse local e o passar nas opções do mapa.
var myLatlng = new google.maps.LatLng(-34.397, 150.644);
var myOptions = {
zoom: 8,
center: myLatlng,
mapTypeId: google.maps.MapTypeId.ROADMAP
};
Fonte: Google Developers (2012c).
Quadro 6 – Google Maps – Exemplo das definições para construção do mapa
Também se define nas opções de mapa o nível de zoom inicial e mapTypeId para
indicar o tipo de mapa. No exemplo do Quadro 6, acima, optou-se por
google.maps.MapTypeId.ROADMAP.
Os seguintes tipos são suportados:
a) ROADMAP exibe as blocos 2D normais, padrão, do Google Maps;
b) SATELLITE exibe blocos fotográficos;
c) HYBRID exibe uma mistura entre blocos fotográficos e uma camada de blocos com
recursos importantes (estradas, nomes de cidade);
d) TERRAIN exibe blocos de relevo físico para exibição de recursos de elevação e água
(montanhas, rios etc).
Anteriormente, na API do Google Maps V2, existia um tipo de mapa padrão. Na
versão V3 deve-se definir um tipo de mapa inicial específico para ver os blocos apropriados.
31
A classe JavaScript que representa um mapa é a classe Map, conforme exemplo no
Quadro 7.
var map = new google.maps.Map(document.getElementById("map_canvas"),
myOptions);
Fonte: Google Developers (2012c).
Quadro 7 – Google Maps – Exemplo da classe google.maps.Map
Ao criar uma nova instância do mapa, deve-se especificar um elemento HTML <div>
na página como um recipiente para o mapa. Os nós HTML são filhos do objeto JavaScript
document e obtém-se uma referência a esse elemento pelo método
document.getElementById().
Ainda conforme Google Developers (2012c), este código define uma variável
(chamada map) e a atribui a um novo objeto Map, além de passar as opções definidas no literal
de objeto myOptions. Essas opções serão usadas para inicializar as propriedades do mapa. A
função Map() é conhecida como construtor.
Para o carregamento, usa-se uma função, como exemplo no Quadro 8.
<body onload="initialize()">
Fonte: Google Developers (2012c).
Quadro 8 – Google Maps – Exemplo Carregamento Initialize()
Durante a renderização de uma página HTML, o DOM é criado e todas as imagens e
scripts externos são recebidos e incorporados ao objeto document. Para garantir que o mapa
seja colocado na página após ela ter sido totalmente carregada, só executa-se a função que
cria o objeto Map depois que o elemento <body> da página HTML recebe um evento onload.
Isso evita um comportamento imprevisível e dá mais controle sobre como e quando o mapa é
desenhado.
O atributo onload da tag body é um exemplo de um manipulador de evento. A API
Javascript do Google Maps fornece um conjunto de eventos que podem ser manipulados para
determinar alterações de estado.
2.3.3.1.2 Objetos de Eventos de Mapa
De acordo com Google Developers (2012d), o JavaScript no navegador é orientado por
eventos, ou seja, o JavaScript responde a interações gerando eventos e espera que um
programa responda aos eventos relevantes. O modelo de evento da API do Google Maps V3
32
há dois tipos de eventos:
a) eventos da interface de usuário: Alguns objetos na API do Google Maps são
desenvolvidos para responder aos eventos de usuário, como eventos do mouse ou
do teclado. Um objeto google.maps.Marker pode escutar os seguintes eventos de
usuário, por exemplo: 'click', 'dblclick', 'mouseup', 'mousedown',
'mouseover', 'mouseout'.
b) eventos de mapa: Para receber notificações de evento usa-se o manipulador de
evento addListener(). Esse método usa um objeto, um evento a ser ouvido e uma
função a ser chamada quando ocorre o evento especificado. Um exemplo onde há
uma mistura eventos de usuário com eventos de alteração de estado, seria anexar
um manipulador de evento a um marcador que amplia o mapa quando clicado.
2.3.3.1.3 Controles de Mapa
Conforme Google Developers (2012e) os mapas do Google Maps contêm elementos de
interface do usuário que possibilitam a interação do usuário em todo o mapa. Estes elementos
são conhecidos como controles e pode-se incluir variações desses controles no aplicativo da
API do Google Maps. A API do Google Maps é fornecida com vários controles incorporados
que podem ser usados nos mapas.
Os controles não podem ser acessados ou modificados diretamente. Em vez disso,
precisa–se modificar os campos MapOptions do mapa que afetam a visibilidade e a
apresentação dos controles. Pode-se ajustar a apresentação do controle ao instanciar o seu
mapa (com MapOptions apropriados) ou modificar um mapa de forma dinâmica chamando
setOptions() para alterar as opções do mapa. Nem todos esses controles estão ativados por
padrão.
Em vez de especificar e configurar controles individuais pode-se simplesmente
especificar que o mapa tenha a aparência da interface do Google Maps (incluindo todos os
novos recursos ou controles que venham a ser adicionados no futuro). O mapa será exibido
com os controles padrão.
Alguns controles aparecem no mapa por padrão, enquanto outros só aparecerão se
forem especificamente solicitados. A adição ou remoção de controles do mapa é especificada
nos campos do objeto Map options, definidos como true para ficarem visíveis ou como
false para ficarem ocultos.
33
2.3.3.1.4 Sobreposições de Mapas
Conforme Google Developers (2012f), superposições são objetos no mapa ligados a
coordenadas de latitude/longitude, portanto elas se movimentam quando se arrasta ou se
amplia o mapa. As superposições refletem os objetos que o implementador adiciona ao mapa
para designar pontos, linhas, áreas ou coleções de objetos.
A Google Maps API tem vários tipos de superposições:
a) locais individuais no mapa são exibidos por meio de marcadores. Algumas vezes,
os marcadores podem exibir imagens personalizadas de ícones e, nesse caso, são
chamados de ícones. Marcadores e ícones são objetos do tipo Marker;
b) as linhas no mapa são exibidas por meio de polilinhas (que representam uma
sequência ordenada de locais). As linhas são objetos do tipo Polyline;
c) as áreas com forma aleatória no mapa são exibidas por meio de polígonos, que são
parecidos com as polilinhas. Assim como as polilinhas, os polígonos são uma
sequência ordenada de locais; ao contrário das polilinhas, os polígonos definem
uma região delimitada por eles;
d) as camadas do mapa podem ser exibidas usando tipos de mapa de superposição.
Pode-se criar o próprio conjunto de blocos criando tipos de mapa personalizados
que substituem ou são exibidos por cima de conjuntos de blocos de mapas base na
forma de superposições;
e) a janela de informações também é um tipo especial de superposição para exibição
de conteúdo (normalmente texto ou imagens) dentro de um balão pop-up por cima
de um mapa em um determinado local;
f) também é possível implementar as próprias superposições personalizadas. Essas
superposições personalizadas implementam a interface OverlayView.
As superposições são normalmente adicionadas ao mapa quando são criadas; todas as
superposições definem um objeto Options para ser usado durante a criação, permitindo que
se especifique o mapa no qual elas deverão aparecer. Também é possível adicionar
diretamente uma superposição ao mapa usando o método setMap() da superposição,
passando o mapa ao qual a superposição deverá ser adicionada.
Para remover uma superposição de um mapa, deve-se usar o método setMap() da
superposição, passando null. A chamada desse método não exclui a superposição; isso
simplesmente remove a superposição do mapa. Para excluir a superposição, será necessário
34
removê-la do mapa e definir a própria superposição como null.
2.3.3.1.5 Serviços de Mapas
Conforme Google Developers (2012g), geocodificação é o processo de conversão de
endereços (como "Rua Antônio da Veiga, 416 – Itoupava Seca, Blumenau, SC, Brasil") em
coordenadas geográficas (como latitude -26.907207 e longitude -49.079702), e pode-se incluir
marcadores ou posicionar o mapa.
A API do Google Maps fornece uma classe de geocodificador para geocodificar
endereços dinamicamente a partir da entrada do usuário. Estas solicitações têm taxas de
limitação para desencorajar o abuso do serviço.
2.3.3.1.5.1 Solicitações de Geocodificação
O acesso ao serviço de geocodificação é assíncrono, uma vez que a API do Google
Maps precisa fazer uma chamada para um servidor externo. Assim, precisa-se passar um
método de retorno de chamada a ser executado após a conclusão da solicitação. Esse método
de retorno de chamada processa os resultados. O geocodificador pode retornar mais de um
resultado.
Pode-se acessar o serviço de geocodificação da API do Google Maps dentro do código
por meio do objetogoogle.maps.Geocoder. O método Geocoder.geocode() inicia uma
solicitação para o serviço de geocodificação, passando um literal de objeto GeocodeRequest,
que contém os termos de entrada e um método de retorno de chamada a ser executado ao
receber a resposta.
O serviço de geocodificação exige um método de retorno de chamada a ser executado
após a recuperação dos resultados do geocodificador. Esse retorno de chamada deve passar
dois parâmetros para conter results e um código status, nessa ordem. Como Geocoder
pode retornar mais de uma entrada, o literal do objeto GeocoderResults é uma matriz.
O literal do objeto GeocoderResults representa um resultado individual de
geocodificação e é um objeto com o formato, conforme Quadro 9.
results[]: {
types[]: string,
formatted_address: string,
address_components[]: {
short_name: string,
35
long_name: string,
types[]: string
},
geometry: {
location: LatLng,
location_type: GeocoderLocationType
viewport: LatLngBounds,
bounds: LatLngBounds
}
}
Fonte: Google Developers (2012c).
Quadro 9 – Google Maps – Resultados do objeto GeocodeRequest
Esses campos são explicados a seguir:
a) types[] é uma matriz que indica o tipo do resultado retornado. Essa matriz contém
um conjunto de uma ou mais tags que identificam o tipo de recurso retornado no
resultado;
b) formatted_address é uma string que contém o endereço legível para humano
deste local. Normalmente, esse endereço é equivalente ao "endereço postal", que
pode variar entre os países;
c) address_component[] é uma matriz que contém os componentes de endereço
separados, conforme explicado acima;
d) geometry contém as seguintes informações: o location contém o valor de
latitude, longitude geocodificado. Retorno desse local como um objeto LatLng, não
como uma string formatada. O location_type armazena dados adicionais sobre o
local especificado.
2.3.3.1.5.2 Geocodificação reversa
O termo geocodificação normalmente se refere à tradução de um endereço legível para
humanos em uma localização no mapa. O processo de conversão, ou seja, tradução de uma
localização no mapa em um endereço legível para humanos é conhecida como geocodificação
reversa.
O Geocoder suporta a geocodificação reversa diretamente. Em vez de fornecer um
endereço textual, basta fornecer um par de latitude e longitude separado por vírgula no
parâmetro latLng.
O geocodificador reverso normalmente retorna mais de um resultado. Os endereços da
geocodificação não são apenas endereços postais, mas qualquer forma de nomear
geograficamente uma localização. O geocodificador reverso retorna todos os resultados.
O geocodificador reverso tenta encontrar resultados correspondentes para entidades
36
políticas (países, províncias, cidades e bairros), endereços e códigos postais.
Os endereços são retornados na ordem de melhor a pior correspondência.
Normalmente, o endereço mais exato é o resultado mais destacado.
A geocodificação reversa não é uma ciência exata. O geocodificador tentará encontrar
o local endereçável mais próximo dentro de uma certa tolerância.
2.3.3.1.5.3 Rotas
Pode-se calcular rotas (com diferentes meios de transporte) usando o objeto
DirectionsService. Esse objeto se comunica com o Serviço de rotas da Google Maps API
que recebe solicitações de rota e retorna resultados calculados. Pode-se manipular esses
resultados de rota manualmente ou usar o objeto DirectionsRenderer para renderizar esses
resultados.
Para usar rotas em V3, deve-se criar um objeto do tipo DirectionsService e chamar
o DirectionsService.route() para iniciar uma solicitação ao serviço de rotas, passando-a
como um literal do objeto DirectionsRequest contendo os termos de entrada e um método
de retorno de chamada a ser executado no recebimento da resposta.
Alguns destes campos são:
a) origin (obrigatório): especifica o local inicial a partir do qual a rota deve ser
calculada. Este valor pode ser especificado como uma String ou como um valor de
LatLng;
b) destination (obrigatório): especifica o local final para o qual a rota deve ser
calculada. Este valor pode ser especificado como uma String ou como um valor de
LatLng;
c) travelMode (obrigatório): especifica qual modo de transporte usar ao calcular a
rota;
d) unitSystem (opcional): especifica qual sistema de medidas usar ao exibir
resultados;
e) waypoints[] (opcional): especifica uma matriz de DirectionsWaypoints. Os
pontos de referência alteram um trajeto traçando-o pelos locais especificados. Um
ponto de referência é especificado como um literal de objeto com os campos
mostrados a seguir: location especifica o local do ponto de referência, como um
valor de LatLng ou como uma String que será geocodificada e o stopover é
um valor booleano que indica que o ponto de referência é uma parada no trajeto, o
37
que resulta na divisão do trajeto em dois;
f) optimizeWaypoints (opcional): especifica que o trajeto que está usando os
waypoints fornecidos pode ser otimizado para oferecer o trajeto mais curto
possível. Se este campo for definido como true, o serviço de rotas retornará os
waypoints reordenados em um campo waypoint_order.
Iniciar uma solicitação de rota para o DirectionsService com o método route()
requer a passagem de um retorno de chamada que será executado na conclusão da solicitação
de serviço. Esse retorno de chamada retornará um código de DirectionsResult e de
DirectionsStatus na resposta.
O DirectionsStatus pode retornar valores, ao qual destacam-se:
a) OK: indica que a resposta contém um DirectionsResult válido;
b) NOT_FOUND: indica que pelo menos um dos locais especificados na origem, destino
ou nos pontos de referência da solicitação não pôde ser geocodificado;
c) ZERO_RESULTS: indica que não foi possível encontrar nenhum trajeto entre a
origem e o destino;
d) MAX_WAYPOINTS_EXCEEDED: indica que muitos DirectionsWaypoints foram
fornecidos no DirectionsRequest. O máximo permitido de pontos de referência é
8, mais a origem e o destino. Para clientes da Google Maps API Premier, são
permitidos 23 pontos de referência, mais a origem e o destino;
Deve-se garantir que a consulta de rota retorne resultados válidos verificando esse
valor antes de processar o resultado.
2.3.3.1.5.4 Modos de transporte
Ao calcular rotas, precisa-se especificar o modo de transporte a ser usado. Atualmente,
os seguintes modos de transporte são suportados:
a) travelMode.DRIVING: indica as rotas de carro padrão usando a malha de
transporte rodoviário;
b) travelMode.WALKING: solicita rotas a pé por faixas de pedestre e calçadas;
c) travelMode.BICYCLING: solicita rotas por ciclovias e ruas para ciclistas.
2.3.3.1.5.5 Sistemas de medidas
Por padrão, as rotas são calculadas e exibidas usando o sistema de medidas do país ou
região de origem. Pode-se substituir esse sistema de medidas configurando explicitamente um
38
sistema de medidas dentro da solicitação usando um dos valores de UnitSystem
(unitSystem.METRIC, unitSystem.IMPERIAL).
2.3.3.1.5.6 DirectionsResult
O DirectionsResult contém o resultado da consulta de rota, que pode ser
manipulado manualmente ou passar para um objeto DirectionsRenderer, que pode
manipulá-lo automaticamente exibindo o resultado em um mapa.
Para exibir um DirectionsResult usando um DirectionsRenderer:
a) criar um objeto DirectionsRenderer;
b) chamar setMap() no renderizador para vinculá-lo ao mapa passado;
c) chamar setDirections() no renderizador, passando a ele o DirectionsResult,
como indicado acima. Como o renderizador é um MVCObject, ele detectará
automaticamente quaisquer alterações em suas propriedades e atualizará o mapa
quando suas rotas associadas forem alteradas.
Um DirectionsRenderer não somente manipula a exibição da polilinha e dos
marcadores associados, como também pode manipular a exibição textual de rotas na forma de
uma série de etapas. Para isso, chama-se o setPanel() no seu DirectionsRenderer,
passando o <div> no qual essas informações devem ser exibidas. Isso também garante a
exibição das respectivas informações de direitos autorais e de quaisquer avisos que possam
estar associados ao resultado.
2.3.3.1.5.7 Matriz de distância
A Google Distance Matrix API fornece um serviço para a computação da distância e a
duração da viagem entre várias origens e destinos usando um determinado modo de viagem.
Este serviço não retorna informações detalhadas sobre o trajeto. As informações de
rota, inclusive rotas textuais e polilinhas, podem ser obtidas passando-se a origem e o destino
desejados para o Serviço de rotas.
2.3.3.1.5.8 Elevação
O serviço de elevação fornece dados de elevação para locais na superfície da Terra,
incluindo locais em solos oceânicos (que retornam valores negativos). Em casos como esse,
para os quais o Google não possui medidas de elevação precisas para o local exato da sua
solicitação, o serviço intervirá e retornará um valor aproximado usando os quatro locais mais
39
próximos.
2.3.3.1.5.9 Street view
De acordo com Google Developers (2012g), o Street View do Google proporciona
visualizações panorâmicas de 360 graus de ruas designadas em toda sua área de cobertura. A
cobertura da Street View API é a mesma do aplicativo Google Maps.
A Google Maps JavaScript API agora fornece o serviço Street View para obtenção e
manipulação de imagens usadas no recurso Street View do Google Maps. Na Google Maps
JavaScript API V3 é suportado de modo nativo dentro do navegador.
2.4 ENTITY FRAMEWORK
Conforme Macoratti 2011, o Entity Framework 4 é o framework ORM (Mapeamento
objeto-relacional) da Microsoft que transforma objetos de negócio em dados relacionais e
vice-versa. O foco do Entity Framework não é o banco de dados, mas o modelo de negócios e
desta forma uma de suas tarefas é gerar o modelo conceitual a partir do modelo do banco de
dados, sendo que desta atividade o desenvolvedor não tem que trabalhar diretamente com o
banco de dados mas com o modelo conceitual e o modelo de entidades.
Conforme Macoratti 2009 o Entity Framework – EF, é um conjunto de tecnologias
ADO.NET que suporta o desenvolvimento a aplicações orientados a dados.
O Entity Framework – EF permite trabalhar com dados na forma de propriedades e
objetos específicos do domínio, sem ter que relacioná-los com as tabelas no banco de dados e
as colunas onde os dados estão armazenados. Isto é viável pela elevação do nível de abstração
na qual se pode trabalhar quando se tratam de dados e pela redução do código que é
necessário para manter as aplicações orientadas a dados. Ou seja, conforme Microsoft 2012b,
o Entity Framework permite desenvolver com dados relacionais como objetos específicos do
domínio, eliminando a maior parte do código de ligação e acesso a dados.
Conforme Macoratti 2009, o Entity Framework renova o modelo conceitual permitindo
que sejam acessados entidades e relacionamentos neste modelo contando com o suporte da
Entity Framework para traduzir estas operações para comandos específicos da fonte de dados
consultem liberando as aplicações das dependências de código específicas de uma fonte de
dados particular.
40
Um padrão comumente usado para modelagem de dados divide o modelo de dados em
3 partes:
a) o Modelo Conceitual: define as entidades e relacionamentos do sistema modelado;
b) o Modelo Lógico: Normaliza as entidades relacionamentos entre as tabelas com
chaves primárias e constraints para os bancos de dados relacionais;
c) o modelo Físico: Análise e aplicação das capacidades de um sistema de
armazenamento específico definindo detalhes de armazenamento como
particionamento e indexação.
O modelo conceitual, o modelo de armazenamento e o mapeamento entre os dois são
expressos em uma especificação externa chamada de EDM (Entity Data Model).
O Entity Data Model é um modelo de dados Entidade-Relacionamento cujo conceito
central são as entidades e os relacionamentos, onde Entidades são instâncias de Tipos de
entidades as quais são estruturas de registros com uma chave. Uma Chave de Entidade é
formada a partir de um subconjunto de propriedades do Tipo da entidade. A chave é um
conceito fundamental para identificar de forma única, atualizar instâncias e permitir que as
instâncias de entidades participem nos relacionamentos.
Além do Entity Data Model, o Entity Framework inclui serviços que incrementam o
modelo incluindo o provedor gerenciado EntityClient, ObjectServices e LINQ to Entities.
Object Services é um componente do Entity Framework que permite que se realizem
consultas, inclusões, atualizações e exclusões de dados.
O Object Services também materializam os dados retornados como objetos e propagam
as alterações dos objetos de volta a fonte de dados, além de fornecer facilidades para tratar
alterações, vinculação de controles a objetos e efetuar o tratamento da concorrência. Um
Entity Data Model – EDM.
O Entity Framework utiliza modelos baseados em XML e arquivos de mapeamento
para transformar operações de criar, ler, atualizar, e deletar contra entidades e
relacionamentos no modelo conceitual para operações equivalentes na fonte de dados.
O Entity Framework está fundamentado na capacidade de permitir que aplicações
acessem e alterem dados que estão representados como entidades e relacionamentos no
modelo conceitual. O Entity Data Model é então usado para traduzir consultas de objetos
contra tipos de entidades que são representados no modelo conceitual em consultas
específicas da fonte de dados. O EF fornece as algumas formas de consultar um EDM e
retornar objetos, LINQ, Entity SQL e Métodos Query Builder, que são detalhados nas
próximas seções.
41
O Entity Framework também inclui um provedor de dados EntityClient que gerencia
conexões, traduz consultas de entidades em consultas específicas da fonte de dados e retorna
um leitor de dados que os Serviços de Objeto usam para materializar os dados de entidades
em objetos. Quando a materialização em objetos não é necessária o provedor EntityClient
também pode ser usado como um provedor de dados ADO .NET padrão permitindo que
aplicações executem consultas Entity SQL e consumam os dados retornados como um leitor
somente-leitura.
A Entity SQL é uma variação da SQL e foi criada com objetivo de escrever consultas
declarativas e atualizações sobre entidades e relacionamentos de entidades no nível
conceitual.
A partir do Entity Framework pode-se fazer mapeamento para bases de dados como
SQLServer, Oracle, DB2, MySql, PostgreSQL, SQLite, VistaDB, Informix, Sybase, entre
outros, bem como para outras fontes como XML, texto e outros serviços.
2.4.1 LINQ
De acordo com Macoratti (2009), LINQ to Entities, fornece suporte as consultas LINQ
para consultar tipos de entidades que são definidos no modelo.
Conforme Wikipédia 2012c, LINQ (Language Integrated Query ou Linguagem
Integrada de Consulta), define um conjunto de nomes de métodos, chamados operadores de
consulta padrão, ou operadores de sequência padrão, juntamente com regras de tradução de
expressões ditas consulta a expressões usando estes nomes de métodos, expressões lambda e
tipos anônimos. Estes podem, por exemplo, ser usados para projeto e filtrar dados em
matrizes, enumeráveis e XML (LINQ to XML), bancos de dados relacionais e fontes de dados
de terceiros.
Ainda, conforme Microsoft 2012c, uma query (consulta) é uma expressão que recupera
dados de uma fonte de dados. As consultas normalmente são expressas em uma linguagem
especializada de consulta. Diferentes linguagens foram desenvolvidas ao longo do tempo para
os diversos tipos de fontes de dados, como por exemplo, SQL para bancos de dados
relacionais e XQuery para XML. Portanto, sempre havia a necessidade de aprender uma nova
linguagem de consulta para cada tipo de fonte de dados ou formato de dados que eles devem
oferecer suporte. LINQ simplifica esta situação, oferecendo um modelo consistente para
42
trabalhar com dados em vários tipos de fontes de dados e formatos. Em uma consulta LINQ,
sempre está se trabalhando com objetos. Usa-se a mesma codificação de padrões básicos para
a query e transformar dados em documentos XML, bases de dados SQL, ADO.NET Datasets,
coleções .NET, e qualquer outro formato para o qual um provedor LINQ esteja disponível.
2.4.2 Entity SQL
Para Macoratti 2009, o Entity SQL, é um dialeto SQL independente que trabalha
diretamente com as entidades no modelo conceitual que suporta as características EDM como
herança e relacionamento.
Conforme Wikipédia 2012d, DO.NET Entity Framework utiliza uma variante da
linguagem de consulta estruturada, chamado Entity SQL, que se destina a escrever consultas
declarativas e atualizações sobre entidades e relacionamentos entidade - no nível conceitual
de tipos que são definidos em um EDM.
De acordo com Macoratti (2009), métodos Query Builder, permitem a construção de
consultas Entity SQL usando o estilo de métodos de consulta LINQ.
2.5 TRABALHOS CORRELATOS
Alguns trabalhos acadêmicos foram desenvolvidos com o objeto de pesquisa similar
ao trabalho apresentado, bem como algumas ferramentas disponíveis no mercado também
possuem funcionalidades similares. Entre estes trabalhos e ferramentas, citam-se TMB Virtual
(TMB, 2011), TransporLis (TRANSPORLIS, 2009) e SPTrans (SPTRANS, 2011).
2.5.1 TMB Virtual
Em Barcelona, um serviço implementado pela empresa de Transportes Metropolitanos
de Barcelona oferece aos turistas e habitantes da cidade o TMB Virtual. Representada na
Figura 10, a ferramenta para Android que permite que o usuário obtenha informações em
tempo real sobre o transporte público. Além de informações de como chegar a um
43
determinado destino, o programa ainda informa quais as linhas operam o trajeto, quanto leva
aproximadamente o percurso e qual o horário que o ônibus ou do metrô passa em cada ponto.
Com a câmera do smartphone o programa identifica onde a pessoa está e relaciona os dados
do transporte público disponível nas proximidades da localização identificada. A ferramenta
faz uso de geolocalização (TMB, 2011).
Fonte: TMB VIRTUAL (2011). Figura 10 – TMB Virtual
2.5.2 TransporLis
Em Lisboa, existe um serviço disponibilizado na web que permite a consulta do
percurso, os valores tarifários e os horários dos serviços de transporte público disponíveis. É o
TransporLis, um sistema de informação multimodal da área Metropolitana de Lisboa,
desenvolvido em parceria pela ANA, Carris, CP, Câmara do Barreiro, Câmara de Loures,
Câmara de Odivelas, Fertagus, Metropolitano de Lisboa, PT Comunicações, Rodoviária de
Lisboa, Scotturb, Transportes Sul do Tejo, Transtejo e Vimeca. A plataforma de mapas e a
informação cartográfica são fornecidas pelo SAPO. Os dados disponibilizados são fornecidos
44
pelas operadoras de transportes coletivos.
A opção de pesquisa pode ser informada escolhendo o ponto de partida e ponto de
chegada diretamente no mapa ou com digitação do ponto de partida e ponto de chegada,
conforme Figura 11. Onde caso na digitação a informação possa ser referência para mais de
um lugar, é listado uma lista de opções para ser selecionado o real ponto de interesse.
Fonte: TRANSPORLIS (2009).
Figura 11 – TRANSPORLIS - Consulta
Posteriormente a indicação de origem e destino para consulta, é exibido um mapa, com
o trajeto do ponto de origem ao de destino. Na lateral é informada textualmente uma lista com
horários de saídas, tempos de espera, e indicações sobre linhas, valores monetários dos
bilhetes de passagem, e etapas da viagem, representado na Figura 12.
45
Fonte: TRANSPORLIS (2009).
Figura 12 – TRANSPORLIS – Resultado da consulta
2.5.3 SPTRANS
Em São Paulo, é disponibilizado um completo serviço informações sobre transporte
coletivo urbano.
Conforme Figura 13, é possível fazer consultas por trajeto, linha de ônibus ou local de
referência, é possível incluir na pesquisa outros modais de transporte público urbano, como
metrô e trem. O resultado indica o percurso que deve ser feito, até o ponto mais próximo,
detalhes e horários da linha, valor total da tarifa, e a opção de fazer o percurso de volta. A
visualização no mapa é feita usando o Google Maps.
46
Fonte: SPTRANS, (2011).
Figura 13 – SPTRANS – Consulta e Resultado O Quadro14 apresenta um comparativo entre as funcionalidades e características
apresentadas pelas três aplicações:
TMB Virtual TRANSLIS SPTRANS
Localização por endereço (digitação do
endereço)
Sim Sim Sim
Localização por visualização no mapa
(clicando no mapa para selecionar o
endereço)
Não informado Sim Não
Mostra os horários que as linhas atendem Sim Sim Sim
Mostra a descrição das linhas que
operam
Sim Sim Sim
Mostra o tempo de percurso entre os
pontos de origem e
Sim Sim Sim
Mostra o custo/valor monetário do
percurso
Não informado Sim Sim
Disponibilização visualização do
itinerário em mapa
Não informado Sim Sim
Permite geolocalização para identificar o Sim Não Não
47
endereço de origem
Descrição do percurso, com
disponibilização de nomes de ruas,
trajetos feitos a pé, etc...
Sim Sim Sim
Disponibiliza consulta que atende sistema
multimodal (com intersecções, ônibus,
trens e metrôs)
Sim Sim Sim
Figura 14 – Tabela comparativa entre os trabalhos correlatos
48
3 DESENVOLVIMENTO DA APLICAÇÃO
Este capítulo demonstra o desenvolvimento da aplicação. São apresentados os
principais requisitos, especificação, implementação da aplicação, e ao final são listados os
resultados.
3.1 REQUISITOS PRINCIPAIS DO PROBLEMA A SER TRABALHADO
Foi desenvolvido um protótipo de uma aplicação web para consulta dos horários de
ônibus, itinerários e visualização do mapa no Google Maps através do uso de API. O Google
Maps disponibiliza um web mapping do tipo dinâmico, onde pode-se criar o mapa, incluir
marcadores, caminhos, sobreposições, além de navegações, alterações de zoom e relevo. As
regras de negócio e administração da aplicação foram feitas em ASP NET, linguagem C#,
usando o modelo conceitual. Assim, a construção é a partir dos seguintes requisitos:
a) permitir ao usuário administrador informar ruas (RF01);
b) permitir ao usuário administrador informar locais de saída – pontos iniciais (RF02);
c) permitir ao usuário administrador informar locais de chegada – pontos finais
(RF03);
d) permitir ao usuário administrador informar localizações adjacentes (RF04);
e) permitir ao usuário administrador informar pontos de paradas (RF05);
f) permitir ao usuário administrador informar linhas de ônibus (RF06);
g) permitir ao usuário administrador informar horários de saída (RF07);
h) permitir ao usuário administrador informar localizações adjacentes aos pontos de
paradas (RF08);
i) permitir ao usuário web consultar horários (RF09);
j) permitir ao usuário web consultar itinerários (RF10);
k) permitir ao usuário visualizar mapa com marcações (RF11);
l) o protótipo da aplicação (regras de negócio) deve ser desenvolvido em C#
(RNF01);
m) a persistência será feita com banco de dados SQL Server Express 2008 R2 Edition
Free (RNF02);
49
n) o protótipo da aplicação (consultas) deve estar disponibilizado para web (RNF03);
o) o protótipo da aplicação deve consumir a API do Google Maps (RNF04).
3.2 ESPECIFICAÇÃO
A especificação foi realizada a partir da ferramenta Enterprise Architect, utilizando a
linguagem de modelagem Unified Modeling Language (UML). Para modelagem foram
utilizados os diagramas de casos de uso, de classes e modelo entidade e relacionamento.
3.2.1 Diagrama de Casos de Uso
Os diagramas de caso de uso estão divididos em: administração e consulta web. Os
casos de uso são apresentados através de diagrama de casos de uso, seguidos da descrição do
cenário de cada caso de uso.
3.2.2 Casos de Uso
Como este trabalho permite consultas públicas de informações relacionadas ao
transporte coletivo urbano, é necessário que o administrador destas informações seja
considerado como o Usuário. Na Figura 15 são demonstradas as ações realizadas pelo
Usuário, que tem a função de administrar as regras e informações relacionadas com os
itinerários, horários, pontos de paradas e linhas de ônibus.
50
Figura 15 – Diagrama de casos de uso do cadastro da aplicação
A seguir serão detalhados os principais casos de uso que correspondem à aplicação que
permite a administração da aplicação.
3.2.2.1 Cadastrar localizações adjacentes
Caso de uso Cadastrar localizações adjacentes, permite que sejam cadastradas
localizações (ruas) adjacentes aos pontos de ônibus. O propósito de uma localização adjacente
é permitir que ruas que não tenham itinerários de linhas de ônibus, possam ser associadas a os
pontos de ônibus nas proximidades, e assim estas localizações adjacentes possam ser
consideradas nas consultas. Mais detalhes descritos no Quadro 16.
Cadastrar localizações adjacentes
Descrição Permite cadastrar localizações adjacentes aos pontos de
ônibus
Caso de Uso UC – 04
51
Pré-condições Ruas previamente cadastradas na aplicação
Pontos previamente cadastrados na aplicação
Cenário principal 01) Administrador acessa o recurso através do menu
02) Sistema apresenta funcionalidade sem informações
novas na área de inclusão e uma grid com os dados já
existentes na base.
03) Administrador por optar por inserir novo. Alterar ou
excluir algum registro existem no grid.
Fluxo alternativo No passo 3, caso o administrador opte por inserir novo:
03.01)Sistema apresenta formulário
03.02) Administrador preenche os dados Id, Descrição,
03.03) Administrador seleciona o ponto que vai informar
uma adjacência
03.04) Administrador seleciona a rua que é adjacente
03.05) Administrador Insere o registro
Exceção No passo 03, caso ocorra alguma inconsistência na
validação como campo obrigatório, ou dados informados
incorretamente o sistema apresenta mensagem referente
ao problema encontrado.
Pós-condições No passo 03, caso o operador opte por inserir, deverá ser
criado um novo registro.
Quadro 16 – Detalhamento do Cadastro das localizações adjacentes
3.2.2.2 Cadastrar pontos de paradas
Caso de uso Cadastrar pontos de paradas, permite que sejam cadastrados os pontos de
paradas, que posteriormente serão utilizados para compor o itinerário das linhas de ônibus.
Mais detalhes descritos no Quadro 17.
Cadastrar pontos de paradas
Descrição Permite cadastrar pontos de paradas
Caso de Uso UC – 05
Pré-condições Ruas previamente cadastradas na aplicação
Pontos previamente cadastrados na aplicação
Cenário principal 01) Administrador acessa o recurso através do menu
02) Sistema apresenta funcionalidade sem informações
novas na área de inclusão e uma grid com os dados já
existentes na base.
03) Administrador por optar por inserir novo. Alterar ou
excluir algum registro existem no grid.
Fluxo alternativo No passo 3, caso o administrador opte por inserir novo:
03.01)Sistema apresenta formulário
03.02) Administrador preenche os dados Id, Número
Localização, Descrição
03.03) Administrador seleciona a rua que é adjacente
03.04) Administrador Insere o registro
52
Exceção No passo 03, caso ocorra alguma inconsistência na
validação como campo obrigatório, ou dados informados
incorretamente o sistema apresenta mensagem referente
ao problema encontrado.
Pós-condições No passo 03, caso o operador opte por inserir, deverá ser
criado um novo registro.
Quadro 17 – Detalhamento do Cadastro os pontos de parada
3.2.2.3 Cadastrar linhas
Caso de uso Cadastrar linhas, permite que sejam cadastrados linhas de ônibus, com
seus respectivos itinerários (composição de pontos atendidos para cada linha de ônibus),
locais de saída e chegada. Mais detalhes descritos no Quadro 18.
Cadastrar linhas
Descrição Permite cadastrar as linhas de ônibus, locais de saída,
locais de chegada e pontos que compõem a linha
Caso de Uso UC – 06
Pré-condições Locais de saída (terminador) previamente cadastrados na
aplicação
Locais de chegada (terminador) previamente cadastrados
na aplicação
Cenário principal 01) Administrador acessa o recurso através do menu
02) Sistema apresenta funcionalidade sem informações
novas na área de inclusão e uma grid com os dados já
existentes na base.
03) Administrador por optar por inserir novo. Alterar ou
excluir algum registro existem no grid.
Fluxo alternativo No passo 3, caso o administrador opte por inserir novo:
03.01)Sistema apresenta formulário
03.02) Administrador preenche os dados Id, Número
Linha, Descrição
03.03) Administrador seleciona Local de Saída
03.04) Administrador seleciona Local de Chegada
03.04) Administrador Insere o registro
Exceção No passo 03, caso ocorra alguma inconsistência na
validação como campo obrigatório, ou dados informados
incorretamente o sistema apresenta mensagem referente
ao problema encontrado.
Pós-condições No passo 03, caso o operador opte por inserir, deverá ser
criado um novo registro.
Quadro 18 – Detalhamento do Cadastro das linhas
53
Na Figura 19 podem-se observar as ações realizadas pelo usuário que efetuará
consultas na aplicação web.
Figura 19 – Diagrama de casos de uso da consulta
No Quadro 20, são representados os casos de uso UC – 10 Consultar itinerários,
onde qualquer usuário do transporte coletivo urbano poderá consultar o atendimento de linhas,
horários, e quais os itinerários dessas linhas.
Consulta pela web
Descrição Consulta pela web – permite ao usuário consultar
horários, itinerários e linhas.
Caso de Uso UC – 10
Pré-condições Acessar o sistema pela web
Cenário principal 01) Usuário acessa página através de um navegador.
02) Usuário informa ponto de origem e ponto de destino
03) Sistema busca as linhas de ônibus que passam pelos
pontos informados e atualiza o mapa.
Fluxo alternativo 01 No passo 3, caso não existam linhas de ônibus passando
por nenhum dos pontos informados:
03.01) Sistema informa que não há linhas atendendo aos
pontos de origem e destino selecionados e sugere nova
consulta.
Pós-condições 01 No passo 03, caso exista uma linha de ônibus cujo
itinerário atenda os dois pontos (de origem e de destino):
03.01) Sistema disponibiliza visualização do mapa
colorindo as ruas com os itinerários das linhas, marca os
pontos de parada entre o segmento informado, listas os
próximos horários disponíveis e lista os endereços com os
pontos de paradas.
Figura 20 – Detalhamento da consulta web
54
3.2.3 Diagrama de Classes
O diagrama de classes representado na Figura 21 exibe as principais classes da
aplicação com seus devidos atributos. Algumas classes e métodos foram abstraídos para uma
melhor visualização do diagrama, não comprometendo o entendimento do mesmo.
Figura 21 – Diagrama de Classes
55
Na classe Rua estão os métodos relacionados com a entidade Rua, como os métodos
que permitem associar as referências ou adjacências aos pontos:
vincularReferenciaAdjacente() e vincularRuaAdjacente().
Na classe Ponto, estão os métodos relacionados com a entidade Ponto como os
métodos que permitem consultar as linhas de transporte que estão relacionadas com o ponto
consultarLinhas().
Na Classe Terminal, estão os métodos relacionados com a entidade Terminal, os
métodos que permitem consultar as linhas de saída e as linhas de entrada, utilizadas na busca
de linhas que os pontos que não estão diretamente no mesmo itinerário:
consultarLinhasEntrada() e consultarLinhasSaida(). Quando os dois pontos não estão
na mesma linha, mas a viagem pode ser contemplada por uma interseção em um terminador, a
localização deste terminador, e a composição do array é feita nesta classe.
Já na classe Linha, a principal da aplicação, estão os métodos relacionados com a
entidade linha, métodos de consultar pontos consultarPontos(), consultar horários
consultarHorarios(), carregar a ordem da linha carregaOrdemLinha()onde tem-se o
array de pontos e consultar os itinerários consultarItinerarios()onde tem-se o array
de ruas.
Na classe Adjacencia, estão os métodos relacionados com a entidade
Referência/adjacênciar. Um método desta classe é o consultarAdjacencia() que permite
localizar as adjacências dos pontos. Uma adjacência consiste em uma rua próxima à uma rua
que tem pontos de ônibus, mas a adjacência não é uma rua atendida por linhas de ônibus. Esta
adjacência, é associada à um ponto. Quando na consulta uma adjacência for informada, a
aplicação procura por pontos, quando estes não são atendidos procura por adjacências. Os
métodos desta procura de adjacências estão nesta classe
Na classe Horário, estão os métodos relacionados com horários, consultarHorario().
3.2.4 Modelo Entidade Relacionamento
Na Figura 22 é representado o Modelo Entidade Relacionamento, com a estrutura das
tabelas do banco de dados que mantem os dados da aplicação, tais como: ruas, pontos,
terminais, linhas e horários.
56
Figura 22 – Diagrama modelo entidade-relacionamento
3.3 IMPLEMENTAÇÃO
A seguir são descritas as técnicas e ferramentas utilizadas na implementação, bem
como detalhes das rotinhas implementadas durante o desenvolvimento da aplicação.
57
3.3.1 Técnicas e ferramentas utilizadas
O desenvolvimento da aplicação foi executado utilizando ASP NET, linguagem de
programação C#, em conjunto com o .Net Framework 4, JavaScript, HTML e Google Maps
Java Script API V3. Quanto ao ambiente de desenvolvimento, foi escolhido o Visual Studio
2010.
Para persistência dos dados foi utilizado o Entity Framework que a partir de uma base
de dados relacionais (descrito na seção 3.2.5) cria um conjunto de classes, gerando um
modelo conceitual sobre o modelo relacional existente na base de dados. A base de dados da
aplicação foi construída em SQL Server Express 2008 R2 (Edition Free).
Na tela de consulta, os pontos de origem e destino, podem ser informados como
endereços em campos específicos ou pelo ‘clique’ no mapa. Este mapa é criado com a Google
Maps Java Script API V3, onde conforme seção 2.3.3.1.1, é feita a chamada da API (com seus
métodos, através do endereço http://maps.google.com/maps/api/js?sensor=false e
sem chave de ativação), representada no quadro 23.
<title>Itinerários de ônibus entre dois pontos clicados no mapa ou entre
dois endereços informados</title>
<script type="text/javascript"
src="http://maps.google.com/maps/api/js?sensor=false"></script>
<script type="text/javascript">
Quadro 23 – Aplicação – chamada API Google Maps
No Quadro 24, estão declarações de variáveis e a função de inicialização do mapa
Inicialize(), onde conforme a seção 2.3.3.1.1 centraliza-se o mapa (CentroMapa) através
das coordenadas geográficas (latitude e longitude), indicando o endereço da Universidade
Regional de Blumenau – FURB, Rua Antônio da Veiga, nº 140 – Itoupava Seca, Blumenau –
SC. E conforme seções e seção 2.3.3.1.4 e 2.3.3.1.5, também são criadas várias de marcação
do mapa (marker0 e marker1), variáveis para receber a informação de endereço desses
marcadores (Coord1 e Coord2), bem como variáveis para receber infowindow do
google.maps.InfoWindow() e directionsService
google.maps.DirectionsService(). Além da criação de arrays que são alimentados com
as informações que vem das funções com dados que estão na base de dados (feitas em C#) e
que são manipulados na página, para criar as linhas de rota e marcadores de pontos de parada.
58
var geocoder;
var map;
var time = 0;
var CentroMapa = new google.maps.LatLng(-26.907549, -49.079821);
var directionsService = new google.maps.DirectionsService();
var infowindow = new google.maps.InfoWindow();
var marker0;
var marker1;
var Coord1 = string;
var Coord2 = string;
var novoArrayPontos = [];
var markersArray = [];
function initialize() {
geocoder = new google.maps.Geocoder();
directionsDisplay = new google.maps.DirectionsRenderer();
var myOptions = {
zoom: 15,
center: CentroMapa,
mapTypeId: google.maps.MapTypeId.ROADMAP
};
map = new
google.maps.Map(document.getElementById("map_canvas"), myOptions);
google.maps.event.addListener(map, "click", function (pt) {
createMarker(pt);
});
directionsDisplay.setMap(map);
directionsDisplay.setPanel(document.getElementById("directionsPanel"));
}
Quadro 24 – Aplicação – função de inicialização
A função CreateMarker(), representada no Quadro 25 cria os marcadores de origem
e destino no mapa. Isso é possível através dos Eventos de Usuário, descritos na seção
2.3.3.1.2. (Objetos de Eventos de Mapa), onde os cliques do mouse, são adicionados em
google.maps.event.addListener e no google.maps.Marker é possível receber as
coordenadas geográficas do mapa (latitude e longitude). Também, com o
google.maps.MarkerImage cria-se um marcador personalizado.
59
function createMarker(pt) {
var image2 = new google.maps.MarkerImage('imagens/bus2.png',
new google.maps.Size(32, 32),
new google.maps.Point(0, 0),
new google.maps.Point(0, 32));
if (marker0 != null && marker1 != null) {
nullMap();
}
eval(" infowindow" + time + " = new google.maps.InfoWindow({
content: pt.latLng.toString() });");
eval(" marker" + time + " = new google.maps.Marker({ position:
pt.latLng, map: map, icon: image2 });");
eval(" google.maps.event.addListener(marker" + time + ",
\"click\", function() { infowindow" + time +
".open(map, marker" + time + "); });");
time++;
if (time == 1) {
Coord1 = marker0.getPosition();
FindAdress(Coord1, 1);
}
if (time == 2) {
start = marker0.getPosition();
end = marker1.getPosition();
Coord2 = marker1.getPosition();
FindAdress(Coord2, 2);
time = 0;
}
}
Quadro 25 – Aplicação – função de marcação no mapa
Como a aplicação deverá apresentar resultados válidos para o usuário que faz as
consultas, essas coordenadas devem ser convertidas em endereço, em uma geocodificação
reversa, que é feita na função FindAdress(), representada no Quadro 26 e descrita na seção
2.3.3.1.5.2.
Optou-se por utilizar o primeiro resultado (results[0].formatted_address) pois
conforme descrito na seção 2.3.3.1.5.2, os resultados são mostrados do melhor para o pior,
assim este será o melhor resultado de endereço. Além de utilizar o formatted_address,
pois o objetivo de resultado é um endereço legível.
60
function FindAdress(CoordX, tipo) {
geocoder.geocode({ 'latLng': CoordX }, function (results,
status) {
if (status == google.maps.GeocoderStatus.OK) {
if (tipo == 1) {
document.getElementById("HiddenFieldOrigem").value
= results[0].formatted_address;
} else {
document.getElementById("HiddenFieldDestino").value =
results[0].formatted_address;
}
if (results[1]) {
infowindow.setContent(results[0].formatted_address);
infowindow.open(map, marker);
}
} else {
alert("Geocoder failed due to: " + status);
}
});
}
Quadro 26 – Aplicação – função para geocodificação reversa
Para a consulta, caso o usuário opte por selecionar os pontos de origem e destino no
mapa, a aplicação captura a coordenada geográfica destes dois pontos, e envia estas
coordenadas para a API do Google Maps, para buscar o endereço legível e enviar para os
métodos feitos em C#. Em C#, usando LINQ estes endereços são localizados na base de
dados.
Após, são verificados a existência de pontos de parada de ônibus cadastradas na base,
ou algum ponto adjacente, bem como são criados os arrays de endereços de ruas que
compõem o segmento informado da linha, o array de pontos de paradas e os horários de saída
dos ônibus da linha localizada. Com estes arrays, o mapa é renderizado novamente, com as
informações de endereço localizadas na base de dados da aplicação.
Desenvolvido em C#, na classe Ponto.cs, o método consultarPonto, permite a
localização do Ponto, e está representa na Figura 27, onde é verificado se há na base de dados
algum ponto cadastrado no endereço informando. Nesta função não são verificadas
adjacências.
61
public static Ponto consultarPonto(string nomeRua, int numLocalizacao,
TccEntities entidades)
{
var pontos = from ponto in entidades.Pontos
where ponto.Rua.Nome.Contains(nomeRua)
&& ponto.NumeroLocalizacao == numLocalizacao
select ponto;
if (pontos.ToString() == "")
{
return null;
}
if (pontos.Count() == 0)
return null;
return pontos.ToArray()[0];
}
Quadro 27 – Aplicação – consultar Pontos
Na classe Linha.cs, o método que verifica quais linhas atendem os dois pontos
informados é linhasQueAtendemOsPontos, representada na Figura 28.
public static List<Linha> linhasQueAtendemOsPontosLista(Ponto
pontoInicial, Ponto pontoFinal, TccEntities entidades)
{
return (from linha in entidades.Linhas
where
(from linhaPonto in entidades.LinhaPontos where
linhaPonto.Ponto.Id == pontoInicial.Id select
linhaPonto.Linha).Contains(linha)
&&
(from linhaPonto in entidades.LinhaPontos where
linhaPonto.Ponto.Id == pontoFinal.Id select
linhaPonto.Linha).Contains(linha)
select linha).ToList();
}
Quadro 28 – Aplicação – obter de linhas que atendem os pontos
Também nesta classe, está o método que verifica a ordem do ponto na linha localizada,
localizarOrdem, representada na Figura 29.
62
public static LinhaPonto localizarOrdem(int pontoOrdem, int
linhaLocalizada, TccEntities entidades)
{
var linhasponto = from linhaponto in entidades.LinhaPontos
where linhaponto.Ponto.Id.Equals(pontoOrdem)
&&
linhaponto.Linha.Id.Equals(linhaLocalizada)
select linhaponto;
if (linhasponto.Count() == 0)
return null;
return linhasponto.ToArray()[0];
}
Quadro 29 – Aplicação – obter ordem
Na Figura 30, está representado o método que carrega a ordem de ruas da linha
localizada e que atende o segmento informado pelos endereços de origem e destino.
public static List<LinhaPonto> carregarOrdemRuas(int pontoOrdemI, int
pontoOrdemF, int linhaLocalizada, TccEntities entidades)
{
var linhasOrdemRuas = from linhaponto in entidades.LinhaPontos
where linhaponto.Ordem >= pontoOrdemI
&& linhaponto.Ordem <= pontoOrdemF
&&
linhaponto.Linha.Id.Equals(linhaLocalizada)
select linhaponto;
if (linhasOrdemRuas.Count() == 0)
return null;
return linhasOrdemRuas.ToList();
}
Quadro 30 – Aplicação – obter ruas
A função AbrirConsulta() cria o novo mapa com os dados localizados na base de
dados está representada na Figura 31.
function AbrirConsulta() {
var image = new
google.maps.MarkerImage('imagens/Stop_sign.png',
new google.maps.Size(32, 32),
new google.maps.Point(0, 0),
new google.maps.Point(0, 32));
var image2 = new google.maps.MarkerImage('imagens/bus2.png',
new google.maps.Size(32, 32),
new google.maps.Point(0, 0),
new google.maps.Point(0, 32));
geocoder = new google.maps.Geocoder();
var listaRuas = '<%= Session["ListaCompletadeRuas"].ToString()
%>';
var listaPontos = '<%=
63
Session["ListaCompletadePontos"].ToString() %>';
var adjacenciaOrigem = '<%=
Session["AdjacenciaOrigem"].ToString() %>';
var adjacenciaDestino = '<%=
Session["AdjacenciaDestino"].ToString() %>';
var strlistaRuas = new String(listaRuas);
var strlistaPontos = new String(listaPontos);
strlistaRuas = listaRuas.substring(0, (listaRuas.length - 1));
strlistaPontos = listaPontos.substring(0, (listaPontos.length
- 1));
var novoArray = strlistaRuas.split('|');
var enderDe = (novoArray[0]);
var enderAte = (novoArray[novoArray.length - 1]);
novoArrayPontos = strlistaPontos.split('|');
var request = {
origin: enderDe,
destination: enderAte,
travelMode: google.maps.DirectionsTravelMode.DRIVING,
waypoints: new Array()
};
for (i = 1; i < novoArray.length - 1; i++) {
var localX= { location: novoArray[i], stopover:false };
request.waypoints.push(localX);
}
for (ii = 0; ii < novoArrayPontos.length; ii++) {
geocoder.geocode({ 'address': novoArrayPontos[ii] },
function (results, status) {
if (status == google.maps.GeocoderStatus.OK) {
map.setCenter(results[0].geometry.location);
var markerk = new google.maps.Marker({
map: map,
position: results[0].geometry.location,
icon: image2
});
} else {
alert("Sem successo: " + status);
}
});
directionsService.route(request, function (response, status) {
if (status == google.maps.DirectionsStatus.OK) {
directionsDisplay.setDirections(response);
}
});
}
Quadro 31 – Aplicação – função AbrirConsulta – resultado da consulta
Esta função, com os arrays de ruas e pontos carregados, as ruas são coloridas no mapa
e os pontos de ônibus são marcados. Com o request.waypoints.push(localX), pode-se indicar
o itinerário que se deseja, sem que o google devolva a rota otimizada e gerada
automaticamente pela API da Google Maps. Cada rua é um waypoint. Porém a versão
gratuita limita há 8 waypoints conforme descrito na seção 2.3.3.1.5.3, para serviços
64
gratuitos e 23 waypoints para Premier. Esta limitação fez com que fosse necessário dois
arrays diferentes para montar o itinerário e a marcação dos pontos no mapa.
O array de ruas retorna a sequencia de ruas da linha localizada, mas somente uma
ocorrência por rua; se existem n pontos de parada na mesma rua, neste array, existe uma
ocorrência por rua. Para que o itinerário não tenha incoerência de ruas, usa-se a numeração de
localização do primeiro ponto da rua para criar endereço do itinerário.
O array de pontos de parada, carrega todos os endereços de ponto de parada para a
linha encontrada dentro do segmento encontrado. Cada endereço é passado para a função
geocoder.geocode da API Google Maps, que devolve as coordenadas geográficas, e o mapa
recebe uma marcação personalizada.
3.3.2 Operacionalidade da implementação
A operacionalidade da aplicação é apresenta na forma de funcionalidades, sendo
representados através de imagens. Primeiramente são apresentadas algumas imagens da
aplicação com as funcionalidades de cadastro.
Conforme Figura 32, são disponibilizadas funcionalidades de cadastros de Ruas,
Pontos, Adjacências, Terminadores, Linhas, Horários e Associar Pontos.
Figura 32 – Aplicação – apresentação dos cadastros
A Figura 33 mostra a funcionalidade de cadastro de Ruas.
65
Figura 33 – Aplicação – cadastro de ruas
A Figura 34 mostra a funcionalidade de cadastro de Pontos em edição.
Figura 34 – Aplicação – alteração de pontos
A página de consulta pública de horários, conforme Figura 35, permite que seja feita
uma consulta por endereços de origem e destino informados no campo que permite que os
endereços sejam digitados ou através do mapa, clicando em dois pontos distintos.
66
Figura 35 – Consulta – apresentação
Quando é clicado um ponto no mapa, o que é feito é uma geocodificação reversa, pois
o clique no mapa, usando a API do Google Maps retorna a coordenada (latitude e longitude).
Essa coordenada é enviada para o serviço da Google, que devolve o endereço legível do local
localizado. Este endereço legível é o que é tratado para localizar os pontos nas proximidades.
Primeiro é verificado se há um ponto dentro do intervalo de numeração informado, depois é
verificado os pontos anteriores a numeração de rua localizada, ou os pontos posteriores a
numeração de rua localizada.
Conforme Figura 36 assim que selecionado um ponto no mapa uma mensagem é
exibida com o endereço exato, para verificação deste endereço. São permitidos sempre dois
cliques no mapa, sendo que o primeiro será considerado origem, e o segundo destino. Se o
usuário verificar que o clique no mapa não traz o endereço que satisfaça sua necessidade de
consulta, poderá efetuar novos cliques, sendo que o terceiro clique limpa o mapa e cria um
novo marcador inicial de consulta.
67
Figura 36 – Consulta – endereço origem
Assim que os dois pontos no mapa contiverem informações que satisfaçam a
necessidade de consulta, conforme exemplificado na Figura 37, deve-se clicar no botão
Consultar. O botão Limpar recarrega a página.
Figura 37 – Consulta – endereço destino
As funcionalidades do Google Maps, descritas na seção 2.3.3.1.4, que permitem balões
de informação, zoom e mudança do tipo do mapa podem ser visualizadas nas Figuras 38.
68
Figura 38 – Consulta – características do mapa apresentado
Na Figura 39 pode ser observado o resultado da consulta, onde é informada a linha de
ônibus localizada na base de dados e que atende os dois pontos informados. E no mapa são
pintadas as ruas que compreendem a rota da linha de ônibus localizada pela consulta, além de
serem marcadas todas as paradas de ônibus do segmento informado. Ao lado do mapa são
informados os três próximos horários e listados os endereços de cada ponto de ônibus.
Figura 39 – Consulta – resultado
69
3.4 RESULTADOS E DISCUSSÃO
O presente trabalho apresentou o desenvolvimento de uma aplicação web para
consultas de transportes coletivos urbanos. O tipo de mapa que utilizado neste trabalho é de
navegação baseada em mapas dinâmicos.
Alguns testes foram feitos na aplicação para verificação de performance. Foram
criados três cenários de linhas hipotéticas com ruas reais, onde no primeiro cenário são apenas
dois pontos de parada (Figura 40). No segundo cenário são três pontos de parada. No terceiro
cenário são apresentados cinco pontos de paradas mais uma localização adjacente.
Figura 40 – Consulta de testes com dois marcadores de pontos de parada
Neste caso, em milissegundos segue o Quadro 41 de resultados com os tempos de 10
consultas feitas em horários aleatórios.
70
Consulta Tempo Média por parada
milissegundos
01 00:00:00:16 00:00:00:08
02 00:00:00:15 00:00:00:08
03 00:00:00:15 00:00:00:08
04 00:00:00:26 00:00:00:13
05 00:00:00:23 00:00:00:12
06 00:00:00:24 00:00:00:12
07 00:00:00:16 00:00:00:08
08 00:00:00:17 00:00:00:09
09 00:00:00:10 00:00:00:05
10 00:00:00:25 00:00:00:13
Quadro 41 – Resultados de testes com doic marcadores de pontos de parada
Sendo que o maior tempo identificado, por parada nos testes é 00:00:00:13
milissegundos, e o menor como 00:00:00:05 milissegundos, criando uma média de tempo por
ponto, neste cenário de consulta de 00:00:00:09 milissegundos.
Para o cenário com três pontos de parada, conforme Figura 42, há o ponto de origem, o
ponto de destino e um ponto de parada intermediário E neste caso, segue o Quadro 43 de
resultados com os tempos de 10 consultas feitas em horários aleatórios.
Figura 42 – Consulta de testes com três marcadores de pontos de parada
71
Consulta Tempo Média por parada
milissegundos
01 00:00:00:16 00:00:00:05
02 00:00:00:23 00:00:00:08
03 00:00:00:24 00:00:00:08
04 00:00:00:23 00:00:00:07
05 00:00:00:24 00:00:00:08
06 00:00:00:16 00:00:00:05
07 00:00:00:26 00:00:00:08
08 00:00:00:26 00:00:00:08
09 00:00:00:25 00:00:00:08
10 00:00:00:16 00:00:00:05
Quadro 43 – Resultados de testes com três marcadores de pontos de parada
Neste caso, verifica-se um tempo de consulta maior (com resultados de até
00:00:00:26) , porém um tempo médio considerando as três paradas menor de 00:00:00:07
milissegundos por marcador.
No ultimo cenário, representado na Figura 44, um cenário com cinco paradas, mais
uma localização adjacente.
Figura 44 – Consulta de testes com cinco marcadores de pontos de parada e adjacente
72
Os resultados apresentados encontram-se no Quadro 45, e observa-se que este
resultado se repete, mostrando um tempo maior de consulta, porém considerando a quantidade
de paradas/ marcadores, apresenta uma média menor, de 00:00:00:05 milissegundos.
Consulta Tempo Média por parada
milissegundos
01 00:00:00:33 00:00:00:05
02 00:00:00:23 00:00:00:04
03 00:00:00:33 00:00:00:05
04 00:00:00:32 00:00:00:05
05 00:00:00:33 00:00:00:05
06 00:00:00:36 00:00:00:06
07 00:00:00:22 00:00:00:03
08 00:00:00:26 00:00:00:06
09 00:00:00:33 00:00:00:05
10 00:00:00:34 00:00:00:05
Quadro 45 – Resultado de testes com cinco marcadores de pontos de parada e adjacente
O espaço necessário para armazenamento do banco de dados foi calculado de acordo
com orientações da Microsoft 2012d, e está apresentado na Tabela 1.
Os valores considerados para quantidade de registros são hipotéticos e baseados em
alguns resultados das pesquisas e levantamentos para este trabalho. Um exemplo a citar é que
os percursos de ônibus atendem 277 ruas Seção (2.3.3), onde os cálculos foram feitos
estimando 300 ruas.
Tabela 1 – Espaço para armazenamento Variável a considerar Tabela LINHA Tabela
PONTO
Tabela
LINHAHORARIOS
Tabela
RUA
Número de linhas da tabela 100 1.000 10.000 300
Número de colunas 5 4 4 3
Total em bytes das colunas com
dados fixos (a)
16 12 16 8
Número de colunas com dados
variáveis
1 1 - -
Tamanho máximo de colunas de
comprimento variável
50 50 - 50
Null Bitmap – fórmula:
2 + (( Número de colunas + 7) /
8) (b)
2+((5+7)/8)= 3,5 3,375 3,375 3
Colunas de tamanho variável:
2 + (Número de colunas com
dados variáveis * 2) + Tamanho
máximo de colunas de
comprimento variável (c)
2 +(1*2)+50 =
54
54 0 54
Tamanho da linha: (a) + (b) +
(c) + 4
77 73 23 71
Linhas por página: 8096 /
Tamanho da linha
8.096/77 = 105 8.096/73=
110
8.096/23 =
352
8.096/71 =
114
Número de páginas 500/105=
4,76
1000/110=
9,09
10.000/352=
28,40
300/114=
2,63
Tamanho da pilha 38.993 74.465 232.652 21.544
Para estas quatro principais tabelas, considerando uma quantidade hipotética de
73
registros, a necessidade de espaço para armazenamento em bytes seria 367.654 bytes, que é
uma quantidade relativamente pequena, considerando a robustez das aplicações que utilizam
estes bancos de dados.
O cálculo foi feito considerando as quantidades de linhas da tabela, o número de
colunas com dados fixos e o número de dados variáveis. Também é incluído o null bitmap
(com fórmula fixa). As colunas com tamanhos variáveis também tem uma fórmula onde é
incluída a soma de dois, mais o número de colunas com dados variáveis, multiplicado por
dois, somado o tamanho máximo de colunas com comprimento variável. Ao final, são
incluídas nos cálculos a quantidade de linhas por página dividida pelo tamanho da linha. Para
o número de páginas, são as quantidades de registros por tabela, dividido pelo resultado da
quantidade de linhas por página.
Ainda, comparando a aplicação deste trabalho com as ferramentas disponibilizadas no
mercado, e descritas na seção 2.5, obtém-se a tabela comparativa representada no Quadro 46.
Este trabalho TMB Virtual TRANSLIS SPTRANS
Localização por
endereço
Sim Sim Sim Sim
Localização por
visualização no mapa
Sim Não informado Sim Não
Horários que
atendem
Sim Sim Sim Sim
Linhas que operam Sim Sim Sim Sim
Tempo de Percurso Não Sim Sim Sim
Valor monetário do
percurso
Não Não informado Sim Sim
Visualização do
itinerário em mapa
Sim Não informado Sim Sim
Geolocalização Não Sim Não Não
Descrição do
percurso
Sim Sim Sim Sim
Multimodal Não Sim Sim Sim
Quadro 46 – Tabela comparativa deste trabalho e aplicações disponíveis no mercado
Em relação às dificuldades encontradas durante o desenvolvimento do trabalho,
tratando-se da API do Google Maps, encontra-se a limitação da API da Google Maps para
apenas oito pontos de caminho (mais origem e destino), e a estrutura das funções de desenho
das polilinhas serem possíveis apenas por coordenadas geográficas.
Para solucionar esse problema optou-se por criar dois arrays de resultados. Onde, para
montar o percurso é utilizado um array apenas com os endereços sem repetição de ruas. E
para compor este endereço, utiliza-se o número de localização na rua do ponto, do primeiro
ponto identificado na rua. Por exemplo, caso uma rua tenha um ponto localizado na
numeração cem, outro ponto na numeração quinhentos e sessenta, e ainda outro ponto na
numeração mil, para o itinerário será enviado para a API do Google neste caso apenas a rua
74
com a numeração cem, os demais serão desconsiderados.
Para a marcação dos pontos, como não há limitação de marcadores, assim utiliza-se
outro array, com todos os pontos de parada do itinerário dentro do intervalo informado como
ponto inicial e ponto final.
Estas regras apenas não se aplicam para situações em que existem intersecções de
linhas, ou seja, quando uma única linha de ônibus não contempla os dois endereços indicados
diretamente, e duas linhas são necessárias para compor este itinerário. Nesta situação, e diante
da limitação de waypoints, não seria viável montar duas listas de itinerários, pois a
quantidade de ruas seria maior que oito waypoints.
Esta limitação ocorre no trabalho porque utilizou-se a versão gratuita. A versão paga,
com 23 waypoints, contempla um número maior de ‘pontos de caminhos’.
Durante o desenvolvimento, verificou-se a possibilidade de persistir todos os pontos de
parada com coordenadas geográficas utilizando campos do tipo geography. Estes campos
permitem um tipo de consulta própria, de localização por coordenada geográfica mais
próxima. A versão mais atual do Entity Framework 4.2 permite o uso destes campos no
modelo conceitual, e esta versão de Framework é compatível o ambiente Visual Studio 2010.
Porém o Visual Studio 2010 não dá o suporte a estes campos; apenas a versão Visual Studio
2012 que permite o suporte a estes campos usando o modelo conceitual.
Com relação ao LINQ, utilizado nas classes de consulta, em alguns métodos (equals,
contains), a consulta não trazia o resultado esperado, sendo necessário usar os operadores
de comparação do próprio C#. Esta situação foi verificada para campos do tipo int.
75
4 CONCLUSÕES
Este trabalho apresentou a especificação e implementação de uma aplicação para
consultas de horários de ônibus e itinerários das linhas com visualização em mapa dinâmico.
Desenvolveu-se uma solução genérica, que permite configurar ruas, pontos de parada,
terminadores e linhas de ônibus de qualquer cidade, disponibilizando os horários e itinerários
para consulta.
Desde o princípio o objetivo era estudar, implementar e testar uma aplicação com a
API do Google Maps. Objetivava-se verificar as funcionalidades, facilidades, dificuldades e
limitações da tecnologia. A API que é gratuita (com exceção em algumas situações), mostrou-
se robusta, a documentação complementa e bem didática. As funções disponibilizadas, apesar
de algumas restrições na versão gratuita, foram suficientes para contemplar as necessidades
do trabalho. Uma dúvida era o comportamento e funcionalidade usando ASP NET, C#, mas a
aplicação mostrou-se viável e não apresentou incompatibilidades ou problemas maiores.
Justamente por usar páginas HTML e JavaScript para a interface, que é comumente usado em
aplicações web e sites. As regras do sistema desenvolvidas em ASP NET, C# permitiram
alcançar os objetivos esperados, pois estas ferramentas mostraram-se viáveis para uso
concomitante, e o proposto inicial foi alcançado.
Durante as pesquisas, constatou-se outros serviços similares no mercado, alguns
gratuitos também. Entre eles o Bing Maps (não gratuito) e Open Street Maps (mapa
colaborativo).
Ainda sobre a API, tecnologias proprietárias que disponibilizam recursos e funções
para mapas gratuitamente, resolvem questões de custo para aplicações. A problemática da
dependência em atualizações de sentidos de ruas não se aplica, considerando que a entrada de
dados é em um sistema de banco de dados, e os itinerários são previstos de acordo com os
dados que estão no banco de dados. Assim, dependências de atualizações de direções não são
verificadas. O que apresenta uma limitação quando novas ruas são criadas, estas dependem da
atualização do mapa. Outra limitação, verificada no uso da API do Google Maps, é não poder
alterar o tipo da representação gráfica da cor do itinerário, essa alteração permitiria uma
representação diferenciada para situações de pontos de origem e destino informados que
tenham mais de uma linha de ônibus em comum.
Durante o desenvolvimento, optou-se por usar o Entity Framework, por ser uma
ferramenta que poderia ser útil considerando a capacidade produtiva que ela permite depois
76
do modelo criado. O uso desta tecnologia agregou agilidade e também clareza inclusive para o
código fonte.
4.1 EXTENSÕES
Como sugestões de extensões para a continuidade do presente trabalho, tem-se:
a) otimizar a busca, utilizando busca por profundidade, para atender algumas
situações onde há uma quebra maior de terminadores de linhas;
b) utilizar outro serviço de mapa disponível no mercado, para avaliar as
funcionalidades existentes;
c) criar webservice para consumo e atualização da base de dados, como por exemplo
ruas, pontos e horários;
d) criar coordenadas cartográficas para todo o mapeamento, para traçar todo o
caminho por polilinhas;
e) disponibilizar mais informações na consulta: custo monetário da viagem (quando
há intersecções, ou sistema de transporte multimodal) e temporização (tempo da
viagem);
f) customizar a interface para a consulta em versão mobile;
g) conceber uma solução de consulta para deficientes visuais.
77
REFERÊNCIAS BIBLIOGRÁFICAS
ADO.NET entity framework. In: WIKIPEDIA, a enciclopédia livre.[S.l.]: Wikimedia
Foundation, 2012d. Disponível em:
<http://en.wikipedia.org/wiki/ADO.NET_Entity_Framework#Entities>. Acesso em: 02 jul.
2012.
API. In: WIKIPEDIA, a enciclopédia livre. [S.l.]: Wikimedia Foundation, 2012a. Disponível
em: <http://pt.wikipedia.org/wiki/Api>. Acesso em: 02 jul. 2012.
ALMEIDA, Regina A. de; GUERRERO, Ana L.; FIORI, Sérgio R. Geografia e cartografia
para o turismo. São Paulo: IPSIS, 2007.
BARBOSA, G.; RABAÇA, C.A. Dicionário de comunicação. Rio de Janeiro: Campus 2001.
BING maps. In: WIKIPEDIA, a enciclopédia livre. [S.l.]: Wikimedia Foundation, 2012b.
Disponível em: <http://pt.wikipedia.org/wiki/Bing_Maps>. Acesso em: 02 jul. 2012.
BING MAPS. Bing Maps. [S.l.], 2012. Disponível em: < http://br.bing.com/maps/ >. Acesso
em: 23 jun. 2012.
CÂMARA Gilberto; DAVIS Clodoveu; MONTEIRO, Vieira M. A. Introdução à ciência da
geoinformação. São José dos Campos, 2001. Disponível em:
<http://www.geolab.faed.udesc.br/paginaweb/Pagina%20da%20disciplina%20geop_files/into
ducao.pdf>. Acesso em: 16 mar. 2012.
GHELMAN, Marcelo. Monitoramento Geoespacial de Queimadas para Prevenção de
Desligamento de Linhas de Transmissão. 2009. Monografia – Departamento de Eletrônica e
de Computação, Universidade Federal do Rio de Janeiro, Rio de Janeiro. Disponível em:
<http://monografias.poli.ufrj.br/monografias/monopoli10001929.pdf>. Acesso em: 25 jul.
2012.
CARVALHO, Alexandre. O geoprocessamento como recurso para análise das
ocorrências em linhas de ônibus urbano em Belo Horizonte – um estudo de caso. 2002. 55
f. Monografia (Especialização) – Departamento de Cartografia, Universidade Federal de
78
Minas Gerais, Belo Horizonte. Disponível em:
<http://www.csr.ufmg.br/geoprocessamento/publicacoes/ALEXANDRE%20DE%20CARVA
LHO.PDF>. Acesso em: 16 mar. 2012.
CATALOGEO. [S.l.], [2011?]. Disponível em:
<http://www.catalogeo.com.br/index.php?option=com_content&view=article&id=104:acarto
grafia&catid=47:noticias&Itemid=89>. Acesso em: 16 mar. 2012.
FARIA, Carolina. Geoprocessamento. Jornal Livre. [S.l.], 2008. Disponível em:
<http://www.jornallivre.com.br/200043/tecnologia-geoprocessamento.html>. Acesso em: 02
jul. 2012.
GOOGLE MAPS. Google Maps. [S.l.], 2012. Disponível em:
<http://maps.google.com.br/maps?hl=pt-BR&tab=wl>. Acesso em: 23 jun. 2012.
GOOGLE DEVELOPERS. Google Maps API. [S.l.], 2012a. Disponível em:
<https://developers.google.com/maps/?hl=pt-BR>. Acesso em: 23 jun. 2012.
______. Google Maps API – princípios básicos da Google Maps Javascript API V3. [S.l.],
2012b. Disponível em:
<https://developers.google.com/maps/documentation/javascript/basics?hl=pt-BR#Welcome>.
Acesso em: 23 jun. 2012.
______. Google Maps API – tutorial Google Maps Javascript API V3. [S.l.], 2012c.
Disponível em:
<https://developers.google.com/maps/documentation/javascript/tutorial?hl=pt-BR>. Acesso
em: 23 jun. 2012.
______. Google Maps API – eventos Google Maps Javascript API V3. [S.l.], 2012d.
Disponível em: <https://developers.google.com/maps/documentation/javascript/events?hl=pt-
BR>. Acesso em: 23 jun. 2012.
______. Google Maps API – controles Google Maps Javascript API V3. [S.l.], 2012e.
Disponível em:
<https://developers.google.com/maps/documentation/javascript/controls?hl=pt-BR>. Acesso
em: 23 jun. 2012.
79
______. Google Maps API – superposições Google Maps Javascript API V3. [S.l.], 2012f.
Disponível em:
<https://developers.google.com/maps/documentation/javascript/overlays?hl=pt-BR>. Acesso
em: 23 jun. 2012.
______. Google Maps API – serviços Google Maps Javascript API V3. [S.l.], 2012g.
Disponível em:
<https://developers.google.com/maps/documentation/javascript/services?hl=pt-BR>. Acesso
em: 23 jun. 2012.
FRESARD, Francisco. Ônibus de Blumenau no Google Maps. Jornal de Santa Catarina,
Blumenau, 2011. Disponível em <http://wp.clicrbs.com.br/pancho/2011/11/15/onibus-de-
blumenau-no-google-maps-2/?topo=52,2,18,,159,e159>. Acesso em: 23 jun. 2012.
LABTATE. Laboratório de cartografia tátil e escola. Florianópolis, 2011. Disponível em:
<http://www.labtate.ufsc.br/>. Acesso em: 16 mar. 2012.
LINQ. In: WIKIPEDIA, a enciclopédia livre. [S.l.]: Wikimedia Foundation, 2012c.
Disponível em: <http://en.wikipedia.org/wiki/LINQ >. Acesso em: 02 jul. 2012.
LOCH, Ruth E. N. Cartografia – representação, comunicação e visualização de dados
espaciais. Florianopólis: Editora da UFSC, 2006.
MACORATTI, José C. Introdução ao Entity Framework. Macoratti. [S.l.], 2009. Disponível
em: <http://www.macoratti.net/09/06/vb_iaef.htm>. Acesso em: 23 jun. 2012.
MACORATTI, José C. SilverLight 4 - usando o entity framework 4. [S.l.], 2011. Disponível
em: <http://www.macoratti.net/11/01/svl4_ef4.htm>. Acesso em: 23 jun. 2012.
MEDEIROS, Anderson M. L. Norteando seu conhecimento em geotecnologias. [S. l.],
2009. Disponível em < http://www.clickgeo.com.br/> . Acesso em 02 jul. 2012.
MEDEIROS, Anderson Maciel Lima. Desenvolvimento de uma aplicação Web Mapping
direcionada à pesquisas educacionais. [S.l.], 2011. Disponível em:
<http://blog.geoprocessamento.net/2010/03/monografia-anderson-medeiros/>. Acesso em: 02
jul. 2012.
80
MICROSOFT. Bing Maps. [S.l.], 2012. Disponível em: <http://msdn.microsoft.com/en-
us/library/dd877180>. Acesso em: 02 jul. 2012.
______, Bing Maps developer resources: map SDKs, APIs, tips, traning. [S.l.], 2011.
Disponível em: <http://www.microsoft.com/maps/developers/mapapps.aspx>. Acesso em: 02
jul. 2012.
______, ADO.NET Entity Framework At-a-Glance. [S.l.], 2012b. Disponível em:
<http://msdn.microsoft.com/en-us/data/aa937709>. Acesso em: 02 jul. 2012.
______, Introdução às consultas do LINQ (C#). [S.l.], 2012c. Disponível em:
<http://msdn.microsoft.com/pt-br/library/bb397906.aspx>. Acesso em: 02 jul. 2012.
______, Estimative the size of a heap. [S.l.], 2012d. Disponível em:
<http://msdn.microsoft.com/en-us/library/ms189124.aspx>. Acesso em: 11 jul. 2012.
MOURA, Ana C. M. Geoprocessamento na gestão e planejamento urbano. Belo
Horizonte: Ed. da autora, 2005.
OPEN STREET MAP. Open street map. [S.l.], 2012. Disponível em:
<http://www.openstreetmap.org/>. Acesso em: 02 jul. 2012.
OPEN STREET MAP WIKI. Open street map wiki. [S.l.], 2012. Disponível em:
<http://www.openstreetmap.org/>. Acesso em: 02 jul. 2012.
SETERB, Seterb. Blumenau, 2012. Disponível em: <http://www.seterb.sc.gov.br/>. Acesso
em: 23 jun. 2012.
TRANSPORLIS. Transporte Lisboa. Lisboa, 2009. Disponível em:
<http://www.transporlis.sapo.pt>. Acesso em: 23. jun 2012.
TMB VIRTUAL, Transportes metropolitanos de Barcelona. Barcelona, 2011. Disponível
em: <http://www.tmb.cat/en/tmb-virtual>. Acesso em: 15 mar. 2012
![ITINERÁRIOS TERAPÊUTICOS: COMPREENDENDO A ......Cabral, Ana Lúcia Lobo Vianna. C117i Itinerários terapêuticos [manuscrito]: compreendendo a trajetória de pessoas em hemodiálise](https://img.document.onl/doc/110x75/5fb930e2924c10679d189842/itinerrios-teraputicos-compreendendo-a-cabral-ana-lcia-lobo-vianna.jpg)
![PORTUGAL - ITINERÁRIOS (PT) [TP - SD]](https://img.document.onl/doc/110x75/577cdfd11a28ab9e78b20b3b/portugal-itinerarios-pt-tp-sd.jpg)
