Resumen Técnico: Horarios de Tránsito Público Recurrentes: Identificación Estable desde GTFS y Análisis de Similitud

1. Planteamiento del Problema

Los horarios de tránsito público exhiben estructuras de servicio recurrentes donde múltiples fechas de calendario comparten tablas de horarios idénticas para el pasajero (por ejemplo, días laborables estándar), mientras que otras difieren debido a fines de semana, días festivos o eventos especiales. Sin embargo, la Especificación de Datos de Transporte General (GTFS, por sus siglas en inglés), el estándar global para datos de tránsito, no codifica explícitamente estos "DayTypes" (Tipos de Día) recurrentes. En su lugar, el GTFS representa el servicio a través de tablas interdependientes (calendario, viajes, tiempos de parada, formas), lo que obliga a los modelos posteriores de programación, asignación de vehículos y análisis de demanda a reconstruir objetos de suministro recurrentes a partir de datos fragmentados.

El desafío central es doble:

1. Identificación: ¿Cómo extraer clases de servicio recurrentes y estables (DayTypes) de GTFS sin depender de identificadores administrativos (por ejemplo, shape_id, stop_id) que pueden cambiar entre las versiones del feed a pesar de que el servicio físico permanezca constante.
2. Comparación: ¿Cómo comparar estos horarios extraídos para distinguir entre diferencias estrictas de horario, cambios menores de tiempo (por ejemplo, un retraso de 1 minuto) y cambios estructurales sustantivos (por ejemplo, la eliminación o adición de una ruta)?

2. Metodología

2.1. Definiciones Formales

El artículo formaliza dos conceptos clave:

• Patrón de Ruta (Route Pattern): Una variante de servicio orientada al pasajero definida por una secuencia ordenada de paradas y una dirección de viaje. A diferencia del shape_id de GTFS, que es un identificador administrativo, un Patrón de Ruta se define por la trayectoria física y el orden de las paradas.
• Tipo de Día (DayType): Una categoría de fechas que comparten exactamente el mismo conjunto de viajes de Patrones de Ruta operando a las mismas horas. Se define estrictamente como el conjunto de especificaciones de viaje: $DayType(d) = \{(p, dep_t, arr_t)\}$, donde $p$ es el Patrón de Ruta, y $dep_t/arr_t$ son la primera salida y la última llegada.

2.2. Extracción Estable mediante Indexación H3

Para garantizar la estabilidad frente al relabelado de identificadores administrativos, los autores proponen un método de extracción utilizando el sistema de indexación geoespacial jerárquica H3 (Uber Technologies, 2018).

• Clave de Patrón de Ruta: En lugar de usar shape_id o stop_id, el método convierte la secuencia ordenada de coordenadas de las paradas en una secuencia de celdas H3 (Resolución 15). Esta secuencia sirve como una clave determinista y estable para el Patrón de Ruta.
• Algoritmo de Extracción:
  1. Expandir las tablas de calendario y de excepciones de GTFS para generar una lista de viajes activos para cada fecha.
  2. Para cada viaje activo, convertir su secuencia de paradas en una clave de Patrón de Ruta basada en H3.
  3. Formar una tupla de especificación de viaje: $(H3\_key, first\_departure, last\_arrival)$.
  4. Agrupar las fechas que comparten exactamente el mismo conjunto de tuplas de especificación de viaje en un solo DayType.
• Invarianza: Este enfoque asegura que si dos feeds de GTFS describen el mismo servicio físico pero utilizan diferentes IDs administrativos, la partición de DayType extraída sea idéntica, siempre que las coordenadas y el orden de las paradas no cambien.

2.3. Marco de Comparación de Horarios

El artículo introduce una jerarquía de tres niveles de métricas para comparar DayTypes $A$ y $B$:

1. Métricas Exactas ($d_0$):

   • Utiliza la Distancia de Jaccard sobre el conjunto de especificaciones de viaje.
   • Trata cualquier diferencia en el Patrón de Ruta, la hora de salida o la hora de llegada como un DayType distinto.
   • Sirve como una señal de auditoría estricta para la calidad de los datos y los ajustes de tiempo intencionales.

2. Métricas con Tolerancia Temporal ($d_\epsilon$):

   • Introduce un parámetro de tolerancia $\epsilon$ (por ejemplo, 1, 3 o 5 minutos).
   • Dos viajes son $\epsilon$-equivalentes si comparten la misma clave de Patrón de Ruta y sus tiempos de salida y llegada difieren por $\le \epsilon$.
   • Calcula la distancia de Jaccard con tolerancia temporal basada en el número máximo de pares $\epsilon$-equivalentes.
   • Esta capa determina si las diferencias exactas son simplemente pequeños desplazamientos de tiempo.

3. Diagnósticos de Comparabilidad Estructural:

   • Para evitar la sobreinterpretación de pequeñas coincidencias como similitudes de todo el horario, el marco computa:
     • Participación de Coincidencia ($M_\epsilon$): La proporción de viajes que pueden emparejarse bajo tolerancia.
     • Desequilibrio en el Conteo de Viajes ($Q$): La diferencia relativa en el número total de viajes entre los dos DayTypes.
     • Conteo No Emparejado ($U_\epsilon$): El número de viajes que no pueden ser emparejados.
   • Esto distingue entre una "versión de un mismo horario con desplazamiento de tiempo" (alta $M_\epsilon$, baja $Q$) y un "cambio estructural de servicio" (baja $M_\epsilon$, alta $Q$).

3. Contribuciones Clave

1. Formalización: Define los Patrones de Ruta y los DayTypes como objetos de suministro recurrentes, distintos de la programación interna de vehículos o tripulación.
2. Extracción Estable: Desarrolla un procedimiento de extracción de GTFS utilizando claves de patrones de ruta H3 que es invariante al relabelado de identificadores administrativos, resolviendo un problema crítico de reproducibilidad en el análisis longitudinal de GTFS.
3. Jerarquía de Comparación: Propone un sistema de métricas que separa la auditoría estricta (exacta), la sensibilidad temporal (tolerancia de tiempo) y el cambio estructural (diagnósticos), abordando las limitaciones de usar una única métrica de similitud.
4. Utilidad para Procesos Posteriores: Proporciona conjuntos de horarios recurrentes compactos que pueden servir como entradas para la sincronización de horarios, la programación de vehículos, la asignación de demanda y los modelos de diagnóstico de desajustes.
5. Validación Empírica: Valida el marco en feeds de GTFS de Japón y Canadá, demostrando una extracción exitosa a través de diferentes escalas de red y estrategias de codificación de calendario.

4. Resultados y Hallazgos

El marco se aplicó a 40 agencias de transporte japonesas y 38 canadienses.

• Éxito de la Extracción: El algoritmo identificó con éxito DayTypes recurrentes para todas las agencias sin intervención manual, recuperando ciclos semanales estándar (días laborables/sábado/domingo), excepciones de días festivos y anomalías de un solo día.
• Conteos de DayType: El número mediano de DayTypes no vacíos por agencia fue de 4 en ambos países. Sin embargo, las agencias japonesas mostraron una mayor variabilidad (máximo 39) en comparación con las canadienses (máximo 17), lo que refleja calendarios estacionales/festivos más granulares en la muestra japonesa.
• Análisis de Disjuntividad:
  • Disjuntividad Exacta: Una parte significativa de las agencias tuvo pares de DayType con cero viajes compartidos (distancia de Jaccard = 1.0). Esto fue más común en Canadá (36% de las agencias) que en Japón (15%).
  • Impacto de la Tolerancia: Al aplicar la tolerancia de tiempo (1–5 minutos), muchos pares "exactamente disjuntos" en Canadá adquirieron algunas coincidencias, lo que sugiere que eran variaciones temporales de estructuras similares. En Japón, la disjuntividad exacta fue más persistente, indicando una separación estructural más fuerte entre los regímenes de servicio.
  • Realidad Estructural: A pesar de adquirir coincidencias bajo la tolerancia, la participación de coincidencia mediana se mantuvo baja (6.3% en Canadá, 0% en Japón) con altos desequilibrios en el conteo de viajes. Esto confirma que muchos DayTypes "disjuntos" representan volúmenes de servicio o conjuntos de rutas fundamentalmente diferentes, no solo horarios desplazados.
• Anidamiento: Se observó un anidamiento completo (donde un DayType es un subconjunto estricto de otro) en el 69% de las agencias japonesas y el 58% de las canadienses, lo que indica que la reducción graduada del servicio es una práctica común en ambas regiones.

5. Significado y Reivindicaciones

El artículo posiciona su contribución como una capa de representación metodológica más que como un nuevo algoritmo de optimización. Su importancia radica en:

• Cerrar la Brecha: Conecta los datos brutos y fragmentados de GTFS con los objetos de suministro recurrentes requeridos por los modelos metodológicos posteriores (por ejemplo, análisis de función de déficit, programación de vehículos).
• Estabilidad: Al desacoplar la identificación del servicio de los IDs administrativos, permite un análisis longitudinal confiable de la evolución de los horarios a través de las distintas versiones de los feeds.
• Interpretación Matizada: La jerarquía de métricas propuesta evita la clasificación errónea del ruido menor de tiempo como cambios estructurales de servicio, manteniendo al mismo tiempo la capacidad de auditar desviaciones exactas de los horarios.
• Representación Compacta: Transforma grandes tablas de horarios específicos por fecha en una biblioteca compacta de DayTypes recurrentes, facilitando una programación, asignación de demanda y análisis de desajustes más eficientes.

Los autores concluyen que, aunque el GTFS no define explícitamente los DayTypes, estos están codificados implícitamente y pueden extraerse y compararse de manera robusta utilizando este marco, proporcionando una base necesaria para la planificación y el análisis avanzado del transporte.