Sistemas Baseados em Localização em um Mundo Sem-fio com J2ME e a Nova API Location
Versão revista e ampliada do artigo "Sistemas Baseados em Localização em um Mundo Sem-fio com J2ME e API Location" aprovado no 3º SBSI – Simpósio Brasileiro de Sistemas de Informação 2006.
Autores: Elias F. Lopes, Jaime G. Nogueira, Thiego G. Nacif
Orientador(a): Profª Drª Thienne M. Johnson
Sistemas ou serviços baseados em localização (do inglês Location-Based Services – LBS) podem ser vistos como a convergência de várias tecnologias atuais, tais como:
•	Sistemas de comunicação móvel;
•	Tecnologias de localização;
•	Dispositivos móveis (DM) com a Internet;
•	Sistemas de informação geográfica (SIGs);
•	Servidores da aplicação e banco de dados espaciais.
O ponto central desses sistemas está em obter informações que determinem a localização de dispositivos móveis (DM) e, baseado nessas informação, oferecer serviços de acordo com o contexto de utilização do sistema (o fator localização agregando valor a outros serviços). Temos como objetivo, através deste trabalho, mostrar a API Location da tecnologia J2ME (JAVA 2 Micro Edition), utilizada para implementação de um sistema LBS com suporte a GPS (handset-based). Mostrando seu funcionamento para gerar serviços de geo-localização, suas principais classes e especificações para a implementação de uma aplicação básica LBS.
Este artigo divide-se em 5 partes. A seção 1 é a introdução deste trabalho. A seção 2 detalha a arquitetura de um LBS, mostrando em outros itens suas tecnologias. A seção 3 especifica a tecnologia JAVA utilizada para a implementação básica de um LBS, analisando trechos específicos. A seção 4 trata sobre o cenário atual da tecnologia no Brasil. Por fim, a seção 4 mostra a conclusão deste nosso trabalho.
2. Arquitetura de Sistemas Baseados na Localização
Para desenvolver LBS, deve existir uma estrutura básica de componentes que dêem suporte a:
•	Determinação da localização (i.e., software e hardware, e.g., Position-Determining Equipment);
•	Solicitações de consultas;
•	Processamento e gerenciamento da informação geográfica e contextual;
Serviços de gateway (i.e., midleware entre os serviços de processamento e os DM para promover compatibilidade).
2.1. O Fornecimento do Serviço
Sob o ponto de vista de fornecimento dos serviços, eles podem ser classificados como Push Services e Pull Services [3]. Onde o Push Services são serviços gerados automaticamente por aplicações de acordo com o perfil do usuário e sua localização, fornecidos no momento certo sem a necessidade de intervenção por parte do usuário, uma vez que já pré-solicitado pelo mesmo.
Para fornecer este tipo de serviço é necessário implementar um sistema para monitorar e fornecer a localização do usuário de acordo com intervalos de tempo pré-determinados.
Já os Pull Services são serviços fornecidos com base na solicitação do usuário no momento que é solicitado. Assim o usuário pode fornecer informações para um refinamento da aplicação de LBS possa fornecer um melhor serviço.
2.2 Tecnologias de localização de dispositivos móveis
As tecnologias utilizadas para a localização podem ser classificadas quanto ao local onde as coordenadas de posicionamento são coletadas e calculadas. São essas: soluções baseadas em rede (network-based), baseadas no dispositivo (handset-based) e soluções híbridas que utilizam tanto a rede quanto o dispositivo para processarem os cálculos.
As network-based se caracterizam pela presença de um equipamento de localização colocado nas estações rádio-base (ERB) e também pelo processamento necessário para o LBS, sendo feito na infra-estrutura da própria rede. Por sua vez, as handset-based implementam grande parte da tecnologia nos DM e tem como base o uso da tecnologia GPS. Em ambientes fechados recomenda-se a utilização de uma das técnicas baseadas em sensores (mobilidade micro).
3. Usando J2ME, Location API e a implementação do LBS
A edição JAVA J2ME (edição mais recente) direcionada ao mercado de pequenos dispositivos. Seu conjunto de especificações tem por objetivo disponibilizar uma JVM (Máquina Virtual JAVA, do acrónimo em inglês Java Virtual Machine), APIs e ferramentas para equipamentos como: telefones celulares, pagers, palmtops, vídeo-games, sistemas embutidos, etc. Atualmente já existe a KVM ('K' Virtual Machine) que é uma máquina virtual que oferece suporte ao J2ME em micro-controladores de 16 ou 32 bits. Voltada à CLDC (Connected Limited Device Configuration) e CDC (Connected Device Configuration), a KVM possui apenas 40K de código e precisa de poucos kilobytes para a sua execução pois esta não implementa a especificação da JVM e, sim, parte dela.
A julgar pela quantidade de pessoas que utilizam telefones celulares em vários lugares públicos, é possível afirmar que a tecnologia sem fio já tem seu lugar no mainstream demostrando como as aplicações LBS logo serão destaques no mundo sem fio. Sendo assim, a J2ME é ideal para tornar-se um padrão para o desenvolvimento desse tipo de aplicação, pois fornece um conjunto de classes e funcionalidades voltadas para esse fim [2].
Direcionada para a implementação de LBS, foi desenvolvida a API Location (Java Specification Request #179 - JSR -179) como pacote de classes adicionais de J2ME. Esta seção tem por objetivo mostrar o uso desta API no suporte ao desenvolvimento de sistema LBS e disponibilizar uma documentação sobre a mesma no idioma nacional (pois materiais em portugues sobre o assunto abordado é escasso). O sistema permite que um DM, equipado com GPS, tenha acesso utilizando um servidor de banco de dados à localização de serviços e localidades próximos a sua posição atual.
3.1. Especificação da API Location
Essa API fornece uma interface padrão de alto nível para acesso a informações de posição de um DM, independente do método de localização utilizado. Esta API é opcional, portanto, não precisa necessariamente estar presente no pacote padrão de APIs encontrados nos dispositivos complacentes com a plataforma J2ME (HAIGES 2003).
Ela contém as classes básicas necessárias para solicitar e obter uma localização geográfica e integra dados genéricos de posição e de orientação com armazenamento persistente de Ponto dos Objetos de Interesse (POI), ou marcos, e conexão via HTTP com servlets , que permitem programadores implementar aplicações e serviços sem fio baseados em localização, para dispositivos de recurso limitados como DM (CDC e CLDC) [6],
Essa API permite a implementação com qualquer método comum de localização de forma transparente ao usuário, isto é, sem deixar a amostra os procedimentos e cálculos complexos dos métodos de localização, exibindo apenas os resultados requeridos.
3.2. Sistema de Coordenadas Geográficas
A API Location utiliza coordenadas geográficas que são obtidas pelo Sistema Geodésico Mundial (World Geodetic System – WGS84). Utilizado também como um sistema de referência via GPS.
As coordenadas são constituídas de valores de latitude, longitude e altitude. Na esfera global as latitudes são linhas horizontais de medida, as mesmas representam o norte e o sulentre os pólos. O pólo norte é 90 graus norte (ou +90º) e o pólo sul é 90 graus sul (ou -90º). O círculo central (maior) é chamado de Equador é definido como 0 grau (0º).
Pelo fato de haver duas definição de pólo norte (o magnético e o geográfico), as implementações com a API Location podem usar tanto um quanto o outro. Recomenda-se que as aplicação utilizando uma bússola deveriam verificar como a API está definindo o pólo.
As longitudes são valores constantes longitudinais definidos pelos meridianos. Na esfera global as longitudes são linhas que atravessam o globo terrestre do norte ao sul. Pelo fato de não existir um meridiano de referencia (de partida), é necessário a definição de um. Tradicionalmente, o meridiano de Greenwich (Inglaterra). O valor do primeiro meridiano é 0 grau, no entanto o WGS84 utilizado pela API Location define o meridiano 0 (zero) a 100m a leste do Greenwich. Localizações a leste do WGS84.
Para fornecer informações confiáveis e algo além de mapas, o LBS pode contar com o auxílio de ferramentas que realizam análise espacial para SIGs (Sistemas de Informações Geográficas), utilizando clássicas e modernas teorias como, por exemplo, técnicas de geo-estatística, lógica fuzzy, redes Bayesianas, estimativas de incerteza, propagação de erros, redes neurais, etc. Um exemplo de onde pode-se aplicar estas técnicas para melhorar o fornecimento de LBSs é a utilização de algoritmos baseados em lógica fuzzy para aumentar o grau de precisão da informação de localização capturada em áreas urbanas quando é utilizada a tecnologia de localização GPS. [8] apresentam um algoritmo implementado com esta finalidade. O uso dessas teorias enriquece as informações disponibilizadas para os usuários, uma vez que oferece dados consistentes para construção do conhecimento que, na maioria das vezes, é a base para a tomada de decisões.
3.3. O Modelo de Objeto do Pacote javax.microedition.location
O pacote Location (javax.microedition.location) é sub-dividido da seguinte forma: em 8 classes, sendo 6 principais e duas de relações de ouvinte de eventos ou classes de interface (LocationListener e ProximityListener). Das seis classes, duas são classes da exceção (LocationException e LandmarkException) e outros quatro (AddressInfo, Criteria, Orientation, e QualifiedCoordinates) são primeiramente objetos do valor.
A classe LocationProvider é o ponto inicial para as aplicações usando esta API e representa o objeto de recuperação da posição do DM, usando os métodos existentes de localização (JAVA COMMUNITY 2006).
Por meio da LocationProvider, a aplicação cria objetos Location (objeto padrão que representa a localização básica de uma posição), obtendo assim a localização do DM no momento que desejar. Já o objeto Location contêm objetos QualifiedCoordinates, que representam as coordenadas geográficas que estão associados com valores de precisão, hora, velocidade e curso (orientção) do DM.
As classes de exceções ocorrem quando há erros relacionados à integridade dos marcos (LandmarkException) ou quando ocorrem erros específicos da API da posição (LocationException).
Com o uso do LocationListener, a aplicação pode pedir um único objeto de posição (coordenadas geo-localizacionais) ou periodicamente ser atualizada com os objetos novos de posição de forma automática, de acordo com a disponibilidade do provedor de localização (receptor GPS). Já o ProximityListener, trabalha com eventos associados a detectar a proximidade (raio de sensibilidade) a algumas coordenadas geográficas já conhecidas pelo usuário (valores de latitude, longitude, altitude) registradas através do LandmarkStore por parte do utilizante.
3.3. Usando as Classes Location e Proximity Listeners
Usando a relação de LocationListener, você pode escutar (obter de forma automática) atualizações da sua posição atual em intervalos de tempo pré-determinados, pode expor e processar informação em um contexto a ser alcançado por outros componentes na demanda. Uma vez executada a relação (instaciamento do objeto) de LocationListener, ele pode ser registrado com o LocationProvider através do método do setLocationListener, para assim poder ser utilizado a obter a posição atual. Usando critérios (disponíveis na classe Criteria) para refinar a ação do sistema.
As escolhas que você faz em seus critérios e o projeto da aplicação pode afetar a:
•	Vida da bateria do DM;
•	Latência na aplicação;
•	Adequação da precisão (horizontal e vertical);
•	Determinação manualmente ou não do método a ser usado para recuperar a posição (ex. GPS indoor)
•	E o custo [4].
Como este é potencialmente um processo longo, este é executado paralelamente em uma thread para deixar a interface livre para o processo de execução de outras funções
public class LocationListenerMIDlet extends MIDlet implements CommandListener, LocationListener(){
cr.setHorizontalAccuracy(100);
cr.setVerticalAccuracy(100);
cr.setPreferredPowerConsumption(Criteria.POWER_USAGE_LOW);
thread tGetLocation = new thread(){
LocationProvider lp=LocationProvider.getInstance(cr);
Location loc=lp.getLocation(60); }
A classe de interface (ouvinte) contém dois métodos: o locationUpdated e providerStateChanged. O LocationProvider provoca o método locationUpdated sempre que a posição mudar. Já o método providerStateChanged é informado quando o estado do LocationProvider muda entre seus três valores possíveis: AVAILABLE, TEMPORARILY_UNAVAILABLE, e OUT_OF_SERVICE [6].
No exemplo abaixo, somente locationUpdated é executado, chamando o método que atualiza o formulário da tela.
this.locationInfo(); }
Ao contrário do LocationListener, que pode ter somente um registro, o LocationProvider permite registrar ProximityListeners múltiplo. O ProximityListener adiciona a proximidade (os pontos geo-localizacionais) do landmark. Ao começo da execução, são registradas três posições de modo que você possa aguardar até escutar eventos de proximidade para três posições diferentes já conhecidas. Cada registro requer o ouvinte, as coordenadas, e o raio de proximidade destas coordenadas como parâmetros.
public class ProximityListenerMIDlet extends MIDlet implements CommandListener, LocationListener, ProximityListener(){
float raio = 100.0F;
locationProvider.addProximityListener(this, UNAMA-AlcCoordinates, raio);
A relação de ProximityListener têm dois métodos: o monitoringStateChanged e o proximityEvent. O método monitoringStateChanged informa aos ouvintes se a notificação da proximidade é atualmente ativa. O método proximityEvent fornece duas coordenadas dos parâmetros [7]. Nesta execução, compara-se às coordenadas dadas (fornecidas pelo usuário) com as que se aguarda quando há modificação (mudança de posição) e seleciona-se a posição combinada, ficando a cargo do programador e suporte do aparelho a escolha de exibir alertas com imagens apropriadas ao landmark nas proximidades (no caso o campi da UNAMA-BR).
public void proximityEvent(Coordinates coordinates, Location location){
if(coordinates.equals(studyCentreCoordinates)){
showUNAMA-AlcProximityAlert();}
3.4. A Coordinates e Outras Informações
Os objetos da posição são subtipos de objetos de AddressInfo e de QualifiedCoordinates, e esses objetos de posição são adquiridos da classe LocationProvider (parametrizado por um objeto Criteria). Uma vez que já tenha o objeto de posição "em mãos", pode-se usar para encontrar as informações atuais através do objeto QualifiedCoordinates (o qual é agregado de Location).
coordinates = location.getQualifiedCoordinates();
Uma posição pode também conter um objeto de AddressInfo, com detalhes tais como o endereço postal, o número de telefone, o país, uma URL associada e etc. Dependendo da execução e do local de contexto, entretanto, não pode realmente haver um AddressInfo associado com qualquer posição dada. Por exemplo, se você estiver no meio de um campo aberto, não haverá nenhum dados de AddressInfo sendo nesse caso sempre nulo.
A direção, a velocidade, e a altura atuais são retornados do objeto de QualifiedCoordinates como valores reais enquanto que a latitude e a longitude são retornadas como double. Para Para melhor visualização dos dados, a classe Coordinates inclui um método de conversão de um objeto de coordenadas (Coordinates.convert) em uma string (palavra) em um dos dois formatos:
a) Graus, minutos, e frações decimais de minuto (em double: 61.51d e em string: 61:30:36);
b) Graus, minutos, segundos, e frações decimais de segundo (em double: 61.51d e em string, 61:30.6).
Abaixo, uma implementação onde a informação da posição é exibido na tela sendo usado o formato "b", usando o campo constante Coordinates.DD_MM_SS. Alternativamente, o formato "a" pode ser selecionado usando Coordinates.DD_MM.
if((qc != null) || (location.isValid())) {
lat = new StringItem("Latitude: " + Coordinates.convert
(coordinates.getLatitude(), Coordinates.DD_MM_SS), "");
long = new StringItem("Longitude: " + Coordinates.convert (coordinates.getLongitude(),	Coordinates.DD_MM_SS), "");
A classe das coordenadas (super classe de QualifiedCoordinates) encapsulam métodos geométricos tais como o cálculo do azimuth (ângulo) e da distância entre posições. A classe Orientation é completamente separada do resto do modelo do objeto, não tendo nenhum relacionamento de associação ou de dependência com quaisquer outras classes. Isto é possível porque nem todos os dispositivos podem suportar a informação de orientação [6]. No mínimo, o dispositivo deve fornece um valor do angulo de compasso aos objetos de orientação da sustentação.
Além de se ajustar a recuperação dos dados formatados (NMEA, LIF), pode-se também ajustar a exibição dos erros de forma detalhada com uso do getExtraInfo [5] o qual e um método intuitivo utilizado para a localização. O valor retornado é um bitwise, uma combinação (OU) da tecnologia do método, tipo do método e informação do auxílio.
Location.getExtraInfo(String mimetype)
getExtraInfo("application/X-jsr179-locationnmea")
getExtraInfo("text/plain")
metodo = location.getLocationMethod();
3.5. Usando as Classes Landmarks e the LandmarkStore
O que distingue particularmente esta API de outras bibliotecas LBS é o uso do armazenamento local nos DM, sendo uma base de dados persistente dos POI. Isto desloca a ênfase no cliente móvel nos termos de aplicações em relação a posição-clientes, permitindo mapeamento locais de posições já conhecidas. A vantagem principal desta é que as aplicações são mais prováveis ter a funcionalidade útil, mesmo onde a conectividade da rede com o servlet é ruim [6], isto é mesmo sem a conexão com o servidor de banco de dados o aplicativo não fica inoperante
O LandmarkStore é uma coleção de POI, podendo haver muitos destes em um DM compartilhado por aplicações múltiplas. Os POI podem, opcionalmente, serem armazenados em lojas múltiplas e à categorias múltiplas. A única limitação é que um POI não pode ser adicionado várias vezes à mesma categoria presente no mesmo LandmarkStore.
Uma característica da API é que um objeto POI pode ser dados de coordenada e de endereço de uma posição gerada pelo LocationProvider (o LocationProvider pode incluir um objeto AddressInfo junto com o QualifiedCoordinates). Isto significa que os POI podem ser adicionados dinamicamente (de forma automatica) ao LandmarkStore.
A seguir, é usado um ProximityListener para indicar alertas ao se aproximar de determinadas coordenadas. A primeira etapa é iniciar uma instância do mesmo (o parâmetro nulo é o padrão). A seguir ao início são criados os objetos POI e armazenados ao LandmarkStore, adicionado-os usando um nome de categoria, nome do local, descrição, conjunto das coordenadas, e o AddressInfo do local.
landmarkStore = LandmarkStore.getInstance(null)
Landmark landmark1 = new Landmark ("UNAMA Alc. Cacela","Um dos campi da UNAMA – Universidade da Amazônia", UNAMACoordinates, info);
landmarkStore.addLandmark(landmark1, "campus");
Mais tarde é feita a recuperação (pesquisa) de um POI determinado usando o método getLandmarks, passando os nomes da categoria e o POI como parâmetros:
Enumeration e = landmarkStore.getLandmarks("campus", " UNAMA Alc. Cacela");
Landmark landmark = (Landmark)e.nextElement();
AddressInfo info = landmark.getAddressInfo();
3.6. Comunicação com o Servlet
Uma outra forma, muito utilizada, de fornecer uma base de dados a dispositivos com pouco poder de armazenamento é o uso de servlets que trabalham com banco de dados. Depois de já obtida a informação da posição atual, é possível submetê-la ao servlet sobre uma conexão do HTTP padrão (definição de uma URL), no caso usando para solicitação o método Get da aplicação LBS (MIDLet ).
public void PesquisarGet() throws IOException {
thread tConnection = new thread(){
hc.setRequestMethod(HttpConnection.GET); }
tConnection.join();
Como foi visto, o MIDLet faz o trabalho de recuperar (no caso via GPS) a posição atual do DM e de entregá-la ao usuário. Em uma aplicação típica se tem um servlet que aceita os pedidos de requisição e manipula essas informações de localização.
A parte chave é o método do doGet(), que faz o trabalho de analisar as informações repassadas do DM, realizar a consulta via uma seqüência SQL ao banco de dados e então retornar as informações de resposta (eventos e logradouros nas proximidades) ao MIDLet.
String latitude = request.getParameter("latitude"), longitude = request.getParameter("longitude"), localidade = pesquisaLocal(latitude, longitude);
public String pesquisaLocal(String latitude, String longitude){
// Obejtos de conexão
String sql = "Select LOCALIDADE From DADOS_LOCALIDADE Where latitude = " + latitude - latRadius + " BETWEEN " + latitude - latRadius + " And longitude = " + longitude – lonRadius + " BETWEEN " + longitude + lonRadius + ";"
Class.forName("…");
…	}
Dentre as operadoras brasileiras a VIVO é a pioneira no uso de serviços LBS a nível nacional , com o serviço VIVO Localiza e outros do gênero. O serviço utiliza tanto o recurso handset-based com o A-GPS (Assisted GPS) quanto network-based com a triangulação de ERBs. Normalmente ao se estar outdoor é utilizado o A-GPS e em indoor a triangulação.
Via menu de download do DM da operadora é possível contratar o serviço que dá direito a um determinado número de localizações. Com o SW já descarregado para o DM, ele captura as informações geo-localizacionais do GPS interno do DM e os envia para um servidor que converte as informações para que sejam plotadas em um mapa geo-referenciado. Seu erro esta na média de 5 a 50m.
Os LBS possuem características que resultam em questões que não são comuns nos sistemas de informação tradicionais, sendo um desafio complexo do ponto de vista tecnológico e comercial. A heterogeneidade e dispersão das fontes de informação e a associação destas as localizações físicas, assim como a condição de mobilidade dos utilizadores, são aspectos que necessitam estar integrados e interagindo uniformemente.
Este artigo mostra o funcionamento de uma nova tecnologia J2ME em um contexto de geo-localização, onde o sistema implementado tem por finalidade, através desta tecnologia e sua API, simular um serviço LBS, cujo qual adquire e retorna valores localizacionais de um usuário qualquer que possua um dispositivo GPS em mãos.
Com a implementação deste sistema tenta-se chamar as atenções de operadoras telefônicas, usuários de telefonia móvel, provedores de serviços e outros para que haja um incentivo e divulgação ainda maior no contexto de LBS. Consecutivamente surge o interesse de criar novos sistemas genuinamente brasileiros, para assim possuirmos um desenvolvimento tecnológico, em um segmento altamente lucrativo, devido à alta agregação de valor aos serviços, onde a localização nas proximidades bem como a sua descrição são os principais componentes.
[1] Fortes, Fernando José Clemente (2006) "Metodologia de Avaliação da Qualidade dos Serviços Dependentes da Posição (Localização em Sistemas Móveis" Disponível em: http://campus.fct.unl.pt/ama/tsig/slides/lbn26.ppt., Dezembro.
[2] Haiges, Syen (2003) "The Location API", Disponível em: http://java.sys_con.com, Agosto.
[3] KOEPPEL, I. (2002) "What are Location Services? - From a GIS Perspective". http://www.jlocationservices.com/education/what_lbs.htm, Dezembro.
[4] Process, Java Community (2006) "Location API for Java™ 2 Micro Edition Version 1.0.1", Disponível em http://www.forum.nokia.com/main/resources/technologies/java/documentation/java_jsr. Agosto.
[5] Wick, Ryan e Lyon, Zane (2006) "Practical Applications of JSR 179", Disponível em: http://developers.sun.com/learning/, Agosto.
[6] Parsons, David (2005) "The Java Location API - Knowing where you are is half the battle", Disponível em: http://www.ddj.com/dept/java/184406388, Setembro.
[7] Venturella, Adam (2006) "J2ME - Location Based Data", Disponível em: http://www.google.com/notebook/public/04105482259393985038/BDUYhIgoQtqSQzbsh, Setembro.
[8] Quaddus, M.A., Noland, R.B., e Ochieng, W.Y. (2005) "The effects of navigation sensors and digital map quality on the performance of map matching algorithms", Disponível em: http://www.mdt.mt.gov/research/docs/trb_cd/Files/06-0237.pdf, Dezembro.