UNIVERSIDADE TECNOLOGICA FEDERAL DO PARAN´ A´...

UNIVERSIDADE TECNOLOGICA FEDERAL DO PARANAPROGRAMA DE POS-GRADUACAO EM ENGENHARIA ELETRICA E

INFORMATICA INDUSTRIAL

PAULO CARVALHO DINIZ JUNIOR

SERVICOS TELEMATICOS EM UMA REDE DE TRANSPORTEPUBLICO BASEADOS EM VEICULOS CONECTADOS E DADOS

ABERTOS

DISSERTACAO

CURITIBA

2017

PAULO CARVALHO DINIZ JUNIOR

SERVICOS TELEMATICOS EM UMA REDE DE TRANSPORTEPUBLICO BASEADOS EM VEICULOS CONECTADOS E DADOS

ABERTOS

Dissertacao apresentada ao Programa de Pos-graduacao em Engenharia Eletrica e InformaticaIndustrial da Universidade Tecnologica Federal doParana como requisito parcial para obtencao do graude “Mestre em Ciencias” – Area de Concentracao:Engenharia da Computacao.

Orientador: Heitor Silverio Lopes

CURITIBA

2017

Dados Internacionais de Catalogação na Publicação

D585s Diniz Junior, Paulo Carvalho

2017 Serviços telemáticos em uma rede de transporte público

baseados em veículos conectados e dados abertos / Paulo

Carvalho Diniz Junior.-- 2017.

114 f.: il.; 30 cm.

Disponível também via World Wide Web.

Texto em português, com resumo em inglês.

Dissertação (Mestrado) - Universidade Tecnológica

Federal do Paraná. Programa de Pós-graduação em Engenharia

Elétrica e Informática Industrial. Área de Concentração:

Engenharia de Computação, Curitiba, 2017.

Bibliografia: f. 74-76.

1. Transporte urbano - Curitiba (PR). 2. Planejamento

urbano - Aspectos ambientais. 3. Sistemas de transmissão

de dados. 4. Telemática. 5. Levantamentos de origem e

destino do trânsito. 6. Métodos estatísticos. 7. Sistemas

inteligentes de veículos rodoviários. 8. Métodos de

simulação. 9. Engenharia elétrica – Dissertações. I. Lopes,

Heitor Silvério, orient. II. Universidade Tecnológica

Federal do Paraná. Programa de Pós-graduação em Engenharia

Elétrica e Informática Industrial. III. Título.

CDD: Ed. 22 -- 621.3

Biblioteca Central do Câmpus Curitiba - UTFPR

Ministério da Educação Universidade Tecnológica Federal do Paraná Diretoria de Pesquisa e Pós-Graduação

TERMO DE APROVAÇÃO DE DISSERTAÇÃO Nº____

A Dissertação de Mestrado intitulada “Serviços Telemáticos em uma Rede de Transporte Público Baseados em Veículos Conectados e Dados Abertos” defendida em sessão pública pelo(a) candidato(a) Paulo Carvalho Diniz Junior, no dia 29 de agosto de 2017, foi julgada para a obtenção do título de Mestre em Ciências, área de concentração Engenharia da Computação, e aprovada em sua forma final, pelo Programa de Pós-Graduação em Engenharia Elétrica e Informática Industrial

BANCA EXAMINADORA:

Prof(a). Dr(a). Heitor Silvério Lopes - Presidente – (UTFPR)

Prof(a). Dr(a). Keiko Verônica Ono Fonseca - (UTFPR)

Prof(a). Dr(a). Luis Carlos Erpen de Bona – (UFPR)

A via original deste documento encontra-se arquivada na Secretaria do Programa, contendo a

assinatura da Coordenação após a entrega da versão corrigida do trabalho.

Curitiba, 29 de agosto de 2017.

AGRADECIMENTOS

Os autor reconhece o suporte da municipalidade de Curitiba e parceiros do projeto

“Smart city concepts in Curitiba - innovation for sustainable mobility and energy efficiency”.

Este ultimo financiado pela VINNOVA (Agencia Governamental para Sistemas

Inovadores) na Suecia, liderados pelo KTH Royal Institute of Technology e envolvendo os

seguintes parceiros suecos e brasileiros: Universidade Tecnologica Federal do Parana (UTFPR),

Volvo Bus Corporation, Combitech, URBS (Urbanizacao de Curitiba S.A.) e a prefeitura de

Curitiba.

O autor gostaria de agradecer imensamente tambem ao suporte, resiliencia, atencao e

paciencia do orientador Heitor Silverio Lopes e da professora Keiko Fonseca. Alem da ajuda e

contribuicao essenciais de Daniel Guerra Diniz, Leonardo Presoto de Oliveira e Kelly Trefflich.

O que importa nao e o que acontece, mas como voce reage (Epicteto).

RESUMO

CARVALHO DINIZ JUNIOR, Paulo. SERVICOS TELEMATICOS EM UMA REDEDE TRANSPORTE PUBLICO BASEADOS EM VEICULOS CONECTADOS E DADOSABERTOS. 114 f. Dissertacao – Programa de Pos-graduacao em Engenharia Eletrica eInformatica Industrial, Universidade Tecnologica Federal do Parana. Curitiba, 2017.

Um conceito bastante em voga atualmente e o de cidades inteligentes. Ele define um tipode desenvolvimento urbano capaz de reduzir os impactos ambientais, melhorando os modelosatuais de acesso a recursos naturais, transportes, gestao do lixo, climatizacao residencial esobretudo a gestao da energia (producao e distribuicao).

O massivo volume de dados produzidos por cidades inteligentes oferece uma grandeoportunidade para analisar, compreender e melhorar o modo como elas funcionam e sedesenvolvem. Esta explosao na quantidade de informacoes tem elevado a importancia doaprendizado a partir de dados a um patamar extremamente elevado.

Esta dissertacao tem por objetivo descrever uma metodologia para aquisicao e exploracao dedados de um dos mais importantes pilares de cidades inteligentes: o sistema de transportepublico. Como obter, armazenar e utilizar tais dados a fim de prover a todos os envolvidos,servicos telematicos de alto valor agregado e o problema que se busca resolver neste trabalho.

Cinco servicos telematicos sao propostos sob forma de prova de conceito: avaliacao dacobertura da rede de transporte atual, seguida de uma proposta de novas linhas de onibus;avaliacao indireta da ocupacao diaria dos onibus da cidade; cerca-eletronica com os limitesgeograficos definidos pelos itinerarios das linhas; servicos de alerta de velocidade e demanutencao.

Os resultados sao bastante coerentes e promissores, abrindo um grande leque de possıveistrabalhos futuros a serem explorados.

Palavras-chave: Servicos telematicos, dados abertos, transporte publico, matriz origem-destino

ABSTRACT

CARVALHO DINIZ JUNIOR, Paulo. TELEMATICS SERVICES IN A PUBLICTRANSPORTATION NETWORK BASED ON CONNECTED VEHICLES AND OPENDATA. 114 f. Dissertacao – Programa de Pos-graduacao em Engenharia Eletrica e InformaticaIndustrial, Universidade Tecnologica Federal do Parana. Curitiba, 2017.

Smart city is a very trendy concept today. It defines a type of urban development capable ofreducing environmental impacts, enhancing current models of access to natural resources, bettertransportation systems, waste management, residential climatization and, above all, energymanagement (production and distribution).

The huge data volume produced by smart cities offers a great opportunity to analyze, understandand improve the way cities work and grow. This explosion in the amount of digital informationhas elevated the importance of learning from data to a higher level.

This document aims at describing a methodology for acquiring and exploring data from one ofthe most important pillars of smart cities: the public transportation system. How to acquire,store and use such data in order to provide to all stakeholders telematics services with highadded value is the problem that is sought to solve in this work.

Five telematics services proof of concept are proposed: assessment of current network coveragefollowed by the proposal of some new bus lines; indirect evaluation of buses’ passengersoccupation during the day; geofence with geographical boundaries according to itineraries;speed alert and maintenance reminder services.

The results are very coherent and promising, opening up a wide range of possible future workto be explored.

Keywords: Telematics, open data, public transportation, OD matrix

LISTA DE FIGURAS

–FIGURA 1 Exemplo de estacao tubo. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14–FIGURA 2 Visao geral da metodologia proposta. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25–FIGURA 3 Diagrama de relacionamento entre as diversas bases de dados criadas. . . . 28–FIGURA 4 Visao geral da grade quadricular sobre a cidade de Curitiba. . . . . . . . . . . . . 31–FIGURA 5 Exemplo de inferencia do ponto de desembarque - parte 1. . . . . . . . . . . . . . . 34–FIGURA 6 Exemplo de inferencia do ponto de desembarque - parte 2. . . . . . . . . . . . . . . 35–FIGURA 7 Exemplo de inferencia do ponto de desembarque - parte 3. . . . . . . . . . . . . . . 35–FIGURA 8 Exemplo de inferencia do ponto de desembarque - parte 4. . . . . . . . . . . . . . . 36–FIGURA 9 Configuracoes do QGIS para producao dos mapas de calor. . . . . . . . . . . . . . 39–FIGURA 10 Servicos Telematicos propostos. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40–FIGURA 11 Grades consideradas na busca por linhas diretas cobrindo os principais pares

origem-destino. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41–FIGURA 12 Visao detalhado da metodologia proposta. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46–FIGURA 13 Extracao da base de utilizacao dos cartoes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48–FIGURA 14 Extracao da base de pontos de onibus. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48–FIGURA 15 Extracao da base de percurso do itinerario das linhas. . . . . . . . . . . . . . . . . . . 49–FIGURA 16 Extracao da base contendo a posicao GPS de todos os onibus da rede. . . . 49–FIGURA 17 Extracao da base contendo o detalhe sobre os pontos do tipo tubo ou

terminais. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49–FIGURA 18 Histograma de utilizacao dos cartoes de transporte no perıodo considerado. 50–FIGURA 19 Histograma de utilizacao dos cartoes de transporte para um unico dia. . . . 50–FIGURA 20 As 15 linhas e veıculos mais utilizados segundo a base de cartoes. . . . . . . . 51–FIGURA 21 Exemplo de onibus tıpico da rede de Curitiba. . . . . . . . . . . . . . . . . . . . . . . . . . 51–FIGURA 22 Quantidade de dados de utilizacao dos cartoes de transporte resultante dos

processos de limpeza dos dados. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53–FIGURA 23 Quantidade de utilizacao de um mesmo cartao por dia. . . . . . . . . . . . . . . . . . 54–FIGURA 24 Exemplo de grade incluindo diversos pontos de onibus. . . . . . . . . . . . . . . . . . 55–FIGURA 25 Tentativa de visualizacao do grafo de origem-destino completo. . . . . . . . . . 56–FIGURA 26 Visualizacao do grafo de origem-destino considerando as mil ligacoes mais

importantes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57–FIGURA 27 Exemplos de mapa de calor utilizando R e GoogleMaps. . . . . . . . . . . . . . . . . 58–FIGURA 28 Concentracao dos principais pontos de origem e destino de passageiros -

Dias de semana. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58–FIGURA 29 Concentracao dos principais pontos de origem e destino de passageiros -

Dias de final de semana. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59–FIGURA 30 Comparativo dos principais pontos de embarque e desembarque de

passageiros. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60–FIGURA 31 Visualizando a matriz origem-destino filtrada por um ponto de interesse. . 60–FIGURA 32 Top 50 pares origem-destino identificados sem cobertura direta por alguma

linha existente. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61–FIGURA 33 Exemplo de ligacao com alta utilizacao mas sem cobertura direta por

alguma linha existente. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62

–FIGURA 34 Indicativo indireto sobre nıvel de utilizacao dos onibus. . . . . . . . . . . . . . . . . 63–FIGURA 35 Grau de afluencia de passageiros nos pontos de embarque e desembarque

para a linha 461. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64–FIGURA 36 Exemplo de servico de cerca eletronica. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68–FIGURA 37 Exemplo de servico de alerta de velocidade. . . . . . . . . . . . . . . . . . . . . . . . . . . . 69–FIGURA 38 Exemplo de servico de avaliacao da velocidade media da linha. . . . . . . . . . 69–FIGURA 39 Exemplo de servico de avaliacao da velocidade media em diversos trechos

da linha. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70–FIGURA 40 Exemplo de servico de Alerta de Manutencao preventiva. . . . . . . . . . . . . . . . 70

LISTA DE TABELAS

–TABELA 1 Principais entradas e saıdas da etapa “Obtencao e Armazenamento dosdados” . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

–TABELA 2 Principais entradas e saıdas da etapa “Limpeza e Preparacao dos dados” . . 29–TABELA 3 Principais entradas e saıdas da etapa “Associacao dos dados de GPS as

informacoes de utilizacao dos cartoes” . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31–TABELA 4 Principais entradas e saıdas da etapa “Estimacao do Ponto de Desembarque

de cada usuario” . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33–TABELA 5 Principais entradas e saıdas da etapa “Criacao e Visualizacao da Matriz de

Origem-Destino” . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36–TABELA 6 Principais entradas e saıdas da etapa “Oferta de pacote de Servicos

Telematicos” . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39–TABELA 7 Quantidade de dados obtidas durante o perıodo considerado. . . . . . . . . . . . . 48–TABELA 8 Associacao entre cod urbs e os quinze terminais e tubos mais utilizados. . 52–TABELA 9 Dispersao na definicao da posicao GPS de passagem do cartao. . . . . . . . . . . 55–TABELA 10 Dispersao do tempo medio de permanencia dos passageiros na linha 461. . 63–TABELA 11 Dispersao nos valores medidos de velocidade. . . . . . . . . . . . . . . . . . . . . . . . . . 66

SUMARIO

1 INTRODUCAO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121.1 SISTEMA DE TRANSPORTE PUBLICO DE CURITIBA . . . . . . . . . . . . . . . . . . . . . . . 131.2 CIDADES INTELIGENTES E DADOS ABERTOS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151.3 VEICULOS CONECTADOS E SERVICOS TELEMATICOS . . . . . . . . . . . . . . . . . . . . 161.4 OBJETIVOS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 171.5 ESTRUTURA DA DISSERTACAO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 182 REVISAO BIBLIOGRAFICA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 192.1 TRABALHOS CORRELATOS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 192.2 FERRAMENTAS UTILIZADAS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 222.2.1 Python . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 222.2.2 Web-services e R . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 222.2.3 Base de dados geo-referenciados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 233 METODOS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 253.1 OBTENCAO E ARMAZENAMENTO DOS DADOS . . . . . . . . . . . . . . . . . . . . . . . . . . . 253.2 LIMPEZA E PREPARACAO DOS DADOS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 293.3 ASSOCIACAO DOS DADOS DE GPS AS INFORMACOES DE UTILIZACAO

DOS CARTOES . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 313.4 ESTIMACAO DO PONTO DE DESEMBARQUE DE CADA USUARIO . . . . . . . . . 333.5 CRIACAO E VISUALIZACAO DA MATRIZ DE ORIGEM-DESTINO . . . . . . . . . . . 363.6 OFERTA DE PACOTE DE SERVICOS TELEMATICOS . . . . . . . . . . . . . . . . . . . . . . . . 393.6.1 Ligacoes importantes sem linha direta dedicada . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 403.6.2 Estimacao do nıvel de utilizacao dos onibus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 413.6.3 Alerta de saıda da rota prevista . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 433.6.4 Alerta de quilometragem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 443.6.5 Alerta de excesso de velocidade . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 444 EXPERIMENTOS E RESULTADOS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 474.1 OBTENCAO E ARMAZENAMENTO DOS DADOS - RESULTADOS . . . . . . . . . . . 474.2 LIMPEZA E PREPARACAO DOS DADOS - RESULTADOS . . . . . . . . . . . . . . . . . . . . 524.3 ASSOCIACAO DOS DADOS DE GPS AS INFORMACOES DE UTILIZACAO

DOS CARTOES - RESULTADOS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 544.4 ESTIMACAO DO PONTO DE DESEMBARQUE DE CADA USUARIO -

RESULTADOS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 554.5 CRIACAO E VISUALIZACAO DA MATRIZ DE ORIGEM-DESTINO -

RESULTADOS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 564.6 OFERTA DE PACOTE DE SERVICOS TELEMATICOS - RESULTADOS . . . . . . . . 615 CONCLUSOES . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 715.1 TRABALHOS FUTUROS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72REFERENCIAS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74Anexo A -- SCRIPT R: OBTER POSICOES GPS E DADOS DOS CARTOES . . . . . . 77Anexo B -- SCRIPT PYTHON: CONTAR QUANTAS VEZES CADA CARTAO FOI

UTILIZADO NO DIA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79Anexo C -- SCRIPT PYTHON: CRIAR GRADES SOBRE A CIDADE DE

CURITIBA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82Anexo D -- SCRIPT SQL: ASSOCIAR GRADES AOS PONTOS DE ONIBUS . . . . . . 84Anexo E -- SCRIPT SQL: UNIR UTILIZACAO DOS CARTOES COM

INFORMACAO DE GPS DOS ONIBUS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86Anexo F -- SCRIPT SQL: DEFINIR GRADE DE PARTIDA E DE CHEGADA . . . . . 89Anexo G -- SCRIPT R: CRIAR GRAFO DAS PRINCIPAIS LIGACOES

ORIGEM/DESTINO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95Anexo H -- SCRIPT SQL: CONFIRMAR AUSENCIA DE COBERTURA DIRETA . 98Anexo I -- SCRIPT PYTHON: CONFIRMAR AUSENCIA DE COBERTURA

DIRETA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101Anexo J -- SCRIPT SQL: IMPLEMENTAR SERVICOS TELEMATICOS . . . . . . . . . 104Anexo K -- SCRIPT PYTHON: IMPLEMENTAR SERVICOS TELEMATICOS . . . 109Anexo L -- TIPOS E CAPACIDADES DOS ONIBUS DE CURITIBA . . . . . . . . . . . . . . . 113

12

1 INTRODUCAO

Alimentada principalmente pelo aumento da capacidade de processamento e o custo

cada vez menor do armazenamento de dados (localmente ou na nuvem) (Executive Office of

the President, 2014), a coleta, o armazenamento e a analise de dados segue uma trajetoria

ascendente e aparentemente sem limites.

A qualquer momento do dia e em qualquer lugar do planeta, grandes volumes de

dados sao produzidos pelos mais diversos dispositivos como celulares, cameras de seguranca,

equipamentos medicos, plataformas de comercio eletronico e sites de redes sociais.

Esta explosao na quantidade de informacoes tem elevado a importancia do aprendizado

a partir de dados a um patamar extremamente elevado. E cada vez maior o numero de cientistas,

decisores e governantes que consideram a analise massiva de dados como uma grande alavanca

para promover melhoras na qualidade de vida e proporcionar um grande crescimento economico

a sociedade (EDWARDS, 2014).

O jornal britanico The Economist em 2010 ja afirmava que “Dados estao se tornando

a nova materia prima dos negocios: Uma entrada economica quase equivalente ao capital ou

ao trabalho”. Na mesma linha, tambem em 2010, a Gartner (uma das maiores empresas de

consultoria do mundo) afirmava que “Dados serao o petroleo do seculo 21”.

Como inumeros “dispositivos conectados” estao se tornando parte de nossas

vidas diarias incluindo dispositivos vestıveis (wearables), sensores, cameras de vigilancias,

aplicativos de smartphones, sistemas de automatizacoes residenciais etc., temos cada vez mais

informacoes disponıveis. Todas estas informacoes que compoem tais dados estao a disposicao

para serem analisados, com a esperanca que os resultados de tais analises ajudem a desenvolver

novas intuicoes, ideias e percepcoes sobre o mundo e ajude a melhora-lo (GESELOWITZ,

2014).

Um conceito bastante em voga atualmente e o de “cidades inteligentes”. Este

conceito define um tipo de desenvolvimento urbano capaz de reduzir os impactos ambientais,

melhorando os modelos atuais de acesso a recursos naturais, transportes, gestao do lixo,

13

climatizacao residenciais e gestao da energia.

Do conceito de cidades inteligentes, muitas outras ideias e tendencias vem sendo

identificadas e fomentadas. A tıtulo de exemplo tem-se projetos de SmartGrid (para gestao

inteligente no consumo de energia) e projetos de “veıculos conectados” (buscando auxiliar na

reducao do transito nas cidades, por exemplo).

Para entender o conceito de “Veıculo Conectado”, pode-se dividi-lo em tres

componentes (PORTER; HEPPELMANN, 2015):

• Componentes fısicos: Referem-se as pecas mecanicas e eletronicas propriamente ditas:

motor, pneu, bateria etc.;

• Componentes inteligentes: Referem-se aos captores, microprocessadores, memorias,

comandos, softwares, interfaces homem-maquina etc.. No caso automotivo, pode-se citar

como exemplos a unidade de injecao eletronica, o sistema de frenagem ABS, o limpador

de para-brisa automatico acoplado ao sensor de chuva, o sistema multimıdia etc.;

• Componentes de conectividade: Referem-se a componentes que permitam a comunicacao

com ou sem fio com o produto, como e o caso de antenas, modens, protocolos de

comunicacao etc..

A chegada massiva dos componentes de conectividade no mundo automotivo e que

tem modificado o panorama e amplificado as possibilidades para esta area.

Esta dissertacao explora um dos principais eixos de cidades inteligentes: o sistema de

transporte publico.

A primeira e a mais essencial questao para o sucesso de qualquer processo de analise

massiva de dados, e ter claramente definido o problema que se deseja resolver (EMC, 2015).

Como obter, armazenar e utilizar os dados abertos do transporte publico de Curitiba a fim de

prover a todos os envolvidos, servicos telematicos de alto valor agregado e o problema que se

busca resolver neste trabalho.

1.1 SISTEMA DE TRANSPORTE PUBLICO DE CURITIBA

Curitiba e a capital do estado do Parana, Brasil, e se estende por uma area de 430,9

km2. De acordo com o ultimo censo brasileiro (datando de 2010), a cidade tem cerca de 1,8

milhoes de habitantes, sendo a oitava mais populosa do paıs.

14

Planejamento urbano e essencial para ordenar e melhorar o desenvolvimento da

cidade. Planejar o espaco urbano, considerando todos os aspectos de uso do territorio, e

fortemente ligado aos sistemas de transporte publico e suas infraestruturas (GUERRA, 2011).

Curitiba e conhecida como a “capital ecologica do Brasil”, tendo uma longa tradicao no

planejamento urbano sustentavel e conceitos urbanistas inovadores. A cidade ja foi considerada

uma das cidades mais inteligentes do mundo e e atualmente membro da C40 megacidades

(KOZIEVITCH et al., 2016).

O sistema de transporte publico de Curitiba e controlado, gerido e operado pela URBS

(Urbanizacao de Curitiba S.A.)1. Trata-se de uma empresa de capital misto com mais de 99%

das acoes pertencentes a Prefeitura de Curitiba2.

No inıcio da decada de 70, a URBS criou corredores ligando os eixos norte e sul

da cidade atraves de onibus expressos (atualmente cobertos tambem por onibus articulados ou

biarticulados, com capacidade para cerca de 250 passageiros por onibus). Diversos terminais

foram criados para conectar estes corredores as linhas alimentadoras (que conectam regioes

mais distantes da cidade). Existem tambem algumas linhas especıficas (Interbairros) que

conectam as regioes perifericas sem passar pelo centro da cidade, alem de algumas linhas diretas

oferecendo alternativas mais rapidas e eficientes para os usuarios. Estas, utilizam pontos de

onibus especiais chamados Estacao Tubo (ver Figura 1), onde o usuario paga ao entrar no ponto

de onibus, reduzindo o tempo de embarque nos onibus e melhorando a agilidade do sistema

como um todo.

Figura 1: Exemplo de ponto de onibus utilizado pelas linhas expressas da cidade: Estacao Tubo.

A respeito do modo de pagamento, Curitiba utiliza a tecnologia de smart card como

cartao de transporte (trata-se de um cartao plastico contendo um chip capaz de validar a

coleta da tarifa do onibus atraves de Comunicacao por Campo de Proximidade - Near Field

Communication - NFC em ingles (PELLETIER et al., 2011)). Os usuarios podem pagar as

1http://www.urbs.curitiba.pr.gov.br/transporte/rede-integrada-de-transporte (site visitado em 02/07/2017)2https://www.urbs.curitiba.pr.gov.br/institucional/acionistas - visitado em 02/07/2017

15

viagens com dinheiro ou utilizando o cartao de transporte (que pode ser carregado em diversos

pontos da cidade). Segundo ultimos dados oficiais divulgados (datando de 2016), cerca de 60%3

dos usuarios do sistema, utilizam o cartao de transporte como meio de pagamento.

1.2 CIDADES INTELIGENTES E DADOS ABERTOS

Em 2012, pela primeira vez, mais de 50% da populacao mundial passou a viver em

cidades (isto significa mais de 3,5 bilhoes de pessoas). De acordo com as Nacoes Unidas, este

numero deve passar de metade para dois-tercos em 2040 (BABINET, 2015).

De certo modo, uma cidade e a concentracao de diversos tipos de fluxos: pessoas,

trens, carros, informacao, energia, agua potavel, esgoto etc. Um dos maiores desafios para

muitas administracoes publicas ao redor do planeta e aprender a lidar com todos esses fluxos de

forma eficiente e ambientalmente responsavel.

Este enorme crescimento da densidade populacional humana em areas urbanas tem

forcado governos a repensar sobre o proprio funcionamento das cidades.

E facil identificar muitos problemas que as cidades deverao enfrentar a fim de se

manterem atrativas tanto para os negocios quanto para os cidadaos.

A partir destas necessidades, nasceu o conceito de Cidades Inteligentes (Smart Cities).

Este conceito esta relacionado a um padrao de desenvolvimento capaz de reduzir impactos

ambientais, melhorando, por exemplo, acessos a recursos naturais, gestao de energia e de

transporte (CHEN et al., 2014). Ele esta fortemente relacionado a obtencao e analise de dados,

com o intuito de aumentar a compreensao, avaliar e melhorar o modo como as cidades trabalham

e se desenvolvem4.

Em 2014, um consorcio de partes interessadas (stakeholders) suecas e brasileiras foi

criado com o intuito de promover o desenvolvimento urbano sustentavel em Curitiba (projeto

chamado Smart city concepts in Curitiba)5.

Este projeto pode ser visto como o ponto de partida para iniciativas com dados abertos

na cidade. Dados abertos (do ingles Open Data) significa dados livres acessıveis a qualquer um.

Eles devem ser publicados de uma maneira estruturada e compartilhado sob uma licenca aberta,

3http://www.urbs.curitiba.pr.gov.br/transporte/estatisticas/uso cartoes (site visitado em 02/07/2017)4Alguns exemplos reais de avancos em cidades inteligentes nos EUA podem ser encontrados neste artigo

do The Wall Street Journal https://www.wsj.com/articles/the-rise-of-the-smart-city-1492395120 (site visitado em02/07/2017)

5http://multimidia.curitiba.pr.gov.br/2016/00180778.pdf (site visitado em 02/07/2017)

16

garantindo sua livre utilizacao, sem nenhuma barreira tecnica ou legal (BABINET, 2015)6.

1.3 VEICULOS CONECTADOS E SERVICOS TELEMATICOS

Dado seu alto impacto em engarrafamentos, poluicao do ar e mobilidade de pessoas

e mercadorias, uma das pecas mais crıticas do quebra-cabeca de Cidades Inteligentes e o

transporte publico(KOZIEVITCH et al., 2016) e a mobilidade urbana de forma geral. Cidades

Inteligentes serao capazes de suportar sistemas de transporte multimodais, facilitar a busca por

vagas de estacionamento, controlar de forma inteligente os semaforos sincronizando-os, por

exemplo, com os horarios e posicoes dos onibus da cidade7.

Alias, com o advento de novas tecnologias nesta area, transformando onibus ordinarios

em onibus conectados (capazes de se comunicar a distancia alguns de seus estados e

parametros), e possıvel ter acesso a uma grande quantidade de dados, oferecendo uma mirıade

de possibilidades para ajudar a organizar, planejar e gerir de forma inteligente o sistema de

transporte publico.

Veıculos conectados sao uma das maiores tendencias atualmente no mundo

automotivo, conforme e apresentado pela imprensa e empresas de consultoria especializadas,

tais como a McKinsey & Company8. Ele tambem e considerado como um dos pilares da

proxima revolucao que o setor deve viver: veıculos autonomos.

Tanto as montadoras de luxo como as mais populares, veem as tecnologias associadas

ao veıculo conectado como essenciais para seus futuros. Ate 2020, o veıculo conectado

deve transformar de forma disruptiva todo o ecossistema automotivo. No entanto, ainda

restam muitos desafios tecnicos, legais e de seguranca a serem vencidos para que os futuros

consumidores realmente confiem em veıculos altamente conectados e autonomos (VIERECKL

et al., 2015).

A palavra telematica (formada da juncao das palavras telecomunicacoes e informatica)

foi cunhada pela primeira vez em um relatorio destinado ao governo frances em maio de

1978 (NORA; MINC, 1978). Este relatorio foi o resultado de uma trabalho solicitado pela

presidencia da republica para “fazer progredir a reflexao sobre como conduzir a informatizacao

6Uma lista das cidades mais inteligentes da Europa, bem como algumas das iniciativas de Open Datadas mesmas e apresentada neste artigo do jornal britanico The Guardian https://www.theguardian.com/media-network/2015/oct/14/manchester-barcelona-smart-cities-open-data (site visitado em 02/07/2017)

7ver http://www.techrepublic.com/article/smart-cities-6-essential-technologies/ para alguns outros exemplosneste sentido (site visitado em 02/07/2017)

8http://www.mckinsey.com/industries/high-tech/our-insights/disruptive-trends-that-will-transform-the-auto-industry (site visitado em 02/07/2017)

17

na sociedade”.

Ainda que no meio academico a palavra ainda tenha mantido seu sentido mais

amplo, comercialmente ela e geralmente associada a telematica veicular (tambem chamada

de “servicos conectados”). O padrao IEEE 802.11p trata da telematica veicular versando

sobre a problematica de trazer a conectividade sem fio para o ambiente veicular. O trabalho

de (SARQUIS, 2013) apresenta maiores detalhes sobre esta norma, bem como um caso de

aplicacao no contexto de comunicacao entre um veıculo e uma estacao rodoviaria.

Um veıculo conectado e um veıculo capaz de comunicar seus dados, estados e

informacoes com agentes externos (como servidores, empresas, call-centers etc) oferecendo

novas possibilidades de servicos aos usuarios e a todos os atores interagindo com ele. Novos

servicos, como o rastreamento de veıculos roubados podem ser criados e oferecidos; alem de

servicos tradicionais ja existentes, como a assistencia 24 horas, podem ser abrilhantados com a

ajuda da conectividade. Tais tipos de servicos sao tambem conhecidos por Servicos Telematicos

Automotivos ou, simplesmente, Servicos Telematicos.

Conforme sera apresentado, os onibus conectados de Curitiba ainda sao bastante

tımidos com relacao a disponibilizacao de seus dados e suas capacidades de conectividade. No

entanto, essas capacidades ja permitem, por exemplo, criar a chamada matriz de origem-destino

(matriz O/D), que basicamente descreve de onde os usuarios vem e para onde eles vao.

Esta matriz pode ter diversas aplicacoes para uma agencia de gestao de transito:

planejamento do servico ao longo do dia; analise da operacao global do sistema; avaliacao

do impacto de alguma alteracao da rede e melhora na gestao do servico (CUI, 2006).

1.4 OBJETIVOS

O objetivo geral deste trabalho e apresentar, de forma simples e direta, como os dados

abertos da cidade de Curitiba podem ser obtidos, armazenados e melhor utilizados.

No caso deste trabalho, a matriz O/D sera a base de dois dos servicos telematicos

propostos. De modo geral, sob a forma de uma prova de conceito, os seguintes servicos serao

apresentados: cerca-eletronica, alerta de velocidade, alerta de manutencao, nova proposta de

linhas e avaliacao do nıvel de ocupacao dos onibus.

Para tal, os seguintes objetivos especıficos foram buscados:

• Apresentar uma alternativa eficaz para a obtencao contınua dos dados abertos do

sistema de transporte publico de Curitiba (dados de utilizacao dos cartoes de transporte,

18

posicionamento geografico dos onibus da rede e dados diversos sobre a estrutura do

sistema de transporte em si);

• Identificar pontos de correcao e ajustes nos mesmos e prover um retorno a URBS sobre

eventuais acrescimos de informacoes (capazes de permitir um melhor aproveitamento dos

dados ja disponibilizados);

• Criar uma representacao aproximada do modo de movimentacao dos usuarios do sistema,

no que tange suas respectivas origens e destinos (atraves da criacao e visualizacao da

matriz origem/destino);

• Utilizar tais informacoes para propor algumas opcoes de servicos telematicos que

poderiam ser facilmente colocadas a disposicao de todos os usuarios.

Criar uma matriz O/D e utiliza-la junto com outros dados brutos tambem disponıveis,

com o intuito de propor servicos telematicos com alto valor agregado, e a maior contribuicao

deste trabalho.

1.5 ESTRUTURA DA DISSERTACAO

O texto segue com o Capıtulo 2 contendo a revisao bibliografica e um pouco mais de

detalhes sobre as ferramentas utilizadas.

O Capıtulo 3 apresenta as hipoteses, condicoes e metodos fundamentais para cada

uma das etapas necessarias a passagem dos dados brutos da cidade a exploracao dos servicos

telematicos. Ela e seguida pelo Capıtulo 4 contendo a discussao dos resultados obtidos em cada

uma das etapas apresentadas.

Este texto e finalizado com o Capıtulo 5 apresentando as conclusoes e as diversas

possibilidades de trabalhos futuros que se apresentam.

19

2 REVISAO BIBLIOGRAFICA

2.1 TRABALHOS CORRELATOS

A literatura esta repleta de exemplos de utilizacao de dados abertos do sistema de

transporte publico (para trens e/ou onibus) em varias cidades do mundo. Em sua imensa

maioria, os trabalhos se dedicam a produzir, de forma automatica a partir destes dados, as

chamadas Matrizes Origem/Destino (matriz O/D).

Segundo (CUI, 2006), isto se deve ao fato de tecnologias como cobranca automatizada

de tarifas (Automated Fare Collection - AFC em ingles) e localizacao automatica de veıculos

(Automated Vehicle Location - AVL em ingles), estarem cada vez mais disseminadas nos

sistemas de transporte ao redor do mundo (como e tambem o caso de Curitiba).

No entanto, mesmo que diversos trabalhos compartilhem ideias e objetivos, a

preparacao e preprocessamento dos dados disponıveis e bastante peculiar e especıfico a cada

cidade (observamos diferencas tanto no foco como na metodologia) (GUERRA, 2011).

Uma matriz O/D basicamente quantifica e sintetiza a mobilidade associada a pessoas

e bens (CACERES et al., 2008), descrevendo o numero de viagens realizadas entre cada regiao

de origem e de destino, para um certo perıodo de tempo.

Esta maneira de obter a matriz O/D quando comparado aos metodos tradicionais

(atraves de pesquisas manuais, entrevistas e contagens), e bastante atrativa por ser muito mais

barata, rapida e, em certos aspectos, mais precisa. Por exemplo, a municipalidade de Curitiba

iniciou em marco de 2016 uma pesquisa de Origem e Destino tradicional1 (entrevistando

cerca de 48000 pessoas, a fim de obter ao menos 16000 entrevistas validas) com previsao

de divulgacao dos resultados no final de 2017. Porem, dado seu alto custo (cerca de R$ 6,3

milhoes) e tempo necessario de realizacao (por volta de dez meses), nao e possıvel que seja

aplicada com uma frequencia elevada (sendo realizadas a cada dez anos, aproximadamente

(GUERRA, 2011)).1http://www.curitiba.pr.gov.br/noticias/pesquisa-origem-destino-comeca-nesta-sexta-feira-em-curitiba/39381

(visitado em 02/07/2017)

20

Esta pesquisa tradicional tem tambem outros objetivos, como identificar as razoes

e motivacoes por tras de cada mobilidade. Este tipo de informacao e mais difıcil de ser

obtida atraves da analise de dados dos cartoes de transporte. Ainda assim, existem trabalhos

que buscam avancar neste sentido tambem, relacionando os dados dos cartoes a dados socio-

demograficos da cidade, como e o caso de (KUHLMAN, 2015).

Um otimo survey sobre o uso de dados abertos dos onibus e trens para aplicacao

em transporte publico, respondendo aos mais diversos objetivos operacionais, taticos ou

estrategicos, pode ser encontrado em (PELLETIER et al., 2011).

Um dos primeiros estudos sobre o uso de dados AFC para definicao de uma matriz

O/D ocorreu em Sao Francisco, nos Estados Unidos, na decada de 80 ((BUNEMAN, 1984)).

Tratava-se de um sistema de transporte ferreo, cujo controle do cartao de transporte era feito no

embarque e no desembarque facilitando, portanto, a precisa identificacao dos pontos de origem

e destino de cada usuario.

A maioria dos sistemas de transporte de onibus ao redor do mundo possui controle de

validacao apenas na entrada do mesmo (como tambem e o caso de Curitiba). Isso significa que

os usuarios nao validam seus cartoes de transporte quando saem do sistema. Portanto, nao e

possıvel definir precisamente o destino dos usuarios. Como consequencia, algumas hipoteses

devem ser assumidas a fim de estimar o ponto de descida de cada usuario.

Tais hipoteses tiveram suas bases estabelecidas em (ZHAO, 2004), na cidade de

Chicago em 2004, e serao apresentadas no Capıtulo 3. Elas tiveram pouca evolucao desde entao,

contando essencialmente com melhorias marginais como uma melhor definicao dos horarios do

dia a serem considerados (TREPANIER et al., 2007) (evitando considerar o dia como sendo

de 0h00 ate 23h59, mas algo do tipo 4h00 do dia “d” ate 3h59 do dia “d+1”) ou tentativas de

melhoria na identificacao dos pontos de transferencia (com base nos tempos levados em cada

transicao), como o que e apresentado em (BAGCHI; WHITE, 2004).

Em 2007, na cidade de Quebec, (TREPANIER et al., 2007) aplica este metodo e levanta

a importante questao referente a validacao dos resultados obtidos. Em 2008, (TREPANIER et

al., 2008) prossegue com um estudo onde apresenta uma forma de modelagem do sistema de

transporte (em linguagem orientada a objeto) e busca comparar os resultados com uma pesquisa

O/D realizada na cidade no mesmo perıodo (algo que podera ser feito tambem com o resultado

desta dissertacao).

Na China, tambem em 2007, (LIANFU et al., 2007) constroi uma matriz O/D

utilizando apenas dados AFC. Como nao utiliza AVL e nao dispoe de daos estruturais da rede de

21

transporte, a identificacao dos pontos de onibus e feita atraves de um questionario preenchido

pelos motoristas com o horario de parada em cada ponto.

A primeira aplicacao no Brasil aconteceu com (FARZIN, 2008) na cidade de Sao

Paulo. O sistema AVL estava presente apenas em alguns poucos onibus, o que dificultou a

validacao e exaustividade dos resultados. Em 2011, (GUERRA, 2011) tambem aplicou um

metodo semelhante na cidade de Maceio. Como tambem nao dispunha de um sistema AVL,

considerou o ponto de embarque e desembarque atraves da comparacao do horario de validacao

do cartao com a tabela horaria das linhas de onibus. Alem disso, a partir desta primeira matriz

(chamada de matriz semente, considerando apenas os usuarios com cartao de transporte), ele

expandiu a matriz unindo-a a dados de contagem de trafego atraves de um programa profissional

especializado chamado TransCAD2.

Formas inovadoras de visualizacao tambem sao de extrema importancia, pois facilitam

a comunicacao sobre os resultados encontrados destas analises. Por exemplo (MA; WANG,

2014), (CALABRESE, 2013) e (COME et al., 2014) apresentam uma boa visao geral de

possıveis solucoes para responder ao problema da visualizacao de grandes volumes de dados.

Sao bem poucos os trabalhos que vao alem da criacao automatica da matriz O/D,

se aproximando, ainda que em pequena escala, dos tipos de servicos telematicos propostos

nesta dissertacao. Sao eles: Identificar irregularidades nas transacoes a fim de evidenciar erros,

fraudes ou equipamentos defeituosos (DEAKIN; KIM, 2001); Estudar o trajeto preciso que cada

usuario teria empregado (HOFFMAN et al., 2009); Calcular o tempo de vida util de um cartao

de transporte (TREPANIER; MORENCY, 2010); Avaliar a aderencia a tabela de horarios ou a

quilometragem total percorrida por cada veıculo e usuario (TREPANIER et al., 2009, 2009);

Estimar quais os pontos de onibus com maior afluencia de usuarios (TREPANIER et al., 2007);

Propor novas linhas visando adaptar a rede existente as reais necessidades dos usuarios (CHU;

CHAPLEAU, 2008; CHU et al., 2009). Neste mesmo sentido de recriar as linhas existentes,

(CALABRESE, 2013) propoe um metodo semelhante em Abidjan, na Costa do Marfim, atraves

de dados do sistema de telefonia celular da cidade.

Em suma, muitos artigos atacam o problema de criacao da matriz O/D atraves de

informacoes AVL e AFC, porem, poucos mostram como transforma-las em servicos telematicos

aos cidadaos ou ao gestor do proprio sistema. Esta e a maior contribuicao desta dissertacao.

2http://www.caliper.com/tcovu.htm

22

2.2 FERRAMENTAS UTILIZADAS

2.2.1 PYTHON

Python e uma linguagem de programacao interpretada bastante poderosa, rapida e de

facil aprendizado3. Python integra-se facilmente com outras linguagens e sistemas e possui

codigo aberto (facilitando sua utilizacao inclusive para usos comerciais). Nao obstante, ela e

amplamente utilizada no meio industrial, cientıfico e academico.

Python possui uma comunidade bastante ativa de desenvolvedores e utilizadores.

Milhares de modulos e aplicacoes utilizando Python existem hoje no mercado: desenvolvimento

para web e internet, acesso a banco de dados, aplicacoes em areas cientıficas e educacionais,

desenvolvimento de jogos entre outros. A sua integracao com um sistema de gestao de base de

dados foi especialmente explorada neste trabalho.

Independentemente da linguagem de programacao, possuir uma boa ferramenta de

desenvolvimento (chamado de IDE - Integrated Development Environment) e de bastante

utilidade pois facilita em muito a edicao e validacao do programa que se deseja implementar.

Existem diversos IDEs para Python, dentre eles pode-se citar o Pydev, PyCharm, Wing IDE,

Spyder Python, PTVS, VIL ou KOMODO IDE. A escolha do IDE a ser utilizado depende

essencialmente das necessidades do desenvolvedor, bem como do orcamento disponıvel para

tal. Neste trabalho, utilizou-se a versao gratis (sob licenca Apache) do IDE PyCharm como

ambiente de desenvolvimento para as tarefas realizadas em Python.

2.2.2 WEB-SERVICES E R

Um web-service pode ser entendido como uma aplicacao que funciona como interface

entre dois sistemas diferentes, possibilitando a comunicacao e integracao entre ambos.

Os dados abertos da cidade de Curitiba sao disponibilizados atraves da publicacao de

web-services dedicados uma vez que os dados estao armazenados em servidores e banco de

dados internos a URBS. Para serem acessados faz-se necessario o envio do pedido ao web-

service que retornara a resposta em um formato padronizado.

R e uma linguagem de programacao utilizada essencialmente para calculos estatısticos

e graficos4. Ele e gratis, tem ampla disponibilidade para diversos sistemas operacionais

e uma enorme quantidade de pacotes e bibliotecas (criados por sua ativa comunidade de

3https://www.python.org/(visitado em 02/07/2017).4https://www.r-project.org/about.html (visitado em 02/07/2017).

23

desenvolvedores) cobrindo diversas areas de estudo.

Ele tem se tornado, junto a linguagem Python, o principal “idioma” de cientista de

dados e estatısticos na realizacao de analises avancadas de dados ou na geracao de graficos

sofisticados.

Neste trabalho, utilizou-se como IDE (tambem gratis e de codigo aberto) R-Studio,

que facilita bastante o uso da linguagem R.

A automatizacao destes chamados foi realizada pelo Windows task scheduler. Ele e um

componente do sistema operacional Microsoft Windows que permite lancar programas scripts

de forma pre-agendada ou em intervalos de tempo regulares5

2.2.3 BASE DE DADOS GEO-REFERENCIADOS

De maneira geral, banco de dados (ou base de dados) e um repositorio onde

informacoes sao armazenadas de forma organizada, permitindo que sejam encontradas

facilmente. Dito de outra forma, sao colecoes organizadas de dados que se relacionam de modo

a criar algum sentido e dar mais eficiencia durante uma pesquisa ou estudo.

As bases de dados sao geridas por um software especıfico chamado de Sistema de

Gerenciamento de Base de Dados (SGBD). Atualmente, existem varios SGBDs disponıveis

no mercado, pagos (como os da Oracle ou o SQL Server da Microsoft) ou gratuitos (como o

MySQL e o PostgreSQL).

PostgreSQL6 e um programa de gestao de base de dados objeto-relacional extensıvel,

com alta conformidade ao padrao da linguagem SQL (Structured Query Language), de codigo

aberto e gratuito.

A linguagem SQL e um linguagem que e usada exclusivamente para criar, manipular

e consultar os dados de base de dados. E atraves do SQL, que os programas interagem com um

banco de dados. Praticamente todas as linguagens de programacao (incluindo Python e R) tem

bibliotecas para acessar e trabalhar com bancos de dados.

Alguns SGBDs possuem tambem capacidade de operar com objetos geograficos

(pontos, linhas, areas etc). PostGIS7 e uma extensao ao PostgreSQL que possibilita o suporte a

objetos geograficos. Permite que atraves de consultas integradas ao codigo SQL, seja possıvel

incluir diretamente condicoes ligadas a posicoes geograficas dos objetos da base (por exemplo,

5https://msdn.microsoft.com/en-us/library/aa446802.aspx (visitado em 02/07/2017).6https://www.postgresql.org/about/ (visitado em 02/07/2017).7http://postgis.net/ (visitado em 02/07/2017).

24

quais sao todos os pontos de onibus a um certo raio de distancia de uma determinada posicao

geografica).

Para trabalhar com SGBDs georreferenciados, um Sistema de Informacao Geografico

ou SIG (Geographic Information System - GIS, em ingles) pode ser de grande valia. Trata-se de

um sistema informatizado para captura, armazenamento, verificacao, integracao, manipulacao,

analise e visualizacao de dados relacionados a posicoes na superfıcie terrestre.

SIG e uma tecnologia e metodologia computacional para coletar, gerenciar, analisar,

modelar e apresentar dados geograficos para uma ampla gama de aplicacoes.

Neste trabalho utilizou-se o QGIS8 como SIG. Ele e gratis e de codigo aberto. Atraves

da conexao deste programa com a base de dados PostgreSQL/PostGIS, e possıvel criar rapida e

facilmente visualizacoes compondo diversas camadas como a localizacao de pontos de onibus

sobre o mapa da cidade, por exemplo.

8https://qgis.org/en/site/about/index.html (visitado em 02/07/2017).

25

3 METODOS

Este capıtulo apresenta, de forma estruturada e cronologica, a metodologia proposta

por este trabalho. A Figura 2 reune as principais etapas a serem seguidas, descritas nas Secoes

seguintes.

Figura 2: Apresentacao dos seis passos fundamentais propostos para passar da obtencao dosdados a exploracao de caracterısticas operacionais da rede de transporte publico atraves de algunsservicos telematicos.

A seguir, sao apresentados tanto a metodologia como os detalhes e hipoteses de cada

etapa. A fim de facilitar a leitura e resumir brevemente cada passo, no inıcio de cada Secao

tem-se uma “ficha de processo” (Tabelas 1, 2, 3, 4, 5 e 6), indicando os principais elementos de

entrada e de saıda de cada uma.

3.1 OBTENCAO E ARMAZENAMENTO DOS DADOS

A URBS disponibilizou (atraves de um portal web e dos chamados web-services) uma

serie de informacoes sobre o sistema de transporte e sua utilizacao pelos usuarios.

E necessario fazer um pre-cadastro antes de ter acesso a tais informacoes. A UTFPR ja

26

Entrada Dados colocados a disposicao pela prefeitura de Curitiba(atraves de web-services e links especıficos)

Saıda Base de dados contendo elementos iniciais, tais como:

• Utilizacao dos cartoes de transporte;

• Posicao dos onibus durante todo o perıodoconsiderado;

• Geolocalizacao de diversos elementos da rede detransporte (pontos de onibus e terminais, tracado daslinhas e associacao entre pontos de onibus e linhas).

Tabela 1: Principais entradas e saıdas da etapa “Obtencao e Armazenamento dos dados”

possuıa cadastro no inıcio deste trabalho, no entanto, qualquer cidadao tem o direito de solicitar

acesso aos dados1.

Dentre os diversos web-services disponibilizados, quatro deles foram essenciais para a

obtencao do material de base deste estudo:

• getLinhas - retorna uma lista com todas as linhas de onibus existentes no sistema publico

de transporte de Curitiba;

• getPontosLinhas - retorna o detalhe sobre cada ponto de onibus que cada uma das linhas

possui. E preciso passar como parametro para este web-service o numero da linha. Logo,

a lista resultante do comando precedente foi utilizada para automatizar a obtencao de

todos os pontos para todas as linhas;

• getShapeLinhas - retorna o detalhe sobre o trajeto/itinerario de cada linha (atraves de

um conjunto de posicoes GPS). E preciso passar como parametro para este web-service

o numero da linha. Logo, a lista resultante do comando getLinhas foi utilizada para

automatizar a obtencao desta informacao para todas as linhas;

• getVeiculosLinha - retorna a coordenada GPS de todos os onibus rodando no sistema no

momento do chamado do web-service;

Alem das funcoes citadas, a informacao sobre a utilizacao dos cartoes de transporte

pode ser obtida atraves de um link dedicado, disponibilizado apenas aos parceiros da URBS,

como e o caso da UTFPR, nao sendo acessıvel a todos os cadastrados.1http://www.urbs.curitiba.pr.gov.br/fale-conosco (referenciar-se a rubrica “Acesso a Informacao - Lei Federal

12.527”) (site visitado em 02/07/2017)

27

A forma escolhida para automatizar a obtencao destes dados foi atraves da combinacao

do uso do Windows task scheduler e de um script bastante simples em R. Os scripts R utilizados

podem ser encontrados no Anexo A.

A informacao sobre as linhas, itinerarios e os pontos de onibus e estatica, necessitando

uma unica execucao do web-service correspondente.

No entanto, a informacao sobre a posicao dos onibus e atualizada a cada dois

minutos. Logo, uma tarefa com periodicidade de dois minutos foi configurada no Windows

task scheduler. Esta tarefa tinha por acao lancar um script em R que: realizava a execucao

do web-service; obtinha o retorno do mesmo; fazia a analise (parsing) dos dados recebidos;

armazenava o resultado em um arquivo tipo texto.

A informacao sobre a utilizacao dos cartoes e bastante volumosa, porem, bem menos

frequente que a anterior. As informacoes sao atualizadas apenas uma vez ao dia. Portanto,

criou-se uma tarefa com recorrencia diaria, que executava atraves do lancamento de um script

em R, o comando para obtencao da base de utilizacao de cartoes do dia anterior. Esta informacao

tambem era processada e salva em um arquivo tipo texto pelo mesmo script em R.

Foram obtidos dados dos dias 29 de outubro de 2016 ate 11 de novembro de 2016. No

entanto, por razoes de indisponibilidade do sistema, os dias 01 e 02 de novembro nao puderam

ser obtidos completamente (tendo sido descartados, portanto, da analise final dos dados).

A Figura 3 mostra um diagrama de relacionamento entre as diversas bases de dados

criadas e carregadas com os dados obtidos. Os atributos em azul nao fazem parte da base inicial

fornecida pela URBS, mas sao necessarios para a aplicacao da metodologia desenvolvida neste

trabalho.

1. URBS CARD raw: Contem os dados de utilizacao dos cartoes. Basicamente, daqui

obtemos a informacao do numero do cartao, o horario, onibus e linha na qual o mesmo

foi validado. Vale ressaltar que os dados sao anonimizados, nao sendo possıvel saber os

dados do portador do cartao. Tambem nao existe nenhuma informacao sobre a posicao

GPS do onibus no momento de validacao do cartao.

2. bus stops table: Tem-se para cada linha da rede, detalhes sobre todos os pontos de onibus

que compoe o itinerario da mesma. Alem da posicao, sentido e numero unico do ponto, a

tabela apresenta a sequencia (coluna seq) indicando a sequencia dos pontos no itinerario

da linha para cada sentido da mesma. A coluna grupo e importante pois possui o mesmo

valor para pontos que fazem parte de uma mesma estrutura maior, como um terminal, por

exemplo.

28

Figura 3: Diagrama de relacionamento entre as diversas bases de dados utilizadas.

3. lines shape: Descreve o trajeto previsto no itinerario de cada linha. Apos uma pequena

transformacao (convertendo as informacoes de latitude e longitude em um objeto

geografico do tipo ponto ou diretamente em uma linha) o conteudo desta tabela pode

ser visualizado no QGIS.

4. Period BUS GPS: Todas as posicoes GPS emitidas por cada veıculo sao armazenadas

nesta tabela. Prefixo refere-se a informacao sobre o veıculo (e o mesmo que codveiculo

da tabela URBS CARD raw ). O web-service para obter este servico retorna apenas a

hora da ultima informacao de GPS emitida. Logo, foi necessario acrescentar uma coluna

(scriptdate) contendo o dia e hora quando o web-service foi lancado.

Alem da base de pontos obtidas pelo web-service, os terminais e tubos necessitam

um tratamento especial. A utilizacao de um cartao de transporte na entrada de um terminal

ou estacao tubo e identificada de forma especial na base de utilizacao dos cartoes. Cada

equipamento validador do cartao em um destes locais possui um codigo especıfico, inicialmente

nao disponibilizado pela URBS. Apos diversas reunioes e trocas de informacoes com a mesma,

boa parte destes codigos foi esclarecida, compondo a tabela base tt no PostgreSQL2. A estrutura

2A URBS ficou de evoluir a implementacao de seus web-services para incluir tais informacoes tambem namesma base de dados GPS dos onibus

29

completa e uma pequena extracao de cada uma destas bases esta apresentada na Secao 4.1.

3.2 LIMPEZA E PREPARACAO DOS DADOS

Antes de poder iniciar propriamente a metodologia para a identificacao da origem e

estimativa do destino de cada usuario, e necessario realizar uma limpeza e preparacao dos dados

brutos, conforme mostrado na Tabela 2.

Entrada Base de dados contendo elementos iniciais, tais como:

• Utilizacao dos cartoes de transporte;

• Posicao dos onibus durante todo o perıodoconsiderado;

• Geolocalizacao de diversos elementos da rede detransporte (pontos de onibus e terminais, tracado daslinhas e associacao entre pontos de onibus e linhas).

Saıda Base de dados contendo um subconjunto dos elementosiniciais, acrescida de algumas informacoes, tais como:

• Utilizacao dos cartoes de transporte apenas para oscasos onde o cartao e utilizado uma ou duas vezes aodia;

• Cada instancia de utilizacao do cartao e categorizadacomo sendo a unica, primeira ou segunda no dia;

• Apenas as utilizacoes de cartoes realizadas emonibus, pontos ou terminais cuja informacao GPS econhecida sao mantidas;

• Cada ponto de onibus e associado ao ID de umagrade quadrada de 500 metros de lado (um conjuntodessas grades e criado cobrindo todo o territorio deCuritiba).

Tabela 2: Principais entradas e saıdas da etapa “Limpeza e Preparacao dos dados”

Uma decisao bastante estruturante para a sequencia do processo e o fato de considerar

apenas o caso onde um mesmo cartao e utilizado uma ou duas vezes ao dia. Tal decisao esta

justificada na Secao 4.2.

Para identificar quantas vezes cada cartao e utilizado em um mesmo dia, criou-se um

procedimento em Python (ver Anexo B). Este procedimento percorre todos os registros (para

30

um determinado dia) da base de cartao por duas vezes. Na primeira ele identifica o total de

utilizacao de cada cartao e na segunda ele atualiza cada instancia (em um atributo chamado

step pass card) como sendo a primeira, segunda, terceira etc utilizacao no dia.

Um dos passos fundamentais para identificar o ponto de origem do usuario e a fusao

das informacoes de utilizacao do cartao com a posicao do onibus no qual o mesmo foi utilizado.

Devido a uma indisponibilidade da informacao, ou incorreta ativacao no sistema em alguns

onibus, diversas instancias de passagem de cartao tiveram que ser descartadas, pois nao existia

informacao de GPS para a linha/veıculo em questao.

A princıpio, os pontos de origem e destino dos usuarios poderiam ser definidos dentre

o conjunto de pontos de onibus da cidade. No entanto, para simplificar a visualizacao, reduzir

o volume de dados final e absorver eventuais erros na predicao dos pontos exatos de origem

e destino, optou-se por mapear os pontos de partida e chegada sobre uma malha quadricular

cobrindo toda a regiao metropolitana da cidade (ver Figura 4).

Esta malha quadricular foi criada automaticamente atraves de um script em Python. O

codigo para tal pode ser encontrado no Anexo C. Este script cria um shapefile contendo cada

uma das grades, que e armazenada sob forma de base de dados geo-referenciada (identificada

por PolygonGrid na Figura 3).

Cada grade e formada por um quadrado de 500 metros de lado. Esta dimensao foi

escolhida pois, segundo a propria URBS, a cada 500 metros seria possıvel encontrar um ponto

de onibus na cidade3.

A base de dados contendo os pontos de onibus foi entao populada com esta informacao

adicional (ID da grade na qual o ponto se insere). Como detalhado no codigo SQL do Anexo D,

esta operacao e bastante facilitada atraves da funcionalidade oferecida pelo PostGIS. Utilizando

a funcao ST MakePoint, cria-se um objeto geografico representando a posicao de cada ponto de

onibus (a partir das informacoes de latitude e longitude). Em seguida, a funcao ST Contains

avalia qual grade (que e, por sua vez, um objeto geografico do tipo area) contem o ponto

geografico que representa o ponto de onibus.

Este procedimento e exatamente o mesmo para associar qualquer outra posicao GPS

(de usuarios ou de elementos da rede) ao respectivo ID da base contendo a grade.

3Informacao confirmada durante o Seminario “Open Data Seminar”, realizada na UTFPR com a presenca derepresentantes da URBS, em 25 de outubro de 2016.

31

Figura 4: Grade composta por quadrados de 500 metros de lado, cobrindo toda a regiao deCuritiba. Cada grade possui um ID unico.

3.3 ASSOCIACAO DOS DADOS DE GPS AS INFORMACOES DE UTILIZACAO DOSCARTOES

Entrada Base de dados contendo a utilizacao dos cartoes detransporte e base de dados com a posicao GPS de todos osonibus da rede.

Saıda Base de dados contendo a utilizacao dos cartoesincrementada com a informacao de GPS, o ID do pontode onibus e o ID da grade onde provavelmente o cartao foivalidado no onibus, estacao tubo ou terminal em questao.

Tabela 3: Principais entradas e saıdas da etapa “Associacao dos dados de GPS as informacoes deutilizacao dos cartoes”

32

A base de utilizacao dos cartoes possui apenas a informacao sobre o numero do cartao,

o onibus/ linha na qual o cartao foi validado e o horario desta validacao (ver a estrutura da

base URBS CARD raw na Figura 3). Logo, a informacao de geolocalizacao nao faz parte desta

base. Portanto, a fim de identificar ou estimar o ponto de partida dos usuarios, faz-se necessario

cruzar as informacoes desta base com as informacoes oriundas da base contendo as posicoes

dos onibus na rede.

Basicamente, e preciso identificar na base Period BUS GPS qual era a posicao, para

aquele determinado onibus e linha, mais proxima do horario em que o usuario validou seu cartao

no mesmo. A partir desta posicao, identifica-se a grade na qual a mesma esta inserida.

Como detalhado no Anexo E, passa-se por 4 tabelas intermediarias ate obter-se a

posicao GPS do veıculo especificado na base de cartoes (atraves dos atributos codlinha,

codveiculo e datautilizacao da base de cartoes). A informacao referente a diferenca de tempo

entre a passagem do cartao no onibus e a emissao da posicao GPS considerada do mesmo

tambem e armazenada na base de cartoes (no atributo timedif ), podendo ser utilizada para

avaliacao do nıvel de confiabilidade da inferencia realizada.

Subentende-se aqui que o passageiro suba no onibus e valide seu cartao. Um possıvel

erro deve ser aceito ja que existem usuarios que podem aguardar na parte da frente do onibus

antes da validacao do cartao (por opcao ou devido ao alto grau de ocupacao do onibus em

questao). No entanto, haja visto o espaco existente nesta parte, e de se esperar que a grande

maioria dos usuarios valide seu cartao logo que embarque no veıculo.

Para um dos servicos telematicos propostos, e preciso identificar o ponto de onibus

mais provavel de embarque do usuario (e nao somente a grade que o inclui). Neste caso, e

necessario um passo adicional buscando associar a posicao GPS identificada com o ponto de

onibus mais proximo pertencente a linha em questao. Novamente, funcionalidades do PostGIS

facilitam bastante esta busca pois ela se resume a identificar dentre os pontos de onibus de uma

lista definida (cujo parametro line da base bus stops table e o mesmo do parametro linha da base

de GPS) aquele que apresenta a menor distancia para a posicao GPS identificada (utilizando a

funcao ST DistanceSphere, por exemplo).

No entanto, nem a base de GPS (Period BUS GPS) nem a base de cartoes

(URBS CARD raw), contem informacao sobre o sentido do onibus naquele instante. Logo,

nem sempre e possıvel definir com precisao qual o ponto exato utilizado.

Resta salientar que, de maneira geral, o ponto de onibus exato no qual o usuario

embarcou nao e essencial nesta abordagem, uma vez que o que se procura e identificar a grade

33

de onde ele embarcou e aquela na qual ele teria desembarcado do onibus.

3.4 ESTIMACAO DO PONTO DE DESEMBARQUE DE CADA USUARIO

Entrada Base de dados contendo a utilizacao dos cartoes detransporte (ja com o ponto de origem definido).

Saıda Base de dados contendo a utilizacao dos cartoes (ja com ainformacao de GPS e o ID da grade de embarque) acrescidada informacao sobre o ID da grade onde estima-se que ousuario desceu do onibus.

Tabela 4: Principais entradas e saıdas da etapa “Estimacao do Ponto de Desembarque de cadausuario”

Conforme mencionado no Capıtulo 2, as hipoteses apresentadas em (ZHAO, 2004)

tem norteado a maior parte dos estudos de criacao de matriz O/D a partir de dados de cartoes e

posicoes GPS dos onibus. A inferencia do ponto/grade de desembarque se baseia nas seguintes

hipoteses:

1. Nao existe nenhum modo de transporte privado (carro, moto, bicicleta etc) entre dois

trechos consecutivos de utilizacao do cartao no dia;

2. A ultima viagem dos usuarios tem por destino final o ponto de partida do dia em questao.

Nesta primeira abordagem, considera-se apenas os casos de utilizacao de ate duas

vezes o mesmo cartao no dia. No caso de exatas duas vezes no dia (o que seria o trajeto mais

regular e simples possıvel), considera-se que: o usuario utiliza o cartao uma primeira vez no

dia, descendo na grade onde ele utilizara o cartao pela segunda vez. Neste mesmo local, ele

deve pegar um onibus para retornar ao ponto de partida.

Porem, em muitas situacoes um dado cartao e validado uma unica vez no dia.

Subentende-se que nestes casos, o usuario deva contar com algum outro meio de transporte

para retornar ao seu ponto de origem, por exemplo. Para estes casos de uma unica utilizacao no

dia, a seguinte estrategia foi adotada (ver 1):

• Procura-se, dentre os outros dias disponıveis (mantendo a distincao entre dias da semana

e finais de semana), se aquele usuario teria um cenario de duas passagens exatas do cartao

no dia, onde ele teria partido de alguma das 8 grades adjacentes a grade em questao. Caso

positivo, considera-se que no dia onde ha apenas uma passagem, ele estaria se dirigindo

para a mesma localidade que foi no dia onde registrou duas utilizacoes diarias;

34

• Caso este cenario nao ocorra, considera-se como destino o ponto para onde a maior parte

dos outros usuarios se dirigiram naquele dia e faixa horaria.

Algorithm 1 Estrategia para unica utilizacao diaria1: GradeOrigem← grade ID da utilizacao unica naquele dia (grade de partida);2: if Existe algum caso de duas utilizacoes diarias do mesmo cartao? then3: if Posicao de partida igual GradeOrigem OU Posicao de partida adjacente a

GradeOrigem then4: GradeDestino←Mesmo destino da viagem identificada5: elseGradeDestino← Top grade ID destino dentre todos os usuarios (no perıodo)6: elseGradeDestino← Top grade ID destino dentre todos os usuarios (no perıodo)

O Anexo F apresenta o codigo SQL utilizado para realizar esta etapa da metodologia.

No cenario contendo uma unica utilizacao, nao e feito nenhuma distincao caso haja mais de uma

viagem do mesmo usuario partindo de um ponto proximo mas indo para destinos diferentes.

O primeiro deles sera considerado como o destino do dia onde apenas uma utilizacao foi

contabilizada. Melhorar este ponto exigiria um esforco computacional consideravel para um

ganho em precisao questionavel.

Observa-se, novamente, que em nenhum momento foi considerada a questao do trajeto

exato tomado pelo usuario. Logo, caso ele tenha feito algum tipo de transferencia em areas

onde nao e necessario revalidar o cartao (como em estacoes tubos ou terminais) tal manobra

nao sera evidenciada por esta abordagem.

Para os casos de duas utilizacoes diarias, a metodologia seguida e a seguinte:

1. Seja o exemplo real do cartao 0001659901, que pegou a linha 212 no perıodo da manha

e validou seu cartao pela segunda vez na linha 685 no inıcio da tarde do mesmo dia (ver

Figura 5).

Figura 5: Exemplo de trajeto considerado como exemplo: O cartao 0001659901 utiliza duas vezeso cartao no dia, uma pela manha e outra no inıcio da tarde, em dois onibus e linhas diferentes.

2. Cruzando a informacao da posicao GPS do onibus BN406 realizando a linha 212 por

volta das 05:50, pode-se inferir o ponto de partida da primeira viagem deste usuario. Da

mesma forma, cruzando-se a informacao da posicao GPS do onibus HA612 realizando a

linha 685 por volta das 16:18, pode-se inferir o ponto de partida deste usuario na viagem

de volta. (ver Figura 6)

35

Figura 6: Posicoes onde o cartao foi validado nos dois momentos do dia.

3. A partir daı, determina-se diretamente em qual das grades cada uma das posicoes faz

parte (ver Figura 7)

Figura 7: Grades contendo cada uma das posicoes identificadas.

4. Por fim, assume-se que a viagem de ida tem por destino a grade definida como o ponto de

partida da viagem de volta, e vice-versa. Deste modo, completa-se a base de dados com os

pontos de origem e destino provavel de cada viagem para os cartoes utilizados duas vezes

36

ao dia. Novamente, a hipotese adotada aqui nao leva em consideracao o trajeto utilizado

pelo usuario. A tıtulo de exemplo, a Figura 8 apresenta quais teriam sido possivelmente

os trajetos deste usuario no dia do exemplo em questao.

Figura 8: A que poderia se assemelhar o trajeto utilizado por este usuario no dia em questao.(fonte mapa: GoogleMaps)

3.5 CRIACAO E VISUALIZACAO DA MATRIZ DE ORIGEM-DESTINO

Entrada Base de dados contendo a utilizacao dos cartoes (ja com ainformacao de GPS e o ID da grade de embarque) acrescidada informacao sobre o ID da grade onde se estima que ousuario desceu do onibus.

Saıda Visualizacao do resultado obtido atraves de diversas formas:mapas de calor sobre o mapa da cidade, grafos e tabelascontendo as ligacoes mais utilizadas pelos usuarios.

Tabela 5: Principais entradas e saıdas da etapa “Criacao e Visualizacao da Matriz de Origem-Destino”

A partir da base SQL que ja representa a matriz origem-destino referentes aos

dias observados neste estudo, a primeira abordagem para verificar os resultados dos passos

precedentes e apresentar esta informacao sob o formato de grafos. Para isto, exportou-se a base

produzida em SQL sob forma de um arquivo tipo texto, para posterior importacao e trabalho

37

em R. Aqui, a matriz foi modelada sob forma de grafo, servindo-se de uma biblioteca em R

dedicada para este fim chamada igraph.

Neste grafo, os nos representam as grades, cada aresta indica a ligacao existente entre

estas duas regioes e o peso de cada uma representa o volume de utilizacao daquela ligacao pelos

usuarios.

Do grafo obtido, fica simples a criacao de uma lista contendo as ligacoes mais

utilizadas pelos usuarios nos dias em questao. Tal lista sera a fonte essencial para a

implementacao de um dos servicos telematicos, conforme sera abordado na Secao 3.6.

Com este mesmo arquivo tipo texto, uma ferramenta gratuita chamada GEPHI4

tambem foi avaliada. Apesar de bastante poderosa e flexıvel, contendo diversos adendos

para estatısticas e visualizacoes de grafos, tal ferramenta ainda apresenta um alto grau de

instabilidade, razao pela qual nao foi muito mais explorada ao longo deste trabalho, tendo

sida utilizada apenas para produzir algumas poucas imagens ilustrativas, nao justificando sua

presenca dentre as ferramentas apresentadas no Capıtulo 2.

Em virtude das dimensoes do grafo (com os nos representando as cerca quatro mil

grades), a visualizacao integral do mesmo fica bastante prejudicada (o que sera discutido no

Capıtulo 4). Logo, tentar apresentar simplesmente todas as ligacoes entre grades nao e nada

legıvel. Portanto, concluiu-se que a melhor solucao passe pela apresentacao de alguns aspectos

especıficos da rede sob forma de grafos ou entao integralmente via os chamados “mapa de

calor” sobrepostos ao mapa da cidade.

Durante este trabalho, buscou-se criar tais mapas das mais diversas maneiras:

• Atraves de bibliotecas dedicadas em R (ggmap, por exemplo), cuja vantagem e ser

bastante simples, nao necessitando de muitas linhas de codigo para produzir algo

visualmente interessante. No entanto, a imagem produzida e estatica, nao sendo

possıvel trabalhar dinamicamente, reconstruindo a imagem a cada aproximacao desejada

(aumentando o nıvel de detalhe apresentado, por exemplo);

• Para buscar maior flexibilidade quanto a isso, experimentou-se utilizar os APIs

disponibilizados pelo Google, atraves da utilizacao direta do GoogleMaps e de algumas

poucas linhas em javascript5;

Em uma primeira abordagem, um arquivo .html era produzido diretamente pelo script

em R, sendo aberto em um navegador de internet. Esta solucao era visualmente bastante4https://gephi.org/ (visitado em 02/07/2017)5https://developers.google.com/maps/documentation/javascript/ (visitado em 02/07/2017).

38

atraente, porem, pecava pelo pouco controle sobre os mapas de calor produzidos nao

sendo possıvel, de maneira facil, obter a legenda das cores, muito menos os algoritmos

utilizados para sua producao;

• A solucao encontrada, combinando simplicidade, controle e potencia, foi a utilizacao

direta do QGIS para a producao de tais visualizacoes.

Como mencionado anteriormente, e possıvel integrar o QGIS diretamente a base

de dados do PostgreSQL. Todos os elementos de tipo geograficos (oferecidos pela extensao

PostGIS) sao passıveis de serem apresentados sobre o mapa da cidade. O QGIS tambem

possibilita a criacao de mapas de calor atraves dos chamados Mapas de kernel.

O termo Mapa de kernel, faz referencia a um metodo estatıstico de estimacao de curvas

de densidade. Ele e bastante util para se ter uma visao geral da intensidade do processo em

estudo sobre todas as regioes do mapa. No caso deste trabalho, o processo se trata dos pontos

de subida e descida dos usuarios do transporte publico de Curitiba.

Basicamente, no ponto central de cada grade (ou eventualmente na geolocalizacao

de cada ponto de onibus) aplica-se uma funcao especıfica (a funcao kernel). Esta funcao

contabiliza seu valor de maximo neste ponto, conforme a quantidade de subidas ou descidas

inferidas ali. Ela entao decresce, seguindo a definicao da propria funcao de kernel, conforme

nos afastamos do ponto central da grade, sobrepondo seus valores as funcoes aplicadas nos

pontos centrais das grades adjacentes.

O QGIS possui algumas opcoes de configuracao para a criacao de tais mapas. A Figura

9 apresenta a maneira como este foi configurado para este trabalho6.

Assim, os mapas de calor foram gerados a partir da consideracao do mapeamento de

origem-destino baseado nas grades quadradas de 500 metros de lado. Como o ponto central

de cada grade encontra-se a 500 metros de distancia de seus adjacentes, o valor de raio de 750

metros produziu mapas de kernel bastante suaves e visualmente atraentes.

Naturalmente, diversas outras formas de visualizacao dos resultados sao possıveis. Tal

topico faz parte dos trabalhos futuros vislumbrados e elencados no final do Capıtulo 5.

39

Figura 9: Configuracoes utilizadas no QGIS para producao de mapas de calor.

Entrada Base de dados contendo a matriz origem-destino (bemcomo sua representacao sob forma de grafo). Base coma informacao de posicao GPS de todos os onibus nos diasobservados e com o trajeto de todas as linhas existentes.

Saıda

• Identificacao de ligacoes mais utilizadas semcobertura direta por nenhuma linha existente;

• Nıvel de utilizacao dos onibus por faixa horaria;

• Total de quilometragem percorrida por cada veıculoda rede;

• Identificacao das velocidades realizadas por cadaveıculo, bem como das velocidades medias das linhaspor horario e regiao;

• Identificacao de veıculos fora da rota prevista pelalinha que deveria realizar.

Tabela 6: Principais entradas e saıdas da etapa “Oferta de pacote de Servicos Telematicos”

3.6 OFERTA DE PACOTE DE SERVICOS TELEMATICOS

Propoe-se aqui um conjunto de novas informacoes derivadas dos dados brutos

capturados (informacao GPS e itinerario das linhas) e da matriz origem-destino produzida.6Um excelente tutorial sobre a maneira de criar mapas de calor no QGIS pode ser encontrado neste site:

http://www.qgistutorials.com/en/docs/creating heatmaps.html (visitado em 02/07/2017)

40

Estas novas informacoes descrevem de certa forma alguns aspectos operacionais e/ou

estrategicos dos onibus e da propria rede de transporte municipal.

Pode-se encarar este conjunto de subprodutos da analise dos dados como uma pacote

de servicos telematicos (ver Figura 10) de grande valia para as empresas que possuem veıculos

no sistema de transporte, para a URBS na sua gestao da rede ou ate mesmo para os usuarios do

sistema.

Figura 10: Servicos telematicos apresentados como prova de conceito para explorar e transformaros dados disponıveis em servicos de valor agregado para todos os atores interagindo com arede de transporte publico. Da esquerda pra direita: Ligacoes importantes sem linha diretadedicada, Estimacao do nıvel de utilizacao dos onibus, Alerta de saıda da rota prevista, Alertade quilometragem e Alerta de excesso de velocidade.

Naturalmente, se alem de suas posicoes GPS e utilizacoes dos cartoes fosse possıvel

recuperar outras informacoes adicionais sobre os sistemas de cada onibus (como nıvel de

combustıvel, carga total, torque do motor, avarias em geral, ...) ou entao ter a possibilidade

de enviar comandos aos veıculos a partir de sistemas externos, seria possıvel propor uma gama

bem maior de servicos telematicos.

No entanto, e bastante valido mostrar que apenas com estas poucas informacoes ja

disponıveis, pode-se oferecer servicos propiciando recursos avancados para monitoramento e

controle das frotas dos veıculos que integram a rede.

3.6.1 LIGACOES IMPORTANTES SEM LINHA DIRETA DEDICADA

Assume-se aqui que as ligacoes mais utilizadas pelos usuarios devam ser cobertas por

linhas diretas conectando estes dois pontos. Naturalmente, esta nao precisa ser necessariamente

a melhor forma de ligar duas localidades com bastante demanda, mas a ausencia de tal ligacao

direta deveria, no mınimo, ser alvo de algum estudo mais aprofundado.

A partir da matriz origem-destino (principalmente sob forma de grafo) identifica-se os

principais pares de origem-destino utilizados. Naturalmente, tais pares variam em funcao da

hora do dia e do dia da semana. No entanto, inicialmente diferenciou-se apenas o fato de ser

dia da semana ou finais de semana.

O grafo representando a matriz origem-destino foi construıdo em R, a partir de um

arquivo csv exportado do banco de dados contendo as informacoes de grades de origem e de

41

destino de cada usuario. O Anexo G contem o codigo em R utilizado para a criacao do grafo.

As maiores ligacoes identificadas (nos com maior grau) sao exportadas do R para alimentarem

uma nova base de dados geo-referenciada (chamada TopOD grid table, como pode ser visto no

Anexo H).

Cada uma das linhas existentes (detalhadas na base line shape) tambem sao tratadas

como objetos geograficos. Utilizando novamente a funcao ST Contains no PostGIS, identifica-

se se as grades de origem e de destino em questao seriam cobertas ao mesmo tempo por uma

mesma linha.

Para os pares de grades que passarem por este primeiro filtro, indicando nao serem

cobertos diretamente por nenhuma linha de onibus existente, faz se uma nova busca, dessa vez

considerando todas as 8 grades adjacentes (ver Figura 11) a cada uma das grades de origem e

de destino. Busca-se encontrar alguma linha de onibus atual unindo diretamente alguma destas

16 grades (ver 2). Esta etapa e realizada em Python, cujo script e apresentado no Anexo I.

Figura 11: Exemplo de grades consideradas como ponto de origem (o mesmo ocorrendo na gradede destino) na busca de uma linha atual que conecte diretamente as grades de origem e destino (oualguma de suas grades adjacentes).

3.6.2 ESTIMACAO DO NIVEL DE UTILIZACAO DOS ONIBUS

Como explicado em 3.3, este servico necessita de uma estrategia ligeiramente diferente

da apresentada com relacao ao mapeamento de origem e destino sobre as grades. No contexto

deste servico, uma granularidade maior se faz necessaria (no nıvel do ponto de onibus, mais

precisamente), tanto para o embarque como para o desembarque.

42

Algorithm 2 Confirmacao de ausencia de linhas diretas1: CandidatoGradeOrigem← grade ID de partida com alta afluencia de usuarios;2: CandidatoGradeDestino← grade ID de chegada com alta afluencia de usuarios;3:4: if Nao existe nenhuma linha ligando diretamente CandidatoGradeOrigem a

CandidatoGradeDestino ? then5: if Ja existe algum linha ligando as grades adjacentes de CandidatoGradeOrigem as

grades adjacentes de CandidatoGradeDestino ? then6: CandidatoGradeOrigem e CandidatoGradeDestino NAO sao consideradas como

ligacao sem cobertura direta7: elseODSemCoberturaDireta←CandidatoGradeOrigem e CandidatoGradeDestino8: elseCandidatoGradeOrigem e CandidatoGradeDestino NAO sao consideradas como

ligacao sem cobertura direta

O Algoritmo 3 apresenta de forma simplificada o procedimento seguido. Para maiores

detalhes, ver os Anexos J e K contendo os scripts SQL e Python utilizados para implementar

este servico.

Uma vez identificado a posicao GPS de passagem do cartao, identifica-se qual e o

ponto de onibus mais proximo cobrindo a linha em questao. Este sera o ponto de onibus

considerado para o embarque. Uma vez identificado o ponto de onibus da volta, define-se

onde o usuario deve ter descido na viagem de ida.

Uma vez definido o ponto de descida do usuario, e possıvel estimar o horario que

o mesmo desceu do onibus. Para isto, encontra-se o mınimo local dentre todas as diferencas

medidas entre a posicao do onibus utilizado pelo usuario e a localizacao do ponto onde se estima

que ele desceu.

Faz-se necessario encontrar um mınimo local, pois esta diferenca depende do momento

em que o onibus emitiu sua posicao. Logo, e possıvel que ao longo do dia, exista um caso onde

a posicao GPS do onibus teria sido enviada no momento onde ele estaria parado exatamente

no ponto em questao. Porem, isto nao quer dizer que o passageiro ainda estivesse no veıculo

naquele trajeto do dia.

Uma vez feito isso, pode-se estimar quantos passageiros subiram e desceram em cada

onibus para cada faixa horaria. Idealmente, seria possıvel descer em um grau de granularidade

bem baixo, na casa do minuto por exemplo. No entanto, por questoes de simplicidade e

validacao do conceito, utilizou-se como perıodo padrao 1 hora.

Para este servico telematico, o conhecimento exato do trajeto seguido pelo usuario se

faz necessario. Para simplificar a tarefa, demonstrando a factibilidade do conceito, consideram-

se usuarios com duas utilizacoes diarias cujas viagens de ida e volta se dao na mesma linha.

43

Este caso e bastante comum em linhas menores, como e o caso da linha 461 demonstrada no

Capıtulo 4.

Algorithm 3 Estimando nıvel de utilizacao dos onibus1: . Apenas para os casos de duas utilizacoes diarias.2: bs1← Ponto de onibus de embarque da viagem de ida;3: bs3← Ponto de onibus de embarque da viagem de volta;4: bs2← Ponto de onibus provavel de desembarque da viagem de ida (proximo a bs3);5: bs4← Ponto de onibus provavel de desembarque da viagem de volta (proximo a bs1);6:7:8: for Todas as posicoes GPS do onibus da viagem de ida do9: Calcular o valor da distancia entre GPS e a posicao de bs2

10: MinimaDistanciaIda← menor valor calculado11: . Considerar condicoes coerentes com o trajeto pois, o onibus deve passar proximo a

bs2 diversas vezes no dia.12:13: for Todas as posicoes GPS do onibus da viagem de volta do14: Calcular o valor da distancia entre GPS e a posicao de bs415: MinimaDistanciaVolta← menor valor calculado16: . Considerar condicoes coerentes com o trajeto pois, o onibus deve passar proximo a

bs4 diversas vezes no dia.17:18: PermanenciaUsuarioIda← Hora(MinimaDistanciaIda)−Hora(embarqueida)19: PermanenciaUsuarioVolta← Hora(MinimaDistanciaVolta)−Hora(embarquevolta)20:21: . Sintetizar informacao para todas as viagens e usuarios de cada dia22: ContagemFinal←Total de usuarios que subiram e desceram de um mesmo onibus por hora

3.6.3 ALERTA DE SAIDA DA ROTA PREVISTA

Sobrepondo as posicoes GPS emitidas pelos onibus com a linha que este deveria estar

executando (simples de ser realizada atraves do QGIS), e imediata a identificacao de momentos

onde o veıculo estaria fora do roteiro previsto.

Tal fato poderia gerar um alerta automatico para o gestor da rede, da linha ou da frota.

No caso deste trabalho, sob a forma de prova de conceito, mostrou-se tal ponto atraves de um

pos-processamento dos dados.

Este tipo de servico ou de prestacao e vendido no mercado nacional de veıculos leves

e pesados sob o nome de “cerca eletronica”. Ele e bastante comum nas ofertas de produtos

comerciais para gestao de frotas.

44

3.6.4 ALERTA DE QUILOMETRAGEM

Como explicado, a cada dois minutos (salvo problemas de comunicacao ou de natureza

tecnica do equipamento) cada veıculo emite suas coordenadas geograficas atuais.

Atraves destes pontos, pode-se calcular a distancia percorrida entre duas emissoes

consecutivas. Neste trabalho, optou-se por calcular esta distancia em linha reta (sem considerar

as distancias no mapa), o chamado “em voo de passaro”. Tratando-se de tao pouco tempo entre

duas informacoes recebidas, espera-se que o veıculo nao tenha rodado grandes distancias (ainda

mais considerando-se se tratar de onibus transportando diversas pessoas e nao um veıculo de

passeio).

Admitindo o conhecimento previo do valor do odometro dos veıculos (quilometragem

total de cada onibus no inıcio do monitoramento), torna-se possıvel a geracao automatica de

alertas individualizados apontando momentos de revisao preventiva ou de algum outro tipo de

manutencao dos onibus.

Este tipo de servico tambem e bastante oferecido pelos atuais sistemas conectados

automotivos disponıveis ao redor do mundo. Naturalmente, estes alertas podem ser mais ou

menos precisos e detalhados em funcao dos dados efetivamente disponıveis. No entanto, todos

encaixam-se no servico telematico comumente conhecido por “alerta de manutencao proativa”.

3.6.5 ALERTA DE EXCESSO DE VELOCIDADE

Do item anterior, pode-se deduzir diretamente a velocidade media de cada veıculo no

perıodo entre duas recepcoes de informacoes de posicao GPS (atraves da simples relacao entre

a distancia percorrida e este intervalo de tempo).

Com isto, o gestor da frota e capaz de receber alertas caso algum de seus motoristas

ultrapasse a velocidade limite definida pela empresa. Ou entao, pode-se associar tambem alertas

caso a velocidade realizada ultrapasse a velocidade da via (necessitando para isto uma outra base

de dados contendo tais informacoes).

Este tipo de servico e comumente conhecido pelo nome de “speed alert” nos sistemas

de veıculos conectados vendidos atualmente no Brasil e no mundo.

Naturalmente, da mesma forma que o servico de cerca eletronica, tal servico tem mais

valor se oferecido de forma a alertar o gestor da frota em tempo-real. Nao foi o caso neste

trabalho, mas esta melhoria, bem como a agregacao e disponibilizacao destes servicos sob uma

forma mais comercial e profissional, constam nas propostas de trabalhos futuros no Capıtulo 5.

45

A Figura 12 sintetiza os passos da metodologia proposta. Ela pode ser considerada um

detalhamento da Figura 2 (seguindo o mesmo codigo de cores).

46

Figura 12: Visao geral detalhada da metodologia proposta.

47

4 EXPERIMENTOS E RESULTADOS

Este capıtulo contem os resultados finais de cada uma das Secoes apresentadas no

Capıtulo 3. Alem disso, cada etapa e acompanhada de discussoes e analises dos resultados.

4.1 OBTENCAO E ARMAZENAMENTO DOS DADOS - RESULTADOS

Como mencionado, este estudo considerou dados dos seguintes dias:

• Dias uteis: 31/10/2016, 03/11/2016, 04/11/2016, 07/11/2016, 08/11/2016, 09/11/2016,

10/11/2016 e 11/11/2016.

• Finais de semana: 29/10/2016, 30/10/2016, 05/11/2016 e 06/11/2016

Grandes volumes de dados foram coletados e armazenados (o arquivo contendo todas

as posicoes GPS para o perıodo de estudo possui cerca de 1 Gb de volume, bastante importante

para um arquivo tipo texto). No entanto, ainda em uma escala capaz de ser tratado e processado

por um computador pessoal. Nao se explorou tecnicas de armazenamento e processamento na

nuvem, tıpicas de problemas necessitando tecnologias mais avancadas de tratamento massivo

de dados. A Tabela 7 apresenta uma sıntese do volume de dados obtidos para o perıodo

considerado.

Algumas incoerencias foram encontradas no levantamento dos dados da Tabela 7,

especialmente no que diz respeito aos dois ultimos elementos: quantidade de linhas e

quantidade de veıculos. Os valores nao sao exatamente os mesmos daqueles obtidos atraves

do web-service getPontosLinhas, da base contendo a informacao de GPS dos onibus e da base

com a utilizacao dos cartoes de transporte. Alem do mais, nenhum destes valores e exatamente o

apresentado nas estatısticas oficiais da URBS (250 linhas de onibus e 1320 veıculos compondo

a frota operante de onibus da cidade1).

1http://www.urbs.curitiba.pr.gov.br/institucional/urbs-em-numeros para maiores informacoes (site visitado em02/07/2017)

48

Posicoes GPS armazenadas 12 457 009 (sendo 79% durante os diasde semana)

Quantidade de pontos de onibus 6 990Utilizacoes de cartoes de transporte 4 104 300 (sendo 85% durante os dias de

semana)Cartoes de transporte distintos observados 344 076Linhas distintas observadas 258 (considerando a base de utilizacao

dos cartoes)Veıculos distintos observados 1 039 (considerando a base de utilizacao

dos cartoes)

Tabela 7: Sıntese da quantidade de dados obtida para o perıodo em questao (29/10/2016 a11/11/2016).

Os dados foram obtidos atraves dos web-services disponibilizados e armazenados em

base de dados. As figuras 13, 14, 15, 16 e 17 ilustram a organizacao destas bases.

Figura 13: Extracao da base de utilizacao dos cartoes. Ela contem essencialmente o numero docartao utilizado, o horario e em que onibus e linha tal utilizacao foi computada.

Figura 14: Extracao da base de pontos de onibus, contendo diversos detalhes sobre o ponto deonibus (como localizacao e tipo), alem de sua localizacao e a linha a qual aquele ponto pertence.

Alem disso, como mostrado na Figura 18 a distribuicao temporal de utilizacao dos

cartoes segue um comportamento esperado para este tipo de sistema em grandes cidades, a

saber, perıodos de pico durante o dia no inıcio da manha e da tarde (hora do rush) e um volume

de utilizacao bem reduzido durante os finais de semana (se comparados com os dias de semana).

49

Figura 15: Extracao da base lines shape, contendo o tracado do itinerario de cada linha de onibusda rede.

Figura 16: Nesta base encontramos todas as posicoes GPS emitidas por cada um dos veıculos dafrota operante no momento do lancamento do web-service.

Figura 17: Pontos tipo tubo ou terminais possuem um codigo especial (“cod urbs” na base deutilizacao dos cartoes). Estes dados foram obtidos atraves de reunioes com a URBS, que engajou-se em integra-los nas atualizacoes dos web-services.

A Figura 19 faz o foco sobre um unico dia, evidenciando as flutuacoes da demanda ao longo do

dia.

A respeito das linhas e veıculos, um outro ponto bastante determinante merece atencao.

A partir da base de cartoes, obtem-se quais seriam os onibus e veıculos mais utilizados pelos

usuarios (ver Figura 20).

Depois de uma serie de hipoteses e indagacoes, observa-se que boa parte dessas linhas

nao se trata de uma “linha padrao”, bem como nenhum destes veıculos refere-se de fato a

algum codigo de um onibus da rede. Como pode ser observado na Figura 21, o codigo dos

veıculos e formado por duas letras e tres algarismos. No caso da Figura 21, o codigo do veıculo

50

Figura 18: Histograma de utilizacao dos cartoes no perıodo estudado.

Figura 19: Histograma de utilizacao dos cartoes no dia 8 de novembro.

seria LE701 e a linha que o mesmo estaria realizando seria a 303 (as linhas sao formadas

majoritariamente por tres caracteres numericos).

Logo, as tres primeiras colunas da Figura 20-a nao sao linhas normais:

• Linha 000: Na base de cartoes tais casos tem por nome da linha a informacao “OPER

S/ LINHA”. Trata-se na verdade da utilizacao do cartao em algum terminal ou ponto

tipo tubo. Nestes casos, a informacao de codveiculo indica qual o terminal ou tubo em

51

(a) (b)

Figura 20: Linhas e veıculos mais utilizados: (a) As 15 linhas mais utilizadas conforme indicadana base de utilizacao de cartoes; (b) Os 15 veıculos mais utilizados conforme indicado na base deutilizacao de cartoes.

Figura 21: Exemplo de um onibus tıpico da rede.

questao.

• Linha OPC: Em alguns casos, alguns onibus precisam integrar a rede para cobrir

momentos de pico de atividade. Tais onibus nao possuem necessariamente uma linha

definida e sao instanciados como “OPERACAO CONTINGENCIA”. Por razoes ainda

nao totalmente esclarecidas, estes onibus nao possuem analogo na base de posicoes GPS

dos onibus;

• Linha ARA: Faz referencia aos onibus oriundos do municıpio de Araucaria, vizinho

a Curitiba. No entanto, como nao sao foco deste trabalho estas instancias foram

desprezadas.

Apos estes esclarecimentos, os supostos “Top 15 veıculos” sao apresentados na Tabela

8. Como explicado na Secao 3.1, trata-se da identificacao de validadores de cartoes presentes

em terminais ou tubos. Este codigo sendo o chamado “cod urbs” da Figura 17.

52

03014 Terminal Portao03046 Estacao praca Eufrasio Correia03009 Terminal Portao09070 Estacao Carlos Gomes00042 Estacao UTFPR00048 Estacao praca Carlos Gomes03019 Terminal Pinheirinho06024 Tubo Jardim das Americas09005 Tubo Terminal Caiua03050 Estacao central (correio)03043 Estacao praca Oswaldo Cruz03001 Terminal Pinheirinho03042 Estacao praca Oswaldo Cruz06061 Estacao praca Eufrasio Correia00009 Terminal Hauer

Tabela 8: Associacao entre cod urbs e os quinze terminais e tubos mais utilizados.

4.2 LIMPEZA E PREPARACAO DOS DADOS - RESULTADOS

A Figura 22 apresenta o que restou apos cada fase de limpeza dos dados.

• Passo 1 - Total inicial: Valor inicial de utilizacao de cartoes (o mesmo valor apresentado

na Tabela 7);

• Passo 2 - Remocao de ARA, OPC e MCC: As instancias de cartoes validadas com este

indicador de “linha” nao pode ser utilizada pois nao e possıvel fazer a associacao com

a base de GPS dos onibus (nao se sabe exatamente que onibus/linha esta utilizacao do

cartao representaria). Apos este passo, quase 6% das transacoes foram desprezadas;

• Passo 3 - Remocao de COD URBS desconhecidos: Alguns codigos passados no campo

“codveiculo” da base de utilizacao dos cartoes (mais precisamente 31 codigos) nao foram

fornecidos pela URBS ate a redacao deste trabalho. Portanto, tais transacoes nao puderam

ser utilizadas pois nao e possıvel identificar onde (tubos ou terminais) tais cartoes teriam

sido utilizados;

• Passo 4 - Selecao de 1 ou 2 utilizacoes ao dia : Conforme mostrado na Figura 23,

inicialmente a base de dados de utilizacao de cartoes apresenta uma maioria de casos

de utilizacao uma ou duas vezes por dia de um mesmo cartao (cerca de 60% do total

inicial). Ao mesmo tempo, percebe-se tambem algumas poucas aberracoes, onde um

mesmo cartao chega a ser utilizado 14 vezes em um mesmo dia.

53

Figura 22: Quantidade de dados de utilizacao dos cartoes de transporte resultante dos processosde limpeza dos dados. Apos os cinco passos de preparacao, consideramos no final cerca de 60%dos dados inicialmente capturados.

Dado esta ampla maioria, conforme explicado na Secao 3.2, por questao de simplicidade

decidiu-se considerar em um primeiro momento apenas os casos de uma ou duas

utilizacoes de um mesmo cartao por dia.

Observa-se na Figura 23 que os valores finais considerados (barras vermelhas) apontam

um pouco mais de casos de uma unica utilizacao por dia. Isso se deve ao fato de

algumas passagens consideradas como sendo duas vezes ao dia, na verdade tratava-se

de utilizacoes seguidas (em menos de cinco minutos uma da outra) de um mesmo cartao.

Neste caso, tais situacoes foram classificadas como sendo uma unica utilizacao ao dia;

• Passo 5 - Remocao dos onibus sem informacao GPS: Por razoes ainda nao muito claras,

alguns veıculos realizando certas linhas nao emitiram suas informacoes GPS conforme

esperado (foi observado um total de 121 pares linha/veiculo nesta situacao). Imagina-se

que isso possa se dever a algum problema no equipamento ou a nao ativacao do sistema

pelo motorista. A URBS comentou sobre a possibilidade de oferecer uma outra base, com

o acumulado das posicoes GPS de todos os veıculos nas 48 horas precedentes. Segundo

eles, estes valores faltantes poderiam estar presentes ali. No entanto, tal base nao foi

disponibilizada a tempo para a redacao deste trabalho.

Conforme explicado anteriormente, o foco neste trabalho nao esta na definicao exata do

ponto de onibus, mas sim na grade onde os usuarios subiram e desceram dos onibus. Portanto,

a base de pontos de onibus foi atualizada indicando para cada ponto qual seria o id da grade

54

Figura 23: Quantidade de utilizacao de um mesmo cartao em um mesmo dia. Observa-se umagrande predominancia de uma ou duas utilizacoes por dia (quase 70% dos dados iniciais). Asbarras em azul representam os valores brutos iniciais, enquanto que as vermelhas indicam osdados considerados apos a etapa de limpeza dos dados.

na qual ele estaria inserido. A Figura 24 mostra o exemplo da grade de id “1566” que agrega

em seu interior 26 pontos de onibus diferentes. Este fato simplifica bastante a definicao de

localizacao de origem ou destino, absorvendo eventuais erros de estimacao por diversas razoes.

Apesar da criacao de cerca de quatro mil grades, apenas 1439 ja foram suficientes para

cobrir todos os pontos de onibus disponıveis na cidade. Portanto, simplifica-se radicalmente a

tarefa de definir origem-destino passando de uma possıvel combinacao entre os 6990 pontos de

onibus para uma bem menor combinando as 1439 grades que os contem.

4.3 ASSOCIACAO DOS DADOS DE GPS AS INFORMACOES DE UTILIZACAO DOSCARTOES - RESULTADOS

Um resumo sobre a dispersao e valores medios da diferenca de tempo entre a

informacao GPS dos onibus e a informacao de utilizacao dos cartoes de transporte e apresentado

na Tabela 9. Observa-se que o dado referente ao terceiro quartil (correspondendo a 75% da

amostra total) possui um valor bastante baixo (52 segundos entre o momento da informacao do

GPS e a passagem do cartao pelo usuario).

O valor de maximo indicaria algum eventual problema encontrado nesta associacao.

Isto deve-se essencialmente aos ja comentados problemas de indisponibilidade de informacoes

de GPS. No entanto, estes valores atıpicos chegam a apenas 0,8% da amostra total.

55

Figura 24: O quadrado amarelo representa a grade de ID “1566”, todos os pontos internos aesta grade, representados pelos pontos vermelhos (26 no total), foram classificados como sendointegrantes desta grade.

Min. 1◦ Quartil Mediana Media 3◦ Quartil Maximo00:00:00 00:00:19 00:00:34 00:03:21 00:00:52 17:57:44

Tabela 9: Dispersao no intervalo de tempo entre a informacao sobre a posicao GPS considerada eo momento de validacao do cartao de transporte no mesmo.

A maneira como esta etapa foi implementada merece ser revista para trabalhos futuros.

A utilizacao de 4 operacoes de join (ver Anexo E) entre bases de dados bastante volumosas e

computacionalmente bastante custosa.

4.4 ESTIMACAO DO PONTO DE DESEMBARQUE DE CADA USUARIO -RESULTADOS

Para o caso de uma unica utilizacao diaria, cerca de 35% das instancias puderam

ser mapeadas a alguma outra utilizacao do mesmo cartao sendo utilizado duas vezes ao dia

(partindo da mesma grade ou de alguma das 8 grades adjacentes). Os cerca de 65% dos casos

restantes tiveram os destinos mapeados para onde a maioria dos outros usuarios se dirigia na

faixa horaria da utilizacao do cartao.

Este ponto e de extrema importancia pois ele influencia fortemente as conclusoes do

servico telematico sobre a cobertura atual das linhas. Isto porque a matriz O/D acaba por

supervalorizar regioes de destino em funcao desses 65% de usuarios que nao sao mapeados

56

de acordo com seu historico de viagens.

Espera-se que este valor diminua caso um perıodo maior de observacao seja

considerado.

4.5 CRIACAO E VISUALIZACAO DA MATRIZ DE ORIGEM-DESTINO -RESULTADOS

Neste ponto, as informacoes de origem-destino dos usuarios je estao disponıveis na

base SQL. Logo, o passo chave nesta etapa esta na apresentacao da mesma, sob os diversos

formatos possıveis, todos com vantagens e desvantagens.

Em uma primeira abordagem, tratou-se de transformar as informacoes presentes na

base SQL sob o formato de grafos. Como explicado anteriormente, isto foi realizado utilizando

uma biblioteca especıfica em R.

O formato de grafo foi bastante util para identificar facilmente as ligacoes mais

importantes na rede (basicamente envolvendo os nos do grafo com maior grau perante os

demais). No entanto, no que tange a visualizacao dos resultados, o formato de grafo nao e

muito amigavel em uma primeira analise, conforme mostrado na Figura 25.

(a) (b)

Figura 25: Tentativas frustradas de visualizacao do grafo completo utilizando um algoritmo dedistribuicao geoespacial (a), que leva em conta as coordenadas geograficas dos nos para organiza-los espacialmente. Outros algoritmos de organizacao do grafo tambem foram utilizados (b), noentanto, devido ao grande volume de informacao, nenhum apresentou um resultado satisfatoriopara exploracao visual.

A visualizacao do grafo com todas as interconexoes da matriz origem-destino revelou-

se de pouca valia. Assim, optou-se por uma visualizacao parcial das relacoes de origem destino.

A Figura 26 apresenta tres possıveis formas de mostrar as mil ligacoes mais volumosas da matriz

57

origem-destino final.

(a) (b) (c)

Figura 26: Tres tentativas de visualizacao das mil ligacoes mais importantes da matriz origem-destino obtida: (a) e (b) Utilizando algoritmos que buscam equalizar o tamanho das arestasevitando ao maximo a superposicao das mesma (conhecidos por force-directed layout). (c)Utilizando um algoritmo que leva em conta a posicao geografica dos nos ao desenhar o grafo(conhecido por geolayout).

O resultado foi visualmente bem mais interessante, abrindo vertentes para futuros

trabalhos que busquem explorar diversas caracterısticas da rede e da matriz origem-destino

atraves de conceitos de grafos (como discutido no Capıtulo 5).

Uma outra alternativa de apelo visual interessante passa pela apresentacao da

informacao contida na matriz origem-destino atraves da aplicacao dos chamados mapa de calor

sobre o mapa da cidade. Para tanto, foram feitas duas abordagens. A primeira utilizando o R e

a segunda trabalhando com os APIs do GoogleMaps. A Figura 27 mostra os resultados obtidos

com as duas abordagens.

Utilizou-se tambem o QGIS para a geracao de mapas de calor atraves da ferramenta

“mapa de calor” do software.

As figuras 28 e 29 apresentam os resultados considerando a matriz origem-destino para

todos os dias de semana e dias de finais de semana, respectivamente.

Observa-se que os locais de maior afluencia sao bastante semelhantes, concentrando-se

essencialmente nos principais eixos viarios da cidade, no centro e no entorno dos terminais.

Com o intuito de equalizar e analisar um pouco mais detalhadamente os principais

centros de chegada e partida de passageiros, a Figura 30 apresenta uma sobreposicao das regioes

de partida e chegada mais importantes (cujo valor no mapa de calor ultrapassa o valor de 50002).

2Este valor foi escolhido pois representam regioes de bastante afluencia, onde a funcao de kernel aponta alta

58

(a) (b)

Figura 27: (a) Utilizacao dos APIs para javascript do GoogleMaps contidos em um arquivo .html,visualizando-o na sequencia em um navegador de internet. ; (b) Exemplo de resultado obtidoatraves da biblioteca ggmap do R.

(a) (b)

Figura 28: Concentracao dos principais pontos de origem e destino nos dias de semana: (a)Principais regioes de origem dos passageiros nos dias de semana; (b) Principais regioes de destinodos passageiros nos dias de semana.

densidade de pessoas embarcando ou desembarcando no decorrer do perıodo observado.

59

(a) (b)

Figura 29: Concentracao dos principais pontos de origem e destino nos finais de semana: (a)Principais regioes de origem dos passageiros aos finais de semana; (b) Principais regioes de destinodos passageiros aos finais de semana.

Nesta figura pode-se observar tambem que os principais pontos de partida de passageiros

tambem sao geralmente focos de grande absorcao de usuarios.

Uma outra forma de explorar o resultado obtido e considerar um ponto de interesse

em particular, como apresenta a Figura 31. Neste exemplo objetiva-se saber de onde vem

os passageiros que desembarcam no entorno do Terminal Centenario ou no Centro Municipal

de Urgencias Medicas do Cajuru (ambos situados em uma mesma grade, representada pelo

quadrado rosa na Figura 31). Claramente, a maior parte dos usuarios vem de regioes proximas

dali, do centro ou da zona oeste da cidade. No entanto, nao parece haver muito fluxo de pessoas

da regiao sudoeste da cidade, por exemplo.

Todos os mapas e grafos aqui apresentados consideram o total de observacoes

coletadas. No entanto, seria naturalmente possıvel filtra-los por faixas horarias especıficas

tambem, dependendo essencialmente do objetivo da analise em curso.

Vale ressaltar que os valores apresentados nos mapas de calor devem ser tratados com

cuidado. Isto porque durante toda a analise considerou-se apenas uma parcela dos usuarios do

transporte que pagam suas tarifas com o cartao de transporte (e apenas aqueles com uma ou

duas utilizacoes diarias). Logo, a fim de obter uma real estimativa da quantidade de usuarios de

60

(a) (b)

Figura 30: Para ambos os graficos, as regioes em verde representam os pontos de desembarquee as de vermelho os de embarque: (a) Considerando todos os dias de semana observados; (b)Considerando todos os dias de finais de semana observados.

Figura 31: Outra forma interessante de explorar a matriz origem-destino obtida seria filtra-lapor algum ponto de interesse, neste caso, procura-se evidenciar de onde vem os passageiros quedesembarcam na regiao do Terminal Centenario ou no Centro Municipal de Urgencias Medicasdo Cajuru, localizados na mesma grade (representada pelo quadrado violeta na figura).

61

fato embarcando ou desembarcando nas mais variadas regioes da cidade, seria preciso aplicar

algum fator de escala nos valores apresentados aqui. Este fator pode ser estimado a partir da

proporcao de usuarios que usam o cartao no sistema de transporte (Secao 1.1) ou utilizar algum

outro estudo externo para abalizar os dados medidos aqui (como a pesquisa manual de Origem-

Destino conduzida neste momento pela prefeitura).

4.6 OFERTA DE PACOTE DE SERVICOS TELEMATICOS - RESULTADOS

Alem das informacoes disponibilizadas visualmente pela matriz origem-destino,

muitas outras funcionalidades podem ser oferecidas atraves da analise da propria matriz e/ou

dos dados de base disponibilizados.

Atraves da analise direta do grafo da Figura 32, foram identificadas as 50 maiores

ligacoes entre as regioes da cidade sem cobertura direta por alguma linha existente. Dentre estas

50 maiores, aquela que possui maior afluencia de usuarios e a ligacao entre a Praca Tiradentes

(no centro de Curitiba) com o Terminal Sıtio Cercado (no sul da cidade), ver Figura 33-a. De

fato, a titulo de exemplo, buscando no Google Maps as alternativas que interconectem estes dois

pontos por meio de transporte coletivo, nao existe nenhuma opcao direta, conforme mostrado

na Figura 33-b.

Figura 32: As cinquenta maiores ligacoes origem-destino observadas sem cobertura direta poralguma linha ja existente.

62

(a) (b)

Figura 33: (a) Ligacao entre Praca Tiradentes (quadrado amarelo) e o Terminal Sıtio Cercado(quadrado verde), um possıvel eixo bastante utilizado pelos usuarios sem cobertura direta pornenhuma linha atual; (b) Exemplo de resposta no Google Maps para um trajeto entre estes doispontos utilizando transporte publico (nenhuma proposta direta de conexao com uma linha diretae apresentada).

Alem do mais, durante um seminario realizado nas instalacoes da URBS no final de

maio de 2017, a URBS confirmou que exatamente esta ligacao estaria sendo o foco de obras

para melhoria de evolucao da rede. Logo, as conclusoes obtidas neste trabalho sugerem uma

consonancia com os estudos internos da URBS.

De fato, as ligacoes mais utilizadas pelos usuarios possuem alguma ligacao direta entre

elas atraves de linhas ja existentes. Isto evidencia uma boa cobertura e organizacao da rede

atual de onibus da cidade comparada a necessidade de mobilidade dos usuarios. Novamente,

vale ressaltar que possuir uma linha direta ligando dois pontos nem sempre e a melhor solucao

do ponto de vista tempo ou distancia a ser percorrida. No entanto, nao deixa de ser um ponto

de alerta interessante para ser analisado com maior profundidade.

Alem da constatacao sobre a coerencia e cobertura da rede atual frente a real demanda

dos usuarios, outro servico conectado interessante seria a estimativa de ocupacao dos onibus,

atraves da analise dos dados obtidos com a construcao da matriz origem-destino.

A Figura 34 mostra o exemplo desta proposta obtido atraves da analise da linha 461.

Esta linha (Santa Barbara-Praca Rui Barbosa) foi escolhida por se tratar de uma linha coberta

sempre pelo mesmo tipo de veiculo (micro-onibus convencional) e cujo modo de pagamento

63

e unicamente atraves do cartao de transporte. Logo, pode-se extrapolar a quantidade de

passageiros total no onibus por simples proporcionalidade considerando a porcentagem de

cartoes utilizada na analise (cartoes utilizados apenas uma ou duas vezes ao dia, conforme

apresentado na Figura 23).

Os tipos de onibus e suas respectivas capacidades podem ser encontradas no Anexo

L. Observa-se que o micro-onibus convencional possui capacidade para 40 passageiros. Logo,

pela analise da Figura 34, verifica-se que em alguns momentos do dia a quantidade media de

passageiros embarcando na linha supera este limite.

A granularidade da analise apresentada aqui e ao nıvel de hora. Ela representa a media

de embarques e desembarques durante o perıodo deste estudo. Logo, apesar de dar bons indıcios

sobre o grau de ocupacao dos onibus, nao e possıvel saber precisamente se dentro do perıodo

de uma determinada hora o onibus atingiu, de fato, a sua capacidade maxima.

Para isto, seria preciso fazer uma analise por dia especıfico, por minuto, por exemplo.

A tıtulo de informacao, a Tabela 10 apresenta um resumo estatıstico dos valores estimados e

calculados referente a permanencia media dos usuarios desta linha. Em media os passageiros

ficam em torno de quinze minutos dentro do onibus (naturalmente, isso depende muito do

horario ao longo do dia).

Figura 34: Estimativa do grau de utilizacao da linha 461, coberta unicamente por micro-onibuscom capacidade para 40 passageiros. Media das quantidades totais de subida (linha azul) e descida(linha vermelha) de passageiros na linha ao longo do dia.

Min. 1◦ Quartil Mediana Media 3◦ Quartil Maximo00:02:01 00:07:21 00:13:54 00:15:19 00:22:05 00:55:49

Tabela 10: Dispersao do tempo medio de permanencia dos passageiros na linha 461.

Da mesma forma se pode identificar os horarios onde o onibus estaria mais ou menos

ocupado, tambem e possıvel identificar, ainda usando o exemplo da linha 461, quais os pontos

64

de onibus mais utilizados para embarque e desembarque. Conforme mostrado na Figura 35,

utilizando a mesma estrategia de visualizacao apresentada na Secao 4.5, pode-se produzir mapas

de calor indicando visualmente os pontos de maior afluencia de pessoas nesta linha.

(b)

(a)

Figura 35: (a) Regioes com maior densidade de passageiros desembarcando na linha 461; (b)Regioes com maior densidade de passageiros embarcando na linha 461.

Atraves da analise dos dados de base, principalmente os dados de geolocalizacao dos

65

onibus, tres diferentes servicos conectados podem ser vislumbrados: cerca eletronica, alerta de

velocidade e de manutencao preventiva.

O servico de cerca eletronica e mostrado aqui atraves do exemplo do veıculo DC852.

Durante os dias observados, este veıculo realizou as seguintes linhas: Z03, 464, 467, 489, 308

e 461. O trajeto oficial destas linhas esta detalhado na Figura 36-a.

De maneira simples, todos os momentos onde este veıculo emitiu posicoes GPS fora

de alguns destes tracados, um alerta poderia ser levantado. No entanto, em algumas situacoes,

o veıculo estava voltando para a garagem, apos o final do perıodo de cobertura da linha. Nestes

casos, o onibus deve emitir como informacao de linha a sigla “REC”. A Figura 36-b mostra

todos os pontos emitidos por este veıculo com a sigla “REC” como sendo a linha em execucao.

Portanto, tais pontos seriam teoricamente sem problemas e nao deveriam levantar nenhum alerta

por nao se sobreporem a nenhum dos trajetos das linhas previstas.

No entanto, todos os pontos apresentados em 36-c mereceriam alguma atencao pois o

onibus estava configurado para realizar uma das linhas citadas anteriormente. As causas podem

ser diversas: o motorista nao alterou o codigo da linha ou o sistema pode estar apresentando

algum erro, por exemplo. De qualquer forma, este fato deveria emitir algum alerta ao gestor da

frota em questao (ou a propria URBS) para que as medidas cabıveis pudessem ser tomadas.

Idealmente este servico deveria ser oferecido em tempo-real. Isto e absolutamente

factıvel haja visto que as informacoes de posicionamento sao disponibilizadas a cada dois

minutos. O proposito aqui e principalmente mostrar a capacidade e simplicidade em prover

um servico conectado de alto valor agregado para a gestao da atividade da frota de onibus,

atraves da utilizacao de dados ja disponibilizados pela URBS.

O alerta de velocidade tambem pode ser proposto apenas com base nas informacoes

de GPS ja disponıveis. A Figura 37 apresenta os valores calculados para o veıculo DC852 ao

longo dos dias observados. A ideia aqui tambem seria alertar em tempo-real algum eventual

excesso de velocidade desenvolvido por algum onibus.

De maneira geral, observa-se que os valores de velocidade medidos estao

majoritariamente abaixo dos 80 km/h. No entanto, encontram-se alguns picos acima dos 120

km/h, por exemplo.

Alias, um outro ponto merece uma certa atencao no que diz respeito a altos valores

de velocidade. Conforme a Tabela 11, analisando as velocidades de todos os veıculos na

rede observa-se alguns valores aberrantes. Apesar de representarem apenas 0,3% do total dos

valores calculados (com velocidade acima de 150 km/h), um ponto importante foi novamente

66

evidenciado: a confiabilidade das informacoes de GPS disponibilizadas.

Na verdade, estes valores exorbitantes de velocidade (chegando a um maximo de

25.000 km/h) devem-se a um erro na identificacao do momento de envio das mensagens GPS.

Em algumas poucas situacoes, duas posicoes GPS a princıpio coerentes sao enviadas. Porem, o

horario contido neste envio diferencia de alguns poucos segundos apenas (enquanto na realidade

deveria ser de cerca de dois minutos). Como o calculo da velocidade e realizado a partir deste

valor da etiqueta temporal da mensagem, obtem-se uma distancia na casa de algumas centenas

de metros percorrida em poucos segundos, resultando em valores gigantescos de velocidade.

Novamente, tais aberracoes sao bastante raras, nao invalidando de forma alguma o conceito

proposto.

Provavelmente, em um futuro proximo, os onibus serao capazes de emitir a informacao

de velocidade (a mesma que e apresentada no velocımetro do veıculo). Desta forma sera

possıvel aumentar a robustez deste tipo de servico conectado.

Alem disso, como exemplo de melhoria neste servico de alerta de velocidade, seria

possıvel comparar a velocidade desenvolvida pelo onibus com a velocidade autorizada na pista

onde ele trafega emitindo, eventualmente, um alerta em caso de excesso de velocidade.

Min. 1◦ Quartil Mediana Media 3◦ Quartil Maximo0,00 0,00 0,09 9,77 13,39 25050,00

Tabela 11: Resumo geral das velocidades (em km/h) calculadas para todos os veıculos durante operıodo observado. Valores de maximo exorbitantes devem-se a algumas poucas incoerencias nasetiquetas de “hora:minuto:segundo” das mensagens GPS emitidas.

Tambem e possıvel explorar a questao das velocidades medias das linhas de maneira

geral. A Figura 38 apresenta uma comparacao das velocidades medias de algumas linhas de

diferentes tipos ao longo das horas do dia (independentemente dos locais por onde tais linhas

passam). Como era de se esperar, pelo proprio perfil da linha, o Ligeirao tem uma media de

velocidade maior do que as outras linhas.

Em paralelo, a Figura 39 apresenta um exemplo de duas linhas comparando a

velocidade media em cada trecho da linha ao longo de um dia completo.

Naturalmente, ambos os efeitos poderiam ser combinados conforme a necessidade.

Por exemplo, pode haver interesse em conhecer a evolucao da velocidade media em um trecho

de uma certa linha nos perıodos que antecedem a hora do rush, por exemplo.

Por fim, o ultimo servico proposto refere-se ao calculo da quilometragem total

percorrida por cada veıculo na rede. A Figura 40 mostra os dez veıculos que teriam mais

67

rodado, segundo os resultados desta analise. A soma de todos os veıculos chega-se a cerca de

280 mil km por dia util. Este valor e muito proximo do valor oficial divulgado pela URBS de

320 mil km por dia util3.

Vale ressaltar que existe um erro intrınseco ao modo de calculo da distancia entre duas

informacoes GPS. Isto se deve ao fato de que as distancias entre dois pontos e calculada em

linha reta, o que nem sempre esta correto. No entanto, o custo computacional e a complexidade

necessarios para corrigir este fato nao se justifica perante o que se pretende demonstrar.

Os dez veıculos apresentados na Figura 40 realizaram 16 linhas distintas durante o

perıodo observado. Somando a quilometragem total realizada por todos os veıculos nos 8 dias

de semana observados chega-se a um total de mais de dois milhoes de quilometros rodados.

O foco principal deste servico seria indicar automaticamente ao gestor da frota o

momento de encaminhar alguns veıculos para manutencao com base somente na quilometragem

rodada. No entanto, o servico poderia ser muito mais rico se considerasse tambem informacoes

como relevo, regioes, tipos de vias utilizadas pelo onibus (informacoes diretamente relacionadas

as linhas realizadas). Bem como informacoes mais detalhadas sobre panes eletricas, carga total,

nıvel dos pneus etc. No futuro proximo vislumbra-se que os onibus certamente serao capazes de

fornecer tais informacoes, ampliando a gama e a eficiencia dos servicos conectados possıveis.

3http://www.urbs.curitiba.pr.gov.br/institucional/urbs-em-numeros (visitado em 02/07/2017).

68

(c)

(b)

(a)

Figura 36: Exemplo de servico de cerca eletronica utilizando o caso do veıculo DC852: (a) Trajetodas linhas realizadas por este veıculo nos dias observados; (b) Posicoes emitidas pelo veıculoquando este estava voltando para a garagem (codigo da linha era “REC”); (c) Pode-se notarcasos fora do trajeto esperado onde o onibus supostamente deveria estar realizando alguma linhaespecıfica (nao estaria voltando pra garagem).

69

Figura 37: Velocidades observadas/calculadas para o veıculo DC852 durante os dias considerados(majoritariamente abaixo dos 80 km/h).

Figura 38: Velocidade media (em km/h) calculada agregando dados de todos os dias observados.Aqui sao comparadas diferentes linhas de diferentes tipos: Convencional (linha 461), Interbairros(linha 40), Expresso (linha 203), Ligeirinho (linha 256), Alimentador (linha 225), Troncal (linha372) e Ligeirao (linha 550). Consiste na velocidade media calculada para toda a linha por hora,independente da posicao geografica de cada onibus da linha naquela hora.

70

(a) (b)

Figura 39: Velocidade media (em km/h) calculada durante todos os dias observados, para cadatrecho da linha (agregando todas as horas do dia). (a) Linha 040: Interbairros IV; (b) Linha 550:Ligeirao - Pinheirinho / C. Gomes.

Figura 40: Lista dos dez veıculos que mais rodaram durante os dias observados.

71

5 CONCLUSOES

Atraves da analise dos dados disponibilizados livremente pela cidade foi possıvel

obter resultados relevantes e de grande valor agregado sobre a forma como o sistema de

transporte e utilizado pela populacao de Curitiba. Alem de evidenciar e propor a URBS alguns

indicadores mais voltados a utilizacao dos veıculos na rede e novos servicos telematicos a todos

os envolvidos na utilizacao, gestao e evolucao do sistema de transporte publico.

Para mostrar o potencial oriundo da exploracao dos dados abertos da cidade, foram

propostos cinco servicos telematicos oferecendo: uma forma objetiva de avaliar as linhas

existentes frente a real necessidade em mobilidade da populacao; uma forma indireta de estimar

o nıvel de utilizacao dos onibus e dos pontos de onibus; o servico de cerca eletronica utilizando

os itinerarios das linhas como limites geograficos para o servico; alertas de velocidade

instantanea e velocidade media dos veıculos e linhas; lembrete de manutencao dos onibus a

partir da quilometragem total percorrida por cada um.

Alem disso, a fim de obter todos os subsıdios para os servicos acima mencionados

, uma matriz de origem-destino foi produzida a partir dos dados de bilhetagem automatica

(cartoes de transporte) e das coordenadas GPS de cada onibus. Espera-se que este trabalho

auxilie as autoridades e responsaveis a melhor compreenderem o comportamento dos usuarios

com respeito a suas origens e destinos. Tudo isso com custos bastante reduzidos (em dinheiro

e em tempo) comparado a sondagens manuais usualmente aplicadas. Algumas alternativas de

visualizacao dos dados tambem foram brevemente apresentadas.

Foi necessario um arduo trabalho de compreensao e limpeza dos dados ate que estes

estivessem realmente prontos para utilizacao. A falta de elementos essenciais tais como:

descricao de cada um dos atributos das bases disponibilizadas; utilizacao de um mesmo campo

para informacoes diferentes (no caso do COD URBS para tubos e terminais); informacoes

conflitantes entre os diversos web-services; oscilacao na presenca de informacoes GPS para

todos os veıculos; ausencia de informacoes como sentido ou ID de cada viagem entre outros,

tornou esta etapa crucial ainda mais crıtica.

72

Ainda assim, gracas ao suporte e disponibilidade de todos os interlocutores, tais

obstaculos puderam ser superadas e por diversas vezes compartilhados em eventos dedicados a

este fim unindo a UTFPR e a URBS.

A maneira como a metodologia foi implementada, principalmente no que tange as

operacoes em SQL, podem certamente ser melhoradas. Por diversas vezes, o modo escolhido

faz uso de operacoes bastante custosas computacionalmente (como cross join), levando bastante

tempo para serem finalizadas. Este fato, unido a uma serie de intervencoes manuais e de troca

de ambientes e linguagens (SQL, Python e R) dificulta uma eventual automatizacao do processo

como um todo.

Independentemente disto, espera-se ter mostrado com bastante clareza o potencial que

os dados abertos do transporte publico de Curitiba possuem. Unir estes dados e conclusoes

a outras bases (ja disponıveis ou nao) da cidade poderiam certamente conduzir a um melhor

entendimento sobre o funcionamento da mesma.

5.1 TRABALHOS FUTUROS

E fascinante vislumbrar a quantidade de temas interessantes e relevantes que se abrem

a partir daqui, possibilitando explorar com maior profundidade este importante tema para a

cidade de Curitiba:

• Validar (eventualmente adequar, corrigir ou abalizar) os resultados obtidos neste trabalho

atraves do cruzamento dos resultados da pesquisa oficial de Origem-Destino aplicada pela

prefeitura de Curitiba no decorrer do ano1;

• Considerar novas hipoteses para um melhor entendimento e estimativa dos casos de unica

utilizacao do cartao no dia, haja visto a importancia e impacto nos resultados;

• Da mesma forma, os casos de utilizacao dos cartoes por mais de duas vezes ao dia

poderiam ser explorados (tanto na busca de identificar casos de fraudes como na tentativa

de agregar novos dados as analises apresentadas). Para isto, seria importante considerar

tambem questoes sobre os possıveis trajetos empregados.

• Validar e afinar a estimativa de utilizacao de cada onibus no decorrer do dia atraves da

utilizacao de outras fontes de dados (como os sensores de peso ja presente em alguns

onibus mais modernos da rede de transporte);1Os resultados estao previstos para serem divulgados em meados de 2017. Para tal, e importante ter em mente

que um fator de proporcionalidade precisa ser definido, uma vez que os valores obtidos aqui representam apenasos usuarios portadores de cartao de transporte.

73

• Trabalhar com tecnicas mais avancadas de visualizacao de dados, facilitando a tomada de

decisao pelos responsaveis da rede de transporte;

• Experimentar, estruturar e analisar os dados recolhidos utilizando tecnicas e tecnologias

de big-data, armazenando e analisando volumes muito maiores de dados;

• Explorar conceitos de correlacao espaco-temporal atraves de analises estatısticas mais

aprofundadas. Da mesma forma, aplicar tecnicas de mineracao de dados ou de analise

de grafos buscando evidenciar caracterısticas intrınsecas da rede de transporte e de seus

usuarios;

• Avaliar o comportamento da rede na ocasiao de grandes eventos na cidade, observando

e modelando a convergencia e a dispersao dos usuarios do sistema de transporte nestas

situacoes pontuais e atıpicas;

• Organizar e unificar todos os servicos em uma plataforma capaz de oferece-los em tempo-

real e de forma a ser facilmente utilizado pela URBS;

• Propor projeto piloto com a URBS para validar, adaptar e ate mesmo estender as

funcionalidades evidenciadas neste trabalho;

• Estimar o quanto a proposta de novas linhas seria capaz de desafogar ou aliviar gargalos

atuais da rede (atraves de simulacoes, por exemplo);

• Buscar cobrir as razoes de tal mobilidade, associando informacoes como dados

meteorologicos, sociais, demograficos ou de localizacao de estabelecimentos como

escolas, hospitais e postos de saude na cidade.

Naturalmente, estes metodos e resultados sao aplicaveis a qualquer outra cidade ao

redor do mundo onde haja a disponibilizacao dos dados vitais sobre o funcionamento da

mesma. Desta forma, a sociedade passaria a ter a oportunidade de usufruir de novos servicos e

funcionalidades inovadores gracas a conectividade.

74

REFERENCIAS

BABINET, G. Big Data, penser l’homme et le monde autrement. [S.l.]: Sofedis, 2015.

BAGCHI, M.; WHITE, P. What role for smart-card data from bus system? Proceedings of theInstitution of Civil Engineers, v. 157, n. 1, p. 39–46, March 2004.

BUNEMAN, K. Automated and passenger-based transit performance measures.Transportation Research Board, n. 992, p. 23–28, 1984.

CACERES, N.; WIDEBERG, J.; BENITEZ, F. Review of traffic data estimations extractedfrom cellular networks. IET Intelligent Transport Systems, v. 2, n. 3, p. 179–192, September2008.

CALABRESE, F. Un reseau d’autobus redessine grace au telephone mobile. La RechercheL’actualite des sciences, OJD, n. 482, p. 32–35, December 2013.

CHEN, M. et al. Big Data Related Technologies, Challenges and Future Prospects. [S.l.]:Springer, 2014. (Springer Briefs in Computer Science, 978-3-319-06245-7).

CHU, K.; CHAPLEAU, R. Enriching archived smart card transaction data for transit demandmodeling. Transportation Research Record: Journal of the Transportation ResearchBoard, v. 2063, n. 8, p. 63–72, 2008.

CHU, K.; CHAPLEAU, R.; TREPANIER, M. Driver-assisted bus interview (dabi): Passivetransit travel survey using smart card automatic fare collection system and its applications. In:BOARD, T. R. (Ed.). 88th Annual Meeting of the Transportation Research Board. [S.l.],2009. (88, 21), p. v.p.

COME, E.; MAHRSI, M. K. E.; OUKHELLOU, L. Cartographie interactive de matricesorigines / destinations. 2014.

CUI, A. Bus Passenger Origin-Destination Matrix Estimation Using Automated DataCollection Systems. Tese (Doutorado) — Massachusetts Institute of Technology, Dept. of Civiland Environmental Engineering, September 2006.

DEAKIN, E.; KIM, S. Transportation technologies: Implications for planning. University ofCalifornia Transportation Center, n. 536, p. 27, May 2001.

EDWARDS, J. Signal processing leads to new wireless technologies [special reports]. IEEESignal Processing Magazine, IEEE, v. 31, n. 5, p. 10–14, August 2014.

EMC. Data Science and Big Data Analytics: Discovering, Analyzing, Visualizing andPresenting Data. [S.l.]: John Wiley & Sons, Inc., 2015. (EMC Education Services, 978-1-118-87613-8).

Executive Office of the President. Big data: Seizing opportunities, preserving values. [S.l.],May 2014.

75

FARZIN, J. Constructing an automated bus origin-destination matrix using farecard and globalpositioning system data in sao paulo, brazil. Transportation Research Record: Journal ofthe Transportation Research Board, v. 2072, n. 4, p. 30–37, 2008.

GESELOWITZ, M. Census and sensibility a little history of big data. The Institute:Connecting the Dots with Big Data, IEEE, p. 9–10, September 2014.

GUERRA, A. L. Determinacao de matriz origem/destino utilizando dados do sistema debilhetagem eletronica. Dissertacao (Mestrado) — Universidade Federal de Minas Gerais,Escola de Engenharia (Curso de Mestrado em Geotecnia e Transportes), July 2011.

HOFFMAN, M.; WILSON, S.; WHITE, P. Automated identification of linked trips at trip levelusing electronic fare collection data. In: TRANSPORTATION RESEARCH BOARD. 88thAnnual Meeting of the Transportation Research Board. Washington DC, United States,2009. p. 18.

KOZIEVITCH, N. P. et al. Exploratory analysis of public transportation data in Curitiba. In:CSBC. 43o SEMISH - Seminario Integrado de Software e Hardware. Porto Alegre, Brazil,2016.

KUHLMAN, W. The construction of purpose specific OD matrices using public transportsmart card data. Dissertacao (Mestrado) — Delft University of Technology, Faculty of CivilEngineering and Geosciences, October 2015.

LIANFU, Z.; SHUZHI, Z.; YONGGANG, Z. Study on the method of constructing bus stopsod matrix based on ic card data. In: International Conference on Wireless Communications,Networking, and Mobile Computing. Shanghai, China: [s.n.], 2007. p. 3147–3150.

MA, X.; WANG, Y. Development of a data-driven platform for transit performance measuresusing smart card and GPS data. Journal of Transportation Engineering, v. 140, n. 12, p.published online, July 2014.

NORA, S.; MINC, A. L’informatisation de la societe. Paris, France, May 1978.

PELLETIER, M.-P.; TREPANIER, M.; MORENCY, C. Smart card data use in public transit:A literature review. Transportation Research Part C, v. 19, n. 4, p. 557–568, August 2011.

PORTER, M. E.; HEPPELMANN, J. E. Comprendre et gerer l’internet des objets. Tout estConnecte Comment l’internet des objets revolutionne tous les business, Groupe PrismaMedia, n. 8, p. 37–62, April 2015.

SARQUIS, M. M. Comunicacao veıculo-para-x Estudo de um caso aplicativo dacomunicacao de controle de uma estacao rodoviaria e dos veıculos em seu alcance.December 2013. Monografia (Graduacao em Engenharia Eletrica), UFPR (UniversidadeFederal do Parana), Curitiba.

TREPANIER, M.; CHAPLEAU, R.; TRANCHANT, N. Individual trip destination estimationin transit smart card automated fare collection system. Journal of Intelligent TransportationSystems: Technology, Planning, and Operations, v. 11, n. 1, p. 1–15, January 2007.

TREPANIER, M.; MORENCY, C. Assessing transit loyalty with smart card data. In: WORLDCONFERENCE ON TRADE RESEARCH SOCIETY. 12th World Conference on TransportResearch. Lisbon, Portugal, 2010.

76

TREPANIER, M.; MORENCY, C.; AGARD, B. Calculation of transit performance measuresusing smartcard data. Journal of Public Transportation, v. 12, n. 1, p. 79–96, March 2009.

TREPANIER, M.; MORENCY, C.; BLANCHETTE, C. Les systemes de paiement par cartes apuces: un complement aux enquetes origine-destination? In: ASSOCIATION QUeBeCOISEDU TRANSPORT ET DES ROUTES. 43e congres de l’Association Quebecoise du transportet des routes. Quebec, Canada, 2008.

TREPANIER, M.; MORENCY, C.; BLANCHETTE, C. Enhancing household travel surveysusing smart card data? In: TRANSPORTATION RESEARCH BOARD. 88th Annual Meetingof the Transportation Research Board. Washington DC, United States, 2009. p. 15.

VIERECKL, R. et al. Connected Car Study 2015 & Racing ahead with autonomous carsand digital innovation. [S.l.], September 2015.

ZHAO, J. The Planning and Analysis Implications of Automated Data Collection System:Rail Transit OD Matrix Inference and Path Choice Modeling Examples. Tese (Doutorado)— Massachusetts Institute of Technology, Department of Urban Studies and Planning and theDepartment of Civil and Environmental Engineering, September 2004.

77

ANEXO A -- SCRIPT R: OBTER POSICOES GPS E DADOS DOS CARTOES

# ***************** SCRIPT R PARA OBTER DADOS CARTÕES *****************

#A cada dia fazer a requisição para obter as localizações#Para rodar o .bat é preciso acrescentar o R na variavel de ambiente "Path"#Armazenar tb a data do request

library(XML)library(jsonlite)library(curl)

#HEADER:#"CODLINHA";"NOMELINHA";"CODVEICULO";"NUMEROCARTAO";"DATAUTILIZACAO"

json <- curl("http://transporteservico.urbs.curitiba.pr.gov.br/convenios/?h=44de3&v=db9b2")mydf <- jsonlite::stream_in(gzcon(json))write.table(mydf, file = "C:\\Users\\Paulo\\Google Drive\\00_MESTRADO\\00_Dados URBS\\Dados_W43_44\\Dados_CARTOES_URBS_3.csv", sep=";",row.names = FALSE, col.names = FALSE, append=TRUE)write.table(paste(Sys.time(),length(mydf[,1]),sep=";"), file = "C:\\Users\\Paulo\\Google Drive\\00_MESTRADO\\00_Dados URBS\\Dados_W43_44\\LOG_CARTOES_3.csv", sep=";",row.names =FALSE, col.names = FALSE, append=TRUE)

# ***************** SCRIPT R PARA OBTER GPS DOS ÔNIBUS *****************#A cada 2 minutos fazer a requisição para obter as localizaçoes# Para rodar o .bat é preciso acrescentar o R na variavel de ambiente "Path"#Armazenar tb a data do request

library(XML)library(jsonlite)library(curl)

#HEADER:#"Sys.time()";"PREFIXO";"HORA";"LAT";"LON";"LINHA";"ADAPT"

json <- curl("http://transporteservico.urbs.curitiba.pr.gov.br/getVeiculosLinha.php?c=44de3")mydf <- jsonlite::stream_in(gzcon(json))#add time scriptinto dataframemydf <- cbind (Sys.time(),mydf)#substituir a virgula por ponto nos valores de lat/longmydf$LAT <- gsub(",", ".", mydf$LAT)mydf$LON <- gsub(",", ".", mydf$LON)write.table(mydf, file = "C:\\Users\\Paulo\\Google Drive\\00_MESTRADO\\00_Dados URBS\\Dados_W43_44\\Dados_GPS_URBS_3.csv", sep=";",row.names = FALSE, col.names = FALSE, append=TRUE)write.table(paste(Sys.time(),length(mydf[,1]),sep=";"), file = "C:\\Users\\Paulo\\Google Drive\\00_MESTRADO\\00_Dados URBS\\Dados_W43_44\\LOG_GPS_3.csv", sep=";",row.names = FALSE, col.names = FALSE, append=TRUE)

78

79

ANEXO B -- SCRIPT PYTHON: CONTAR QUANTAS VEZES CADA CARTAO FOIUTILIZADO NO DIA

import sysimport psycopg2import datetime

#Maiores info: https://wiki.postgresql.org/wiki/Psycopg2_Tutorialconn = psycopg2.connect("dbname = 'OD_urbs_mestrado' user = 'postgres' host = 'localhost' password = 'jeanclaude'")cur = conn.cursor()

## ****************** Criar 1/1, 1/2, 2/2 ... ***********************#### Acrescentar info se é a 1/1, 1/2 ou 2/2 passagem do cartão naquele dia (fazer por dia!!)## ATENCAO PARA O NOME DA TABELA DE CARTOES UTILIZADA!!## Acrescentar tal info na coluna "STEP_PASS_CARD"## Criar hashmap com o número do cartão como "chave" e quantas vezes aquele cartão é utilizado no dia como "valor".

##Carregar a tabela de cartões (por dia)query = """SELECT *FROM public.URBS_CARD_rawWHERE URBS_CARD_raw.datautilizacao LIKE '03/11/16%'ORDER BY URBS_CARD_raw.datautilizacao;"""cur.execute(query)conn.commit()

#When you have executed your query you need to have a list [variable?] to put your results in.#Now all the results from our query are within the variable named "rowsUrbs_Cards". Using this variable you can start processing the results.rowsUrbs_Cards = cur.fetchall()

#print (len(rowsUrbs_Cards))

## "CODLINHA" "NOMELINHA" "CODVEICULO" "NUMEROCARTAO" "DATAUTILIZACAO"

Hash_Cards= {}for row in rowsUrbs_Cards:

#If key does not exist, create it (with value 1).. otherwise, increment itif row[3] in Hash_Cards:

Hash_Cards[row[3]] = (0, Hash_Cards[row[3]][1] + 1)else:

Hash_Cards[row[3]]=(0, 1)

keys = Hash_Cards.keys()values = Hash_Cards.values()

# print("Keys:")# print(keys)print(len(rowsUrbs_Cards))print (datetime.datetime.now())## print("Values:")# print(values)# #print(len(values))

## After that, for each appearance, fill STEP_PASS_CARD## For each row fill value and increment "1" at Hash_Cards[row[0]][0]i=0for row in rowsUrbs_Cards:

Hash_Cards[row[3]] = (Hash_Cards[row[3]][0] + 1, Hash_Cards[row[3]][1])query = """

UPDATE public.URBS_CARD_raw SET STEP_PASS_CARD =

'"""+str(Hash_Cards[row[3]][0])+"""/"""+str(Hash_Cards[row[3]][1])+"""' WHERE URBS_CARD_raw.numerocartao = '"""+row[3]+"""' and URBS_CARD_raw.codlinha = '"""+row[0]+"""' and URBS_CARD_raw.nomelinha = '"""+row[1]+"""' and URBS_CARD_raw.codveiculo = '"""+row[2]+"""' and URBS_CARD_raw.datautilizacao = '"""+row[4]+"""' ;"""

80

cur.execute(query)conn.commit()i=i+1##print(i)

print (datetime.datetime.now())

81

82

ANEXO C -- SCRIPT PYTHON: CRIAR GRADES SOBRE A CIDADE DE CURITIBA

import shapefile as shpimport math

minx,maxx,miny,maxy = -49.408763, -49.143656, -25.645602, -25.308706

#Dividindo-se o perímetro pelos 360º da circunferência da Terra, chega-se à conclusão de que cada grau de curvatura terrestre tem 111,12 quilômetros.# 1.00 >> 111,12 km. Logo: 500 m >> 0.0045

dx = 0.0045dy = 0.0045

nx = int(math.ceil(abs((maxx - minx)/dx)))ny = int(math.ceil(abs((maxy - miny)/dy)))

# minx,maxx,miny,maxy = 448262.080078, 450360.750122, 6262492.020081, 6262938.950073# dx = 100# dy = 100## nx = int(math.ceil(abs(maxx - minx)/dx))# ny = int(math.ceil(abs(maxy - miny)/dy))

w = shp.Writer(shp.POLYGON)w.autoBalance = 1w.field("ID")id=0

for i in range(ny):for j in range(nx):

id+=1vertices = []parts = []vertices.append([min(minx+dx*j,maxx),max(maxy-dy*i,miny)])vertices.append([min(minx+dx*(j+1),maxx),max(maxy-dy*i,miny)])vertices.append([min(minx+dx*(j+1),maxx),max(maxy-dy*(i+1),miny)])vertices.append([min(minx+dx*j,maxx),max(maxy-dy*(i+1),miny)])parts.append(vertices)w.poly(parts)w.record(id)

w.save('polygon_grid2')

83

84

ANEXO D -- SCRIPT SQL: ASSOCIAR GRADES AOS PONTOS DE ONIBUS

--## Acrescentar coluna em bus_stops_table com a info sobre qual GridID cada ponto faz parteALTER TABLE public.bus_stops_table ADD COLUMN gps_position geometry(POINT,4326);ALTER TABLE public.bus_stops_table ADD COLUMN grid_id character varying;ALTER TABLE public.bus_stops_table ADD COLUMN grid_gps geometry(MULTIPOLYGON,4326);

--# Cria-se um atributo tipo geográfico a partir das informações de latitude e longitudeUPDATE public.bus_stops_table SET gps_position = ST_SetSRID(ST_MakePoint(lon,lat),4326);select * into temporary tmp2from(select * from(select *, ST_Contains(gridgeo, gps_position) as status from bus_stops_table cross joinpolygongrid) as foowhere status= TRUE) as foo2;

UPDATE tmp2 SET grid_id = id;UPDATE tmp2 SET grid_gps = gridgeo;

85

86

ANEXO E -- SCRIPT SQL: UNIR UTILIZACAO DOS CARTOES COMINFORMACAO DE GPS DOS ONIBUS

--##############################################################################################--## File 2: From cards to GPS--## Achar o GPS mais próximo do ônibus em questão para cada passagem de cartão --## (para um único dia 26/09)--## HYP: SÓ EXISTE UM DIA NA BASE DE CARTOES E GPS!! PREENCHER O DIA EM QUESTÃO NO SQL ABAIXO--##############################################################################################

DISCARD TEMP;

--## Tabela temporária com o tempo minimo para cada passagem do cartão (mas sem as coordenadas)SELECT * INTO TEMPORARY parcial_1FROM(SELECTtmp.numerocartao as nCard1, tmp.codlinha as line1, tmp.codveiculo as veic1,tmp.step_pass_card as step1, tmp.homogeneousdatetime as datautilizacao1, MIN (tmp.dif) asmindistFROM(SELECT

URBS_CARD_raw.numerocartao, URBS_CARD_raw.codlinha,URBS_CARD_raw.codveiculo,URBS_CARD_raw.step_pass_card,URBS_CARD_raw.homogeneousdatetime, Period_BUS_GPS.lat,Period_BUS_GPS.lon,Period_BUS_GPS.gps_position,(CASE WHEN URBS_CARD_raw.homogeneousdatetime > Period_BUS_GPS.homogeneousdatetime THENURBS_CARD_raw.homogeneousdatetime - Period_BUS_GPS.homogeneousdatetime ELSEPeriod_BUS_GPS.homogeneousdatetime - URBS_CARD_raw.homogeneousdatetime END) as dif

FROMpublic.URBS_CARD_raw inner join public.Period_BUS_GPSON URBS_CARD_raw.codlinha=Period_BUS_GPS.linha andURBS_CARD_raw.codveiculo=Period_BUS_GPS.prefixo

WHERE URBS_CARD_raw.datautilizacao LIKE '11/11/16%' and Period_BUS_GPS.scriptdate LIKE'2016-11-11%'

) as tmpGroup by nCard1,line1, veic1, step1, datautilizacao1

) AS tmp2;

--## Tabela temporária com dist de tempo de cada onibus com a passagem de cada cartãoSELECT * INTO TEMPORARY parcial_2FROM(

SELECTURBS_CARD_raw.numerocartao, URBS_CARD_raw.codlinha,URBS_CARD_raw.codveiculo,URBS_CARD_raw.step_pass_card,URBS_CARD_raw.homogeneousdatetime, Period_BUS_GPS.lat,Period_BUS_GPS.lon,Period_BUS_GPS.gps_position,(CASE WHEN URBS_CARD_raw.homogeneousdatetime > Period_BUS_GPS.homogeneousdatetime THENURBS_CARD_raw.homogeneousdatetime - Period_BUS_GPS.homogeneousdatetime ELSEPeriod_BUS_GPS.homogeneousdatetime - URBS_CARD_raw.homogeneousdatetime END) as dif

FROMpublic.URBS_CARD_raw inner join public.Period_BUS_GPSON URBS_CARD_raw.codlinha=Period_BUS_GPS.linha andURBS_CARD_raw.codveiculo=Period_BUS_GPS.prefixo

WHERE URBS_CARD_raw.datautilizacao LIKE '11/11/16%' and Period_BUS_GPS.scriptdate LIKE'2016-11-11%'

) as tmp3;

--## Tabela temporária final com as coordenadas e seu respectivo delta t minimoSELECT * INTO TEMPORARY parcial_3FROM (SELECT DISTINCT tmp4.numerocartao as nCard3,tmp4.codlinha as line3, tmp4.codveiculo asveic3, tmp4.step_pass_card as step3, tmp4.homogeneousdatetime as datautilizacao3,tmp4.mindist as mindist3, tmp4.lat as lat3, tmp4.lon as lon3,tmp4.gps_position as gps3FROM(parcial_1 inner join parcial_2ONparcial_1.nCard1 = parcial_2.numerocartao ANDparcial_1.line1 = parcial_2.codlinha ANDparcial_1.veic1 = parcial_2.codveiculo ANDparcial_1.step1 = parcial_2.step_pass_card AND

87

parcial_1.datautilizacao1 = parcial_2.homogeneousdatetime ANDparcial_1.mindist = parcial_2.dif

) as tmp4) as tmp5;

--## Usado para o update (join da parcial_3 e da gps_urbs)SELECT * INTO TEMPORARY parcial_4FROM (SELECT *FROM(public.URBS_CARD_raw inner join parcial_3ONURBS_CARD_raw.numerocartao = parcial_3.ncard3 ANDURBS_CARD_raw.codlinha = parcial_3.line3 ANDURBS_CARD_raw.codveiculo = parcial_3.veic3 ANDURBS_CARD_raw.step_pass_card = parcial_3.step3 ANDURBS_CARD_raw.homogeneousdatetime = parcial_3.datautilizacao3

) as tmp5) as tmp6;

--## Update da tabela de cartões com os dados da parcial_4UPDATE public.URBS_CARD_rawSET lat = parcial_4.lat3, lon = parcial_4.lon3, gps_position = parcial_4.gps3, timedif =parcial_4.mindist3FROM parcial_4WHERE

URBS_CARD_raw.numerocartao = parcial_4.ncard3 ANDURBS_CARD_raw.codlinha = parcial_4.line3 ANDURBS_CARD_raw.codveiculo = parcial_4.veic3 ANDURBS_CARD_raw.step_pass_card = parcial_4.step3 ANDURBS_CARD_raw.homogeneousdatetime = parcial_4.homogeneousdatetime;

drop table parcial_1;drop table parcial_2;drop table parcial_3;drop table parcial_4;

88

89

ANEXO F -- SCRIPT SQL: DEFINIR GRADE DE PARTIDA E DE CHEGADA

--## HIPÓTESE:-- □ Não necessitamos saber exatamente o trajeto, nem o ponto de embarque e desembarque (exceto no caso da estimativa do preenchimento dos ônibus).-- □ Consideramos que a pessoa usando duas vezes o cartão, vai e volta para a mesma região..-- □ Logo, para os x/2-- - considerar apenas os GPS de pegada da linha (mais confiável e fazer a seguinte configuração):-- □ 1/2: Grid_Start:OK Grid_Stop: colocar o Grid_Start do 2/2 correspondente-- □ 2/2: Grid_Start:OK Grid_Stop: colocar o Grid_Start do 1/2 correspondente-- - Para os 1/1, seguir estratégia diferente: Havendo outra utilização dupla no dia, partindo de um ponto próximo dali, considera-la como o -- mesmo destino. Caso não exista, considerar como destino a região de maior afluência de usuários--##

update public.urbs_card_raw_final aset grid_stop = b.grid_start, grid_stop_lat = b.grid_start_lat, grid_stop_lon =b.grid_start_lon, grid_stop_gps= b.grid_start_gpsfrom public.urbs_card_raw_final bwhere a.numerocartao = b.numerocartaoand EXTRACT(DAY FROM a.homogeneousdatetime) = EXTRACT(DAY FROM b.homogeneousdatetime)and a.step_pass_card = '2/2'and b.step_pass_card = '1/2';

update public.urbs_card_raw_final aset grid_stop = b.grid_start, grid_stop_lat = b.grid_start_lat, grid_stop_lon =b.grid_start_lon, grid_stop_gps= b.grid_start_gpsfrom public.urbs_card_raw_final bwhere a.numerocartao = b.numerocartaoand EXTRACT(DAY FROM a.homogeneousdatetime) = EXTRACT(DAY FROM b.homogeneousdatetime)and a.step_pass_card = '1/2'and b.step_pass_card = '2/2';

--## Ajustar também para os casos de única utilização diária (Step_Pass_Card = 1/1)

--## PARA OS DIAS DA SEMANA (8 dias):select count(use), usefrom(select count (numerocartao) as use, numerocartao from urbs_card_raw_final wherestep_pass_card = '1/1'and (datautilizacao LIKE '31/10/16%' or datautilizacao LIKE '03/11/16%' or datautilizacaoLIKE '04/11/16%' or datautilizacao LIKE '07/11/16%' ordatautilizacao LIKE '08/11/16%' or datautilizacao LIKE '09/11/16%' or datautilizacao LIKE'10/11/16%' or datautilizacao LIKE '11/11/16%')group by numerocartao)as foogroup by use order by use;-- 88109;1-- 56903;2-- 38537;3-- 26427;4-- 18636;5-- 13934;6-- 10526;7-- 6216;8

select count(numerocartao) from urbs_card_raw_final where step_pass_card = '1/1' andgrid_stop IS NULLand (datautilizacao LIKE '31/10/16%' or datautilizacao LIKE '03/11/16%' or datautilizacaoLIKE '04/11/16%' or datautilizacao LIKE '07/11/16%' ordatautilizacao LIKE '08/11/16%' or datautilizacao LIKE '09/11/16%' or datautilizacao LIKE'10/11/16%' or datautilizacao LIKE '11/11/16%') ; --> 723.428

--## Dos que são 8 dias, não tem jeito.. só tem mesmo uma única informação nos 8 dias de dados que recolhi!(sempre 1/1 nos 8 dias coletados) --## Já nos outros, daria pra torcer para ver se teríamos algum outro caso com 1/2, saindo de algum lugar próximo ao do 1/1 em questão

select * into temporary tmp1from(

90

select num_tmpfrom(select count (numerocartao) as use, numerocartao as num_tmp from urbs_card_raw_final wherestep_pass_card = '1/1'and (datautilizacao LIKE '31/10/16%' or datautilizacao LIKE '03/11/16%' or datautilizacaoLIKE '04/11/16%' or datautilizacao LIKE '07/11/16%' ordatautilizacao LIKE '08/11/16%' or datautilizacao LIKE '09/11/16%' or datautilizacao LIKE'10/11/16%' or datautilizacao LIKE '11/11/16%')group by numerocartao)as foowhere use <> 8INTERSECTselect numerocartao from urbs_card_raw_final where step_pass_card <> '1/1'and (datautilizacao LIKE '31/10/16%' or datautilizacao LIKE '03/11/16%' or datautilizacaoLIKE '04/11/16%' or datautilizacao LIKE '07/11/16%' ordatautilizacao LIKE '08/11/16%' or datautilizacao LIKE '09/11/16%' or datautilizacao LIKE'10/11/16%' or datautilizacao LIKE '11/11/16%') ) as foo2;

--## Copiar os valores do 1/2 se o bsStart do 1/2 comparado ao bsStart do 1/1 estiverem separados por menos de 2121 metros --(diagonal do quadrado formado pelos grids que considerei com os 8 adjacentes)select * into temporary tmp2from(select * fromtmp1 inner join urbs_card_raw_final on numerocartao = num_tmp and step_pass_card <> '1/1'and (datautilizacao LIKE '31/10/16%' or datautilizacao LIKE '03/11/16%' or datautilizacaoLIKE '04/11/16%' or datautilizacao LIKE '07/11/16%' or

datautilizacao LIKE '08/11/16%' or datautilizacao LIKE '09/11/16%' or datautilizacao LIKE'10/11/16%' or datautilizacao LIKE '11/11/16%')) as foo;

update urbs_card_raw_final set grid_stop = tmp2.grid_stop, grid_stop_lat =tmp2.grid_stop_lat, grid_stop_lon = tmp2.grid_stop_lon, grid_stop_gps= tmp2.grid_stop_gpsfrom tmp2where urbs_card_raw_final.numerocartao=tmp2.num_tmp and urbs_card_raw_final.step_pass_card='1/1' and ST_DistanceSphere(urbs_card_raw_final.bsstart_gps, tmp2.bsstart_gps)<=2121and (tmp2.datautilizacao LIKE '31/10/16%' or tmp2.datautilizacao LIKE '03/11/16%' ortmp2.datautilizacao LIKE '04/11/16%' or tmp2.datautilizacao LIKE '07/11/16%' or

tmp2.datautilizacao LIKE '08/11/16%' or tmp2.datautilizacao LIKE '09/11/16%' ortmp2.datautilizacao LIKE '10/11/16%' or tmp2.datautilizacao LIKE '11/11/16%');

-- ## Verificando quanto sobraram apos este processoselect count(*) from urbs_card_raw_final where grid_stop IS NULL and step_pass_card = '1/1'and (datautilizacao LIKE '31/10/16%' or datautilizacao LIKE '03/11/16%' or datautilizacaoLIKE '04/11/16%' or datautilizacao LIKE '07/11/16%' ordatautilizacao LIKE '08/11/16%' or datautilizacao LIKE '09/11/16%' or datautilizacao LIKE'10/11/16%' or datautilizacao LIKE '11/11/16%') ;-->> 470.154 (ao inves dos 723.428 iniciais)

--## Desses aqui, utilizar outra heurística: considerar o destino "mais utilizado" pelos outros usuários que pegaram na mesma hora que ele.--discard temp;SELECT * INTO TEMPORARY parcial_1from (select foo.periodo, max (foo.count) as maxCountfrom (select periodo, grid_stop, count(grid_stop) as count from urbs_card_raw_finalwhere step_pass_card <> '1/1' and(datautilizacao LIKE '31/10/16%' or datautilizacao LIKE '03/11/16%' or datautilizacao LIKE'04/11/16%' or datautilizacao LIKE '07/11/16%' ordatautilizacao LIKE '08/11/16%' or datautilizacao LIKE '09/11/16%' or datautilizacao LIKE'10/11/16%' or datautilizacao LIKE '11/11/16%')group by periodo, grid_stop)as foogroup by (foo.periodo)order by foo.periodo) as foo2;

SELECT * INTO TEMPORARY parcial_2from (select periodo, grid_stop, count(grid_stop) as count from urbs_card_raw_finalwhere step_pass_card <> '1/1' and(datautilizacao LIKE '31/10/16%' or datautilizacao LIKE '03/11/16%' or datautilizacao LIKE

91

'04/11/16%' or datautilizacao LIKE '07/11/16%' ordatautilizacao LIKE '08/11/16%' or datautilizacao LIKE '09/11/16%' or datautilizacao LIKE'10/11/16%' or datautilizacao LIKE '11/11/16%')group by periodo, grid_stopORDER BY periodo, count)as foo3;

SELECT * INTO TEMPORARY parcial_3FROM (SELECT parcial_1.periodo, parcial_2.grid_stopFROM(parcial_1 inner join parcial_2ONparcial_1.periodo = parcial_2.periodo AND parcial_1.maxCount = parcial_2.count)) as foo4;

--## Complementar em parcial_4 os valores de lat e lon do bsstop_num, grid_stop, grid_stop_lat, grid_stop_lon encontrados (antes de atualizar a base de cartões com tal valor)SELECT * INTO TEMPORARY parcial_4FROM (select distinct (periodo), grid_stop, centergrid_lat, centergrid_lon, centergrid_gps from (parcial_3 inner join polygon_grid2ON parcial_3.grid_stop = polygon_grid2.id)) as foo5;

-- Update da tabela de cartões com os dados da parcial_4UPDATE public.urbs_card_raw_finalSET grid_stop = parcial_4.grid_stop, grid_stop_lat = parcial_4.centergrid_lat, grid_stop_lon= parcial_4.centergrid_lon, grid_stop_gps = parcial_4.centergrid_gpsFROM parcial_4WHEREurbs_card_raw_final.step_pass_card = '1/1' ANDurbs_card_raw_final.grid_stop IS NULL ANDurbs_card_raw_final.periodo = parcial_4.periodo AND(datautilizacao LIKE '31/10/16%' or datautilizacao LIKE '03/11/16%' or datautilizacao LIKE'04/11/16%' or datautilizacao LIKE '07/11/16%' ordatautilizacao LIKE '08/11/16%' or datautilizacao LIKE '09/11/16%' or datautilizacao LIKE'10/11/16%' or datautilizacao LIKE '11/11/16%');


discard temp;

--## Fazer o mesmo PARA OS DIAS DE FINAIS DE SEMANA (4 dias):select count(use), usefrom(select count (numerocartao) as use, numerocartao from urbs_card_raw_final wherestep_pass_card = '1/1'and (datautilizacao LIKE '29/10/16%' or datautilizacao LIKE '30/10/16%' or datautilizacaoLIKE '05/11/16%' or datautilizacao LIKE '06/11/16%')group by numerocartao)as foogroup by use order by use;

-- 74219;1-- 26987;2-- 6256;3-- 1591;4

select count(numerocartao) from urbs_card_raw_final where step_pass_card = '1/1' andgrid_stop IS NULLand (datautilizacao LIKE '29/10/16%' or datautilizacao LIKE '30/10/16%' or datautilizacaoLIKE '05/11/16%' or datautilizacao LIKE '06/11/16%'); --> 104.863

select * into temporary tmp1from(select num_tmpfrom(

92

select count (numerocartao) as use, numerocartao as num_tmp from urbs_card_raw_final wherestep_pass_card = '1/1'and (datautilizacao LIKE '29/10/16%' or datautilizacao LIKE '30/10/16%' or datautilizacaoLIKE '05/11/16%' or datautilizacao LIKE '06/11/16%')group by numerocartao)as foowhere use <> 4INTERSECTselect numerocartao from urbs_card_raw_final where step_pass_card <> '1/1'and (datautilizacao LIKE '29/10/16%' or datautilizacao LIKE '30/10/16%' or datautilizacaoLIKE '05/11/16%' or datautilizacao LIKE '06/11/16%') ) as foo2;

--## Copiar os valores do 1/2 se o bsstart_gps do 1/2 comparado ao bsstart_gps do 1/1 estiverem separados por menos de 2121 metros --(diagonal do quadrado formado pelos grids que considerei com os 8 adjacentes)

select * into temporary tmp2from(select * fromtmp1 inner join urbs_card_raw_final on numerocartao = num_tmp and step_pass_card <> '1/1'and (datautilizacao LIKE '29/10/16%' or datautilizacao LIKE '30/10/16%' or datautilizacaoLIKE '05/11/16%' or datautilizacao LIKE '06/11/16%')

) as foo;

update urbs_card_raw_final set grid_stop = tmp2.grid_stop, grid_stop_lat =tmp2.grid_stop_lat, grid_stop_lon = tmp2.grid_stop_lon, grid_stop_gps= tmp2.grid_stop_gpsfrom tmp2where urbs_card_raw_final.numerocartao=tmp2.num_tmp and urbs_card_raw_final.step_pass_card='1/1' and ST_DistanceSphere(urbs_card_raw_final.bsstart_gps, tmp2.bsstart_gps)<=2121and (tmp2.datautilizacao LIKE '29/10/16%' or tmp2.datautilizacao LIKE '30/10/16%' ortmp2.datautilizacao LIKE '05/11/16%' or tmp2.datautilizacao LIKE '06/11/16%');

-- ## Verificando quanto sobraram apos este processoselect count(*) from urbs_card_raw_final where grid_stop IS NULL and step_pass_card = '1/1'and (datautilizacao LIKE '29/10/16%' or datautilizacao LIKE '30/10/16%' or datautilizacaoLIKE '05/11/16%' or datautilizacao LIKE '06/11/16%') ;-->> 96.950 (ao inves dos 104.863 iniciais)

--## Desses aqui, utilizar outra heurística: considerar o destino "mais utilizado" pelos outros usuários que pegaram na mesma hora que ele.--discard temp;SELECT * INTO TEMPORARY parcial_1from (select foo.periodo, max (foo.count) as maxCountfrom (select periodo, grid_stop, count(grid_stop) as count from urbs_card_raw_finalwhere step_pass_card <> '1/1' and(datautilizacao LIKE '29/10/16%' or datautilizacao LIKE '30/10/16%' or datautilizacao LIKE'05/11/16%' or datautilizacao LIKE '06/11/16%')group by periodo, grid_stop)as foogroup by (foo.periodo)order by foo.periodo) as foo2;

SELECT * INTO TEMPORARY parcial_2from (select periodo, grid_stop, count(grid_stop) as count from urbs_card_raw_finalwhere step_pass_card <> '1/1' and(datautilizacao LIKE '29/10/16%' or datautilizacao LIKE '30/10/16%' or datautilizacao LIKE'05/11/16%' or datautilizacao LIKE '06/11/16%')group by periodo, grid_stopORDER BY periodo, count)as foo3;

SELECT * INTO TEMPORARY parcial_3FROM (SELECT parcial_1.periodo, parcial_2.grid_stopFROM(parcial_1 inner join parcial_2ONparcial_1.periodo = parcial_2.periodo AND parcial_1.maxCount = parcial_2.count)) as foo4;

93

--## Complementar em parcial_4 os valores de lat e lon do bsstop_num, grid_stop, grid_stop_lat, grid_stop_lon encontrados (antes de atualizar a base de cartões com tal valor)SELECT * INTO TEMPORARY parcial_4FROM (select distinct (periodo), grid_stop, centergrid_lat, centergrid_lon, centergrid_gps from (parcial_3 inner join polygon_grid2ON parcial_3.grid_stop = polygon_grid2.id)) as foo5;

-- Update da tabela de cartões com os dados da parcial_4UPDATE public.urbs_card_raw_finalSET grid_stop = parcial_4.grid_stop, grid_stop_lat = parcial_4.centergrid_lat, grid_stop_lon= parcial_4.centergrid_lon, grid_stop_gps = parcial_4.centergrid_gpsFROM parcial_4WHEREurbs_card_raw_final.step_pass_card = '1/1' ANDurbs_card_raw_final.grid_stop IS NULL ANDurbs_card_raw_final.periodo = parcial_4.periodo AND(datautilizacao LIKE '29/10/16%' or datautilizacao LIKE '30/10/16%' or datautilizacao LIKE'05/11/16%' or datautilizacao LIKE '06/11/16%');


discard temp;

94

95

ANEXO G -- SCRIPT R: CRIAR GRAFO DAS PRINCIPAIS LIGACOESORIGEM/DESTINO

library(ggmap)library(igraph)

#Leitura do CSV exportado da base SQL (com a matriz O/D)routes <- read.csv("C:/Users/Paulo/Google Drive/00_MESTRADO/00_Dados URBS/Dados_W43_44/OD_up_to_2_a_day_ALL_DAYS_29to11_OUTNOV_Gridnew.txt", sep=";")

Date='27/09/2016'

##----------- CONSIDERANDO ROUTES DO DIA TODO PARA PEGAR O TOP_OD --------------#### bsstart_num e bsstopnum são os IDs dos gridspontos1 <- cbind(routes$bsstart_num, routes$bsstart_lat, routes$bsstart_lon)pontos2 <- cbind(routes$bsstop_num, routes$bsstop_lat, routes$bsstop_lon)pontos <- rbind(pontos1, pontos2)pontos <- unique(pontos)colnames(pontos) <- c("bs_num","lat","lon")

## Criando o grafoODgraph = graph.data.frame(routes,vertices=pontos)E(ODgraph)$weight = routes$odweight#simplify removes self edges, synthesize duplicate edges (adding weights) AND put edges in ordem crescente do nó de partida!ODgraph = simplify(ODgraph)# Poderia utilizar a opção "concat": esta concatenate all edge attributes into a vector, this creates a complex attribute.# Porém aqui ele não faz a união dos edges somando os pesos!!# No modo padrão, todos os atributos dos edges são suprimidos nesta simplificação!!#ODgraph = simplify(ODgraph, edge.attr.comb="concat")

w = which(pontos[,1] %in% pontos[,1]) #considerar tudo!

G1 <- induced_subgraph(ODgraph,w)G1$layout = cbind(V(G1)$lon,V(G1)$lat)E(G1)$color = rgb(0,0,0,E(G1)$weight/(max(E(G1)$weight)))plot_vector1<- as.data.frame(cbind(V(G1)$lon,V(G1)$lat,degree(G1, V(G1), mode ='in'),degree(G1, V(G1), mode = 'out'), degree(G1, V(G1), mode = 'all')))colnames(plot_vector1) <- c("lon","lat","degIN","degOUT","degINOUT")

degV_IN1 <- as.data.frame(degree(G1, V(G1), mode = 'in'))colnames(degV_IN1) <- c("degIN")degV_OUT1 <- as.data.frame(degree(G1, V(G1), mode = 'out'))colnames(degV_OUT1) <- c("degOUT")degV_ALL1 <- as.data.frame(degree(G1, V(G1), mode = 'all'))colnames(degV_ALL1) <- c("degINOUT")

edgelist1 <- get.edgelist(G1)

edgelist1[,1]<-as.numeric(match(edgelist1[,1],V(G1)$name))edgelist1[,2]<-as.numeric(match(edgelist1[,2],V(G1)$name))

edges1 <- data.frame(plot_vector1[(V(G1)[as.numeric(edgelist1[,1])]),]$lon,plot_vector1[(V(G1)[as.numeric(edgelist1[,1])]),]$lat,plot_vector1[(V(G1)[as.numeric(edgelist1[,2])]),]$lon,plot_vector1[(V(G1)[as.numeric(edgelist1[,2])]),]$lat,E(G1)$color,degV_IN1[(V(G1)[as.numeric(edgelist1[,2])]),],degV_OUT1[(V(G1)[as.numeric(edgelist1[,1])]),])

colnames(edges1) <- c("X1","Y1","X2","Y2","Color", "degV_IN", "degV_OUT")

###### Montar o TOP X (200) de OD neste diatmp= as.data.frame(cbind(get.edgelist(ODgraph),E(ODgraph)$weight))tmp <- transform(tmp, V1 = as.character((V1)))tmp <- transform(tmp, V2 = as.character((V2)))tmp <- transform(tmp, V3 = as.numeric(as.character(V3)))top_OD = head(tmp[ order(-tmp[,3], tmp[,1], tmp[,2]), ], 200)colnames(top_OD) <- c("Orig","Dest","weight")

# Add lat/lon for each vertex (origin/destination)a= match(top_OD$Orig, pontos[,1])b= match(top_OD$Dest, pontos[,1])top_OD = cbind(top_OD, pontos[a,][,2],pontos[a,][,3], pontos[b,][,2],pontos[b,][,3])colnames(top_OD) <- c("Orig","Dest","weight", "Orig_lat","Orig_lon","Dest_lat","Dest_lon")

96

fileNameOUT <- paste("C:\\Users\\Paulo\\Google Drive\\00_MESTRADO\\00_Dados URBS\\Dados_W43_44\\TOP_OD_GRID_",gsub("/", "_", Date),"NEW.csv", sep="")write.csv(top_OD, file = fileNameOUT, row.names=FALSE)

##----------- FIM DA OBTENCAO DO TOP_OD PARA O DIA EM QUESTAO --------------##

97

98

ANEXO H -- SCRIPT SQL: CONFIRMAR AUSENCIA DE COBERTURA DIRETA

--##############################################################################################--## File 6: TOP_OD without lines--## Considering GRIDS only--## Reescrever a linhas shape com base no grid!!--##############################################################################################

--drop table TopOD_grid_table

CREATE TABLE TopOD_grid_table (Orig varchar,Dest varchar,weight varchar,Orig_lat double precision,Orig_lon double precision,Dest_lat double precision,Dest_lon double precision);--## IMPORT DATA FROM PGADMIN GUI (output from R - TOPOD)

--## Criar uma linha unindo Origem e Destino para poder apresentar no QGIS (utilizando objetos geométricos - point e line)DISCARD TEMP;ALTER TABLE public.TopOD_grid_table ADD COLUMN orig_gps geometry(POINT,4326);ALTER TABLE public.TopOD_grid_table ADD COLUMN dest_gps geometry(POINT,4326);UPDATE public.TopOD_grid_table SET orig_gps =ST_SetSRID(ST_MakePoint(orig_lon,orig_lat),4326);UPDATE public.TopOD_grid_table SET dest_gps =ST_SetSRID(ST_MakePoint(dest_lon,dest_lat),4326);ALTER TABLE public.TopOD_grid_table ADD COLUMN orig_dest_Linegps geometry(LINESTRING,4326);UPDATE public.TopOD_grid_table SET orig_dest_Linegps = ST_SetSRID(ST_Makeline(orig_gps,dest_gps),4326);

--## Acrescentar os geom dos polygon_grid2 na tabela TopOD_grid_table !--drop table tmp;select * into temporary tmpfrom (select tab1.geom as orig_grid_gps, tab2.geom as dest_grid_gps, TopOD_grid_table.*,ROW_NUMBER()OVER(PARTITION BY ORIG, DEST ORDER BY ORIG)as RNfrom TopOD_grid_tableinner join polygon_grid2 as tab1 on orig = tab1.idinner join polygon_grid2 as tab2 on dest = tab2.id) as foowhere rn=1;drop table TopOD_grid_table;select * into TopOD_grid_tablefrom(select * from tmp) as foo;

--## Criar tb um "orig_dest_Linegps" compondo cada linha como um conjunto de shapes (do grid!)--drop table LinhasShapeGrid_FromPontos;select line, sentido, ST_UNION(grid_gps) as line_Grid INTO LinhasShapeGrid_FromPontosfrom(select line, lat, lon, gps_position, sentido, grid, grid_gps, seq from bus_stops_table2order by line, sentido, CAST (seq AS numeric) ) as ordered_pointsgroup by line, sentido

--## Agora, de fato comparar se temos OD cobertos pela mesma linha (de um ponto de vista dos grids)--## Ver se tenha alguma linha "próxima" tanto da origem como do destino--drop table TopOD_grid_withlines;Select * into temporary TopOD_grid_withlinesfrom (select distinct (line), orig,dest,orig_gps, dest_gps,orig_dest_Linegps, orig_grid_gps,dest_grid_gpsfrom TopOD_grid_table cross join LinhasShapeGrid_FromPontoswhere (ST_Contains(line_grid, orig_grid_gps)) and (ST_Contains(line_grid, dest_grid_gps))order by line) foo;

--## Para quais pares não foram achados nenhuma linha???--## Colocar numa nova tabela (para facilitar visualização no QGIS)

99

-- drop table TopOD_grid_filteredselect * into TopOD_grid_filteredfrom (select orig, dest, orig_grid_gps, dest_grid_gps, orig_dest_linegps from TopOD_grid_tableEXCEPTselect orig, dest, orig_grid_gps, dest_grid_gps, orig_dest_linegps from TopOD_grid_withlines) as foo;-- select * from TopOD_grid_filtered; > 55 possiveis pares!!

--## ********** Nestes que deram no resultado, é preciso verificar se não existiria uma linha que ligue diretamente um dos 8 grids adjacentes a origem ou ao destino--## ESTA PARTE ESTÁ IMPLEMENTADA EM PYTHON ##

100

101

ANEXO I -- SCRIPT PYTHON: CONFIRMAR AUSENCIA DE COBERTURA DIRETA



## ****************** ENCONTRAR REAIS OD SEM COBERTURA DIRETA ***********************#### Para cada um dos candidatos a OD sem cobertura (TopOD_grid_filtered), verificar se nenhuma das 8 grids adjacentes não teria## uma linha cobrindo as duas localidades (eliminando assim o erro inicial de definição do ponto)## Nesta caso, teríamos uma garantia suficiente que não existe mesmo uma linha fazendo ligação direta entre os dois pontos!

##1 - Obter os candidatos a OD sem coberturaquery = """SELECT *FROM TopOD_grid_filtered;"""cur.execute(query)conn.commit()

rowsOD_Candidatos = cur.fetchall()

print (len(rowsOD_Candidatos))

orig_tmp=''dest_tmp=''i=0

for row in rowsOD_Candidatos:orig_tmp=row[0]dest_tmp = row[1]if i>0:

query = """ drop table tmp; drop table tmp2; """

cur.execute(query)conn.commit()

#print (str(orig_tmp) + '_'+ str(dest_tmp))#print(i)query = """

select * into temporary tmp from ( (select id as orig, geom as orig_grid_gps from polygon_grid2 cross join TopOD_grid_filtered where (ST_Touches(orig_grid_gps, geom) or ST_Contains(orig_grid_gps, geom)) and orig =

'"""+orig_tmp+"""' and dest = '"""+dest_tmp+"""') as a cross join (select id as dest, geom as dest_grid_gps from polygon_grid2 cross join TopOD_grid_filtered where (ST_Touches(dest_grid_gps, geom) or ST_Contains(dest_grid_gps, geom)) and orig =

'"""+orig_tmp+"""' and dest = '"""+dest_tmp+"""') as b ) as foo;

Select * into temporary tmp2 from ( select distinct(line), orig, dest, orig_grid_gps, dest_grid_gps

-

102

from tmp cross join LinhasShapeGrid_FromPontos where(ST_Contains(line_grid, orig_grid_gps)) and (ST_Contains(line_grid, dest_grid_gps)) order by line ) foo; select count(*) from tmp2; """


LinesFound = cur.fetchall()#print (LinesFound[0][0])

if LinesFound[0][0]==0:## Meaning that we found something at tmp2 (otherwise, LinesFound would have something different from zero! ## teríamos achado ao menos uma linha cobrindo ao mesmo tempo um par de grids adjacentes a origem e ao destino considerado)print('VÁLIDOS: '+str(orig_tmp) + '->' + str(dest_tmp))

i=i+1

-

103

104

ANEXO J -- SCRIPT SQL: IMPLEMENTAR SERVICOS TELEMATICOS

--##############################################################################################--## File 7: Bus usage estimation--## Complementar a parte dos ônibus (estimar o horário da descida do ônibus)--## Através do bsstart e bsstop, inferir o horário que a pessoa deve ter descido!--##############################################################################################

--## Criar nova base, utilizando todos os dias obtidos (semana e fim de semana) para a linha do Sta Barbara (461) - como prova de conceito..SELECT * INTO Teste_StaBarbaraFROM(select * from URBS_CARD_raw_FINALwhere URBS_CARD_raw_FINAL.codlinha = '461'

) AS foo;

SELECT * INTO GPS_Teste_StaBarbaraFROM(select * from period_bus_gps2_completewhere period_bus_gps2_complete.linha = '461'

) AS foo;

ALTER TABLE public.GPS_Teste_StaBarbara ADD COLUMN gps_position geometry(POINT,4326);UPDATE public.GPS_Teste_StaBarbara SET gps_position = ST_SetSRID(ST_MakePoint(lon,lat),4326);ALTER TABLE public.GPS_Teste_StaBarbara ADD COLUMN HomogeneousDateTime TIMESTAMP;UPDATE public.GPS_Teste_StaBarbara SET HomogeneousDateTime = cast((left(scriptdate,11)||hora) as timestamp);

-- Rodar PYTHON para calcular horário de descida e tempo de permanência estimado

-- Para os que obtivemos valores criar uma lista com a ocupação de cada par linha/veiculo para cada hora (buscar identificar os pontos tb)-- fazendo um balanço de qts subiram e qts desceram daquele onibus (naquela linha) naquele horario-- fazer para cada dia individualmente!!

DISCARD TEMP;

SELECT * INTO TEMPORARY ContagemSubidaFROM(select codlinha, codveiculo, bsstart_num as ponto, SUBSTRING(datautilizacao,10, 2) ashoraSobe, count(numerocartao) as ctrSubidafrom Teste_StaBarbarawhere datautilizacao LIKE '11/11/16%' and step_pass_card<>'1/1'group by codlinha, codveiculo,bsstart_num, horaSobeorder by codlinha, codveiculo,bsstart_num, horaSobe) as foo1;

SELECT * INTO TEMPORARY ContagemDescidaFROM(select codlinha, codveiculo, bsstop_num as ponto, LEFT(horadescida, 2) as horaDesce ,count(numerocartao) as ctrDescidafrom Teste_StaBarbarawhere datautilizacao LIKE '11/11/16%' and step_pass_card<>'1/1'group by codlinha, codveiculo,bsstop_num, horaDesceorder by codlinha, codveiculo,bsstop_num, horaDesce) as foo2;

-- Desta forma teremos o registro na tabela final apenas caso tenhamos gente subindo e descendo na mesma hora.-- Horas onde so sobem ou so descem são perdidas se pararmos aqui!

SELECT * INTO temporary ContagemOnibusHora_subidaFROM(SELECT ContagemSubida.codlinha, ContagemSubida.codveiculo,ContagemSubida.ponto,ContagemSubida.horasobe as hora, ContagemSubida.ctrSubida, ContagemDescida.ctrDescida,

105

((CASE WHEN (ContagemSubida.ctrsubida IS NULL) THEN 0 ELSE ContagemSubida.ctrsubida END) -CASE WHEN (ContagemDescida.ctrdescida IS NULL) THEN 0 ELSE ContagemDescida.ctrdescida END)as deltapeoplefrom ContagemSubida full outer join ContagemDescidaON ((ContagemSubida.codlinha = ContagemDescida.codlinha)and (ContagemSubida.codveiculo = ContagemDescida.codveiculo)and (ContagemSubida.ponto = ContagemDescida.ponto)and (ContagemSubida.horaSobe = ContagemDescida.horaDesce))order by codlinha, codveiculo, ponto, hora) as foo3;

SELECT * INTO temporary ContagemOnibusHora_descidaFROM(SELECT ContagemDescida.codlinha, ContagemDescida.codveiculo, ContagemDescida.ponto,ContagemDescida.horadesce as hora, ContagemSubida.ctrSubida,ContagemDescida.ctrDescida,((CASE WHEN (ContagemSubida.ctrsubida IS NULL) THEN 0 ELSE ContagemSubida.ctrsubida END) -CASE WHEN (ContagemDescida.ctrdescida IS NULL) THEN 0 ELSE ContagemDescida.ctrdescida END)as deltapeoplefrom ContagemDescida full outer join ContagemSubidaON ((ContagemSubida.codlinha = ContagemDescida.codlinha)and (ContagemSubida.codveiculo = ContagemDescida.codveiculo)and (ContagemSubida.ponto = ContagemDescida.ponto)and (ContagemSubida.horaSobe = ContagemDescida.horaDesce))order by codlinha, codveiculo,ponto, hora) as foo4;

-- Tablea com a contagem final correta para o 461 (fazendo por dia, individualmente)select * into temporary ContagemOnibusHora from(select * from ContagemOnibusHora_subida where codlinha IS NOT NULLUNIONselect * from ContagemOnibusHora_descida where codlinha IS NOT NULL)as foo5;

select codveiculo,hora,sum(ctrsubida) as subida,sum(ctrdescida) as descida,sum(deltapeople)as delta from ContagemOnibusHora group by codveiculo,hora order by codveiculo,hora ;select ponto,hora,sum(ctrsubida) as subida,sum(ctrdescida) as descida,sum(deltapeople) asdelta from ContagemOnibusHora group by ponto,hora order by ponto,hora ;select hora,sum(ctrsubida) as subida,sum(ctrdescida) as descida,sum(deltapeople) as deltafrom ContagemOnibusHora group by hora order by hora ;

--## MAINTENANCE ALERT REMINDER-- Estimar a KM rodada por cada veiculo-- Fazer a soma das distâncias percorridas a cada 2 minutos (entre duas posições GPS). O erro é pequeno mesmo sendo "em vôo de pássaro" entre essas duas posições-- a) obter a lista de veículos únicos que temos na base de GPS-- b) ordená-los por ordem cronológica e calcular a diferença de espaço (deltaD)-- c) somar cada trecho para cada veículo (somando ao valor inicial!!)-- d) Por fim, bastaria definir os limites considerados importantes para a revisão!!

SELECT * INTO ConnectedServices_FullFrotaFROM(select * from Period_BUS_GPS2_COMPLETEwhere scriptdate NOT LIKE '2016-11-01%' and scriptdate NOT LIKE '2016-11-02%'order by prefixo, homogeneousdatetime

) AS foo;

-- Acrescentar colunas que conterão o deltaD e deltaT comparado a medida anterior, bem como o speed (que é a divisão de um pelo outro)ALTER TABLE ConnectedServices_FullFrota ADD COLUMN deltaD double precision;ALTER TABLE ConnectedServices_FullFrota ADD COLUMN deltaT interval;ALTER TABLE ConnectedServices_FullFrota ADD COLUMN speed double precision;ALTER TABLE ConnectedServices_FullFrota ADD COLUMN id SERIAL PRIMARY KEY;--Colocar uma coluna de ID para facilitar a próxima tarefa

--Preenchendo km e deltatUPDATE ConnectedServices_FullFrotaSET deltad = ST_DistanceSphere(b.gps_position, a.gps_position) , deltat =

106

b.homogeneousdatetime - a.homogeneousdatetimeFROMConnectedServices_FullFrota as a cross join ConnectedServices_FullFrota as bwhere ConnectedServices_FullFrota.id = b.id and b.id= a.id+1 and a.prefixo = b.prefixo;

--Agora a velocidade (em km/h)UPDATE ConnectedServices_FullFrotaSET speed = ((deltad / abs( extract( second from deltat ) + extract( minute from deltat ) *60 + extract( hour from deltat ) * 60 * 60 + extract( day from deltat ) * 60 * 60 * 24)))*3.6where abs( extract( second from deltat ) + extract( minute from deltat ) * 60 + extract(hour from deltat ) * 60 * 60 + extract( day from deltat ) * 60 * 60 * 24) <> 0;

select sum(deltad),prefixo from ConnectedServices_FullFrota group by prefixo;

-- Apenas dias de semanaselect sum(deltad),prefixo from ConnectedServices_FullFrota where scriptdate NOT LIKE'2016-10-29%' andscriptdate NOT LIKE '2016-10-30%' and scriptdate NOT LIKE '2016-11-05%' and scriptdate NOTLIKE '2016-11-06%'group by prefixo;

-- ## AVERAGE SPEED de algumas linhas-- Fazer exemplo para as seguintes linhas:-- Convencional: 461-- Interbairros: 040-- Expresso: 203-- Ligeirinho: 256-- Alimentador: 225-- Troncal: 372-- Ligeirão : 550

SELECT * INTO Teste_ConnectedServices_AvgSpeedFROM(select * from Period_BUS_GPS2_COMPLETEwhere Period_BUS_GPS2_COMPLETE.linha = '461' or Period_BUS_GPS2_COMPLETE.linha = '040' orPeriod_BUS_GPS2_COMPLETE.linha = '203' or Period_BUS_GPS2_COMPLETE.linha = '256' orPeriod_BUS_GPS2_COMPLETE.linha = '225' or Period_BUS_GPS2_COMPLETE.linha = '372' orPeriod_BUS_GPS2_COMPLETE.linha = '550'and scriptdate NOT LIKE '2016-11-01%' and scriptdate NOT LIKE '2016-11-02%'order by prefixo, homogeneousdatetime

) AS foo;

-- Acrescentar colunas que conterão o deltaD e deltaT comarado a medida anterior, bem como o speed (que é a divisão de um pelo outro)ALTER TABLE Teste_ConnectedServices_AvgSpeed ADD COLUMN deltaD double precision;ALTER TABLE Teste_ConnectedServices_AvgSpeed ADD COLUMN deltaT interval;ALTER TABLE Teste_ConnectedServices_AvgSpeed ADD COLUMN speed double precision;ALTER TABLE Teste_ConnectedServices_AvgSpeed ADD COLUMN id1 SERIAL PRIMARY KEY;--Colocar uma coluna de ID para facilitar a próxima tarefa

--Preenchendo km e deltatUPDATE Teste_ConnectedServices_AvgSpeedSET deltad = ST_DistanceSphere(b.gps_position, a.gps_position) , deltat =b.homogeneousdatetime - a.homogeneousdatetimeFROMTeste_ConnectedServices_AvgSpeed as a cross join Teste_ConnectedServices_AvgSpeed as bwhere Teste_ConnectedServices_AvgSpeed.id1 = b.id1 and b.id1= a.id1+1 andTeste_ConnectedServices_AvgSpeed.prefixo = b.prefixo and b.prefixo= a.prefixo;

--Agora a velocidade (em km/h)UPDATE Teste_ConnectedServices_AvgSpeedSET speed = ((deltad / abs( extract( second from deltat ) + extract( minute from deltat ) *60 + extract( hour from deltat ) * 60 * 60 + extract( day from deltat ) * 60 * 60 * 24)))*3.6where abs( extract( second from deltat ) + extract( minute from deltat ) * 60 + extract(hour from deltat ) * 60 * 60 + extract( day from deltat ) * 60 * 60 * 24) <> 0;

--Acrescentar a info de periodo para facilitar a visualizaçõão por periodo (hora) do diaALTER TABLE Teste_ConnectedServices_AvgSpeed ADD COLUMN periodo varchar;UPDATE Teste_ConnectedServices_AvgSpeedset periodo = SUBSTRING(scriptdate,12,2);--Ajustar tb o deltaT que é tipo "interval". Este tipo não é suportado no QGIS, logo, vou

107

coloca-lo como inteiro e o valor do intervalo em segundosALTER TABLE Teste_ConnectedServices_AvgSpeed ADD COLUMN deltat_sec double precision;UPDATE Teste_ConnectedServices_AvgSpeed set deltat_sec = abs( extract( second from deltat )+ extract( minute from deltat ) * 60 + extract( hour from deltat ) * 60 * 60 + extract( dayfrom deltat ) * 60 * 60 * 24);

-- Acrescentar a info sobre o GRID que cada posição faz parte.. desta forma, sera possível visualizar a velocidade média também por região da linha--## Acrescentar coluna em bus_stops_table2 com a info de em qual grid tal ponto estaALTER TABLE public.Teste_ConnectedServices_AvgSpeed ADD COLUMN grid character varying;ALTER TABLE public.Teste_ConnectedServices_AvgSpeed ADD COLUMN grid_gpsgeometry(MULTIPOLYGON,4326);

select * into temporary tmp2from(select * from(select *, ST_Contains(geom, gps_position) as status from Teste_ConnectedServices_AvgSpeedcross join polygon_grid2) as foowhere status= TRUE) as foo2;

UPDATE tmp2 SET grid = id;UPDATE tmp2 SET grid_gps = geom;ALTER TABLE tmp2 DROP COLUMN gid;ALTER TABLE tmp2 DROP COLUMN id;ALTER TABLE tmp2 DROP COLUMN geom;ALTER TABLE tmp2 DROP COLUMN centergrid_gps;ALTER TABLE tmp2 DROP COLUMN centergrid_lat;ALTER TABLE tmp2 DROP COLUMN centergrid_lon;ALTER TABLE tmp2 DROP COLUMN status;

drop table Teste_ConnectedServices_AvgSpeed;select * into Teste_ConnectedServices_AvgSpeedfrom(select * from tmp2) as foo;

-- Calculando a media das velocidades por linha (apenas quando velocidade < 200.. que seriam valores mais coerentes)

select * into Teste_ConnectedServices_AvgSpeed_byGRIDfrom(select linha, grid,grid_gps, avg(speed)from Teste_ConnectedServices_AvgSpeedwhere speed < 200group by linha,grid,grid_gpsorder by linha, grid) as foo2;

COPY(SELECT homogeneousdatetime, prefixo, linha, deltad, deltat_sec, speedFROM Teste_ConnectedServices_AvgSpeed order by id)TO 'C:/Users/Paulo/Google Drive/00_MESTRADO/00_Dados URBS/Dados_W43_44/Raw_Final_StatisticsAVERAGE.csv' DELIMITER ';' ENCODING 'LATIN10' CSVHEADER;

108

109

ANEXO K -- SCRIPT PYTHON: IMPLEMENTAR SERVICOS TELEMATICOS



### ***PASSO 4: ESTIMAR HORARIO DE DESCIDA DO PONTO E TEMPO DE PERMANÊNCIA NOS ÔNIBUS. Para cada linha da base de cartões:### 0) Criar uma extração da base de cartões apenas com 1/1, 1/2 e 2/2 (tabela temporaria - OD1_2_only_tmp) - sem considerar os TT, ja que não da pra saber que onibus pegou exatamente!### 1) Criar uma tmp table com a linha da tabela de cartões (tmpcard)### 2) Fazer query obtendo as posições dos ônibus, a deltaDIST (do gps do ônibus e da bsstop) e a deltaTIME (apenas os positivos). Ordernar a resposta por homogeneousdatetime### 3) Buscar o primeiro mínimo no deltaDIST(n-1>n<n+1). Esse é o que buscamos!!### 4) Update base de cartão com estes dados### 5) Drop tmp table e pego a próxima linha da OD1_2_only_tmp### 0.1) Drop OD1_2_only_tmp

query = """SELECT * INTO TEMPORARY OD1_2_only_tmpFROM (SELECT *FROM public.Teste_StaBarbaraWHERE (Teste_StaBarbara.STEP_PASS_CARD <> '1/1' ) ) as foo1;

SELECT * FROM OD1_2_only_tmp ;"""

cur.execute(query)conn.commit()rowsUrbs_Cards = cur.fetchall()

i=0for row in rowsUrbs_Cards:

i=i+1#print (i)#print(row)query = """

SELECT * INTO TEMPORARY tmpcard FROM ( SELECT * FROM OD1_2_only_tmp WHERE (codlinha = '"""+str(row[0])+"""' and nomelinha = '"""+str(row[1])+"""' and codveiculo = '"""+str(row[2])+"""' and numerocartao = '"""+str(row[3])+"""' and datautilizacao = '"""+str(row[4])+"""' and step_pass_card = '"""+str(row[5])+"""' and homogeneousdatetime = '"""+str(row[6])+"""') )as foo1 ;"""


query = """ SELECT tmpcard.numerocartao, tmpcard.datautilizacao, tmpcard.step_pass_card,

GPS_Teste_StaBarbara.prefixo, GPS_Teste_StaBarbara.linha, GPS_Teste_StaBarbara.homogeneousdatetime, GPS_Teste_StaBarbara.hora,

(ST_DistanceSphere(tmpcard.bsstop_gps, GPS_Teste_StaBarbara.gps_position)) as dist_dif, (GPS_Teste_StaBarbara.homogeneousdatetime - tmpcard.homogeneousdatetime) as time_dif FROM tmpcard INNER JOIN GPS_Teste_StaBarbara ON(GPS_Teste_StaBarbara.linha =

tmpcard.codlinha and GPS_Teste_StaBarbara.prefixo = tmpcard.codveiculo) WHERE ( (EXTRACT(DAY FROM tmpcard.homogeneousdatetime) = EXTRACT(DAY FROM

GPS_Teste_StaBarbara.homogeneousdatetime)) and (GPS_Teste_StaBarbara.homogeneousdatetime - tmpcard.homogeneousdatetime) > '00:00:00')

110

order by homogeneousdatetime ;"""

cur.execute(query)conn.commit()rows_TMPCard = cur.fetchall()

n_minus_1 = ''n=''time=''time_n_minus_1=''timeDIF=''time_DIF_n_minus_1 = ''n_plus_1 = ''found =0for row2 in rows_TMPCard:

#print(row2)# deltaTIME is row[8] ; deltaDIST is row[7]# need to find the first MINIMUM: when "n_minus_1" > row[7] < "n_plus_1"if (n_minus_1 == ''):

n_minus_1=float(row2[7])time_n_minus_1 =row2[6]time_DIF_n_minus_1 = row2[8]

elif (n == ''):n = float(row2[7])time=row2[6] #homogeneousdatetimefrom bustimeDIF=row2[8] #permanencia

elif (n_plus_1==''):n_plus_1=float(row2[7])#print("n-1= " + str(n_minus_1) + " n= " + str(n) + " n+1= " + str(n_plus_1) )## considerar pelo menos dois minutos dentro do ônibus!!(timeDIF é um datetime.timedelta type..if (n_minus_1 >= n and n < n_plus_1 and timeDIF >= datetime.timedelta(minutes=2)):

#We found!!! Update cards tablefound=1query = """

UPDATE Teste_StaBarbara SET horadescida= '""" + str(time) + """' , permanencianoonibus= '""" +

str(timeDIF) + """', DistDifVERIFY_descida= '""" + str(n) + """' WHERE (codlinha= '""" + str(row2[4]) + """' and codveiculo= '""" + str(row2[3]) + """' and numerocartao= '""" + str(row2[0]) + """' and datautilizacao= '""" + str(row2[1]) + """' and step_pass_card= '""" + str(row2[2]) + """') ;"""

cur.execute(query)conn.commit()break

else:#need to clean n+1 and change values of n-1 and nn_minus_1=ntime_n_minus_1 = timetime_DIF_n_minus_1 = time

n=n_plus_1time = row2[6]timeDIF = row2[8]n_plus_1=''

if (found==0):print ("we didn't find nothing!!" + str(i))#print(row)## Sometimes, there is not enough data for compute minimum. In this case, we will get here and we will consider the minimum of n-1 and n#print ("n= "+ str(n)+" and n-1= "+ str(n_minus_1))no_answer=0if (n=='' and n_minus_1!=''):

#to be sure it will be something wrong!n='9999999999999999999999999999999999999999'

elif (n_minus_1==''and n!=''):#to be sure it will be something wrong!

111

n_minus_1='9999999999999999999999999999999999999999'elif (n_minus_1==''and n==''):

n ='0'n_minus_1='0'no_answer=1

if ((float(n_minus_1) <= float(n)) and no_answer==0):#print ("do we get here!?")#print (row2)#n_minus_1 is the smallest valuequery = """

UPDATE Teste_StaBarbara SET horadescida= '""" + str(time_n_minus_1) + """' , permanencianoonibus= '""" +

str(time_DIF_n_minus_1) + """', DistDifVERIFY_descida= '""" + str(n_minus_1) +"""'

WHERE (codlinha= '""" + str(row2[4]) + """' and codveiculo= '""" + str(row2[3]) + """' and numerocartao= '""" + str(row2[0]) + """' and datautilizacao= '""" + str(row2[1]) + """' and step_pass_card= '""" + str(row2[2]) + """') ;"""


if ((float(n) < float(n_minus_1)) and no_answer == 0):#n is the smalest one#print("do we get here!? 2")#print(row2)query = """

UPDATE Teste_StaBarbara SET horadescida= '""" + str(time) + """' , permanencianoonibus= '""" +

str(timeDIF) + """', DistDifVERIFY_descida= '""" + str(n) + """' WHERE (codlinha= '""" + str(row2[4]) + """' and codveiculo= '""" + str(row2[3]) + """' and numerocartao= '""" + str(row2[0]) + """' and datautilizacao= '""" + str(row2[1]) + """' and step_pass_card= '""" + str(row2[2]) + """') ;"""


query = """ DROP TABLE tmpcard ;"""


query = """DROP TABLE OD1_2_only_tmp;"""cur.execute(query)conn.commit()

112

113

ANEXO L -- TIPOS E CAPACIDADES DOS ONIBUS DE CURITIBA

UNIVERSIDADE TECNOLOGICA FEDERAL DO PARAN´ A´...

Documents

Transcript of UNIVERSIDADE TECNOLOGICA FEDERAL DO PARAN´ A´...