Embed Size (px)
Citation preview
UNIVERSIDADE FEDERAL DE MATO GROSSO
INSTITUTO DE COMPUTACAO
COORDENACAO DE ENSINO DE ESPECIALIZACAO EM
BANCO DE DADOS
ARMAZENAMENTO E MANIPULACAO DE DADOSGEOESPACIAIS NO ANDROID
KIVSON MARCELL NOGUEIRA DE ANDRADE
Cuiaba - MT
2015
UNIVERSIDADE FEDERAL DE MATO GROSSO
INSTITUTO DE COMPUTACAO
COORDENACAO DE ENSINO DE ESPECIALIZACAO EM
BANCO DE DADOS
ARMAZENAMENTO E MANIPULACAO DE DADOSGEOESPACIAIS NO ANDROID
KIVSON MARCELL NOGUEIRA DE ANDRADE
Orientador: Prof. Dr. Thiago Meirelles Ventura
Monografia apresentada ao Curso deEspecializacao em Banco de Dados, doInstituto de Computacao da UniversidadeFederal de Mato Grosso, como requisito paraobtencao do tıtulo de Especialista em Banco deDados.
Cuiaba - MT
2015
i
SUMARIO
1 Introducao p. 1
1.1 Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 2
1.1.1 Objetivo Geral . . . . . . . . . . . . . . . . . . . . . . . . . . p. 2
1.1.2 Objetivos Especıficos . . . . . . . . . . . . . . . . . . . . . . . p. 2
1.2 Justificativa . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 2
1.3 Metodologia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 3
1.4 Organizacao do Trabalho . . . . . . . . . . . . . . . . . . . . . . . . . p. 4
2 Fundamentacao teorica p. 6
2.1 Servicos Baseados em Localizacao . . . . . . . . . . . . . . . . . . . . p. 6
2.1.1 Arquitetura . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 7
2.1.2 Dados Geoespaciais . . . . . . . . . . . . . . . . . . . . . . . p. 9
2.2 Android . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 10
2.2.1 Arquitetura . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 10
2.2.2 Recursos de um LBS no Android . . . . . . . . . . . . . . . . p. 12
2.3 SQLite . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 12
2.3.1 spatialite . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 13
2.3.2 geohash . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 14
3 Consultas Espaciais p. 16
3.1 Consulta tradicional . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 18
3.2 Consulta com Geohash . . . . . . . . . . . . . . . . . . . . . . . . . . p. 18
3.3 Consulta com Spatialite . . . . . . . . . . . . . . . . . . . . . . . . . . p. 19
4 Analise dos Resultados p. 22
4.1 Desempenho . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 22
4.2 Armazenamento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 24
4.3 Avaliacao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 26
5 Consideracoes Finais p. 27
Referencias p. 29
ii
iii
LISTA DE FIGURAS
1 Arquitetura generica de um LBS . . . . . . . . . . . . . . . . . . . . . p. 8
2 Exemplo da interface de um sistema que utiliza um LBS . . . . . . . . p. 8
3 Arquitetura proposta de um LBS . . . . . . . . . . . . . . . . . . . . . p. 9
4 Arquitetura Android. Fonte: (BRAHLER, 2010) . . . . . . . . . . . . . . p. 11
5 Exemplo de pontos com Geohash. . . . . . . . . . . . . . . . . . . . . p. 15
6 Imagem da tela de exibicao de estabelecimentos. . . . . . . . . . . . . p. 17
7 Duracao da consulta por quantidade de estabelecimentos. . . . . . . . p. 23
8 Consumo de armazenamento de cada implementacao. . . . . . . . . . p. 25
iv
LISTA DE ABREVIATURAS E SIGLAS
API Application Programming Interface
ARM Acorn RISC Machine
GPL GNU General Public License
GPS Global Positioning System
IP Internet Protocol
LBS Location Based Services
LGPL GNU Lesser General Public License
MPL Mozilla Public License
OGC Open Geospatial Consortium
RISC Reduced Instruction Set Computer
SDK Software Development Kit
SQL Structured Query Language
v
RESUMO
A popularizacao e o avanco tecnologico dos dispositivos moveis promoveram ocrescimento das aplicacoes moveis que trabalham com dados geoespaciais, exibindodados de interesse do usuario baseadas na sua posicao geografica. Em geral, esses dadossao solicitados por meio de conexoes de internet movel, assim o processamento dasconsultas geoespaciais ocorrem em um computador remoto. Neste trabalho foi feito umcomparativo entre essa abordagem e a alternativa de manter esses dados e executar asconsultas no proprio dispositivo movel, a fim de verificar a viabilidade da segundaabordagem como uma alternativa off-line para os usuarios utilizarem operacoesgeoespaciais. Para isso, foi implementado um sistema para a plataforma Android queexibe um mapa com os dados de estabelecimentos credenciados proximos ao usuario queaceitam seu cartao de alimentacao. Nesse aplicativo, o usuario pode consultar osestabelecimentos que aceitem seu cartao de forma off-line. Essa implementacao mostrouque e viavel realizar as consultas geoespaciais no proprio dispositivo movel.
Palavras-chaves: Computacao Movel, Dados Geoespaciais, SpatiaLite, GeoHash.
CAPITULO 1
INTRODUCAO
Servicos baseados em localizacao (LBS, do ingles Location Based Service),
sao servicos que trazem conteudo para o usuario baseado na posicao geografica (KUMAR
et al., 2009; VANJIRE et al., 2014). E, segundo Kushwaha e Kushwaha (2011) e Silva
(2005), estao emergindo como um importante tipo de aplicacao em dispositivos moveis
com a popularizacao de tecnologias voltadas para o geoposicionamento nesses
dispositivos, sendo inclusive usados por empresas brasileiras como forma de expandir
seu mercado. Com isso, ha uma demanda maior por trabalhar com dados geoespaciais de
forma eficiente nesses dispositivos.
Uma alternativa para trazer ao usuario conteudo baseado na sua localizacao e
o uso de um servidor remoto para buscar essas informacoes, por meio de um web
service, por exemplo. Nesse modelo, o servidor remoto recebe a informacao da posicao
do dispositivo como um parametro, realiza toda a consulta geoespacial na base de dados
que esta nele ou em outro servidor e retorna apenas o resultado de interesse do usuario
(KUMAR et al., 2009; VANJIRE et al., 2014).
Porem, ha situacoes em que comunicar com um servidor remoto pode ser um
problema, como:
• falta de conexao com a internet;
• velocidade de conexao baixa para a quantidade de dados que precisa ser transferida;
• nao ser possıvel arcar com os custos de um servidor com a disponibilidade desejada.
Uma alternativa para lidar com essas situacoes, e manter todos os dados
geoespaciais, ou uma grande parte deles, no dispositivo movel. Sendo feito download
dos dados apenas uma vez, e com as consultas executadas dentro do proprio dispositivo,
o usuario tera os dados que precisar independente das questoes levantadas anteriormente.
1.1 OBJETIVOS
1.1.1 OBJETIVO GERAL
O objetivo desse trabalho e avaliar a possibilidade de armazenar e manipular
dados geoespaciais em dispositivos moveis com o sistema operacional Android.
1.1.2 OBJETIVOS ESPECIFICOS
• Pesquisar as bibliotecas para consulta de dados geoespaciais em dispositivos
moveis.
• Implementar as consultas de dados geoespaciais em Android utilizando as
alternativas encontradas.
• Definir a melhor forma de armazenar os dados no dispositivo movel.
• Avaliar o desempenho de cada alternativa quanto ao armazenamento, tempo de
resposta e complexidade de implementacao.
1.2 JUSTIFICATIVA
Manter um servidor para realizar consultas geoespaciais de uma aplicacao
movel traz uma serie de restricoes. Tais restricoes podem estar relacionadas ao uso do
aplicativo, como o acesso a internet com uma taxa de transferencia insuficiente para a
aplicacao, o que inclusive pode limitar o tamanho da area geografica de busca disponıvel.
E tambem podem estar relacionadas ao negocio, com a exigencia de um servidor capaz
de processar esse tipo de consulta.
2
A fim de resolver tais problemas, pode ser feita a manipulacao dos dados
geoespaciais, bem como seu armazenamento, no proprio dispositivo movel. Sendo essa
alternativa viavel para uma aplicacao real, e possıvel utiliza-la para reduzir custos com
servidores - muito util para desenvolvedores independentes - e reduzir a dependencia
entre a aplicacao e a conexao com a internet - aumentando assim a disponibilidade dos
dados para o usuario.
1.3 METODOLOGIA
Para atingir os objetivos propostos, este trabalho fez um estudo de caso em
cima do aplicativo para Android SSaldo1. O aplicativo foi criado por Kivson Andrade 2 e
Mahmoud Ali 3 inicialmente apenas para mostrar o saldo dos cartoes alimentacao e
refeicao de uma grande empresa do ramo. No decorrer dessa monografia foi
implementado um novo modulo para mostrar os estabelecimentos que aceitam os cartoes
nas proximidades do usuario.
A empresa de cartoes alimentacao e refeicao e contratada por outras
empresas para terceirizar a alimentacao dos seus trabalhadores. De posse desses cartoes
o funcionario pode gastar seus creditos em estabelecimentos credenciados pela empresa
de cartoes. Os dados dos estabelecimentos brasileiros credenciados, bem como sua
localizacao geografica, e disponibilizada publicamente para consulta no site da empresa.
Com este caso em mente, foi feita uma revisao bibliografica sobre os temas
que compoem esse trabalho. Tanto dos temas mais conceituais, como LBS, dados
geoespaciais, representacao e armazenamento desses dados, quanto dos temas ligados a
implementacao em si, como sistema operacional Android, padroes de armazenamento de
dados e bibliotecas para manipulacao de dados geoespaciais.
Depois desse levantamento, foi implementado o modulo para exibicao dos
estabelecimentos. Para essa implementacao, foi utilizada uma base de dados, com dados
extraıdos atraves de web crawling, das informacoes dos estabelecimentos disponibilizadas
publicamente no site da empresa e as tecnologias de armazenamento e manipulacao de
dados geoespaciais disponıveis para Android.
1Disponıvel em: https://play.google.com/store/apps/details?id=br.com.kivson.ssaldo2http://lattes.cnpq.br/80155638448112423http://lattes.cnpq.br/8937596369075526
3
Alem da funcionalidade principal, de mostrar os estabelecimentos proximos
ao usuario, esse modulo possui algumas opcoes de benchamrk. Onde e possıvel calcular
o tempo das consultas e alterar sua extensao geografica.
A partir da implementacao foram feitos testes do uso desse modulo. Para
isso, foi utilizado um smartphone com caracterısticas de hardware similares aos
dispositivos que possuem a aplicacao instalada atualmente. Tambem foi utilizada a
funcao de localizacoes fictıcias do Android, para fazer consultas em locais com uma
maior quantidade de estabelecimentos por metro quadrado, como a regiao metropolitana
de Sao Paulo.
Por fim, com as informacoes de desempenho adquiridas com essa
implementacao, foi possıvel fazer uma breve analise sobre alguns pontos dessa
implementacao, como:
• se as bibliotecas pesquisadas atendem as necessidades da aplicacao;
• se esta e uma implementacao viavel para a aplicacao;
• quais vantagens e desvantagens da implementacao apresenta.
1.4 ORGANIZACAO DO TRABALHO
Baseado nessa metodologia, esse trabalho foi dividido em tres capıtulos:
fundamentacao teorica 2, consultas espaciais3 e analise de resultados4.
No primeiro, estao detalhados, por meio da revisao bibliografica, os
conceitos teoricos que servem como base para a compreensao do que foi elaborado neste
trabalho. Dentre estes conceitos estao: o tipo de aplicacao a ser desenvolvida e avaliada,
sua arquitetura basica, o tipo de dados com que ela trabalha, o sistema operacional
Android e seu banco de dados padrao.
No capıtulo seguinte, estao exibidos os detalhes de implementacao das
diferentes formas de consulta de dados espaciais no Android. Utilizando os conceitos
apresentados no capitulo anterior para a implementacao do modulo de consulta de
estabelecimentos do aplicativo SSaldo.
4
Por fim, no ultimo capıtulo, traz uma analise dessas consultas, com suas
vantagens e desvantagens, baseado-se em dados de benchmark obtidos atraves da
implementacao apresentada no capıtulo anterior.
5
CAPITULO 2
FUNDAMENTACAO TEORICA
Este capitulo trata dos conceitos relacionados a elaboracao desse trabalho, foi
abordado o tipo de aplicacao a ser desenvolvida, sua arquitetura basica, com que tipo de
dados ela trabalha, uma breve descricao do sistema Android, bem como sua arquitetura.
Por fim, foi discutido o banco de dados padrao do Android, que e o banco de dados
utilizado para o desenvolvimento proposto nesse trabalho.
2.1 SERVICOS BASEADOS EM LOCALIZACAO
O Open Geospatial Consortium (OGC) e uma instituicao internacional
formada por atualmente 496 universidades, agencias governamentais e representantes da
industria, que definem padroes abertos para o desenvolvimento de servicos baseados em
localizacao (Open Geospatial Consortium, 2014a). Com a importancia e abrangencia de seus
membros, a OGC consegue a aceitacao de seus padroes servindo de referencia para os
desenvolvedores, sendo assim, considerada a instituicao de maior importancia na
definicao de padroes abertos para sistemas baseados em localizacao, como e o caso do
LBS.
LBS e definido como “um servico sem fio sobre IP que utiliza informacao
geografica para atender um usuario movel. Qualquer servico de aplicacao que explora a
posicao de um terminal movel” (MABROUK et al., 2005). Um exemplo de uma aplicacao
dessas seria um aplicativo que mostre os restaurantes perto do usuario.
Para que um servico como esse seja possıvel alguns itens sao necessarios.
Segundo Vanjire et al. (2014), sao eles:
• dispositivo movel;
• aplicativo;
• rede de comunicacao;
• sistema de posicionamento;
• servidor com servico e dados.
Detalhando o exemplo de LBS citado anteriormente, esses itens podem ser
vistos da seguinte maneira: o usuario, de posse do seu smartphone (um dispositivo
movel) acessa um aplicativo desse aparelho, que por sua vez consulta a posicao do
usuario pelo GPS (sistemas de posicionamento) e utiliza a rede Wifi (rede de
comunicacao) para acessar um servidor remoto. O servidor recebe os dados de
posicionamento, faz uma consulta na sua base de dados espaciais, e retorna para o
aplicativo as informacoes dos restaurantes proximos ao usuario.
2.1.1 ARQUITETURA
Com os itens citados anteriormente, e possıvel montar uma arquitetura
generica de um LBS como e mostrado na Figura 1. Nesse exemplo e possıvel ver que o
dispositivo movel obtem sua posicao, por meio de um satelite e, por sua vez, faz uma
solicitacao (1 e 2), por meio de uma rede sem fio ou da rede de uma operadora movel, a
um servidor informando sua posicao. Esse servidor utiliza os dados da posicao do
dispositivo para consultar uma base de dados, que possui dados igualmente baseados em
localizacao, e retorna (3 e 4) o conteudo de interesse do usuario. Por exemplo, uma lista
de restaurantes perto da posicao do dispositivo movel, conforme pode ser visto na Figura
2.
Como e possıvel perceber nessa arquitetura, cada nova consulta do usuario
leva a uma requisicao pela internet para adquirir parte dos dados baseado na sua
7
Figura 1: Arquitetura generica de um LBS
Figura 2: Exemplo da interface de um sistema que utiliza um LBS
localizacao, ja que os dados nao sao armazenados no dispositivo. O que esta sendo
proposto neste trabalho e uma arquitetura como na Figura 3, no qual o dispositivo movel
se conectara a um servidor uma vez e fara um download de toda a base de dados
geoespacial (1 a 4). Depois disso, as consultas sao realizadas no proprio dispositivo (5 e
6). Como, por exemplo, fazer o download de todos os restaurantes disponıveis da cidade
do usuario e, dentro do proprio dispositivo, realizar as consultas sobre quais estao mais
proximos.
8
Figura 3: Arquitetura proposta de um LBS
2.1.2 DADOS GEOESPACIAIS
Dados espaciais sao a representacao de objetos espaciais feitos a partir de
pontos, linhas, superfıcies, volumes e ate objetos com mais dimensoes. Em geral, esses
dados sao atrelados a outros dados de natureza nao espacial (SAMET, 1995 apud
BUOHRNANN et al., 1990).
Assim como os dados espaciais, os dados geoespaciais referem-se a objetos
espaciais, porem relacionados a posicoes na superfıcie terrestre e atrelados a alguma
caracterıstica, ou fenomeno, nao espacial dessa regiao (SILVA, 2004; Open Geospatial
Consortium, 2014b). Alguns exemplos de dados geoespaciais sao: a regiao de um paıs
afetada por determinado clima, a regiao que ocupa uma cidade ou a localizacao de um
restaurante.
A forma mais elementar de representar um dado geoespacial e o ponto que e
utilizado para representar as retas e por sua vez sao utilizadas para representar os
polıgonos. Em se tratando da superfıcie do planeta Terra o par de coordenadas desses
pontos sao denominadas latitude e longitude. A latitude e a medida de distancia angular
entre norte e sul, variando entre 90◦graus e -90◦entre ambos, respectivamente. Longitude
e a medida da distancia angular a partir do Meridiano de Greenwich, sendo que a oeste
ela varia ate -180◦e a leste ate 180◦.
Conforme Rosero (2012), a representacao mais comum para latitude e
longitude e atraves da notacao de graus, minutos e segundos. Nesse formato o predio do
Instituto de Ciencia da Computacao da UFMT - localizado em Cuiaba-MT, Brasil - teria
o ponto (15◦36 30 S,56◦3 46 W), por exemplo. E possıvel, tambem, representar latitude
9
e longitude no formato de graus decimais, no qual o mesmo ponto seria representado
como (-15.608333, -56.062778).
Alem do par de coordenadas latitude e longitude, existem outras formas de
representar a posicao de um ponto no globo terreste. Uma delas e o Geohash, que
encontra-se explicado em mais detalhes na Secao 2.3.2.
2.2 ANDROID
O Android e um sistema operacional de codigo aberto para dispositivos
moveis mantido pela Google Inc. e pela Open Handseat Alliance. Ele contem todo um
conjunto de softwares para o gerenciamento e uso dos dispositivos moveis. E, alem
disso, atraves de seu SDK (Software Development Kit) e possıvel desenvolver aplicativos
e jogos, na linguagem Java, de forma completamente gratuita (Google Inc., 2014a;
MEURER, 2012).
Ele e o sistema operacional mais utilizado em smartphones na atualidade.
De acordo com o relatorio da IDC (2015), no primeiro quadrimestre de 2015 os
smartphones com Android representavam 78,0% do mercado mundial. E, segundo App
Brain (2014), a loja virtual de aplicativos e jogos para Android, Play Store1, possuıa na
epoca aproximadamente 1,4 milhoes de aplicativos e jogos.
2.2.1 ARQUITETURA
O Android possuı uma arquitetura em 4 camadas: kernel linux, bibliotecas
(libraries) e runtime, framework de aplicacao (application framework) e aplicacoes
(applications). Essas camadas podem ser vistas em mais detalhes na Figura 4 (BRAHLER,
2010; COMACHIO, 2011).
A camada kernel e um kernel linux adaptado para lidar com os requisitos
de um dispositivo movel, como: baixo consumo de energia, baixa disponibilidade de
armazenamento e memoria. Ele e o responsavel por se comunicar com o hardware.
Na segunda camada estao as bibliotecas, que sao as responsaveis por fornecer
acesso ao hardware para camada acima dela. Elas sao escritas em C e C++, como por
1https://play.google.com/store
10
Figura 4: Arquitetura Android. Fonte: (BRAHLER, 2010)
exemplo, a biblioteca Sqlite, que encontra-se melhor detalhanda na Secao 2.3. Na mesma
camada esta a Android Runtime, que e composta pela JVM (Java Virtual Machine) e pelas
bibliotecas basicas do Java. As aplicacoes Android rodam sobre essa JVM (BRAHLER,
2010).
A terceira camada e o framework de aplicacoes, escrita em Java. Essa
camada e responsavel por fornecer as interfaces abstratas em Java para as bibliotecas do
sistema, de forma que as aplicacoes possam acessar seus recursos (BRAHLER, 2010).
Nessa camada existem, por exemlplo, classes como a SQLiteOpenHelper, que faz uma
interface em java para a biblioteca Sqlite citada anteriormente.
Por fim, estao as aplicacoes, tanto as nativas do sistema operacional, quanto
as desenvolvidas por terceiros. E por meio delas, exclusivamente, que o usuario final
interage com o dispositivo movel.
11
2.2.2 RECURSOS DE UM LBS NO ANDROID
Dentre os muitos recursos do Android distribuıdos nessas 4 camadas, que
tem seu uso descrito na documentacao oficial, em Google Inc. (2014a), estao alguns
fundamentais para a construcao de um LBS. Todos eles estao disponıveis por meio das
APIs (do ingles, Application Programming Interface), que sao as interfaces abstratas
citadas anteriormente na descricao da camada framework de aplicacao.
Um dos recursos e o Location APIs, que abstrai a descoberta da posicao
geografica do dispositivo de acordo com os varios sensores que podem estar disponiveis
no dispositivo (GPS, rede wifi, torres de telefonia). Outro, e a API para operacoes de
rede, com varias classes para acesso de conteudo por uma rede de dados (wifi ou rede do
provedor movel, por exemplo). E ainda, ha a API para acesso a biblioteca SQLite,
utilizada no gerenciamento de bancos de dados.
2.3 SQLITE
SQLite e uma biblioteca que implementa um banco de dados relacional de
forma embutida na aplicacao. Diferente da maioria dos bancos de dados, onde existe um
processo dedicado para fornecer acesso a base de dados para a aplicacao cliente no SQLite
nao existe um processo dedicado para tanto, ou seja, a biblioteca que esta embutida na
aplicacao cliente, fornece o acesso ao banco de dados, que nada mais e do que um arquivo
no disco (OWENS; ALLEN, 2006; HIPP, 2014).
Dessa forma, nao e necessario fazer configuracoes administrativas ou de rede
para se ter acesso ao banco de dados e nao se tem a sobrecarga das chamadas de rede
(OWENS; ALLEN, 2006). Alem disso, como a banco de dados e composto por um unico
arquivo cross-plataform, existe uma grande facilidade na manutencao, backup e
implantacao. Principalmente para sistemas que devem rodar em multiplas plataformas
com poucas ou nenhuma modificacao (OWENS; ALLEN, 2006; HIPP, 2014).
A biblioteca SQLite e escrita em ANSI-C puro, podendo ser compilada por
qualquer compilador que aceite esse padrao. Ela e uma biblioteca pequena, em algumas
plataformas seu tamanho compilado pode chegar a menos de 500KB (HIPP, 2014).
Apesar de toda esse simplicidade, o SQLite implementa a maioria das
funcionalidades do padrao SQL (Structured Query Language). As poucas que nao sao
12
implementadas - RIGHT OUTER JOIN e FULL OUTER JOIN, por exemplo - estao
listadas em http://www.sqlite.org/omitted.html.O SQLite e de dominio publico,
sendo gratuito para qualquer uso, comercial ou privado e pode ter suas funcionalidade
expandidas atraves de extensoes (HIPP, 2014).
Devido a essas caracterısticas o SQLite e um banco de dados utilizado em
aplicacoes bastante conhecidas e em dispositivos embarcados. Ele e utilizado nos
navegadores Firefox, Google Chrome e Safari, no cliente do Skype e como banco de
dados padrao para aplicacoes do Android. Algumas linguagens, como PHP e Python,
possuem por padrao interfaces para a biblioteca SQLite. Uma lista de aplicacoes
conhecidas que utilizam SQLite pode ser encontrada em
http://www.sqlite.org/famous.html (HIPP, 2014).
O SQLite nao e um banco que consegue manipular dados espaciais. Para
lidar, de forma nativa, com consultas baseadas em latitude e longitude e necessario fazer
um consulta com os valores de mınimo e maximo da latitude e longitude. Dessa forma
pode-se obter como resultado todos os pontos geoespaciais dentro um retangulo formado
por valores mınimos e maximos de latitude e longitude. (HIPP, 2014).
Alem dessa abordagem, existe duas alternativas para fazer a consulta de
dados geoespaciais em um banco SQLite. A primeira consiste no uso de uma biblioteca
de codigo aberto, chamada Spatialite, que estende o SQLite e lhe confere a capacidade
completa de lidar com dados geoespaciais (SPATIALITE, 2014b). A segunda e o uso de
uma tecnica denominada Geohash, que converte latitude e longitude em um valor de
texto, mantendo determinada precisao, podendo ser utilizado para facilitar a
manipulacao e consulta dos dados geoespaciais (GEOHASH, 2014).
2.3.1 SPATIALITE
A SpatiaLite e uma biblioteca de codigo aberto, escrita na linguagem C, que
estende a SQLite, desenvolvida e mantida por Alessandro Furieri. Atualmente esta na
versao 4.2.0, sendo que a versao 4.1.0 e a atual estao sendo financiadas pela regiao da
Toscana, Italia (SPATIALITE, 2014a).
A biblioteca adiciona ao banco SQLite tipos de dados e funcoes SQL para
lidar com dados espaciais. A SpatiaLite esta, em sua maioria, em conformidade com as
especificacoes do OGC. Ela e disponibilizada nos termos de tres licencas MPL (Mozilla
13
Public License) 1.1, GPL (GNU General Public License) v2.0 ou superior e LGPL (GNU
Lesser General Public License) v2.1 ou superior (SPATIALITE, 2014a).
Alem de ser compilada para plataforma x86 ela tambem pode ser compilada
para Android, utilizando o Android NDK. Segundo Google Inc. (2014b), Android NDK
e um conjunto de ferramentas que permite implementar partes do seu aplicativo usando
linguagens de codigo nativo, como C e C++. Mais informacoes sobre o processo de
compilacao e uso no Android podem ser encontrados na Secao 3.3.
2.3.2 GEOHASH
Geohash e estrutura de dados espaciais hierarquica, inventada e colocada em
domınio publico por Gustavo Niemeyer. Nela, os valores de latitude e longitude sao
convertidos em uma sequencia de caracteres que representa uma area retangular do globo
terrestre onde o ponto espacial se encontra. O tamanho dessa area depende de quantos
caracteres sao utilizados para representar esse ponto (GEOHASH, 2014).
Para fazer isso, a representacao do globo terrestre e dividida em 32 partes.
Para cada uma dessas areas e atribuıda uma letra, sendo essa a primeira letra do Geohash.
Por sua vez, cada uma desas areas e dividida em outras 32 partes, dando origem a segunda
letra do Geohash. Esse processo se repete gerando uma representacao com sequencias de
caracteres cada vez maiores para areas cada vez menores. Considera-se assim a precisao
do Geohash como sendo a quantidade de caracteres utilizada para representa-lo.
Dessa forma, pontos que se encontrarem em uma mesma area, considerando
determinada precisao, terao o mesmo prefixo de Geohash. Por exemplo, os pontos
A(-15.609445, -56.073912), B(-15.608701, -56.063741) e C(-15.614952, -56.061531),
da Figura 5, possuem, respectivamente, os seguintes Geohashs: 6v0phn2hrhs9,
6v0phnx8sphz, 6v0phm3hr9ux.
Pode-se observar que os tres pontos possuem o mesmo prefixo ate o quinto
caractere, indicando que os tres pertencem a regiao designada pelo 5 primeiros caracteres
6v0ph, em verde no mapa. Porem, ao considerar os 6 primeiros caracteres, apenas os
pontos A e B estao na mesma regiao, 6v0phn, em azul no mapa.
Por sua caracterıstica hierarquica, o Geohash pode ser utilizado para
encontrar os pontos proximos fazendo-se uma consulta dos pontos que possuem
determinado prefixo. Existem casos extremos, como o do ponto A, em que o simples
14
Figura 5: Exemplo de pontos com Geohash.
aumento da precisao nao encontra todos os pontos proximo a ele, no caso os pontos a
esquerda. Para contornar esses casos a consulta deve ser feita para o prefixo de Geohash
do ponto e os prefixos vizinhos, totalizando 9 Geohashs consultados. Um exemplo disso
pode ser encontrado na secao 3.2 (GEOHASH, 2014).
Geohash pode ser utilizado, por exemplo, em bases de dados onde seja mais
facil consultas baseadas em um unico ındice, inves de dois (latitude e longitude). Ou
ainda, ser utilizado como parte da construcao de um ındice mais complexo, como o
proposto por Lee et al. (2014), onde o geohash e utilizado para uma filtragem dos pontos
candidatos a satisfazer uma consulta. Dessa maneira apenas esses pontos seriam
submetidos as funcOes espaciais que consomem mais tempo, diminuindo assim o tempo
da consulta.
15
CAPITULO 3
CONSULTAS ESPACIAIS
Durante este trabalho foi implementado um modulo para o aplicativo SSaldo
que exibe em um mapa os estabelecimentos proximos a posicao indicada pelo usuario que
aceita o seu cartao. A Figura 6 mostra a tela de exibicao de estabelecimentos.
Como biblioteca para fornecer os mapas para a plicacao, foi utilizada a
biblioteca do Google Maps, padrao do Android. Essa biblioteca utiliza mapas online, o
que pode parecer um contrassenso na busca de uma alternativa para manter dados
geoespaciais offline. Contudo a eliminacao da dependencia de um servidor dedicado para
armazenar e disponibilizar os dados geoespaciais ja se justifica. Alem disso, outras
alternativas de mapas, que sejam offline, podem ser utilizadas.
As consultas foram feitas sobre um conjuntos de 175 mil estabelecimentos,
para cada qual foram consultadas 5 informacoes: nome fantasia do estabelecimento,
latitude, longitude, endereco completo, identificacao do cartao aceitado. O tamanho da
base de dados variou de acordo com a forma de consulta utilizada.
Para definir o tamanho da regiao a ser consultada em volta do usuario, foi
considerado o desempenho do hardware durante os teste. Depois de carregados, do
banco para o mapa, os estabelecimentos e suas informacoes ficam em memoria, inclusive
de acordo com o zoom todos seriam exibidos na tela ao mesmo tempo. Dessa forma,
fazer uma consulta de uma area grande e permitir que o usuario navegue por ela deixou a
navegacao pelo mapa lenta. Em alguns lugares, como Sao Paulo, a navegacao ficou
Figura 6: Imagem da tela de exibicao de estabelecimentos.
inviavel devido a grande densidade de estabelecimentos que chegou em alguns locais a
aproximadamente 380 estabelecimentos por km2.
Por causa desse problema, a implementacao foi feita de forma que cada vez
que o usuario navega pelo mapa sao exibidos os estabelecimentos, em uma area menor,
proximos a posicao central do mapa. Isso gerou o requisito de que as consultas devem ser
rapidas o suficiente para nao comprometer a navegacao do usuario pelo mapa.
A implementacao das consultas foram feitas de tres maneiras distintas:
utilizando as informacoes de mınimo e maximo da latitude e longitude para filtrar as
colunas numericas de latitude e longitude, doravante chamada de consulta tradicional;
utilizando a biblioteca Spatialite; utilizando a tecnica de Geohash.
17
3.1 CONSULTA TRADICIONAL
A consulta tradicional consiste no uso das informacoes de maximo e mınimo
da latitude e longitude para consultar os estabelecimentos em uma area de formato
retangular. A consulta abaixo e uma exemplo de consulta nesse formato. Nas linhas 3 e 4
os estabelecimentos sao filtrados por sua latitude e longitude.
1 SELECT n o m e f a n t a s i a , l a t i t u d e , l o n g i t u d e , e n d e r e c o
2 FROM e s t a b e l e c i m e n t o i d x
3 WHERE l a t i t u d e <= −23.543701171875 AND l a t i t u d e >= −23.5601806640625
4 AND l o n g i t u d e <= −46.6259765625 AND l o n g i t u d e >= −46.658935546875
5 AND p r o d u t o i d = 8
Para realizar essa consulta a unica alteracao que foi feita no banco de dados
foi a criacao de um ındice nas colunas de latitude e longitude conforme SQL abaixo.
Dessa maneira o banco que ocupava 15,3 MB passou a ocupar 19,6 MB de espaco em
disco.
1 CREATE INDEX i d x l a t l o n g ON e s t a b e l e c i m e n t o (
2 l a t i t u d e ,
3 l o n g i t u d e
4 )
3.2 CONSULTA COM GEOHASH
Essa consulta utiliza o GeoHash do ponto para encontrar os pontos proximos a
ele. Par tanto, foi necessario o usu de uma biblioteca Java para fazer o calculo do Geohash
a partir da aplicacao. A biblioteca escolhida foi a geohash-java, disponıvel sobre licenca
LGLP em https://github.com/kungfoo/geohash-java. Com ela a aplicacao calcula
o Geohash do ponto que se deseja fazer a consulta e extrai o prefixo desse Geohash, de
acordo com a precisao desejada.
A precisao foi definida como 6, levando em consideracao o que foi exposto
no inıcio dessa secao sobre tamanho da area a ser consultada. O SQL a seguir mostra uma
consulta nesse formato.
1 SELECT n o m e f a n t a s i a , l a t i t u d e , l o n g i t u d e , e n d e r e c o
2 FROM e s t a b e l e c i m e n t o g e o h a s h
18
3 WHERE (
4 geohash g lob ” 6 gyf46 ∗” OR geohash g lob ” 6 gyf4d ∗” OR
5 geohash g lob ” 6 gyf49 ∗” OR geohash g lob ” 6 gyf48 ∗” OR
6 geohash g lob ” 6 gyf42 ∗” OR geohash g lob ” 6 gyf40 ∗” OR
7 geohash g lob ” 6 gyf41 ∗” OR geohash g lob ” 6 gyf44 ∗” OR
8 geohash g lob ” 6 gyf43 ∗” )
9 AND p r o d u t o i d = 8
Note que, conforme explicado na Secao 2.3.2, para evitar o problema com
casos extremos sao consultados o Geohash do ponto bem como todos os 8 Geohashs
vizinhos a esse. E importante perceber ainda que das tres tecnicas apresentadas, o
Geohash e a menos flexıvel. Nela, as regioes retangulares a serem consultadas sao fixas
de acordo com a precisao do Geohash, enquanto nas demais e possıvel definir os pontos
(latitude e longitude) das areas a serem consultadas.
Para a implementacao dessa consulta foi preciso criar uma nova coluna na
tabela do banco com o Geohash de cada ponto. Isso aumentou a necessidade de
armazenamento de 15,3 MB para 17,7 MB. Para melhorar a performance da consulta foi
criado um ındice no campo, o que fez o tamanho do aquivo do banco saltar para 21,2
MB.
3.3 CONSULTA COM SPATIALITE
A consulta com SpatiaLite funciona atraves de operacoes com tipos de dados
espaciais, ambos definidos pela propria biblioteca. Para utilizar a SpatiaLite em
dispositivos com Android e necessario adicionar o arquivo compilado da biblioteca na
aplicacao. Para a compilar a SpatiLite para Android a documentacao oficial recomenda
as instrucoes contidas no repositorio do projeto Geopaparazzi no GitHub
(https://github.com/geopaparazzi/libjsqlite-spatialite-android/wiki).
Alem das instrucoes de compilacao, o repositorio contem as bibliotecas ja
compiladas para Android, nas arquiteturas x86 e ARM. A versao da biblioteca utilizada
foi a 4.2.0, a mais recente. Quando adicionada no Android ela fara parte da segunda
camada da arquitetura Android apresentada na figura 4 da Secao 2.2.1.
Conforme visto tambem na Secao 2.2.1, e necessario uma interface em java
na terceira camada para que a aplicacao tenha acesso a uma biblioteca. Para a SpatiaLite
19
essa biblioteca e a javasqlite que tambem pode ser encontrada no repositorio do projeto
Geopaparazzi.
A consulta utilizando a SpatiaLite e a mais complexa das tres, mas tambem e
a mais flexıvel. Nela e criado um polıgono e a partir disso sao consultados quais pontos
encontram-se dentro desse polıgono. Durante as consultas foi utilizado um polıgono
retangular, para mante-la similar as outras consultas, mas poderia ser um circulo ou
mesmo ser utilizado o formato de um bairro ou cidade para retornar, dessa forma, todos
os estabelecimentos dentro deste territorio. Abaixo segue a consulta utilizando
SpatiaLite:
1 SELECT n o m e f a n t a s i a , l a t i t u d e , l o n g i t u d e , e n d e r e c o
2 FROM e s t a b e l e c i m e n t o
3 WHERE S T c o n t a i n s ( PolyFromText ( ’POLYGON( (
4 −46.6259765625 −23.543701171875 ,
5 −46.6259765625 −23.5601806640625 ,
6 −46.658935546875 −23.5601806640625 ,
7 −46.658935546875 −23.543701171875 ) ) ’
8 ) , p o n t o s p a t i a l )
9 AND p r o d u t o i d = 8
10 AND ROWID IN (
11 SELECT ROWID
12 FROM S p a t i a l I n d e x
13 WHERE f t a b l e n a m e = ’ e s t a b e l e c i m e n t o ’
14 AND s e a r c h f r a m e = PolyFromText ( ’POLYGON( (
15 −46.6259765625 −23.543701171875 ,
16 −46.6259765625 −23.5601806640625 ,
17 −46.658935546875 −23.5601806640625 ,
18 −46.658935546875 −23.543701171875) ) ’ ) )
Pode-se perceber pela consulta que existe uma nova coluna no banco,
chamada ponto spatial. Essa coluna e do tipo POINT, um tipo definido pela propria
Spatialite. Durante a consulta, um polıgono retangular e criado, utilizando a funcao
PolyFromText, e sao consultados todos os registros cujo ponto spatial esta contido no
polıgono, utilizando a funcao ST contains.
Para otimizar a consulta, foi feita a criacao de um ındice espacial. As linhas
de 10 a 18 do SQL acima referem-se ao uso desse ındice. De acordo com SpatiaLite
20
(2014a), o ındice espacial e tratado como uma tabela virtual. Seu uso se faz ao adicionar
o operador AND, na clausula WHERE da consulta, com uma consulta aninhada a essa
tabela virtual. Essa consulta pode filtrar, atraves do parametro search frame, os pontos
que, de acordo com o ındice, podem fazer parte do conjunto de pontos desejados. Dessa
maneira apenas esses pontos serao submetidos a funcao ST Contains, economizando
assim, processamento e consequentemente, tempo. Note que o polıgono passado no
paramero de consulta do ındice search frame e o mesmo utilizado durante a consulta, na
funcao ST Contains.
O arquivo da base de dados precisou ser criado com uma ferramenta da
propria biblioteca, inclusive pode-se perceber que varias tabelas auxiliares sao criadas no
momento da criacao da base. Depois de populada, a base ocupou 39,2 MB, sendo que
depois da criacao do ındice esse valor passou para 47,9 MB. Alem disso, por incluir o
arquivo da biblioteca compilada, o arquivo do aplicativo teve seu tamanho aumentado de
3,049 MB para 12,777 MB. Um comparativo do consumo de armazenamento das
implementacoes apresentadas pode ser visto no Capıtulo 4.
21
CAPITULO 4
ANALISE DOS RESULTADOS
Depois de realizadas as tres implementacoes foram feitos teste para calcular
o desempenho - tempo de reposta - de cada implementacao, alem disso foi feito um
comparativo do consumo de armazenamento de cada alternativa.
Tendo em vista que cada uma das tres consultas lida com os dados de forma
diferente, as consultas foram implementadas de forma que cada uma retornasse o mesmo
conjunto de dados. Para isso, utilizou-se como base para a implementacao menos flexıvel,
o Geohash, conforme exposto no Capıtulo 3. Dessa maneira, para todas as consultas foi
calculado o Geohash, com precisao 6. Entao, para a consulta tradicional e a SpatiaLite,
foram utilizados pontos que formam o retangulo dessa regiao de Geohash como parametro
para suas consultas. Dessa maneira as tres consultas retornavam os dados da mesma
regiao.
4.1 DESEMPENHO
Para os teste de desempenho foi utilizado um SmartPhone Motorola Moto G,
rodando Android 5.0.2, com processador de 1.2 GHz Quad Core, 1GB de RAM e 16 GB
de armazenamento interno. Foram entao escolhidos 4 pontos nos centros de grandes
cidades, sao eles: Sao Paulo (-23.552076, -46.641683), Rio de Janeiro (-22.914830,
-43.202200), Belo Horizonte (-19.922874, -43.944519) e Cuiaba (-15.598039,
-56.096395).
Os pontos foram escolhidos de forma a mostrar o comportamento de cada
implementacao com um porcao crescente de dados. A partir disso foram feitas 1000
consultas para cada ponto, com cada implementacao. Foi mensurado o tempo necessario
para executar a consulta e inserir os resultados em uma lista de objetos em Java. A Figura
7 mostra os resultados desses testes.
Figura 7: Duracao da consulta por quantidade de estabelecimentos.
E possıvel perceber, pelo grafico da Figura 7, que o desempenho da consulta
Tradicional e da Geohash foi muito similar com uma breve vantagem para segunda.
Enquanto a SpatiaLite teve um desempenho muito baixo em relacao as duas.
Diante disso, foram feitos testes com a consulta SpatiaLite, para verificar o
desempenho de seu indice. Testando a implementacao sem o uso do ındice, as consultas
demoravam em torno de 27 segundo no smartphone. Isso deixa claro que o desempenho
do indice e formidavel, ja que ele reduziu o tempo da mesma consulta para 450
milisegundos.
Dessa forma um ponto ser levantado para justificar esse baixo desempenho. A
SpatiLite e uma biblioteca muito robusta, tendo sido desenvolvida para executar diversas
operacao complexas em estruturas espaciais. Porem, devido a necessidade da aplicacao
23
ela foi subutilizada para consultar apenas uma area retangular do mapa. Isso foi feito
pela SpatiaLite utilizando uma funcao que calcula se uma estrutura espacial esta contida
dentro de outra, o que e muito mais complexo do que comparacoes entre numeros ou
texto, como e o caso das outras duas implementacoes.
Prova do alto custo computacional da funcao ST contains, utilizada para
verificar se uma estrutura espacial esta contida em outra, e o desempenho do ındice. De
acordo com SpatiaLite (2014a), o ındice espacial funciona como um filtro, reduzindo a
area total onde o resto da consulta vai ser executado. Quando a consulta - a funcao
ST contains - e executada sem ındice, ou seja, em todos os pontos, ela demora uma
quantidade muito maior de tempo, aproximadamente 27 segundos. Enquanto com o
ındice essa demora e de apenas 450 ms, porque a funcao e efetivamente aplicada a um
conjunto menor de dados.
Alem disso, uma demora de 450 ms, no caso com maior volume de dados
retornado, nao chega a ser um problema dependendo de como for utilizado. No caso da
implementacao do SSaldo, onde foi escolhido fazer uma consulta cada vez que o usuario
move o mapa, esse tempo realmente causou uma perceptıvel perda de fluidez na exibicao
dos dados na tela - levando em consideracao que ha ainda o tempo para os dados serem
efetivamente mostrados pela biblioteca de mapas. Contudo, para outras aplicacoes esse
tempo pode ser totalmente satisfatorio. Talvez o maior problema do uso da SpatiaLite na
aplicacao SSaldo seja sua necessidade de armazenamento, como sera visto em seguida.
4.2 ARMAZENAMENTO
A Figura 8 e um comparativo do custo total de armazenamento de cada
implementacao, tanto no tamanho do arquivo do banco de dados quanto no aplicativo em
si, conforme detalhado no Capitulo 3.
E possıvel destacar um consumo de armazenamento muito maior para
implementacao com SpatiaLite. Inclusive, diferente das demais, alem dos consumo com
o arquivos do banco de dados em si, existe um aumento no tamanho do arquivo da
aplicacao em si.
A possıvel justificativa para o tamanho maior acupado pela SpatiaLite e o
mesmo do seu desempenho. A alta complexidade da biblioteca faz com que ela necessite
24
Figura 8: Consumo de armazenamento de cada implementacao.
de muito mais espaco. O proprio ındice exige a criacao de tres novas tabelas, as quais
sao acessadas pela tabela virtual SpatialIndex. Quanto ao pequeno aumento da
implementacao de Geohash em relancao a implementacao tradicional, era esperado
considerando o aumento de uma coluna no banco.
Para reduzir o tamanho da base de dados para o usuario final uma alternativa
seria dividı-la em bases menores de acordo com a localizacao em que o mesmo deseja
fazer as consultas. Como, por exemplo, fornecer uma base de dados para cada estado.
Essa alternativa envolve uma maior complexidade de implementacao mas diminuiria os
requisitos de armazenamento, contudo, nao resolve um dos problemas no uso da
SpatiaLite: o aumento no tamanho do arquivo da aplicacao.
Esse aumento se torna um grande problema considerando o fluxo de
downloads e instalacao do aplicativo. O arquivo do aplicativo e baixado pelo usuario da
Play Store, sem a base de dados de estabelecimentos. Dessa forma ele pode ter acesso as
outras funcionalidades da aplicacao sem ter que fazer uma grande download - o que pode
ser incomodo ou mesmo impossıvel para o usuario devido a sua conexao de dados. Caso
queira utilizar a busca por estabelecimentos ele pode fazer o download separado da base
de dados quando tiver disponibilidade. Dessa maneira, aumentar o tamanho do arquivo
do aplicativo pode prejudicar a adesao ao aplicativo.
25
4.3 AVALIACAO
Tendo em vista os resultados acima, foi feita a escolha da implementacao
para o modulo do aplicativo SSaldo. Primeiramente, fica claro que o uso da biblioteca
SpatiaLite deve ser voltado a aplicacoes que realmente precisem utilizar as funcionalidade
de um banco de dados espacial, devido ao seu baixo desempenho e complexidade, em
comparado as outras alternativas. Esse nao e o caso do aplicativo, que deseja apenas
exibir na tela os pontos proximos ao usuario. Ainda assim, vale ressaltar que a biblioteca
possui um bom desempenho considerando a atividade complexa a que se propoe.
Quando as outras duas implementacoes, ambas tiveram um otimo
desempenho, contudo a tradicional se mostra mais adequada a aplicacao. Apesar da leve
vantagem da Geohash no desempenho da consulta, a consulta tradicional, por ser mais
flexıvel, permite consultas de areas retangulares arbitrarias, podendo assim consultar a
exata porcao da area que esta sendo exibida na tela do celular naquele momento.
Enquanto a Geohash forcaria um tamanho de grid fixo que seria maior que a area
exibida. Com isso, a implementacao tradicional reduz a quantidade de dados buscada do
banco, reduzindo o consumo de memoria da aplicacao e o tempo da consulta.
A escolha da forma como implementar um consultar geoespacial em um
dispositivo movel depende muito dos requisitos da aplicacao e de como a consulta vai
ser utilizada. O mais importante foi constatar que e totalmente viavel fazer as consultas
de forma offline na aplicacao, sem depender um servidor exclusivamente para isso.
26
CAPITULO 5
CONSIDERACOES FINAIS
Servicos baseados em localizacao sao um tipo de aplicacao emergente nos
dispositivos moveis. Sua arquitetura mais comum compreende o uso constante da
internet para buscar as informacoes baseadas na localizacao atual do usuario, mantendo
as consultas geoespaciais em um servidor remoto.
A arquitetura proposta nesse trabalho traz as consultas para dentro do
dispositivo movel, reduzindo assim a dependencia da aplicacao com um servidor remoto
e com a conexao com a internet.
Para tanto, foi feito um estudo das alternativas para o armazenamento e
manipulacao desses dados em dispositivos moveis, bem como a implementacao dessa
arquitetura, com uma base de dados real. Isso foi fundamental para validar a
aplicabilidade dessa arquitetura.
Para isso, foi feita a implementacao do modulo de estabelecimentos do
aplicativo SSaldo para Android. A implementacao foi feita de tres maneiras diferentes,
utilizando o maximo e mınimo da latitude e longitude, utilizando Geohash e a biblioteca
SpatiaLite.
Para a implementacao do SSaldo ficou claro que a primeira foi a mais
adequada. Porem, mais importante que isso, todas as tres se mostraram totalmente
viaveis para a implementacao de uma solucao de dados geoespaciais offline,
resguardadas as necessidades da aplicacao.
28
29
REFERENCIAS
App Brain. App Brain Stats Index. 2014. Disponıvel em:<http://www.appbrain.com/stats/stats-index>.
BRAHLER, S. Analysis of the android architecture. 2010.
BUOHRNANN, A.; GUNTHER, O.; SMITH, T. R.; WANG, Y. F. Design andimplementation of large spatial databases. 1990.
COMACHIO, V. Funcionamento de banco de dados em android: Um estudo experimentalutilizando sqlite. 2011.
GEOHASH. GeoHash Documentation. 2014. Disponıvel em: <http://geohash.org/>.
Google Inc. Android Documentation. 2014. Disponıvel em:<https://developer.android.com/guide/index.html>.
Google Inc. NDK Documentation. 2014. Disponıvel em:<https://developer.android.com/tools/sdk/ndk/index.html>.
HIPP, D. R. SQLite Documentation. 2014. Disponıvel em:<http://www.sqlite.org/docs.html>.
IDC. Worldwide Quarterly Mobile Phone Tracker. 2015. Disponıvel em:<http://www.idc.com/tracker/showproductinfo.jsp?prod id=37>.
KUMAR, S.; QADEER, M. A.; GUPTA, A. Location based services using android(lbsoid). In: IEEE. Internet Multimedia Services Architecture and Applications (IMSAA),2009 IEEE International Conference on. [S.l.], 2009. p. 1–5.
KUSHWAHA, A.; KUSHWAHA, V. Location based services using android mobileoperating system. International Journal of Advances in Engineering & Technology, I A ET Publishing House, v. 1, n. 1, 2011.
LEE, K.; GANTI, R. K.; SRIVATSA, M.; LIU, L. Efficient spatial query processing forbig data. framework, v. 7, n. 11, p. 4–12, 2014.
MABROUK, M.; BYCHOWSKI, T.; NIEDZWIADEK, H.; BISHR, Y.; GAILLET, J.;CRISP, N.; WILBRINK, W.; HORHAMMER, M.; ROY, G.; MARGOULIS, S. Opengislocation services (openls): Core services. OGC Implementation Specification, Citeseer,v. 5, p. 016, 2005.
MEURER, F. Desenvolvimento de um aplicativo para a criacao de um diario de lugeresutilizando gps e imagens da camera de dispositivos moveis com android. 2012.
Open Geospatial Consortium. About OGC. 2014. Disponıvel em:<http://www.opengeospatial.org/ogc>.
Open Geospatial Consortium. Glossario OGC. 2014. Disponıvel em:<http://www.opengeospatial.org/ogc/glossary>.
OWENS, M.; ALLEN, G. The definitive guide to SQLite. [S.l.]: Springer, 2006.
ROSERO, O. F. G. Sistema movel de monitoramento e treinamento para ciclista comsmartphone android. 2012.
SAMET, H. Spatial Data Structures. 1995.
SILVA, G. K. d. C. Implementacao de servicos baseados em localizacao utilizandoarquiteturas e padroes abertos. Biblioteca Digital da Unicamp, 2005.
SILVA, M. A. S. da. Mapas auto-organizaveis na analise exploratoria de dadosgeoespaciais multivariados. SILVA, v. 681, p. 019, 2004.
SPATIALITE. SpatiaLite Documentation. 2014. Disponıvel em:<https://www.gaia-gis.it/fossil/libspatialite/wiki?name=4.2.0-doc>.
SPATIALITE. SpatiaLite Homepage. 2014. Disponıvel em:<https://www.gaia-gis.it/fossil/libspatialite/index>.
VANJIRE, S.; KANCHAN, U.; SHITOLE, G.; PATIL, P. Location based services onsmart phone through the android application. provider, v. 3, n. 1, 2014.
30
