ministério da defesa exército brasileiro departamento - SE/8

MINISTÉRIO DA DEFESA
EXÉRCITO BRASILEIRO
DEPARTAMENTO DE CIÊNCIA E TECNOLOGIA
INSTITUTO MILITAR DE ENGENHARIA
CURSO DE GRADUAÇÃO EM ENGENHARIA DE COMPUTAÇÃO
FREDERICO CIANNELLA NUNES
IGOR DE CASTRO LIMA
LUCAS VELOSO SARAIVA
IMPLEMENTAÇÃO DE UM SISTEMA DE NAVEGAÇÃO PARA DISPOSITIVOS
MÓVEIS UTILIZANDO MAPAS ARMAZENADOS EM BANCOS DE DADOS
GEOGRÁFICOS
Rio de Janeiro
2009
SUMÁRIO
LISTA DE ILUSTRAÇÕES .................................................................................. 4
LISTA DE SIGLAS .............................................................................................. 6
RESUMO ............................................................................................................. 9
ABSTRACT ....................................................................................................... 10
1.
INTRODUÇÃO ........................................................................................... 11
2.
OBJETIVOS ............................................................................................... 12
2.1.
3.
JUSTIFICATIVA ....................................................................................................12
FUNDAMENTAÇÃO TEÓRICA ................................................................. 14
3.1.
SISTEMAS DE NAVEGAÇÃO E BASES CARTOGRÁFICAS DIGITAIS .............................14
3.1.1.
Global Navigation Satellite System – GNSS ................................................................... 14
3.1.2.
Características do Sistema NAVSTAR GPS ................................................................... 15
3.1.3.
GPS Diferencial (DGPS) .................................................................................................. 17
3.1.4.
Mapas .............................................................................................................................. 17
3.1.5.
Estruturação de Dados Gráficos Digitais ......................................................................... 18
3.1.6.
Banco de Dados Geográficos .......................................................................................... 20
3.1.7.
Open Geospatial Consortium (OGC) ............................................................................... 21
3.1.8.
Geograhic Markup Language - GML ............................................................................... 23
3.1.9.
OGC Web Services - OWS.............................................................................................. 25
3.2.
TECNOLOGIA DE IMPLEMENTAÇÃO EM DISPOSITIVOS MÓVEIS ................................27
3.2.1.
Formatos Vetoriais ........................................................................................................... 27
3.2.2.
Sistemas de Geoinformação ........................................................................................... 30
3.2.3.
Fontes de Dados Geográficos ......................................................................................... 31
3.2.4.
Tecnologias de Implantação ............................................................................................ 34
3.2.5.
Sistemas Operacionais .................................................................................................... 36
3.2.6.
Módulos de Desenvolvimento.......................................................................................... 39
3.2.7.
Configurações (Configurations) ....................................................................................... 42
3.2.8.
Perfis (Profiles) ................................................................................................................ 43
3.2.9.
Máquinas Virtuais ............................................................................................................ 47
4.
METODOLOGIA ........................................................................................ 49
4.1.
EQUIPAMENTOS ..................................................................................................49
4.2.
SOFTWARES .......................................................................................................50
4.3.
JSR’S ................................................................................................................51
2
4.4.
DESENVOLVIMENTO DO SOFTWARE......................................................................52
4.4.1.
Exibição do mapa ............................................................................................................ 52
4.4.2.
Recepção de coordenadas do receptor .......................................................................... 53
4.4.3.
Manipulação de mapas SVG ........................................................................................... 55
4.4.4.
Integração de todas as funcionalidades .......................................................................... 66
4.5.
EXTRAS ..............................................................................................................68
4.5.1.
Envio das coordenadas para o servidor .......................................................................... 68
4.5.2.
Chat ................................................................................................................................. 70
4.5.3.
Integração com Google Map ........................................................................................... 70
5.
CONCLUSÕES .......................................................................................... 73
6.
TRABALHOS FUTUROS .......................................................................... 75
7.
REFERÊNCIAS BIBLIOGRÁFICAS .......................................................... 78
8.
ANEXOS .................................................................................................... 82
8.1.
ANEXO A ............................................................................................................82
8.2.
ANEXO B ............................................................................................................83
8.3.
ANEXO C ............................................................................................................91
8.4.
ANEXO D ............................................................................................................93
8.5.
ANEXO E ............................................................................................................98
3
LISTA DE ILUSTRAÇÕES
Figura 1 - Constelação de Satélites[13] .................................................................... 15
Figura 2 - Vetorial versus Raster[1] .......................................................................... 19
Figura 3 - Código GML com o schema de uma cidade[9]. ....................................... 24
Figura 4 - Arquivo SVG[27]....................................................................................... 29
Figura 5 - Modelo de banco de dados integrados com várias instituições transferindo
dados entre si [Adaptado de Néri[19]] ...................................................................... 33
Figura 6 - Estrutura do J2SE[27]. ............................................................................. 40
Figura 7 - Estrutura do J2EE[27]. ............................................................................. 41
Figura 8 - Estrutura do J2ME[27].............................................................................. 41
Figura 9 - Configuração CLDC[27] ........................................................................... 42
Figura 10 - Estrutura de JVM, Configurações e Perfis no J2ME[4] .......................... 45
Figura 11 - Plataforma JavaME com suas configurações, perfis e API's[4].............. 46
Figura 12 - Máquina virtual[27] ................................................................................. 48
Figura 13 - Classe responsável pela exibição do mapa svg ..................................... 52
Figura 14 - Método responsável por desenhar o mapa na tela ................................ 53
Figura 15 - Coordenadas do receptor....................................................................... 54
Figura 16 - Instanciação de um receptor e obtenção de coordenadas ..................... 54
Figura 17 - Rotação .................................................................................................. 56
Figura 18 - Zoom ...................................................................................................... 56
Figura 19 - Arraste do mapa ..................................................................................... 57
Figura 20 - Métodos de tratamento de interações com o usuário............................. 58
Figura 21 - Localizacao Atual ................................................................................... 59
Figura 22 - Plotagem do ponto referente às coordenadas do receptor .................... 60
Figura 23 - Seleção de feições ................................................................................. 61
Figura 24 - Seleção de feição ................................................................................... 61
Figura 25 - Seleção de feição e representação de atributos na tabela..................... 62
Figura 26 - Seleção de layers ................................................................................... 63
Figura 27 - Seleção de layer..................................................................................... 64
Figura 28 - Tracklog ................................................................................................. 65
4
Figura 29 - Tracklog ................................................................................................. 65
Figura 30 - Acesso ao sistema de arquivos .............................................................. 66
Figura 31 - Arquitetura do sistema ........................................................................... 68
Figura 32 - Envio de coordenadas para o servidor ................................................... 69
Figura 33 - Chat........................................................................................................ 70
Figura 34 - Integração com Google Map .................................................................. 71
Figura 35 - Diagrama de Classes ............................................................................. 92
Figura 36 - Pré-Conversor ........................................................................................ 94
Figura 37 - Código Fonte Conversor SVG ................................................................ 97
Figura 38 - Classe Principal...................................................................................... 97
Figura 39 - Extrato de um arquivo em formato SVG, referente ao mapa do bairro de
Botafogo – RJ, gerado a partir do Geoserver ........................................................... 98
Figura 40 - Extrato de um arquivo em formato SVG, referente ao mapa do bairro de
Botafogo – RJ, gerado a partir do conversor da Carto.Net[2]. .................................. 98
Figura 41 - Extrato do arquivo SVG gerado a partir dos dois arquivos anteriores
utilizando-se o conversor próprio.............................................................................. 99
Figura 42 - Mapa do bairro de Botafogo – RJ obtido pelo conversor próprio. .......... 99
Figura 43 - Mapa do bairro do Centro - RJ obtido a partir do conversor próprio. ... 100
Figura 44 - Mapa do bairro do Centro – RJ gerado a partir do conversor da
Carto.Net[2]. ........................................................................................................... 100
5
LISTA DE SIGLAS
API
–
APLICATION PROGRAMMING INTERFACE
BDG
–
BANCO DE DADOS GEOGRÁFICO
BD
–
BANCO DE DADOS
CAD
–
COMPUTER AIDED DESIGN
DGPS –
GPS DIFERENCIAL
DTD
DOCUMENT TYPE DEFINITION
–
GNSS –
GLOBAL NAVIGATION SATELLITE SYSTEM
GPS
–
GLOBAL POSITIONING SYSTEM
ISO
–
INTERNATIONAL ORGANIZATION FOR STANDARDIZATION
JCP
–
JAVA COMMUNITY PROCESS
JSR
–
JAVA SPECIFICATION REQUESTS
KML
–
KEYHOLE MARKUP LANGUAGE
OGC
–
OPEN GEOSPATIAL CONSORTIUM
OGIS
–
OPEN GEODATE INTEROPERABILITY SPECIFICATION
PDA
–
PERSONAL DIGITAL ASSISTANT
SGBD –
SISTEMA GERENCIADOR DE BANCO DE DADOS
SIG
SISTEMA DE INFORMAÇÃO GEOGRÁFICA
–
SOAP –
SIMPLE OBJECT ACCESS PROTOCOL
SVG
–
SCALABLE VECTORIAL GRAPHICS
UDDI
–
UNIVERSAL DESCRIPTION, DISCOVERY AND INTEGRATION
XML
–
EXTENSIBLE MARKUP LANGUAGE
W3C
–
WORLD WIDE WEB CONSORTIUM
WSDL –
WEB SERVICES DEFINITION LANGUAGE
6
GLOSSÁRIO
API – Conjunto de rotinas, estruturas de dados, classes de objetos e protocolos
provido por bibliotecas para dar suporte ao desenvolvimento de aplicações.
Especifica uma interface e o comportamento dos objetos desta interface. Quando
um software provê a funcionalidade de uma API ele é dito uma implementação desta
API.
CARTA – Representação no plano, em escala média ou grande, dos aspectos
artificiais e naturais de determinada área, subdividida em folhas articuladas de
maneira sistemática.
DATUM – Ponto de interseção entre a Terra e a superfície de referência utilizada
para realizar cálculos de posição.
DTD – Definições de padrões para a estrutura de um xml.
JCP – Comitê formado por membros da comunidade JavaTM responsável por
analisar e aprovar ou não uma JSR.
JSR – Especificações para a plataforma Java. Podem ser submetidas por qualquer
desenvolvedor e é analisada pela JCP.
JSR179 – API Location. Utilizada para a obtenção de coordenadas a partir de um
receptor GPS.
JSR226 – API SVG Graphic 2D Canvas. Utilizada para a renderização e tratamento
de um arquivo SVG.
JSR75 – File Connection. Utilizada para o acesso ao sistema de arquivos do
dispositivo.
LAYERS – São as camadas de um mapa. Podem formar vários temas.
MAPA – Representação no plano, em escala pequena, dos aspectos geográficos,
naturais, culturais e artificiais de determinada área destinada aos mais variados
usos.
7
KML – Linguagem xml para descrição de dados em mapas bidimensionais ou
tridimensionais.
SOAP – Consiste em um arquivo xml utilizado para a troca de informações e
estruturado segundo uma das especificações recomendadas pela W3C.
W3C – Desenvolve especificações, padrões, ferramentas e softwares para a
interoperabilidade de tecnologias a fim de extrair o máximo potencial da Web.
Funciona também como um fórum de pesquisas, informações, negócios e
aprendizado.
WSDL – Linguagem baseada em xml para descrever WebServices.
8
RESUMO
Este projeto implenta um sistema de navegação, em JavaME, para dispositivos
móveis com configuração mínima CLDC 1.1 MIDP 2.0 utilizando-se soluções em
padrões abertos e empregando-se o conceito de software livre.
O presente sistema de navegação consiste em uma aplicação capaz de fornecer
na tela do dispositivo móvel sua posição sobre um mapa vetorial em formato aberto
carregado pelo usuário, ou sobre os dados do Google Maps, no caso de
disponibilidade de conexão via http. A implementação deste protótipo prevê a
obtenção deste mapa a partir de um banco de dados geográfico ou de um arquivo,
com possibilidade futura de adquiri-lo a partir de outros formatos já adotados pelos
produtos comerciais de geoprocessamento.
O sistema permite a manipulação do mapa, sobre o qual é locada a posição do
dispositivo, por meio de zoom, arraste, rotação, seleção de feições, seleção de
níveis de informação (layers) e visualização de atributos. Uma das potencialidades
do sistema consiste em permitir o lançamento dos dados obtidos em campo sobre o
mapa, visando a carga no banco de dados para fins de atualização cartográfica.
A aplicação do projeto se dá em várias áreas que exijam o conhecimento da
posição em tempo real, ou nas quais seja útil o armazenamento de pontos obtidos
em campo. Citam-se, como exemplo, atividades turísticas, práticas de trilha,
deslocamentos de automóvel ou até mesmo atividades de levantamento de pontos
expeditos em um terreno, como ferramenta de auxílio na cartografia.
O software foi desenvolvido com arquitetura modular, de modo a permitir a
inserção futura de novas funcionalidades. A localização é atualmente feita através
de satélites pelo Sistema de Posicionamento Global Navistar GPS, podendo ser
expandido, futuramente, para o uso de outras tecnologias.
9
ABSTRACT
This project implements a navigation system in Java ME for mobile devices with
minimal configuration CLDC 1.1 MIDP 2.0 solutions using open standards and using
the concept of free software.
This navigation system consists of an application capable of providing the screen
of the mobile device's position on a map vector carried by the user, or on data from
Google Maps, where the availability of connection via http is required. The
implementation of this prototype provides for the achievement of this map from a
geographic database or file, with the future possibility of achievement of others
formats as adopted by the commercial GIS products.
The system allows the manipulation of the map, which is leased to position the
device, by zooming, dragging, rotation, selection of features, selection of levels of
information (layers) and visualization of attributes. One of the capabilities of the
system is to allow the release of the data obtained on the map, in order to load the
database for update mapping.
The implementation of the project takes place in several areas that require
knowledge of the position in real time, or in which it is useful for storage of points
obtained in the field. For example, tourist activities, tracking, the car shifts or even
raising activities expedited points on land, as a tool to aid in cartography.
The software was developed with a modular architecture in order to allow future
integration of new features. The location is currently done through the satellite Global
Positioning System GPS Navistar, which can be expanded in future to the use of
other technologies.
10
1. Introdução
Com o crescente avanço tecnológico, têm-se dispositivos móveis com grande
capacidade de processamento gráfico permitindo a visualização de coordenadas
sobre um mapa na tela dos mesmos. Entretanto, os diversos dispositivos atuais com
sistemas de navegação utilizam mapas em formato proprietário limitando a cobertura
à regiões de interesse comercial do fabricante, obrigando o usuário a gastos
freqüentes com atualizações e impedindo-o, ou ao menos dificultando-o, a
visualização de seus próprios mapas.
Atualmente, os sistemas de navegação estão se tornando cada vez mais
acessíveis. Este fato se deve principalmente ao barateamento dos dispositivos
receptores GPS e a possibilidade do uso destes com dispositivos móveis de uso
cotidiano, como celulares e PDAs. Isto permitiu uma expansão do universo de
aplicações que podem ser oferecidas tanto para o meio civil quanto para o meio
militar, como por exemplo, a orientação de tropas, onde a clareza, a rapidez na
leitura das informações e a portabilidade se tornam vitais, bem como servir de guia
para turistas em viagens.
Nesse contexto, faz-se necessário o desenvolvimento de um software de
navegação, genuinamente brasileiro, que atenda às necessidades atuais das Forças
Armadas e em aplicações civis, além de servir como plataforma de desenvolvimento
de novas tecnologias na área. Este sistema deve ser capaz de não apenas fornecer
a localização, como também de permitir a implementação de algoritmos de
roteamento entre dois pontos utilizando mapas em formato aberto.
Por fim, tal sistema de navegação possui um alto valor agregado, devido à
importância das informaçoes tratadas, e encontra-se em um setor da tecnologia em
franca expansão. Tal fato comprova-se com a crescente oferta de aparelhos que
convergem para a integração entre telefones celulares, PDAs e receptores GPS a
preços cada vez mais acessíveis.
11
2. Objetivos
Este trabalho pretende desenvolver um sistema capaz de:
a) Carregar na tela de um dispositivo móvel cartas vetoriais convertidas a partir
de uma base cartográfica armazenada segundo o padrão OpenGIS e realizar
a navegação sobre estas cartas;
b) através das coordenadas transmitidas a partir de um receptor GPS, plotar na
tela do dispositivo a posição;
c) armazenar pontos e trilhas e relacioná-los a atributos e a metadados, de
forma que possam ser utilizados na produção e na atualização cartográfica a
partir de sua transferência para um BDG compatível com o padrão OpenGIS;
2.1.
Justificativa
O trabalho a ser desenvolvido neste PFC se enquadra no Plano Setorial de
Ciência e Tecnologia (PSCT) junto ao Grupo de Comando e Controle, na área de
Sistemas de Informações Geográficas (SIG) e possui as seguintes premissas:
a) Aderência ao Plano Setorial de Ciência e Tecnologia (PSCT) do
Departamento de Ciência e Tecnologia (DCT) do Exército Brasileiro;
b) Utilização de programas de código aberto;
c) Compatibilidade com o padrão aberto OpenGIS;
d) Dualidade de aplicação (civil-militar), possibilitando a implantação de um
sistema de navegação que possa ser utilizado junto ao protótipo
12
SigDesktop desenvolvido no GC2/PBCT, um SIG que objetiva o emprego
pelas Organizações Militares e pela comunidade civil.
e) Possibilita a redução de custos na aquisição pelas Forças Armadas de
equipamentos para os fins citados (posicionamento, navegamento e
levantamentos cartográficos expeditos), uma vez que o sistema permitirá o
uso de dispositivos do cotidiano, tais como smartphones e PDAs.
13
3. Fundamentação Teórica
Nesta seção, será feita uma introdução teórica necessária para a compreensão
do cenário técnico-científico, no qual se insere esta projeto e dos resultados obtidos.
3.1.
Sistemas de Navegação e Bases Cartográficas Digitais
3.1.1. Global Navigation Satellite System – GNSS
Sistema Global de Navegação por Satélite (GNSS) é um sistema que utiliza
técnicas de posicionamento por satélites para fornecer aos usuários informações de
posição e de tempo. Os principais exemplos de GNSS na atualidade são: o
NAVSTAR GPS (Navigation Satellite with Time and Ranging - Global Positioning
System, EUA), o GLONASS (Sistema de Navegação Global por Satélite, Rússia), o
GALILEO (União Européia), o Beidou (China) e o IRNSS (Indian Regional
Navigational Satellite System, Índia).
O sistema NAVSTAR GPS tem origem nos Estados Unidos e é controlado pelo
Departamento de Defesa norte-americano (Departament of Defense – DoD). Esse
sistema está completo e em pleno funcionamento com uma constelação de 27
satélites, sendo que 3 deles são reservas. Ele é atualmente o sistema de navegação
mais utilizado no mundo[31].
O sistema GLONASS foi desenvolvido pela Rússia e é controlado pela
Federação Russa. Ainda hoje não está totalmente implantado.
O sistema Galileo é um projeto da União Européia. Ele será uma alternativa civil
ao GPS existente atualmente que é controlado pelos militares americanos. Serão
colocados em órbita 30 satélites até 2010 (prorrogaçao de 2 anos do projeto
14
original). Há a expectativa de que esse novo sistema seja mais preciso que o GPS e
que possua uma maior área de cobertura de satélites.
Além desses existem, os sistemas Beidou, Chinês, e o IRNSS, Indiano, que
estão ainda em fase de testes de projeto.
3.1.2. Características do Sistema NAVSTAR GPS
Cada satélite transmite duas ondas portadoras: bandas L1 e L2. Elas são
geradas a partir da freqüência fundamental de 10,23 MHz, que é disponibilizada
pelos relógios atômicos a bordo do satélite. Multiplicando a freqüência fundamental
por 154 tem-se a freqüência da portadora L1, e multiplicando por 120 tem-se a
freqüência da portadora L2.
L1 = 1575,42 MHz e λ = 19 cm.
L2 = 1227,60 MHz e λ = 24 cm.
Figura 1 - Constelação de Satélites[13]
15
Cada satélite na constelação Navstar transmite simultaneamente as duas
bandas L. Na mensagem são transmitidas informações sobre as efemérides dos
satélites, o tempo GPS, comportamento do relógio e mensagens da saúde (status)
do sistema.
Os códigos são modulados, em fase, sobre essas duas portadoras. Essa técnica
permite realizar medidas de distâncias a partir da medida do tempo de propagação
da modulação[32]. É uma seqüência binária de +1 e -1, ou 0 e 1, que parece ter
características aleatórias. Como é gerado por um algoritmo, pode ser univocamente
identificado. Interessam ao presente trabalho os códigos C/A e P.
O código C/A (Coarse Acquisition – aquisição bruta), está disponível livre de
custos para usuários civis em todos os cantos do globo terrestre. Possui o
comprimento de onda por volta de 300m, é transmitido na taxa de 1 milhão de bits
por segundo, com o intervalo de repetição de 1.023 bits. Portanto é repetido depois
de aproximadamente um milésimo de segundo.
O código P (Precise or Protected – preciso ou protegido) tem sido reservado
para o uso das Forças Armadas norte-americanas e dos usuários autorizados. Ele é
protegido por técnicas de criptografia que restringe o acesso e nega precisão total
aos usuários não autorizados. É transmitido numa taxa de 10 milhões de bits por
12
segundo, seu intervalo de repetição é de aproximadamente 6x10 bits. Essa
diferença faz com que as medições com o código P sejam bem mais precisas.
Cada um dos satélites da constelação Navstar possui um código C/A e um
código P. Isso poderia causar dificuldades para um receptor GPS distinguir entre
todos os códigos possíveis. No entanto, o código C/A faz parte de uma família de
códigos (Gold codes), que tem como característica básica a baixa correlação entre
seus membros. Isso possibilita a rápida distinção dos sinais recebidos,
simultaneamente, de vários satélites[32].
16
3.1.3.
GPS Diferencial (DGPS)
Diz-se que as medições de coordenadas feitas por um único receptor a partir
apenas dos sinais emitidos pelos satélites do sistema GPS são obtidas por
posicionamento absoluto.
O GPS Diferencial é o método utilizado em receptores GPS para isso
capacitados, com o objetivo de determinar a diferença entre a posição informada
pelo sistema GPS e a sua posição geográfica verdadeira na superfície terrestre.
Tem por finalidade obter uma precisão superior às obtidas pelos receptores em
modo absoluto de posicionamento.
As correções DGPS se dividem em dois grupos: em tempo real e pósprocessadas. No DGPS em tempo real os receptores utilizam dispositivos de
transmissao em tempo real tais como: transmissores de ondas de rádio e telefone
celular. É capaz de obter posicionamento com precisão de metro no local e na hora
do procedimento, desde que um dos receptores se encontre estacionado sobre um
ponto de coordenada conhecida.
No DGPS pós-processado armazenam-se todas as informações fornecidas
pelos satélites da rede GPS para que os dados obtidos pelo receptor sejam
confrontados posteriormente com o sinal rastreado por uma estação base de
rastreamento GPS (fornecedora do ponto de coordenadas conhecidas). Assim, os
erros sistemáticos do rastreio feito pelo receptor móvel (também conhecidos como
ROVER) são minimizados e em grande parte eliminados.
3.1.4.
Mapas
O conhecimento, a observação e a representação da superfície terrestre têm
papel fundamental nas atividades de organização das sociedades.
Da antigüidade até os tempos atuais, informações espaciais têm sido
observadas por guerreiros, navegadores, geógrafos, pesquisadores e descritas de
17
forma gráfica pelos cartógrafos. Seguramente, o que hoje se conhece como mapa,
nada mais é que uma das mais antigas formas de comunicação visual da
humanidade.
Um mapa consiste na representação de uma área curva sobre uma superfície
plana ressaltando relações entre elementos do espaço como objetos, feições do
terreno, regiões e temas. Geralmente, constitui-se em uma representação de um
espaço tri-demensional em outro correspondente bidimensional. Apresenta-se em
folhas de papel ou digitalmente. No último caso, torna-se dinâmico, interativo e pode
ser apresentado tridimensionalmente. Mapas digitais podem ser estruturados em um
ou mais níveis ou camadas (layers).
Um dos elementos fundamentais dos mapas é a escala, que permite
determinar as dimensões reais de objetos e medir distâncias. Escala é o quociente
entre a medida no mapa e a medida real correspondente. Quanto maior é a escala,
maior o detalhe.
A maioria das análises do terreno pode ser feita sobre uma carta,
denominando-se Cartometria. Este processo é realizado de forma visual, com o
emprego de instrumentos gráficos extraindo um conjunto limitado de informações
como perfis topográficos, distâncias, áreas de visibilidade, entre outros. Este
processo é demorado e dispendioso, além de normalmente se trabalhar com um
grande conjunto de cartas, aliada a um conjunto de informações dispostas em
relatórios em papel.
3.1.5.
Estruturação de Dados Gráficos Digitais
Os dados gráficos em meio digital podem ser estruturados basicamente de
duas formas: matricial e vetorial. Dizemos que o dado está na forma matricial
quando está estruturado com pixels de diferentes cores, ou tonalidades (no caso de
imagens monocromáticas), dispostos como uma matriz. Estes pixels, quando vistos
em conjunto em uma escala menor, formam uma imagem contínua. A imagem
18
matricial ocupa maior espaço já que contém a informação de cor para cada pixel que
compõe a imagem.
Já a representação vetorial pode ser expressa pelas três primitivas
geométricas básicas: pontos, linhas e polígonos. Estes elementos podem ser
associados a um rótulo que permite identificá-los. Como são armazenadas apenas
as coordenadas dos pontos que definem cada forma geométrica, ocupa-se menor
espaço de armazenamento representando um ganho para dispositivos com limitação
de recursos. Segue abaixo uma figura que mostra a distinção entre as
representações matricial e vetorial. Repare na figura que cada feição da porção
esquerda é representada por polígonos (vetorial), ao passo que a porção direita é
dividida em pequenos pedaços que quando vistas em conjunto formam as diferentes
feiçoes na figura.
Figura 2 - Vetorial versus Raster[1]
Outra vantagem da representação vetorial sobre a raster é a escalabilidade, o
que permite a ampliação ou redução do mapa sem perda de qualidade A
representação vetorial permite, ainda, realizar transformações de rotação,
transladação e de multiplicação por uma constante de forma simples já que suas
instruções de desenho são independentes de resolução. Essa característica permite
a multiplicação ou divisão da figura vetorial por uma constante possibilitando a
19
transformação desta figura de modo que se adapte aos diferentes tipos de resolução
dos diversos dispositivos.
No caso de representação raster deve-se criar um conjunto de imagens,
figuras e de ícones separados para cada tipo de resolução de tela.
Em animações utilizando-se raster, na mudança de um quadro de exibição, a
imagem muda a cada quadro de animação. Em contrapartida, animações vetoriais
incluem apenas as instruções que indicam quais dos elementos sofrerão mudanças
e quando eles as sofrerão. Dessa forma, as animações vetoriais são da ordem de
duas vezes menores que as animações rasteres, o que torna as primeiras bastante
atrativas para a transmissão e apresentação em dispositivos móveis.
3.1.6.
Banco de Dados Geográficos
A introdução de conceitos referentes a um banco de dados geográficos (BDG)
se faz necessária visto que a base cartográfica do sistema de navegação para o
qual levantar-se-ão seus requisitos, é armazenada em um BDG. A diferença entre
um BDG e um banco de dados (BD) se deve à manipulação e armazenamento de
dados compostos por atributos espaciais junto aos convencionais, aspectos sobre os
quais um BD convencional não oferece suporte, ou o oferece de forma não
otimizada.
Um BDG representa atualmente uma tendência em Sistemas de Informação
Geográfica (SIG) no que diz respeito ao armazenamento, consulta e análise de
dados georreferenciados e é entendidocomo uma extensão dos bancos de dados
relacionais que incorporam ferramentas para gerenciamento de informações
espaciais [18].
Presente nos BDG e SIG, o dado geográfico é um dado espacial
georreferenciado, ou seja, possui uma localização sobre a superfície terrestre em
um certo intervalo de tempo.
20
3.1.7.
Open Geospatial Consortium (OGC)
O Open Geospatial Consortium (OGC) - Consórcio Geoespacial Aberto é um
consórcio industrial internacional com mais de 348 companhias, agências do
governo e universidades participando em um processo concensual para desenvolver
especificações de uma interface disponivel publicamente.
Com o intuito de padronizar o acesso a esses dados e assim permitir a
interoperabilidade entre SIG’s, o OGC estabeleceu um padrão aberto conhecido
como OpenGIS (Open Geodate Interoperability Specification).
A utilização do padrão OpenGIS para o armazenamento e acesso de dados
geográficos garante a interoperabilidade entre diferentes Bancos de Dados e
Sistemas de Informações Geográficas, não se atendo a um aplicativo específico.
Interoperabilidade é a capacidade de comunicar, executar rotinas ou transferir
informações através de unidades funcionais de modo que o usuário tenha o mínimo
ou nenhum conhecimento das características específicas de cada unidade [ISO
2382-1]. O OGC foi fundado devido justamente ao problema de não haver
interoperabilidade entre sistemas da indústria geoespacial. O consórcio OpenGIS
implementa soluções para aplicações espaciais seguindo um padrão aberto
internacional e possui membros trabalhando colaborativamente no desenvolvimento
de tecnologias de informação e localização espacial.
As especificações OpenGIS existentes até o momento da pesquisa são:
implementação
de
feições
simples
(Simple
Features
Implementation),
implementação
de
feiçoes
espaciais
(Spatial
Features
Implementation),
implementação de serviços de catálogo (Catalogue Service Implementation) e
apresentação (Presentation).
A implementação de feições simples diz respeito à criação de uma ferramenta
para manipular ruas, terrenos, linhas que são representadas em um mapa como
figuras vetoriais. Suas interfaces terão uma geometria (pontos, linhas e polígonos
compostos por vetores), uma referência espacial (sistema geodésico e de projeção)
e atributos. Exemplos são classificação de um município por zona ou de uma
21
rodovia por tipo (pavimentação, federal, estadual, municipal, entre outros). Essas
especificações possibilitarão qualquer usuário fazer o intercâmbio de dados ou sua
manipulação, utilizando qualquer software que esteja em acordo com tais
especificações OpenGIS, independente do software utilziado para gerá-los.
A implementação de feições espaciais lida com dados gráficos do tipo matricial
(por exemplo, imagens geradas por satélites e fotos aéreas). O usuário de qualquer
software que atenda a tais especificações pode, por exemplo,utilizar uma foto aérea
digital para sobrepor a ela feições de um mapa vetorial ou, caso se possua uma
imagem em que diferentes intensidades de cores representem as diferenças de
temperatura numa região, pode-se efetuar uma consulta para saber quais células do
grid possui temperatura da água entre 15 e 18 graus Celsius.
A implementação de serviços de catálogo estabelece um padrão para criar
entradas em serviços de buscas espaciais que descrevam informações geoespaciais
e metadados online permitindo, assim, a indexação de milhares de web sites que
versem sobre o mesmo tema. Isso torna mais rápida a consulta por informações
sobre uma região ou um ponto do planeta. Essas entradas podem versar, por
exemplo, sobre o tipo de solo da região descrita, temperatura média, vegetação,
elevações, escolas próximas, resolução da imagem, ou qualquer outro dado de
natureza espacial.
A apresentação especifica protocolos de requisição e resposta entre um cliente
e um servidor de mapas da seguinte forma: um cliente faz uma consulta ao serviço
de buscas, segundo as especificações dos serviços de Catálogo para descobrir
URLs contendo a informação desejada. O serviço de catálogo retorna URLs. O
cliente aciona um ou mais servidores acessíveis pelas URLs retornadas pelo serviço
de catálogo e as acessa remotamente. Cada servidor de mapas requisitado acessa
a informação desejada pelo cliente e retorna um mapa com uma ou mais camadas
ou níveis (layers) dependendo da consulta. Os produtos do trabalho do OGC nesta
área estão apresentados sob forma e especificações de interfaces, como, por
exemplo, WMS, WFS (Web Services), SFS (para SQL) e padrões de intercâmbio de
dados (GML).
22
3.1.8.
Geograhic Markup Language - GML
O OpenGIS usa o padrão XML (eXtensible Markup Language) para definir
uma forma de codificar dados geográficos. Especificou-se, então, a linguagem GML
(OGC,2004). A GML foi especificada para a codificação da informação geográfica
visando o armazenamento e o transporte desta, incluindo propriedades espaciais e
não espaciais das feições.
O objetivo da GML é oferecer um conjunto de regras com as quais um usuário
pode definir quais informações (por meio de campos) serão armazenadas, gerando
assim sua própria linguagem para descrever seus dados sendo, dessa forma,
baseada em esquemas XML. O esquema XML define os elementos (tags) usados
em um documento que descreve os dados. Os principais esquemas em GML são:
a. BasicTypes: componentes simples e genéricos para representação de
atributos;
b. Topology: definições do esquema topológico;
c. Coordinate Reference System: sistema de referência de coordenadas;
d. Temporal Information and Dynamic Feature:estende as características
temporais dos dados geográficos;
e. Definitions and Dictionaries:definições de condições de uso e dicionário de
dados;
f. Metadata: metadados que descrevem os dados geográficos.
De posse destes esquemas, um usuário pode definir o seu próprio esquema para
sua aplicação.
A GML prevê como tipos de dados geométricos: pontos, linhas, polígonos e
coleções
geométricas
(MultiPoint,
MultiPolygon)
definidos
por
coordenadas
cartesianas associados a um sistema de referência espacial. Seu uso permite
bastante flexibilidade ao usuário na definição de campos por meio de ‘tags’ que
expressam o significado do dado escrito. Entretanto, a utilização de uma mesma
23
entidade com nomes diferentes como em <rio> e <curso_de_água> possibilitará a
troca de informações apenas pelo fato de ambos herdarem a classe <_Feature>,
definida pelo esquema Feature.xsd da GML , e não pelo aspecto semântico. A
solução para tal problema seria a inserção de tags que descrevam as entidades e
suas relações, ou que identifiquem sinônimos. A GML é extensamente utilizada pela
especificação WFS. Segue abaixo, um exemplo de um código GML descrevendo
uma cidade.
Figura 3 - Código GML com o schema de uma cidade[9].
24
3.1.9.
OGC Web Services - OWS
Um Web Service é uma aplicação Web que realiza uma tarefa específica ou
um conjunto de tarefas na forma de serviço, cuja interface é descrita através de uma
notação XML que fornece os detalhes necessários para interagir com o serviço. Esta
tecnologia
independe
de
linguagem
e
de
plataforma,
o
que
facilita
a
interoperabilidade entre sistemas através da adoção de padrões abertos como http,
XML, SOAP, WSDL e UDDI.
Ao contrário das aplicações clientes/servidores tradicionais, um Web Service
não fornece uma interface gráfica com o usuário. Ao invés disso, oferece uma
interface de programação que pode ser utilizada através da rede. Um exemplo é o
serviço de busca oferecido pelo Google[10], que fornece uma API através da qual
programadores, utilizando a linguagem de programação desejada, podem construir
aplicativos customizados que realizam remotamente consultas à base de dados do
Google.
1. Web Map Service – WMS
A especificação OpenGIS WMS(OGC, 2006) define um serviço para a produção
de mapas dinâmicos na WEB. O mapa se torna, portanto, a abstração dos dados
geográficos do usuário, uma vez que ele pode entrar com as coordenadas da região
desejada, por exemplo, e podem ser obtidos nos formatos matriciais (raster) PNG,
GIF e JPEG, ou em formatos vetoriais como o SVG ou KML.
Quando o cliente requisita um mapa utilizando o serviço, um conjunto de
parâmetros deve ser informado ao servidor: as camadas desejadas, os estilos que
devem ser aplicados sobre as camadas, a área de cobertura do mapa, a projeção, o
sistema de coordenadas geográficas e o formato do mapa gerado.
Os servidores WMS podem ser de dois tipos:
a. Básico: fornece suporte às operações GetCapabilities e GetMap, que são
obrigatórias;
25
b. Completo: fornece suporte à operação GetFeatureInfo, que é opcional na
implementação de um servidor WMS e que difere das anteriores por exibir os
metadados das feições tais como: tamanho do arquivo, data de coleta, autor
dos dados, entre outros.
2. Web Feature Service – WFS
As três operações mencionadas na seção anterior (WMS) fornecem uma
maneira interoperável de combinar e visualizar mapas de fontes diferentes, bem
como de consultar informações a respeito de um elemento (feature) exibido nos
mapas, porém estes últimos fornecidos sob a forma matricial. A especificação WFS
(OGC, 2005b) define a interface de um serviço complementar: o acesso e
manipulação de dados geográficos que estão por trás dos mapas na forma vetorial,
empregando GML como formato de intercâmbio de dados. O serviço pode ser
implementado de três formas:
a. Básico: disponibiliza apenas operações de consulta;
b. Com suporte a XLink: deve suportar a operação GetGmlObject, com Xlinks
locais ou remotos;
c. Transacional: implementa o serviço completo, que inclui operações de
inserção, exclusão, atualização, consulta de objetos (features) geográficos,
sendo opcional a implementação da operação GetGmlObject, que retorna as
informações de determinado objeto estruturadas em tags internas ao referido
objeto.
Dessa forma, cabe aqui enfatizar a vantagem da utilização do WFS, uma vez que
permite o intercâmbio de mapas sob a forma vetorial, possibilitando a inserção,
edição e consulta de dados do mapa com menor complexidade em relação ao mapa
matricial. Em especial para dispositivos móveis, o formato vetorial permitirá ainda a
navegação sobre o mapa sem a necessidade de computação no servidor e portanto,
sem a obrigatoriedade de conexão com o mesmo para operações de roteamento,
um requisito para o sistema proposto.
26
3.2.
Tecnologia de Implementação em Dispositivos Móveis
Os sistemas de navegação são compostos por segmento de terra (estações de
controle, receptores e usuários) e segmento espacial (satélite). Os receptores de
sinal, conhecidos como navegadores ou, coloquialmente, GPS, reúnem o receptor e
o decodificador de sinais do sistema GPS, podendo posicionar o usuário por meio de
coordenadas ou sobre um mapa digital. Esses mapas podem ser codificados sobre a
forma matricial ou vetorial. No caso desta primeira implementação do sistema, serão
utilizados mapas vetoriais.
3.2.1.
Formatos Vetoriais
Servem para armazenar informação de localização e seus atributos, como nome,
temperatura, data de coleta, digitalmente como vetores. O tipo de dados que mais
será utilizado neste projeto é estruturado de forma vetorial. Dentre eles, podem-se
destacar os formatos SHP (shapefile), DGN (Design), DXF (Drawing Exchange
Format), SVG (Scalable Vector Graphics) e KML (Keyhole Markup Language).
1. ESRI Shapefile – SHP
Formato de arquivo vetorial geoespacial não topológico mais utilizado em
softwares de sistemas de informações geográficas. Desenvolvido pela ESRI como
um padrão aberto de arquivo para interoperabilidade de dados tanto entre sistemas
da ESRI como entre sistemas proprietários.
É geralmente composto por três arquivos de extensões distintas: *.shp, *.shx e
*.dbf. Em *.shp, descrevem-se as geometrias das feições do mapa (pontos,
polilinhas e polígonos), sendo incompleto sem as outras extensões.
Em *.shx, faz-se a indexação das feições com os seus atributos contidos no
formato *.dbf. Existem, ainda, formatos opcionais como o *.prj que descreve o tipo
27
de projeção e o sistema de coordenadas utilizados, o *.sbn, que contém índices
espaciais das feições, entre outros.
Um entrave à sua utilização em dispositivos móveis provém de seu tamanho,
normalmente inviável para dispositivos com limitações de armazenamento, até
mesmo por ser um formato não topológico. Entretanto, a maior parte do seu
conteúdo é despendido com as tabelas de atributos, armazenados no *.dbf.
2. Scalable Vector Graphics – SVG
Formato de arquivo em XML, compatível com padrão aberto especificado pela
W3C utilizado em aplicações com gráficos vetoriais e animações, inicialmente em
ambiente web. As feições e comportamentos do mapa são definidos em textos XML.
SVG oferece importantes vantagens quanto à representação em relação aos
formatos bitmaps ou a outros formatos matriciais, como por exemplo, a identificação
de feições para a aplicação de operadores topológicos e espaciais, tais como
definição de melhor caminho, intersecção, conectividade e outros. Outras vantagens
são a possibilidade de edição e seleção de textos de um arquivo SVG, o tamanho
relativamente menor aos dos formatos matriciais, interatividade, interoperabilidade e
internacionalização, já que se trata de um arquivo XML e padrão aberto.
O conteúdo de um arquivo SVG é armazenado como um Document Object
Model (DOM), o que permite o acesso aos seus atributos, bem como, modificá-los.
Os elementos suportados são: <rect>, <circle>, <ellipse>, <line>, <path>, <use>,
<image>, <text>, <a>, tag de representação de um elemento genérico, <g>, tag de
representação a um conjunto de elementos gráficos. Segue abaixo o exemplo de um
SVG com o código referente.
28
Figura 4 - Arquivo SVG[27].
No SVG acima foi criado um círculo e um retângulo. O primeiro possui os
atributos ‘id’, utilizado no código para recuperar as suas informações, ‘cx’ e ‘cy’,
posição x e posição y na tela, respectivamente, ‘r’, o raio, ‘fill’, a cor de
preenchimento do círculo, ‘fill-opacity’, a definição de transparência da geomteria,
‘stroke’, a cor da borda e ‘stroke-width’, a largura da borda.
a. SVG Tiny – SVGT
Oferece
um
subconjunto
das
capacidades
do
SVG,
voltado
para
implementações em dispositivos móveis. Permite a implementação de animações
através de instruções encapsuladas no arquivo de imagem que possibilitam que ela
se modifique em resposta a eventos ou entradas do usuário.
b. SVG Basic – SVGB
Assim como o SVGT, trata-se de um subconjunto dos recursos oferecidos
pelo SVG, sendo que o SVGB foi definido para dispositivos com maiores recursos e
com maior capacidade de processamento como os PDAs.
29
3.
DGN
Oriundo do acrônimo em inglês DesiGN, este é o formato de arquivo utilizado
no
programa
Bentley
Systems
MicroStation.
A
maior
parte
das
cartas
disponibilizadas pelo IBGE está no formato DGN. Atualmente, já existem iniciativas
para tornar o formato DGN em um padrão aberto, o OpenDGN[16]. Responde por
grande parte da base cartográfica digital do Brasil, uma vez que foi um dos primeiros
arquivos para codificação de mapas vetoriais, utilizado pelo programa CAD
Mycrostation, originalmente de propriedade da Intergraph[12].
4.
DXF
Oriundo do acrônimo em inglês Drawing eXchange Format, é também um
formato utilizado no programa AutoCAD. Desenvolvido pela Autodesk com o intuito
de possibilitar a interoperabilidade entre os desenhos gerados no AutoCAD e outros
programas.
À medida que o AutoCAD foi se tornando mais complexo em termos de
objetos e de recursos, o formato DXF se tornou incompleto para representar tais
mudanças, pois certos tipos de objetos não estão documentados. Apesar de ser
simples, é bastante utilizado ainda.
3.2.2.
Sistemas de Geoinformação
Nos últimos anos, vem surgindo um grande número de tecnologias baseadas em
software livre para manipulação de dados geográficos. Esta seção visa apresentar
alguns sistemas livres e comerciais.
1. GeoServer
Consiste em um servidor web de código livre que possibilita visualização de
informações geográficas.
30
Possibilita, ainda, a edição e a publicação dessas informações espaciais
utilizando padrões abertos. Suporta diferentes protocolos OpenGIS como WFS,
WFS-T, WMS para a produção de dados geográficos em diversos formatos, sejam
matriciais, vetoriais ou para impressão, tal como PDF. Neste projeto, o Geoserver
será utilizado na exportação de dados armazenados no SGBD (Postgres) para o
dispositivo móvel e vice-versa.
2. PostgreSQL e POSTGIS
O PostgreSQL é um SGBD objeto-relacional de código aberto que começou a ser
desenvolvido em 1986 na Universidade da Califórnia em Berkeley.
Trata-se
de
um
SGBD
objeto-relacional
por
implementar,
além
das
características de um SGBD relacional, algumas características de orientação a
objetos, como herança e tipos personalizados.
Um dos pontos fortes desse SGBD é seu potencial de extensibilidade, o que
possibilitou o desenvolvimento de uma extensão geográfica mais completa,
chamada PostGIS. Este módulo foi desenvolvido pela empresa canadense
Refractions Research, segue as especificações da SFS–SQL (Simple Feature
Specifications for SQL e dota o pgSQL da capacidade de armazenamento,
manipulação e consultas sobre dados de natureza geográfica.
3.2.3.
Fontes de Dados Geográficos
No século XX, ampliou-se o desenvolvimento de mapas topográficos e
temáticos. A fotogrametria e o sensoriamento remoto permitiram o mapeamento de
amplas áreas, com elevado grau de exatidão. Surgiram os métodos matemáticos e
computacionais para o tratamento dos dados contidos nos mapas visando as
análises espacial e não-espacial. Estas técnicas de produção e análise tomaram
grande impulso com a evolução dos computadores e vêm modificando a forma de
produzir conhecimento.
31
Nesse contexto, os sistemas de informação têm um papel de suma importância
quanto ao acesso e a busca da informação, podendo ser definido segundo [15],
como: “Sistema de informação pode ser uma biblioteca, pública ou especializada;
um centro de documentação de uma empresa; um arquivo, um museu ou um banco
de dados, uma mapoteca digital. Seja qual for a sua denominação original, um
sistema de informação tem por função coletar, tratar e disseminar a informação
produzida”.
O objetivo básico da informação é ajudar na tomada de decisão, utilizando
recursos como materiais, tecnologia, equipamentos e pessoas, caracterizando
assim, a existência de um sistema de informação.
Seguem abaixo alguns dos principais órgãos e instituições responsáveis pela
produção cartográfica atual.
1. BDGEX
Segundo portaria número 034-DCT, de 17 de novembro de 2005 publicada no
Boletim do Exército n° 51, de 23 de dezembro de 2005, Banco de Dados
Geográficos do Exército (BDGEx) é o repositório do acervo de arquivos digitais de
cartas topográficas e de imagens armazenados e em condições de serem
recuperados, para atender o usuário interno do Exército. Este repositório será alvo
de testes pelo sistema em desenvolvimento neste projeto.
2. Mapoteca Digital
Com o auxílio dos sistemas de informação geográfica, o mapa passou do papel
para o meio eletrônico. Com a utilização do computador, as tarefas antes realizadas
para a confecção de mapas foram automatizadas. Esta automação possibilitou o
armazenamento, a indexação e a consulta de uma maior quantidade de mapas
servindo de fonte de informações para pesquisadores que trabalham com sistemas
de informações em imagens, universidades e instituições governamentais. Isto
possibilitou a implementação de mapotecas digitais.
32
Para Moretti[18], “Mapoteca digital é uma estrutura de armazenamento de dados
geográficos digitais criada para facilitar o gerenciamento dos arquivos, incluindo
níveis de acesso e procedimentos padronizados de checagem e atualização”.
Já Viana&Neves[31], acreditam que a mapoteca digital “é um banco de dados
composto pelos arquivos digitais de mapas, e imagens, junto com um sistema de
identificação de busca”.
Conforme Gonçalves[9], “é uma coleção não convencional de informações
geográficas dispostas em arquivos digitais de imagens e mapas”.
Semelhantes a outros sistemas geográficos, a mapoteca digital tem os seguintes
componentes:
Interface com o usuário;
Entrada e integração de dados;
Funções de procedimentos gráficos e de imagens;
Visualização e plotagem;
Armazenamento e recuperação de dados geográficos.
No Brasil existe a Mapoteca do Instituto Brasileiro de Geografia e Estatística
(IBGE).
Figura 5 - Modelo de banco de dados integrados com várias instituições transferindo dados entre si
[Adaptado de Néri[19]]
33
3. OpenStreetMap
Comunidade virtual responsável por criar e prover mapas de ruas de forma
gratuita. Seu intuito é tornar livre o acesso a mapas de regiões de qualquer parte do
mundo antes restritos a clientes de um fornecedor proprietário. Sua produção é
colaborativa permitindo qualquer um, cadastrado no sistema, a editar um mapa
fornecido pelo OpenStreetMap.
4. TrackSource
O Projeto Tracksource foi criado com o intuito de confeccionar mapas vetoriais do
Brasil, através da produção colaborativa, para uso em aparelhos GPS da Garmin. O
projeto surgiu porque os mapas fornecidos pela Garmin, no Brasil, não possuem um
detalhamento suficiente das cidades e estradas.
3.2.4.
Tecnologias de Implantação
Uma vez apresentados os tipos de estruturação de dados espaciais, os padrões
e os sistemas que os manipulam, assim como os GNSS, apresenta-se nesta seção
uma introdução e uma distinção entre tecnologias e termos consagrados para o
entendimento no desenvolvimento de sistemas para dispositivos móveis.
1. Sistemas Embarcados
É um sistema desenvolvido para desempenhar uma tarefa dedicada, na maioria
das vezes em tempo real, confinado em um hardware,. Em contraste, um PC pode
realizar múltiplas tarefas dependendo de como o aplicativo que está sendo
executado foi programado. A maioria dos dispositivos atuais é controlado por
sistemas embarcados, desde dispositivos portáteis como relógios digitais, MP3
players até semáforos e controladores industriais.
34
Para ilustrar a diferença, um computador de mão possui um sistema operacional
e microprocessadores que o alimentam. Dessa forma, não é considerado
exatamente um sistema embarcado uma vez que executa diferentes aplicativos e é
capaz de se conectar a periféricos.
2. Celular x PDA x SmartPhone
O telefone celular, ou simplesmente celular é um dispositivo eletrônico portátil
para a transmissão de voz ou dados através de uma rede de estações bases. Além
da transmissão de voz comum ao telefone convencional, a maioria dos celulares
oferecem funcionalidades adicionais como SMS para mensagens de textos, email,
comutação de pacotes para o acesso à Internet, capacidade gráfica para jogos,
comunicação Bluetooth, comunicação Wi-Fi, comunicação infra-vermelho, MMS para
troca de fotos e de vídeos.
Personal Digital Assistant (PDA) é um computador de mão que, geralmente,
possui a propriedade de touch screen para a entrada de dados através de teclado
virtual ou para a seleção de opções, tela a cores e som, o que o possibilita ser usado
também como navegador para Internet ou até como celular (caso dos smartphones).
Podem possuir teclado, cartão de memória para armazenar dados e no mínimo uma
das seguintes tecnologias para conectividade: IrDA, Bluetooth e Wi-Fi. Essas
tecnologias de conexão permitem conectar o PDA a teclados externos, receptores
GPS, impressoras e outros acessórios, bem como para a troca de informações entre
PDA’s. A presença de programas como agenda de compromissos, calendário,
agenda de contatos e algum editor de texto conferem ao dispositivo a denominação
de PDA. Uma importante função presente nos PDA’s é a sincronização de dados
com o computador pessoal. Essa funcionalidade permite a atualização de dados
para o PDA garantindo a utilização de informação como se estivesse utilizando o
PC. Do mesmo modo, garante que o backup dos dados do PDA passando-os para o
PC impedindo a perda das informações contidas no dispositivo móvel. A maioria dos
PDA’s já vêm com um programa de sincronização como é o caso dos dispositos com
sistema operacional Palm OS, os quais vêm com o HotSync e ou daqueles com
Windows Mobile, que vêm com ActiveSync. Alguns desses programas de
sincronização possuem a limitação de só sincronizarem informações de programas
proprietários, como é o caso do ActiveSync da Microsoft. Dentre alguns PDA’s
35
disponíveis atualmente no Mercado, podemos citar Black Berry,
Apple iPhone,
Apple Newton, Palm Treo, Palm Pilot, Apple iPod e HP iPAQ séries 6900 e 9000.
Um smartphone consiste em um telefone móvel que oferece recursos mais
avançados do que aqueles oferecidos por um simples telefone celular. Não há uma
definição padrão para smartphones. Uns consideram-no como um telefone com um
sistema operacional que oferece uma plataforma para desenvolvimento de
aplicativos. Outros consideram-no um telefone móvel com recursos avançados como
correio eletrênico, Internet e teclado. Segundo o vice-presidente de dispositivos
portáteis da HP, Rick Roesler, smartphones são computadores usados como
telefones também. Smartphone, com letra maiúscula no início, faz referência ao
sistema operacional.
3.2.5. Sistemas Operacionais
1. Symbian
Symbian é um sistema operacional aberto, para dispositivos móveis, com
bibliotecas, frameworks de
interface
com
usuário
e ferramentas próprias
desenvolvidos pela Symbian Ltda. Executa exclusivamente em processadores ARM.
Em 1998 a Symbian foi fundada com a intenção de explorar a convergência entre
PDA’s e celulares e era formada por quatro grandes empresas: Ericsson, Nokia,
Motorola e Psion. Em 2008, a Symbian Ltda foi adquirida integralmente pela Nokia.
Recentemente anunciaram a intenção de desenvolver programas de código livre e
de abrir o código do sistema operacional.
Symbian OS é estruturado, como alguns sistemas operacionais para Desktop,
com proteção de memória e com multitarefa preemptiva. Foi desenvolvido com base
em três objetivos: segurança e integridade dos dados do usuário, menor Kernel
possível com apenas as funções mais simples e essenciais e divisão absoluta entre
o tempo de CPU e de aplicativos. A programação em Symbian é orientada a
eventos.
36
Segundo pesquisa realizada no segundo trimestre de 2008 pela Canalys,
empresa especializada em análise de lideranças de tecnologias no mercado, o
Symbian OS lidera o mercado de sistemas para dispositivos móveis com 57.1%
seguido de RIM BlackBerry com 17.4% , da Microsoft com Windows CE e com o
Windows Mobile com 12%, do Linux OS com 7.3% e do iPhone OS, do Palm OS e
do BREW representando o restante da participação no mercado.
Todas os aplicativos que rodam no Symbian foram desenvolvidos sobre classes
definidas na arquitetura de aplicação. Essas classes definem um ambiente básico
para a execução de aplicativos. Recursos adicionais devem ser criados
independentemente e suas API’s capazes de interagir com as classes originais,
ficando a cargo dos fabricantes disponibilizarem plug-in’s para mais funcionalidades.
A programação em C++ para Symbian requer o uso de técnicas especiais como
descritores e gerenciamento de pilha, o que dificulta a implementação. É
questionável também se o paradigma de gerência de memória é benéfico. Acreditase que essas técnicas foram desenvolvidas para o mais restritivo dispositivo móvel
do século XX, aumentando desnecessariamente a complexidade de código fonte
para os dispositivos atuais. A plataforma de desenvolvimento em Symbian é voltada
para a programação em mais baixo-nível e para modelos de dispositivos móveis
antigos, tornando o trabalho mais complexo.
2. Windows CE
Oficialmente conhecido como Windows Embedded Compact é um dos sistemas
operacionais da Microsoft para computadores de bolso e para sistemas embarcados.
É
um
sistema
otimizado
para
dispositivos
que
possuem
limitações
de
armazenamento – o kernel do Windows CE pode rodar com menos de 1 MB de
memória. É um sistema baseado em tempo real com a implementação de threads,
simplificando a interface e otimizando o tempo de execução. Plataformas posteriores
foram essencialmente desenvolvidas sobre o núcleo do Windows CE, como: Pocket
PC 2000, Pocket PC 2002, Windows Mobile 2003, Windows Mobile 2003 SSE,
Windows Mobile 5.0, Windows Mobile 6, Smartphone 2002, Smartphone 2003. Uma
das vantagens do desenvolvimento para Windows CE consiste na distribuição de
37
grande parte do seu código fonte para fabricantes de dispositivos móveis de modo
que possam adaptar seus hardwares para este sistema operacional.
A plataforma baseada em Smartphone (Windows Mobile Standard) oferece
sistema operacional estável e interface para celulares. Suportam funcionalidades
como multimídia e email.
Windows Mobile 5.0 suporta USB 2.0, o que significa que o PDA comporta-se
como um pen-drive permitindo o acesso a suas informações de qualquer PC provido
de entrada USB, sem a necessidade de qualquer programa extra de sincronização.
3. Pocket PC
Trata-se de uma especificação de hardware para computadores de mão com
sistema operacional Microsoft Windows Mobile. Deve ser capaz de suportar,
também, outros sistemas operacionais como NetBSD, Linux, Android. Possui
algumas das funcionalidades dos mais modernos desktop’s, como editores de texto,
planilhas de dados, programas de email, editores de imagens, gerenciador de
memória, entre outros. Segundo a Microsoft, o Pocket PC é um dispositivo de mão
capaz de trocar e armazenar emails, contatos, agenda, executar arquivos multimídia,
jogos, editores de texto e navegar pela Internet.
Atualmente, existem vários aplicativos desenvolvidos para Pocket PC, alguns
dos quais são gratuitos. Muitos desses dispositivos incluem a funcionalidade de
telefones móveis e de receptores GPS podem, também, ser usados como leitores de
textos e como câmeras fotográficas. Dispositivos sem a funcionalidade de celular
são denominados Windows Mobile Classic ao invés de Pocket PC. Dispositivos com
celular integrado e com a propriedade de comando por toque na tela são
denominados Windows Mobile Professional.
4. Android
É um sistema operacional baseado no sistema operacional Linux e desenvolvido
pela Google e pela Open Handset Alliance, um consórcio formado por 34 empresas
de software, hardware e de telecomunicação empenhadas em desenvolver padrões
abertos
para
dispositivos
móveis.
Abrange
38
também
uma
plataforma
de
desenvolvimento possibilitando a escrita de códigos utilizando a biblioteca criada
pela Google em linguagem Java. Dessa forma, possui a limitação de não permitir a
escrita de códigos em Java ‘puro’.
Suas tecnologias para conectividade são: GSM, CDMA, UMTS, Bluetooth e WiFi. Suporta, também, API’s para troca de mensagens SMS. Seu browser é baseado
no software de código live Web Kit. Programas escritos em Java são executados
utilizando-se a máquina virtual Dalvick Virtual Machine.
Talvez por se tratar de uma plataforma muito recente, pois seu lançamento foi
em meados de 2008, são observados a existência de bugs, documentação falha,
sistema de FAQ precário e que nem todo o código(ou, as últimas releases) desta
plataforma está disponível gratuitamente.
5. Binary Runtime Enviroment for Wireless – BREW
É uma plataforma de desenvolvimento para dispositivos móveis desenvolvido
nos Estados Unidos pela Qualcomm. Recentemente, recebeu novo impulso na
Europa devido ao Skypephone terceira geração.
6. iPhone OS
Sistema operacional baseado no MAC OS X. Aplicações de terceira geração
foram originalmente desenvolvidas para este tipo de ambiente, como por exemplo,
serviços WEB que só poderiam ser acessados pelo browser nativo neste sistema.
Atualmente, entretanto, já é possível baixar aplicativos nativos deste sistema e
executá-los.
3.2.6.
Módulos de Desenvolvimento
Inicialmente conhecida como Oak, a linguagem Java foi desenvolvida pela
Sun Microsystems e com o intuito de programação para dispositivos. É notável pela
facilidade em portabilidade de aplicações quando desenvolvidas nesta linguagem.
39
Arquiteturalmente,
o
compilador
Java
transforma
a
linguagem
de
programação Java em um conjunto de bytecodes, instruções para uma máquina
abstrata de computação denominada máquina virtual (Virtual Machine – VM). A
máquina virtual Java (Java Virtual Machine – JVM) interpreta os bytecodes para
poder executar o programa. Desta forma, é tida também como um interpretador,
apesar de o código Java poder também ser compilado a partir de uma máquina de
código binário.
Dadas as limitações de processamento, de memória e de apresentação
gráfica de muitos dispositivos móveis, foram criadas especificações mais restritivas
que as da linguagem Java padrão desenvolvidas para aparelhos como celulares,
smartphones e PDA’s.
Após estudos desenvolvidos pela Sun, a linguagem foi dividida em três
edições, que são:
1. Java 2 Standard Edition – J2SE
Voltado para o desenvolvimento em aplicações Desktop convencionais e
portanto, munido dos principais recursos disponíveis para o ambiente Java como
Swing, API para interface gráfica avançada. A figura abaixo ilustra todos os recursos
do J2SE disposto em camadas.
Figura 6 - Estrutura do J2SE[27].
40
2. Java 2 Enterprise Edition – J2EE
Superconjunto do J2SE orientado a aplicações institucionais e empresariais, e
portanto, mais robustas, com ênfase no desenvolvimento de softwares que rodam
em servidores de aplicações utilizando Enterprise JavaBeans (EJBs), aplicações
WEB (servlets e Java Server Pages), CORBA e Extensible Markup Language(XML).
A figura abaixo ilustra a disposição do J2EE.
Figura 7 - Estrutura do J2EE[27].
3. Java 2 Micro Edition – J2ME
Subconjunto do J2SE orientado a dispositivos móveis que não suportam, por
motivos de restrições de memória e ou de processamento, a implementação do
J2SE completa.
Figura 8 - Estrutura do J2ME[27].
41
Cabe ressaltar que J2ME não define uma nova linguagem, apenas adapta a
tecnologia Java para dispositivos com limitações de processamento.
3.2.7.
Configurações (Configurations)
Especifica um ambiente de execução básico para J2ME. Este ambiente inclui
máquina virtual, a qual pode ser mais limitada que a utilizada pelo J2SE e
subconjuntos de API’s do Java para uma família de dispositivos com capacidades
similares.
Atualmente, duas configurações estão definidas: Connected Limited Device
Configuration (CLDC) e Connected Device Configuration (CDC). Em comum, estas
duas configurações são para dispositivos com recursos de conexão em rede.
1. Connected Limited Device Configuration – CLDC
Trata-se de um framework para aplicações desenvolvidas em Java ME
rodando em dispositivos com limitação crítica de recursos, como pagers e celulares.
Sua especificação tem origem no J2SE, sendo que várias API’s originais foram
removidas, como por exemplo java.lang.Thread.interrupted(), que notifica a
interrupção da thread corrente por outra thread e suporte a SWING, biblioteca
gráfica criada em complemento à AWT. Além disso, não possui suporte a ponto
flutuante, nem à finalização de objetos, responsável por evitar que objetos não
referenciados consumam recursos.
Figura 9 - Configuração CLDC[27]
42
No que diz respeito ao CLDC para aparelhos celulares, temos as seguintes
características:
Hardware requerido: mínimo de 160KB de memória para Java, um
processador de no mínimo 16 bits com baixo consumo (adequado a baterias típicas
de um celular) e conexão de rede (neste caso wireless – 9.6Kbps, 144Kbps ou
2Mbps).
2. Connected Device Configuration – CDC
Este é outro framework para aplicações em sistemas embarcados na
linguagem Java ME. Trata-se da especificação de um subconjunto do J2ME menos
restritivo que o CLDC com uma configuração mais completa com API’s próprias do
Java SE, com suporte a applets e a toda a AWT.
3.2.8.
Perfis (Profiles)
É uma extensão da configuração, que oferece bibliotecas específicas para
aplicações em dispositivos específicos. Serve para prover funcionalidades que não
estão presentes nas configurações. Vale ressaltar que qualquer aplicação escrita
para a configuração CLDC funcionará também em uma plataforma CDC. A diferença
entre configuração e perfil é que o primeiro descreve de forma geral uma família de
dispositivos, enquanto que o segundo é específico para um tipo particular de
aparelho em uma dada família.
1. Mobile Information Device Profile – MIDP
Trata-se de uma especificação para o uso da linguagem de programação
Java para dispositivos móveis tais como celulares e PDA’s. MIDP consiste em uma
parte da plataforma de desenvolvimento Java ME e faz parte de um conjunto de
43
interfaces de programação de baixo nível (CLDC). MIDP foi desenvolvido pela Java
Community Process nas versões MIDP 1.0 e MIDP 2.0.
O MIDP 1.0 possui várias limitações, como:
a. não possui API’s para renderização;
b. não possui suporte para acesso a imagens (pixels RGB);
c. não possui suporte para o modo de tela cheia;
d. não possui suporte para áudio;
e. a requisição a um servidor web é feita apenas por http.
Uma das vantagens de utilizá-lo é garantir a portabilidade da aplicação haja
vista a simplicidade dessa biblioteca. Algumas de suas API’s são
a. javax.microedition.io (operações de entrada/saída);
b. javax.microedition.lcdui (interface com usuário);
c. javax.microedition.rms (persistência de dados);
d. javax.microedition.Midlet (base para aplicações em Java ME).
O MIDP 2.0 introduz API’s para jogos e multimídia representando um algo
mais em implementações que o utilizam. São elas
a. javax.microedition.media;
b. javax.microedition.lcdui.game;
c. javax.microedition.pki (para conexões seguras).
Existem ainda outras API’s que não são implementadas pelo MIDP 1.0 nem
pelo MIDP 2.0, mas que garantem funcionalidades extras aos dispositivos, como:
a. javax.microedition.messaging (para mensagens SMS e MMS);
b. javax.microedition.pim (para acesso a informações pessoais de
PDA’s, como a agenda, por exemplo);
c. javax.microedition.io.File (para acesso a arquivos do PDA).
44
2. Foundation Profiles
Perfil base para dispositivos em rede sem recursos de interface com usuário
sobre CDC.
3. Personal Basis Profiles
Oferece suporte a gráficos e RMI (Remote Method Invocation) para
dispositivos CDC e Foundation.
A figura abaixo ilustra a disposição da arquitetura J2ME em camadas
hierárquicas representando os recursos oferecidos por cada nível. A parte circulada
mostra o ambiente utilizado neste projeto, a dizer:
1. Configuração: CLDC 1.1
2. Perfil: MIDP 2.0
Figura 10 - Estrutura de JVM, Configurações e Perfis no J2ME[4]
Simplificando, toda aplicação Java desenvolvida para dispositivos móveis
conectáveis possui uma configuração base: a CLDC e a CDC. A primeira serve para
dispositivos com grandes limitações de armazenamento (até 160KB de memória não
45
volátil – RAM e 512 KB de memória volátil – ROM), de processamento, gráficas e de
conexão de pequena largura de banda. Exemplos de dispositivos com configuração
CLDC são os celulares e smartphones. Sobre a CLDC, podem-se aplicar perfis
como o MIDP para acrescentar funcionalidades através de API’s implementadas por
eles oferecendo assim, um ambiente de desenvolvimento mais completo.
•
O perfil MIDP existe até a versão 2.1 e serve somente para a configuração
CLDC. A configuração CDC foi desenvolvida para dispositivos mais robustos:
CPU de 32 bits, 2MB RAM, 2.5MB ROM, rede confiável e de desempenho
razoável, mas que ainda assim possuem restrições de memória, processamento
e outros. Sobre o CDC podem-se aplicar outros tipos de perfis que não o MIDP,
quais sejam: Personal, Personal Basis ou Foundation. A figura abaixo ilustra a
disposição das duas configurações e seus perfis.
Figura 11 - Plataforma JavaME com suas configurações, perfis e API's[4].
46
3.2.9.
Máquinas Virtuais
Consiste em um software que executa programas como se um computador
fosse. Foi definido por Goldberg como uma eficiente e independente duplicata de
uma máquina real. É responsável por prover serviços ao programa que está sendo
executado em seu ambiente de execução, atuando como um sistema operacional ou
hardware para os quais o programa havia sido escrito. A característica essencial de
uma máquina virtual é que o software rodando nela está limitado aos recursos e às
abstrações providos por ela.
Máquinas virtuais separam-se em dois grupos, de acordo com seus usos e
com seus níveis de abstração a uma máquina real: máquina virtual de sistema e
máquina virtual de processo. A máquina virtual de sistema provê uma plataforma de
sistema completa suportando, portanto, a execução de um sistema operacional. Este
tipo de máquina permite compartilhar os recursos da máquina física para várias
máquinas virtuais, cada uma rodando seu próprio sistema operacional. Em
contrapartida, a máquina virtual de processo dedica-se à execução de um programa,
ou seja, um único processo. Seu principal propósito é criar um ambiente de
desenvolvimento independente de plataforma, abstraindo detalhes de hardware e de
sistema operacional e permitindo que programas executem da mesma maneira em
qualquer plataforma. Esse tipo de MV se tornou popular com a linguagem de
programação Java, a qual é implementada usando a máquina virtual Java. Outro
exemplo é o da framework .NET que utiliza a MV chamada Common Language
Runtime.
1. CrE-ME
Desenvolvida pela NSicom, trata-se de uma máquina virtual Java para
dispositivos com Windows CE. Ela provê a implementação do CDC e é reconhecida
como a máquina mais rápida para dispositivos com Windows Mobile e com
requisição moderada de recursos. Mais informações disponíveis em [12].
47
2. JeodeRuntimeTM
Desenvolvida pela Insígnia Solutions pode ser instalada, utilizada ou copiada
quando de acordo com os termos de licença. Segue as especificações do
PersonalJava 1.2 da Sun, voltada para aparelhos com configuração CDC. Pode ser
utilizada tanto para applets Java em Web Pages quanto para aplicações Java em
Pocket PC’s.
3. Kilobyte Virtual Machine – KVM
Consiste de uma máquina virtual desenvolvida pela Sun em linguagem C para
dispositivos móveis. É derivada da JVM, possuindo um subconjunto de seus
recursos. CLDC especifica o uso da KVM. O ‘K’ de KVM é um acrônimo de Kilobyte,
significando que ela roda em kilobytes de memória.
Figura 12 - Máquina virtual[27]
48
4. Metodologia
Linguagem de Programação: Java ME
Escolha motivada, principalmente, pela concepção de portabilidade que envolve
o desenvolvimento Java. Isto se deve ao fato de o compilador Java não gerar
instruções específicas a uma plataforma operacional. Gera-se um programa em
código intermediário pelo compilador Java, denominado bytecode, que pode ser
descrito como uma linguagem de máquina destinada a um interpretador de
bytecodes, a Java Virtual Machine – JVM, a qual emula um processador. Portanto,
torna-se necessário possuir uma JVM instalada para o sistema proposto executar,
independentemente do sistema operacional utilizado no dispositivo. Destaca-se,
também, o fato de esta ser uma linguagem que não necessita de licença para o seu
uso, seu compilador ser livremente disponibilizado, a máquina virtual ser também
disponibilizada
gratuitamente,
e
não
menos
importante,
a
plataforma
de
desenvolvimento ser livre.
Configuração: CLDC 1.1 MIDP 2.0
Essa escolha se deve ao fato de os dispositivos com essa configuração terem
processamento suficiente mínimo para executar uma aplicação de navegação, bem
como possuem as especificações necessárias para o desenvolvimento da aplicação,
como a JSR’s Location e Scalability Vetorial Graphic.
4.1.
Equipamentos
A escolha por um celular, do tipo smartphone, se justifica por ser um
equipamento portátil, compacto, com poder de processamento, inclusive gráfico, de
custo relativamente baixo e de fáceis aquisição e disponibilidade no comércio. Além
49
disso, permite a conexão com receptores GPS via cabo ou rede sem fio (bluetooth),
existindo até smartphones e PDAs com receptores embutidos.
Dentre os equipamentos disponíveis no mercado, trabalhou-se com dispositivos
que reunissem os requisitos necessários, tanto em armazenamento quanto em
processamento, que possibilitassem o desenvolvimento em Java e que possuíssem
um sistema operacional largamente utilizado, como o Windows Mobile e o Symbian.
Os equipamentos utilizados foram:
1. Nokia N95 – escolha baseada nos requisitos de configuração mínima do
sistema
2. Nokia E71 – escolha baseada nos requisitos de configuração mínima do
sistema
3. HP6945 – desenvolvimento voltado para celulares e PDA’s
4. Garmin CS – utilizado na fase de ambientação
4.2.
Softwares
1. Wireless Tool Kit 2.5.2 – emulador Sun
2. Eclipse + Plugin Eclipse ME – Plataforma OpenSource de desenvolvimento
Java com módulo para Java ME
3. Geoserver – Servidor de mapas OpenSource
4. Jeode RunTime – máquina virtual para Pocket PC
5. Postgres + PostGIS – Banco de dados com módulo para objetos geográficos
6. S60 3rd Edition SDK Feature Pack 2 – emulador Nokia
7. Apache TomCat 5.5 – servlet container, utilizado para o funcionamento do
servidor para o envio de coordenadas e para o chat.
50
A escolha dos softwares supra-listados se deve, fundamentalmente, por serem
livres, não havendo a cobrança por licenças. Ainda assim, buscaram-se nessa
escolha aqueles que fossem robustos, estáveis e de comprovada aceitação técnica.
A escolha pelo GeoServer se deu, principalmente, por ser escrito em Java e
possuir documentação disponível, o que facilita sua configuração. Além disso,
possui mais funcionalidades que seu principal concorrente, o MapServer, como por
exemplo, o WFS-Transacional, que permite a realização de inserções, atualização e
exclusão de feições.
A escolha pelo Postgres se deve pela disponibilidade do módulo PostGIS, o qual
implementa as recomendações do padrão OpenGIS para a interoperabilidade de
mapas.
Dentre os softwares utilizados, aquele que não se adequou aos nossos testes foi
a máquina virtual Jeode, utilizada no HP6945. Como essa máquina não possui as
principais JSRs que utilizamos no sistema, como a JSR179 e a JSR226, a utilização
de PDAs ficou comprometida no projeto.
Pesquisaram-se outras máquinas
disponíveis, mas a grande maioria necessita da aquisição de licenças. Dentre elas
destacam-se a CrEme, J9 e Kaffe.
4.3.
JSR’s
Seguem-se as principais especificações Java utilizadas, sobretudo, com o intuito
de acelerar o desenvolvimento do sistema e de focar em soluções para a arquitetura
do sistema.
1. JSR266 – Scalable Vetorial Graphics: especifica métodos que manipulam o
arquivo vetorial svg conferindo maior rapidez ao desenvolvimento
2. JSR179 – Location: especifica métodos necessários na comunicação entre o
dispositivo móvel e o receptor GPS para a obtenção das coordenadas
geográficas.
51
4.4.
Desenvolvimento do Software
Utilizou-se, no desenvolvimento deste sistema, arquitetura modular visando a
maior facilidade de manutenção, bem como, a evolução do sistema com o acréscimo
ou, até mesmo, a substituição de funcionalidades.
À evolução deste sistema, destacam-se a obtenção de coordenadas sem o uso
de GPS (como, por exemplo, o posicionamento por rede de celular, por rede sem fio
ou por RFID), a inclusão de operadoresespaciais, a possibilidade de navegação
sobre cartas em formato matricial e a correção DGPS em tempo real. Dentre os
principais módulos implementados, destacam-se a exibição do mapa, a obtenção de
coordenadas e a manipulação de mapas.
4.4.1.
Exibição do mapa
Utilizaram-se as especificações da JSR226 para a implementação da exibição
de mapas vetoriais no dispositivo. Encontrou-se a limitação de 17.600 vértices.
O construtor abaixo é o responsável por instanciar um objeto do tipo
SVGImage com o svg passado pelo usuário através da variável path. O método
paint é responsável por renderizar na tela o mapa agora instanciado, como mostra a
figura 16.
Figura 13 - Classe responsável pela exibição do mapa svg
52
Figura 14 - Método responsável por desenhar o mapa na tela
4.4.2.
Recepção de coordenadas do receptor
Realizada através de métodos especificados pela JSR179, como mostrado no
código abaixo. Inicialmente, especifica-se a precisão requerida pelo usuário para o
datum horizontal (latitude e longitude). Outras restrições podem ser feitas ao
receptor como, por exemplo, a de ser um receptor com baixo consumo de bateria,
ou ainda, que seja livre de tarifas.
Em seguida, instancia-se um objeto do tipo LocationProvider, o qual fornecerá
um receptor, conectado ao celular, com as características determinadas pelo objeto
Criteria.
Se houver mais de um receptor com as mesmas características, o
LocationProvider selecionará o primeiro da lista de receptores. Feita a seleção do
receptor que transmitirá as coordenadas segundo os critérios estabelecidos de
precisão, instancia-se um objeto do tipo Coordinates, responsável por armazenar as
coordenadas transmitidas pelo receptor.
53
Figura 15 - Coordenadas do receptor
Figura 16 - Instanciação de um receptor e obtenção de coordenadas
54
4.4.3.
Manipulação de mapas SVG
Seguem-se algumas das funcionalidades do sistema quanto à manipulação dos
arquivos SVG em tempo de execução.
Arraste, zoom e rotação
Essas três funcionalidades envolvem a edição, em tempo de execução, do
arquivo svg que descreve o mapa. Utilizam-se funções de manipulação de arquivos
xml, disponibilizadas no JavaME pelo pacote org.w3c.dom.svg.*.
Através de uma instância do mapa em questão, utilza-se a função getDocument()
para armazenar em uma variável do tipo Document o xml referente ao mapa. Todas
as alterações no svg serão feitas por esta variável Document. Ela oferece acesso a
todas as tags do xml.
E, uma vez acessando cada elemento do arquivo, seus atributos podem ser
modificados em tempo de execução. Para a rotação, o zoom e o arraste, utilizaramse, respectivamente, as funções setCurrentRotate(float), setCurrentScale(float) e
setX(float) ou setY(float), dependendo da direção de arraste.
55
Figura 17 - Rotação
Figura 18 - Zoom
56
Figura 19 - Arraste do mapa
O método da figura 23 realiza o tratamento de interações entre o usuário e as
teclas do dispositivo móvel. As teclas direcionais identificadas pelo Keycode -1, -2, 3 e -4 fazem o arraste do mapa nas direções norte, sul, leste e oeste,
respectivamente, através dos métodos setX(float) e setY(float).
A tecla ‘*’ invoca o método responsável pela seleção das feições. As teclas ‘2’ e
‘8’ realizam o zoom in out, respectivamente. Já a tecla ‘0’ faz a seleção de layers.
57
Figura 20 - Métodos de tratamento de interações com o usuário
58
Plotar ponto recebido do GPS
Figura 21 - Localizacao Atual
O método da figura 25 é responsável por criar um elemento dentro do arquivo
svg em tempo de execução. Inicialmente, instancia-se um objeto do tipo Document
que receberá o arquivo svg instanciado no método MapCanvas, visto anteriormente,
e armazenado na variável svgMap. O tipo SVGSVGElement representa o corpo do
svg onde estão declarados todas as feições.
Cada feição possui um identificador único. No exemplo abaixo, o elemento criado
consiste em um círculo usado para a representação das coordenadas oriundas do
receptor GPS. Para não criar vários círculos sobrepostos, utilizou-se a variárel
firstCall para que o círculo seja criado no svg uma única vez e que depois tenha
apenas atualizadas as coordenadas do seu centro (cx,cy) de acordo com os valores
passados pelo receptor GPS. A atualização do centro do círculo ocorre com a
utilização
do
método
getElementById(String),
59
implementado
pela
JSR226,
responsável por encontrar o elemento “circle” dentro do arquivo svg. Em seguida, os
métodos setFloatTrait(String, float) realiza a atualização da propriedade “cx” do
elemento “circle” do svg.
Figura 22 - Plotagem do ponto referente às coordenadas do receptor
Seleção de feições
O método da figura 26 é o responsável pela seleção de feições do mapa. Da
mesma forma que nos métodos anteriores, inicialmente carrega-se o svg numa
variável Document e, em seguida, acessa-se o conteúdo do svg através do
getDocumentElement(), fornecido pela JSR226.
A solução adotada foi percorrer todas as feições do svg iterativamente
incrementando-se
o
valor
do
identificador
passado
como
parâmetro
em
getElementById(). Uma vez instanciado o SVGElement “text” com determinado
identificador,
apenas
altera-se
a
cor
dessa
feição
através
do
método
setRGBColorTrait(String, Color), também especificado na JSR226. O ideal seria que
o usuário selecionasse a feição desejada através do cursor de tela, mas esse tipo de
60
solução só foi encontrada para svg’s para Desktop, que são visualizados em
browsers e que, portanto, podem utilizar comandos em JavaScript.
Figura 23 - Seleção de feições
Figura 24 - Seleção de feição
61
Ainda no método changeFeature(), ocorre a renderização da tabela de atributos
com os valores referentes à feição selecionada.
Faz-se através do método
getTrait(String) em que passa-se como parâmetro o identificador da variável
SVGElement, no caso, “text” precedido por ‘#’. Esse método acessa os atributos
associados com a feição selecionada do svg. Em seguida, insere-se o atributo na
tabela de atributos.
Figura 25 - Seleção de feição e representação de atributos na tabela
A classe JMTable, responsável pela implementação da tabela de atributos,
estende a classe CustomItem responsável por criar elementos customizados. A
construção da tabela foi toda desenvolvida com métodos primitivos, como o
drawLine(), e renderizada sobre o canvas, que consiste em uma tela gráfica em
branco.
62
Exibição de vários layers (selecionável)
Figura 26 - Seleção de layers
O método da figura 30 é responsável por selecionar determinada layer do mapa.
Faz-se iterativamente, percorrendo-se todos os identificadores de todas as layers do
mapa, e apenas altera-se a propriedade “stroke” da feição para “none”. Isso torna
um layer oculta em tempo de execução, mas não a exclui em definitivo. Tal layer
continua fazendo parte do svg, apenas o contorno da feição fica oculta ao usuário.
63
Figura 27 - Seleção de layer
Tracklog
Utiliza a mesma idéia do item anterior, exceto que não há a atualização do
mesmo objeto no arquivo svg, mas a inserção de vários outros novos pontos
simulando o caminho percorrido. Atualmente, as coordenadas do tracklog são
armazenadas no sistema de arquivos do celular utilizando-se o próprio registro de
arquivos do celular, o Record Management Store – RMS. Entretanto, busca-se uma
solução em que o tracklog seja salvo diretamente em um arquivo com formato svg, o
que facilitará o intercâmbio de informações entre o dispositivo móvel e a base de
dados no Desktop.
64
Figura 28 - Tracklog
O método da fogira 32 é semelhante ao método editSVG(), apresentado
anteriormente,
exceto que a cada nova coordenada recebida, cria-se um novo
círculo no conteúdo do svg, simulando-se o caminho percorrido.
Figura 29 - Tracklog
65
Acesso ao sistema de arquivos
Utiliza a JSR75, FileConnection, responsável pelo acesso ao sistema de arquivos
do celular. Esta JSR é nativa a todas as configurações do JavaME, desde às mais
limitadas, e portanto, sua implementação é válida em todos os celulares com
máquina virtual java.
Figura 30 - Acesso ao sistema de arquivos
4.4.4.
Integração de todas as funcionalidades
A figura 34 ilustra a arquitetura do sistema desde a fase de obtenção do mapa
em Desktop, sua posterior conversão para svg e sua transferência ao celular através
de um cabo, cartão SD ou conexão bluetooth. Os mapas que alimentam o sistema
66
são obtidos de um repositório de mapas em conformidade com o padrão OpenGis.
Tal escolha deixa não elimina a dependência a mapas em formato proprietário e
favorece a interoperabilidade de informações entre outros sistemas que também
adotem o padrão OpenGis.
Inicialmente, utilizou-se o servidor de mapas Geoserver para a aquisição dos
mapas. Entrava-se com o shapefile do mapa e o servidor retornava o svg
correspondente. Entretanto, todos os atributos do mapa eram perdidos quando da
conversão pelo Geoserver. Como o foco do trabalho não é a conversão de formatos
de mapas, mas sim o desenvolvimento de um sistema de navegação, utilizou-se
outra solução. A partir de um conversor de terceiros, livre e disponível em [3], fez-se
a conversão do shapefile para o svg com todos os atributos inclusos.
Embora o svg gerado tenha sido visualizado corretamente em browsers, o
mesmo não apresenta o padrão que as rotinas da JSR226 do JavaME conseguem
interpretar. Dessa forma, fez-se um conversor próprio para que o mapa fosse
visualizado nos aparelhos portáteis também. Por isso, a figura mostra a seta do BG
Geográfico, que representa o Geoserver, em cor de destaque como sugestão para
trabalho futuro.
Ao final da figura, ilustra-se o sistema propriamente dito, o qual está
implementado num dispositivo móvel conectado a um receptor GPS para a obtenção
das coordenadas.
67
Figura 31 - Arquitetura do sistema
4.5.
Extras
Apresentam-se nesta seção algumas funcionalidades que a priori não fazem
parte dos objetivos do projeto, mas que constituem pontos de verificação das
potencialidades do JavaME. Nesse sentido, implementaram-se funcionalidades
peculiares a um usuário de um sistema de navegação, como o envio de
coordenadas para um servidor, a integração com o GoogleMap, possibilitando a
utilização de mapas em formato de imagens e o chat, o qual explora o intercâmbio
de informações em tempo real entre os usuários.
4.5.1.
Envio das coordenadas para o servidor
Ocorre através do protocolo HTTP, uma vez que ele existe em todos os celulares
atuais. Ao selecionar ‘Enviar Coordenadas’, o sistema solicita a entrada do endereço
68
do servidor para o qual enviará as coordenadas. Este endereço consiste no
endereço IP do servidor, o número da porta onde foi instalado o servlet container e o
caminho da lógica da aplicação (http://EndereçoIP:Porta/servlet/EnviaCoordenadas).
O servlet utilizado foi escrito em Java e consiste na lógica de funcionamento do
envio de coordenadas. É a responsável por receber requisições dos dispositivos
móveis e fazer o tratamento seguindo a lógica implementada. Esse servlet fica
armazenado em um repositório, que é o servlet container. Utilizou-se neste projeto o
TomCat 5.5, servidor OpenSource, de propriedade da Apache Foundation.
Embora
a
solução
implementada
ao
envio
de
coordenadas
requeira
disponibilidade de conexão via HTTP, existe a possibilidade de se utilizar outras
tecnologias de envio, como, por exemplo, por conexão GPRS, através de redes de
celulares. Apesar de não implementada, essa solução faz parte de trabalhos futuros
ao projeto como forma de eliminar a necessidade de conexão à internet. Destaca-se
como positivo à sua adoção, a grande disseminação de redes de celulares,
atualmente abrangendo mais localidades que a rede IP.
Figura 32 - Envio de coordenadas para o servidor
69
4.5.2. Chat
Seu funcionamento consiste em um servlet, que possui a função de um servidor,
de receber e tratar requisições, implementada em Desktop. Existe uma variável que
armazena, em uma lista do tipo String, todas as conversas dos usuários. Qualquer
acesso ao servlet, através do servidor, retorna essa lista de conversas simulando
assim um chat.
O servidor utilizado foi o Apache TomCat 5.5 o qual funciona como um
armazenador de servlets. O acesso à servlet implementada é feita através do
endereço http://EndereçoIP:Porta/servlet/IMEChat , onde EndereçoIP é o endereço
IP da máquina do servidor, porta é o local onde o TomCat foi instalado, geralmente
na porta 8080, e /servlet/IMEChat é o caminho que acessa a lógica do Chat.
Figura 33 - Chat
4.5.3. Integração com Google Map
70
Nesse caso, envia-se uma requisição ao servidor da Google com os valores
lat/long recebidos pelo receptor GPS através do módulo implementado com a
JSR179 para localização e aquele servidor responde com uma imagem raster do
local correspondente.
Figura 34 - Integração com Google Map
O método abaixo obtém o mapa a partir de uma requisição aos servidores da
Google passando como parâmetros a latitude e a longitude recebidos da antena
GPS. A passagem desses parâmetros ocorre através da chamada ao método
mapaHttp(String).
71
Figura 23 - Integração com Google Map
A requisição http é da forma :
Figura 24 - Requisição Http
72
5. Conclusões
Neste trabalho pode-se concluir que a linguagem JavaME representa um passo
significativo para desenvolvimento em dispositivos portáteis. Ela consegue agregar o
paradigma de programação orientado a objeto aos recursos limitados desses
dispositivos.
Apesar disso, ainda há um conjunto de particularidades que dificultam o
desenvolvimento em JavaME. As principais delas são as diferenças de recursos
existentes nos dispositivos atuais, o que dificulta a portabilidade de um sistema para
vários dispositivos, e a grande quantidade de máquinas virtuais existentes com a
falta de uniformidade entre elas.
As JSRs existentes fornecem mecanismo para se implementar métodos de
manipulação de SVG. Isto possibilitou o desenvolvimento das funcionalidades do
sistema que permitem o manuseio do SVG, como rotação, translação, seleção de
feição e arraste.
A utilização do GeoServer para gerar o SVG não foi satisfatória, pois o SVG
gerado não apresentava o formato esperado para manipulação de atributos com as
bibliotecas do JavaME. Tal problema foi contornado utilizando-se o Parser
implementado para obter os atributos do SVG manipuláveis. Este Parser consiste
em um programa escrito em Java que manipula o SVG gerado pelo Geoserver para
que ele contenha os atributos que identifiquem as feições do mapa, conforme
explica o Anexo D.
A captura da posição pelo GPS foi bem sucedida, apresentando o erro dentro do
esperado para esta técnica de posicionamento. A restrição de utilização de
coordenadas Geodésicas em WGS84 não inviabilizou o uso dos mapas existentes
em outros sistemas. Exige-se sua conversão prévia para o referido sistema de
coordenadas.
73
As funcionalidades de manipulação do SVG, como arraste, zoom, rotação e
seleção de feições foram implementadas com êxito. O uso destas funcionalidades
tornam o sistema próximo do encontrado em outros de natureza comercial, como é o
caso da rotação e do arraste, ao mesmo tempo que permite a obtenção de
informações de atributos de feições do mapa.
Por fim, a Interface gráfica desenvolvida atende aos objetivos iniciais do sistema,
quando visto sob a ótica de uma prova de conceito (com possibilidades de evolução,
conforme sugerido na seção Trabalhos Futuros), pois possui um layout simples de
fácil usabilidade. A dificuldade aparece na medida em que se deseja acrescentar
mais funcionalidades ao sistema. Para isso, deve-se pesar o que se deseja acessar
facilmente e o quanto de área livre para exibição se deseja ter na tela.
74
6. Trabalhos Futuros
Atualmente, diversas funcionalidades podem agregar valor a um sistema de
posicionamento. Algumas delas com aplicação tanto no meio militar quanto no meio
civil. Por exemplo, saber quais caminhos percorrer para ir de um ponto a outro é
importante tanto em manobras militares quanto no uso cotidiano. Isso torna o
roteamento uma funcionalidade valiosa em sistemas de posicionamento.
Pode-se incluir essa funcionalidade utilizando-se as feições como objetos de
roteamento. Para tanto deve-se construir no svg uma lista de adjacências, estrutura
de dados básica para algoritmos de roteamento. Nela, cada feição é formada por um
conjunto de vértices, em que cada um deles possui uma lista de seus vizinhos.
Dessa maneira, podem-se saber quais as feições são vizinhas de uma outra
qualquer.
Com a lista de adjacências construída, pode-se utilizar um dos algoritmos de
roteamento conhecido para se encontrar o menor caminho entre duas feições do
mapa. Algoritmos com essa capacidade podem ser: Dijkstra, Bellman-Ford.e FloydWarshall. Tais algoritmos permitem adotar pesos a cada uma das arestas do grafo.
Isso agrega a funcionalidade de permitir escolher o menor caminho entre duas
feições levando-se em conta diversos critérios. A importância desse recurso pode
ser visualizada no processo de deslocamento de uma tropa, onde deseja-se
escolher o caminho com menor quantidade de tropas inimigas, ou um caminho na
cidade com pouco congestionamento.
O sistema de funcionamento pode ter sua capacidade de uso ampliada
tornando-o independente do GPS. Hoje, o número de aparelhos celulares com
dispositivo GPS ainda é pequeno, mesmo que tenha se tornado comum em
aparelhos novos de alto custo. Além disso, o consumo de energia decorrente do uso
do GPS nesses aparelhos reduz sua autonomia em termos de tempo. Pesquisas
revelam[26] que no uso cotidiano, o tempo que os usuários possuem cobertura GPS
75
representa uma parcela mínima do dia, dada a exigência do sistema por uma visada
direta do céu.
Sendo assim, uma tecnologia de posicionamento do dispositivo de modo
independente do GPS se torna desejável em paralelo a este. Essa independência
pode ser conseguida utilizando-se outro sistema emissor de ondas, tais como redes
WiFi e da rede de telefonia móvel GSM, dentre outros. O método se baseia na
triangulação do dispositivo com bases, no tempo de resposta entre as bases e o alvo
ou pela comparação das fontes de sinais, a partir de suas respectivas intensidades,
com uma base de dados georreferenciada levantada previamente[26]. Desse modo,
sabendo-se a posição das bases, pode-se estimar a posição do dispositivo.Tal
funcionalidade permitiria o posicionamento do sistema independente do GPS, e
ainda possibilitaria o uso do mesmo em locais fechados, onde não se consegue
obter os sinais do sátelite para localização via GPS.
Atualmente existem diferentes tipos de mapas empregados nos diversos
sistemas de posicionamento. O sistema oferece suporte apenas ao padrão
OpenGIS. Isso é uma limitação, uma vez que algumas regiões estão mapeadas em
outros padrões de arquivos como KML, utilizado pelo Google, mapas para uso em
receptores GPS de navegação, DGN, empregado por órgãos oficiais da cartografia
nacional – IBGE e DSG ou shapefiles, utilizado, sobretudo, em empresas da área de
cartografia.
Um ponto importante para uma melhor usabilidade do sistema é tornar a
interface mais intuitiva para o usuário. Isso impacta diretamente na aceitação do
sistema, uma vez que interfaces pouco intuitivas deixam o usuário confuso e dificulta
a utilização de todas as fucionalidades do sistema. O desafio encontra-se em extrair
o máximo proveito dos recursos limitados de um dispositivo portátil e tornar seu uso
mais intuitivo. Esses dispositivos possuem recursos gráficos limitados, e em
conjunto com a dimensão da tela, tornam o trabalho da elaboração da interface mais
criterioso, para que as funcionalidades possam ser acessadas facilmente.
Em resumo, sugere-se o desenvolvimento das seguintes funcionalidades:
76
Implementação de acesso ao protocolo n-Trip[21], através de conexão http, a
fim de possibilitar o uso do DGPS[5] ao sistema, aumentando a precisão final
obtida no posicionamento em tempo real;
Obtenção de coordenadas a partir de outros emissores de Rádio Freqüência
(rede Wi-Fi, redes de telefonia celular, RFID, bluetooth, entre outros), a fim de
criar sistemas de posicionamento independentes do GPS;
Levantar os requisitos para o desenvolvimento de interfaces mais intuitivas e
fáceis de usar para uso em dispositivos com telas de dimensões reduzidas e
com processamento gráfico limitado;
Desenvolver rotinas para a conversão dos principais arquivos de mapas
digitais vetoriais para o padrão empregado no atual sistema;
Permitir o uso de cartas digitais em formato matricial georreferenciado ou não
e o seu georreferenciamento no próprio dispositivo móvel;
Adicionar operadores espaciais básicos, tais como consulta a feições por
suas relações topológicas, operadores de álgebra de mapas e ferramentas de
análise espacial e de roteamento, além da possibilidade de configuração do
sistema de coordenadas e de projeção desejados e a conseqüente
necessidade de funções de conversão de sistemas;
Possibilitar anexar arquivos de multimídia georreferenciados a mapas no
dispositivo;
Visualização de mapas digitais tridimensionais;
Edição do arquivo de mapa corrente no dispositivo (atualmente em formato
SVG) para a introdução, em campo, de feições e de atributos para fins de
atualização cartográfica e para o emprego como ferramenta de reambulação
(vertente civil da produção cartográfica) ou de reconhecimento (vertente de
emprego militar);
Demais aplicações que possam empregar ferramentas desenvolvidas neste
projeto.
77
7. Referências Bibliográficas
[1]CÂMARA, Gilberto; et al. Análise espacial e geoprocessamento. Disponível
em:<http://www.dpi.inep.br/gilberto/livro/analise/cap.1-intro-pdf>. Acesso em: 10 jun.
2008.
[2]Carto:Net. Cartographers on the net. Disponível em <http://www.carto.net>.
Acesso em 13 out 2008.
[3]COELHO, Pedro Alexandre. Programação em Java 2 (SDK 1.4 - J2SE - J2EE J2ME) - Curso Completo. ISBN. 9727223
[4]DevMedia
Disponível
em:
http://www.devmedia.com.br/articles/viewcomp_
forprint.asp?comp=8585. Acesso em 12 fev 2009.
[5]DGPS
–
Differential
GPS
Explained.
Disponível
em
<http://
http://www.esri.com/news/arcuser/0103/differential1of2.html>. Acesso em 10 out
2009.
[6]ESRI, 2000a, Managing ArcSDE Services, Redlands, C.A., ESRI.
[7]ESRI, 2000b, Modelling Our World : The ESRI Guide to Geodatabase Design,
Redlands, CA.
[8]ESRI, 2005, Raster Data in ArcSDE, Redlands, U.S.A., ESRI
[9]GONÇALVES, Nelson Veiga. Modelo de recuperação de informações temática
interrelacionadas, contidas em imagens de satélites, baseado em descritores
contextuais. 2001. 220f.
Tese (Doutorado em Ciência da Informação). Universidade de Brasiléia; DF, 2001.
[10]GEOSERVER PROJECT. Disponível em: <http://geoserver.org>. Acesso em 08
fev 2008.
[11]GOOGLETM. Disponível em: <http://www.google.com.br>
78
[12]GOOGLE MAPS. Disponível em: <http://maps.google.com>
[13]INSTITUTO NACIONAL DE PESQUISAS ESPACIAIS – INPE. Disponível em:<
http://www.inpe.br/index.php>. Acesso em: 10 jun 2008.
[14]INTERGRAPH. Disponível em <http://www.intergraph.com>.
[15]INTERNATIONAL ORGANIZATION FOR STANDARDIZATION – ISO. Disponível
em <http://www.iso.com>.
[16] Leick, Alfred (1995). “GPS Satellite Surveying”. Second edition. John Willey &
Sons, Inc New York. Leick, Alfred (2004).
[17]LIMA, V.M.A. Terminologia, comunicação e representação documentária.
1998. 135f. Dissertação (Mestrado em Comunicação e Artes) – Universidade
Federal de São Paulo, 1998.
[18]MORETTI,
Edmar.
Apostila
Arcview.
Disponível
em:
<http://www.planeta.terra.com.br/informatica/edmarmoretti/
apostilaarcview/index.htm> Acesso em: 20 out 2005.
[19]MUCHOW, J. W. Core J2me: Tecnologia e Midp
[20]NERI,
Sara
Heloisa
Alberto.
A
utilização
das
ferramentas
de
geoprocessamento para identificação de comunidades expostas a hepatite A
nas áreas de ressacas dos municípios de Macapá e Santana/AP. 2004. 137f.
Dissertação (mestrado em engenharia civil). Universidade Federal do Rio de Janeiro,
2004.
[21]NTRIP Casters – Real Time GPS Data. Disponível em <http://www.ntrip.org>.
Acesso em 20 jul 2009.
[22]NSicom CrE-ME VM. Disponível em: <http://www.nsicom.com/Default.aspx
?tabid=138>. Acesso em 10 jan 2009.
[23]OpenDGN. Disponível em:<http://www.opengeospatial.org/ogc>. Acesso em 8
jan 2009.
79
[24]Open
Geospatial
Consortium.
Disponível
em:
<http://www.opengeospatial.org/ogc>. Acesso em 8 jan 2009.
[25]PAREDES, Evaristo Atencio. Sistema de informação geográfica. São Paulo:
Érica, 1994.
[26]PLACE LAB. Disponível em: <http://www.placelab.org/>. Acesso em 24 jun 2009.
[27]Java Sun MicroSystems. Disponível em: http://java.sun.com. Acesso em 8 jan
2009.
[28] THOMÉ, Rogério. Interoperabilidade em geoprocessamento: conversão entre
modelos conceituais de sistemas de informação geográfica e comparação com o
padrão Open Gis. 1998.193f. Dissertação (Mestrado em Computação Aplicada) –
Ministério da Ciência e Tecnologia, Instituto Nacional de Pesquisa Espaciais – INPE,
São José dos Campos, 1998.
[29]Tutorial sobre Bancos de. Dados Geográficos. GeoBrasil 2006. Instrutores:.
Gilberto
Ribeiro
Queiroz.
Karine
Reis
Ferreira
Disponível
em:
<
http://
www.dpi.inpe.br/TutorialBdGeo_GeoBrasil2006.pdf >. Acesso em: 10 fev 2009.
[30]Tutorial
J2ME
Autor:
Java
Sun
Disponível
em:
<http://java.sun.com/javame/index.jsp >. Acesso em: 10 fev 2009.
[31]VIANNA, Pedro Costa Guedes; NEVES, Arinaldo Inácio das. Mapoteca Digital
Humboldt. Scripta Nova. Revista Eletrônica de Geografia y Ciências Sociales.
Barcelona, v. 8, n. 170, 01 agos. 2004. Disponível em: <http://www.ub.es./geocrit/sn170-64/htm>. Acesso em: 24 jan 2009.
[32]VINHAS, L. F., K. R. , 2005. Descrição da TerraLib. In: CASANOVA, M. A. C., G.;
DAVIS JR., C. A.; VINHAS, L.; QUEIROZ, G. R., ed., Bancos de Dados
Geográficos: Curitiba, Editora MundoGeo, p. 397-439.
[33]Wells ,Martin J. Java Me Game Programming, 2nd Edition
[34]W3C.
A
little
history
of
the
World
Wide
Web.
http://www.w3.org/History.html.
[35]POSTGIS [on-line]. 2007. Disponível: <http://postgis.refractions.net/
80
2005.
documentation/>. Acesso em 8 out. 2007.
[36]OPEN
GEOSPATIAL
CONSORTIUM
(OGC)
[on-line].
2005.
Disponível:http://www.opengeospatial.org/. Acesso em 20 mai. 2005.
[37]POSTGRESQL [on-line]. 2007. Disponível em: <http://www.postgresql.org/>.
Acesso em 8 out 2007.
[38]
Sistema
de
Posicionamento
Global
<http://pt.wikipedia.org/wiki/Sistema_de_Posicionamento_Global>. Acesso em 8 out
2007
81
8. Anexos
8.1.
Anexo A
Identificação dos usuários do sistema
1 - Quem são os usuários? Quem necessita desta aplicação?
O usuário é caracterizado por qualquer pessoa comum que possua um celular
dotado dos requisitos para executar a aplicação. Necessita da aplicação aqueles
usuários, acima definidos, interessados na visualização de mapas e na navegação
sobre os mesmos, desde que não tenham que pagar um valor para utilizá-los.
2 - Qual é sua formação educacional?
Devido à necessidade de se possuir um celular que atenda os requisitos da
aplicação, sendo este é acessível principalmente à pessoas que possuem recursos
financeiros mais fartos, o usuário típico da aplicação possui, ou está cursando, nível
superior.
3 - Quais são seus conhecimentos de computador, dispositivos móveis e tecnologia
em geral?
Os
usuários
acima
definidos
são
entusiastas
de
tecnologia
e
possuem
conhecimentos nível usuário intermediário com relação à computadores e
dispositivos móveis.
4 - Eles estão familiarizados com este tipo de aplicação?
Sim, normalmente já utilizam os aplicativos de geolocalização que já vem préinstalados em seus dispositivos móveis.
5 - Que plataformas eles utilizam hoje?
82
Utilizam softwares de mapas e geolocalização pré-instalados, assim como
aplicativos proprietários da Garmin.
6- Em que contextos os usuários utilizarão a aplicação?
Normalmente utilizarão a aplicação em viagens para lugares que não possuem
mapas gratuitamente disponíveis ou necessitam de um mapa específico.
7 - Qual a sua expectativa com relação à usabilidade da aplicação?
Desejam que a aplicação seja fácil de usar, mesmo para os usuários mais leigos,
possua interface amigável, intuitiva e simples.
8 - Existem expectativas com relação ao desempenho?
Existem poucas expectativas, principalmente nos momentos em que seja
necessário geolocalização, tendo em vista que este serviço é inerentemente de
acesso demorado e instável.
8.2.
Anexo B
Instalação do ambiente de desenvolvimento
Passo 1 – Instalação do Java Development Kit (JDK) e da IDE Eclipse
Deve-se obter as últimas versões dos softwares Java Development Kit (JDK) e da
IDE Eclipse e prosseguir com suas instalações padrão. Estes softwares formam a
base para o desenvolvimento Java.
a. Download: Eclipse IDE for Java EE Developers http://www.eclipse.org/downloads/
b. Download: Java SE Development Kit (JDK) http://java.sun.com/javase/downloads/index.jsp
Passo 2 – Instalação do Eclipse Mobile Tools for Java (MTJ)
83
Durante o curso deste projeto o software conhecido como EclipseME mudou seu
nome para
Eclipse,
Eclipse Mobile Tools for Java (MTJ). Este software, um plugin do
fornece
uma
extensão
do
framework
Eclipse
possibilitando
o
desenvolvimento para dispositovos móveis em Java (J2ME).
a. Download: Mobile Tools for the Java Platform (MTJ) http://www.eclipse.org/dsdp/mtj/
b. Instalação: Basta descompactar o arquivo Zip para a pasta de instalação
do Eclipse conforme a imagem a seguir:
Passo 3 – Instalação do emulador S60 3rd Edition Feature Pack 2 v1.1 da Nokia
Este emulador representa a plataforma de simulação e teste escolhida para os
softwares em linguagem J2ME desenvolvidos neste projeto.
a. Download: S60 3rd Edition Feature Pack 2 v1.1 http://www.forum.nokia.com/info/sw.nokia.com/id/ec866fab-4b76-49f6b5a5-af0631419e9c/S60_All_in_One_SDKs.html
b. Instalação – Tela Inicial: Selecione “Yes” para a primeira pergunta.
84
c. Instalação – Tela de seleção do modo de instalação: Selecione “typical”.
85
d. Instalação – Tela de seleção da pasta de instalação: Selecione uma pasta
para a instalação.
86
e. Instalação: Basta concluir a instalação do emulador.
Passo 4 – Configuração do Eclipse
a. Abra o Eclipse e selecione o menu Options, Preferences e abra a guia
Java ME conforme a figura:
87
b. Clique em Import e na tela seguinte clique em Browse e selecione a pasta
onde o emulador S60 foi instalado.
c. Aperte OK e aguarda a importação. Em seguida cliquem em Refresh e
marque Select All.
88
d. Clique em Finish e Ok para finalizar a configuração do emulador.
Passo 5 – Obter o projeto através do repositório SVN
a. Ainda no Eclipse, selecione o Menu File, Import e escolha Checkout
Projects From SVN
89
b. Na tela a seguir selecione Create New Repository Location, Next e digite o
endereço do servidor SVN onde o projeto está hospedado
(http://mapime.googlecode.com/svn), clique em next e selecione o projeto.
c. Finalize a importação.
Passo 6 – Obter o conversor ShapeFile para SVG
a. Basta obter os arquivos ogis2svg.exe e shp2pgsql.exe no endereço
http://www.carto.net/papers/svg/utils/shp2svg/ e seguir as instruções de
uso da página.
90
8.3.
Anexo C
No centro da arquitetura do sistema está o LocationMidlet, responsável por
iniciar o sistema e por realizar o tratamento das interações do usuário com o mesmo.
Funciona como a classe principal do sistema. Acoplado a ele existem quatro
grandes módulos de funcionalidades do sistema, quais sejam:
Instruments, responsável pela recepção das coordenadas utilizadas para locar a
posição do dispositivo sobre mapa;
Canvas, responsável por renderizar o mapa na tela do dispositivo;
Server Connections, responsável pelas conexões sem-fio dispositivo – servidor;
FileAccess, responsável pelo acesso ao sistema de arquivos do celular.
O módulo Instruments possui apenas a recepção das coordenadas pela antena
GPS disponível, através do módulo GPS, mas a arquitetura do sistema foi adequada
de forma a acomodar novas tecnologias de posicionamento. O módulo
serverConnections, atualmente, trabalha apenas com o protocolo de conexão Http.
Esses quatro grandes módulos do sistema provêm todas as funcionalidades listadas
na seção 4.4. A figura 35 ilustra a arquitetura do sistema.
91
Figura 35 - Diagrama de Classes
92
8.4.
Anexo D
Os mapas com os quais se trabalharam neste projeto foram obtidos com a
extensão Shapefile e posteriormente deveriam ser convertidos para SVG.
Entretanto, os mapas em SHP quando convertidos para SVG pelo servidor de
mapas Geoserver, não inclui no arquivo SVG gerado os atributos das feições do
mapa, conforme mostra a figura 39. Repare na figura 39, que o código do arquivo
SVG apresenta apenas a geometria das feições representadas por <path d=” “>. Por
outro lado, utilizando-se o conversor livre Shp2SVG da Carto.Net[2], obtivemos um
SVG com todos os atributos das feições do mapa, mas seu DTD (svg11.dtd),
conforme ilustra a figura 40, Document Type Definition, que consiste em definições
que padronizam arquivos com extensão xml, não é compatível com o DTD aceito
pelo JavaME (svg10.dtd). Ao utilizar o SVG do conversor da Carto.Net[2], o
resultado foi a não representação correta das geometrias das feições, conforme
mostra a figura 44. Constatou-se que o DTD utilizado pelo conversor da Carto.Net é
voltado para a exibição de svgs em browsers. Para solucionar tal problema,
desenvolveu-se um Parser próprio responsável por manipular esses dois arquivos
SVGs gerados, um a partir do Geoserver e o outro a partir do conversor da
Carto.Net[2], e extraíram-se a geometria das feições de um e os atributos do outro
para compor um novo SVG, o qual fosse interpretado corretamente pelo dispositivo
móvel, conforme ilustra a figura 41. Repare que o DTD desse arquivo continua como
svg11.dtd, mas o correto seria a criação de um novo DTD que fornece tanto a
geometria quantos os atributos em SVGs voltados para a exibição em dispositivos
móveis. Importante observar que, até o momento da pesquisa, desconhece-se a
existência de um DTD com as características necessárias para a utilização em
dispositivos móveis. Segue o código do conversor próprio.
93
Figura 36 - Pré-Conversor
A função do pré-conversor consiste em adequar o SVG oriundo do conversor da
Carto.Net[2] para que seus atributos sejam lidos corretamente.
O SVG da
Carto.Net[2] representa os atributos da seguinte forma:
A leitura correta leitura desses atributos pela função específica do JavaME exige
que as feições do SVG sejam reescritas como:
94
O
pré-conversor,
justamente,
insere
modificações
acessórias
para
a
transformação do xml.
A classe ConversorSVG é responsável pela
captura dos atributos do SVG
gerado a partir do conversor da Carto.Net[2] e da geometria das feições do SVG
gerado pelo Geoserver e reuni-los em um novo SVG.
Em seguida, temos a classe principal que ilustra a execução do Parser para o
mapa de Brasília BSB_WGS84_UTM_Malha_Viaria.svg gerado pelo Geoserver a
partir de um SHP. Este sofre modificações pelo pré-coversor e a saída, o b2.svg já
está pronto para receber os atributos do bsb.svg, o SVG gerado pelo conversor da
Carto.Net[2]. O resultado final é o b4.svg, o qual contém os atributos e as
geometrias representados de forma interpretável pelo JavaME.
95
96
Figura 37 - Código Fonte Conversor SVG
Figura 38 - Classe Principal
97
8.5.
Anexo E
Figura 39 - Extrato de um arquivo em formato SVG, referente ao mapa do bairro de Botafogo – RJ, gerado
a partir do Geoserver
Figura 40 - Extrato de um arquivo em formato SVG, referente ao mapa do bairro de Botafogo – RJ, gerado
a partir do conversor da Carto.Net[2].
98
Figura 41 - Extrato do arquivo SVG gerado a partir dos dois arquivos anteriores utilizando-se o conversor
próprio
Figura 42 - Mapa do bairro de Botafogo – RJ obtido pelo conversor próprio.
99
Figura 43 - Mapa do bairro do Centro - RJ obtido a partir do conversor próprio.
Figura 44 - Mapa do bairro do Centro – RJ gerado a partir do conversor da Carto.Net[2].
100