Estimación automática de subidas por paradero
1. Introducción
El proceso de estimación automática de subidas por paradero tiene como objetivo generar información temprana sobre la demanda del sistema de transporte público, a partir del procesamiento integrado de validaciones de pago, posiciones GPS y programa de operación vigente.
A diferencia de los procesos definitivos de estimación, este módulo opera con un desfase reducido respecto de la fecha de operación. En la configuración actual, el sistema procesa automáticamente la información correspondiente al día ubicado cuatro días antes de la fecha de ejecución. Esto permite disponer de resultados de demanda con mayor rapidez, facilitando el monitoreo operacional, el análisis temprano de comportamiento de usuarios y la toma de decisiones en plazos más cortos.
La principal ventaja de este enfoque es la oportunidad de la información. Sin embargo, dado que las fuentes de entrada son obtenidas de manera temprana, estas pueden no estar completamente consolidadas. Se estima que el nivel de completitud de los datos disponibles en esta etapa se encuentra cercano al 95%, por lo que los resultados deben interpretarse como una estimación temprana y no como una versión definitiva del procesamiento.
2. Objetivo del proceso
El objetivo del módulo es estimar, para cada validación de pago, el punto de subida más probable de la persona usuaria y posteriormente agregar estas subidas a nivel de paradero, servicio, periodo y otros atributos operacionales.
El resultado permite disponer de una tabla de demanda agregada por paradero, útil para análisis como:
- monitoreo temprano de subidas por punto de parada;
- identificación de paraderos con alta demanda;
- análisis por servicio y media hora;
- comparación entre modos de transporte;
- seguimiento por contrato u operador;
- análisis territorial por comuna;
- apoyo a decisiones operacionales y de planificación.
3. Fuentes de información
El proceso utiliza tres grupos principales de datos de entrada.
3.1 Datos GPS
Existe un proceso de extracción que obtiene los datos GPS en línea desde el web server del DTPM. Estos registros son estandarizados y almacenados en archivos diarios, manteniendo registros únicos por fecha de operación.
Esta fuente permite reconstruir la posición de los buses en el tiempo y estimar la ubicación del vehículo al momento en que ocurrió una validación.
3.2 Datos de validaciones
Existe un segundo proceso encargado de procesar las validaciones de pago. Este proceso estandariza los datos transaccionales y los guarda en archivos diarios.
Las validaciones constituyen la base principal de la estimación de subidas, ya que cada registro representa un evento de pago asociado a una persona usuaria, un medio de pago, un modo de transporte y, cuando está disponible, información operacional como validador, vehículo, servicio o estación.
3.3 Programa de operación vigente
Un tercer proceso descarga los archivos necesarios para el día de análisis. Este proceso obtiene:
- los archivos diarios de GPS;
- los archivos diarios de validaciones;
- el programa de operación vigente desde un FTP dispuesto por el DTPM.
El programa de operación permite disponer de información de servicios, sentidos, secuencias de paraderos y otros diccionarios necesarios para relacionar validaciones, buses y puntos de parada.
4. Flujo general del proceso
El proceso automático se ejecuta con una lógica de desfase de cuatro días. Es decir, si el sistema se ejecuta en una fecha determinada, procesa la información correspondiente al día operacional ubicado cuatro días antes.
El flujo general considera las siguientes etapas:
- Extracción y estandarización diaria de datos GPS.
- Extracción y estandarización diaria de validaciones.
- Descarga automática de los archivos de entrada para el día a procesar.
- Descarga del programa de operación vigente.
- Ejecución del módulo de estimación de subidas en C++.
- Estimación del paradero de subida según modo de transporte y disponibilidad de información.
- Agregación de resultados por atributos operacionales y territoriales.
- Generación de tabla final de subidas estimadas.
5. Metodología de estimación de subidas
La metodología de estimación depende del modo de transporte y de la información disponible en cada validación.
5.1 Metro y MetroTren
En los modos Metro y MetroTren, la estimación de subida se obtiene directamente desde la estación donde se realizó la validación.
En estos casos no se requiere interpolar posiciones GPS ni buscar paraderos cercanos, ya que la validación queda asociada a una estación específica. Por lo tanto, la ubicación de subida corresponde directamente a dicha estación.
5.2 Zonas pagas
En el caso de zonas pagas, la validación se realiza en el punto de acceso de la zona y no necesariamente sobre el bus abordado. Por esta razón, el servicio utilizado por la persona usuaria no queda identificado de forma directa en la validación.
Para resolver este caso, el proceso utiliza una distribución precalculada entregada como dato de entrada. Esta distribución permite asignar las validaciones de la zona paga a los servicios correspondientes, de acuerdo con la metodología definida previamente para este tipo de infraestructura.
La posición de subida se considera directa, ya que corresponde al paradero o zona donde se realiza la validación.
5.3 Bus con servicio-sentido identificado
Para validaciones realizadas en bus, cuando existe información de servicio-sentido, el sistema estima primero la posición del vehículo al momento de la validación.
Para ello, se buscan los registros GPS anterior y posterior al tiempo de validación del bus correspondiente. Con ambos puntos se realiza una interpolación temporal para estimar la posición del vehículo en el instante exacto de la validación.
Una vez obtenida la posición estimada, el sistema revisa la secuencia de paraderos del servicio-sentido y selecciona el paradero más cercano a dicha posición. Este paradero se asigna como punto de subida estimado.
5.4 Bus sin servicio-sentido identificado
Cuando una validación de bus no cuenta con servicio-sentido asociado, el sistema aplica una regla alternativa.
En este caso, la posición de subida también se estima mediante interpolación entre los GPS anterior y posterior al tiempo de validación. Luego, en vez de buscar el paradero más cercano dentro de una secuencia específica, se busca el paradero más cercano dentro de toda la red.
Para evitar asignaciones incoherentes, la búsqueda considera la dirección de avance inferida a partir de los registros GPS. De esta forma, el paradero seleccionado debe ser cercano a la posición estimada y coherente con la dirección de movimiento del vehículo.
6. Agregación de resultados
Una vez estimado el paradero de subida para cada validación, el sistema construye una tabla agregada de resultados.
La agregación se realiza considerando las siguientes dimensiones:
- fecha;
- tipo de día;
- paradero;
- comuna;
- modo de transporte;
- contrato u operador;
- tipo de pago;
- servicio;
- periodo;
- media hora.
El resultado corresponde a la cantidad de subidas estimadas para cada combinación de estas dimensiones.
Esta salida permite consultar la demanda de manera agregada, reduciendo el volumen de datos y facilitando su uso en tableros, reportes y análisis operacionales.
7. Pseudocódigo general
```text id="n6krvj" definir fecha_proceso = fecha_actual - 4 días
descargar archivo GPS diario para fecha_proceso descargar archivo de validaciones diario para fecha_proceso descargar programa de operación vigente desde FTP
cargar datos GPS cargar datos de validaciones cargar programa de operación cargar diccionarios de servicios, sentidos y paraderos cargar distribución precalculada para zonas pagas
inicializar tabla de subidas estimadas
Para cada validación:
identificar modo de transporte
Si modo es Metro o MetroTren:
obtener estación asociada a la validación
asignar estación como punto de subida
asignar servicio o línea según información disponible
Si validación corresponde a Zona Paga:
obtener zona paga asociada a la validación
asignar paradero o punto de validación como punto de subida
asignar servicio usando distribución precalculada de zona paga
Si modo es Bus:
obtener vehículo asociado a la validación
obtener tiempo de validación
buscar GPS anterior al tiempo de validación
buscar GPS posterior al tiempo de validación
Si existen GPS anterior y posterior:
interpolar posición del bus al tiempo de validación
Si existe servicio-sentido asociado:
obtener secuencia de paraderos del servicio-sentido
buscar paradero más cercano en la secuencia
asignar paradero como subida estimada
Si no existe servicio-sentido asociado:
estimar dirección de avance usando GPS anterior y posterior
buscar paradero más cercano de toda la red
que sea coherente con la dirección de avance
asignar paradero como subida estimada
Si no existen GPS suficientes:
marcar validación con subida no estimada
continuar
construir atributos de agregación:
fecha
tipo de día
paradero
comuna
modo
contrato
tipo de pago
servicio
periodo
media hora
acumular una subida en la combinación correspondiente
generar tabla final de subidas agregadas guardar resultados ```
8. Salida del proceso
La salida principal del módulo es una tabla agregada de subidas estimadas. Cada registro representa una combinación de atributos y la cantidad de subidas estimadas para dicha combinación.
Una estructura general de salida considera los siguientes campos:
- fecha: día de operación procesado.
- tipo_dia: clasificación del día, por ejemplo laboral, sábado, domingo o festivo.
- paradero: identificador del punto de parada o estación.
- comuna: comuna asociada al punto de subida.
- modo: modo de transporte utilizado.
- contrato: contrato, unidad de negocio u operador asociado.
- tipo_pago: clasificación del pago o perfil tarifario.
- servicio: servicio estimado o informado.
- periodo: periodo operacional del día.
- media_hora: intervalo de media hora asociado a la validación.
- subidas: cantidad agregada de subidas estimadas.
Esta tabla permite disponer de una visión temprana de la demanda observada en la red, agregada a un nivel útil para análisis operacionales.
9. Consideraciones metodológicas
El proceso está diseñado para entregar información con rapidez, por lo que utiliza datos disponibles con un desfase de cuatro días. Esta condición permite apoyar la toma de decisiones en plazos más cortos que los procesos definitivos de consolidación de información.
Sin embargo, al tratarse de datos tempranos, las fuentes de entrada pueden no estar completas al 100%. Se estima una completitud aproximada cercana al 95%, por lo que los resultados deben interpretarse como una estimación preliminar.
La calidad de la estimación depende de la disponibilidad y consistencia de los datos GPS, de la correcta asociación entre validaciones y vehículos, del programa de operación vigente y de la calidad de los diccionarios utilizados.
En el caso de buses, la estimación de subida depende especialmente de la existencia de registros GPS anterior y posterior al tiempo de validación. Cuando estos datos no están disponibles o presentan errores, la validación puede no ser estimada o puede quedar con menor calidad.
En zonas pagas, la asignación de servicio depende de una distribución precalculada. Por lo tanto, el resultado representa una asignación metodológica y no una observación directa del bus abordado por cada persona usuaria.
Los resultados de este proceso son adecuados para análisis tempranos, monitoreo y detección de patrones generales. Para análisis finales, reportes oficiales o procesos que requieran máxima precisión, se recomienda utilizar la versión consolidada de los datos cuando esté disponible.