Saltar a contenido

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.

Esta guía está disponible en inglés, portugués y francés.

Información general

La seguridad del 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 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 otras autoridades. 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.

Rep√ļblica del burro

Foto: Martti Tulenheimo.

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.

Desde su creación en 2015, GBFS se ha convertido en el estándar de facto para datos de movilidad compartidos. La especificación ahora se utiliza en cientos de ciudades en al menos 45 países en todo el mundo.

Los formuladores de pol√≠ticas deber√≠a require API GBFS p√ļblicas al permitir o otorgar licencias para operaciones de movilidad compartida.

Desde su creación en 2015, GBFS se ha convertido en el estándar de facto para datos de movilidad compartidos. Actualmente, la especificación se usa en cientos de ciudades en al menos 45 países en el mundo.

Los responsables pol√≠ticos deber√≠an exigir APIs p√ļblicas de GBFS al autorizar o conceder licencias a los operadores 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
  • Zonas geogr√°ficamente reguladas 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 y viajes multimodales, lo que hace posible un mayor n√ļmero de viajes sin autom√≥viles.

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 autoridades de regulaci√≥n de la movilidad y otras autoridades p√ļblicas 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. GBFS también tiene el potencial de atraer más usuarios a la plataforma de un operador al integrarse con aplicaciones de terceros. 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.

Vélib

Foto: Jean-Louis Zimmermann.

Recomendaciones

Incluir el GBFS como parte de una solicitud de propuesta.

Su solicitud de propuesta 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 para la 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/MobilityData/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 sus departamentos de tecnología, licencias o regulación 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 12 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.

Girar

Foto: Spin.

Descripción general de los archivos del GBFS

Nombre del archivo Donde sea requerido ‚Äď Descripci√≥n
gbfs.json Obligatorio : 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.
manifest.json Requerido condicionalmente : Este archivo es un índice de URL de gbfs.json para cada conjunto de datos GBFS producido por un editor.
gbfs_versions.json Opcional : 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 y email. Los campos opcionales adicionales pueden ser √ļtiles seg√ļn su caso de uso.
vehicle_types.json Requerido condicionalmente : este archivo es obligatorio para los sistemas que incluyen información sobre los tipos de vehículos en el archivo vehicle_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. 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.json Requerido 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_vehicles_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.
vehicle_status.json Requerido condicionalmente : este archivo o su equivalente 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_regions.json Opcional : 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.json Opcional : 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/MobilityData/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, vehicle_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, field name
  • file_name.json: field_name, field name

Para ver un ejemplo de cómo un regulador puede adaptar este lenguaje a sus necesidades particulares, consulte el lenguaje de permisos de scooter de la SFMTA (en Inglés, y que comienza en la página 41).

Consideraciones adicionales

El valor de los datos abiertos de movilidad s√≥lo puede aprovecharse plenamente cuando esos datos son f√°cilmente accesibles para el p√ļblico y se protege la privacidad de los viajeros; GBFS est√° dise√Īado para apoyar ambas cosas. Las ciudades y las autoridades de transporte deber√≠an publicar las ubicaciones de los archivos gbfs.json en sus sitios web o portales de datos abiertos y tambi√©n en el cat√°logo de datos de libre acceso conectado a GBFS.

La solicitud de datos abiertos a los operadores de movilidad compartida ser√° a√ļn m√°s crucial en los pr√≥ximos a√Īos, ya que la Comisi√≥n Europea impone la obligaci√≥n de que cada estado miembro establezca un punto de acceso nacional (NAP) que act√ļe como portal de todos los datos abiertos en relaci√≥n con los servicios de movilidad y toda la informaci√≥n destinada a los ciudadanos. Los NAP est√°n dise√Īados para fomentar un pr√≥spero ecosistema europeo basado en la interoperabilidad entre los modos de movilidad y las regiones, fortaleciendo la capacidad de cualquier ciudadano para viajar sin problemas dentro de la Uni√≥n Europea. El GBFS es un formato com√ļn y aceptado que permite a los pa√≠ses cumplir con la directiva europea en varios niveles:

  • Cumple con la voluntad de crear un mercado com√ļn abierto, lo que evitar√° posiciones monopol√≠sticas;
  • Permite la transparencia de los datos y apoya los esfuerzos europeos para abrir m√°s datos para que los consumidores participen en la vida de las instituciones;
  • Protege la privacidad de los usuarios garantizando que s√≥lo se publique informaci√≥n p√ļblica, de acuerdo con el esp√≠ritu del reglamento general de protecci√≥n de datos (RGPD);
  • Apoya una movilidad m√°s ecol√≥gica y sostenible en la que los usuarios tienen opciones distintas a la de conducir en solitario;
  • Es totalmente compatible con las normas y est√°ndares europeos.

Para abrir los datos, algunos NAP, como el gestionado por Entur en Noruega o el francés data.gouv.fr, han creado un equipo para ayudar a los operadores de movilidad a abrir sus datos. Si es necesario, se puede solicitar su orientación sobre cómo aprovechar el GBFS.

El GBFS se ha desarrollado y probado bajo un modelo de consenso para garantizar que los datos definidos en la especificaci√≥n no afecten negativamente a la privacidad del usuario. Las versiones actuales de GBFS cumplen con el RGPD, en el sentido de que no contienen ning√ļn dato personal o de identificaci√≥n personal. El punto clave que hay que recordar es que con GBFS no hay una forma trivial de reconstruir el viaje o los h√°bitos de un solo usuario gracias a la rotaci√≥n obligatoria de los n√ļmeros de identificaci√≥n del veh√≠culo.

Se debe tener mucho cuidado cuando se requieran datos de los operadores que est√©n fuera del alcance de la especificaci√≥n. Los datos relativos a los veh√≠culos que forman parte de un alquiler activo nunca deben aparecer en los feeds de GBFS. Se desaconseja encarecidamente la recopilaci√≥n excesiva de datos, es decir, la obtenci√≥n 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 para la privacidad. Tambi√©n habr√° que tener cuidado con el cumplimiento del esp√≠ritu del RGPD, que establece que la recogida de datos debe ser adecuada y proporcionada a las necesidades de las operaciones y no puede contener ninguna informaci√≥n de identificaci√≥n sin el claro consentimiento de las personas.

Para apoyar una mejor interoperabilidad en Europa, el CEN ha desarrollado Transmodel (la norma europea ‚ÄúModelo de datos de referencia para el transporte p√ļblico‚ÄĚ (EN 12896)), un est√°ndar de datos que facilita la interoperabilidad entre los sistemas de procesamiento de informaci√≥n de los operadores y agencias de transporte mediante el uso de definiciones, estructuras y sem√°ntica coincidentes para los elementos de datos utilizados por sus distintos sistemas. Sobre la base de Transmodel, se han definido otras normas: NeTEx (CEN/TS 16614-1/2/3/5) para el intercambio de informaci√≥n sobre horarios de transporte p√ļblico, y SIRI (EN 15531-1/2/3/4/5) para la informaci√≥n en tiempo real. Ambas se est√°n adaptando a los ‚Äúnuevos modos‚ÄĚ, incluidas las soluciones de movilidad compartida.

GBFS es el √ļnico est√°ndar de datos abiertos, utilizado internacionalmente, que ha sido reconocido por el CEN como compatible y convertible con NeTEx/SIRI sobre la base de un mapeo can√≥nico que pronto ser√° aprobado por el CEN. Esta convertibilidad reduce la carga de producci√≥n y consumo de datos para todas las partes interesadas del sector de la movilidad compartida.

Enlaces √ļtiles

* 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

Heidi Guenin, Mitch Vars, Josée Sabourin, Tu-Tho Thai y Newton Davis.

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 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.