May 7, 2020 5:25 pm

¿Qué hay de nuevo en GBFS v2.0? 🚲🛴

** Desde este artículo, hemos realizado muchos cambios. Para obtener más información sobre versiones más recientes de GBFS, visite nuestros artículos sobre v2.2 y v2.3-RC (¡junto con enlaces a traducciones!) **

El nuevo estándar de datos de micromovilidad mejora la movilidad compartida

¿Conoce velocípedo? Incluso si no conoce el nombre, apuesto a que lo ha visto en imágenes:

A “penny-farthing” — the v1.0 of bicycles (Source: Wikipedia)

El velocípedo es la bicicleta de antaño con una rueda grande en el frente y una pequeña rueda en la parte trasera. Cuando el velocípedo llegó al mercado, ofreció velocidades más rápidas y mejor absorción de impactos que sus predecesores con ruedas.

Estuvo de moda por casi una década a finales del siglo XIX. Pero no duró mucho debido a la aparición de la bicicleta, como la conocemos hoy.

¿Fue la bicicleta antigua innovadora? Si 👍. ¿Fue la bicicleta que la reemplazó mejor? Absolutamente 👍👍.

La versión 2.0 de GBFS para datos de bicicletas y patinetes compartidos también hace mejoras claves en la versión anterior, que ya era buena. La versión 2.0 es la sucesora de la versión original creada por NABSA en 2015.

En 2019, NABSA eligió MobilityData para coordinar la comunidad de GBFS, para cambiar procesos y satisfacer las necesidades de la industria. Sin embargo, no creamos v2.0 solos; hemos trabajado juntos como una comunidad para hacer más fácil encontrar opciones de movilidad. Estamos muy agradecidos por la inmensa participación continua de la comunidad en los talleres de MobilityData y en GitHub 🙌.

GBFS v2.0 makes it easier for apps like Transit and Google Maps to seamlessly integrate with micromobility provider apps

Novedades en v2.0 🎉

GBFS v1.0 tuvo un gran éxito — más de 230 operadores de bicicletas y patinetes compartidos lo han adoptado para compartir información en tiempo real con aplicaciones usadas por millones de usuarios alrededor del mundo. Sin embargo, en paralelo que la micromovilidad compartida aumentaba en popularidad, hubo un incremento del número de casos que GBFS no pudo servir perfectamente, así como las aclaraciones necesarias sobre cómo o se deben usar ciertos campos. A continuación , se incluyen mejoras nuevas en GBFS v2.0.

Vínculos directos — “deep links” 🔗

El principal uso de GBFS es hacer visible los vehículos disponibles para alquilar en las aplicaciones móviles creadas por terceros. Cuando un usuario ve la bicicleta o patinete que quiere, solo tiene que hacer un clic en el icono del vehículo que quiere alquilar 👆. Sin embargo, este fue uno de los puntos débiles de la versión 1.0. Le faltaba información para crear un enlace entre las aplicaciones móviles creadas por terceros a las aplicaciones nativas de los operadores.

GBFS v2.0 permite el soporte de los vínculos directos (“deep links”). Esto permite una mejor experiencia de viaje: ahora puede elegir una bicicleta o un patinete en la aplicación de terceros, y la aplicación de alquiler del proveedor se abre de inmediato para ese vehículo o estación en particular.

Los vínculos directos son compatibles de diferentes maneras, descritas en las siguientes subsecciones.

App Links en Android y Universal Links en iOS 📱

El método preferido para que los proveedores de GBFS implementen los vínculos directos (“deep links”) se llama “Android App Links” en Android y “Universal Links” en iOS. Estos formatos de vínculos directos requieren una configuración adicional en el sitio web del proveedor además de la aplicación nativa del proveedor, pero agregan los siguientes beneficios sobre los formatos de vínculos directos anteriores:

  • Al elegir el vehículo para alquilar, el viajero siempre se dirige a la aplicación del proveedor correcta: no tiene que hacer clic en los cuadros de diálogo intermedios para abrir el enlace en un navegador o aplicación nativa.
  • Las aplicaciones de terceros no tienen que verificar manualmente si la aplicación del proveedor está instalada o no en el dispositivo y redirigirla a la tienda de aplicaciones respectiva, esta situación es manejada automáticamente por el sistema operativo.
  • Puede definir vínculos directos que funcionen tanto en el navegador web como en plataformas nativas.

Después de que un proveedor de GBFS haya implementado Android App Links y Universal Links en sus aplicaciones y sitio web nativos, deberá agregar una sección rental_apps con discovery_uris a su archivo GBFS system_information.json.

system_information.json

{
  "last_updated": 1572447999,
  "data": {
    "system_id": "abc_cityname",
    "short_name": "ABC Bike Rental",
    "rental_apps": {
      "android": {
        "discovery_uri": "com.abcrental.android://"
        "store_uri": "https://play.google.com/store/apps/details?id=com.abcrental.android",
      },
      "ios": {
        "store_uri": "https://apps.apple.com/app/apple-store/id123456789",
        "discovery_uri": "com.abcrental.ios://"
      }
    },
…

discovery_uris son identificadores de recursos universales (URI) que se pueden usar para descubrir si la aplicación nativa del proveedor está instalada en las plataformas respectivas (por ejemplo, usando PackageManager.queryIntentActivities() en Android y UIApplication canOpenURL: en iOS). Este campo permite que una aplicación de terceros priorice las aplicaciones de alquiler para un viajero individual en función de si ya tiene instalada una aplicación de alquiler en particular. Por ejemplo, si hay 3 proveedores de bicicletas compartidas en una ciudad, y el viajero ya tiene una aplicación nativa para el proveedor de bicicletas compartidas “ABC Rental” instalada en su teléfono, una aplicación de terceros debe priorizar las opciones que usan “ABC Rental” sobre los otros proveedores al mostrar al viajero opciones multimodales de viaje.

Luego, para cada estación (en station_information.json) o vehículo flotante (en free_bike_status.json), se debe crear un vínculo directo único en rental_uris que llevará al viajero a esa estación o vehículo en la aplicación del proveedor.

Aquí hay un ejemplo para una estación:

station_information.json

"stations": [
  {
    "station_id": "425",
    "name": "Coppertail",
    "lat": 27.9563335328521,
    "lon": -82.430436084371,
    "rental_uris": {
      "android": "https://www.abc.com/app?sid=1234567890&platform=android",
      "ios": "https://www.abc.com/app?sid=1234567890&platform=ios"
    }
  }
…

El vínculo directo puede tener cualquier formato útil para la implementación de un proveedor en particular y puede contener varios parámetros significativos para el proveedor. En el ejemplo anterior, el proveedor está utilizando el parámetro sid como un identificador para esa estación, que la aplicación nativa del proveedor puede extraer para mostrar al viajero esa estación exacta. Algunos parámetros están reservados para comunicar el análisis entre aplicaciones de terceros y proveedores, más sobre eso en un momento.

Las aplicaciones de terceros pueden abrir los campos rental_uris como vínculos directos en las plataformas respectivas, por ejemplo, usando la intención android.intent.action.VIEW en Android. Para obtener más detalles, las aplicaciones de terceros deben consultar la documentación correspondiente de “Deep Links” en Android y “Communicate with Other Apps” en iOS.

Tenga en cuenta que, como práctica recomendada, los proveedores deben rotar los identificadores dentro de los vínculos directos después de cada alquiler para evitar exponer involuntariamente los orígenes y destinos de los viajes en vehículos compartidos. Consulte la sección “Enfatizar la privacidad del viajero” a continuación para obtener una discusión sobre la privacidad con bike_id.

El formato nativo básico para vínculos directos (“deep links”)📱

Es posible que las aplicaciones de proveedores anteriores no admitan “Android App Links” en Android y “Universal Links” en iOS, pero pueden tener aún soporte básico para vínculos directos (“deep links”).

Para permitir que las aplicaciones de terceros utilicen estos vínculos directos, además del campo discovery_uri, los proveedores también deben proporcionar un campo store_uri para cada plataforma. Esto permite que la aplicación de terceros dirija a los viajeros a las tiendas de aplicaciones respectivas si la aplicación del proveedor no está instalada:

system_information.json

{
  "last_updated": 1572447999,
  "data": {
    "system_id": "abc_cityname",
    "short_name": "ABC Bike Rental",
    "rental_apps": {
      "android": {
        "discovery_uri": "com.abcrental.android://"
        "store_uri": "https://play.google.com/store/apps/details?id=com.abcrental.android",
      },
      "ios": {
        "store_uri": "https://apps.apple.com/app/apple-store/id123456789",
        "discovery_uri": "com.abcrental.ios://"
      }
    },
…

Si usted es un proveedor, puede encontrar los ID de las aplicaciones para usar en los campos store_uri de su aplicación utilizando la documentación correspondiente para iOS y Android.

Similar al método de vínculos directos anteriores, los proveedores deberán especificar un vínculo directo único en rental_uris para cada estación o vehículo flotante. La principal diferencia aquí es que su esquema URI probablemente será personalizado y no comenzará con http. En el siguiente ejemplo, el proveedor ha definido un esquema URI personalizado de com.abcrental.android:// para Android y com.abcrental.ios:// para iOS:

station_information.json

"stations": [
  {
    "station_id": "425",
    "name": "Coppertail",
    "lat": 27.9563335328521,
    "lon": -82.430436084371,
    "rental_uris": {
      "android": "com.abcrental.android://open.abc.app/app?sid=1234567890",
      "ios": "com.abcrental.ios://open.abc.app/app?sid=1234567890"
    }
  },
…

Antes de abrir los vínculos directos, las aplicaciones de terceros ahora también deberán verificar primero si el viajero tiene la aplicación instalada utilizando el discovery_uri. Si no, la aplicación de terceros debería utilizar el store_uri para abrir la tienda de aplicaciones al listado de la aplicación de los proveedores.

Las aplicaciones web 🌐

Finalmente, GBFS v2.0 también soporta vínculos directos (“deep links”) en aplicaciones web (es decir, no iOS o Android nativo) para estaciones y vehículos flotantes a través de la web URI de alquiler:

"stations": [
  {
    "station_id":"425",
    "name":"Coppertail",
    "lat":27.9563335328521,
    "lon":-82.430436084371,
    "rental_uris": {
      "web":"https://www.abc.com/app?sid=1234567890",
    }
  },
…

Las aplicaciones de terceros pueden dirigir a los viajeros a esta URL para ver esta estación en particular en un navegador web.

La analítica 📊

Las aplicaciones de terceros también pueden agregar algunos parámetros a vínculos directos para pasar información analítica a las aplicaciones del proveedor. Los siguientes parámetros se enumeran específicamente en v2.0, aunque es posible que se admitan más en el futuro:

  • client_id: el nombre de dominio para la aplicación de terceros. (por ejemplo, google.com para Google)
  • ad_id: Advertising ID emitida a la aplicación de terceros (por ejemplo, Identifier for Advertiser (IFDA) en iOS o Google Advertising ID (AAID) en Android)
  • token: un identificador emitido por la aplicación del proveedor a la aplicación de terceros

Consulte GBFS Deep Links Analytics documentation (en inglés) para obtener más información.

Comunicación y descubrimiento de feeds más fácil 🤝

GBFS v2.0 también hace que sea más fácil descubrir varios archivos dentro del feed: el archivo de “autodiscovery”, gbfs.json, que contiene enlaces a todos los demás archivos de feed, ahora se requiere en v2.0. El campo de nombre para cada archivo dentro de gbfs.json ahora también se ha estandarizado, asegurando que el software de un consumidor pueda realizar un seguimiento de un solo enlace a gbfs.json, en lugar de rastrear múltiples URL en varios archivos para un solo feed.

Para facilitar la comunicación entre los consumidores y productores de feeds, se ha agregado un nuevo campo feed_contact_email a system_information.json. Este correo electrónico ofrece a los consumidores un método claro para contactar al operador de un feed para informar problemas técnicos.

Las aclaraciones 🛠️

También se han hecho algunas aclaraciones claves a los campos en GBFS v2.0.

En v1.0, el significado exacto de num_bikes_available y num_docks_available no estaba claro al considerar si la plaza estaba abierta o no para su uso. Por ejemplo, si físicamente hay 5 bicicletas en una estación, pero is_renting está establecido en falso, ¿debería num_bikes_available ser 0 o 5?

En v2.0, las definiciones de num_bikes_available y num_docks_available se han aclarado para que sean el estado físico del número de bicicletas y plazas disponibles en la estación, independientemente de si se puede o no alquilar o devolver una bicicleta. Como resultado, los consumidores ahora deben asegurarse de verificar el campo is_renting para saber si se puede alquilar una bicicleta “available”, y el campo is_returning para saber si un cliente puede devolver una bicicleta a una plaza “available”.

En otro cambio nuevo a v2.0, todos los campos en la especificación que eran verdaderos o falsos ahora se representan como valores booleanos JSON canónicos de true o false, en lugar de la representación entera anterior de 0 y 1.

Entonces, los feeds que se veían así en v1.0:

{
  "station_id": "2721922",
  "is_installed": 1,
  "is_renting": 1,
  "is_returning": 1,
  …
},

… ahora se verán así en v2.0:

{
  "station_id": "2721922",
  "is_installed": true,
  "is_renting": true,
  "is_returning": true,
  …
},

Centrarse en la privacidad del viajero 🕵️🔒

Cuando se desarrolló el GBFS para sistemas de bicicletas compartidas con estaciones, un viajero iba a una estación, tomaba una bicicleta para su viaje y la devolvía a una estación, lo que hacía difícil identificar un viajero individual. Ahora, con vehículos sin estaciones, que podemos llevar directamente desde nuestra puerta de entrada a nuestro médico, oficina, escuela, es mucho más fácil identificarnos como individuos si el GBFS incluye una identificación estable para cada vehículo. Ahora se requiere rotar bike_id después de cada alquiler de vehículos flotantes en v2.0. Esta técnica hace que sea más difícil reconstruir viajes individuales a partir de datos sin procesar.

Facilitando la transición a v2.0 😌

GBFS v2.0 es una versión MAJOR, lo que significa que algunos cambios afectarán a los consumidores existentes. Por ejemplo, cuando un productor cambia los valores booleanos de 0/1 a false/true, el software del consumidor que aún no se ha actualizado no podrá entender esto.

Por lo tanto, a medida que los productores actualicen sus GBFS feeds, es importante admitir tanto la versión 1.0 actual, así como la nueva versión 2.0 en paralelo en dos direcciones URL diferentes. GBFS define las siguientes mejores prácticas en esta área para “version endpoints

  • Los productores de GBFS deben proporcionar puntos finales que se ajusten tanto a la rama de soporte a largo plazo (LTS) de la especificación actual (actualmente v1.0) como a la rama de la última versión (actualmente v2.0) dentro de al menos 3 meses de una nueva versión de especificación MAJOR o MINOR. No es necesario admitir más de una versión MINOR del mismo grupo de versiones MAJOR porque las versiones MINOR son compatibles con versiones anteriores.
  • Los consumidores de GBFS deberían, como mínimo, apoyar la rama LTS actual. Se recomienda mucho que los consumidores de GBFS apoyan versiones posteriores.
  • Las URL de feed predeterminadas de GBFS (por ejemplo, https://www.example.com/data/gbfs.json o https://www.example.com/data/fr/system_information.json) deben dirigir a los consumidores al feed que se ajusta a la rama de documentación LTS actual (actualmente v1.0).

Si los productores no están listos para admitir varias versiones de feed simultáneamente pero aún así desean agregar algunas de las características no disruptivas en la v2.0, se ha lanzado una actualización MINOR a GBFS, v1.1. Esto permite a los productores agregar vínculos directos (“deep links”) y feed_contact_email a sus feeds, los cuales son compatibles con los consumidores existentes v1.0.

Para obtener más información sobre las versiones de especificación GBFS, consulte la Documentación sobre versiones de especificaciones (en inglés).

Y, si quiere ver la especificación completa de GBFS v2.0, está disponible aquí (en inglés).

¿Qué es lo que sigue?

Hemos sentado las bases para la evolución futura de GBFS, porque queremos mantener la continuidad en el formato al mismo tiempo que ampliamos sus casos de uso. Ya estamos trabajando en una nueva versión MINOR, GBFS v2.1, que incluye soporte oficial para zonas de geovalla para sistemas free floating y estaciones virtuales, así como para especificar diferentes tipos de vehículos. También se están preparando nuevos cambios importantes para una futura versión v3.0, que incluye exigir a los productores que definan la licencia de sus feeds.

¡Finalmente, le invitamos a participar en el proceso de cambio de GBFS! Diríjase al repositorio GBFS GitHub para ver debates abiertos sobre varios temas, así como los cambios propuestos en las “pull requests”. ¡Nos vemos allí! 👋