September 3, 2021 8:19 am

GBFS e Política de Dados de Mobilidade Compartilhada

Ajudando as cidades a apoiar opções de mobilidade contínua e sustentável com a GBFS.

(Este guia está disponível em espanhol, francês e inglês.)

Visão geral

Garantir acesso aos dados de mobilidade é parte importante de um programa de mobilidade compartilhada. O acesso público aos dados de mobilidade cria confiança nos programas de mobilidade e aumenta a adoção da mobilidade compartilhada. A elaboração de políticas eficazes pode garantir que os dados de mobilidade sejam precisos e acessíveis.
Este relatório é destinado principalmente aos indivíduos responsáveis pelas políticas e aquisições de mobilidade compartilhada nas cidades ou outros municípios. O relatório fornece uma compreensão fundamental de como A GBFS suporta opções de mobilidade sustentável e contínua e como alavancar o potencial dos dados de fonte aberta, ao formular políticas que podem influenciar a adoção e a prática da mobilidade compartilhada. Um relatório similar para as partes interessadas nas Américas foi publicado em Junho de 2021 e pode ser encontrado aqui.

Foto: Martti Tulenheimo

Como a GBFS pode apoiar o esforço das cidades para oferecer transporte sustentável 

A GBFS facilita aos viajantes encontrar e utilizar a mobilidade compartilhada. 

Desde a sua criação em 2015, o GBFS tornou-se o padrão de facto para a partilha de dados de mobilidade. Presentemente, a especificação é utilizada em centenas de cidades em pelo menos 45 países de todo o mundo.

Os formuladores de políticas devem exigir APIs da GBFS públicas ao autorizar ou licenciar operações de mobilidade compartilhada. A GBFS fornece uma linguagem comum para que os operadores de mobilidade compartilhada compartilhem informações sobre as opções disponíveis para os viajantes. A GBFS inclui informações sobre veículos (bicicletas, scooters, ciclomotores e carros), estações, e muito mais:

  • Localização e disponibilidade de veículos, estações e vagas
  • Características do veículo – tipo de motor, distância que pode ser percorrida na carga restante
  • Áreas delimitadas (geofencing) por regras relacionadas a velocidade, estacionamento e zonas proibidas.

Estes dados são usados por aplicativos de planejamento de viagem e Mobilidade como Serviço (MaaS), para fornecer aos viajantes as informações necessárias para que eles possam descobrir e escolher a mobilidade compartilhada.  As API públicas GBFS permitem a integração de serviços de mobilidade partilhada com os transportes públicos, permitindo aos utilizadores fazer ligações na sua viagem e viagens multimodais, permitindo viagens mais livres de automóvel.

Além disso, a GBFS fornece aos municípios e agências uma forma padronizada de consumir, analisar e comparar dados gerados por sistemas de mobilidade compartilhada. Os avanços nas plataformas de mobilidade compartilhada resultaram na geração de grandes quantidades de dados de mobilidade. Esses dados se tornaram parte essencial da formulação de políticas e da regulamentação dos operadores de mobilidade compartilhada. Os dados das plataformas de mobilidade compartilhada nos ajudam a entender como esses serviços têm impacto na segurança pública, e se avançam ou não equidade, inovação, sustentabilidade e outras metas políticas. O acesso público aos dados de mobilidade compartilhada aumenta a transparência e torna os operadores responsáveis pelos serviços que operam na via pública.

A GBFS foi projetada especificamente para ser usada como fonte de dados públicos. Para tornar as APIs da GBFS verdadeiramente públicas, elas devem ser disponibilizadas gratuitamente na Internet aberta e não exigir nenhuma chave API, token ou outro meio de acesso ou autenticação. Feeds contendo dados sensíveis que requerem autenticação não são um substituto para APIs públicas.

A GBFS permite o intercâmbio de informações de forma a garantir que todas as partes concordem sobre o que as informações representam. É como se fosse um dicionário, onde cada termo tem uma definição e um conjunto de regras de como pode ser usado. A GBFS é uma especificação de dados em tempo real que descreve o estado atual de um sistema de mobilidade. A GBFS não suporta nem se destina ao uso de dados históricos, como registros de viagem ou manutenção.

A GBFS reduz os encargos administrativos das cidades, reduz os encargos de conformidade para operadores. 

Ao contrário dos requisitos de compartilhamento de dados customizados do passado, a padronização de dados de mobilidade compartilhada beneficia tanto as cidades quanto os operadores. A padronização dos dados de mobilidade através da GBFS resultou em um mercado crescente de serviços e software de gestão de dados, proporcionando uma melhor qualidade e uma maior variedade de soluções disponíveis. Estes produtos e serviços são usados para ajudar os reguladores da mobilidade e outras autoridades públicas a trabalhar com dados GBFS para gerenciar e regular eficazmente os serviços de mobilidade.

Políticas que exigem dados abertos padronizados podem impedir a criação de ‘jardins murados’, um cenário de compras em que as cidades ficam dependentes de ferramentas ou serviços proprietários de um fornecedor específico. Dados abertos e padronizados são portáteis, permitindo que as cidades mudem de operador caso um serviço não atenda às expectativas.

Para os operadores, padronização significa o fim de um trabalho de ajuste normativo que requer dados diferentes em formatos diferentes para cada cidade em que operam. A padronização proporciona aos operadores a garantia de que os pedidos de dados sejam claramente definidos e possam ser totalmente implementados. O GBFS também tem o potencial de atrair mais utilizadores para a plataforma de um operador através da integração com aplicações de terceiros. Como padrão de código aberto baseado em consenso, os operadores têm voz igual à das cidades no desenvolvimento contínuo da especificação GBFS. Documentação e recursos abrangentes estão disponíveis tanto para as cidades quanto para os operadores para ajudar na implementação.

Foto: Jean-Louis Zimmermann

Recomendações

Incluir a GBFS como parte de um pedido de propostas.

Seu pedido de propostas deve exigir como requisito uma API da GBFS acessível ao público e deve estabelecer expectativas para os dados necessários para atingir as metas de suas políticas.

Exemplos de redação do pedido de propostas

Requisitos de compartilhamento de dados

  • Uma API acessível ao público em conformidade com a versão atual da General Bikeshare Feed Specification (GBFS) disponível em https://github.com/NABSA/gbfs/.
  • A API da GBFS deve estar disponível ao público na internet livre sem a necessidade de autenticação.

Determinar quais dados devem ser obrigatórios em uma política abrangente.

À medida em que a indústria da mobilidade compartilhada evolui, a GBFS evolui para incluir novas funcionalidades, capacidades e serviços. É por isso que você lerá “ou seu equivalente” nos exemplos de redação da política e nas informações detalhadas da GBFS que se seguem. Exigir que um operador de mobilidade compartilhada forneceça um feed de GBFS público não garante que os dados atendam às necessidades regulatórias ou outras. 

Ao desenvolver políticas de dados, é uma boa idéia reunir a contribuição de especialistas no assunto que estarão envolvidos na implementação do programa. Estes podem incluir pessoal de seu departamento de TI, da Procuradoria Geral do Município, funcionários da prefeitura ou terceiros envolvidos na análise de dados.

A GBFS é projetada para acomodar as necessidades de uma grande variedade de plataformas de mobilidade e usos, desde as bicicletas compartilhadas tradicionais com base em uma estação até bicicletas soltas, scooters, e outros veículos. A especificação consiste em treze arquivos ou pontos de extremidade (endpoints) que contêm diferentes tipos de dados de mobilidade. Alguns destes arquivos e seus campos associados são obrigatórios para estar em conformidade com a especificação, enquanto outros são opcionais. Quais destes arquivos são exigidos pela especificação depende do tipo específico de sistema de mobilidade que está sendo representado. Os arquivos e campos opcionais fornecem dados adicionais para fins e casos de uso específicos. Os municípios podem exigir alguns destes arquivos ou campos opcionais em seus regulamentos para fornecer informações adicionais de apoio aos viajantes, metas municipais ou outras necessidades.

Foto: Spin

Visão geral dos arquivos GBFS

Nome do ArquivoObrigatoriedade
gbfs.jsonObrigatório – Este arquivo é um índice de URLs para todos os outros arquivos publicados como parte de uma API da GBFS.  Para disponibilizar os dados ao público, um link para este arquivo deve ser publicado no site da prefeitura, da agência ou em um portal de dados abertos. 
gbfs_versions.jsonOpcional – Este arquivo lista todos os arquivos publicados pelo operador, de acordo com suas versões. A manutenção de feeds em versões anteriores à medida que novas versões da GBFS se tornam disponíveis pode evitar a interrupção de aplicações downstream.
system_information
.json
Obrigatório – Este arquivo contém informações básicas sobre o sistema de mobilidade compartilhada, porém a maioria dos campos são opcionais. As melhores práticas são a publicação dos campos opcionais phone_number, e-mail e feed_contact_email. Campos opcionais adicionais podem ser úteis, dependendo de seu caso de uso.
vehicle_types.jsonCondicionalmente obrigatório – Este arquivo é exigido de sistemas que incluam informações sobre tipos de veículos no arquivo free_bike_status ou seu equivalente. Este arquivo deve ser publicado pelos sistemas que oferecem múltiplos tipos de veículos para aluguel, por exemplo, bicicletas de pedal e bicicletas elétricas (e-bikes). Se este arquivo não for publicado, presume-se que todos os veículos no feed sejam bicicletas não motorizadas.
station_information
.json
Condicionalmente obrigatório – Este arquivo é necessário para sistemas que utilizam vagas em estações. Qualquer estação definida neste arquivo deve ter uma entrada correspondente no arquivo station_status.json. Ele contém uma lista de todas as estações, suas capacidades de vagas ou estacionamento, e localizações. Ele suporta a configuração de estações virtuais que podem ser usadas para designar áreas de estacionamento aprovadas, tais como bicicletários ou áreas com geofencing para veículos não baseados em estações. Esta informação pode ser usada para dar suporte a restrições de estacionamento para veículos sem base através do uso de áreas de estacionamento designadas.
station_status.jsonCondicionalmente obrigatório – Este arquivo é necessário para sistemas que utilizam vagas baseadas em estações e  pode ser usado opcionalmente em sistemas sem base para monitorar estações virtuais.  Qualquer estação definida neste arquivo deve ter uma entrada correspondente no arquivo station_information.json. Este é um arquivo em tempo real que mostra o status atual de uma estação ou estação virtual, seus veículos e suas vagas. Ele inclui números agregados de veículos e vagas disponíveis que podem opcionalmente ser agregados por tipo de veículo. Estes dados podem ser usados para determinar a distribuição equitativa dos serviços. O campo opcional num_bikes_disabled ou seu equivalente pode ser útil para determinar o número total de veículos implantados ou a porcentagem da frota de veículos que pode ser alugada.
free_bike_status.jsonCondicionalmente obrigatório Este arquivo (ou seu equivalente) é necessário para veículos soltos (sem vaga na estação) ou híbridos (com vaga/sem vaga). É opcional para veículos baseados na estação (com vaga). Este é um arquivo em tempo real que mostra a localização atual, status de disponibilidade, e outros atributos de veículos individuais de uma frota. Opcionalmente pode ser usado em sistemas baseados em estações (com vagas) para publicar informações sobre tipos de veículos, níveis de carga ou combustível, e outros atributos do veículo. Estes dados podem ser usados para determinar o número de veículos implantados, sua disponibilidade para aluguel e sua distribuição dentro da área de serviço.
system_hours.jsonOpcional – Este arquivo é usado para indicar horas e dias de operação quando os veículos estão disponíveis para aluguel. Deve ser obrigatório se o serviço não estiver disponível por 24 horas por dia, 7 dias por semana. Se este arquivo não for publicado, indica que os veículos estão disponíveis para aluguel 24 horas por dia, 7 dias por semana. (Este arquivo poderá tornar-se obsoleto no futuro; nesse caso, o horário do sistema deverá ser publicado usando o método descrito na versão apropriada).
system_calendar.jsonOpcional – Este arquivo opcional deve ser obrigatório para sistemas que operam sazonalmente ou que não ofereçam serviço contínuo durante todo o ano. (Este arquivo poderá tornar-se obsoleto no futuro; nesse caso, o horário do sistema deverá ser publicado usando o método descrito na versão apropriada).
system_regions.jsonOpcional – Este arquivo é usado para definir regiões dentro de um sistema. Ele pode ser usado para suportar relatórios em sistemas que abrangem múltiplas jurisdições.
system_pricing_plans
.json
Opcional – Este arquivo descreve os planos de preços para um sistema. É útil para aplicações de planejamento de viagens de terceiros, mas pode não ser suficientemente abrangente para modelar todos os preços disponíveis para o sistema.
system_alerts.jsonOpcional – Este arquivo destina-se a alertar os usuários sobre mudanças no sistema que não se enquadram nas operações normais do sistema. Por exemplo, interrupções do sistema devido a condições climáticas extremas seriam listados aqui. As cidades devem tornar este arquivo obrigatório como um meio de comunicação de informações de emergência ou de outra ordem aos usuários.
geofencing_zones
.json
Opcional – Este arquivo descreve as zonas delimitadas por geofencing e suas regras ou atributos associados. As zonas geograficamente cercadas (geofenced) podem ser usadas para comunicar informações relativas a estacionamento, limites de velocidade, zonas de pedestres, ou outras regras ou restrições. Elas podem ser usadas para definir geografias relacionadas à equidade, limites de veículos, ou outros casos de uso. As cidades devem impor obrigatoriedade deste arquivo se suas políticas se basearem em informações de delimitação geográfica (geofencing). Deve-se tomar cuidado ao desenvolver políticas geoespaciais que se baseiem em dados de localização. Os dados de localização dos sinais GPS, celulares e Wi-Fi estão sujeitos a interferência, resultando em graus de precisão da ordem de dezenas de metros ou mais.   

Recomendações sobre política de dados

As políticas de dados devem incluir linguagem clara e aplicável, definindo exatamente os dados necessários e a versão da especificação a ser publicada.

No mínimo, uma política de dados de mobilidade compartilhada deve:

  • Garantir acesso contínuo aos dados tanto para o órgão regulador quanto para o público, sem restrições indevidas a seu uso.
  • Definir claramente o formato e a versão dos dados necessários.
  • Garantir o acesso a dados específicos necessários para licenciar, regular e gerenciar efetivamente os provedores de mobilidade compartilhada.
  • Proteger a privacidade dos indivíduos que utilizam a plataforma de mobilidade.

Exemplos de redação da política

[EMPRESA] deverá fornecer uma API acessível ao público que esteja em conformidade com a versão atual da General Bikeshare Feed Specification (GBFS) disponível em https://github.com/NABSA/gbfs/ .

[EMPRESA] deverá disponibilizar a API ao público na internet aberta, sem exigir autenticação.

[EMPRESA] informará [AGÊNCIA LICENCIADORA] a URL do endpoint gbfs.json antes de implantar os veículos. [EMPRESA] deverá notificar [AGÊNCIA LICENCIADORA] pelo menos 30 dias antes de alterar a URL do endpoint gbfs.json.

Os dados contidos na API serão disponibilizados ao público e [AGÊNCIA LICENCIADORA] sob uma licença não revogável que permita que os dados da API sejam utilizados, modificados e compartilhados sem restrições além da atribuição.

Ao lançar uma nova versão da GBFS, [EMPRESA] deve atualizar a API para a nova versão dentro de [XX1] dias, a menos que haja um acordo prévio com [AGÊNCIA LICENCIADORA].

  1. recomenda-se 90 dias

A API da GBFS deve conter os seguintes endpoints e todos os campos obrigatórios de acordo com a especificação GBFS

  • gbfs.json
  • system_information.json
  • [lista de endpoints adicionais, por exemplo: station_information.json, station_status.json, free_bike status.json ou equivalente, etc.]

Além dos campos obrigatórios nos termos da especificação, os seguintes arquivos também devem conter estes campos opcionais

  • file_name.json: field_name, field name
  • file_name.json: field_name, field name 

Para um exemplo de como um regulador pode adaptar esta língua às suas necessidades particulares, ver a linguagem da scooter da SFMTA (em inglês, a partir da página 41).

Considerações adicionais

O valor dos dados de mobilidade aberta só pode ser plenamente realizado quando tais dados são facilmente acessíveis ao público e a privacidade dos viajantes é protegida; o GBFS foi concebido para suportar ambos. As cidades e as autoridades de transportes devem publicar os locais dos ficheiros gbfs.json nos seus websites ou abrir portais de dados e também no catálogo de dados aberto ligado ao GBFS.

O pedido de dados abertos de operadores de mobilidade partilhada tornar-se-á ainda mais crucial nos próximos anos, uma vez que a Comissão Europeia impõe a cada Estado membro a obrigação de estabelecer um Ponto de Acesso Nacional (PNA) para actuar como um portal para todos os dados abertos relacionados com serviços de mobilidade e todas as informações para os cidadãos. Os PAN são concebidos para promover um ecossistema europeu próspero baseado na interoperabilidade entre modos de mobilidade e regiões, reforçando a capacidade de qualquer cidadão de viajar sem problemas dentro da União Europeia. O GBFS é um formato comum e aceite que permite aos países cumprirem a directiva da UE a vários níveis:

  • Cumpre a vontade de criar um mercado comum aberto, o que evitará posições monopolistas;
  • Permite a transparência dos dados e apoia os esforços europeus para abrir mais dados para que os consumidores possam participar na vida das instituições;
  • Protege a privacidade dos utilizadores, assegurando que apenas a informação pública seja publicada, no espírito do Regulamento Geral de Protecção de Dados (GDPR); 
  • Apoia uma mobilidade mais ecológica e mais sustentável onde os utilizadores têm outras opções para além da condução sozinhos;
  • É totalmente compatível com as normas e padrões europeus.

Para abrir os dados, alguns NAPs, tais como o gerido pela Entur na Noruega ou o data.gouv.fr francês, criaram uma equipa para ajudar os operadores de mobilidade a abrir os seus dados. Se necessário, as suas orientações sobre como tirar partido do GBFS estão disponíveis mediante pedido.

A GBFS foi desenvolvida e testada em um modelo consensual para garantir que os dados definidos na especificação não afetarão negativamente a privacidade do usuário. As versões actuais do GBFS são compatíveis com o GDPR no sentido em que não contêm quaisquer dados pessoais ou pessoalmente identificáveis.  O ponto-chave a lembrar é que com GBFS não existe uma forma trivial de reconstruir a viagem ou hábitos de um único utilizador graças à rotação obrigatória de VINs.

Deve-se tomar extremo cuidado ao exigir dados de operadores que estejam fora do escopo da especificação.  Os dados referentes a veículos que fazem parte de um aluguel ativo nunca devem aparecer em feeds de GBFS. A coleta excessiva de dados – coletar dados sem finalidade definida – é fortemente desencorajada. A combinação de dados de mobilidade compartilhada com outros conjuntos de dados disponíveis publicamente poderia ter sérias implicações quanto à privacidade. Também se deve ter o cuidado de respeitar o espírito da GDPR, que afirma que a recolha de dados deve ser adequada e proporcional às necessidades das operações e não pode conter qualquer informação de identificação sem o consentimento claro dos indivíduos.

Para apoiar uma melhor interoperabilidade na Europa, o CEN desenvolveu o Transmodel (a norma europeia “Reference Data Model for Public Transport” (EN 12896)), uma norma de dados que facilita a interoperabilidade entre os sistemas de processamento de informação dos operadores e agências de transporte através da utilização de definições, estruturas e semântica correspondentes para os elementos de dados utilizados pelos seus diferentes sistemas. Com base no modelo Transmodel, foram definidas outras normas: NeTEx (CEN/TS 16614-1/2/3/3/5) para o intercâmbio de informações sobre horários de transportes públicos, e SIRI (EN 15531-1/2/3/3/4/5) para a informação em tempo real. Ambos estão a ser adaptados a “novos modos”, incluindo soluções de mobilidade partilhada. 

GBFS é a única norma de dados aberta, utilizada internacionalmente, que foi reconhecida pelo CEN como compatível e convertível com NeTEx/SIRI, com base num mapeamento canónico que será em breve aprovado pelo CEN. Esta convertibilidade reduz o peso da produção e consumo de dados para todos os intervenientes no sector da mobilidade partilhada.

Links úteis

* principalmente em inglês com alguns recursos em espanhol

Email da equipe de Mobilidade Compartilhada na MobilityData: sharedmobility@mobilitydata.org

Agradecimentos

Equipe de Mobilidade Compartilhada na MobilityData

Heidi Guenin, Diretora, Produto, Mobilidade Compartilhada 

Mitch Vars, Sênior, Especialista em Mobilidade Compartilhada 

Josée Sabourin, Especialista em Mobilidade Compartilhada 

Partnerships, Europa na MobilityData

Tu-Tho Thai, Diretora, Partnerships, Europa

Newton Davis, Partnerships, Europa

Revisores

Josh Johnson, Public Policy Manager, Spin

Oliver O’Brien, Senior Research Associate, University College London

Scott Shepard, VP Global Public Sector, Iomob

Este documento é elaborado com a intenção de apoiar e ajudar as cidades na adoção da GBFS e não se destina a assessoria jurídica. Os formuladores de políticas devem determinar se é necessária uma consideração adicional das leis e estatutos locais antes de utilizar o exemplo de redação de política contido neste documento.