View
214
Download
0
Category
Preview:
Citation preview
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.
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).
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.
# ***************** 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
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
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
--## 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
--##############################################################################################--## 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
--## 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%');
drop table parcial_1;drop table parcial_2;drop table parcial_3;drop table parcial_4;
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%');
drop table parcial_1;drop table parcial_2;drop table parcial_3;drop table parcial_4;
discard temp;
94
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
--##############################################################################################--## 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
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()
## ****************** 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; """
cur.execute(query)conn.commit()
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
--##############################################################################################--## 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
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()
### ***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 ;"""
cur.execute(query)conn.commit()
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]) + """') ;"""
cur.execute(query)conn.commit()
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]) + """') ;"""
cur.execute(query)conn.commit()
query = """ DROP TABLE tmpcard ;"""
cur.execute(query)conn.commit()
query = """DROP TABLE OD1_2_only_tmp;"""cur.execute(query)conn.commit()
112
Recommended