UNIVERSIDADE TECNOLOGICA FEDERAL DO PARAN A …repositorio.roca.utfpr.edu.br/jspui/bitstream/1/... · universidade tecnologica federal do paran a departamento academico de inform^

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.



chuva.” e “Meu avo ja quebrou o braco ao cair numa calcada inadequada”.

39



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.



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,


);

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,


);

CREATE TABLE cadeirante.escolaridade (

escolaridade_id serial CONSTRAINT firstkey2 PRIMARY KEY,


);

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


dificuldade_cod_id

integer REFERENCES cadeirante.dificuldade_cod (dificuldade_cod_id),

valor integer

);

CREATE TABLE cadeirante.resultado (

resultado_id serial CONSTRAINT firstkey5 PRIMARY KEY,


);

CREATE TABLE cadeirante.tipo_marcacao (

tipo_marcacao_id serial CONSTRAINT firstkey8 PRIMARY KEY,


);

CREATE TABLE cadeirante.problema (

problema_id serial CONSTRAINT firstkey9 PRIMARY KEY,

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,


);

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),


data_hora timestamp NOT NULL,


);

CREATE TABLE cadeirante.registro (

registro_id serial CONSTRAINT firstkey10 PRIMARY KEY,


foto_url varchar(140),


);

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,


"url": "http://200.134.10.21:3000/usuario",

"method": "POST",

"headers": { "Content-Type": "application/json" },


"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}"

}


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,


"url": "http://200.134.10.21:3000/authenticate",

"method": "POST",

"headers": { "Content-Type": "application/json" },


"data": "{

\n\t\"email\": \"[email protected]\",

65

\n\t\"password\": \"123123\"

\n}"

}



});

Se a resposta for positiva do login teremos acesso ao token de autenticacao.

{

"auth_token":

"eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.


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,


"url": "http://200.134.10.21:3000/problema",

"method": "POST",

"headers": {

"Authorization": "eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.


iXPjVvQk9SEr4qprgyYW1tq7p4jCWIZxh5LTh_2W_6c",

"Content-Type": "application/json"

},


"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}"

}



});

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.

Documents

UNIVERSIDADE TECNOLOGICA FEDERAL DO PARAN A …repositorio.roca.utfpr.edu.br/jspui/bitstream/1/... · universidade tecnologica federal do paran a departamento academico de inform^