June 30, 2021 8:48 pm

GBFS y política de datos de movilidad compartida

Ayudar a las ciudades a respaldar opciones de movilidad integradas y sostenibles a través de GBFS.

Información general

Asegurar el acceso a los datos de movilidad es una parte importante de un programa de movilidad compartida. El acceso público a los datos de movilidad genera confianza en los programas de movilidad y aumenta la adopción de la movilidad compartida. La redacción de una política eficaz puede garantizar que los datos de movilidad sean precisos y accesibles.

Este informe está dirigido principalmente a las personas responsables de las políticas y adquisiciones de movilidad compartida en ciudades u otros municipios. El informe proporciona una comprensión fundamental de cómo GBFS admite opciones de movilidad integradas y sostenibles y cómo aprovechar el potencial de los datos de código abierto al redactar políticas que pueden influir en la adopción y práctica de la movilidad compartida. El lenguaje de política específico se aplica principalmente a las ciudades de las Américas. Para las partes interesadas europeas, se publicará un informe específico en el verano de 2021. 

Photo: Alejandro De La Cruz

Cómo GBFS puede apoyar el esfuerzo de las ciudades para ofrecer transporte sostenible

GBFS facilita a los viajeros la búsqueda y el uso de la movilidad compartida

Los reguladores de políticas deben exigir APIs del GBFS públicas al permitir u otorgar licencias para operaciones de movilidad compartida.  El GBFS proporciona un lenguaje común para que los operadores de movilidad compartida compartan información sobre las opciones disponibles para los viajeros. El GBFS incluye información sobre vehículos (bicicletas, patinetes, ciclomotores y automóviles), estaciones y más:

  • Ubicación y disponibilidad de vehículos, estaciones y anclajes
  • Características del vehículo: tipo de potencia, distancia que se puede recorrer con la carga restante
  • Áreas geovalladas para reglas relacionadas con la velocidad, estacionamiento y zonas prohibidas

Estos datos son utilizados por las aplicaciones de planificación de viajes y movilidad como servicio (‘Mobility as a Service’ o ‘MaaS’) para proporcionar a los viajeros la información que necesitan para descubrir y elegir la movilidad compartida. Las APIs públicas del GBFS permiten la integración de servicios de movilidad compartida con el transporte público, lo que permite a los usuarios realizar conexiones en su trayecto.

Además, el GBFS proporciona a los municipios y agencias una forma estandarizada de ingerir, analizar y comparar los datos generados por los sistemas de movilidad compartida. Los avances en las plataformas de movilidad compartida han dado como resultado la generación de grandes cantidades de datos de movilidad. Estos datos se han convertido en una parte esencial de la formulación de políticas y la regulación de los operadores de movilidad compartida. Los datos de las plataformas de movilidad compartida nos ayudan a comprender cómo estos servicios afectan la seguridad pública y si promueven o no la equidad, la innovación, la sostenibilidad y otros objetivos de política pública. El acceso público a los datos de movilidad compartida aumenta la transparencia y hace que los operadores sean responsables de los servicios que operan en el derecho de paso público.

El GBFS ha sido diseñado específicamente para su uso como una fuente de datos públicos. Para que las APIs (interfaz de programación de aplicaciones) del GBFS sean realmente públicas, deben estar disponibles gratuitamente en Internet y no requieren clave de API, token u otros medios de acceso o autenticación. Los feeds que contienen datos confidenciales que requieren autenticación no deben considerarse un sustituto de las APIs públicas.

El GBFS permite el intercambio de información de una manera que garantiza que todas las partes estén de acuerdo sobre lo que representa la información. Puede pensarse como una especie de diccionario, donde cada término tiene una definición y un conjunto de reglas sobre cómo se pueden utilizar. El GBFS es una especificación de datos en tiempo real. Describe el estado actual de un sistema de movilidad. El GBFS no admite ni está diseñado para datos históricos como serían registros de viajes o de mantenimiento.

El GBFS reduce las cargas administrativas en las ciudades, reduce las cargas de cumplimiento para los operadores.

A diferencia de los requisitos de intercambio de datos personalizados del pasado, la estandarización de los datos de movilidad compartida beneficia tanto a las ciudades como a los operadores. La estandarización de los datos de movilidad a través del GBFS ha dado lugar a un mercado creciente de software y servicios de gestión de datos, proporcionando una mejor calidad y una mayor variedad de soluciones disponibles. Estos productos y servicios se utilizan para ayudar a las ciudades a trabajar con datos del GBFS para gestionar y regular los servicios de movilidad de forma eficaz.

Las políticas que requieren de datos abiertos y seguir estándares pueden evitar la creación de ‘jardines amurallados’, un escenario de adquisiciones donde las ciudades están limitadas a las herramientas o servicios patentados de un proveedor específico. Los datos abiertos y estandarizados son portátiles, lo que permite a las ciudades cambiar de proveedor si un servicio no cumple con las expectativas.

Para los operadores, la estandarización significa el fin de un parche de regulación que requiere diferentes datos en diferentes formatos para cada ciudad en la que operan. La estandarización proporciona a los operadores la garantía de que las solicitudes de datos se pueden definir claramente y se pueden implementar por completo. Como estándar de código abierto basado en consenso, los operadores tienen la misma voz junto con las ciudades en el desarrollo continuo de la especificación del GBFS. Las ciudades y los operadores tienen acceso a la documentación y a los recursos completos para ayudar en la implementación.

Photo: Daniel Garcia Neto

Recomendaciones

Incluir el GBFS como parte de una solicitud de propuesta

Su RFP debe requerir una API del GBFS de acceso público como requisito y debe establecer expectativas de los datos necesarios para cumplir con los objetivos de su política.

Ejemplo de lenguaje de solicitud

Requisitos para compartir datos

  • Una API de acceso público que se ajusta a la versión actual del GBFS disponible en https://github.com/NABSA/gbfs/.
  • La API del GBFS debe estar disponible para el público en Internet abierto sin requerir autenticación.

Determinar qué datos requerir en una política integral

A medida que evoluciona la industria de la movilidad compartida, el GBFS evoluciona para incluir nuevas características, capacidades y servicios. Es por eso que leerá “o su equivalente” en el lenguaje de política de muestra y en la información detallada del GBFS que se muestra a continuación. El simple hecho de requerir que un operador de movilidad compartida proporcione datos públicos del GBFS no garantizará que los datos cumplan con las necesidades reglamentarias o de otro tipo. 

Al desarrollar políticas de datos, es buena idea obtener retroalimentación de expertos en la materia que participarán en la implementación del programa. Estos pueden incluir personal de su departamento de tecnología, la oficina legal de la ciudad, o terceros involucrados en el análisis de datos.

El GBFS está diseñado para adaptarse a las necesidades de una amplia variedad de plataformas de movilidad y casos de uso, desde bicicletas compartidas tradicionales hasta bicicletas sin anclajes, patinetes y otros vehículos. La especificación consta de trece archivos o puntos finales que contienen diferentes tipos de datos de movilidad. Algunos de estos archivos son necesarios para cumplir con la especificación, mientras que otros son opcionales. ¿Cuáles de estos archivos son requeridos por la especificación? depende del tipo específico de sistema de movilidad. Los archivos y campos opcionales proporcionan datos adicionales para propósitos y casos de uso específicos. Es posible que los municipios necesiten exigir algunos de estos archivos o campos opcionales en sus reglamentos para proporcionar información adicional en apoyo de los viajeros, los objetivos municipales u otras necesidades.

Photo: waltarrrrr

Descripción general de los archivos del GBFS

Nombre del archivoDonde sea requerido
gbfs.jsonObligatorio: este archivo es un índice de URL para todos los demás archivos publicados como parte de una API del GBFS. Para que los datos estén disponibles para el público, se debe publicar un enlace en este archivo en el sitio web de la ciudad o agencia o en el portal de datos abiertos. 
gbfs_versions.jsonOpcional: este archivo enumera todos los archivos publicados por el operador según sus versiones. Mantener versiones anteriores del feed cuando existen versiones más nuevas disponibles, ayuda a prevenir interrupciones en las aplicaciones.
system_information
.json
Obligatorio: este archivo contiene información básica sobre el sistema de movilidad compartida; sin embargo, la mayoría de los campos son opcionales. Las mejores prácticas son publicar los campos opcionales phone_number, email  y feed_contact_email. Los campos opcionales adicionales pueden ser útiles según su caso de uso.
vehicle_types.jsonRequerido condicionalmente: este archivo es obligatorio para los sistemas que incluyen información sobre los tipos de vehículos en el archivo free_bike_status o su equivalente. Este archivo debe ser publicado por sistemas que ofrecen varios tipos de vehículos para alquilar, por ejemplo, bicicletas de pedales y bicicletas eléctricas. Si este archivo no se publica, se asume que todos los vehículos del feed son bicicletas no motorizadas.
station_information
.json
Requerido condicionalmente: este archivo es obligatorio para los sistemas con anclajes de vehículos. Cualquier estación definida en este archivo debe tener una entrada correspondiente en el archivo station_status.json file. Contiene una lista de todas las estaciones, sus capacidad de anclaje o estacionamiento y ubicaciones. Admite la configuración de estaciones virtuales que se pueden utilizar para designar áreas de estacionamiento aprobadas, como racks o áreas geovalladas para vehículos sin anclajes. Esta información puede usarse para respaldar las restricciones de estacionamiento para vehículos sin anclajes mediante el uso de áreas de estacionamiento designadas.
station_status.jsonRequerido condicionalmente: este archivo es necesario para los sistemas que utilizan anclajes y, opcionalmente, se puede usar en sistemas sin anclajes para monitorear estaciones virtuales. Cualquier estación definida en este archivo debe tener una entrada correspondiente en el archivo station_information.json. Este es un archivo en tiempo real que muestra el estado actual de una estación o estación virtual, sus vehículos y sus anclajes. Incluye números agregados de vehículos y anclajes disponibles que, opcionalmente, pueden agregarse por tipo de vehículo. Estos datos pueden usarse para determinar la distribución equitativa de servicios. El campo opcional num_bikes_disabled o su equivalente puede ser útil para determinar el número total de vehículos desplegados o el porcentaje de la flota de vehículos que se puede alquilar. 
free_bike_status.jsonRequerido condicionalmente: este archivo (o su equivalente en v3.0) es necesario para vehículos que flotan libremente (sin anclajes) o híbridos (pueden usar anclajes o no). Es opcional para vehículos basados en estaciones (solo se usa con anclajes). Este es un archivo en tiempo real que muestra la ubicación actual, el estado de disponibilidad y otros atributos de los vehículos individuales de una flota. Puede usarse opcionalmente en sistemas basados en estaciones (solo se usa con anclajes) para publicar información sobre tipos de vehículos, niveles de carga o combustible y otros atributos del vehículo. Estos datos pueden usarse para determinar la cantidad de vehículos desplegados, su disponibilidad para alquiler y su distribución dentro del área de servicio.
system_hours.jsonOpcional: este archivo se utiliza para indicar las horas y los días de funcionamiento cuando los vehículos están disponibles para alquilar. Debería ser obligatorio si el servicio no está disponible las 24 horas del día, los 7 días de la semana. Si este archivo no se publica, indica que los vehículos están disponibles para alquiler 24 horas al día, 7 días a la semana. Este archivo puede quedar obsoleto en el futuro, en cuyo caso las horas del sistema deben publicarse utilizando el método descrito en la versión correspondiente.
system_calendar.jsonOpcional: este archivo opcional debe exigirse a los sistemas que operan estacionalmente o que no ofrecen un servicio continuo durante todo el año. Este archivo puede quedar obsoleto en el futuro, en cuyo caso la información del calendario debe publicarse utilizando el método descrito en la versión correspondiente.
system_regions.jsonOpcional: este archivo se utiliza para definir regiones dentro de un sistema. Puede usarse para respaldar la presentación de informes en sistemas que abarcan múltiples jurisdicciones.
system_pricing_plans
.json
Opcional: este archivo describe los planes de precios para un sistema. Es útil para aplicaciones de planificación de viajes de terceros, pero puede que no sea lo suficientemente completo como para modelar todos los precios disponibles para el sistema.
system_alerts.jsonOpcional: este archivo está diseñado para alertar a los viajeros sobre cambios en el sistema que no se encuentran dentro de las operaciones normales del sistema. Por ejemplo, aquí se enumeran los cierres de sistemas debido a condiciones climáticas extremas. Las ciudades deberían exigir este archivo para su uso como medio de comunicar emergencias u otra información a los viajeros.
geofencing_zones
.json
Opcional: este archivo describe las zonas geovalladas y sus reglas o atributos asociados. Las zonas geovalladas pueden usarse para comunicar información sobre estacionamiento, límites de velocidad, zonas prohibidas u otras reglas o restricciones. Pueden usarse para definir geografías relacionadas con la equidad, límites de vehículos u otros casos de uso. Las ciudades deberían requerir este archivo si sus políticas se basan en información de geovallas. Se debe tener cuidado al desarrollar políticas geoespaciales que se basan en datos de ubicación. Los datos de ubicación de las señales del GPS, celulares y Wi-Fi están sujetos a interferencias que dan como resultado niveles de precisión de decenas de metros o más. 

Recomendaciones de la política de datos

Las políticas de datos deben incluir un lenguaje claro que los reguladores puedan hacer cumplir. El lenguaje debe describir exactamente qué datos se requieren y qué versión de la especificación deben cumplir.

Como mínimo, una política de datos de movilidad compartida debería:

  • Garantizar el acceso continuo a los datos tanto para los reguladores como para el público sin restricciones indebidas sobre su uso.
  • Definir claramente el formato y la versión de los datos requeridos.
  • Garantizar el acceso a los datos específicos necesarios para permitir, regular y gestionar de forma eficaz los operadores de movilidad compartida.
  • Protejer la privacidad de las personas que utilizan la plataforma de movilidad.

Ejemplo de lenguaje de política

[COMPAÑÍA] proporciona una API de acceso público que se ajuste a la versión actual del GBFS (General Bikeshare Feed Specification) disponible en https://github.com/NABSA/gbfs/. [COMPAÑÍA] debe poner la API a disposición del público en Internet abierto sin requerir autenticación.

[EMPRESA] informará a la [AGENCIA QUE PERMITE] de la dirección del punto final gbfs.json antes del despliegue de vehículos. [COMPAÑÍA] debe notificar a la [AGENCIA QUE PERMITE] al menos 30 días antes de cambiar la URL del punto final gbfs.json.

Los datos contenidos en la API se ofrecerán al público y a la [AGENCIA QUE PERMITE] bajo una licencia irrevocable que permite que los datos de la API se utilicen, modifiquen y compartan sin restricciones más allá de la atribución.

Tras el lanzamiento de una nueva versión del GBFS, [COMPAÑÍA] debe actualizar la API a la nueva versión dentro de los [XX1] días, a menos que se haya hecho un acuerdo previo con la [AGENCIA QUE PERMITE].

  1. Recomendado 90 días

La API del GBFS debe contener los siguientes puntos finales y todos los campos requeridos según la especificación de GBFS:

  • gbfs.json
  • system_information.json
  • [lista de puntos finales adicionales, p. ej. station_information.json, station_status.json, free_bike status.json, etc.]

Además de los campos requeridos bajo la especificación, los siguientes archivos también deben contener estos campos opcionales:

  • file_name.json: field_name, nombre de campo
  • file_name.json: field_name, nombre de campo

Consideraciones adicionales

El valor de los datos de movilidad abiertos solo se puede realizar plenamente cuando el público puede acceder fácilmente a esos datos. Las ciudades y agencias deben publicar las ubicaciones de los archivos gbfs.json en sus sitios web o portales de datos abiertos y en el catálogo de conjuntos de datos disponible abiertamente conectado a GBFS.

El GBFS ha sido desarrollado y probado bajo un modelo de consenso para garantizar que los datos definidos en la especificación no afecten negativamente la privacidad del usuario. Se debe tener mucho cuidado cuando se requieran datos de los operadores que estén fuera del alcance de la especificación. ( El exceso de recopilación de datos – Se desaconseja categóricamente la recogida de datos sin un propósito definido. La combinación de datos de movilidad compartidos con otros conjuntos de datos disponibles públicamente podría tener graves implicaciones en la privacidad.) Los datos sobre vehículos que forman parte de un alquiler activo nunca deben aparecer en conjuntos de datos públicos del GBFS.

Enlaces útiles

GBFS Centro de Recursos* 

GBFS repositorio en GitHub

GBFS canal público de Slack*

GBFS & datos abiertos – NABSA*

* principalmente en inglés con algunos recursos en español

Correo electrónico del equipo de movilidad compartida de MobilityData: sharedmobility@mobilitydata.org

Nuestro equipo habla español, así que no dude en enviarnos cualquier pregunta o solicitud.

Agradecimientos

Equipo de movilidad compartida en MobilityData

Heidi Guenin, Directora, Producto, Movilidad Compartida 

Mitch Vars, Especialista Senior en Movilidad Compartida 

Josée Sabourin, Especialista en Movilidad Compartida

Revisores

Diego Canales, Global Partnerships Manager, Populus AI

Josh Johnson, Public Policy Manager, Spin

Andrew Salzberg, Head of Policy, Transit

Michael Schwartz, Head of Customers and Policy, Ride Report

Este documento se creó con la intención de apoyar y ayudar a las ciudades en la adopción del GBFS y no sirve como asesoramiento legal. Este documento no pretende servir como asesoramiento legal. Los responsables de la formulación de políticas deben determinar si es necesaria una consideración adicional de las leyes y estatutos locales antes de utilizar el lenguaje de política de muestra contenido en este documento.