UNIVERSIDADE TECNOLOGICA FEDERAL DO PARANADEPARTAMENTO ACADEMICO DE INFORMATICABACHARELADO EM SISTEMAS DE INFORMACAO
GABRIEL FRANCISCO MARTINS LOYOLAMAYCOW THOMAZ MEIRA
PROPOSTA DE APLICACAO DE VISUALIZACAO DEDADOS FOCADA EM PLANEJAMENTO URBANO
ACESSIVEL
TRABALHO DE CONCLUSAO DE CURSO
CURITIBA
2018
GABRIEL FRANCISCO MARTINS LOYOLAMAYCOW THOMAZ MEIRA
PROPOSTA DE APLICACAO DE VISUALIZACAO DE
DADOS FOCADA EM PLANEJAMENTO URBANO
ACESSIVEL
Trabalho de Conclusao de Curso apresentado aocurso de Bacharelado em Sistemas de Informacaoda Universidade Tecnologica Federal do Paranacomo requisito parcial para obtencao do tıtulo deBacharel em Sistemas de Informacao.
Orientadora: Professora Dra. Nadia PuchalskiKozievitch
CURITIBA
2018
Ministério da EducaçãoUNIVERSIDADE TECNOLÓGICA FEDERAL DO PARANÁ
Câmpus CuritibaDiretoria de Graduação e Educação Profissional
Departamento Acadêmico de InformáticaCoordenação do Curso de Bacharelado em Sistemas de Informação
TERMO DE APROVAÇÃO
“PROPOSTA DE APLICAÇÃO DE VISUALIZAÇÃO DE DADOS FOCADA EMPLANEJAMENTO URBANO ACESSÍVEL”
por
“Gabriel Francisco Martins Loyola e Maycow Thomaz Meira”
Este Trabalho de Conclusão de Curso foi apresentado no dia 19 de Junho de 2018 como requisito parcial à
obtenção do grau de Bacharel em Sistemas de Informação na Universidade Tecnológica Federal do Paraná -
UTFPR - Câmpus Curitiba. O(a)(s) aluno(a)(s) foi(ram) arguido(a)(s) pelos membros da Banca de Avaliação abaixo
assinados. Após deliberação a Banca de Avaliação considerou o trabalho
________________________________________.
________________________________
Nádia Puchalski Kozievitch(Presidente - UTFPR/Curitiba)
________________________________
Leonelo Dell Anhol Almeida(Avaliador(a) 1 - UTFPR/Curitiba)
________________________________
Ricardo Dutra Da Silva(Avaliador 2(a) - UTFPR/Curitiba)
________________________________
Profa. Leyza Baldo Dorini(Professora Responsável pelo TCC – UTFPR/Curitiba)
_____________________________
Prof. Leonelo Dell Anhol Almeida(Coordenadordo curso de Bacharelado em
Sistemas de Informação – UTFPR/Curitiba)
“A Folha de Aprovação assinada encontra-se na Coordenação do Curso.”
AGRADECIMENTOS
A Deus, pelo dom da vida e por proporcionar a oportunidade e o privilegio de
realizar nossos objetivos, nos dando tambem saude e disposicao.
Aos familiares, por viabilizar a estrutura necessaria em toda a trajetoria nesta
graduacao.
A todos fazem parte do nosso dia-a-dia, tanto amigos quanto nossas amadas,
pela compreensao e apoio que nao faltaram em nenhum momento, mesmo naqueles mais
difıceis.
A nossa orientadora, por todo o empenho em disponibilizar seu tempo e conhe-
cimentos, nos guiando durante o desenvolvimento deste trabalho.
RESUMO
LOYOLA, G. F. M.; MEIRA, M. T.. PROPOSTA DE APLICACAO DE VISUALIZACAODE DADOS FOCADA EM PLANEJAMENTO URBANO ACESSIVEL. 67 f. Trabalhode Conclusao de Curso – Bacharelado em Sistemas de Informacao, Universidade Tec-nologica Federal do Parana . Curitiba, 2018.
O planejamento urbano tem como objetivo melhorar a vida das pessoas, e para que issose concretize e ideal que a prefeitura tenha acesso as informacoes sobre os problemasencontrados pela populacao no seu dia a dia. Este trabalho apresenta a proposta de duasaplicacoes com objetivo de auxiliar na consulta de dados levantados pela populacao e pelaprefeitura sobre condicoes de calcadas e rebaixamentos. A primeira consiste em uma API1
para acesso e manipulacao de dados de forma segura atraves de outras aplicacoes. Comfoco nas visualizacoes dessas informacoes, a segunda e uma aplicacao Web que permitea visualizacao clusterizada2 e a filtragem desses dados de forma que nao exija ao usuarionenhuma formacao tecnica para seu uso. Neste trabalho tambem realizou-se uma analisede um questionario sobre calcadas e rebaixamentos na cidade de Curitiba com objetivo decompreender melhor o problema estudado, assim como duas entrevistas com funcionariosdo IPPUC3 para coleta de informacoes sobre o que e utilizado atualmente por eles, testespraticos da aplicacao web e os resultados obtidos no desenvolvimento das aplicacoes.
Palavras-chave: planejamento urbano, visualizacao de dados, dados abertos
1Application Programming Interface - Interface de programacao de aplicacoes2Agrupamento de dados similares3Instituto de Pesquisa e Planejamento Urbano de Curitiba
ABSTRACT
LOYOLA, G. F. M.; MEIRA, M. T.. PROPOSAL OF DATA VISUALIZATION AP-PLICATION FOCUSED IN ACCESSIBLE URBAN PLANNING. 67 f. Thesis – BSc,Universidade Tecnologica Federal do Parana . Curitiba, 2018.
The urban planning has as goal to improve people’s life, and for this to happen it isideal that for the municipality to have access to information about problems found bythe population at their daily basis. This paper presents a proposal of two applicationswith the goal to aid the municipality and population gathered data about sidewalks andcurb ramps conditions. The first consists in an API1 to access and manipulate data in asafe manner through other applications. Focused on the clustered visualizations of theseinformations, the second one is a web application that allows the visualization and filteringof these data in a way that does not require technical background from the user using it.In this paper was also accomplished the analyzes of a questionnaire about sidewalks andcurb ramps in the city of Curitiba with the goal to understand better the studied problem,as well as two interviews with IPPUC2 technical employees to collect information aboutwhat is used by them nowadays, web application practical testing and the results achievedat the development of the applications.
Keywords: urban planning, data visualization, open data
1Application Programming Interface2Institute of Urban Planning and Research of Curitiba
LISTA DE FIGURAS
–FIGURA 1 Mapeamento de temas abordados e suas relacoes. . . . . . . . . . . . . . . . . 12–FIGURA 2 Representacao do uso de um SIG. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15–FIGURA 3 Interface usuario Easywheel. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17–FIGURA 4 Visao geral do sistema proposto por Kozievitch et al. (2016). . . . . . 18–FIGURA 5 Travessia com rebaixamento faltante (MINETTO et al., 2016). . . . 18–FIGURA 6 Interface do Taxivis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21–FIGURA 7 Mapa de entrada de refugiados na Africa Oriental em 2009. . . . . . . 22–FIGURA 8 Mapa de saıda de refugiados na Africa Oriental em 2009. . . . . . . . . . 23–FIGURA 9 Agrupamento de tipos de pontos de onibus diferentes na cidade deCuritiba. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24–FIGURA 10 Mapa de desembarques em tempo-real do Uber. . . . . . . . . . . . . . . . . . . 25–FIGURA 12 A integracao do SIG, dados abertos e outros modelos de banco dedados com os processos de planejamento adaptado de Yeh (1999) . . . . 27–FIGURA 13 Mapa bairro Tatuquara apresentando 17 camadas de dados. . . . . . . 30–FIGURA 14 Interfaces de Nascimento (2018) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31–FIGURA 15 Interfaces de Camenar e Almeida (2018) . . . . . . . . . . . . . . . . . . . . . . . . . . 32–FIGURA 16 Passos da metodologia utilizada. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34–FIGURA 17 Resumo das respostas das questoes 1. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38–FIGURA 18 Resumo das respostas das questoes 2. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38–FIGURA 19 Resumo das respostas das questoes 3. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39–FIGURA 20 Resumo das respostas das questoes 6. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39–FIGURA 21 Arquitetura geral da comunicacao entre os sistemas. . . . . . . . . . . . . . . 41–FIGURA 22 Diagrama de dados API Mao na Roda. . . . . . . . . . . . . . . . . . . . . . . . . . . . 42–FIGURA 23 Diagrama de Caso de Uso do sistema de visualizacao. . . . . . . . . . . . . 46–FIGURA 24 Visualizacao de pontos de problema clusterizados. . . . . . . . . . . . . . . . . 47–FIGURA 25 Visualizacao do historico de frequencias com filtro de data. . . . . . . . 48–FIGURA 26 Fluxo de autorizacao de requisicao JWT. . . . . . . . . . . . . . . . . . . . . . . . . . 49–FIGURA 27 Teste de requisicao de autenticacao da API Mao na Roda. . . . . . . . . 53–FIGURA 28 Teste de requisicao de frequencia de problemas da API Mao naRoda. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
LISTA DE TABELAS
–TABELA 1 Comparativo de aplicacoes de SIG . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19–TABELA 2 Comparativo de aplicacoes de Visualizacao de Dados . . . . . . . . . . . . . 26–TABELA 3 Comparativo de aplicacoes de Cidades Inteligentes e PlanejamentoUrbano . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
LISTA DE SIGLAS
API Application Programming Interface - Interface de programacao de aplicacoesONU Organizacao das Nacoes UnidasSIG Sistema de Informacao GeograficaIPPUC Instituto de Pesquisa e Planejamento Urbano de CuritibaSQL Structured Query Language - Linguagem de Consulta EstruturadaHTTP Hypertext Transfer Protocol - Protocolo de Transferencia de HipertextoGPS Global Positioning System - Sistema de Posicionamento GlobalUNHCR The United Nation Refugee Agency - Agencia de Refugiados das Nacoes UnidasURBS Urbanizacao de Curitiba S/ATIC Tecnologia da Informacao e ComunicacaoDAINF Departamento Academico de InformaticaJSON JavaScript Object Notation - Notacao de Objetos JavaScriptUTFPR Universidade Tecnologica Federal do ParanaJWT JsonWebTokenIHC Interacao Humano-Computador
SUMARIO
1 INTRODUCAO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101.1 OBJETIVOS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111.1.1 Objetivo Geral . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111.1.2 Objetivos Especıficos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111.2 JUSTIFICATIVA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121.3 ESTRUTURA DO TRABALHO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132 LEVANTAMENTO BIBLIOGRAFICO E ESTADO DA ARTE . . . . . . 142.1 SIG . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142.1.1 Aplicacoes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162.2 VISUALIZACAO DE DADOS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 192.2.1 Visualizacao espaco-temporal de dados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 202.2.2 Aplicacoes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 212.3 CIDADES INTELIGENTES E PLANEJAMENTO URBANO . . . . . . . . . . . . . . . . 262.3.1 Dados abertos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272.3.2 Acessibilidade . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 282.3.3 Aplicacoes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 283 METODOLOGIA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 343.1 REQUISITOS DO PROJETO DE SOFTWARE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 353.1.1 API Mao na Roda . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 353.1.2 Visualizacao Mao na Roda . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 354 DESENVOLVIMENTO E IMPLEMENTACAO . . . . . . . . . . . . . . . . . . . . . 374.1 QUESTIONARIOS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 374.1.1 Analise de resultados do questionario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 374.2 ENTREVISTAS REALIZADAS COM COLABORADORES DO IPPUC . . . . . . 404.3 IMPLEMENTACAO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 414.3.1 Arquitetura do sistema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 414.3.1.1 API Mao na Roda . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 414.3.1.2 Aplicacao Web “Mao na Roda” . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 464.3.1.3 Tecnologias utilizadas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 484.3.2 Testes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 504.3.2.1 Perfil dos participantes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 504.3.2.2 Roteiro . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 504.3.2.3 Analise dos resultados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 504.3.2.4 API . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 525 CONSIDERACOES FINAIS E TRABALHOS FUTUROS . . . . . . . . . . . 54REFERENCIAS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56Apendice A -- SQL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60Apendice B -- DOCUMENTACAO PARCIAL DA API MAO NA RODA 63Apendice C -- QUESTIONARIO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67C.1 CALCADAS E REBAIXAMENTOS NA CIDADE DE CURITIBA . . . . . . . . . . . 67
10
1 INTRODUCAO
O conceito de Cidades Inteligentes tem sido abordado e aplicado por muitas
cidades europeias, asiaticas e das Americas. No Brasil, algumas cidades ja caminham
nessa direcao, como Porto Alegre, Rio de Janeiro e Curitiba. Para a criacao de Cidades
Inteligentes, TICs1 sao aplicadas e disponibilizadas de forma adaptada as necessidades
e caracterısticas de cada cidade (WEISS, 2013). Uma das atitudes que a gestao publica
pode tomar para isso e a disponibilizacao de dados abertos. Com isso, o potencial de
compreensao e gerenciamento dos dados gerados e captados pelos orgaos pode ser melhor,
alem de aumentar a transparencia dos resultados da supervisao administrativa do Estado
(KUCERA; CHLAPEK, 2014).
No ambito dos desafios do planejamento urbano, a ONU2 recomenda o desen-
volvimento e a promocao da acessibilidade como um bem coletivo para o benefıcio de
todos (ONU, 2016). Nesse contexto, diversos esforcos ja estao sendo realizados para de-
senvolver servicos de planejamento de rotas para pessoas com deficiencia. Tais esforcos
envolvem o processamento de uma quantidade muito grande de dados como mapas, ima-
gens, informacoes detalhadas de transporte publico e feedback colaborativo de usuarios
(KOZIEVITCH et al., 2016).
Dentre os trabalhos envolvidos, Kozievitch et al. (2016) realizaram estudos na ci-
dade de Curitiba para desenvolver uma abordagem alternativa e inteligente para criacao de
rotas para usuarios de cadeiras de rodas com uso de Sistemas de Informacoes Geograficas
(SIGs). Dados abertos do IPPUC (Instituto de Pesquisa e Planejamento Urbano de Cu-
ritiba 3) e do Open Street Map4 foram utilizados para mapear a regiao do Batel, bairro
nobre de Curitiba, quanto a ruas, calcadas, travessias e rebaixamentos. Posteriormente,
Minetto et al. (2016) buscaram levar em consideracao tambem o feedback colaborativo
dos usuarios, diferentemente do trabalho relacionado anteriormente, que realizava o ma-
1Tecnologias da Informacao e Comunicacao2Organizacao das Nacoes Unidas3www.ippuc.org.br - Acessado em: 01 de outubro de 2017.4www.openstreetmap.org - Acessado em: 01 de outubro de 2017.
11
peamento das calcadas de forma automatica. Com isso, buscou-se criar um servico de
planejamento de rotas voltadas ao uso de pedestres, visando identificar problemas de
acessibilidade de forma eficiente, refinando o modelo utilizado com esses novos dados e
aprimorando o calculo das rotas usando um algoritmo de busca guloso.
Alem desses trabalhos, Camenar e Almeida (2018) identificaram a necessidade do
apoio das tecnologias no desenvolvimento da mobilidade urbana, atraves de uma aplicacao
colaborativa para apontar problemas nos rebaixamentos das calcadas de Curitiba. Essa
aplicacao foi tambem idealizada e modelada por Nascimento (2018), que avaliou algumas
aplicacoes semelhantes ja implementadas. Camenar e Almeida (2018) tambem constata-
ram a possibilidade de realizar o controle dos dados gerados pela primeira aplicacao citada
pela prefeitura da cidade, para um planejamento urbano visando melhorar o estado de
calcadas acessıveis, baseando-se no trabalho de Tsampoulatidis et al. (2013), propondo
algumas melhorias e adotando a acessibilidade como foco da aplicacao.
1.1 OBJETIVOS
1.1.1 OBJETIVO GERAL
Desenvolver um sistema baseado em visualizacoes de dados para auxiliar no pla-
nejamento da manutencao dos rebaixamentos de uma cidade, utilizando dados coletados
pelas interfaces de Camenar e Almeida (2018) e Nascimento (2018).
1.1.2 OBJETIVOS ESPECIFICOS
a) Realizar uma revisao bibliografica acerca dos conceitos abordados na Figura 1 e dos
trabalhos de Kozievitch et al. (2016), Minetto et al. (2016), Nascimento (2018) e
Camenar e Almeida (2018), que fomentam este trabalho.
b) Criar e adaptar o modelo de banco de dados em SQL que foi proposto por Camenar
e Almeida (2018), para a utilizacao do banco pela API.
c) Criar uma API RESTful5 como ferramenta de comunicacao entre as aplicacoes de
Camenar e Almeida (2018) e Nascimento (2018) e o banco de dados compartilhado,
mencionado no item anterior, que sera utilizada pelas interfaces mencionadas e pela
desenvolvida neste trabalho.
5Uma API RESTful e uma interface de programacao de aplicacoes que usa requisicoes HTTP paraobter, alterar, inserir e deletar dados.
12
d) Aplicar um questionario para compreender e relacionar o problema nas calcadas e
rebaixamentos da cidade de Curitiba e seus cidadaos;
e) Desenvolver um prototipo com visualizacoes de dados geograficos provenientes das
aplicacoes de Camenar e Almeida (2018) e Nascimento (2018).
f) Testar o prototipo da aplicacao para a validacao e avaliacao da interface e de suas
funcionalidades.
Figura 1: Mapeamento de temas abordados e suas relacoes.
1.2 JUSTIFICATIVA
De acordo com o IBGE (2017), estima-se que Curitiba possui aproximadamente
1,9 milhoes de habitantes. Dentre esses, quase 100 mil declaram-se com alguma deficiencia
motora, sendo quase 32 mil com deficiencia motora grave ou impossibilitadas de andar.
Com esses dados, e possıvel enxergar a demanda de um planejamento urbano referente a
acessibilidade para todos (CAMENAR; ALMEIDA, 2018).
Tal planejamento possui dois grandes desafios: (i) adaptar a cidade a acessibili-
dade universal, no ambito do deslocamento de pedestres visando a melhoria do tempo de
13
deslocamento e reducao de distancias percorridas; (ii) aumentar a capacidade tecnica de
gerenciamento de projetos de problemas urbanos, atraves de uma abordagem que auxi-
lie a gestao publica nas etapas de planejamento, fiscalizacao, regulacao, controle social e
participacao (CAU/BR, 2017).
Em seu trabalho, Nascimento (2018) implementou um prototipo de sugestao de
rotas para cadeirantes que permite que o usuario reporte problemas em rebaixamentos
ao longo desse trajeto, indicando sua localizacao e descrevendo o problema encontrado.
Camenar e Almeida (2018) desenvolveram um prototipo da interface da prefeitura, onde
seria possıvel a exibicao e gestao dos problemas reportados pelo prototipo de Nascimento
(2018). Com esses trabalhos, surgiu a demanda de unificar o acesso e modificacao dos
dados pelos respectivos prototipos. Mediante a situacao, o primeiro esforco realizado neste
trabalho foi implementar uma API para atender tal demanda, implementada de forma a
manter a seguranca e persistencia dos dados.
Para auxiliar o planejamento urbano, o presente trabalho implementou tambem
um prototipo que utiliza o conceito das visualizacoes de dados geograficos com cluste-
rizacao, pois o processamento cerebral em uma informacao visual e mais rapida do que
em uma informacao textual (FREIRE et al., 2014). Com essa abordagem, o prototipo pos-
sui uma interface que propicia a observacao, destaque e analise dos pontos crıticos quanto
a acessibilidade de cadeirantes, que poderiam ser sanados com melhorias provenientes de
acoes da gestao publica.
1.3 ESTRUTURA DO TRABALHO
Este trabalho esta dividido em cinco capıtulos. O proximo capıtulo abordada os
principais temas que permeiam os objetivos e suas respectivas aplicacoes. Em seguida,
apresenta-se a metodologia que foi utilizada. O quarto capıtulo descreve os esforcos de de-
senvolvimento do trabalho, incluindo o questionario, entrevistas realizadas e as aplicacoes
implementadas, testes feitos, resultados obtidos e dificuldades encontradas. Por fim, o
ultimo capıtulo e referente as consideracoes finais do estudo realizado.
14
2 LEVANTAMENTO BIBLIOGRAFICO E ESTADO DA ARTE
Este capıtulo realiza o levantamento dos principais conceitos em torno dos tra-
balhos bases e do trabalho a ser desenvolvido, representado na Figura 1.
2.1 SIG
Os Sistemas de Informacao Geografica, tambem conhecidos como SIG, tem como
funcionalidades essenciais a captura, armazenamento, consulta, analise e exibicao de dados
geoespaciais (CHANG, 2015). Dados geoespaciais descrevem nao so uma localizacao, mas
tambem outras informacoes relacionadas a ela. Tomando como exemplo uma rua, temos
sua localizacao geografica e seus atributos: comprimento, nome, direcao, entre outros.
Um SIG se destaca por permitir que um usuario administre dados de natureza
espacial. Para cada objeto referenciado em um mapa do solo, varios atributos podem ser
atrelados com dados fısicos e quımicos desse objeto (CHANG, 2015).
De acordo com Fox e Leidig (2014), SIGs podem ser divididos pelas seguintes
camadas:
• Camada de apresentacao: Interface com o usuario onde ele pode entrar com
parametros para suas consultas e visualizar os resultados;
• Camada de processamento: Trata-se da parte responsavel pela manipulacao das
entradas do usuario, que sao tratadas para poder se transformar em consultas ao
banco de dados, alem de tratar os resultados de acordo com o escopo da aplicacao
antes de apresentar o retorno ao usuario;
• Camada de dados: E onde ficam armazenados tanto os dados espaciais, como
polıgonos, pontos e arestas; quanto os dados semanticos, como o nome desses locais
e informacoes relacionadas a eles.
A Figura 2 apresenta um esquema cıclico do funcionamento de um SIG, por
15
Hamada e Goncalves (2007), o qual foi adaptado por Lara e Martins (2016) com o intuito
de demonstrar que, em casos de aplicacoes colaborativas, os usuarios se tornam tambem
fonte de informacao e parte do ciclo.
Figura 2: Representacao do uso de um SIG por Hamada e Goncalves (2007) eadaptada por Lara e Martins (2016)
Segundo Druck (2004) o modelo mais utilizado de bancos de dados geograficos e o
modelo geo-relacional, que mistura o paradigma relacional de um banco de dados habituais
com atributos e objetos geograficos. Geralmente facilmente instalados em SGBDs comuns
atraves de plugins, extensoes, etc.
Os objetos geograficos mais comumente usados por SIGs:
• Pontos: representados por um par ordenado de coordenadas espaciais; ex.: (x,y);
• Polilinhas: uma sequencia de pares ordenados que podem representar uma estrada,
rio, fronteiras, entre outros; ex.: [(3,4),(3,6),(2,2)] (HAMADA; GONCALVES, 2007);
• Polıgonos: uma sequencia de pontos, porem sendo o primeiro e o ultimo o mesmo
ponto, formando uma regiao fechada no plano; ex.: [(3,4),(3,6),(2,2),(3,4)] (HA-
MADA; GONCALVES, 2007);
• Amostras: uma tripla ordenada (x,y,z), onde (x,y) representa coordenadas como no
ponto e z representa um valor relacionado a essa coordenada. Geralmente utilizado
16
para representar varias informacoes que podem estar em uma mesma localizacao
especıfica (DRUCK, 2004);
• Grade regular: Representacao matricial em que cada elemento se associa a um
numero, utilizada para descrever regioes da superfıcie terrestre (NAMIKAWA, 1995);
• Imagem: Representacao matricial em que cada elemento esta associado a um valor
numerico inteiro (um mapa de bits), e que pode ser usada em conjunto com uma
grade regular ou um polıgono, mostrando a textura, vegetacao, areas de precipitacao
ou o que a imagem indicar sobre a regiao (LARA; MARTINS, 2016).
2.1.1 APLICACOES
Menkens et al. (2011) desenvolveram uma aplicacao movel social que permitia,
nao somente tracar rotas entre pontos, mas tambem que seus usuarios reportassem pro-
blemas de acessibilidade em seu caminho na cidade de Berlim. Alem de visualizar bar-
reiras, era possıvel verificar outras marcacoes reportadas pelos usuarios, como banheiros
acessıveis ou vagas para pessoas com deficiencia. A Figura 3 apresenta as interfaces dessa
aplicacao, com as respectivas funcionalidades mencionadas. Tal aplicacao tambem levava
em consideracao diferentes nıveis de dificuldade de locomocao no calculo da rota para
seus diferentes tipos de usuarios. Easywheel foi desenvolvido para a plataforma Android e
possui uma arquitetura que utiliza informacoes de acessibilidade adquiridas pela API do
OpenStreetMap para alimentar seus dados sobre pontos de interesse, e ao mesmo tempo
ja atualizava a base de dados com dados provenientes dos usuarios da Easywheel. Mas na
aplicacao movel em si, o motor de mapas para exibicao das rotas que era utilizado era o
GoogleMaps.
Sumida et al. (2012) propuseram um sistema de navegacao para cadeira de rodas
manuais baseado em dados de barreiras, adquiridos com a utilizacao de sensores em
cadeiras de roda eletricas pela cidade de Toquio. Para gerar as rotas, foi considerado o
nıvel de esforco que um cadeirante precisaria realizar, tambem o espaco disponıvel para a
passagem de uma cadeira de rodas, tracando assim rotas mais eficientes para os usuarios
cadeirantes, que era o foco de sua pesquisa. Devido a dificuldade do meio de coleta de
dados, o que demanda um grande esforco para o mapeamento da regiao, esse recurso e
uma alternativa difıcil de ser aplicada em escalas maiores, como uma cidade ou distrito.
Mourcou et al. (2013) apresentaram um estudo de caso em algumas ruas de
Crolles, na Franca, onde desenvolveram uma aplicacao movel para coleta de informacoes
17
Figura 3: Interface usuario Easywheel.
Fonte: (MENKENS et al., 2011)
usando sensores do proprio aparelho celular, como aceleracao, desaceleracao, inclinacao,
orientacao, velocidade e posicao GPS. Depois da coleta, esses dados foram extraıdos e
usados como parametros para a geracao de rotas. Apesar de transpor a dificuldade da
coleta de dados como a de Sumida et al. (2012), a qual necessita de uma cadeira de
rodas eletrica adaptada, utilizar um smartphone, Mourcou et al. (2013) nao integrariam
a sua aplicacao um gerador de rotas, que pode ser implementado posteriormente em um
computador ou no proprio smartphone.
Como comentado no capıtulo 1, Kozievitch et al. (2016) desenvolveram um metodo
para planejar de rotas para cadeirantes utilizando SIG. Nesse trabalho foi realizada uma
abordagem diferenciada, levando em consideracao as calcadas em vez das ruas. Com isso,
localizaram possıveis areas de interseccao entre elas e tambem definiram um criterio de
atribuicao de pesos as arestas. Uma aresta poderia ter pesos diferentes temporariamente,
devidos a algum obstaculo presente no caminho, como uma obra ou um rebaixamento de-
feituoso. A Figura 4 mostra os passos seguidos por Kozievitch et al. (2016) para chegarem
neste modelo.
18
Figura 4: Visao geral do sistema proposto por Kozievitch et al. (2016).
Na continuacao do trabalho de Kozievitch et al. (2016), Minetto et al. (2016)
argumentaram que para um servico de planejamento de rotas realıstico e necessario que
exista o feedback colaborativo dos usuarios, possibilitando a identificacao de problemas
de acessibilidade. Minetto et al. (2016) refinaram o grafo gerado usando esses dados
colaborativos, removendo arestas do grafo que nao representavam um caminho real para
um cadeirante, como apresentado na Figura 5. Isso resultou em um grafo que possuıa
caminhos realmente muito custosos aos cadeirantes ou ate impossıveis de ser realizados,
dependendo do ponto de partida e de destino.
Figura 5: Travessia com rebaixamento faltante.
Fonte: (MINETTO et al., 2016)
A ideia deste projeto e proporcionar um gerenciamento dessas arestas pela pre-
feitura, verificando historicamente o comportamento das mesmas nas diversas regioes da
cidade.
19
A Tabela 1 apresenta um comparativo das aplicacoes, salientando as vantagens
e desvantagens de cada uma nos quesitos: colaboracao do usuario, uso de dados abertos,
publico-alvo e recursos de hardware necessarios para o usuario da aplicacao.
Tabela 1: Comparativo de aplicacoes de SIG
Menkens
et al. (2011)
Sumida
et al.
(2012)
Mourcou
et al. (2013)
Kozievitch
et al. (2016)
e Minetto
et al. (2016)
Este projeto
Colaborativo X X X
Dados abertos X X
Voltado a
diversos tipos
de deficiencia
motora
X X N/A
2.2 VISUALIZACAO DE DADOS
Ward et al. (2010) definem visualizacao como a comunicacao de informacao
usando representacoes graficas. Imagens tem sido utilizadas como mecanismo de comu-
nicacao muito antes do estabelecimento de uma linguagem escrita. Uma unica imagem
pode conter uma infinidade de informacoes e pode ser processada muito mais rapidamente
pelo sistema perceptivo humano em comparacao a um texto; imagens tambem podem ser
independentes de uma linguagem local, assim como um grafico ou um mapa pode ser
compreendido por um grupo de pessoas sem uma lıngua em comum.
O design de uma visualizacao depende muito do tipo de dado disponıvel e do que
o usuario deseja extrair desse dado. Esses podem vir de uma grande variedade de fontes,
tambem podem apresentar-se em uma estrutura simples ou complexa. O usuario pode
querer usar a visualizacao para exploracao, para confirmar uma hipotese ou apresentar
o resultado de uma analise. Exemplos interessantes de serem representados visualmente
sao anomalias, agrupamentos e tendencias (WARD et al., 2010).
Para visualizar dados, e preciso definir um mapeamento dos dados a serem apre-
sentados. Ha inumeras maneiras de alcancar esse mapeamento. A interface do usuario
consiste em componentes, alguns dos quais lidam com dados que necessitam ser inseridos,
apresentados, monitorados, analisados e computados. Esses componentes de interfaces
20
geralmente sao simples caixas de dialogos, mas eles podem ser representacoes visuais de
dados para facilitar as selecoes requeridas pelos usuarios. Visualizacoes podem prover
mecanismos para apresentacao de dados e tarefas em formatos mais intuitivos e visuais
para os usuarios realizarem suas tarefas (WARD et al., 2010).
2.2.1 VISUALIZACAO ESPACO-TEMPORAL DE DADOS
De acordo com (ELLIS; MANSMANN, 2010) dados espaciais pode ser definidos
como dados com referencias no mundo real, como medidas geograficas, dados de posicio-
namento de GPS e dados de aplicacoes sensoriais remotas; basicamente dados que podem
ser representados em um mapa ou grafico. Ja dados temporais trabalham em funcao do
tempo, ou seja, o valor dessas variaveis podem mudar com o decorrer do tempo. Im-
portantes tarefas de analise de dados incluem a identificacao de padroes, correlacoes e
tendencias sobre itens sobre o tempo. Em conjunto esses dados, que sao baseados tanto
no tempo quanto no espaco, geram um outro nıvel de complexidade para os analistas que
desejam extrair conhecimento deles.
Problemas espaco-temporais sempre fizeram parte do dia-a-dia em sociedade. A
maioria de nossas decisoes sao baseadas em onde e quando estamos. Quando o escopo
de tais tomadas de decisoes excedem a area diretamente observavel, geralmente utiliza-
mos mapas como recurso visual. Essas representacoes imperfeitas da realidade servem
como modelos adequados para a solucao de problemas e tomadas de decisao. Mapas nao
servem somente para orientar geograficamente as pessoas, mas tambem para auxiliar a
compreender eventos e realizar descobertas (ELLIS; MANSMANN, 2010).
Dados temporais e espaciais sao diferentes dos demais dados e devem ser ana-
lisados e tratados de forma diferenciada para geracao de conhecimento, como feito por
Gilbert (1958) ao analisar o mapa do Dr. John Snow e outros mapas sobre doencas na
Inglaterra.
Peuquet (1994) determina tres classes de consultas em sua tipologia:
• identificar um conjunto de objetos em um dado local e tempo;
• dado um tempo e um conjunto de objetos, descrever os locais ocupados pelos objetos;
• descrever os tempos que um conjunto de objetos ocupam em um determinado con-
junto de localizacoes.
21
2.2.2 APLICACOES
Ferreira et al. (2013) utilizaram uma abordagem visual para poder dar acesso a
consultas de dados abertos geograficos sobre rotas de taxis da cidade de Nova Iorque.
Tal abordagem permitia a utilizacao por pessoas que nao tenham necessariamente co-
nhecimentos tecnicos da area da computacao. Esse sistema e utilizado hoje em dia pelo
departamento de transportes da cidade de Nova Iorque e pela comissao de taxis e limu-
sines, os quais elogiaram sua usabilidade e desempenho. Essa aplicacao foi otimizada
pois Ferreira et al. (2013) desenvolveram uma base de dados unica deles para poder lidar
eficientemente com dados geograficos de tamanha complexidade. Podemos ver na Figura
6B as possibilidades de consultas espaciais usando delimitacoes em polıgonos, pesquisas
por codigos postais ou por bairros definidos pelo usuario. Filtros temporais tambem estao
presentes na Figura 6A. Geracao de filtros visuais e estatısticas obtidas sao apresentados
na Figura 6C e Figura 6D.
Figura 6: Interface do Taxivis (FERREIRA et al., 2013).
22
“Mapeamento dos movimentos dos refugiados ao redor do mundo” e um projeto
da Universidade de Zurich para a Agencia Suica de Desenvolvimento e Cooperacao que
tem como objetivo demonstrar informacoes espaco-temporais em uma visualizacao inte-
rativa que possui elementos de storytelling e permitindo acesso aos dados fornecidos pela
UNHCR1 sobre a movimentacao mundial de entrada e saıda dos refugiados em certas
regioes desde o fim da Guerra Fria (BELTRAN et al., 2017).
Figura 7: Mapa de entrada de refugiados na Africa Oriental em 2009.
Fonte: (BELTRAN et al., 2017)
O mapa interativo possibilita consultas aos dados, como escolher o ano e se esta
querendo saber informacoes de entrada, Figura 7, ou dados de saıda, Figura 8, dos refu-
giados do paıs atraves de um switch2 na parte superior do mapa. A espessura das setas
e proporcional a quantidade de pessoas. Tambem traz informacoes sobre os principais
paıses de origem destes refugiados em um grafico de barra.
1Agencia de refugiados das Nacoes Unidas - http://www.unhcr.org/ - Acessado em 05 de novembrode 2017.
2switch - botoes para troca de valores em determinado contexto, nesse caso utilizado para filtrar avisualizacao.
23
Figura 8: Mapa de saıda de refugiados na Africa Oriental em 2009.
Fonte: (BELTRAN et al., 2017)
Vila et al. (2016) realizaram um trabalho de integrar diversas bases de dados
abertos, como IPPUC, URBS3, Open Street Map e Google Maps, todas relacionadas a
mobilidade urbana da cidade de Curitiba. Tendo como desafio criar uma interface de
visualizacao e consulta unica que permitisse demonstrar esses dados integrados. Vila et
al. (2016) tambem apresentaram visualizacoes utilizando clusterizacao de dados por k-
means e pelo algoritmo de clusterizacao de marcacoes, como pode ser visto na Figura 9,
metodos que facilitam a visualizacao de grandes massas de dados urbanos.
3Urbanizacao de Curitiba S/A - empresa responsavel pelos onibus da cidade de Curitiba.
24
Figura 9: Agrupamento de tipos de pontos de onibus diferentes na cidade de Curi-tiba.
Fonte: (VILA et al., 2016)
Belmonte (2016), engenheiro de software da Uber4, diz que foi implementado no
inicio de 2015 um time de visualizacao de dados dentro da empresa, tendo como objetivo
principal entregar inteligencia atraves do desenvolvimento de ferramentas de analise visual
de dados exploratorios. Sua aplicacao gera bilhoes de dados de localizacao diariamente,
e a nao utilizacao desses dados e uma oportunidade perdida de compreender melhor o
seu negocio e produto. Eles desenvolveram um framework chamado react-map-gl5, com o
objetivo de gerar visualizacoes de dados em camadas sobrepondo os mapas, o que permite
ver uma quantidade de dados massiva em um navegador de forma interativa e dinamica.
Na Figura 10 tem-se uma ideia da quantidade dados que eles conseguem lidar diariamente.
No caso a imagem representa onde o cursor do mapa esta, o numero de pessoas deixadas
naquela localizacao e a origem delas.
4Empresa de transporte urbano privado.5https://github.com/uber/react-map-gl - Acessado em: 15 de Outubro de 2017.
25
Figura 10: Mapa de desembarques em tempo-real do Uber.
Fonte: (BELMONTE, 2016)
Na Figura 11 podemos ver uma comparacao entre a movimentacao de carros
de viagens normais e a modalidade UberPool6, mostrando que gera menos trafego nas
regioes centrais, pois nessa modalidade, ha mais pessoas usando menos veıculos. Esse
recurso visual auxilia em tomas das de decisao, como a de investir mais nessa modalidade
de transporte.
Figura 11: Esquerda: Viagens de Uber normais gerando trafego no centro. Direita:Mesma quantidade de pessoas, mas usando a modalidade UberPool.
Fonte: (BELMONTE, 2016)
Na Tabela 2, pode-se verificar as vantagens e desvantagens de cada aplicacao
quanto a colaboracao dos usuarios, ao uso de dados abertos, a interatividade das consultas
6Consiste em uma modalidade onde mais de uma pessoa anda no veıculo ao mesmo tempo para ir emlocais diferentes mas na mesma rota.
26
e se permite que essas sejam de especie espaco-temporal. Alem disso, esta tabela apresenta
o que esta proposta abrange.
Tabela 2: Comparativo de aplicacoes de Visualizacao de Dados
Ferreira
et al.
(2013)
Beltran
et al.
(2017)
Vila et al.
(2016)
Belmonte
(2016)Este projeto
Colaborativo X X
Dados abertos X X X X X
Interatividade X X X X
Consultas
espaco-temporaisX X X X
2.3 CIDADES INTELIGENTES E PLANEJAMENTO URBANO
Atualmente, as grandes cidades sao protagonistas da economia global e, conse-
quentemente, apresentam diversas caracterısticas da globalizacao, sejam elas positivas,
como a concentracao de fluxo monetario, a concentracao e expansao dos servicos e do se-
tor manufatureiro ou tambem negativas, como a precariedade ou mesmo a falta de alguns
servicos basicos, como educacao, saude e mobilidade (WEISS et al., 2015).
Nesse sentido, a internet e os seus servicos vem tomando grande importancia
quando se trata de inovacao nos diversos topicos de gestao publica. As Cidades Inteligentes
buscam envolver a tecnologia e os servicos direcionados ao usuario, para que esse seja parte
primordial no avanco da pesquisa e da inovacao aplicada (SCHAFFERS et al., 2011).
Reforcando a ideia, Weiss et al. (2013) afirmam que a utilizacao das TICs propor-
ciona uma consideravel transformacao no padrao de gestao das cidades, trazendo muitas
melhorias no ponto da eficiencia e desempenho gerencial. Alem disso, essa pratica estimula
tambem a transparencia e interacoes entre o governo e seus cidadaos.
Yeh (1999) resume o processo do planejamento urbano em oito etapas. Sao elas:
(i) definicao dos objetivos; (ii) levantamento do inventario de recursos; (iii) analise de
situacoes; (iv) modelagem e projecao; (v) desenvolvimento das opcoes do planejamento;
(vi) selecao das opcoes planejadas; (vii) implementacao do planejamento; (viii) avaliacao,
monitoramento e feedback do planejamento.
Quando se trata de planejamento urbano, um SIG pode auxiliar em todas as
27
suas etapas com dados e algumas tecnicas, como por exemplo a visualizacao de dados
(Figura 12). Porem para atender a demanda de cada etapa, e necessario que esse atue
em conjunto com outras bases de dados, tecnicas e modelos diferentes (YEH, 1999). Para
complementar o SIG, uma alternativa e o uso de dados abertos, que sera melhor detalhado
na proxima secao.
Figura 12: A integracao do SIG, dados abertos e outros modelos de banco de dadoscom os processos de planejamento.
Fonte: Adaptado de Yeh (1999)
2.3.1 DADOS ABERTOS
Dados sao definidos como abertos se nao existem restricoes de acesso a qualquer
pessoa, a qual pode utiliza-los, modifica-los e compartilha-los com qualquer intuito, desde
que conserve-se a abertura e origem desses dados (KNOWLEDGE, 2017).
Eaves (2009) propos tres leis a serem seguidas no ato de abertura de dados:
1. Se o dado nao pode ser encontrado e indexado na Web, ele nao existe;
2. O dado nao podera ser aproveitado caso nao esteja aberto e disponıvel em formato
28
compreensıvel por maquina;
3. Se houver algum dispositivo legal que nao permita a replicacao do dado, ele se torna
inutil.
Alem desses pontos, e importante ressaltar a presenca das caracterısticas de dados
abertos presentes em legislacao no Brasil, como na Lei Complementar 131/2009 (Lei da
Transparencia)7, que determina a disponibilizacao em tempo real de informacoes financei-
ras e orcamentarias da Uniao, dos Estados, do Distrito Federal e dos Municıpios, e na Lei
12.527/2011 (Lei de Acesso a Informacao)8, que preve a disponibilizacao de informacoes
publicas a qualquer pessoa, seja ela fısica ou jurıdica, sem necessidade de justificar o
acesso aos dados.
2.3.2 ACESSIBILIDADE
A acessibilidade, no contexto das calcadas e rebaixamentos, e um conceito que
aborda a relacao entre transporte e uso do solo para que diferentes tipos de pessoas
desenvolvam suas atividades (JONES, 1981). Nesse mesmo contexto, a acessibilidade
pode ser considerada tambem como a quantidade de esforco despendido pelo pedestre
nessa acao (AGUIAR, 2010).
Embora a acessibilidade seja um tema que tem sido discutido com maior enfase
nos estudos de planejamento e transporte em todo o mundo, a maioria das cidades ainda
nao consegue garantir infraestrutura adequada a todos os cidadaos. Essa situacao se
agrava dependendo de suas necessidades de locomocao. Quando se trata do nıvel de
acessibilidade nas calcadas, estes espacos publicos apresentam frequentemente diversas
situacoes (barreiras) que dificultam ou impedem a mobilidade dos pedestres, em especial
para as pessoas com dificuldade de locomocao (cadeirantes ou que usam outras instru-
mentos de auxılio a locomocao, como andadores, muletas etc.) (AGUIAR, 2010).
2.3.3 APLICACOES
Lab (2015) e uma aplicacao Web e mobile voltada a avaliacao da acessibilidade
dos estabelecimentos, como restaurantes, shoppings dentre outros. De forma colaborativa,
a aplicacao permite que o usuario encontre o estabelecimento desejado, avalie quanto ao
7http://www.leidatransparencia.cnm.org.br/ - Acessado em: 08 de novembro de 2017.8http://www.acessoainformacao.gov.br/assuntos/conheca-seu-direito/a-lei-de-acesso-a-informacao -
Acessado em: 08 de novembro de 2017.
29
grau de acessibilidade, acesse as avaliacoes de outros usuarios e compartilhe sua avaliacao
nas redes sociais. A empresa desenvolvedora tambem promove uma especie de maratona
com premios em dinheiro para fomentar a colaboracao dos usuarios, que podem formar
grupos e aumentar o numero de avaliacoes realizadas. Porem, como o aplicativo armazena
somente informacoes sobre estabelecimentos, nao e possıvel estabelecer rotas nem obter
informacoes sobre a acessibilidade das calcadas que compoem o trajeto ate os mesmos.
Em 2015, a Prefeitura da Cidade do Rio de Janeiro promoveu o “Desafio Rio
Apps” para incentivar o desenvolvimento de aplicativos que promovem o acesso a in-
formacao e assim tornando a cidade mais inteligente (JANEIRO, 2015). O vencedor desse
desafio foi o Jump Park 9, um aplicativo que permitia que proprietarios de estacionamentos
cadastrassem diversas informacoes sobre seu estabelecimento e servicos prestados, assim
os motoristas poderiam buscar o estabelecimento que mais atenderia as suas expectativas
e perder menos tempo nas ruas e, em consequencia, reduzindo o congestionamento das
ruas. Atualmente esse aplicativo Jump Park Gestor e pago por ter se tornado um sistema
completo de gerenciamento de estacionamento.
Barczyszyn (2015) realizou uma integracao de diversos dados abertos espaco-
temporais providos pela IPPUC, como informacoes sobre arruamento, educacao, hidro-
grafia, limites legais, religiao, saude e transporte em um banco de dados georreferenciado.
Esses dados possibilitaram fazer consultas que relacionam essas diferentes abordagens de
forma mais facilitada e, inclusive, mostrar essas informacoes em um mapa, como pode-
mos ver na Figura 13, onde temos 17 camadas de dados diferentes referentes ao bairro
Tatuquara. Como dito na secao 2.2, esse tipo de visualizacao leva a uma compreensao
mais facilitada das informacoes por pessoas que nao precisam ser da area da computacao
para entender esses dados.
9http://jumppark.com.br/ - Acessado em 14 de novembro de 2017
30
Figura 13: Mapa bairro Tatuquara apresentando 17 camadas de dados.
Fonte: (BARCZYSZYN, 2015)
Nascimento (2018) realizou a modelagem de uma aplicacao movel que utilizasse
dados abertos do IPPUC, computados atraves do Open Street Map, para exibir o plane-
jamento de rotas para cadeirantes, passando pelas calcadas da cidade de Curitiba. Tais
rotas sao fornecidas por uma API desenvolvida em Barczyszyn et al. (2017), que calcula
o melhor caminho conforme o metodo de Minetto et al. (2016). Esse planejamento e
baseado tanto no estado dos rebaixamentos e calcadas quanto no tipo da deficiencia que o
usuario tem. As rotas seriam constantemente melhoradas na medida em que um usuario
contribuısse com o feedback sobre algum problema em algum trecho da rota percorrida.
Na Figura 14, podemos visualizar alguns casos de uso. Em A, o usuario busca o
destino e sao dadas ate tres rotas baseadas em sua localizacao, indicando o grau de aces-
sibilidade dos segmentos com cores, sendo azul acessıvel, amarelo parcialmente acessıvel
e vermelho nao acessıvel. Em B, o usuario pode obter informacoes mais detalhadas sobre
cada segmento. Ja em C, o prototipo permite o reporte de um problema em determinado
segmento da rota, inserindo algumas informacoes e, se desejar, uma foto do local.
Essa aplicacao e voltada somente para os usuarios cadeirantes, ou seja, os bene-
ficiados desse planejamento. Por isso, nao e possıvel verificar os pontos com problemas
fora de uma rota especificada, nao sendo possıvel verificar grandes areas, como bairros ou
31
regioes da cidade.
Figura 14: Interfaces de Nascimento (2018)
Em seu trabalho, Camenar e Almeida (2018) desenvolveram um prototipo de
aplicacao que possibilitaria a prefeitura a visualizar a localizacao de calcadas ou rebaixa-
mentos com problemas. Na Figura 15 constam duas telas da interface desse prototipo.
A Figura 15A ilustra a interacao do usuario ao clicar em um marcador, que
representa um reporte do usuario do prototipo de Nascimento (2018). Nessa interacao,
o usuario pode ver os detalhes do problema reportado, marca-lo como solucionado e
adicionar uma descricao para essa solucao. Ja na tela a direita, o caso de uso seria
quando a prefeitura realiza uma solucao ou melhoria em uma calcada ou rebaixamento
nao reportado pelo prototipo de Nascimento (2018). Nesse caso, o usuario seleciona se a
obra e realizada em um rebaixamento ou calcada, em seguida descreve o problema a ser
resolvido pela obra.
32
Figura 15: Interfaces de Camenar e Almeida (2018)
Como o foco desse prototipo foi somente nas duas acoes descritas no paragrafo
anterior, nao seria possıvel visualizar dados de maneira mais complexa, como fez Vila et al.
(2016) atraves da clusterizacao. Tambem nao e possıvel realizar consultas de informacoes
espaco-temporais.
O comparativo entre as aplicacoes listadas pode ser visto na Tabela 3, que toma
a comparacao a partir dos pontos: foco em acessibilidade, no planejamento urbano e se
faz uso de dados abertos.
Em resumo, esta proposta tem como intuito proporcionar o gerenciamento da
aplicacao integrada as interfaces de Camenar e Almeida (2018) e Nascimento (2018), de
forma que possa contribuir nas etapas do planejamento urbano atraves de visualizacoes
dos dados gerados de forma massiva e com filtros apropriados que serao melhor detalhados
nas secoes seguintes.
33
Tabela 3: Comparativo de aplicacoes de Cidades Inteligentes e Planejamento Ur-bano
Lab
(2015)
Jump
Park
Barczyszyn
(2015)
Nascimento
(2015)
Camenar e
Almeida
(2017)
Este projeto
Voltado a
acessibilidadeX X X X
Usa dados
abertosX X X X
Foco no
planejamento
urbano
X X X X
34
3 METODOLOGIA
Este trabalho tem como objetivo o desenvolvimento de um produto pratico com
finalidade de auxiliar a visualizacao de dados massivos referentes a problemas nas calcadas
da cidade de Curitiba, e com isso, melhorar o planejamento urbano para trazer solucoes
aos cidadaos e ate avisa-los sobre obras que virao a ocorrer. Este capıtulo tem como
objetivo apresentar os passos da execucao deste trabalho na sequencia apresentada na
Figura 16.
Figura 16: Passos da metodologia utilizada.
A primeira etapa abrange o levantamento bibliografico dos principais temas que
estao acerca dos objetivos. Com a revisao do referencial teorico, o principal intuito e
identificar as questoes de visualizacao de dados e planejamento urbano que pertencem a
problematica levantada neste trabalho. Tal estudo tem como foco Kozievitch et al. (2016),
Minetto et al. (2016), Nascimento (2018) e Camenar e Almeida (2018). Investigando
esses trabalhos, buscou-se encontrar aplicacoes realizadas dentro dos temas, analisando a
utilizacao dos conceitos em seus resultados, para basear tambem o presente trabalho em
sua metodologia.
Alem da analise dos trabalhos anteriores, foi realizado um questionario com alguns
alunos da UTFPR em 2018, com perguntas sobre as condicoes das calcadas da cidade de
Curitiba. Foi feita tambem uma visita no IPPUC para verificar a viabilidade da aplicacao.
Os resultados dessa etapa sao apresentados na secao 4.1 do capıtulo de desenvolvimento.
A terceira etapa foi constituıda do desenvolvimento de uma ferramenta que pos-
sibilita a manipulacao e coleta das informacoes geradas pelas aplicacoes de Camenar e
35
Almeida (2018) e de Nascimento (2018). Para isso foi criada a API “Mao na Roda” que
centraliza a manipulacao dos dados dessas aplicacoes. Visando a utilizacao integrada,
realizou-se uma adaptacao do modelo entidade-relacionamento idealizado por Camenar
e Almeida (2018). A centralizacao dos dados, tanto reportados por usuarios, quanto
reportados pela prefeitura, facilita o uso dos mesmos por aplicacoes distintas.
A quarta etapa baseou-se na construcao da aplicacao web, visando uma interface
que permitiria consultas elaboradas com filtros de data e local, mas de uma maneira
simples permitindo que usuarios nao precisem ter nenhum conhecimento em SQL para
realizar tais consultas. O objetivo foi auxiliar no levantamento de informacoes relevantes
no processo de analise de problemas e tomada de decisao.
Esta etapa ainda teve como objetivo criar uma visualizacao utilizando cluste-
rizacoes, semelhante a aplicacao de Vila et al. (2016), auxiliando a visualizar problemas
mais comuns ou regioes mais afetadas por um determinado tipo de problema. Tambem
cogitou-se uma representacao temporal das ocorrencias, para auxiliar no acompanhamento
historico de problemas e solucoes apontadas.
3.1 REQUISITOS DO PROJETO DE SOFTWARE
Com um nıvel de especificidade medio, pode se descrever ambos os projetos de
softwares atraves dos seguintes requisitos nesta secao.
3.1.1 API MAO NA RODA
• O sistema deve estar dentro do padrao RESTful para a comunicacao com o banco
de dados e com outros sistemas;
• O sistema deve permitir requisicoes somente de usuarios autenticados, com excecao
das requisicoes de cadastro e de autenticacao;
• O sistema deve permitir o uso para cadastro e consulta dos usuarios, problemas e
solucoes.
3.1.2 VISUALIZACAO MAO NA RODA
• O sistema deve permitir o usuario visualizar pontos de problemas e solucoes repor-
tadas em um mapa;
36
• O sistema deve agrupar os pontos de acordo com a escala do mapa;
• O sistema deve permitir a filtragem dos pontos de acordo com a situacao do pro-
blema;
• O sistema deve oferecer filtros temporais para as datas dos reportes.
• O sistema deve elaborar graficos com dados quantitativos dos reportes de problemas
e solucoes.
37
4 DESENVOLVIMENTO E IMPLEMENTACAO
Neste capıtulo sera apresentado o desenvolvimento dos passos descritos no capıtulo
3, a implementacao e os testes realizados.
4.1 QUESTIONARIOS
Esta secao tem como objetivo a analise dos resultados obtidos na aplicacao do
questionario, criado com o intuito de validacao da ideia da nossa proposta e tambem
coletar informacoes sobre a percepcao das condicoes das calcadas e rebaixamentos na
cidade de Curitiba. O questionario aplicado encontra-se no Apendice C.
4.1.1 ANALISE DE RESULTADOS DO QUESTIONARIO
Nos dados coletados com o questionario aplicado em 05 de Abril de 2018 com 30
alunos da UTFPR em Curitiba, notou-se que aproximadamente 90% dos participantes da
pesquisa andam a pe com frequencia na cidade, como representado na Figura 17.
Foi utilizada uma escala de Likert em algumas questoes com ideia de obter respos-
tas de acordo com a intensidade da percepcao dos respondentes. A Figura 18 apresenta os
resultados da segunda pergunta do questionario, relacionada as condicoes das calcadas e
que possuıa como opcao de resposta uma escala de 1 a 5, com 1 representando “pessima”
e 5 “excelente”. Demonstrando que as condicoes calcadas e rebaixamentos, de maneira
geral, obtiveram classificacao de media a baixa.
A Figura 19 apresenta o resultado de que mais da metade das pessoas entrevis-
tadas ja sofreu ou conhecem alguem que ja sofreu um acidente por causa de calcadas ou
rebaixamento defeituosos. Na sequencia, o respondente que afirmou positivamente essa
pergunta podia relatar o ocorrido. Nessa pergunta, destacam-se algumas respostas como:
“Como as calcadas sao totalmente desniveladas, nao so eu ja sofri quedas, como sempre
presencio idosos que sofrem muitas vezes quedas violentas, principalmente em dias de
38
Figura 17: Resumo respostas questoes 1.
Fonte: Gerado automaticamente por Google Forms.
Figura 18: Resumo respostas questoes 2.
Fonte: Gerado automaticamente por Google Forms.
chuva.” e “Meu avo ja quebrou o braco ao cair numa calcada inadequada”.
39
Figura 19: Resumo respostas questoes 3.
Fonte: Gerado automaticamente por Google Forms.
Devido a obras sendo realizadas nas ruas 96,7% ja tiveram que andar nas ruas
para desviar pois a calcada estava intransitavel. A Figura 19 mostra que saber sobre essas
obras e problemas nas calcadas e suas solucoes foi constatado como de interesse de 70%
dos entrevistados.
Figura 20: Resumo respostas questoes 6.
Fonte: Gerado automaticamente por Google Forms.
Esse questionario nos trouxe a importancia nao somente da manutencao das
calcadas e rebaixamentos, mas tambem a notificacao de que existem obras sendo rea-
40
lizadas na regiao. Informacoes que a aplicacao proposta neste trabalho visa trazer, nao
somente para a prefeitura, mas tambem disponibilizar de forma aberta para a populacao.
4.2 ENTREVISTAS REALIZADAS COM COLABORADORES DO IPPUC
Foram realizadas duas entrevistas com funcionarios do IPPUC, orgao responsavel
pelo planejamento urbano na cidade de Curitiba. A primeira entrevista foi realizada com
um funcionario tecnico do instituto no dia 19 de marco de 2018 no DAINF da UTFPR,
onde foi possıvel obter informacoes relevantes para levantar requisitos dos aplicativos.
Segundo ele, atualmente ha uma equipe que analisa e trata dados sobre acessibilidade das
calcadas da cidade, porem para cada caso, e necessario que os profissionais da area de
Banco de Dados criem consultas para o uso e visualizacao dos dados georreferenciados.
Portanto, ressaltou-se a necessidade de implementar uma aplicacao que seja capaz de
auxiliar a prefeitura nesse processo, na qual seja possıvel obter visualizacoes informativas
sobre rebaixamentos com problemas, mas de forma simples para qualquer usuario.
Com o intuito de conhecer melhor o trabalho do instituto, no dia 23 de abril
de 2018 foi realizada uma visita tecnica ao setor de geoprocessamento, onde foi feita
a entrevista com o responsavel do setor. Nessa entrevista, identificou-se que o setor
trabalha com uma diversidade de contextos, desde dados sobre atendimento de acidentes
nas rodovias que circundam e permeiam a cidade de Curitiba ate dados sobre transporte
publico.
Sobre os dados relacionados aos problemas nas calcadas, o entrevistado comentou
que nao ha nenhuma aplicacao que trate esse tipo de situacao na cidade e que seria de
grande utilidade para o trabalho da prefeitura. Ele comentou tambem que a maior dificul-
dade, alem do tratamento desses dados, seria a atribuicao da responsabilidade ocasional
dos problemas. Em uma pergunta sobre as funcionalidades do prototipo inicial, o entre-
vistado comentou sobre a possibilidade de resolver essa dificuldade. Porem analisou-se que
este e um problema a ser solucionado pelas aplicacoes que, diferentemente da aplicacao
deste trabalho, alimentam o banco de dados.
41
4.3 IMPLEMENTACAO
4.3.1 ARQUITETURA DO SISTEMA
A Figura 21 apresenta a arquitetura geral do sistema. Todas as aplicacoes fazem
uso da API Mao na Roda, para ter acesso ao banco de dados e cadastrar usuarios, pro-
blemas e solucoes. A interface de Nascimento (2018) faz a comunicacao com o cidadao
e reporta problemas em determinadas localizacoes. A aplicacao de Camenar e Almeida
(2018) traz esse problemas a prefeitura que pode cadastrar solucoes para elas, ou ate
mesmo registrar problemas do tipo Obra no sistema. A interface foco do trabalho traz a
possibilidade de filtros e visualizacao em massa dos problemas relatados, sendo possıvel
visualiza-los de forma agrupada e saber qual o status atual do problema, alem de trazer
a frequencia de reportes de problemas e solucoes.
Figura 21: Arquitetura geral da comunicacao entre os sistemas.
4.3.1.1 API MAO NA RODA
Para poder dar continuidade aos projetos de Kozievitch et al. (2016), Minetto
et al. (2016), Camenar e Almeida (2018) e Nascimento (2018), foi desenvolvida uma
API RESTful que pudesse ser utilizada em todas as interfaces relacionadas. A API
desenvolvida permite que as interfaces de Camenar e Almeida (2018) e Nascimento (2018)
acessem e modifiquem os dados do banco de forma mais abstraıda e segura. Esses dados
gerados fomentarao a interface desse projeto com os dados de problemas e solucoes. E
42
possıvel ver a documentacao completa do uso desta API no Apendice B.
A Figura 22 representa a estrutura dos dados que sao trabalhados pela API.
A relacao Usuario e utilizada tanto pelos usuarios tanto da aplicacao de Nascimento
(2018), quanto pelos usuarios da prefeitura na aplicacao de Camenar e Almeida (2018).
Ambos podendo cadastrar problemas na relacao Problemas, mas somente o usuario da
prefeitura podera cadastrar uma solucao na relacao Solucao para tal problema.
Figura 22: Diagrama de dados API Mao na Roda.
Camenar e Almeida (2018) propuseram um modelo de entidade-relacionamento
para a estrutura do banco de dados. Neste trabalho, realizou-se a implementacao do
SQL para a geracao de um banco de dados que refletisse a necessidade das aplicacoes que
utilizarao a API. Abaixo e possıvel ver a criacao das tabelas que abrangem os principais
dados que foram trabalhados, o problema e a solucao. A lista completa de criacao das
tabelas esta no Apendice A.
CREATE TABLE cadeirante.problema (
problema_id serial CONSTRAINT firstkey9 PRIMARY KEY,
usuario_id
integer REFERENCES cadeirante.usuario (usuario_id),
tipo_marcacao_id
integer REFERENCES cadeirante.tipo_marcacao (tipo_marcacao_id),
43
lat_inicio double precision NOT NULL,
long_inicio double precision NOT NULL,
lat_final double precision NOT NULL,
long_final double precision NOT NULL,
data_hora_reporte timestamp NOT NULL,
descricao varchar(40)
);
CREATE TABLE cadeirante.solucao (
solucao_id serial CONSTRAINT firstkey6 PRIMARY KEY,
usuario_id integer REFERENCES cadeirante.usuario (usuario_id),
resultado_id integer REFERENCES cadeirante.resultado (resultado_id),
problema_id integer REFERENCES cadeirante.problema (problema_id),
data_hora timestamp NOT NULL,
descricao varchar(40)
);
A API foi desenvolvida usando a arquitetura RESTful com as requisicoes HTTP
padroes conhecidas como GET, POST, PATCH (ou PUT ) e DELETE, onde respectiva-
mente “pegamos”, “postamos”, “remendamos” e “deletamos” recursos da base de dados
(FIELDING; TAYLOR, 2000). Por exemplo, para inserir um problema e necessario re-
alizar o envio dos dados para a API, podendo ser feito a partir de varias linguagens de
programacao, para endereco web onde a API esta hospedada com o namespace1 “pro-
blema” com os devidos dados e autorizacao. No exemplo abaixo podemos ver o envio a
partir da linguagem JavaScript.
var settings = {
"async": true,
"crossDomain": true,
"url": "http://200.134.10.21:3000/problema",
"method": "POST",
"headers": {
"Authorization": "eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.
eyJ1c2VyX2lkIjo2LCJleHAiOjE1Mjg1MzA2NTF9.
iXPjVvQk9SEr4qprgyYW1tq7p4jCWIZxh5LTh_2W_6c",
1Nome reservado para um certo recurso dentro de uma aplicacao RESTful.
44
"Content-Type": "application/json"
},
"processData": false,
"data": "{
\n\"usuario_id\":2,
\n\"tipo_marcacao_id\":1,
\n\"lat_inicio\":44.968046,
\n\"long_inicio\":-94.420307,
\n\"lat_final\":44.968046,
\n\"long_final\":-94.420307,
\n\"descricao\":\"Rebaixamento com defeito\"
\n}"
}
$.ajax(settings).done(function (response) {
console.log(response); // Imprime a resposta da API
});
A API responde a aplicacao que fez a requisicao no formato JSON2 com as in-
formacoes passadas anteriormente e o identificador com o qual o problema foi cadastrado
no banco e suas respectivas informacoes.
{
"problema_id":1,
"usuario_id":2,
"tipo_marcacao_id":1,
"lat_inicio":44.968046,
"long_inicio":-94.420307,
"lat_final":44.968046,
"long_final":-94.420307,
"data_hora_reporte":"2017-09-26T04:58:33.266Z",
"descricao":"Rebaixamento com defeito"
}
Para apresentar a visualizacao do historico da frequencia dos reportes de pro-
blemas e de solucoes cadastradas no banco de dados, ver Figura 25, foi criado uma fun-
cionalidade que gera um relatorio de frequencia na API. Essa funcao foi implementada
2JavaScript Object Notation - Notacao de Objetos JavaScript
45
como uma requisicao a mais alem das padroes, tanto para as entidades de Problema e
Solucao. Ao realizar essa requisicao existem as seguintes possibilidades: determinar um
perıodo que se deseja saber a frequencia dos problemas e solucoes ao longo do tempo,
ou nao informar perıodo nenhum. Caso nao seja informado o perıodo por parametros, o
sistema define como perıodo inicial a data de reporte de Problema mais antigo, e como
perıodo inicial a data que foi realizado a requisicao.
Quando uma aplicacao externa faz a chamada para a URL problema/frequencia
ou problema/solucao, recebe um relatorio como este abaixo, onde pode-se notar que no
mes 6 do ano 2018 o valor e zero, ou seja, dentro da funcionalidade tambem sao levados
em consideracao os meses onde nao houveram reportes.
[
{"ano": 2018, "mes": 3, "valor": 6},
{"ano": 2018, "mes": 4, "valor": 14},
{"ano": 2018, "mes": 5, "valor": 4},
{"ano": 2018, "mes": 6, "valor": 0}
]
Abaixo e apresentado um exemplo de consulta feita para montar o reporte de
frequencia de problemas dos meses de marco de 2018 a junho de 2018.
SELECT COUNT(*)
AS count_all, (EXTRACT(YEAR FROM data_hora_reporte))::integer
AS extract_year_from_data_hora_reporte_integer,
(EXTRACT(MONTH FROM data_hora_reporte))::integer
AS extract_month_from_data_hora_reporte_integer
FROM "problema"
WHERE
(data_hora_reporte >= '2018-03-01 00:00:00' AND
data_hora_reporte <= '2018-06-30 23:59:59.999999')
GROUP BY (EXTRACT(YEAR FROM data_hora_reporte))::integer,
(EXTRACT(MONTH FROM data_hora_reporte))::integer
ORDER BY 2 ASC, 3 ASC
46
4.3.1.2 APLICACAO WEB “MAO NA RODA”
A aplicacao mencionada no quinto objetivo foi desenvolvida como uma aplicacao
Web. Na Figura 23 estao modelados os casos de uso dessa aplicacao. Este diagrama
apresenta as possıveis acoes do usuario e o papel da API Mao na Roda nessa utilizacao.
O usuario pode, por exemplo, filtrar dados para uma determinada visualizacao geografica,
ou verificar o historico de reportes em determinado perıodo.
Figura 23: Diagrama de Caso de Use do sistema de visualizacao
A aplicacao web permite que sejam realizadas consultas de problemas relatados
filtrando por estado do problema, solucionado ou nao, e a data de reporte. Isso permite,
por exemplo, verificar quais sao as regioes com maior quantidade de reportes de problemas,
ou a epoca em que eles mais ocorrem. Auxiliando assim na tomada de decisoes por parte
da prefeitura no planejamento urbano.
A Figura 24 representa uma tela da aplicacao. Nessa tela, o usuario pode visua-
lizar um mapa com os pontos de problemas reportados clusterizados. Ao lado do mapa,
encontram-se os filtros que podem ser aplicados na visualizacao atual. Sao esses:
• Filtro por status do problema: esse filtro permite mostrar ou omitir os problemas
47
solucionados ou nao solucionados;
• Filtro por data de reporte: esse filtro permite a mostrar os problemas com base
na data que foram reportados. Nele, e possıvel tanto inserir uma data inicial, para
mostrar apenas problemas reportados apos a data determinada, quanto uma data
final, mostrando os problemas reportados antes da dessa data.
Figura 24: Visualizacao de pontos de problema clusterizados.
Outra tela pode ser observada na Figura 25. Nela, e possıvel verificar os pro-
blemas e solucoes reportados ao longo dos meses, representados por um grafico de linha.
Semelhante a tela da Figura 24, esta tela possui um filtro para alterar o perıodo mostrado
de acordo com os meses selecionados.
48
Figura 25: Visualizacao do historico de frequencias com filtro de data.
Com o prototipo da aplicacao apresentada, a prefeitura da cidade ou ate mesmo
a populacao poderia ser beneficiada em alguns casos. Seguem alguns desses casos:
• Verificar as regioes da cidade que apresentam mais problemas nas calcadas
e rebaixamentos
A clusterizacao dos pontos geograficos permite que o usuario visualize os dados de
forma imediata e quantitativa. Assim, um agente da prefeitura poderia verificar
qual regiao da cidade ou de um bairro esta com mais problemas reportados nas
calcadas e rebaixamentos.
• Apurar perıodos com maior acao da prefeitura
Com o grafico historico, e possıvel identificar perıodos em que houveram maior
quantidade de problemas reportados ou perıodos que tiveram maior quantidade de
problemas solucionados. Desta forma, seria possıvel por exemplo saber em qual
gestao houveram mais problemas reportados e em qual a prefeitura tomou mais
acoes para sana-los.
4.3.1.3 TECNOLOGIAS UTILIZADAS
A API Mao na Roda utilizou um servidor de pequeno porte modelo Dell Optiplex
380 na UTFPR, rodando em um sistema operacional de base Linux. O software utiliza
as seguintes tecnologias:
49
• Ruby on Rails 5.1.3 3;
• PostgreSQL 9.4 4;
A API foi desenvolvida usando o Ruby in Rails, utilizando a arquitetura REST
que ve a aplicacao como conjunto de recursos e fornece os metodos para acessar e modificar
eles. Mas para manter a seguranca desses dados cada requisicao deve estar autenticada.
Com esse intuito, foi usado o metodo de autenticacao chamado JWT5. Por ser uma
autenticacao baseada em token, ela e considerada stateless, ou seja, nao armazena dados
de autenticacao no servidor, mas cria um token codificado unico que deve ser enviado
e e verificado a cada nova requisicao (vide fluxo na Figura 26). Esse codigo e obtido
pelos usuarios da aplicacao sempre que executam login na API atraves do metodo de
autenticacao que pode ser visto na documentacao no apendice B.
Figura 26: Fluxo de autorizacao de requisicao JWT.
A aplicacao web Mao na Roda ainda nao esta hospedada em um servidor, mas
pode ser facilmente instalada em qualquer maquina ja que usa codigo aberto6. O software
utiliza as seguintes tecnologias:
• Angular 5.2.0 7;
3www.rubyonrails.org - Acessado em: 01 de outubro de 2017.4www.postgresql.org - Acessado em: 01 de outubro de 2017.5JsonWebToken6Disponıvel em: www.github.com/gabrielloyola/mao-na-roda-frontend7www.angular.io - Acessado em: 12 de janeiro de 2018.
50
• ng2-charts 1.6.0 8;
• Angular Google Maps 1.0.0-beta.2 9 ;
4.3.2 TESTES
Para fins de validacao das aplicacoes propostas, foi realizado um teste no dia 08 de
junho de 2018 com cinco pessoas contendo tres atividades para validar as funcionalidades
propostas. Para a aplicacao deste teste, o servidor da API foi iniciado em uma maquina
virtual na nuvem com dados simulados de a problemas e solucoes nos ultimos 2 anos.
4.3.2.1 PERFIL DOS PARTICIPANTES
Os participantes da pesquisa estavam na faixa etaria de 20 a 28 anos. Duas delas
ja eram graduadas da area de tecnologia e as outras tres estavam cursando graduacao de
nıvel superior. Essas pessoas nao foram selecionadas utilizando nenhum criterio, apenas
se ofereceram para participar de forma voluntaria e suas identidades nao serao trazidas
neste trabalho.
4.3.2.2 ROTEIRO
Aos participantes do teste, foram propostas as seguintes tarefas:
• Visualizar os problemas na cidade de Curitiba do perıodo de 01 de junho de 2017
ate 01 de junho de 2018;
• Identificar quantos problemas solucionados existem nesse perıodo;
• Encontrar a regiao com o maior acumulo de problemas nao resolvidos no mesmo
perıodo;
• Verificar no historicos a frequencia desse mesmo perıodo.
4.3.2.3 ANALISE DOS RESULTADOS
Todos os participantes conseguiram realizar as atividades propostas. Porem,
algumas questoes foram levantadas a partir da observacao e de constatacoes verbalizadas
pelos participantes. Sao elas:
8www.valor-software.com/ng2-charts/ - Acessado em: 15 de janeiro de 2018.9www.angular-maps.com/ - Acessado em: 12 de janeiro de 2018.
51
• O filtro possui inconsistencia no tıtulo dos campos.
Um dos participantes indicou que, na tela representada na Figura 25, os tıtulos dos
campos de filtro informam a selecao de um mes, porem na verdade o campo permite
a selecao de uma data completa, com dia, mes e ano;
• Os campos de data dos filtros so abrem o seletor de data ao clicar no
ıcone do calendario (pode ser visualizado nas Figuras 24 e 25).
Em um dos testes, o participante esperou o seletor abrir e ficou confuso ao tentar
encontrar a opcao correta para abri-lo;
• A tela representada na Figura 24 nao possuıa legenda para os elementos
do mapa.
Esse ponto foi observado ou verbalizado em todos os testes;
• As marcacoes no mapa nao possuem informacoes, apesar de indicarem
um possıvel clique.
Todos os participantes tentaram clicar nas marcacoes, porem o prototipo nao exibe
nenhuma informacao nem realiza outra acao a partir desse clique;
• Ao aplicar um filtro, nao ha informacoes do estado do sistema enquanto
o prototipo carrega os dados.
Apesar de haver a mensagem de sucesso ao aplicar o filtro, enquanto o prototipo
carrega os dados adquiridos pela API nao ha nada indicando que o sistema esteja
carregando esses dados;
• Nao ha nenhuma informacao indicando a natureza dos problemas.
Em todos os testes, os participantes nao souberam afirmar do que se tratavam os
problemas informados pela interface.
Para sanar cada uma dessas questoes levantadas, foram apontadas possıveis
solucoes:
• Alterar o tıtulo dos filtros da tela representada na Figura 25 para “Perıodo inicial”
e “Perıodo final”;
• Atrelar a acao de abrir o seletor de data tambem ao clicar no campo;
• Adicionar uma legenda explicando cada elemento do mapa;
52
• Adicionar informacoes de problemas as marcacoes do mapa. Tendo em vista que a
API ja retorna esses dados no metodo da aquisicao de problemas cadastrados, esse
ponto e factıvel;
• Adicionar um elemento visual para indicar o carregamento dos dados em cada re-
quisicao realizada para a API, que seria omitido ao obter a resposta e atualizar os
dados na interface;
• Adicionar uma contextualizacao da interface para um usuario inicial que nao saiba
a natureza dos problemas.
Apos a realizacao do teste, os participantes foram questionados sobre a utilidade
do prototipo e suas possıveis aplicacoes. Com isso, foi levantada uma diversidade de res-
postas. Alguns demonstraram interesse na clusterizacao dos pontos, ressaltando que e
possıvel visualizar facilmente as regioes crıticas da cidade. Outros mencionaram que o
grafico historico permite o acompanhamento e a analise de perıodos de maior quantidade
de acoes. Como nao houve uma contextualizacao tanto no pre-teste quanto na inter-
face, alguns participantes indicaram aplicacoes genericas, como “Auxiliar a prefeitura em
problemas gerais” ou “Gerar homogeneidade nos bairros quanto ao tratamento dos pro-
blemas”. Porem, alguns sugeriram aplicacoes especıficas, mas fora do contexto real do
prototipo, como auxiliar no combate a criminalidade, ou auxiliar na escolha de um hotel,
baseando-se nos pontos turısticos indicados no mapa.
4.3.2.4 API
Os testes de funcionalidade da API foram feitos durante sua producao utilizando
um software chamado Postman10, que tem como objetivo auxiliar o desenvolvimento de
APIs. A Figura 27 mostra um teste de requisicao para a URL de autenticacao, e na
Figura 28 temos um teste para a URL de frequencia de problema.
10www.getpostman.com
53
Figura 27: Teste de requisicao de autenticacao da API Mao na Roda.
Figura 28: Teste de requisicao de frequencia de problemas da API Mao na Roda.
54
5 CONSIDERACOES FINAIS E TRABALHOS FUTUROS
O planejamento urbano encontra-se em contınuo desenvolvimento com o uso das
tecnologias da informacao no contexto de cidades inteligentes. Existe uma grande quan-
tidade de dados sendo gerada diariamente e que pode se transformar em informacoes
importantes na tomada de decisao para o futuro das cidades. Por outro lado, a situacao
das calcadas de Curitiba e um problema evidente, de acordo com as respostas obtidas no
questionario realizado. Nas entrevistas, foi possıvel constatar tambem que as condicoes
atuais de tratamento dos dados sobre essa situacao necessita de um conhecimento tecnico
e de mao-de-obra qualificada para isso.
As principais contribuicoes deste trabalho foram: uma aplicacao web1 capaz de
abstrair consultas aos dados levantados pelas aplicacoes de Camenar e Almeida (2018) e
Nascimento (2018) de forma visual e usando conceitos de dados abertos; a API2 desenvol-
vida, que entra como protagonista dessa disponibilizacao de dados e tambem possibilita
a alteracao dos dados de forma unificada e segura; o questionario que trouxe uma ciencia
maior sobre o problema no ponto de vista de um grupo de cidadaos; as entrevistas na
IPPUC que trouxe uma nocao do contexto atual do tratamento desses dados.
Houveram algumas limitacoes que afetaram o desenvolvimento deste trabalho.
Uma delas foi a impossibilidade de disponibilizar a mesma aplicacao em servidores publicos
por falta de recursos, o que seria desejavel para uma futura utilizacao da mesma. Outra
limitacao notada foi o desenvolvimento anterior aos testes, que poderiam ser realizados
utilizando paradigmas de IHC3, fato que poderia prevenir alguns erros apontados nos
testes realizados no trabalho, alem de proporcionar outras otimizacoes de interface. Por
ultimo, os testes da interface web nao terem sido feitos com funcionarios da prefeitura, o
que possivelmente traria uma validacao mais adequada a visualizacoes apresentadas.
Foi possıvel tambem identificar algumas melhorias nao realizadas neste trabalho,
1github.com/gabrielloyola/mao-na-roda-frontend2github.com/maycowmeira/api-mao-na-roda3Interacao Humano-Computador
55
por exigirem mais tempo de desenvolvimento e estudo. Entretanto, ficam indicadas para
serem abordadas em trabalhos futuros:
• A estruturacao de um paralelismo da infraestrutura da API utilizando alguma tec-
nologia de containers para que possa suportar diversos acessos simultaneos prove-
nientes de diversas aplicacoes.
• A elaboracao de novos filtros dentro da API e da aplicacao web.
• A implementacao de um mapa geografico de calor (Heat Map) para uma visualizacao
diferenciada dos problemas indicados.
56
REFERENCIAS
AGUIAR, F. d. O. Acessibilidade relativa dos espacos urbanos para pedestres comrestricoes de mobilidade. Doutorado (Ciencias-Engenharia de Transportes).EESC/USP, Sao Carlos, 2010.
BARCZYSZYN, G. L. Integracao de dados geograficos para planejamento urbanoda cidade de Curitiba. Dissertacao (B.S. thesis) — Universidade Tecnologica Federaldo Parana, 2015.
BARCZYSZYN, G. L.; KOZIEVITCH, N. P.; MINETTO, R.; SILVA, R. D. d.; SANTI,J. d. Utilizacao de dados de altimetria para o fornecimento de rotas acessıveis para cadei-rantes. Proceedings XVIII GEOINFO, p. 104–109, 2017.
BELMONTE, N. G. Engineering Intelligence Through Data Visualization atUber. Maio 2016. Disponıvel em: https://eng.uber.com/data-viz-intel/. Acessado em09 de Outubro de 2017.
BELTRAN, R.; CORNEHLS, S.; GILARD, F.; GUT, R.; SCHEIWILLER, P.; STE-PANSKI, L. Mapping Global Refugee Movements. 2017. Acessado em 12 de novem-bro de 2017. Disponıvel em: <https://refugeemovements.com/>.
CAMENAR, L. M. d. O.; ALMEIDA, L. D. A. A method for analyzing mobility issuesfor people with physical disabilities in the context of developing countries. HCI Inter-national, 2018, Las Vegas, Springer International Publishing, 2018.
CAU/BR. Planejamento Urbano e Territorial: questoes e desafios para umaNova Agenda Urbana. Outubro 2017. Acessado em 15 de outubro de 2017. Disponıvelem: <http://www.caubr.gov.br/ii-planejamento-urbano-e-territorial-questoes-e-desafios-para-uma-nova-agenda-urbana/>.
CHANG, K.-T. Introduction to Geographic Information Systems. oitava edicao.Colombus, OH, USA: McGraw-Hill Education, 2015.
DRUCK, S. Analise espacial de dados geograficos. Brasılia, Brasil: Empraba Cerra-dos, 2004.
EAVES, D. The three laws of open government data. Eaves. ca, v. 30, 2009.
ELLIS, G.; MANSMANN, F. Mastering the information age solving problems with visualanalytics. In: Eurographics. Graz, Austria: Eurographics Digital Library, 2010. v. 2,p. 5.
FERREIRA, N.; POCO, J.; VO, H. T.; FREIRE, J.; SILVA, C. T. Visual exploration ofbig spatio-temporal urban data: A study of new york city taxi trips. IEEE Transactionson Visualization and Computer Graphics, IEEE, v. 19, n. 12, p. 2149–2158, 2013.
57
FIELDING, R. T.; TAYLOR, R. N. Architectural styles and the design of network-based software architectures. California, USA: University of California, Irvine Doc-toral dissertation, 2000.
FOX, E. A.; LEIDIG, J. P. Digital libraries applications: Cbir, education, social networks,escience/simulation, and gis. Synthesis Lectures on Information Concepts, Retri-eval, and Services, & Claypool Publishers, v. 6, n. 1, p. 1–175, 2014.
FREIRE, J.; SILVA, C. T.; VO, H. T.; DORAISWAMY, H.; FERREIRA, N.; POCO, J.Riding from urban data to insight using new york city taxis. IEEE Data Eng. Bull.,v. 37, n. 4, p. 43–55, 2014.
GILBERT, E. W. Pioneer maps of health and disease in england. The GeographicalJournal, JSTOR, v. 124, n. 2, p. 172–183, 1958.
HAMADA, E.; GONCALVES, R. R. do V. Introducao ao geoprocessamento: princıpiosbasicos e aplicacao. Embrapa Meio Ambiente, 2007.
IBGE. Cidades @ Curitiba. 2017. Acessado em 01 de agosto de 2017. Disponıvel em:<http://cod.ibge.gov.br/8XS>.
JANEIRO, P. da Cidade do Rio de. Concurso Rio Apps 2015. 2015. Acessado em 09de novembro de 2017. Disponıvel em: <http://rioapps.com.br/>.
JONES, S. Accessibility measures: a literature review. Reino unido, 1981.
KNOWLEDGE, O. The Open Definition. ago 2017. Acessado em 15 de agosto de 2017.Disponıvel em: <http://opendefinition.org/>.
KOZIEVITCH, N. P.; ALMEIDA, L. D.; SILVA, R. D. da; MINETTO, R. An alternativeand smarter route planner for wheelchair users: Exploring open data. In: IEEE. SmartCities and Green ICT Systems (SMARTGREENS), 2016 5th InternationalConference on. Rome, Italy: IEEE, 2016. p. 1–6.
KUCERA, J.; CHLAPEK, D. Benefits and risks of open government data. Journal ofSystems Integration, Journal of Systems Integration, v. 5, n. 1, p. 30, 2014.
LAB, A. AXS Map. 2015. Acessado em 12 de novembro de 2017. Disponıvel em:<http://www.axsmap.com/>.
LARA, F. R. d.; MARTINS, T. S. Melhoria na eficiencia da mobilidade urbana- sistema de transporte compartilhado na UTFPR. Dissertacao (B.S. thesis) —Universidade Tecnologica Federal do Parana, 2016.
MENKENS, C.; SUSSMANN, J.; AL-ALI, M.; BREITSAMETER, E.; FRTUNIK, J.;NENDEL, T.; SCHNEIDERBAUER, T. Easywheel-a mobile social navigation and sup-port system for wheelchair users. In: IEEE. Information Technology: New Genera-tions (ITNG), 2011 Eighth International Conference on. Las Vegas, NV, USA:IEEE, 2011. p. 859–866.
MINETTO, R.; KOZIEVITCH, N. P.; SILVA, R. D. da; ALMEIDA, L. D. A.; SANTI, J.de. Shortcut suggestion based on collaborative user feedback for suitable wheelchair routeplanning. In: IEEE. Intelligent Transportation Systems (ITSC), 2016 IEEE 19thInternational Conference on. Rio de Janeiro, Brasil: IEEE, 2016. p. 2372–2377.
58
MOURCOU, Q.; FLEURY, A.; DUPUY, P.; DIOT, B.; FRANCO, C.; VUILLERME, N.Wegoto: A smartphone-based approach to assess and improve accessibility for wheelchairusers. In: IEEE. Engineering in Medicine and Biology Society (EMBC), 201335th Annual International Conference of the IEEE. Osaka, Japan: IEEE, 2013. p.1194–1197.
NAMIKAWA, L. M. Um metodo de ajuste de superfıcie para grades triangulares consi-derando linhas caracterısticas. Sao Jose dos Campos, 1995.
NASCIMENTO, D. d. F. do. Modelagem de uma aplicacao para dispositivosmoveis de um planejador de rotas baseado em calcadas para usuarios de ca-deiras de rodas. 2018. Trabalho de Conclusao de Curso de Bacharelado em Sistemas deInformacao da Universidade Tecnologica Federal do Parana.
ONU. Accessibility and Inclusion of Persons with Disabilities in Ur-ban Development. 2016. Acessado em 12 de agosto de 2017. Disponıvel em:<http://bit.ly/ONU2016Accessibility>.
PEUQUET, D. J. It’s about time: A conceptual framework for the representation oftemporal dynamics in geographic information systems. Annals of the Association ofamerican Geographers, Wiley Online Library, v. 84, n. 3, p. 441–461, 1994.
SCHAFFERS, H.; KOMNINOS, N.; PALLOT, M.; TROUSSE, B.; NILSSON, M.; OLI-VEIRA, A. Smart cities and the future internet: Towards cooperation frameworks foropen innovation. The future internet, Springer, p. 431–446, 2011.
SUMIDA, Y.; HAYASHI, M.; GOSHI, K.; MATSUNAGA, K. Development of a routefinding system for manual wheelchair users based on actual measurement data. In: IEEE.Ubiquitous Intelligence & Computing and 9th International Conference onAutonomic & Trusted Computing (UIC/ATC), 2012 9th International Confe-rence on. Fukuoka, Japan: IEEE, 2012. p. 17–23.
TSAMPOULATIDIS, I.; VERVERIDIS, D.; TSARCHOPOULOS, P.; NIKOLOPOU-LOS, S.; KOMPATSIARIS, I.; KOMNINOS, N. Improvemycity: an open source plat-form for direct citizen-government communication. In: ACM. Proceedings of the 21stACM international conference on Multimedia. Barcelona, Spain: ACM, 2013. p.839–842.
VILA, J. J. R.; KOZIEVITCH, N. P.; GADDA, T. M.; FONSECA, K.; ROSA, M. O.;GOMES-JR, L. C.; AKBAR, M. Urban mobility challenges-an exploratory analysis ofpublic transportation data in curitiba. Revista de Informatica Aplicada, v. 12, n. 1,2016.
WARD, M.; GRINSTEIN, G.; KEIM, D. Interactive Data Visualization: Founda-tions, Techniques, and Applications. Florida, United States: CRC Press, 2010. (360Degree Business). ISBN 9781439865545.
WEISS, M. C. Cidades inteligentes como nova pratica para o gerenciamento dos servicose infraestruturas urbanos: estudo de caso da cidade de porto alegre. centro universitarioda fei. Centro Universitario da FEI, Sao Paulo.[Links], 2013.
59
WEISS, M. C.; BERNARDES, R. C.; CONSONI, F. L. Cidades inteligentes: a aplicacaodas tecnologias de informacao e comunicacao para a gestao de centros urbanos. RevistaTecnologia e Sociedade, v. 9, n. 18, 2013.
WEISS, M. C.; BERNARDES, R. C.; CONSONI, F. L. Cidades inteligentes como novapratica para o gerenciamento dos servicos e infraestruturas urbanos: a experiencia dacidade de porto alegre. Revista Brasileira de Gestao Urbana, SciELO Brasil, v. 7,n. 3, p. 310–324, 2015.
YEH, A. G.-O. Urban planning and gis. Geographical Information Systems: Princi-ples, Techniques, Applications, and Management 2nd edition, Eds PA Longley,M Goodchild, D Maguire, D Rhind (John Wiley, New York) pp, p. 877–888,1999.
60
APENDICE A -- SQL
Codigo completo para a criacao da base de dados utilizada pelas interfaces de
Camenar e Almeida (2018), Nascimento (2018) e do artefato produzido por este TCC.
CREATE TABLE cadeirante.genero (
genero_id serial CONSTRAINT firstkey PRIMARY KEY,
descricao varchar(40) NOT NULL
);
CREATE TABLE cadeirante.perfil (
perfil_id serial CONSTRAINT firstkey1 PRIMARY KEY,
descricao varchar(40) NOT NULL
);
CREATE TABLE cadeirante.escolaridade (
escolaridade_id serial CONSTRAINT firstkey2 PRIMARY KEY,
descricao varchar(40) NOT NULL
);
CREATE TABLE cadeirante.usuario (
usuario_id serial CONSTRAINT firstkey3 PRIMARY KEY,
escolaridade_id
integer REFERENCES cadeirante.escolaridade (escolaridade_id),
perfil_id integer REFERENCES cadeirante.perfil (perfil_id),
genero_id integer REFERENCES cadeirante.genero (genero_id),
nome varchar(90) NOT NULL,
email varchar(40) NOT NULL,
password_digest varchar(200) NOT NULL,
ano integer,
61
profissao varchar(90),
restricao varchar(140),
restricao_outras varchar(140)
);
CREATE TABLE cadeirante.dificuldade_cod (
dificuldade_cod_id serial CONSTRAINT firstkey4 PRIMARY KEY,
nome varchar(90) NOT NULL
);
CREATE TABLE cadeirante.dificuldade (
dificuldade_id serial CONSTRAINT firstkey7 PRIMARY KEY,
usuario_id
integer REFERENCES cadeirante.usuario (usuario_id),
dificuldade_cod_id
integer REFERENCES cadeirante.dificuldade_cod (dificuldade_cod_id),
valor integer
);
CREATE TABLE cadeirante.resultado (
resultado_id serial CONSTRAINT firstkey5 PRIMARY KEY,
descricao varchar(40) NOT NULL
);
CREATE TABLE cadeirante.tipo_marcacao (
tipo_marcacao_id serial CONSTRAINT firstkey8 PRIMARY KEY,
descricao varchar(40) NOT NULL
);
CREATE TABLE cadeirante.problema (
problema_id serial CONSTRAINT firstkey9 PRIMARY KEY,
usuario_id
integer REFERENCES cadeirante.usuario (usuario_id),
tipo_marcacao_id
integer REFERENCES cadeirante.tipo_marcacao (tipo_marcacao_id),
62
lat_inicio double precision NOT NULL,
long_inicio double precision NOT NULL,
lat_final double precision NOT NULL,
long_final double precision NOT NULL,
data_hora_reporte timestamp NOT NULL,
descricao varchar(40)
);
CREATE TABLE cadeirante.solucao (
solucao_id serial CONSTRAINT firstkey6 PRIMARY KEY,
usuario_id integer REFERENCES cadeirante.usuario (usuario_id),
resultado_id integer REFERENCES cadeirante.resultado (resultado_id),
problema_id integer REFERENCES cadeirante.problema (problema_id),
data_hora timestamp NOT NULL,
descricao varchar(40)
);
CREATE TABLE cadeirante.registro (
registro_id serial CONSTRAINT firstkey10 PRIMARY KEY,
problema_id integer REFERENCES cadeirante.problema (problema_id),
foto_url varchar(140),
descricao varchar(40)
);
63
APENDICE B -- DOCUMENTACAO PARCIAL DA API MAO NA RODA
Documentacao parcial da API Mao na roda, artefato gerado para poder ser uti-
lizado pelas interfaces de Camenar e Almeida (2018) e Nascimento (2018), servindo para
coletar dados que estao sendo utilizados pela interface de visualizacao proposta por este
trabalho.
Para visualizar a documentacao completa acesse:
https://documenter.getpostman.com/view/794036/api-mao-na-roda/RWEcQLs9.
Durante o desenvolvimento desta aplicacao, foi possibilitado a instalacao desta
API em um servidor dentro da UTFPR. Entao os proximos exemplos terao como endereco
de requisicao o IP e porta disponibilizado para esse fim.
Para comecar a utilizar a API Mao na Roda primeiramente se deve registra um
usuario, pois a maioria das requisicoes necessitam que seja enviado uma autenticacao do
seu usuario para que seja executada. Para isso devemos fazer uma requisicao POST para
o /usuario. Segue um exemplo utilizando JavaScript Jquery AJAX :
var settings = {
"async": true,
"crossDomain": true,
"url": "http://200.134.10.21:3000/usuario",
"method": "POST",
"headers": { "Content-Type": "application/json" },
"processData": false,
"data": "{
\n \"escolaridade_id\": 6,
\n \"perfil_id\": 2,
\n \"genero_id\": 1,
\n \"nome\": \"Usuario Teste\",
\n \"email\": \"[email protected]\",
64
\n \"password\": \"123123\",
\n \"password_confirmation\": \"123123\",
\n \"ano\": 1990
\n}"
}
$.ajax(settings).done(function (response) {
console.log(response);
});
Nota-se que e passado uma escolaridade, um genero e um perfil para poder ser
criado o usuario, caso contrario nao ira funcionar. Ja temos alguns destes dados iniciali-
zados no banco de dados para podermos comecar a trabalhar com a API, mas que podem
ser complementados posteriormente atraves de seus respectivos metodos que podem ser
vistos na documentacao completa. Os dados ja registrados sao os seguintes:
Escolaridade Genero Perfil
1 Fundamental incompleto 1 Masculino 2 Android
2 Fundamental completo 2 Feminino 3 Prefeitura
3 Medio incompleto
4 Medio completo
5 Superior incompleto
6 Superior completo
Com o usuario criado o proximo passo e realizar o login na API para se ter acesso
ao token de autenticacao, com ele sera possıvel realizar as demais requisicoes.
var settings = {
"async": true,
"crossDomain": true,
"url": "http://200.134.10.21:3000/authenticate",
"method": "POST",
"headers": { "Content-Type": "application/json" },
"processData": false,
"data": "{
\n\t\"email\": \"[email protected]\",
65
\n\t\"password\": \"123123\"
\n}"
}
$.ajax(settings).done(function (response) {
console.log(response); // Imprime a resposta da API
});
Se a resposta for positiva do login teremos acesso ao token de autenticacao.
{
"auth_token":
"eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.
eyJ1c2VyX2lkIjo2LCJleHAiOjE1Mjg1MzA2NTF9.
iXPjVvQk9SEr4qprgyYW1tq7p4jCWIZxh5LTh_2W_6c"
}
Esse valor sera usado para realizar todas as demais requisicoes daqui a para frente.
Abaixo o exemplo do registro de um problema na base de dados via API:
var settings = {
"async": true,
"crossDomain": true,
"url": "http://200.134.10.21:3000/problema",
"method": "POST",
"headers": {
"Authorization": "eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.
eyJ1c2VyX2lkIjo2LCJleHAiOjE1Mjg1MzA2NTF9.
iXPjVvQk9SEr4qprgyYW1tq7p4jCWIZxh5LTh_2W_6c",
"Content-Type": "application/json"
},
"processData": false,
"data": "{
\n\"usuario_id\":1,
\n\"tipo_marcacao_id\":1,
\n\"lat_inicio\":44.968046,
66
\n\"long_inicio\":-94.420307,
\n\"lat_final\":44.968046,
\n\"long_final\":-94.420307,
\n\"descricao\":\"Rampa com defeito\"
\n}"
}
$.ajax(settings).done(function (response) {
console.log(response); // Imprime a resposta da API
});
Os demais possıveis URLs estao disponıveis no link da documentacao completa.
67
APENDICE C -- QUESTIONARIO
Questionario aplicado no dia 05 de abril de 2018 em uma turma de alunos da
UTFPR.
C.1 CALCADAS E REBAIXAMENTOS NA CIDADE DE CURITIBA
Esta pesquisa tem como objetivo obter informacoes sobre os habitos de uso das
calcadas de Curitiba, para a realizacao do Trabalho de Conclusao de Curso de Bacharelado
de Sistemas de Informacao, realizado pelos alunos Gabriel Loyola e Maycow Meira.
1.Com qual frequencia voce anda a pe na cidade? Em uma escala de 1 a 5,
sendo 1 ”Nunca”e 5 ”Sempre”.
2.Como voce classificaria as condicoes das calcadas e rebaixamentos da
cidade? Em uma escala de 1 a 5, sendo 1 ”Pessimas”e 5 ”Excelentes”.
3.Ja sofreu ou conhece alguem que tenha sofrido algum acidente por causa
de uma calcada ou rebaixamento defeituoso? Opcoes: Sim, Nao, Nao me
lembro, Prefiro nao responder.
4.Caso tenha respondido sim na pergunta anterior, poderia descrever bre-
vemente o ocorrido? Pergunta aberta.
5.Ja teve de andar na rua por causa de problemas ou obras na calcada?
Opcoes: Sim, Nao, Nao me lembro, Prefiro nao responder.
6.Seria do seu interesse saber sobre problemas e obras em calcadas e re-
baixamentos da cidade e as solucoes dadas a eles? Opcoes: Sim ou Nao.