Además del tiempo de espera desplegado en la pantalla, puede ser útil tener una animación que, de un vistazo (glanceability), permita saber por dónde viene el o los buses que están circulando.

Características:

• La primera propuesta no es un mapa
• En cambio, puede ser un diagrama lineal simplificado, no a escala, que indica la posición relativa del bus con respecto a la secuencia de paradas, algo así como:

--P1-(B)--P2------P3--(B)-P4------P5--
    12 min           3 min

donde (B) es un bus (L1 o L2) y Pi es una parada.

• Debajo del bus indica el tiempo para llegar (esto haría la animación casi "autosuficiente")
• La parada donde está la pantalla está resaltada de alguna forma.
• Las paradas y el trayecto que "van quedando atrás" cambian de color o forma.
• (Bonus) Es posible cambiar la imagen de los elementos de la animación para hacerlo temático. Por ejemplo, alguna vez pueden ser ilustraciones pixeladas, en otro momento tipo manga, o según fechas de celebraciones, etc.

Posiblemente la animación requiere de:

• geoshapes para conocer la trayectoria de la ruta
• stops para conocer la ubicación de las paradas
• location para interpolar la ubicación relativa entre una parada y otra

Para la primera pantalla prototipo es necesario especificar la información desplegada.

Prototipo

• Ubicación: Soda Facultad de Ingeniería
• Vinculada a paradas: Ingeniería "hacia abajo" e Ingeniería "hacia arriba", que pueden considerarse "una sola estación"
• Rutas servidas: UCR L1 y UCR L2
• Modelo: pantalla E-Ink de MBTA para una parada de bus

Datos requeridos, caso 1: solamente con entidad Trip Updates

Preliminarmente, por cada parada, es necesario:

• Nombre de la parada (stop_ido stop_code)
• Hora
• Información estática (posiblemente hard coded)
• Lista de próximos buses:
  • Opcional: ícono
  • Código de ruta (L1 o L2, por ejemplo)
  • Información de la dirección en la que va, que sería trip_short_name de la tabla trips de GTFS Schedule. Nota: en cada FeedMessage de GTFS Realtime con la entidad trip_updates viene el trip_id con el cual podemos buscar trip_short_name.
  • Tiempo estimado de llegada (en minutos que faltan)

Esta opción tiene:

• Layout fijo
• No muestra información de Vehicle Positions o de Service Alerts

Tareas

Especificar la interfaz de datos entre la recolección y clasificación de GTFS Realtime que hacen David y Josué y las pantallas que aquí se administran. Por ejemplo:

[
  {
    "stop_id": "UCR_1_05",
    "next_bus": [
        {
            "route_id": "UCR_L1",    
            "trip_id": "desde_artes_sin_milla_entresemana_7:30",
            "direction_id": "1",
            "arrival": 1705689632,
         },
         {
            "route_id": "UCR_L2",    
            "trip_id": "desde_educacion_sin_milla_entresemana_7:45",
            "direction_id": "1",
            "arrival": 1705689895,
          },
      ]
  },
  {
    "stop_id": "UCR_0_07",
    "next_bus": [
        {
            "route_id": "UCR_L1",    
            "trip_id": "hacia_artes_sin_milla_entresemana_7:40",
            "direction_id": "0",
            "arrival": 1705689789,
         },
         {
            "route_id": "UCR_L2",    
            "trip_id": "hacia_educacion_sin_milla_entresemana_7:55",
            "direction_id": "0",
            "arrival": 1705689987,
          },
      ],
  }
]

• Especificación del formato de datos que debe recibir con la información para cada parada (ejemplo: el JSON anterior)
• ¿Cómo desplegar esa información en la página de la pantalla?
• ¿Cómo utilizar WebSockets para actualizar esa información?

Los televisores para mostrar la información tienen salida de audio. Podemos usar señales auditivas para indicar eventos como la llegada de un bus.

Es necesario diseñar las acciones que tendríamos que habilitar en el servidor y en el navegador para implementarlo.

El mensaje puede ser algo como:

[Sonido campana] "El próximo bus de la línea {X} está llegando"

Una hipótesis es que el servidor puede enviar una señal tipo ARRIVING que el navegador ejecuta con un audio pregrabado.