Soluções OpenSource no planejamento multimodal de viagens em Campinas.

Transcrição

1 Soluções OpenSource no planejamento multimodal de viagens em Campinas. Eduardo Patto Kanegae 1 eduardokanegae@emdec.com.br 1 : EMDEC ( Empresa Municipal de Desenvolvimento de Campinas ) Gerência de Tecnologia da Informação Rua Dr. Salles Oliveira, 1028, Vila Industrial CEP , Campinas/SP Fone: (19) RESENHA No ano de 2010 a EMDEC empresa pública responsável pelo trânsito e transporte na cidade de Campinas publicou em seu site uma ferramenta para a consulta por itinerários de horários contendo recursos inovadores como a roteirização de viagens e a visualização de resultados na forma de mapas integrados à plataforma Google Maps. O presente trabalho tem por objetivo traçar as características gerais desta ferramenta em operação desde 2010, bem como efetuar uma análise dos esforços necessários para a implantação do sistema OpenTripPlanner um planejador de viagens OpenSource desenvolvido pela agência de trânsito de Portland/Oregon/EUA como alternativa à solução proprietária em uso atualmente na EMDEC. PALAVRAS-CHAVE Roteirização, Transporte público, Planejamento multimodal de viagens, Sistemas de Informação Geográfica INTRODUÇÃO Com uma população de 1(um) milhão de habitantes no município e quase 3(três) milhões de habitantes em sua região metropolitana, Campinas possui atualmente a terceira maior população do estado de São Paulo e seu sistema de transporte público é responsável pelo deslocamento mensal de cerca de 15(quinze) milhões de passageiros na cidade. Para auxiliar a população na identificação de trajetos e deslocamentos diários, a EMDEC empresa responsável pelo trânsito e transportes em Campinas disponibilizou em seu site no ano de 2010 o Sistema de Informação ao Usuário (SIU): uma ferramenta para pesquisa de itinerários e horários de ônibus que pode ser acessada através da Internet. Com recursos inovadores como a roteirização de viagens a partir de pontos de origem e destino informados como endereços, cruzamentos ou pontos de referência e a visualização do trajeto resultante (percurso a pé e percurso de ônibus) na forma de mapas interativos integrados à plataforma Google Maps, o SIU foi um dos fatores responsáveis pelo expressivo aumento de 60% no número total de internautas que acessaram o site da EMDEC no período 2010 a 2012 à procura de informações sobre itinerários e horários do transporte público na cidade. Por cerca de dois anos em operação, o SIU demonstrou ser ferramenta essencial para a população e por esta razão a Gerência de Tecnologia da Informação da EMDEC iniciou um processo de pesquisa e desenvolvimento com o uso sistemas de informação geográfica com o objetivo de atualizar e acrescentar melhorias a este sistema. Após pesquisas e testes Página 1

2 preliminares, a ferramenta OpenTripPlanner (OTP) software opensource 1 desenvolvido pela agência de trânsito e transportes de Portland/Oregon/EUA para o planejamento multimodal de viagens foi identificada como uma alternativa ideal para atender a este processo de modernização do SIU. O presente trabalho tem por objetivo apresentar as principais características do OpenTripPlanner, bem como elucidar sucintamente os procedimentos realizados pela EMDEC durante o processo de sua implantação em caráter de teste para o município de Campinas. DIAGNÓSTICO, PROPOSIÇÕES E RESULTADOS 1 Especificações básicas do Sistema de Informação ao Usuário Com o objetivo de se organizar uma lista de requisitos para o teste e implantação da solução OpenTripPlanner com dados do município de Campinas, foram observadas as seguintes características do atual sistema em operação (SIU): a) Interface para informar o local de origem e local de destino da viagem na forma de endereços, cruzamento de logradouros ou seleção de origem/destino através de uma lista de pontos de interesse. Figura 1 - Especificação de local de origem ou destino através de um endereço 1 OpenSource modelo de desenvolvimento de software no qual usuários e desenvolvedores tem, sem custos diretos com licenças, a permissão para instalar, usar, modificar e distribuir quaisquer sistemas licenciados nesta forma de distribuição. Página 2

3 Figura 2 - Especificação de local através de um ponto de interesse Figura 3 - Especificação de local através da digitação de um cruzamento de logradouros b) Recursos que permitam o usuário especificar parâmetros da viagem como o horário de partida, o tipo de data ( dia útil, sábado ou domingo), máxima distância a ser percorrida a pé e opção para definir se o usuário necessita ou não de recursos de acessibilidade para usuários com restrições de mobilidade. Figura 4 - Especificação de preferências adicionais para o planejamento da viagem c) Cálculo e seleção do melhor roteiro de viagem com base nos parâmetros informados nos itens (a) e (b) com exibição descritiva dos detalhes da viagem ( tempo estimado, distância percorrida, distância total a ser percorrida a pé, custo da viagem, total de linhas Página 3

4 a utilizar e resumo do roteiro. Em alguns casos, o sistema também exibe trajetos alternativos. Figura 5 - o resumo da viagem é exibido após o cálculo da melhor rota d) Visualização do roteiro selecionado na forma de mapa Figura 6 - o roteiro de viagem pode ser visualizado através de uma interface integrada ao Google Maps e) Atalho que permita o usuário visualizar um roteiro de volta a partir de uma viagem previamente calculada f) Interface para consulta e visualização de itinerários e horários por linha 2 Características gerais do sistema OpenTripPlanner O OpenTripPlanner é um software opensource para planejamento multimodal de viagens. Sua característica multimodal baseia-se na possibilidade de se planejar roteiros através de diversas combinações dos meios de locomoção, tais como roteiros a pé, viagens usando veículos e evitando-se percursos a pé, viagens de ônibus, percursos com bicicleta somente ou ainda combinações como percursos de bicicleta e ônibus. Seu desenvolvimento foi financiado e apoiado pela agência de trânsito e transporte de Portland/Oregon/EUA no período de 2009 a Para escolha do OTP como opção e teste de planejamento de viagens, foram observadas as características e especificações gerais do atual Sistema de Informação ao Usuário e comparadas com as principais características do OpenTripPlanner que incluem: Página 4

5 a) Possibilidade de informar locais de origem e destino através de endereços, cruzamentos, pontos de interesse, pontos de parada ou através de pontos localizados em um mapa interativo. b) Possibilidade de informar opções da viagem como o horário de partida ou chegada, data da viagem, máxima distância a ser percorrida a pé, definição de necessidade de carro adaptado para atendimento a usuários com restrições de mobilidade c) Para trechos de viagens realizados a pé ou de bicicleta, o sistema também leva em consideração parâmetros como topografia do terreno e índice de segurança para trânsito com bicicleta. d) Cálculo e seleção do melhor roteiro de viagem, além de roteiros alternativos. Após o cálculo, o roteiro escolhido é exibido na forma de um mapa interativo e são exibidos também os detalhes completos da viagem como tempo estimado, distância percorrida, distância total a ser percorrida a pé, custo da viagem, total de linhas a utilizar e resumo do roteiro. e) Possui recurso para definição rápida de um roteiro de volta. f) Interface para listagem e consulta das linhas existentes que podem ser selecionadas e visualizadas diretamente em um mapa interativo. Além das características supracitadas, que por si já definem o sistema OTP como uma opção equivalente ao atual SIU, também podem ser evidenciados outros recursos adicionais inexistentes no atual sistema: g) Planejamento multimodal de viagens combinando trechos realizados a pé, de bicicleta, de ônibus e veículos. h) Para percursos realizado a pé ou de bicicleta, é exibido um gráfico de elevação da topografia do percurso. O que permite ao usuário analisar previamente o seu nível de esforço para eventuais aclives e declives componentes do trajeto. i) Possui interface para ajuste dos parâmetros de distância, elevação do terreno e segurança para trechos percorridos com bicicleta j) Integração com a plataforma Google StreetView que permite a visualização de imagens de locais selecionados no mapa como pontos de partida, destino ou pontos de parada. k) Possibilidade de se configurar a interface do sistema em outro idioma. l) Presença de módulo para integração com dados de monitoramento de frota e exibição da posição atual em mapa para cada ônibus em tempo real. Página 5

6 3 Comparação OTP versus SIU Após o levantamento completo das características de ambos os sistemas, estes dados foram tabulados com objetivo de facilitar a comparação entre as duas soluções. Tabela 1 Comparação de itens funcionais OTP x SIU CARACTERIZAÇÃO GERAL Licença de uso OpenSource Proprietário Tipo de modal usado no cálculo de viagens Idioma da interface OTP considera ônibus, automóveis, bicicletas, viagens a pé ou combinações entre modais português, inglês, espanhol, italiano, alemão, holandês, gaélico, hebraico, úngaro, polonês, turco e marati. SIU somente ônibus português Consulta detalhada por linha sim sim DEFINIÇÃO DE PARÂMETROS DE PESQUISA local de origem/destino como endereço, cruzamento ou ponto de interesse sim sim local de origem/destino através de pontos clicados em mapa interativo sim não local de origem/destino escolhendo o ponto de parada sim não data da viagem calendário dia útil, sábado ou domingo horário de partida sim sim horário de chegada sim não distância máxima a pé sim sim necessidade de veículo adaptado para usuários com restrição de mobilidade sim sim priorização por trecho mais curto, mais plano ou mais seguro - para viagens de bicicleta RESULTADOS DE PESQUISA resumo da viagem - tempo estimado, distância total percorrida, distância percorrida a pé, total de linhas a embarcar e descrição textual do trajeto roteiro de viagem na forma de mapa interativo sim sim definição de roteiro de volta através de atalho sim sim gráfico de elevação do percurso - para viagens de bicicleta sim não integração com Google StreetView para visualização de locais sim não integração com monitoramento de frota, para exibição da posição atual de cada ônibus sim não RECURSOS AVANÇADOS definição de alertas de roteiros por ou SMS sim não ferramentas de análise sim não interface para dispositivos móveis sim não sim sim não sim Página 6

7 4 Preparando os conjuntos de dados necessários para a configuração do OTP Para a correta instalação, configuração e uso do OpenTripPlanner, é necessário a preparação de dois conjuntos de dados essenciais para o sistema: uma base de dados para representação dos trajetos possíveis percorridos a pé, de bicicleta ou veículo automotor, além de outra base de dados para representação dos trajetos possíveis executados por ônibus e dados complementares como a localização de pontos de parada e tabelas de horários para cada linha de ônibus. Com o objetivo de se simplificar o processo de teste do OTP, para o primeiro conjunto de dados foi adotado um subconjunto da base de dados do projeto OpenStreetMap 2 (OSM) abrangendo a área que cobre o município de Campinas/SP. Já no segundo caso, foi necessária a transformação de dados oriundos da base de dados geográfica da EMDEC - contendo informações de linhas ônibus e pontos de parada em arquivos de dados em formato GTFS 3. Os procedimentos utilizados para a elaboração destes conjuntos de dados são expostos a seguir. 4.1 Criando uma base de dados OSM para o município de Campinas Para fazer o download de um subconjunto qualquer de dados através do site do projeto OpenStreetMap, uma alternativa muito comum é definir uma área de interesse através das coordenadas de um retângulo envolvente. Ao especificar este parâmetro as coordenadas devem ser informadas em graus decimais, no sistema geográfico com datum WGS84 e os valores devem ser informados na seguinte sequência: Longitude inferior esquerda (minx) Latitude inferior esquerda (miny) Longitude superior direita (maxx) Latitude superior direita (maxy) Figura 7 Retângulo de envolvente de Campinas 2 O OpenStreetMap é um projeto difundido via internet no qual usuários do mundo todo coletam dados geográficos que são posteriormente publicados na forma de mapas para internet que contemplam mapas de cidades, estradas e rodovias, divisas políticas municipais, estaduais e nacionais. Os dados finais do projeto são distribuídos de forma livre e gratuita via internet para qualquer usuário. 3 A especificação GTFS ( General Transit Feed Specification ) foi criada em 2005 através de uma parceria entre a Google e a agência trânsito e transportes de Portland/Oregon/EUA (TriMet) e atualmente é um formato de dados utilizado pelo sistema Google Transit Trip Planner, além de ser compatível também com outros sistemas comerciais e opensource. Página 7

8 Usando esta definição de sequência como parâmetro, o menor retângulo envolvente que cobre toda a área limite do município de Campinas pode ser definido por: Longitude inferior esquerda: Latitude inferior esquerda: Longitude superior direita: Latitude superior direita: Em seguida, define-se o link para a realização do download dos dados selecionados, gravando o arquivo resultante com o nome de campinas.osm : O arquivo em formato OSM contém informações vetoriais e alfanuméricas sobre vias de circulação, cruzamentos, pontos de interesse e demais objetos de importância geográfica que compõem o mapa de cidades que são atendidas pelo projeto OpenStreetMap. No caso de vias de circulação, podem existir atributos que definem restrições por trecho informando se a via permite a circulação de pedestre, bicicletas ou somente veículos motorizados. Figura 8 Arquivo campinas.osm visualizado com o editor de dados do OSM 4.2 Criando arquivos GTFS para o município de Campinas O formato de dados GTFS especificação pública criada pela Google para atender aos requisitos do sistema Google Transit é composto por uma série de arquivos de tipo texto puro, com valores de dados separados por vírgula, que devem conter informações relevantes sobre as operadoras de transporte público da cidade, localização e dados sobre pontos de parada de ônibus, trajetos e períodos de operação das linhas de ônibus, horários de passagem por cada ponto de parada associado por linha de ônibus e outras informações complementares ao sistema de transporte público que não foram consideradas para este teste. Para cada arquivo do sistema GTFS, existem valores que devem ser explícitos obrigatoriamente e outros que opcionalmente podem ser informados ou não. Recomenda-se a consulta ao Guia de Referência da especificação GTFS 4, documentação oficial do projeto disponível na internet, para melhor compreensão destes requisitos. 4 General Transit Feed specification Reference disponível em Página 8

9 4.2.1 Arquivo agency.txt O arquivo agency.txt define atributos sobre as operadoras que executam as viagens de ônibus para uma determinada cidade. As operadoras definidas neste arquivo são relacionadas posteriormente no arquivo routes.txt. No caso da EMDEC, este arquivo foi gerado contendo apenas uma única linha de dados contendo apenas a operadora EMDEC para fins de simplificação da tarefa. O conteúdo deste arquivo ficou da seguinte forma: Figura 9 Conteúdo do arquivo "agency.txt" para cidade de Campinas Os atributos especificados neste arquivo são: Agency_id: define um código identificador exclusivo para cada operadora de transporte. Agency_name: define o nome da operadora. Agency_url: define o website da operadora de transporte. Agency_timezone: define o fuso horário utilizado como referência pela operadora de transporte. Agency_lang: define o idioma padrão utilizado pela operadora. Agency_phone: define o telefone de contato da operadora de transporte Arquivo stops.txt Atualmente o município de Campinas possui cerca de 5.000(cinco mil) pontos de parada de ônibus e dado o alto volume de dados, para elaboração deste arquivo foram considerados somente os atributos essenciais para o funcionamento do arquivo GTFS. Figura 10 Conteúdo parcial do arquivo "stops.txt" para a cidade de Campinas Atributos do arquivo stops.txt : Stop_id: define um código identificador exclusivo para cada ponto de ônibus. Stop_code: pode-se utilizar este campo para definir um código próprio para cada ponto de parada. Por exemplo: um código que seja visível no ponto de parada para melhor informar os usuários do sistema de transporte. Para fins de simplificação, no caso da EMDEC, adotou-se stop_code com o mesmo valor do campo stop_id. Stop_name: este atributo pode ser usado para se definir um nome curto para cada ponto de parada. Página 9

10 Stop_desc: atributo utilizado para se definir uma descrição textual longa para pontos de parada. Normalmente, associa-se a este campo um valor como uma referência à localização do ponto de parada. Por exemplo: Ponto da Igreja Matriz Municipal. Stop_lat: este campo deve conter o valor de Latitude da coordenada de localização do ponto de parada. O valor deve ser expresso em grau decimal em sistema geográfico ajustado para Datum WGS84. Stop_lon: este campo deve conter o valor de Longitude da coordenada de localização do ponto de parada. O valor deve ser expresso em grau decimal em sistema geográfico ajustado para Datum WGS84. Location_type: este atributo define se um ponto de parada é um ponto comum (valor 0) ou se é uma estação que aglomera vários pontos de parada (valor 1). Para fins de simplificação do referido teste, todos os pontos de parada de Campinas foram definidos com valor 0 (zero) Arquivo routes.txt O arquivo routes.txt deve conter os atributos básicos para cada linha (rota) de ônibus existente e em operação na cidade. O município de Campinas atualmente possui cerca de 300 linhas em operação, sendo que cerca de um quinto deste valor possui dois sentidos: ida e volta. Para o teste foram consideradas somente as linhas com sentido de ida. Figura 11 Conteúdo parcial para o arquivo "routes.txt" Estrutura de atributos para o arquivo routes.txt : Route_id: define um código identificador exclusivo para cada linha de ônibus. Este identificador deve conter o mesmo valor que será usado posteriormente no campo shape_id do arquivo shapes.txt. Agency_id: contém o identificador exclusivo da operadora de transporte responsável pela linha de ônibus. Como neste teste no arquivo agency.txt foi criada apenas uma única agência, no arquivo routes.txt todas as linhas constarão com valor 1 neste campo. Route_short_name: especifica um nome abreviado para identificação do trajeto percorrido pela linha de ônibus. Para o caso de Campinas, adotou-se o código da linha que é o mesmo valor especificado no letreiro e placa indicativa lateral dos ônibus. Por exemplo: 150. Route_long_name: especifica um nome para identificação do trajeto. Neste caso, todas as linhas tiveram este campo definido com o nome da linha. Por exemplo: o nome Terminal Vila União I corresponde ao nome de letreiro da linha de número (route_short_name) 150. Route_desc: a presença deste atributo é opcional no arquivo e caso seja informado, pode ser usado para se especificar os pontos principais por onde passa a linha/trajeto. Route_type: atributo de valor numérico que especifica o tipo de modal operado pelo trajeto. Para trajetos de ônibus deve ser definido com o valor 3. Route_url: este atributo pode ser usado para especificação de um endereço válido de internet (link) que contenha informações detalhadas sobre a linha de ônibus. Por exemplo: o link Página 10

11 quando acessado pelo usuário irá exibir os detalhes da linha 150-Terminal Vila União I diretamente do Sistema de Informações ao Usuário atualmente em operação no site da EMDEC Arquivo calendar.txt Figura 12 Detalhes da linha 150 acessíveis via SIU O arquivo calendar.txt é utilizado pelo formato GTFS para se definir o calendário operacional de serviço das linhas em operação. Sua estrutura basicamente define um código de serviço, os dias da semana envolvidos no serviço e as datas que definem o momento de início e fim da vigência do serviço. Como o sistema de transportes de Campinas opera atualmente com basicamente três tipos de serviço dias úteis, sábado e domingo o presente arquivo foi elaborado contendo apenas três registros em seu conteúdo e para fins de teste, para cada tipo de serviço, definiu-se todo o ano de 2013 como período operacional: Figura 13 Conteúdo do arquivo "calendar.txt" Service_id: define um código identificador exclusivo para um tipo de serviço. No exemplo da EMDEC foram criados os códigos 100, 200 e 300 para os modos de operação dias úteis, sábado e domingo respectivamente. Monday, Tuesday, Wednesday, Thursday, Friday, Saturday e Sunday: estes atributos devem ser preenchidos com valor 1 ou 0 e indicam se um determinado serviço opera às segundas-feiras, terças-feiras, quartas-feiras, quintas-feiras, sextasfeiras, sábados e domingos respectivamente. Por exemplo: para o tipo de serviço 300 (domingos), somente o atributo Sunday deve ser preenchido com valor 1. Os outros atributos (Monday, Tuesday, Wednesday, Thursday, Friday e Saturday) devem ser preenchidos com o valor 0. Start_date: indica a data inicial de vigência do serviço no formato AAAA/MM/DD ( ano, mês e dia). Por exemplo: o valor define a data 1º de Janeiro de End_date: indica a data final de vigência do serviço no formato AAAA/MM/DD ( ano, mês e dia). Por exemplo: o valor define a data 31 de Dezembro de Página 11

12 4.2.5 Arquivo shapes.txt Para cada registro de dados presente no arquivo routes.txt deve-se criar um conjunto de registro de dados equivalente no arquivo shapes.txt especificando valores de referência no valor do campo shape_id. O arquivo shapes.txt deverá conterá a descrição geométrica para cada trajeto de ônibus presente no arquivo routes.txt onde para cada linha/trajeto existente deverá constar um registro de dado para cada vértice componente da respectiva linha. Estrutura de atributos do arquivo shapes.txt : Shape_id: define um código identificador exclusivo para cada geometria que representa a estrutura geométrica de uma linha de ônibus. Este identificador terá seus valores repetidos para cada seqüência de pontos ao longo dos registros de dados de cada trajeto. Para facilitar a tarefa, na EMDEC foi adotado neste atributo os mesmos valores usados no campo route_id do arquivo routes.txt. Shape_pt_lat: contém o valor de Latitude da coordenada de localização de cada vértice que compõe um trajeto de ônibus. O valor deve ser expresso em grau decimal em sistema geográfico ajustado para Datum WGS84. Shape_pt_lon: contém o valor de Longitude da coordenada de localização de cada vértice que compõe um trajeto de ônibus. O valor deve ser expresso em grau decimal em sistema geográfico ajustado para Datum WGS84. Shape_pt_sequence: define um indicador de seqüência para cada vértice representado como registro de dados para um dado trajeto. Por exemplo: ao primeiro vértice de uma linha de ônibus qualquer deve ser atribuído o valor 1 neste campo, ao segundo vértice será atribuído o valor 2 e assim sucessivamente. Shape_dist_traveled: contém o valor expresso em quilômetros que mede a distância linear do primeiro vértice do trajeto até o vértice correspondente na seqüência de dados. Figura 14 Mapa da linha 150 ( ID 51 ) com destaque à localização dos 5 primeiros vértices do trajeto Página 12

13 Figura 15 Arquivo "shapes.txt" contendo os 5 primeiros vértices da linha de ID = Arquivo trips.txt O arquivo trips.txt cria o conceito de viagem dentro do padrão GTFS, onde cada viagem equivale à execução de todo um trajeto (linha de ônibus) com saída em um horário pré-determinado. Assim sendo, se uma determinada linha possui 20 horários de partida para um determinado tipo de serviço, no arquivo trips.txt deverão existir 20 registros de dados correspondentes a esta mesma linha. Para citar o caso da linha 150-Terminal Vila União I que possui 87 horários de partida definidos para o tipo de serviço dias úteis temos: Número de viagens em dias úteis = 1 linha X 1 modo de serviço X 87 horários Estrutura de atributos do arquivo trips.txt : Route_id: define o identificador do trajeto. Os trajetos existentes são listados no arquivo routes.txt. Service_id: define o identificador do tipo de serviço. Os tipos de serviço existentes são listados no arquivo calendar.txt. Trip_id: define um código identificador exclusivo para cada viagem. Trip_headsign: este atributo deve conter uma descrição que indique aos passageiros o destino da viagem. Para o teste da EMDEC foi utilizado o mesmo valor do atributo route_long_name do arquivo routes.txt. Direction_id: especifica se a viagem tem sentido de IDA (valor 0) ou VOLTA (valor 1). Shape_id: define o identificador da descrição geométrica de um trajeto. Estes identificadores são listados no arquivo shapes.txt. Figura 16 Conteúdo parcial do arquivo "trips.txt" contendo algumas viagens da linha com ID = 51 Página 13

14 4.2.7 Arquivo stoptime.txt O arquivo stoptime.txt é sem dúvida o item mais complexo a ser gerado dentro de uma estrutura GTFS, pois, para sua elaboração é necessário realizar o cruzamento de dados oriundos dos arquivos de pontos de parada, viagens e ainda definir a seqüência de horários de passagem em cada ponto de parada associado às linhas de ônibus, bem como a distância percorrida desde o início da linha até o referido ponto de parada. Em termos práticos, para cada viagem de um determinado trajeto, deverão existir no arquivo stoptime.txt um número de registro de dados que corresponda ao número de pontos de parada por onde o trajeto executa paradas para embarque e desembarque de passageiros. Para a elaboração deste arquivo na EMDEC utilizou-se a velocidade padrão de 15Km/hora. Esta velocidade padrão é necessária para se calcular o tempo de chegada para cada viagem nos pontos de parada associados ao trajeto. Por exemplo: na imagem a seguir a viagem 9712 tem início às 00:10 e após 13,1 metros passa pelo primeiro ponto de parada identificado pelo número e chega no 14º ponto de parada após percorrer 3,5 quilômetros e 14 minutos após o início da viagem. Estrutura do arquivo stoptime.txt : Trip_id: define o identificador da viagem. As viagens existentes são listadas no arquivo trips.txt. Arrival_time: define o horário de chegada da viagem a um ponto de parada associado ao trajeto. Para o cálculo deste horário, foi utilizado a velocidade média padrão de 15km/h e é necessário também ter o valor do atributo shape_dist_traveled. Departure_time: com o objetivo de se facilitar a elaboração deste arquivo, foi atribuído a este campo o mesmo valor do campo arrival_time. Ou seja, foi considerado que o ônibus permanece um tempo nulo (zero) em cada ponto de parada. Stop_id: define o identificador de um ponto de parada associado ao trajeto da viagem. Stop_sequence: define a seqüência do ponto de parada em relação aos pontos associados ao trajeto da viagem. Por exemplo: o primeiro ponto de parada por onde uma viagem passa, deverá receber o valor 1 e o segundo ponto deverá receber o valor 2 e assim sucessivamente. Shape_dist_traveled: este atributo deve conter a distância linear expressa em quilômetros desde o ponto inicial do trajeto até o referido ponto de parada associado no campo stop_id. É importante salientar que a localização dos pontos de parada muitas vezes não passa sobre as linhas geométricas que definem um trajeto e por este motivo Página 14

15 recomenda-se utilizar como referência uma projeção perpendicular do ponto de parada até o segmento de reta mais próximo do trajeto Resumo por arquivo e finalização do conjunto GTFS A tabela a seguir traz um resumo dos arquivos elaborados para teste no ambiente da EMDEC considerando algumas premissas: Uma única operadora de transporte foi definida para todas as linhas Todos os pontos de parada foram considerados como ponto comum Não foram considerados parâmetros de acessibilidade em linhas ou pontos de parada Somente foram consideradas as linhas com sentido de ida Somente foram definidas viagens para o tipo de serviço dia útil Para o cálculo de horários de chegada de cada viagem a cada ponto de parada associado, foi considerada a velocidade constante e média de 15km/h e não foi considerado nenhum intervalo para o embarque e desembarque em cada ponto de parada. Tabela 2 Total de registros de dados por arquivo Arquivo Total de registros agency.txt 1 stops.txt routes.txt 319 calendar.txt 3 shapes.txt trips.txt stoptime.txt Dados complementares Modelo Digital de Terreno do município de Campinas O OpenTripPlanner também oferece suporte opcional ao uso de modelos digitais de terreno. Este tipo de dado quando configurado no OTP, será utilizado pelo sistema para desenhar um gráfico de perfil para percursos executados a pé ou de bicicleta com o objetivo de se informar o usuário o nível de esforço físico que este enfrentará ao caminhar ou pedalar por aclives ou declives da cidade. No Brasil, dados de modelo digital de terreno com resolução espacial de 30 metros podem ser obtidos através do site do projeto INPE/TOPODATA 5. 5 Efetuando testes com o OTP O sistema OTP contém em sua distribuição de instalação, um módulo responsável pelo processamento do conjunto de dados formado por dados OSM, arquivos GTFS e modelos digitais de terreno. O conjunto de dados é processado e um novo arquivo é gerado contendo toda a estrutura de grafos e dados complementares que depois são lidos pelo módulo servidor de aplicação. Após iniciar o servidor de aplicação do OTP, é possível acessar um mapa interativo via web com um painel lateral para a especificação de parâmetros de viagem. 5 TOPODATA Página 15

16 5.1 Teste de trajeto via ônibus Para operação e definição de um novo trajeto no OTP o processo é simples: através de um mapa interativo, via web, o usuário navega pelo mapa e utiliza-se de comandos simples como um clique com o botão direito do mouse para definir os pontos de origem e destino de uma nova viagem. Figura 17 Definindo um ponto de partida Depois especifica-se parâmetros adicionais da consulta como data e hora de partida ou chegada da viagem ou ainda a distância máxima a ser percorrida a pé. Figura 18 Definindo um ponto de chegada Página 16

17 Uma vez definidos os pontos de partida e chegada o usuário deverá clicar no botão denominado Calcular e após alguns segundos uma ou mais opções de trajeto serão exibidas através do mapa interativo e também com detalhes da viagem exibidos através do painel lateral do sistema. Figura 19 Visualização de trajeto resultante no OTP 5.2 Detalhando trechos de um trajeto O OTP além de exibir o trajeto resultante na forma de mapa também exibe uma descrição textual para cada trecho a ser percorrido a pé ou de bicicleta. Na imagem a seguir, ao selecionar um trecho que deve ser percorrido a pé, é exibida uma janela contendo um atalho para o Google StreetView. Este atalho se acionado irá exibir imagens do Google StreetView para a localização escolhida. Figura 20 Recurso do Google StreetView habilitado no OTP Página 17

18 5.3 Teste de trajeto via bicicleta Para pesquisa por trajetos a serem realizados de bicicleta, o usuário pode também interir nos parâmetros de pesquisa e definir se deseja priorizar um caminho mais rápido, com menos incidência de aclives ou com maior segurança para ciclistas. Figura 21 Consulta por trajetos de bicicleta Figura 22 Detalhamento de trajeto para percurso com bicicleta Página 18

19 CONCLUSÕES Após a realização de testes por trajetos diversos envolvendo pontos e localidades de interesse no município de Campinas, a solução OpenTripPlanner provou ser uma alternativa muito interessante para a implantação de websites que tenham por objetivo fornecer informações de trajetos para munícipes e visitantes do município em geral. Sua possibilidade de permitir buscas por trajetos a pé, de bicicleta, de ônibus ou a combinação de entre modalidades é um atrativo perante sistemas concorrentes como o Google Transit. Contudo, a ausência de funcionalidades para o gerenciamento automatizado de dados que compõe uma estrutura de transporte público como pontos de parada, tabelas horárias e linhas de ônibus é fator que deve ser analisado com cuidado pelas agências de trânsito pois a ausência de tais funções poderão eventualmente ocasionar um atraso no processo de atualização de informações e consequentemente poderão informar incorretamente usuários do transporte público que venham a consultar o sistema. REFERÊNCIAS Google. General Transit Feed Specification Reference. Disponível em Acesso em: 26 de Julho de OpenTripPlanner. Users and Developers documentation. Disponível em Acesso em: 25 de Julho de Página 19