Serviços telemáticos em uma rede de transporte público baseados em veículos conectados e dados abertos

(1)

PROGRAMA DE P ´

OS-GRADUAC

¸ ˜

AO EM ENGENHARIA EL ´

ETRICA E

INFORM ´

ATICA INDUSTRIAL

PAULO CARVALHO DINIZ JUNIOR

SERVIC

¸ OS TELEM ´

ATICOS EM UMA REDE DE TRANSPORTE

P ´

UBLICO BASEADOS EM VE´ICULOS CONECTADOS E DADOS

ABERTOS

DISSERTAC

¸ ˜

AO

CURITIBA 2017

(2)

SERVIC

¸ OS TELEM ´

ATICOS EM UMA REDE DE TRANSPORTE

P ´

UBLICO BASEADOS EM VE´ICULOS CONECTADOS E DADOS

ABERTOS

Dissertação apresentada ao Programa de Pós-graduação em Engenharia Elétrica e Informática Industrial da Universidade Tecnológica Federal do Paraná como requisito parcial para obtenção do grau de “Mestre em Ciências” – Área de Concentração: Engenharia da Computação.

Orientador: Heitor Silv´erio Lopes

CURITIBA 2017

(3)

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

(4)

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.

(5)

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 último financiado pela VINNOVA (Agência Governamental para Sistemas Inovadores) na Suécia, liderados pelo KTH Royal Institute of Technology e envolvendo os seguintes parceiros suecos e brasileiros: Universidade Tecnológica Federal do Paraná (UTFPR), Volvo Bus Corporation, Combitech, URBS (Urbanização de Curitiba S.A.) e a prefeitura de Curitiba.

O autor gostaria de agradecer imensamente também ao suporte, resiliência, atenção e paciência do orientador Heitor Silvério Lopes e da professora Keiko Fonseca. Além da ajuda e contribuição essenciais de Daniel Guerra Diniz, Leonardo Presoto de Oliveira e Kelly Trefflich.

(6)

(7)

CARVALHO DINIZ JUNIOR, Paulo. SERVIÇ OS TELEM ÁTICOS EM UMA REDE DE TRANSPORTE P ÚBLICO BASEADOS EM VEÍCULOS CONECTADOS E DADOS ABERTOS. 114 f. Dissertação – Programa de Pós-graduação em Engenharia Elétrica e Informática Industrial, Universidade Tecnológica Federal do Paraná. Curitiba, 2017.

Um conceito bastante em voga atualmente é o de cidades inteligentes. Ele define um tipo de desenvolvimento urbano capaz de reduzir os impactos ambientais, melhorando os modelos atuais de acesso a recursos naturais, transportes, gestão do lixo, climatização residencial e sobretudo a gestão da energia (produção e distribuição).

O massivo volume de dados produzidos por cidades inteligentes oferece uma grande oportunidade para analisar, compreender e melhorar o modo como elas funcionam e se desenvolvem. Esta explosão na quantidade de informações tem elevado a importância do aprendizado a partir de dados a um patamar extremamente elevado.

Esta dissertação tem por objetivo descrever uma metodologia para aquisição e exploração de dados de um dos mais importantes pilares de cidades inteligentes: o sistema de transporte público. Como obter, armazenar e utilizar tais dados a fim de prover a todos os envolvidos, serviços telemáticos de alto valor agregado é o problema que se busca resolver neste trabalho. Cinco serviços telemáticos são propostos sob forma de prova de conceito: avaliação da cobertura da rede de transporte atual, seguida de uma proposta de novas linhas de ônibus; avaliação indireta da ocupação diária dos ônibus da cidade; cerca-eletrônica com os limites geográficos definidos pelos itinerários das linhas; serviços de alerta de velocidade e de manutenção.

Os resultados s˜ao bastante coerentes e promissores, abrindo um grande leque de poss´ıveis trabalhos futuros a serem explorados.

Palavras-chave: Serviços telemáticos, dados abertos, transporte público, matriz origem-destino

(8)

CARVALHO DINIZ JUNIOR, Paulo. TELEMATICS SERVICES IN A PUBLIC TRANSPORTATION NETWORK BASED ON CONNECTED VEHICLES AND OPEN DATA. 114 f. Dissertação – Programa de Pós-graduação em Engenharia Elétrica e Informática Industrial, Universidade Tecnológica Federal do Paraná. Curitiba, 2017.

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

The huge data volume produced by smart cities offers a great opportunity to analyze, understand and improve the way cities work and grow. This explosion in the amount of digital information has 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 of the 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 high added value is the problem that is sought to solve in this work.

Five telematics services proof of concept are proposed: assessment of current network coverage followed by the proposal of some new bus lines; indirect evaluation of buses’ passengers occupation 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 work to be explored.

(9)

–

FIGURA 1 Exemplo de estac¸˜ao tubo. . . 14 –

FIGURA 2 Vis˜ao geral da metodologia proposta. . . 25 –

FIGURA 3 Diagrama de relacionamento entre as diversas bases de dados criadas. . . . 28 –

FIGURA 4 Vis˜ao geral da grade quadricular sobre a cidade de Curitiba. . . 31 –

FIGURA 5 Exemplo de inferˆencia do ponto de desembarque - parte 1. . . 34 –

FIGURA 9 Configurações do QGIS para produção dos mapas de calor. . . 39 –

FIGURA 10 Servic¸os Telem´aticos propostos. . . 40 –

FIGURA 11 Grades consideradas na busca por linhas diretas cobrindo os principais pares origem-destino. . . 41 –

FIGURA 12 Vis˜ao detalhado da metodologia proposta. . . 46 –

FIGURA 13 Extração da base de utilização dos cartões. . . 48 –

FIGURA 14 Extração da base de pontos de ônibus. . . 48 –

FIGURA 15 Extração da base de percurso do itinerário das linhas. . . 49 –

FIGURA 16 Extração da base contendo a posição GPS de todos os ônibus da rede. . . . 49 –

FIGURA 17 Extrac¸˜ao da base contendo o detalhe sobre os pontos do tipo tubo ou terminais. . . 49 –

FIGURA 18 Histograma de utilização dos cartões de transporte no per´ıodo considerado. 50 –

FIGURA 19 Histograma de utilização dos cartões de transporte para um único dia. . . . 50 –

FIGURA 20 As 15 linhas e ve´ıculos mais utilizados segundo a base de cart˜oes. . . 51 –

FIGURA 21 Exemplo de ˆonibus t´ıpico da rede de Curitiba. . . 51 –

FIGURA 22 Quantidade de dados de utilização dos cartões de transporte resultante dos processos de limpeza dos dados. . . 53 –

FIGURA 23 Quantidade de utilização de um mesmo cartão por dia. . . 54 –

FIGURA 24 Exemplo de grade incluindo diversos pontos de ˆonibus. . . 55 –

FIGURA 25 Tentativa de visualizac¸˜ao do grafo de origem-destino completo. . . 56 –

FIGURA 26 Visualização do grafo de origem-destino considerando as mil ligações mais importantes. . . 57 –

FIGURA 27 Exemplos de mapa de calor utilizando R e GoogleMaps. . . 58 –

FIGURA 28 Concentrac¸˜ao dos principais pontos de origem e destino de passageiros -Dias de semana. . . 58 –

FIGURA 29 Concentrac¸˜ao 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 ligação com alta utilização mas sem cobertura direta por alguma linha existente. . . 62

(10)

para a linha 461. . . 64 –

FIGURA 36 Exemplo de servic¸o de cerca eletrˆonica. . . 68 –

FIGURA 37 Exemplo de servic¸o de alerta de velocidade. . . 69 –

FIGURA 38 Exemplo de serviço de avaliação da velocidade média da linha. . . 69 –

FIGURA 39 Exemplo de serviço de avaliação da velocidade média em diversos trechos da linha. . . 70 –

(11)

–

TABELA 1 Principais entradas e sa´ıdas da etapa “Obtenc¸˜ao e Armazenamento dos dados” . . . 26 –

TABELA 2 Principais entradas e sa´ıdas da etapa “Limpeza e Preparac¸˜ao dos dados” . . 29 –

TABELA 3 Principais entradas e sa´ıdas da etapa “Associação dos dados de GPS às informações de utilização dos cartões” . . . 31 –

TABELA 4 Principais entradas e sa´ıdas da etapa “Estimação do Ponto de Desembarque de cada usuário” . . . 33 –

TABELA 5 Principais entradas e sa´ıdas da etapa “Criação e Visualização da Matriz de Origem-Destino” . . . 36 –

TABELA 6 Principais entradas e sa´ıdas da etapa “Oferta de pacote de Servic¸os Telem´aticos” . . . 39 –

TABELA 7 Quantidade de dados obtidas durante o per´ıodo considerado. . . 48 –

TABELA 8 Associac¸˜ao entre cod urbs e os quinze terminais e tubos mais utilizados. . 52 –

TABELA 9 Dispersão na definição da posição GPS de passagem do cartão. . . 55 –

TABELA 10 Dispersão do tempo médio de permanência dos passageiros na linha 461. . 63 –

(12)

1 INTRODUC¸ ˜AO . . . 12

1.1 SISTEMA DE TRANSPORTE P ´UBLICO DE CURITIBA . . . 13

1.2 CIDADES INTELIGENTES E DADOS ABERTOS . . . 15

1.3 VEÍCULOS CONECTADOS E SERVIÇ OS TELEM ÁTICOS . . . 16

1.4 OBJETIVOS . . . 17

1.5 ESTRUTURA DA DISSERTAC¸ ˜AO . . . 18

2 REVIS ˜AO BIBLIOGR ´AFICA . . . 19

2.1 TRABALHOS CORRELATOS . . . 19

2.2 FERRAMENTAS UTILIZADAS . . . 22

2.2.1 Python . . . 22

2.2.2 Web-services e R . . . 22

2.2.3 Base de dados geo-referenciados . . . 23

3 M ´ETODOS . . . 25

3.1 OBTENC¸ ˜AO E ARMAZENAMENTO DOS DADOS . . . 25

3.2 LIMPEZA E PREPARAC¸ ˜AO DOS DADOS . . . 29

3.3 ASSOCIAÇ ÃO DOS DADOS DE GPS ÀS INFORMAÇ ÕES DE UTILIZAÇ ÃO DOS CART ÕES . . . 31

3.4 ESTIMAÇ ÃO DO PONTO DE DESEMBARQUE DE CADA USU ÁRIO . . . 33

3.5 CRIAÇ ÃO E VISUALIZAÇ ÃO DA MATRIZ DE ORIGEM-DESTINO . . . 36

3.6 OFERTA DE PACOTE DE SERVIC¸ OS TELEM ´ATICOS . . . 39

3.6.1 Ligac¸˜oes importantes sem linha direta dedicada . . . 40

3.6.2 Estimação do n´ıvel de utilização dos ônibus . . . 41

3.6.3 Alerta de sa´ıda da rota prevista . . . 43

3.6.4 Alerta de quilometragem . . . 44

3.6.5 Alerta de excesso de velocidade . . . 44

4 EXPERIMENTOS E RESULTADOS . . . 47

4.1 OBTENC¸ ˜AO E ARMAZENAMENTO DOS DADOS - RESULTADOS . . . 47

4.2 LIMPEZA E PREPARAC¸ ˜AO DOS DADOS - RESULTADOS . . . 52

4.3 ASSOCIAÇ ÃO DOS DADOS DE GPS ÀS INFORMAÇ ÕES DE UTILIZAÇ ÃO DOS CART ÕES - RESULTADOS . . . 54

4.4 ESTIMAÇ ÃO DO PONTO DE DESEMBARQUE DE CADA USU ÁRIO -RESULTADOS . . . 55

4.5 CRIAÇ ÃO E VISUALIZAÇ ÃO DA MATRIZ DE ORIGEM-DESTINO -RESULTADOS . . . 56

4.6 OFERTA DE PACOTE DE SERVIC¸ OS TELEM ´ATICOS - RESULTADOS . . . 61

5 CONCLUS ˜OES . . . 71

5.1 TRABALHOS FUTUROS . . . 72

REFER ˆENCIAS . . . 74

Anexo A -- SCRIPT R: OBTER POSIÇ ÕES GPS E DADOS DOS CART ÕES . . . 77 Anexo B -- SCRIPT PYTHON: CONTAR QUANTAS VEZES CADA CART ÃO FOI

(13)

CURITIBA . . . 82 Anexo D -- SCRIPT SQL: ASSOCIAR GRADES AOS PONTOS DE ÔNIBUS . . . 84 Anexo E -- SCRIPT SQL: UNIR UTILIZAÇ ÃO DOS CART ÕES COM

INFORMAÇ ÃO DE GPS DOS ÔNIBUS . . . 86 Anexo F -- SCRIPT SQL: DEFINIR GRADE DE PARTIDA E DE CHEGADA . . . 89

Anexo G -- SCRIPT R: CRIAR GRAFO DAS PRINCIPAIS LIGAC¸ ˜OES

ORIGEM/DESTINO . . . 95 Anexo H -- SCRIPT SQL: CONFIRMAR AUS ˆENCIA DE COBERTURA DIRETA . 98

Anexo I -- SCRIPT PYTHON: CONFIRMAR AUS ˆENCIA DE COBERTURA

DIRETA . . . 101 Anexo J -- SCRIPT SQL: IMPLEMENTAR SERVIÇ OS TELEM ÁTICOS . . . 104 Anexo K -- SCRIPT PYTHON: IMPLEMENTAR SERVIÇ OS TELEM ÁTICOS . . . 109 Anexo L -- TIPOS E CAPACIDADES DOS ÔNIBUS DE CURITIBA . . . 113

(14)

1 INTRODUC¸ ˜AO

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 an´alise de dados segue uma trajet´oria ascendente e aparentemente sem limites.

A qualquer momento do dia e em qualquer lugar do planeta, grandes volumes de dados são produzidos pelos mais diversos dispositivos como celulares, câmeras de segurança, equipamentos médicos, plataformas de comércio eletrônico e sites de redes sociais.

Esta explosão na quantidade de informações tem elevado a importância do aprendizado a partir de dados a um patamar extremamente elevado. É cada vez maior o número de cientistas, decisores e governantes que consideram a análise massiva de dados como uma grande alavanca para promover melhoras na qualidade de vida e proporcionar um grande crescimento econômico à sociedade (EDWARDS, 2014).

O jornal britânico The Economist em 2010 já afirmava que “Dados estão se tornando a nova matéria prima dos negócios: Uma entrada econômica quase equivalente ao capital ou ao trabalho”. Na mesma linha, também em 2010, a Gartner (uma das maiores empresas de consultoria do mundo) afirmava que “Dados serão o petróleo do século 21”.

Como inúmeros “dispositivos conectados” estão se tornando parte de nossas vidas diárias incluindo dispositivos vest´ıveis (wearables), sensores, câmeras de vigilâncias, aplicativos de smartphones, sistemas de automatizações residenciais etc., temos cada vez mais informações dispon´ıveis. Todas estas informações que compõem tais dados estão a disposição para serem analisados, com a esperança que os resultados de tais análises ajudem a desenvolver novas intuições, ideias e percepções sobre o mundo e ajude a melhorá-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, gest˜ao do lixo,

(15)

climatização residenciais e gestão da energia.

Do conceito de cidades inteligentes, muitas outras ideias e tendências vem sendo identificadas e fomentadas. A t´ıtulo de exemplo tem-se projetos de SmartGrid (para gestão inteligente no consumo de energia) e projetos de “ve´ıculos conectados” (buscando auxiliar na redução do trânsito nas cidades, por exemplo).

Para entender o conceito de “Ve´ıculo Conectado”, pode-se dividi-lo em trˆes componentes (PORTER; HEPPELMANN, 2015):

• Componentes f´ısicos: Referem-se as peças mecânicas e eletrônicas propriamente ditas: motor, pneu, bateria etc.;

• Componentes inteligentes: Referem-se aos captores, microprocessadores, memórias, comandos, softwares, interfaces homem-máquina etc.. No caso automotivo, pode-se citar como exemplos a unidade de injeção eletrônica, o sistema de frenagem ABS, o limpador de para-brisa automático acoplado ao sensor de chuva, o sistema multim´ıdia etc.;

• Componentes de conectividade: Referem-se a componentes que permitam a comunicação com ou sem fio com o produto, como é o caso de antenas, modens, protocolos de comunicação 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 dissertação explora um dos principais eixos de cidades inteligentes: o sistema de transporte público.

A primeira e a mais essencial questão para o sucesso de qualquer processo de análise massiva de dados, é ter claramente definido o problema que se deseja resolver (EMC, 2015). Como obter, armazenar e utilizar os dados abertos do transporte público de Curitiba a fim de prover a todos os envolvidos, serviços telemáticos de alto valor agregado é o problema que se busca resolver neste trabalho.

1.1 SISTEMA DE TRANSPORTE P ´UBLICO DE CURITIBA

Curitiba é a capital do estado do Paraná, Brasil, e se estende por uma área de 430,9 km2. De acordo com o último censo brasileiro (datando de 2010), a cidade tem cerca de 1,8 milhões de habitantes, sendo a oitava mais populosa do pa´ıs.

(16)

Planejamento urbano é essencial para ordenar e melhorar o desenvolvimento da cidade. Planejar o espaço urbano, considerando todos os aspectos de uso do território, é fortemente ligado aos sistemas de transporte público e suas infraestruturas (GUERRA, 2011). Curitiba é conhecida como a “capital ecológica do Brasil”, tendo uma longa tradição no planejamento urbano sustentável e conceitos urbanistas inovadores. A cidade já foi considerada uma das cidades mais inteligentes do mundo e é atualmente membro da C40 megacidades (KOZIEVITCH et al., 2016).

O sistema de transporte público de Curitiba é controlado, gerido e operado pela URBS (Urbanização de Curitiba S.A.)1. Trata-se de uma empresa de capital misto com mais de 99% das ações pertencentes à Prefeitura de Curitiba2.

No in´ıcio da década de 70, a URBS criou corredores ligando os eixos norte e sul da cidade através de ônibus expressos (atualmente cobertos também por ônibus articulados ou biarticulados, com capacidade para cerca de 250 passageiros por ônibus). Diversos terminais foram criados para conectar estes corredores às linhas alimentadoras (que conectam regiões mais distantes da cidade). Existem também algumas linhas espec´ıficas (Interbairros) que conectam as regiões periféricas sem passar pelo centro da cidade, além de algumas linhas diretas oferecendo alternativas mais rápidas e eficientes para os usuários. Estas, utilizam pontos de ônibus especiais chamados Estação Tubo (ver Figura 1), onde o usuário paga ao entrar no ponto de ônibus, reduzindo o tempo de embarque nos ônibus e melhorando a agilidade do sistema como um todo.

Figura 1: Exemplo de ponto de ônibus utilizado pelas linhas expressas da cidade: Estação Tubo.

A respeito do modo de pagamento, Curitiba utiliza a tecnologia de smart card como cartão de transporte (trata-se de um cartão plástico contendo um chip capaz de validar a coleta da tarifa do ônibus através de Comunicação por Campo de Proximidade - Near Field Communication - NFC em inglês (PELLETIER et al., 2011)). Os usuários podem pagar as

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

(17)

viagens com dinheiro ou utilizando o cartão de transporte (que pode ser carregado em diversos pontos da cidade). Segundo últimos dados oficiais divulgados (datando de 2016), cerca de 60%3 dos usuários do sistema, utilizam o cartão de transporte como meio de pagamento.

1.2 CIDADES INTELIGENTES E DADOS ABERTOS

Em 2012, pela primeira vez, mais de 50% da população mundial passou a viver em cidades (isto significa mais de 3,5 bilhões de pessoas). De acordo com as Nações Unidas, este número deve passar de metade para dois-terços em 2040 (BABINET, 2015).

De certo modo, uma cidade é a concentração de diversos tipos de fluxos: pessoas, trens, carros, informação, energia, água potável, esgoto etc. Um dos maiores desafios para muitas administrações públicas ao redor do planeta é aprender a lidar com todos esses fluxos de forma eficiente e ambientalmente responsável.

Este enorme crescimento da densidade populacional humana em áreas urbanas tem forçado governos a repensar sobre o próprio funcionamento das cidades.

´

E fácil identificar muitos problemas que as cidades deverão enfrentar a fim de se manterem atrativas tanto para os negócios quanto para os cidadãos.

A partir destas necessidades, nasceu o conceito de Cidades Inteligentes (Smart Cities). Este conceito está relacionado a um padrão de desenvolvimento capaz de reduzir impactos ambientais, melhorando, por exemplo, acessos a recursos naturais, gestão de energia e de transporte (CHEN et al., 2014). Ele está fortemente relacionado à obtenção e análise de dados, com o intuito de aumentar a compreensão, avaliar e melhorar o modo como as cidades trabalham e se desenvolvem4.

Em 2014, um cons´orcio de partes interessadas (stakeholders) suecas e brasileiras foi criado com o intuito de promover o desenvolvimento urbano sustent´avel 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 inglˆes Open Data) significa dados livres acess´ıveis a qualquer um. Eles devem ser publicados de uma maneira estruturada e compartilhado sob uma licenc¸a aberta,

3_{http://www.urbs.curitiba.pr.gov.br/transporte/estatisticas/uso cartoes (site visitado em 02/07/2017)}

4_{Alguns exemplos reais de avanc¸os 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 em 02/07/2017)

(18)

garantindo sua livre utilização, sem nenhuma barreira técnica ou legal (BABINET, 2015)6.

1.3 VEÍCULOS CONECTADOS E SERVIÇ OS TELEM ÁTICOS

Dado seu alto impacto em engarrafamentos, poluição do ar e mobilidade de pessoas e mercadorias, uma das peças mais cr´ıticas do quebra-cabeça de Cidades Inteligentes é o transporte público(KOZIEVITCH et al., 2016) e a mobilidade urbana de forma geral. Cidades Inteligentes serão capazes de suportar sistemas de transporte multimodais, facilitar a busca por vagas de estacionamento, controlar de forma inteligente os semáforos sincronizando-os, por exemplo, com os horários e posições dos ônibus da cidade7.

Aliás, com o advento de novas tecnologias nesta área, transformando ônibus ordinários em ônibus conectados (capazes de se comunicar à distância alguns de seus estados e parâmetros), é 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 público.

Ve´ıculos conectados são uma das maiores tendências atualmente no mundo automotivo, conforme é apresentado pela imprensa e empresas de consultoria especializadas, tais como a McKinsey & Company8. Ele também é considerado como um dos pilares da próxima revolução que o setor deve viver: ve´ıculos autônomos.

Tanto as montadoras de luxo como as mais populares, veem as tecnologias associadas ao ve´ıculo conectado como essenciais para seus futuros. Até 2020, o ve´ıculo conectado deve transformar de forma disruptiva todo o ecossistema automotivo. No entanto, ainda restam muitos desafios técnicos, legais e de segurança a serem vencidos para que os futuros consumidores realmente confiem em ve´ıculos altamente conectados e autônomos (VIERECKL et al., 2015).

A palavra telemática (formada da junção das palavras telecomunicações e informática) foi cunhada pela primeira vez em um relatório destinado ao governo francês em maio de 1978 (NORA; MINC, 1978). Este relatório foi o resultado de uma trabalho solicitado pela presidência da república para “fazer progredir a reflexão sobre como conduzir a informatização 6_{Uma lista das cidades mais inteligentes da Europa, bem como algumas das iniciativas de Open Data} das mesmas é apresentada neste artigo do jornal britânico The Guardian https://www.theguardian.com/media-network/2015/oct/14/manchester-barcelona-smart-cities-open-data (site visitado em 02/07/2017)

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

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

(19)

na sociedade”.

Ainda que no meio acadêmico a palavra ainda tenha mantido seu sentido mais amplo, comercialmente ela é geralmente associada à telemática veicular (também chamada de “serviços conectados”). O padrão IEEE 802.11p trata da telemática veicular versando sobre a problemática 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 aplicação no contexto de comunicação entre um ve´ıculo e uma estação rodoviária.

Um ve´ıculo conectado é um ve´ıculo capaz de comunicar seus dados, estados e informações com agentes externos (como servidores, empresas, call-centers etc) oferecendo novas possibilidades de serviços aos usuários e a todos os atores interagindo com ele. Novos serviços, como o rastreamento de ve´ıculos roubados podem ser criados e oferecidos; além de serviços tradicionais já existentes, como a assistência 24 horas, podem ser abrilhantados com a ajuda da conectividade. Tais tipos de serviços são também conhecidos por Serviços Telemáticos Automotivos ou, simplesmente, Serviços Telemáticos.

Conforme será apresentado, os ônibus conectados de Curitiba ainda são bastante t´ımidos com relação a disponibilização de seus dados e suas capacidades de conectividade. No entanto, essas capacidades já permitem, por exemplo, criar a chamada matriz de origem-destino (matriz O/D), que basicamente descreve de onde os usuários vêm e para onde eles vão.

Esta matriz pode ter diversas aplicações para uma agência de gestão de trânsito: planejamento do serviço ao longo do dia; análise da operação global do sistema; avaliação do impacto de alguma alteração da rede e melhora na gestão do serviço (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 será a base de dois dos serviços telemáticos propostos. De modo geral, sob a forma de uma prova de conceito, os seguintes serviços serão apresentados: cerca-eletrônica, alerta de velocidade, alerta de manutenção, nova proposta de linhas e avaliação do n´ıvel de ocupação dos ônibus.

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

• Apresentar uma alternativa eficaz para a obtenção cont´ınua dos dados abertos do sistema de transporte público de Curitiba (dados de utilização dos cartões de transporte,

(20)

posicionamento geogr´afico dos ˆonibus da rede e dados diversos sobre a estrutura do sistema de transporte em si);

• Identificar pontos de correção e ajustes nos mesmos e prover um retorno a URBS sobre eventuais acréscimos de informações (capazes de permitir um melhor aproveitamento dos dados já disponibilizados);

• Criar uma representação aproximada do modo de movimentação dos usuários do sistema, no que tange suas respectivas origens e destinos (através da criação e visualização da matriz origem/destino);

• Utilizar tais informações para propor algumas opções de serviços telemáticos que poderiam ser facilmente colocadas à disposição de todos os usuários.

Criar uma matriz O/D e utilizá-la junto com outros dados brutos também dispon´ıveis, com o intuito de propor serviços telemáticos com alto valor agregado, é a maior contribuição deste trabalho.

1.5 ESTRUTURA DA DISSERTAC¸ ˜AO

O texto segue com o Cap´ıtulo 2 contendo a revis˜ao bibliogr´afica e um pouco mais de detalhes sobre as ferramentas utilizadas.

O Cap´ıtulo 3 apresenta as hipóteses, condições e métodos fundamentais para cada uma das etapas necessárias à passagem dos dados brutos da cidade à exploração dos serviços telemáticos. Ela é seguida pelo Cap´ıtulo 4 contendo a discussão dos resultados obtidos em cada uma das etapas apresentadas.

Este texto ´e finalizado com o Cap´ıtulo 5 apresentando as conclus˜oes e as diversas possibilidades de trabalhos futuros que se apresentam.

(21)

2 REVIS ˜AO BIBLIOGR ´AFICA

2.1 TRABALHOS CORRELATOS

A literatura está repleta de exemplos de utilização de dados abertos do sistema de transporte público (para trens e/ou ônibus) em várias cidades do mundo. Em sua imensa maioria, os trabalhos se dedicam a produzir, de forma automática a partir destes dados, as chamadas Matrizes Origem/Destino (matriz O/D).

Segundo (CUI, 2006), isto se deve ao fato de tecnologias como cobrança automatizada de tarifas (Automated Fare Collection - AFC em inglês) e localização automática de ve´ıculos (Automated Vehicle Location - AVL em inglês), estarem cada vez mais disseminadas nos sistemas de transporte ao redor do mundo (como é também o caso de Curitiba).

No entanto, mesmo que diversos trabalhos compartilhem ideias e objetivos, a preparação e preprocessamento dos dados dispon´ıveis é bastante peculiar e espec´ıfico a cada cidade (observamos diferenças 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 n´umero de viagens realizadas entre cada regi˜ao de origem e de destino, para um certo per´ıodo de tempo.

Esta maneira de obter a matriz O/D quando comparado aos métodos tradicionais (através de pesquisas manuais, entrevistas e contagens), é bastante atrativa por ser muito mais barata, rápida e, em certos aspectos, mais precisa. Por exemplo, a municipalidade de Curitiba iniciou em março de 2016 uma pesquisa de Origem e Destino tradicional1 (entrevistando cerca de 48000 pessoas, a fim de obter ao menos 16000 entrevistas válidas) com previsão de divulgação dos resultados no final de 2017. Porém, dado seu alto custo (cerca de R$ 6,3 milhões) e tempo necessário de realização (por volta de dez meses), não é poss´ıvel que seja aplicada com uma frequência elevada (sendo realizadas a cada dez anos, aproximadamente (GUERRA, 2011)).

1_{http://www.curitiba.pr.gov.br/noticias/pesquisa-origem-destino-comeca-nesta-sexta-feira-em-curitiba/39381} (visitado em 02/07/2017)

(22)

Esta pesquisa tradicional tem também outros objetivos, como identificar as razões e motivações por trás de cada mobilidade. Este tipo de informação é mais dif´ıcil de ser obtida através da análise de dados dos cartões de transporte. Ainda assim, existem trabalhos que buscam avançar neste sentido também, relacionando os dados dos cartões a dados sócio-demográficos da cidade, como é o caso de (KUHLMAN, 2015).

Um ótimo survey sobre o uso de dados abertos dos ônibus e trens para aplicação em transporte público, respondendo aos mais diversos objetivos operacionais, táticos ou estratégicos, pode ser encontrado em (PELLETIER et al., 2011).

Um dos primeiros estudos sobre o uso de dados AFC para definição de uma matriz O/D ocorreu em São Francisco, nos Estados Unidos, na década de 80 ((BUNEMAN, 1984)). Tratava-se de um sistema de transporte férreo, cujo controle do cartão de transporte era feito no embarque e no desembarque facilitando, portanto, a precisa identificação dos pontos de origem e destino de cada usuário.

A maioria dos sistemas de transporte de ônibus ao redor do mundo possui controle de validação apenas na entrada do mesmo (como também é o caso de Curitiba). Isso significa que os usuários não validam seus cartões de transporte quando saem do sistema. Portanto, não é poss´ıvel definir precisamente o destino dos usuários. Como consequência, algumas hipóteses devem ser assumidas a fim de estimar o ponto de descida de cada usuário.

Tais hipóteses tiveram suas bases estabelecidas em (ZHAO, 2004), na cidade de Chicago em 2004, e serão apresentadas no Cap´ıtulo 3. Elas tiveram pouca evolução desde então, contando essencialmente com melhorias marginais como uma melhor definição dos horários do dia a serem considerados (TREPANIER et al., 2007) (evitando considerar o dia como sendo de 0h00 até 23h59, mas algo do tipo 4h00 do dia “d” até 3h59 do dia “d+1”) ou tentativas de melhoria na identificação dos pontos de transferência (com base nos tempos levados em cada transição), como o que é apresentado em (BAGCHI; WHITE, 2004).

Em 2007, na cidade de Quebec, (TREPANIER et al., 2007) aplica este método e levanta a importante questão referente à validação 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 poderá ser feito também com o resultado desta dissertação).

Na China, também em 2007, (LIANFU et al., 2007) constrói uma matriz O/D utilizando apenas dados AFC. Como não utiliza AVL e não dispõe de daos estruturais da rede de

(23)

transporte, a identificação dos pontos de ônibus é feita através de um questionário preenchido pelos motoristas com o horário de parada em cada ponto.

A primeira aplicação no Brasil aconteceu com (FARZIN, 2008) na cidade de São Paulo. O sistema AVL estava presente apenas em alguns poucos ônibus, o que dificultou a validação e exaustividade dos resultados. Em 2011, (GUERRA, 2011) também aplicou um método semelhante na cidade de Maceió. Como também não dispunha de um sistema AVL, considerou o ponto de embarque e desembarque através da comparação do horário de validação do cartão com a tabela horária das linhas de ônibus. Além disso, a partir desta primeira matriz (chamada de matriz semente, considerando apenas os usuários com cartão de transporte), ele expandiu a matriz unindo-a a dados de contagem de tráfego através de um programa profissional especializado chamado TransCAD2.

Formas inovadoras de visualização também são de extrema importância, pois facilitam a comunicação sobre os resultados encontrados destas análises. Por exemplo (MA; WANG, 2014), (CALABRESE, 2013) e (COME et al., 2014) apresentam uma boa visão geral de poss´ıveis soluções para responder ao problema da visualização de grandes volumes de dados.

São bem poucos os trabalhos que vão além da criação automática da matriz O/D, se aproximando, ainda que em pequena escala, dos tipos de serviços telemáticos propostos nesta dissertação. São eles: Identificar irregularidades nas transações a fim de evidenciar erros, fraudes ou equipamentos defeituosos (DEAKIN; KIM, 2001); Estudar o trajeto preciso que cada usuário teria empregado (HOFFMAN et al., 2009); Calcular o tempo de vida útil de um cartão de transporte (TREPANIER; MORENCY, 2010); Avaliar a aderência à tabela de horários ou a quilometragem total percorrida por cada ve´ıculo e usuário (TREPANIER et al., 2009, 2009); Estimar quais os pontos de ônibus com maior afluência de usuários (TREPANIER et al., 2007); Propor novas linhas visando adaptar a rede existente às reais necessidades dos usuários (CHU; CHAPLEAU, 2008; CHU et al., 2009). Neste mesmo sentido de recriar as linhas existentes, (CALABRESE, 2013) propõe um método semelhante em Abidjan, na Costa do Marfim, através de dados do sistema de telefonia celular da cidade.

Em suma, muitos artigos atacam o problema de criação da matriz O/D através de informações AVL e AFC, porém, poucos mostram como transformá-las em serviços telemáticos aos cidadãos ou ao gestor do próprio sistema. Esta é a maior contribuição desta dissertação.

(24)

2.2 FERRAMENTAS UTILIZADAS 2.2.1 PYTHON

Python é uma linguagem de programação interpretada bastante poderosa, rápida e de fácil aprendizado3. Python integra-se facilmente com outras linguagens e sistemas e possui código aberto (facilitando sua utilização inclusive para usos comerciais). Não obstante, ela é amplamente utilizada no meio industrial, cient´ıfico e acadêmico.

Python possui uma comunidade bastante ativa de desenvolvedores e utilizadores. Milhares de módulos e aplicações utilizando Python existem hoje no mercado: desenvolvimento para web e internet, acesso a banco de dados, aplicações em áreas cient´ıficas e educacionais, desenvolvimento de jogos entre outros. A sua integração com um sistema de gestão de base de dados foi especialmente explorada neste trabalho.

Independentemente da linguagem de programação, possuir uma boa ferramenta de desenvolvimento (chamado de IDE - Integrated Development Environment) é de bastante utilidade pois facilita em muito a edição e validação 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 orçamento dispon´ıvel para tal. Neste trabalho, utilizou-se a versão grátis (sob licença 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 aplicação que funciona como interface entre dois sistemas diferentes, possibilitando a comunicação e integração entre ambos.

Os dados abertos da cidade de Curitiba são disponibilizados através da publicação de web-services dedicados uma vez que os dados estão armazenados em servidores e banco de dados internos a URBS. Para serem acessados faz-se necessário o envio do pedido ao web-serviceque retornará a resposta em um formato padronizado.

R é uma linguagem de programação utilizada essencialmente para cálculos estat´ısticos e gráficos4. Ele é grátis, tem ampla disponibilidade para diversos sistemas operacionais e uma enorme quantidade de pacotes e bibliotecas (criados por sua ativa comunidade de

3_{https://www.python.org/(visitado em 02/07/2017).}

(25)

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 realização de análises avançadas de dados ou na geração de gráficos sofisticados.

Neste trabalho, utilizou-se como IDE (também grátis e de código aberto) R-Studio, que facilita bastante o uso da linguagem R.

A automatização destes chamados foi realizada pelo Windows task scheduler. Ele é um componente do sistema operacional Microsoft Windows que permite lançar programas scripts de forma pré-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) é um repositório onde informações são armazenadas de forma organizada, permitindo que sejam encontradas facilmente. Dito de outra forma, são coleções organizadas de dados que se relacionam de modo a criar algum sentido e dar mais eficiência durante uma pesquisa ou estudo.

As bases de dados s˜ao geridas por um software espec´ıfico chamado de Sistema de Gerenciamento de Base de Dados (SGBD). Atualmente, existem v´arios 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 é um programa de gestão de base de dados objeto-relacional extens´ıvel, com alta conformidade ao padrão da linguagem SQL (Structured Query Language), de código aberto e gratuito.

A linguagem SQL é um linguagem que é usada exclusivamente para criar, manipular e consultar os dados de base de dados. É através do SQL, que os programas interagem com um banco de dados. Praticamente todas as linguagens de programação (incluindo Python e R) têm bibliotecas para acessar e trabalhar com bancos de dados.

Alguns SGBDs possuem também capacidade de operar com objetos geográficos (pontos, linhas, áreas etc). PostGIS7 é uma extensão ao PostgreSQL que possibilita o suporte a objetos geográficos. Permite que através de consultas integradas ao código SQL, seja poss´ıvel incluir diretamente condições ligadas a posições geográficas dos objetos da base (por exemplo,

5_{https://msdn.microsoft.com/en-us/library/aa446802.aspx (visitado em 02/07/2017).} 6_{https://www.postgresql.org/about/ (visitado em 02/07/2017).}

(26)

quais são todos os pontos de ônibus a um certo raio de distância de uma determinada posição geográfica).

Para trabalhar com SGBDs georreferenciados, um Sistema de Informação Geográfico ou SIG (Geographic Information System - GIS, em inglês) pode ser de grande valia. Trata-se de um sistema informatizado para captura, armazenamento, verificação, integração, manipulação, análise e visualização de dados relacionados a posições na superf´ıcie terrestre.

SIG é uma tecnologia e metodologia computacional para coletar, gerenciar, analisar, modelar e apresentar dados geográficos para uma ampla gama de aplicações.

Neste trabalho utilizou-se o QGIS8como SIG. Ele é grátis e de código aberto. Através da conexão deste programa com a base de dados PostgreSQL/PostGIS, é poss´ıvel criar rápida e facilmente visualizações compondo diversas camadas como a localização de pontos de ônibus sobre o mapa da cidade, por exemplo.

(27)

3 M ´ETODOS

Este cap´ıtulo apresenta, de forma estruturada e cronológica, a metodologia proposta por este trabalho. A Figura 2 reúne as principais etapas a serem seguidas, descritas nas Seções seguintes.

Figura 2: Apresentação dos seis passos fundamentais propostos para passar da obtenção dos dados à exploração de caracter´ısticas operacionais da rede de transporte p úblico através de alguns serviços telemáticos.

A seguir, são apresentados tanto a metodologia como os detalhes e hipóteses de cada etapa. A fim de facilitar a leitura e resumir brevemente cada passo, no in´ıcio de cada Seção 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 OBTENC¸ ˜AO E ARMAZENAMENTO DOS DADOS

A URBS disponibilizou (através de um portal web e dos chamados web-services) uma série de informações sobre o sistema de transporte e sua utilização pelos usuários.

´

(28)

Entrada Dados colocados a disposição pela prefeitura de Curitiba (através de web-services e links espec´ıficos)

Sa´ıda Base de dados contendo elementos iniciais, tais como: • Utilização dos cartões de transporte;

• Posição dos ônibus durante todo o per´ıodo considerado;

• Geolocalização de diversos elementos da rede de transporte (pontos de ônibus e terminais, traçado das linhas e associação entre pontos de ônibus e linhas).

Tabela 1: Principais entradas e sa´ıdas da etapa “Obtenc¸˜ao e Armazenamento dos dados”

possu´ıa cadastro no in´ıcio deste trabalho, no entanto, qualquer cidad˜ao tem o direito de solicitar acesso aos dados1.

Dentre os diversos web-services disponibilizados, quatro deles foram essenciais para a obtenc¸˜ao do material de base deste estudo:

• getLinhas - retorna uma lista com todas as linhas de ˆonibus existentes no sistema p´ublico de transporte de Curitiba;

• getPontosLinhas - retorna o detalhe sobre cada ponto de ônibus que cada uma das linhas possui. É preciso passar como parâmetro para este web-service o número da linha. Logo, a lista resultante do comando precedente foi utilizada para automatizar a obtenção de todos os pontos para todas as linhas;

• getShapeLinhas - retorna o detalhe sobre o trajeto/itinerário de cada linha (através de um conjunto de posições GPS). É preciso passar como parâmetro para este web-service o número da linha. Logo, a lista resultante do comando getLinhas foi utilizada para automatizar a obtenção desta informação para todas as linhas;

• getVeiculosLinha - retorna a coordenada GPS de todos os ˆonibus rodando no sistema no momento do chamado do web-service;

Além das funções citadas, a informação sobre a utilização dos cartões de transporte pode ser obtida através de um link dedicado, disponibilizado apenas aos parceiros da URBS, como é o caso da UTFPR, não sendo acess´ıvel a todos os cadastrados.

1_{http://www.urbs.curitiba.pr.gov.br/fale-conosco (referenciar-se à rubrica “Acesso à Informação - Lei Federal} 12.527”) (site visitado em 02/07/2017)

(29)

A forma escolhida para automatizar a obtenção destes dados foi através da combinação 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 informação sobre as linhas, itinerários e os pontos de ônibus é estática, necessitando uma única execução do web-service correspondente.

No entanto, a informação sobre a posição dos ônibus é atualizada a cada dois minutos. Logo, uma tarefa com periodicidade de dois minutos foi configurada no Windows task scheduler. Esta tarefa tinha por ação lançar um script em R que: realizava a execução do web-service; obtinha o retorno do mesmo; fazia a análise (parsing) dos dados recebidos; armazenava o resultado em um arquivo tipo texto.

A informação sobre a utilização dos cartões é bastante volumosa, porém, bem menos frequente que a anterior. As informações são atualizadas apenas uma vez ao dia. Portanto, criou-se uma tarefa com recorrência diária, que executava através do lançamento de um script em R, o comando para obtenção da base de utilização de cartões do dia anterior. Esta informação também era processada e salva em um arquivo tipo texto pelo mesmo script em R.

Foram obtidos dados dos dias 29 de outubro de 2016 até 11 de novembro de 2016. No entanto, por razões de indisponibilidade do sistema, os dias 01 e 02 de novembro não puderam ser obtidos completamente (tendo sido descartados, portanto, da análise 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 não fazem parte da base inicial fornecida pela URBS, mas são necessários para a aplicação da metodologia desenvolvida neste trabalho.

1. URBS CARD raw: Contém os dados de utilização dos cartões. Basicamente, daqui obtemos a informação do número do cartão, o horário, ônibus e linha na qual o mesmo foi validado. Vale ressaltar que os dados são anonimizados, não sendo poss´ıvel saber os dados do portador do cartão. Também não existe nenhuma informação sobre a posição GPS do ônibus no momento de validação do cartão.

2. bus stops table: Tem-se para cada linha da rede, detalhes sobre todos os pontos de ônibus que compõe o itinerário da mesma. Além da posição, sentido e número único do ponto, a tabela apresenta a sequência (coluna seq) indicando a sequência dos pontos no itinerário da linha para cada sentido da mesma. A coluna grupo é importante pois possui o mesmo valor para pontos que fazem parte de uma mesma estrutura maior, como um terminal, por exemplo.

(30)

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

3. lines shape: Descreve o trajeto previsto no itinerário de cada linha. Após uma pequena transformação (convertendo as informações de latitude e longitude em um objeto geográfico do tipo ponto ou diretamente em uma linha) o conteúdo desta tabela pode ser visualizado no QGIS.

4. Period BUS GPS: Todas as posições GPS emitidas por cada ve´ıculo são armazenadas nesta tabela. Prefixo refere-se a informação sobre o ve´ıculo (é o mesmo que codveiculo da tabela URBS CARD raw ). O web-service para obter este serviço retorna apenas a hora da última informação de GPS emitida. Logo, foi necessário acrescentar uma coluna (scriptdate) contendo o dia e hora quando o web-service foi lançado.

Além da base de pontos obtidas pelo web-service, os terminais e tubos necessitam um tratamento especial. A utilização de um cartão de transporte na entrada de um terminal ou estação tubo é identificada de forma especial na base de utilização dos cartões. Cada equipamento validador do cartão em um destes locais possui um código espec´ıfico, inicialmente não disponibilizado pela URBS. Após diversas reuniões e trocas de informações com a mesma, boa parte destes códigos foi esclarecida, compondo a tabela base tt no PostgreSQL2. A estrutura 2_{A URBS ficou de evoluir a implementação de seus web-services para incluir tais informações também na} mesma base de dados GPS dos ônibus

(31)

completa e uma pequena extração de cada uma destas bases está apresentada na Seção 4.1.

3.2 LIMPEZA E PREPARAC¸ ˜AO DOS DADOS

Antes de poder iniciar propriamente a metodologia para a identificação da origem e estimativa do destino de cada usuário, é necessário realizar uma limpeza e preparação dos dados brutos, conforme mostrado na Tabela 2.

Entrada Base de dados contendo elementos iniciais, tais como: • Utilização dos cartões de transporte;

• Posição dos ônibus durante todo o per´ıodo considerado;

• Geolocalização de diversos elementos da rede de transporte (pontos de ônibus e terminais, traçado das linhas e associação entre pontos de ônibus e linhas). Sa´ıda Base de dados contendo um subconjunto dos elementos

iniciais, acrescida de algumas informações, tais como: • Utilização dos cartões de transporte apenas para os

casos onde o cart˜ao ´e utilizado uma ou duas vezes ao dia;

• Cada instância de utilização do cartão é categorizada como sendo a única, primeira ou segunda no dia; • Apenas as utilizações de cartões realizadas em

ônibus, pontos ou terminais cuja informação GPS é conhecida são mantidas;

• Cada ponto de ônibus é associado ao ID de uma grade quadrada de 500 metros de lado (um conjunto dessas grades é criado cobrindo todo o território de Curitiba).

Tabela 2: Principais entradas e sa´ıdas da etapa “Limpeza e Preparac¸˜ao dos dados”

Uma decisão bastante estruturante para a sequência do processo é o fato de considerar apenas o caso onde um mesmo cartão é utilizado uma ou duas vezes ao dia. Tal decisão está justificada na Seção 4.2.

Para identificar quantas vezes cada cart˜ao ´e utilizado em um mesmo dia, criou-se um procedimento em Python (ver Anexo B). Este procedimento percorre todos os registros (para

(32)

um determinado dia) da base de cartão por duas vezes. Na primeira ele identifica o total de utilização de cada cartão e na segunda ele atualiza cada instância (em um atributo chamado step pass card) como sendo a primeira, segunda, terceira etc utilização no dia.

Um dos passos fundamentais para identificar o ponto de origem do usuário é a fusão das informações de utilização do cartão com a posição do ônibus no qual o mesmo foi utilizado. Devido a uma indisponibilidade da informação, ou incorreta ativação no sistema em alguns ônibus, diversas instâncias de passagem de cartão tiveram que ser descartadas, pois não existia informação de GPS para a linha/ve´ıculo em questão.

A princ´ıpio, os pontos de origem e destino dos usuários poderiam ser definidos dentre o conjunto de pontos de ônibus da cidade. No entanto, para simplificar a visualização, reduzir o volume de dados final e absorver eventuais erros na predição dos pontos exatos de origem e destino, optou-se por mapear os pontos de partida e chegada sobre uma malha quadricular cobrindo toda a região metropolitana da cidade (ver Figura 4).

Esta malha quadricular foi criada automaticamente através de um script em Python. O código para tal pode ser encontrado no Anexo C. Este script cria um shapefile contendo cada uma das grades, que é armazenada sob forma de base de dados geo-referenciada (identificada por PolygonGrid na Figura 3).

Cada grade é formada por um quadrado de 500 metros de lado. Esta dimensão foi escolhida pois, segundo a própria URBS, a cada 500 metros seria poss´ıvel encontrar um ponto de ônibus na cidade3.

A base de dados contendo os pontos de ônibus foi então populada com esta informação adicional (ID da grade na qual o ponto se insere). Como detalhado no código SQL do Anexo D, esta operação é bastante facilitada através da funcionalidade oferecida pelo PostGIS. Utilizando a função ST MakePoint, cria-se um objeto geográfico representando a posição de cada ponto de ônibus (a partir das informações de latitude e longitude). Em seguida, a função ST Contains avalia qual grade (que é, por sua vez, um objeto geográfico do tipo área) contém o ponto geográfico que representa o ponto de ônibus.

Este procedimento é exatamente o mesmo para associar qualquer outra posição GPS (de usuários ou de elementos da rede) ao respectivo ID da base contendo a grade.

3_{Informação confirmada durante o Seminário “Open Data Seminar”, realizada na UTFPR com a presença de} representantes da URBS, em 25 de outubro de 2016.

(33)

Figura 4: Grade composta por quadrados de 500 metros de lado, cobrindo toda a regi˜ao de Curitiba. Cada grade possui um ID ´unico.

3.3 ASSOCIAÇ ÃO DOS DADOS DE GPS ÀS INFORMAÇ ÕES DE UTILIZAÇ ÃO DOS CART ÕES

Entrada Base de dados contendo a utilização dos cartões de transporte e base de dados com a posição GPS de todos os ônibus da rede.

Sa´ıda Base de dados contendo a utilização dos cartões incrementada com a informação de GPS, o ID do ponto de ônibus e o ID da grade onde provavelmente o cartão foi validado no ônibus, estação tubo ou terminal em questão.

Tabela 3: Principais entradas e sa´ıdas da etapa “Associação dos dados de GPS às informações de utilização dos cartões”

(34)

A base de utilização dos cartões possui apenas a informação sobre o número do cartão, o ônibus/ linha na qual o cartão foi validado e o horário desta validação (ver a estrutura da base URBS CARD raw na Figura 3). Logo, a informação de geolocalização não faz parte desta base. Portanto, a fim de identificar ou estimar o ponto de partida dos usuários, faz-se necessário cruzar as informações desta base com as informações oriundas da base contendo as posições dos ônibus na rede.

Basicamente, é preciso identificar na base Period BUS GPS qual era a posição, para aquele determinado ônibus e linha, mais próxima do horário em que o usuário validou seu cartão no mesmo. A partir desta posição, identifica-se a grade na qual a mesma está inserida.

Como detalhado no Anexo E, passa-se por 4 tabelas intermediárias até obter-se a posição GPS do ve´ıculo especificado na base de cartões (através dos atributos codlinha, codveiculoe datautilizacao da base de cartões). A informação referente a diferença de tempo entre a passagem do cartão no ônibus e a emissão da posição GPS considerada do mesmo também é armazenada na base de cartões (no atributo timedif ), podendo ser utilizada para avaliação do n´ıvel de confiabilidade da inferência realizada.

Subentende-se aqui que o passageiro suba no ônibus e valide seu cartão. Um poss´ıvel erro deve ser aceito já que existem usuários que podem aguardar na parte da frente do ônibus antes da validação do cartão (por opção ou devido ao alto grau de ocupação do ônibus em questão). No entanto, haja visto o espaço existente nesta parte, é de se esperar que a grande maioria dos usuários valide seu cartão logo que embarque no ve´ıculo.

Para um dos serviços telemáticos propostos, é preciso identificar o ponto de ônibus mais provável de embarque do usuário (e não somente a grade que o inclui). Neste caso, é necessário um passo adicional buscando associar a posição GPS identificada com o ponto de ônibus mais próximo pertencente à linha em questão. Novamente, funcionalidades do PostGIS facilitam bastante esta busca pois ela se resume a identificar dentre os pontos de ônibus de uma lista definida (cujo parâmetro line da base bus stops table é o mesmo do parâmetro linha da base de GPS) aquele que apresenta a menor distância para a posição GPS identificada (utilizando a função ST DistanceSphere, por exemplo).

No entanto, nem a base de GPS (Period BUS GPS) nem a base de cartões (URBS CARD raw), contém informação sobre o sentido do ônibus naquele instante. Logo, nem sempre é poss´ıvel definir com precisão qual o ponto exato utilizado.

Resta salientar que, de maneira geral, o ponto de ônibus exato no qual o usuário embarcou não é essencial nesta abordagem, uma vez que o que se procura é identificar a grade

(35)

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

3.4 ESTIMAÇ ÃO DO PONTO DE DESEMBARQUE DE CADA USU ÁRIO

Entrada Base de dados contendo a utilização dos cartões de transporte (já com o ponto de origem definido).

Sa´ıda Base de dados contendo a utilização dos cartões (já com a informação de GPS e o ID da grade de embarque) acrescida da informação sobre o ID da grade onde estima-se que o usuário desceu do ônibus.

Tabela 4: Principais entradas e sa´ıdas da etapa “Estimação do Ponto de Desembarque de cada usuário”

Conforme mencionado no Cap´ıtulo 2, as hipóteses apresentadas em (ZHAO, 2004) tem norteado a maior parte dos estudos de criação de matriz O/D a partir de dados de cartões e posições GPS dos ônibus. A inferência do ponto/grade de desembarque se baseia nas seguintes hipóteses:

1. Não existe nenhum modo de transporte privado (carro, moto, bicicleta etc) entre dois trechos consecutivos de utilização do cartão no dia;

2. A última viagem dos usuários tem por destino final o ponto de partida do dia em questão.

Nesta primeira abordagem, considera-se apenas os casos de utilização de até duas vezes o mesmo cartão 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 usuário utiliza o cartão uma primeira vez no dia, descendo na grade onde ele utilizará o cartão pela segunda vez. Neste mesmo local, ele deve pegar um ônibus para retornar ao ponto de partida.

Porém, em muitas situações um dado cartão é validado uma única vez no dia. Subentende-se que nestes casos, o usuário deva contar com algum outro meio de transporte para retornar ao seu ponto de origem, por exemplo. Para estes casos de uma única utilização no dia, a seguinte estratégia foi adotada (ver 1):

• Procura-se, dentre os outros dias dispon´ıveis (mantendo a distinção entre dias da semana e finais de semana), se aquele usuário teria um cenário de duas passagens exatas do cartão no dia, onde ele teria partido de alguma das 8 grades adjacentes à grade em questão. Caso positivo, considera-se que no dia onde há apenas uma passagem, ele estaria se dirigindo para a mesma localidade que foi no dia onde registrou duas utilizações diárias;

(36)

• Caso este cenário não ocorra, considera-se como destino o ponto para onde a maior parte dos outros usuários se dirigiram naquele dia e faixa horária.

Algorithm 1 Estratégia para única utilização diária

1: GradeOrigem← grade ID da utilização única naquele dia (grade de partida); 2: if Existe algum caso de duas utilizações diárias do mesmo cartão? then

3: if Posição de partida igual GradeOrigem OU Posição de partida adjacente a GradeOrigemthen

4: GradeDestino← Mesmo destino da viagem identificada

5: elseGradeDestino ← Top grade ID destino dentre todos os usu´arios (no per´ıodo) 6: elseGradeDestino ← Top grade ID destino dentre todos os usu´arios (no per´ıodo)

O Anexo F apresenta o código SQL utilizado para realizar esta etapa da metodologia. No cenário contendo uma única utilização, não é feito nenhuma distinção caso haja mais de uma viagem do mesmo usuário partindo de um ponto próximo mas indo para destinos diferentes. O primeiro deles será considerado como o destino do dia onde apenas uma utilização foi contabilizada. Melhorar este ponto exigiria um esforço computacional considerável para um ganho em precisão questionável.

Observa-se, novamente, que em nenhum momento foi considerada a questão do trajeto exato tomado pelo usuário. Logo, caso ele tenha feito algum tipo de transferência em áreas onde não é necessário revalidar o cartão (como em estações tubos ou terminais) tal manobra não será evidenciada por esta abordagem.

Para os casos de duas utilizações diárias, a metodologia seguida é a seguinte:

1. Seja o exemplo real do cartão 0001659901, que pegou a linha 212 no per´ıodo da manhã e validou seu cartão 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 cartão 0001659901 utiliza duas vezes o cartão no dia, uma pela manhã e outra no in´ıcio da tarde, em dois ônibus e linhas diferentes.

2. Cruzando a informação da posição GPS do ônibus BN406 realizando a linha 212 por volta das 05:50, pode-se inferir o ponto de partida da primeira viagem deste usuário. Da mesma forma, cruzando-se a informação da posição GPS do ônibus HA612 realizando a linha 685 por volta das 16:18, pode-se inferir o ponto de partida deste usuário na viagem de volta. (ver Figura 6)

(37)

Figura 6: Posições onde o cartão foi validado nos dois momentos do dia.

3. A partir da´ı, determina-se diretamente em qual das grades cada uma das posic¸˜oes faz parte (ver Figura 7)

Figura 7: Grades contendo cada uma das posic¸˜oes 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 prov´avel de cada viagem para os cart˜oes utilizados duas vezes

(38)

ao dia. Novamente, a hipótese adotada aqui não leva em consideração o trajeto utilizado pelo usuário. A t´ıtulo de exemplo, a Figura 8 apresenta quais teriam sido possivelmente os trajetos deste usuário no dia do exemplo em questão.

Figura 8: A que poderia se assemelhar o trajeto utilizado por este usu´ario no dia em quest˜ao. (fonte mapa: GoogleMaps)

3.5 CRIAÇ ÃO E VISUALIZAÇ ÃO DA MATRIZ DE ORIGEM-DESTINO

Entrada Base de dados contendo a utilização dos cartões (já com a informação de GPS e o ID da grade de embarque) acrescida da informação sobre o ID da grade onde se estima que o usuário desceu do ônibus.

Sa´ıda Visualização do resultado obtido através de diversas formas: mapas de calor sobre o mapa da cidade, grafos e tabelas contendo as ligações mais utilizadas pelos usuários.

Tabela 5: Principais entradas e sa´ıdas da etapa “Criação e Visualização da Matriz de Origem-Destino”

A partir da base SQL que já representa a matriz origem-destino referentes aos dias observados neste estudo, a primeira abordagem para verificar os resultados dos passos precedentes é apresentar esta informação sob o formato de grafos. Para isto, exportou-se a base produzida em SQL sob forma de um arquivo tipo texto, para posterior importação e trabalho

(39)

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 nós representam as grades, cada aresta indica a ligação existente entre estas duas regiões e o peso de cada uma representa o volume de utilização daquela ligação pelos usuários.

Do grafo obtido, fica simples a criação de uma lista contendo as ligações mais utilizadas pelos usuários nos dias em questão. Tal lista será a fonte essencial para a implementação de um dos serviços telemáticos, conforme será abordado na Seção 3.6.

Com este mesmo arquivo tipo texto, uma ferramenta gratuita chamada GEPHI4 também foi avaliada. Apesar de bastante poderosa e flex´ıvel, contendo diversos adendos para estat´ısticas e visualizações de grafos, tal ferramenta ainda apresenta um alto grau de instabilidade, razão pela qual não foi muito mais explorada ao longo deste trabalho, tendo sida utilizada apenas para produzir algumas poucas imagens ilustrativas, não justificando sua presença dentre as ferramentas apresentadas no Cap´ıtulo 2.

Em virtude das dimensões do grafo (com os nós representando as cerca quatro mil grades), a visualização integral do mesmo fica bastante prejudicada (o que será discutido no Cap´ıtulo 4). Logo, tentar apresentar simplesmente todas as ligações entre grades não é nada leg´ıvel. Portanto, concluiu-se que a melhor solução passe pela apresentação de alguns aspectos espec´ıficos da rede sob forma de grafos ou então integralmente via os chamados “mapa de calor” sobrepostos ao mapa da cidade.

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

• Através de bibliotecas dedicadas em R (ggmap, por exemplo), cuja vantagem é ser bastante simples, não necessitando de muitas linhas de código para produzir algo visualmente interessante. No entanto, a imagem produzida é estática, não sendo poss´ıvel trabalhar dinamicamente, reconstruindo a imagem a cada aproximação 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, através da utilização 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 soluc¸˜ao era visualmente bastante 4_{https://gephi.org/ (visitado em 02/07/2017)}

(40)

atraente, porém, pecava pelo pouco controle sobre os mapas de calor produzidos não sendo poss´ıvel, de maneira fácil, obter a legenda das cores, muito menos os algoritmos utilizados para sua produção;

• A solução encontrada, combinando simplicidade, controle e potência, foi a utilização direta do QGIS para a produção de tais visualizações.

Como mencionado anteriormente, é poss´ıvel integrar o QGIS diretamente à base de dados do PostgreSQL. Todos os elementos de tipo geográficos (oferecidos pela extensão PostGIS) são pass´ıveis de serem apresentados sobre o mapa da cidade. O QGIS também possibilita a criação de mapas de calor através dos chamados Mapas de kernel.

O termo Mapa de kernel, faz referência a um método estat´ıstico de estimação de curvas de densidade. Ele é bastante útil para se ter uma visão geral da intensidade do processo em estudo sobre todas as regiões do mapa. No caso deste trabalho, o processo se trata dos pontos de subida e descida dos usuários do transporte público de Curitiba.

Basicamente, no ponto central de cada grade (ou eventualmente na geolocalização de cada ponto de ônibus) aplica-se uma função espec´ıfica (a função kernel). Esta função contabiliza seu valor de máximo neste ponto, conforme a quantidade de subidas ou descidas inferidas ali. Ela então decresce, seguindo a definição da própria função de kernel, conforme nos afastamos do ponto central da grade, sobrepondo seus valores às funções aplicadas nos pontos centrais das grades adjacentes.

O QGIS possui algumas opções de configuração para a criação 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 consideração 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 distância de seus adjacentes, o valor de raio de 750 metros produziu mapas de kernel bastante suaves e visualmente atraentes.

Naturalmente, diversas outras formas de visualização dos resultados são poss´ıveis. Tal tópico faz parte dos trabalhos futuros vislumbrados e elencados no final do Cap´ıtulo 5.