universidad de chile facultad de ciencias fÍsicas y ... · ayuda que me brindó durante el trabajo...
TRANSCRIPT
UNIVERSIDAD DE CHILE FACULTAD DE CIENCIAS FÍSICAS Y MATEMÁTICAS DEPARTAMENTO DE CIENCIAS DE LA COMPUTACIÓN DEPARTAMENTO DE INGENIERÍA INDUSTRIAL
TÉCNICAS DE IMPUTACIÓN PARA VIAJES CON INFORMACIÓN INCOMPLETA A
PARTIR DE DATOS TRANSACCIONALES DE TRANSANTIAGO MEMORIA PARA OPTAR AL TÍTULO DE INGENIERO CIVIL EN COMPUTACIÓN E
INGENIERO CIVIL INDUSTRIAL
DANIEL ANDRÉS MIRANDA VALENZUELA
PROFESOR GUÍA SEBASTIÁN RÍOS PÉREZ
MIEMBROS DE LA COMISIÓN BENJAMÍN BUSTOS CÁRDENAS
GASTÓN L’HUILLIER CHAPARRO MARCELA MUNIZAGA MUÑOZ
SANTIAGO DE CHILE ABRIL 2011
1
RESUMEN DE LA MEMORIA PARA OPTAR AL TÍTULO DE INGENIERO CIVIL EN COMPUTACIÓN E INGENIERO CIVIL INDUSTRIAL POR: DANIEL MIRANDA VALENZUELA FECHA: 20/04/2011 PROF. GUÍA: SEBASTIÁN A. RÍOS PÉREZ
Resumen
En trabajos previos se ha desarrollado una metodología para estimar los puntos de bajada de los pasajeros de Transantiago. El presente trabajo busca ser una ayuda que permita aumentar los casos de éxito del algoritmo utilizando en la estimación de bajadas.
Para esto se proponen técnicas de corrección de datos con información de viajes incompletos, basadas en la regularidad en el uso del sistema de transporte público.
Para el estudio se utilizan los datos generados a partir de las transacciones que realizan los pasajeros todos los días, usando una tarjeta inteligente (smart card) llamada Bip!, que es el medio de pago. Este tipo de sistema se denomina AFC (Automatic Fare Collection o Recolección Tarifaria Automática). Semanalmente se generan más de 35.000.000 transacciones, por lo que procesar esta cantidad de datos implica un desafío importante desde el punto de vista del tiempo de ejecución.
Los buses del Transantiago integran dispositivos GPS que permiten su localización geográfica a través de sistemas AVL (Automatic Vehicle Location o Localización Automática de Vehículos), de esta forma, se registra información de posición de más de 6.000 buses todos los días.
Al unir la información provenientes de ambos sistemas, esto es, AFC y AVL, se dispone de información detallada muy útil en el análisis y estudio del funcionamiento de Transantiago. Es posible conocer el lugar y tiempo de cada una de las transacciones realizadas y estudios más elaborados permiten construir estimaciones de matrices origen-destino (OD) de viajes, que es información muy relevante dentro del área de transporte.
En este proyecto se llevó a cabo un estudio del comportamiento de los pasajeros para determinar aquellos que tuvieran un comportamiento regular, de esta forma se definieron técnicas de imputación de datos para viajes con información incompleta basándose en patrones de uso del sistema.
Los algoritmos involucrados se construyeron utilizando concurrencia, para poder hacer uso de todos los procesadores disponibles en el computador a utilizar.
De esta forma, se logró estimar 729.250 patrones de usuarios y 359.591 imputaciones de datos, lo que corresponde a un porcentaje muy pequeño del total de datos sin estimación de bajadas (2,5% aproximadamente). Una de las limitantes más importantes de este proyecto fue la poca cantidad de datos para generar los patrones: 2 semanas. Se podría realizar un estudio más robusto del comportamiento de los usuarios utilizando al menos 2 meses de datos.
Se realizó una evaluación de prueba con datos supervisados y se determinó que todos los valores imputados tuvieron una diferencia menor a un metro de distancia respecto al dato real. En el 68% de los casos se obtuvo una diferencia de tiempo menor a una hora entre el valor imputado y el real, en el 87% de los casos se obtuvo una diferencia de tiempo menor a dos horas.
2
Agradecimientos
En primer lugar, agradezco a Dios por haberme guiado desde pequeño a través del camino de la
vida en los buenos y malos momentos, durante el colegio, la Universidad y ahora en el futuro laboral
que recién comienza. Espero estar a la altura de lo que espera de mí.
Agradezco a toda mi familia, en especial a mi madre Patricia por todo el amor que me entregó
cada día, a mi hermana Kathy por su cariño, a mi polola Lenka por todos los momentos entretenidos que
pasamos juntos y a mi tía Lina por su preocupación.
También le doy las gracias a todo el grupo de compañeros de la Universidad con los que
compartí muy buenos momentos, sobre todo aquellas maratones adrenalínicas cuando nos
quedábamos hasta tarde en la “U”, ya sea estudiando o terminando las tareas para enviarlas antes de
las 11:59 por U-Cursos: Francisco, Roberto, Nail, Victor y Felipe. Juntos llegamos al teorema de que para
obtener la nota máxima en las pruebas, tareas o informes solo falta una unidad: un día de estudio o un
día de trabajo.
Le doy gracias al profesor Sebastián por su cercanía a pesar de su poco tiempo y por toda la
ayuda que me brindó durante el trabajo de la memoria al igual que Gastón, también agradezco a la
profesora Marcela por aceptar un infiltrado en el mundo del transporte. Gracias a Mauricio por la
disposición en ayudarme con todos los datos de Transantiago.
3
Índice
1 INTRODUCCIÓN ............................................................................................................................................. 6
1.1 ANTECEDENTES GENERALES Y MOTIVACIÓN ................................................................................................................ 6 1.2 ANTECEDENTES DEL PROYECTO ................................................................................................................................ 9 1.3 PLANTEAMIENTO DEL PROBLEMA ........................................................................................................................... 10 1.4 OBJETIVOS ......................................................................................................................................................... 11 1.5 METODOLOGÍA ................................................................................................................................................... 12 1.6 RESULTADOS ESPERADOS ...................................................................................................................................... 12 1.7 ALCANCES ......................................................................................................................................................... 13
2 ANTECEDENTES ............................................................................................................................................ 13
2.1 SISTEMA DE TRANSPORTE PÚBLICO ......................................................................................................................... 13 2.1.1 Estimación del punto de bajada ........................................................................................................... 21
2.2 MINERÍA DE DATOS ............................................................................................................................................. 24 2.2.1 Aprendizaje no supervisado .................................................................................................................. 24 2.2.2 Clustering .............................................................................................................................................. 25 2.2.3 Métodos de clustering .......................................................................................................................... 26 2.2.4 Clustering basado en densidad ............................................................................................................. 27
3 SOLUCIÓN PROPUESTA ................................................................................................................................ 29
3.1 DESCRIPCIÓN DE LOS DATOS .................................................................................................................................. 29 3.2 BÚSQUEDA DE PATRONES ..................................................................................................................................... 30
3.2.1 Análisis del tiempo ................................................................................................................................ 31 3.2.2 Análisis de la posición ........................................................................................................................... 32 3.2.3 Generación de patrones........................................................................................................................ 38
3.3 IMPUTACIÓN DE DATOS ........................................................................................................................................ 38 3.3.1 Viajes con información incompleta ...................................................................................................... 38 3.3.2 Búsqueda de transacciones faltantes ................................................................................................... 39
3.4 EFICIENCIA EN EL CÁLCULO .................................................................................................................................... 43
4 APLICACIÓN EN TRANSANTIAGO .................................................................................................................. 44
4.1 DESCRIPCIÓN DE LOS DATOS DE TRANSANTIAGO ........................................................................................................ 44 4.1.1 Preprocesamiento ................................................................................................................................. 44 4.1.2 Descripción de datos transaccionales ................................................................................................... 45
4.2 IMPLEMENTACIÓN DEL ALGORITMO ........................................................................................................................ 47 4.2.1 Diagrama de Clases .............................................................................................................................. 47 4.2.2 Búsqueda de patrones .......................................................................................................................... 48 4.2.3 Imputación de datos ............................................................................................................................. 51 4.2.4 Visualización ......................................................................................................................................... 56 4.2.5 Concurrencia ......................................................................................................................................... 56 4.2.6 Parámetros de algoritmos .................................................................................................................... 58
5 ANÁLISIS DE RESULTADOS............................................................................................................................ 58
5.1 RESULTADOS EN LA BÚSQUEDA DE PATRONES ........................................................................................................... 59 5.2 RESULTADOS EN IMPUTACIÓN DE TRANSACCIONES ..................................................................................................... 60 5.3 EVALUACIÓN DE DATOS IMPUTADOS ....................................................................................................................... 62
6 CONCLUSIONES ............................................................................................................................................ 63
6.1 TRABAJO FUTURO ................................................................................................................................................ 64 6.1.1 Paralelismo (Xgrid) ............................................................................................................................... 64 6.1.2 Análisis de patrones de 1 transacción diaria ........................................................................................ 64 6.1.3 Evaluación de algoritmos ..................................................................................................................... 65
4
6.1.4 Otros métodos de imputación .............................................................................................................. 65
7 REFERENCIAS BIBLIOGRÁFICAS .................................................................................................................... 65
8 ANEXOS ....................................................................................................................................................... 66
8.1 DICCIONARIO DE DATOS ....................................................................................................................................... 66 8.2 COORDENADAS UTM .......................................................................................................................................... 75 8.3 CADENAS DE MARKOV ......................................................................................................................................... 76 8.4 INFERENCIA BAYESIANA ........................................................................................................................................ 76
Índice de Figuras
Figura 1: Zonas y troncales de Transantiago .................................................................................................6 Figura 2: Zonas Transantiago .........................................................................................................................7 Figura 3: Histograma diario de transacciones................................................................................................8 Figura 4: Performance de estimación de bajada [1] ......................................................................................9 Figura 5: Causas de error [1] ....................................................................................................................... 10 Figura 6: Historial de transacciones de una tarjeta [3] ............................................................................... 15 Figura 7: Número de abordajes en un día por sector y en distintos horarios [4] ...................................... 17 Figura 8: Cantidad de bajadas a nivel de paradero y por tipo de tarjeta [8] .............................................. 20 Figura 9: Centroides de clusters (en base al tiempo) para cinco clases de tarjeta [9] ............................... 21 Figura 10: Estimación del punto de bajada [11] ......................................................................................... 22 Figura 11: Elección de paradero [1] ............................................................................................................ 23 Figura 12: Destinos de viajes [12] ............................................................................................................... 23 Figura 13: Density-reachable, density-connected [19] ............................................................................... 28 Figura 14 : Transacciones de un usuario ..................................................................................................... 31 Figura 15: Agrupación de transacciones diferentes ................................................................................... 33 Figura 16: Transacciones separadas ........................................................................................................... 34 Figura 17: Primera Transacción del día ....................................................................................................... 34 Figura 18: Mapa Primera Transacción del día............................................................................................. 35 Figura 19: Comparación Día - Patrón .......................................................................................................... 41 Figura 20: Arquitectura Xgrid ...................................................................................................................... 43 Figura 21: Tramado automático de rutas [12] ............................................................................................ 45 Figura 22: Proyección a ruta [12] ................................................................................................................ 45 Figura 23: Diagrama Relacional Transantiago............................................................................................. 46 Figura 24: Diagrama de Clases .................................................................................................................... 48 Figura 25: Transacciones con Imputación ................................................................................................... 54 Figura 26: Mapa Imputación ....................................................................................................................... 55 Figura 27: Mapa Imputación (otra vista) .................................................................................................... 55 Figura 28: Google Earth............................................................................................................................... 56 Figura 29: Uso de CPU y memoria RAM ..................................................................................................... 57 Figura 30: Rendimiento ............................................................................................................................... 57 Figura 31: Divisiones UTM .......................................................................................................................... 75
5
Índice de Tablas
Tabla 1: Distribución de transacciones por tipo de problema [3] .............................................................. 14 Tabla 2: Matriz OD [12] ............................................................................................................................... 24 Tabla 3: Primera Transacción del día .......................................................................................................... 31 Tabla 4: Cuarta Transacción del día ............................................................................................................ 32 Tabla 5: Datos Transaccionales de Transantiago ........................................................................................ 49 Tabla 6: Registros de Patrón ....................................................................................................................... 50 Tabla 7: Registros de datos Imputados ....................................................................................................... 52 Tabla 8: Patrón Usuario............................................................................................................................... 53 Tabla 9: Imputación Usuario ....................................................................................................................... 53 Tabla 10: Datos Transaccionales de Transantiago ...................................................................................... 59 Tabla 11: Experimentos - Patrones ............................................................................................................. 60 Tabla 12: Experimentos - Imputaciones ..................................................................................................... 61 Tabla 13: Diferencias de tiempo ................................................................................................................. 63 Tabla 14: Periodos en casos de días laborales ............................................................................................ 68 Tabla 15: Tabla de información adicional por unidad de negocio .............................................................. 68 Tabla 16: Tabla de transacciones ................................................................................................................ 70 Tabla 17: Registros de transacciones – parte 1 .......................................................................................... 71 Tabla 18: Registros de transacciones – parte 2 .......................................................................................... 71 Tabla 19: Registros de transacciones – parte 3 .......................................................................................... 71 Tabla 20: Registros de transacciones – parte 4 .......................................................................................... 72 Tabla 21: Registro de ejemplo .................................................................................................................... 74
Índice de Ecuaciones
Ecuación 1: Función a minimizar en k-means ............................................................................................. 26 Ecuación 2: Core-Distance [19] .................................................................................................................. 29 Ecuación 3: Reachability-distance [19] ....................................................................................................... 29 Ecuación 4: Frecuencia de la moda ............................................................................................................. 35 Ecuación 5: Restricción frecuencia de moda .............................................................................................. 36 Ecuación 6: Restricción población clúster ................................................................................................... 37 Ecuación 7: Restricción distancia máxima .................................................................................................. 40 Ecuación 8: Tiempo, opción 1 ..................................................................................................................... 42 Ecuación 9: Tiempo, opción 2 ..................................................................................................................... 42 Ecuación 10: Tiempo, opción 3 ................................................................................................................... 42 Ecuación 11: Tiempo, opción 4 ................................................................................................................... 42
6
1 Introducción
1.1 Antecedentes generales y motivación
El presente trabajo se llevó a cabo a partir de los datos generados durante una semana de
marzo y otra de abril de 2009 en Transantiago, sistema de transporte público de Santiago de Chile,
comenzó a operar en una primera etapa el 22 de octubre de 2005, siendo completada el 10 de febrero
de 2007. El sistema se basa en una estructura de buses troncales y alimentadores, siendo el metro una
componente importante. Transantiago cuenta con nueve áreas de operación alimentadoras y 6 áreas de
operación troncales (ver Figura 1), el operador troncal principal es el Metro, los otros cinco son líneas de
buses. Existen más de 300 rutas de buses diferentes y alrededor de 6.000 buses operando diariamente,
se cuenta con más de 10.000 paraderos y el Metro tiene aproximadamente 85 KM de vías.
El sistema de pago es a través de una tarjeta inteligente (Smart-Card) llamada Bip!, donde cada
usuario marca con su tarjeta en el dispositivo de pago al momento de abordar, de esta forma, un
pasajero puede realizar hasta tres combinaciones en un lapso de dos horas. Han entrado en circulación
más de once millones de tarjetas Bip! y existen más de 150 paraderos equipados con un sistema de pago
especial, donde el usuario paga al entrar al paradero (“Zona Paga”), de esta manera se busca aumentar
la eficiencia de toma de pasajeros en horarios punta en los lugares más congestionados.
Figura 1: Zonas y troncales de Transantiago1
Santiago está dividido en 34 comunas, con una población de aproximadamente 6 millones de
habitantes, y una distribución de población no homogénea. La ciudad fue dividida en 10 Zonas de
1 Fuente: http://www.transantiagoinforma.cl/ - Fecha último acceso: 03/04/2011
7
servicio, para poder ordenar la operación de los servicios de transporte que conectan las comunas de la
ciudad. Cada Zona se identifica con una letra y color distinto, y están formadas por un grupo de comunas
(ver Figura 2).
Figura 2: Zonas Transantiago2
El sistema de pago es a través de una tarjeta inteligente (Smart-Card) llamada Bip!, donde cada
usuario marca con su tarjeta en el dispositivo de pago al momento de abordar. De esta forma, un
pasajero puede realizar hasta tres combinaciones en un lapso de dos horas. Actualmente se ha agregado
la restricción de que al tomar por segunda vez seguida un bus que esté realizando el mismo servicio, se
efectuará otro cobro.
Todas las transacciones Bip! que se llevan a cabo son registradas en una base de datos que
contiene información sobre el operador, el id y el tipo de tarjeta Bip!, hora, fecha, monto y el bus o
estación de metro donde se realizó la transacción. Cada dispositivo de pago tiene asociado un
identificador único y está asociado a un bus, una estación de Metro o un paradero habilitado con Zonas
Pagas. Cada semana se registran alrededor de 35 millones de transacciones realizadas por más de 3
millones de tarjetas Bip! en cerca de 6.000 buses.
Existe otra base de datos que contiene información de localización de todos los buses, esta base
de datos almacena elementos como la latitud, longitud, fecha, hora y velocidad instantánea.
2 Fuente: http://www.transantiagoinforma.cl/ - Fecha último acceso: 03/04/2011
8
Cada bus está identificado por su patente y el operador al cual pertenece. En la mayoría de los
buses, se realizan observaciones GPS cada 30 segundos, a veces el periodo es mayor, y en otros casos
menor. De esta forma, cada semana se registran alrededor de 80 millones de observaciones.
El sistema además cuenta con las rutas de los buses geo-codificadas, las posiciones de las
estaciones de Metro, paraderos y paraderos con Zonas Pagas.
En la Figura 3 se puede observar la variación del número de transacciones en Transantiago
realizadas en intervalos de media hora para un día laboral:
Figura 3: Histograma diario de transacciones3
Se pueden identificar dos puntos de alta frecuencia durante el día, entre 7:30 y 8:00 de la
mañana y entre las 6:30 y 7:00 de la tarde. En menor proporción se puede observar un incremento de
transacciones a la “hora de almuerzo” entre la 1:00 y 1:30 de la tarde. La actividad es muy baja entre las
00:00 horas y las 5:00 de la mañana.
Es posible unir la información generada por las tarjetas Bip! y el sistema de geo-localización de
los buses, lográndose obtener el tiempo y espacio en que se realizó cada transacción. Luego es posible
realizar distintos análisis, como la cantidad de abordajes por sector de la ciudad, o distribución de las
transacciones durante del día, identificándose claramente sectores de la capital con mayor demanda de
transporte y los horarios punta.
3 Fuente: Elaboración propia.
9
1.2 Antecedentes del proyecto
En trabajos anteriores realizados en Transantiago, se han desarrollado metodologías para
estimar los puntos de bajada de pasajeros [1] y también se han definido métodos para estimar la
velocidad promedio de los buses a distintos niveles de detalle [2].
Para la estimación de bajada de pasajeros en Transantiago, se tiene aproximadamente un 18%
de casos de error, como se muestra en la Figura 4. En el presente trabajo se busca identificar patrones
de uso del sistema que permitan corregir datos para disminuir el número de casos de error.
Se dice que la información está incompleta cuando no es posible estimar un punto de bajada
debido a distintos factores, como por ejemplo, que exista solo una transacción en el día, o que el punto
de bajada estimado se encuentra demasiado lejos de la siguiente transacción, que por lo general se
debe a que existió evasión en alguna parte del viaje o se utilizó otro medio de transporte, lo que
conlleva una perdida en el seguimiento del viaje de ese pasajero.
Figura 4: Performance de estimación de bajada [1]
En Transantiago, las tarjetas Bip! no están asociadas de forma reglamentaria a un solo usuario,
por lo que un pasajero podría utilizar diferentes tarjetas, y también una tarjeta podría ser utilizada por
distintos pasajeros (en el caso de pases escolares, la tarjeta es personal e intransferible, pero pueden
existir usuarios que no respeten estas reglas).
Por ejemplo, existen ocasiones donde algún hijo que se queda sin saldo, utiliza la tarjeta Bip! de
alguno de los padres, de esta forma esa tarjeta no sigue el mismo patrón de viaje que ha mostrado
durante los demás días de la semana. También existen ocasiones donde los usuarios utilizan distintas
tarjetas en la semana o a veces, varias tarjetas en un mismo día.
10
Un factor muy importante a considerar, es el gran tamaño de datos que se requiere procesar,
por ejemplo, en [1] solo se usó una semana de datos, tomando muchas horas de procesamiento en
computadores poderosos. Es por esto que se debe buscar una forma eficiente para procesar grandes
cantidades de datos en un tiempo razonable.
1.3 Planteamiento del problema
Actualmente se han realizado esfuerzos para el desarrollo de metodologías y algoritmos que
permitan realizar una estimación del punto de bajada de los pasajeros del Transantiago, este trabajo
está a cargo de la División Ingeniería de Transporte del Departamento de Ingeniería Civil de la
Universidad de Chile, la metodología se describe con mayor detalle en la sección 2.1.1.
Dentro del área de transporte es muy valiosa la información de movimiento de personas en la
ciudad. Por ejemplo, Sectra (Secretaría de Planificación de Transporte) ha realizado esfuerzos de alto
costo económico para llevar a cabo encuestas de origen-destino.
Mediante la estimación de los puntos de bajada de pasajeros es posible generar información
similar a las obtenidas mediante encuestas de origen-destino, a partir de los datos generados por las
transacciones del sistema de transporte público, sin la necesidad de incurrir en gastos mayores y con la
posibilidad de contar con información actualizada de manera mucho más rápida.
Para lograr esto, uno de los principales desafíos es el desarrollo de un algoritmo que permita
estimar de forma precisa los puntos de bajada de pasajeros. En la Figura 5 se indica cómo se distribuyen
los casos de error para este algoritmo.
Figura 5: Causas de error [1]
El mayor porcentaje de error, corresponde a aquellos casos donde la distancia entre el punto
estimado de bajada y el punto de subida de la siguiente transacción es demasiado grande (1.000
metros), por lo que se determina como “no caminable”.
11
Es probable que esto suceda por la pérdida de información en algún punto del viaje debido, por
ejemplo, al uso de otro medio de transporte o por evasión blanda (cuando un pasajero paga su pasaje al
marcar en los dispositivos Bip!, pero no marca en algún trasbordo del viaje cuando el bus está
demasiado lleno por ejemplo).
En este trabajo se plantea una forma para disminuir los casos de error tipo “no caminables”
utilizando dos conceptos principales:
• Búsqueda de patrón de uso diario del sistema de transporte público.
• Imputación de transacciones faltantes dentro de un viaje según el patrón del usuario.
1.4 Objetivos
• Objetivo General
Diseñar e implementar técnicas de imputación para viajes con información incompleta a partir
de los datos transaccionales de Transantiago, mediante técnicas de clustering y búsqueda de patrones
de uso para disminuir el error en la estimación de los puntos de bajada de los pasajeros.
• Objetivos Específicos
1) Profundizar en la problemática del sistema de transporte público de Santiago de Chile,
los desafíos y soluciones más recientes.
2) Entender el estado del arte en métodos de imputación de datos.
3) Entender el estado del arte en técnicas y sistemas de procesamiento masivo de datos.
4) Realizar el diseño e implementación de un mecanismo de imputación de transacciones.
5) Evaluar la calidad de los datos imputados obtenidos.
12
1.5 Metodología
En la realización de este trabajo, se siguieron los siguientes pasos:
Investigación bibliográfica y de contenidos:
Estudio de papers de transporte relacionados con uso de información de sistemas AFC y del área
de minería de datos, especialmente clustering, además de libros e información web.
Comunicación con encargado de datos e implementación de software de estimación de bajadas
de Transantiago (Mauricio Zuñiga):
Se realizaron todas las consultas necesarias a través de reuniones concertadas con anticipación,
más la posibilidad de mensajería instantánea, cuando se requirió algún tipo de información particular
sobre los datos.
Investigación descriptiva y de campo:
Se fijaron reuniones frecuentes con la profesora Marcela Munizaga, jefe División Ingeniería de
Transporte del Departamento de Ingeniería Civil de la Universidad de Chile, quien es miembro del
instituto Milenio en sistemas de ingeniería, por lo que fue posible discutir en estas instancias dudas
sobre la forma de abordar los problemas.
Investigación sobre técnicas de minería de datos:
Se investigaron técnicas y metodologías utilizadas por la comunidad de minería de datos.
Específicamente, se estudió acerca de clustering, redes bayesianas y cadenas de Markov.
1.6 Resultados esperados
Este proyecto busca desarrollar técnicas de imputación que permitan disminuir los casos de
error del algoritmo de estimación de bajadas para Transantiago. Para esto, es necesario plantear
metodologías que permitan identificar patrones de usuarios para ser utilizados como base en la
imputación de datos sobre viajes con información incompleta.
13
De esta forma, los resultados específicos son:
1. Desarrollar antecedes y marco teórico acerca de los principales estudios y avances en
cuanto a los sistemas de transporte público modernos y la información que se genera
en estos.
2. Diseñar una metodología que permita identificar patrones de uso del sistema de
transporte público Transantiago.
3. Diseñar técnicas de imputación de datos sobre viajes con información incompleta
basadas en patrones de uso.
1.7 Alcances
Las técnicas de imputación expuestas en este trabajo se basaron principalmente en el estudio
de comportamientos regulares de pasajeros. En este trabajo no se abordan otras técnicas basadas en
otro tipo de información. El diseño y su aplicación fueron desarrollados bajo las características y
restricciones de un sistema de transporte público en particular (Transantiago).
2 Antecedentes
En la primera parte del presente capitulo se presenta el estado del arte en los sistemas de
transporte público modernos, los avances alcanzados y sus desafíos. En la segunda parte se presenta el
marco teórico de los algoritmos de minería de datos utilizados en este trabajo.
2.1 Sistema de transporte público
A continuación se describe el avance actual en cuanto a la recuperación de información a través
de los datos generados por sistemas de recolección tarifaria automática (AFC, Automatic Fare
Collection) utilizando Smart-Cards.
En [3] Chapleau y Chu proponen una metodología para mejorar la calidad de los datos
generados por las tarjetas de pago (Smart-Card) del transporte público. Los datos de las transacciones
14
usados en este estudio provienen del sistema de recolección tarifaria automática (AFC) de la “Société de
transports de l’Outaouais (STO)”, una agencia de transporte público que opera en la región capital
nacional de Canadá, siendo Ottawa y Gatineau las dos mayores ciudades.
La base de datos utilizada en [3] registra 763.570 transacciones en el mes de febrero de 2005
generadas por 21.813 tarjetas diferentes que representa el 80% de los usuarios del sistema de
transporte. Una característica importante de este sistema, es que cada tarjeta está individualmente
identificada con una fotografía y es limitada a solo un usuario. El sistema requiere que el usuario utilice
su tarjeta solo al momento de abordar.
En este estudio se indica que el primer paso es filtrar todas las transacciones irrelevantes, por
ejemplo, aquellas que contienen un número de bus inválido, número de zona inválida, servicios no
regulares como sucede en el caso de mantenimientos, entre otros. Luego se muestran los principales
errores identificados, como valores nulos en la hora de partida o la inicialización fallida de un recorrido
por parte del conductor, lo que lleva a que las transacciones del siguiente recorrido sean asociadas al
recorrido anterior. Además existen transacciones sospechosas, por ejemplo, la permanencia excesiva de
un bus en un solo paradero.
En la Tabla 1 se describen los tipos de problemas encontrados y su frecuencia en las
transacciones de la muestra en estudio. Se observa que un 15.15% corresponde a transacciones con
problemas.
Tabla 1: Distribución de transacciones por tipo de problema [3]
Tipo de problema Reglas Nº de transacciones
Irrelevantes
Número de vehículo Inválido 2
Número de bloque Inválido 376
Viaje especial 577
Erróneos
Abordajes en buses fuera de servicio 25897
Tiempo de salida vacío 15108
Abordajes en terminales de buses 25212
Sospechosos
Tiempos de detención excesivos 84320
Tiempos de viaje excesivos 24004
Tiempos entre viajes Excesivos 17368
Total con problemas Todas las reglas combinadas 115650 (15.15%)
Sin problemas 647920 (84.85%)
Total general 763570 (100%)
Para realizar la corrección de los datos anómalos, se utilizaron dos conceptos de transporte:
15
� Regularidad de las operaciones del transporte público:
Se pueden corregir errores usando restricciones respecto de la geometría de un viaje e
información de ruta y tiempo asignado a un bus.
� Regularidad de los patrones del historial de viaje de cada pasajero:
Se pueden corregir errores observando los patrones de viaje de los pasajeros y de esta
forma asignar el valor más probable cuando no existe ese dato.
Como se explica en el siguiente párrafo, para realizar la corrección de las rutas se utilizó un
enfoque bayesiano4, esto es, los parámetros de la distribución de probabilidad se consideran como
variables aleatorias y se usan los datos observados para proveer información sobre los parámetros.
En particular, el proceso de asignación de rutas se considera un problema de clasificación, donde
el día de la semana y la hora de la transacción se usan como las variables explicativas. De esta forma se
busca la ruta más frecuente utilizada por el usuario a la misma hora en otros días, en este caso, se utilizó
una ventana de tiempo de 5 minutos.
La Figura 6 ilustra todas las transacciones realizadas con una tarjeta típica en el mes de febrero
de 2005. Distintos símbolos denotan diferentes rutas según fue registrado. Los puntos sin relleno indican
una transacción con algún tipo de problema.
Figura 6: Historial de transacciones de una tarjeta [3]
4 Ver anexo 8.4
16
En el caso de la corrección de paraderos, también se utilizó un enfoque bayesiano, en este
problema de clasificación, se usó el paradero como la clase y la información de la ruta (ruta, dirección y
tiempo de partida) como variables explicativas. Se busca encontrar el paradero usado con mayor
frecuencia cuando el usuario toma este recorrido en los otros días. También se debe cumplir que el bus
cumpla con las restricciones de tiempo-espacio: el orden de los paraderos debe ser consecuente con el
orden de las transacciones y la velocidad del bus debe ser razonable. En los casos de transacciones
donde fue posible corregir, se aplica interpolación y extrapolación lineal en tiempo y distancia.
Inicialmente en [3], un 84,3% de las transacciones se consideraron válidas (sin problemas como
datos en blanco o incongruentes), luego de aplicar el procedimiento presentado en este estudio, el
98.1% de las transacciones se consideró validas (o sea, aplicando las correcciones mencionadas en los
casos donde era posible inferir). De todas formas, es de esperar que algunas de las transacciones
corregidas contengan pequeños errores.
En [4] los autores exponen que los sistemas de recolección tarifaria automática (AFC) han sido
adoptados por numerosas agencias de tránsito en el mundo y la tendencia sigue en aumento. A pesar de
que su principal objetivo es la recolección tarifaría, se ha comprobado que también son una excelente
fuente de datos de viajes, en especial aquellos que integran tecnologías de localización de vehículos
automática (AVL), como por ejemplo GPS.
Los datos registrados originalmente por el sistema AFC a través de las tarjetas (Smart-Cards)
están lejos de ser usables, en general existen dos grandes problemas. Primero, se tienen distintas
situaciones de la vida real que el sistema no puede anticipar y manejar, por ejemplo fallas en los
procedimientos realizados por los conductores (como inicializar una nueva ruta). Segundo, muchos
sistemas requieren que el usuario solo utilice su tarjeta al abordar, por lo que no es directa la obtención
de datos sobre la bajada del usuario, información indispensable para la generación de matrices origen-
destino usada en planificaciones de tránsito.
En [4], se describen las características de la implementación en particular del sistema AFC,
definición de los objetos en juego como por ejemplo los tipos de tarjeta (adulto, estudiante, tercera
edad, otros) y datos registrados en cada transacción. Luego se hace alusión a [3] para indicar el proceso
de identificación y corrección de errores.
Para llevar a cabo la modelación de la planificación de servicios, primero se debe hacer un
análisis de la demanda. Gracias a los datos generados por el sistema AFC, se pueden generar reportes y
17
gráficos de la distribución espacio-temporal de los abordajes por parte del usuario en el sistema de
transporte.
Por ejemplo, en la Figura 7 se puede observar la distribución espacio-temporal de los abordajes
en distintos horarios de un día de semana laboral, por ventanas de 3 horas. El espacio fue particionado
en cuadrados de 1 Km. La concentración de transacciones en la tarde (3:00 a 5:59) refleja muy bien la
intensidad de las actividades en el centro del comercio de la ciudad (Ottawa).
Figura 7: Número de abordajes en un día por sector y en distintos horarios [4]
Posteriormente se muestra un procedimiento experimental para elaborar datos de viaje en
forma desagregada, donde, para inferir los puntos de bajada de los usuarios, se utiliza el supuesto de
que un pasajero baja en un sector cercano a donde aborda la siguiente ruta. De esta manera, es posible
también calcular perfiles de carga para las rutas. Por otro lado, En [5] se describe una metodología para
detectar trasbordos y patrones de trasbordos.
Finalmente en [4], se puede proceder a la estimación de la matriz de origen-destino, que es uno
de los puntos más importantes en la modelación y planificación del sistema de transporte, en cuanto a
la geometría de la red y nuevos recorridos.
En [6], se describe la importancia de las encuestas de viaje para el estudio del contexto del
transporte urbano, en particular, se analizan los resultados obtenidos en la encuesta CATI (Computer-
Assisted Telephone Interview) realizada en Greater Montreal Area (GMA) a la luz de un sistema de
18
información geográfica (GIS). Esta encuesta se realiza cada 5 años en los hogares y cubre un 5% de la
población, lo que representa cerca de 160.000 personas pertenecientes a 65.000 hogares, y se obtiene
información de 400.000 viajes para un día promedio laboral.
Cada viaje se geo-referencia según la residencia del encuestado y se obtiene su origen, destino y
trasbordos. También se guarda información sobre las casas y características personales (edad, sexo, si
posee licencia de conducir, si es dueño de algún vehículo, sueldo), además se registran datos sobre el
viaje (propósito de éste, tiempo de partida, medios de transporte, entre otros.). La validación de las
respuestas de la encuesta y la completitud de los detalles de cada viaje se realizan mediante un software
GIS.
Mediante estas encuestas se construye la matriz de origen-destino (OD), cuyo objetivo es el
entendimiento de las tendencias principales que afectan los comportamientos de viaje de los usuarios.
También es posible estudiar el espacio demográfico según las consecuencias del crecimiento de la
población.
Gracias a este tipo de encuestas es posible generar mucha infamación valiosa en la
caracterización del sistema de transporte, por ejemplo, los sectores con mayor afluencia de gente,
cantidad de personas por distintos tramos y volumen del tráfico de automóviles. En [7] se agrega
también la posibilidad de inferir sobre el propósito de los viajes y análisis de los patrones de actividad de
los usuarios.
En [8] se indica que en las encuestas de viaje a los hogares, se capturan los viajes realizados a
través de los distintos medios de transporte y luego se expande estadísticamente para representar a la
población entera. Los datos recolectados son útiles en el análisis de las tendencias en el
comportamiento del grueso de la ciudad, pero no son adecuados para planificaciones de tránsito.
Se requiere de encuestas realizadas al abordar el medio de transporte público para compensar
insuficiencias como:
� Periodos entre encuesta demasiado largos (5 años por ejemplo).
� Tamaño de muestra insuficiente.
� Poco nivel de detalle o precisión de los datos.
19
De todas maneras, ambos tipos de encuestas requieren de mucho trabajo y son bastante caras
de realizar, en general sobre un millón de dólares. Es así, que los sistemas AFC con el uso de Smart-Cards
(tarjetas inteligentes), combinados con tecnologías AVL y GIS tienen mucho que ofrecer en esta área:
� En cada transacción se registra completa información a través del tiempo para todo el
segmento de usuarios de tarjetas, permitiendo un análisis entre días para observar la
variabilidad en el uso del sistema de transporte, además se obtiene mayor precisión,
como por ejemplo en las horas de partida.
� El sistema asocia datos de transacciones con datos en detalles de la operación de
tránsito, que son esenciales para la planificación operacional.
� Además ofrece la posibilidad de asociar a los usuarios de tarjetas con lugares de
actividad específicos y de esta forma se tiene una dimensión extra para analizar
patrones de actividad en el comportamiento del viaje.
� No es necesario ningún tipo de esfuerzo extra por parte del encuestado, más que el
hecho de mantener su tarjeta con carga.
Según [8], la metodología utilizada para obtener los datos de la encuesta mediante el sistema
AFC se puede resumir en:
� Detección de datos erróneos y sospechosos.
� Corrección de los datos reemplazando los valores erróneos y sospechosos.
� Estimación del paradero de bajada usando un enfoque desagregado para la secuencia de
transacciones.
� Detección de trasbordos basándose en coincidencias espacio-temporales.
� Inferencia e interpretación de la información de viajes según su localización y contexto.
La implementación es intensiva en datos y recursos computacionales. Como resultado se
obtienen información valiosa sobre sectores de alta actividad o puntos de interés (POI), caracterización
de la red de transporte, entre otros.
A modo de ejemplo se muestra la Figura 8, que ilustra la distribución espacial de los puntos de
bajada de los usuarios a un nivel de paraderos, además se hace la distinción por tipo de tarifa. El tamaño
20
de los círculos indica el número de bajadas al día, el color muestra la composición por parte de adultos
(rojo), estudiantes (azul) y adultos mayores (amarillo). De aquí se desprende que la mayoría de los
puntos de bajada ocurren en el centro de comercio de Ottawa y la mayoría corresponde a adultos no
estudiantes.
Figura 8: Cantidad de bajadas a nivel de paradero y por tipo de tarjeta [8]
Dado el número de ventajas del sistema AFC sobre las encuestas tradicionales, la alta resolución
de los datos y la completitud de la información, este sistema se muestra como la encuesta número uno
para la planificación de tránsito.
Por otra parte, en [9] se busca medir la variabilidad del tránsito utilizando los datos de las Smart-
Cards (tarjetas inteligentes). En la mayoría de las redes urbanas, la demanda de transporte público
cambia constantemente, dependiendo del día de la semana y otros factores como el clima o fallas en
servicios dados. Generalmente los operadores de transporte encuentra extremadamente difícil el ajuste
del servicio a la demanda, por otro lado, un mejor ajuste puede reducir costos de operación y optimizar
el uso del vehículo a través de la red. Para mejorar esto, se utilizaron los siguientes indicadores:
� Indicadores de variabilidad espacial:
La variabilidad espacial del tránsito se examinó a través de la enumeración de todos los
paraderos usados para abordar (punto donde se marca con la tarjeta). Primero se examinan todos los
21
paraderos usados para abordar, luego se estudia su frecuencia de uso para expresar un nivel de
regularidad. Esta frecuencia se puede medir de forma agregada o por tipo de tarjeta.
� Indicadores de variabilidad temporal y métodos de clustering:
La variabilidad temporal del tránsito se evalúa mediante técnicas de minería de datos, en
particular usando algoritmos de clustering. De esta manera es posible identificar patrones de abordaje
en el tiempo para tarjetas de clase similar. El algoritmo utilizado en concreto fue k-means [10] usando la
distancia de Hamming, y definiendo 4 clusters.
A continuación se muestra la Figura 9, que ilustra 4 clusters por cada tipo de tarjeta.
Figura 9: Centroides de clusters (en base al tiempo) para cinco clases de tarjeta [9]
Se puede observar que algunos clusters son bastante importantes dentro de un tipo de tarjeta.
Por ejemplo el cluster 1 de adultos regulares (A-R 1), con tiempo de partida a las 7:00 y 17:00 horas
cubren alrededor del 37% de los abordajes para este tipo de tarjeta.
2.1.1 Estimación del punto de bajada
El método de estimación de bajadas de pasajeros expuesto en [11] se basa principalmente en el
hecho de que un usuario se baja en el sitio perteneciente a la ruta del bus o metro utilizado más cercano
al punto donde se realizó la siguiente transacción o siguiente abordaje. Si el tiempo transcurrido entre
22
la bajada estimada y la realización de la siguiente transacción es lo suficiente largo, se dice que esa
bajada es el término de un viaje, y de no ser así, se considera como un trasbordo. Para el cálculo de la
bajada de la última transacción del día, se utiliza el supuesto de que el usuario vuelve al punto de partida
(primera transacción del día).
En la Figura 10 se ejemplifica lo explicado anteriormente, los puntos negros señalan el abordaje
de un bus, se llama “Vanishing route” a la ruta que utilizó el pasajero en un viaje y se enmarca con un
cuadrado el punto de bajada estimado, que es el punto más cercano dentro de la “Vanishing route” al
siguiente abordaje.
Biks1
21iks
11iks
41iks
51iks
jiks1
ikV1
jiks2
jiks3
Biks2
Biks3
ikV2
ikV3
{ }ikikikik VVVJ 321 ,,=
ikd1
ikd2
ikd3′
Figura 10: Estimación del punto de bajada [11]
En [1] se introduce el concepto de “Tiempo Generalizado” como una mejora al método
expuesto en [11]. El “Tiempo Generalizado” es un criterio mejorado para estimar el paradero de bajada,
que no solo toma en cuenta factores espaciales, esto es, la distancia a caminar hacia los paraderos, sino
que también incluye factores temporales, ya que existen casos donde el paradero más cercano no
implica un menor tiempo total de viaje, como se ilustra en la Figura 11.
23
Figura 11: Elección de paradero [1]
Un método que solo considere distancia, estimaría a B como el punto de bajada, pero si a la vez
se toma en cuenta el tiempo necesario para llegar al punto de la siguiente transacción de abordaje se
estimará A como punto de bajada.
Con los datos de estimación de bajadas, es posible realizar estudios de localización de destinos
de viajes por ejemplo.
Figura 12: Destinos de viajes [12]
A su vez, también es posible construir matrices de origen – destino, información muy valiosa
para los estudios realizados en áreas de transporte, donde es posible observar los datos a distintos
niveles de detalle. En la Tabla 2 se aprecia una matriz origen – destino a un nivel muy agregado, solo a
modo de ejemplo.
24
Tabla 2: Matriz OD [12]
O/D North West East Center South South-East Oi North 552 145 195 410 115 125 1542 West 122 1093 660 983 125 196 3179 East 208 562 1557 1126 404 912 4769
Center 374 824 961 889 509 748 4305 South 124 150 428 612 476 264 2054
South-East 117 177 972 754 217 1261 3498 Dj 1497 2951 4773 4774 1846 3506 19347
2.2 Minería de Datos
La minería de datos consiste en la extracción de información que reside de manera implícita en
los datos. En otras palabras, la minería de datos prepara, sondea y explora los datos para sacar la
información que no es evidente en una primera instancia.
Bajo el nombre de minería de datos se engloba todo un conjunto de técnicas encaminadas a la
extracción de conocimiento implícito en las bases de datos. Está fuertemente ligado con la supervisión
de procesos industriales de todo tipo ya que resulta muy útil para aprovechar los datos almacenados en
las bases de datos.
Las bases de la minería de datos se encuentran en la inteligencia artificial y en el análisis
estadístico. Mediante los modelos extraídos utilizando técnicas de minería de datos se aborda la
solución a problemas como la predicción, clasificación y clustering.
La búsqueda manual de patrones sobre los datos existe desde hace siglos, por ejemplo los
métodos basados en el teorema de Bayes (1700s) y regresión (1800s). Los adelantos computacionales
han permitido un gran aumento en la recolección, almacenamiento y manipulación de datos. De esta
forma, en la medida que aumenta el volumen de datos y su complejidad, se hacen más necesarias
técnicas que permitan obtener información automatizadamente.
2.2.1 Aprendizaje no supervisado
En aprendizaje no supervisado, un modelo es ajustado a las observaciones. Se distingue del
aprendizaje supervisado por el hecho de que no hay un conocimiento a priori. El aprendizaje no
supervisado, trata típicamente los datos de entrada como un conjunto de variables aleatorias, siendo
construido un modelo de densidad para el conjunto de datos.
El objetivo es inferir directamente las propiedades de la densidad de probabilidad sin la ayuda
de un “supervisor” que provea respuestas o margen de error para cada observación.
25
Existen diversas técnicas de aprendizaje no supervisado que se detallarán a continuación.
2.2.2 Clustering
Desde el punto de vista de Machine-Learning, el clustering puede ser considerado el principal
tipo de aprendizaje no supervisado, su objetivo es dividir los datos en grupos (clusters), de modo que los
elementos asignados al mismo clúster sean similares entre sí, y los elementos pertenecientes a clusters
distintos sean diferentes.
En el análisis de clusters, se busca agrupar una serie de vectores de acuerdo con un criterio de
cercanía. Esta cercanía se define en términos de una determinada función de distancia, como por
ejemplo la euclidiana.
Dado que generalmente los vectores de un mismo grupo (o clusters) comparten propiedades
comunes, el conocimiento de los grupos puede permitir una descripción característica de un conjunto de
datos multidimensional complejos.
Algunas aplicaciones para clustering pueden ser:
• Marketing: agrupar clientes con comportamientos similares dado su historial de
compras.
• Biología: clasificación de plantas y animales según sus características.
• Aseguradoras: identificación de fraudes.
• Estudios de terremotos: agrupación de epicentros observados para identificar zonas de
peligro.
• WWW: clasificación de documentos, clustering de weblogs para descubrir patrones de
comportamiento en la web.
Un algoritmo muy utilizado en clustering dado que requiere poco poder de procesamiento es k-
means [13], [14], la desventaja es que se debe indicar a priori el número de clusters a encontrar. La idea
principal de este algoritmo es particionar n datos en k clusters, cada elemento pertenece al clúster
donde la distancia entre el elemento y la media del clúster sea menor.
26
Sea { }1,..., nX x x= el conjunto de datos, k-means busca particionar los datos en k grupos, con
k ≤ n. Se busca un conjunto de particiones { }1,..., kS s s= tal que la suma de cuadrados entre los
elementos de S sea mínima:
Ecuación 1: Función a minimizar en k-means
Donde µi es la media entre los elementos de si.
Otro algoritmo de clustering es SOM (Self-Organizing Map)[15], también llamado redes de
Kohonen, son un tipo de red neuronal no supervisada, distribuida de forma regular en una rejilla de,
normalmente dos dimensiones, cuyo fin es descubrir la estructura subyacente de los datos introducidos
en ella. A lo largo del entrenamiento de la red, los vectores de datos son introducidos en cada neurona y
se comparan con el vector de peso característico de cada neurona. La neurona que presenta menor
diferencia entre su vector de peso y el vector de datos es la neurona ganadora y ella y sus vecinas verán
modificados sus vectores de pesos.
2.2.3 Métodos de clustering
En general, los métodos de clustering se dividen en tres tipos [16], [17]:
Clustering de particionamiento: La idea de este método es particionar el conjunto de datos, si se
tienen n vectores de datos, se busca dividirlos en k grupos o clústers llamados particiones, entonces se
debe cumplir que cada partición es distinta de vacío, la intersección entre particiones diferentes es vacía
y la unión de todas las particiones debe generar el conjunto universo de datos.
Clustering jerárquico: Principalmente se busca construir una jerarquía de clústers, existen dos
tipos:
• Aglomerativa: Cada observación parte como un clúster de 1 elemento y se van uniendo
los clústers para ir subiendo en la jerarquía.
27
• Divisiva: Se parte con un gran clúster que contiene todas las observaciones para luego
irse dividiendo iterativamente en clústers más pequeños, a medida que se va bajando en
la jerarquía.
Clustering basado en densidad: Estos métodos se basan en el concepto de densidad usado en
Física, se aborda en mayor detalle en la siguiente sección.
2.2.4 Clustering basado en densidad
La idea principal, es que los clústers se generan cuando la vecindad de los elementos excede
algún umbral de densidad definido.
Sea { }1,..., nX x x= el universo de datos, { }1,...,t tmC c c= el conjunto de clústers en la iteración
“t”, δ el umbral de densidad, card(ck) el número de elementos in el clúster ck. Un elemento xj pertenece
a ck cuando (c , )tk jD x R≤ , donde D es una función de distancia y R es un radio. El proceso termina
cuando kc C∀ ∈ , card(ck) ≤ δ, sino el centroide del clúster es redefinido [17].
Dentro de los algoritmos de clustering basados en densidad, se tiene a DBSCAN y OPTICS, los
que se explican a continuación.
2.2.4.1 Algoritmo DBSCAN
“Density-Based Spatial Clustering of Applications with Noise” [18], define los clústers utilizando
el concepto de accesibilidad por densidad (density reachability). Un punto q es alcanzable por densidad
desde un punto p, si es que existe una distancia máxima Ԑ (primer parámetro del algoritmo) entre ellos,
esto es, está dentro de la vecindad respecto a Ԑ y si es que p está rodeado de una cantidad suficiente de
puntos (segundo parámetro del algoritmo), de forma que se pueda considerar a p y q como miembros
de un clúster. Se dice que q es alcanzable por densidad desde p si existe una secuencia p1,…,pn de puntos
con p1 = p y pn = q donde cada pi+1 es alcanzable por densidad desde pi. La relación de accesibilidad por
densidad no es simétrica, ya que por ejemplo, q puede quedar en la “esquina” de un clúster, sin tener
una cantidad de vecinos suficientes como para ser contado dentro de un clúster. Es por esto que se
introduce la noción de conectado por densidad (density connected): dos puntos p y q están conectados
por densidad si es que existe un punto r tal que r con p y r con q son alcanzables por densidad.
28
Figura 13: Density-reachable, density-connected [19]
Luego cada clúster debe cumplir con:
1. Todos los puntos de un clúster deben estar conectados por densidad.
2. Si un punto está conectados por densidad con algún punto del clúster, entonces ese
punto es parte del clúster también.
Las ventajas de este algoritmo es que no necesita conocer a priori el número de clústers a
buscar y además tiene un buen manejo de outliers o ruido.
Las desventajas son que este algoritmo no responde bien cuando se utilizan distancias que
manejan muchas dimensiones y además no es útil en casos donde los datos tienen densidad variable
(conjuntos de datos jerárquicos).
La complejidad de este algoritmo es ( log )O n n .
2.2.4.2 Algoritmo OPTICS
“Ordering Points To Identify the Clustering Structure” [19] es un algoritmo que comparte las
mismas bases que DBSCAN, pero soluciona uno de sus principales problemas: la detección de clústers en
datos con densidad variable. Para lograr esto, los puntos de la base de datos son ordenados linealmente,
de forma que los puntos más cercanos sean vecinos en el ordenamiento.
Al igual que DBSCAN, OPTICS requiere dos parámetros: Ԑ, la distancia máxima (o radio) a
considerar y MinPts, el número de puntos mínimos requeridos para formar un clúster. Un punto p es un
core point si dentro de su Ԑ-vecindad ( )N pε existen al menos MinPts puntos. A diferencia de DBSCAN,
este algoritmo considera aquellos puntos que pueden ser parte de un clúster más denso, de forma que a
cada punto se le asigna una distancias core que esencialmente describe la distancia respecto a su punto
número MinPts:
29
Ecuación 2: Core-Distance [19]
La distancia de accesibilidad o reachability distance de un punto p desde un punto r, es la
distancia entre p y r, o la distancia core (core distance) de r:
Ecuación 3: Reachability-distance [19]
Entonces se tiene que si r y p son vecinos cercanos, la reachability-distance es la distancia menor
a Ԑ que se necesita para que r y p pertenezcan al mismo clúster.
La core distance y reachability-distance son indefinidas si es que no se logra un clúster lo
suficientemente denso respecto a Ԑ. Esto nunca ocurriría si es que se utiliza un Ԑ lo suficientemente
grande, pero entonces cada Ԑ-vecindad retornaría todos los puntos de la base de datos, volviéndose un
problema intratable desde el punto de la eficiencia computacional. Luego, el parámetro Ԑ es necesario
para acotar la densidad de los clusters que no se considera relevante.
Al igual que en el caso de DBSCAN, la complejidad de este algoritmo es ( log )O n n . Los autores
de OPTICS [19] señalan que este algoritmo es 1.6 veces más lento que DBSCAN.
3 Solución propuesta
3.1 Descripción de los datos
Los datos involucrados en este trabajo, son aquellos generados por un sistema de transporte
público con recolección tarifaría automática (AFC), junto con sistemas de localización automática de
vehículos (AVL).
30
A través de la Smart-Card (tarjeta inteligente) utilizada por los pasajeros en cada abordaje, se
registran datos como el id y tipo de tarjeta, fecha y hora de la transacción, patente del vehículo o
estación de metro utilizada, entre otros.
Mediante los dispositivos GPS disponibles en los buses, es posible tener datos de
posicionamiento, hora e id del vehículo.
3.2 Búsqueda de patrones
Como se ha mencionado con anterioridad, cada vez que un usuario utiliza el sistema de
transporte público, ya sea mediante buses o el metro, debe “marcar” con su Smart-Card (tarjeta Bip!) en
el dispositivo validador. Mediante este acto, queda automáticamente registrado el id de la tarjeta que se
usó y el tiempo (fecha y hora) en que se llevó a cabo la transacción, en un proceso posterior se asocian
los datos de posicionamiento, esto es, las coordenadas (latitud y longitud) del punto donde se realizó la
transacción. Estos serán los datos principales que se utilizarán para buscar patrones de uso diario.
Para poder visualizar como un usuario realiza transacciones en el sistema diariamente, se
provee un gráfico de días vs tiempo (hora dentro del día), además sobre cada punto se muestra la
comuna donde se llevó a cabo la transacción y no sus coordenadas (latitud y longitud) a modo de
simplificación visual, de todas formas en este ejemplo particular, efectivamente los puntos de subida
(donde se realiza la transacción) pertenecientes a una misma comuna y una misma posición dentro del
día, son muy cercanos entre sí (pocos metros de diferencia), o sea pertenecen al mismo paradero.
En la figura solamente se muestran días laborales, ya que son los más importantes al momento
de buscar patrones de usuarios. Los días 21 y 22 no contienen datos por ser estos un sábado y un
domingo respectivamente.
31
Figura 14 : Transacciones de un usuario
5
Como se puede observar en el caso particular de la figura, existe una regularidad diaria en los
puntos donde se realizan las transacciones, en orden de más temprano a más tarde se tiene la siguiente
secuencia: San Bernardo – Santiago – Las Condes - Las Condes - Las Condes – Santiago.
3.2.1 Análisis del tiempo
Si se analiza solo la primera transacción de cada día es posible decir que es muy regular ya que
siempre es en San Bernardo, a pesar de esto, se puede observar que la hora en que se realizaron son
bastante diferentes entre sí, en la Tabla 3 se muestra la hora exacta en que fueron hechas las primeras
transacciones del día:
Tabla 3: Primera Transacción del día
Hora
9:16:11
9:41:26
9:15:49
10:05:48
8:45:08
5 Fuente: Elaboración propia.
32
Puede haber diferencias de hasta más de una hora entre transacciones que cumplen la misma
función (en esto caso, ser la primera transacción del día). De hecho, analizando los tiempos de la cuarta
transacción del día podemos encontrar tiempos aún más distintos, con más de dos horas de diferencia
(ver Tabla 4).
Tabla 4: Cuarta Transacción del día
Hora
17:58:05
18:41:36
17:43:32
16:30:09
18:47:42
Estás diferencias de tiempo se pueden explicar por múltiples razones, como congestión en
distintos puntos de la red del sistema de transporte, impuntualidad de los usuarios en ciertos días,
cambios de actividades, falla en la frecuencia de buses, entre otros.
Cualquier tipo de modelo que use rangos de tiempo discreto fallaría, porque sería imposible
agrupar transacciones que tengan la misma función (primera transacción del día, segunda, tercera, etc.)
de distintos días, sin incluir además la transacción siguiente o anterior de algún día. Este traslape
inutilizaría cualquier tipo de estudio sobre patrones.
Por los motivos explicados anteriormente, se decidió describir la variable tiempo como una
secuencia dentro del día, esto es, “primera transacción”, “segunda transacción”, etc.
Es posible ver que mediante este tratamiento del tiempo se pierde información comparado con
otros modelos que puedan utilizar el tiempo por rangos discretos, pero sirve para poder realizar una
comparación entre distintos días, siempre y cuando se mantenga el orden de la función de cada
transacción en el día, este tema se aborda más adelante.
3.2.2 Análisis de la posición
Para realizar el estudio de las posiciones donde se llevan a cabo las transacciones, la información
optima sería el paradero exacto donde el usuario abordó el bus, este nivel de granularidad es óptimo,
dado que es información muy detallada y a la vez simple desde el punto de vista de cálculo
computacional sobre paraderos, suponiendo que se dispone de la definición completa de paraderos,
33
como un código identificador único, coordenadas exactas de su posición, recorridos de buses que lo
utilizan, entre otros.
Sin embargo, el sistema de transporte en estudio (Transantiago) no dispone de esta información
(paraderos asociados a transacciones); por lo tanto se deben buscar alternativas que permitan el estudio
de patrones de usuario utilizando la información disponible, esto es para el caso de la posición, las
coordenadas estimadas del punto donde se realizó la transacción o puntos de subida de los usuarios.
Actualmente existe un desarrollo preliminar de algoritmos que permiten asignar un paradero a una
transacción, por este motivo, no se puede determinar su nivel de precisión, y por ende no puede ser
utilizado en este trabajo, debido a la sensibilidad que hay en la búsqueda de patrones frente a errores
en la asignación de paraderos.
En primera instancia, se podría pensar en utilizar una grilla o cuadricula como partición, con
algún largo y ancho fijos. El problema es que mientras menos fina la grilla, aumenta la probabilidad de
agrupar dentro de un mismo rectángulo (componente de la grilla) a dos paraderos distintos, sobre todo
si estos son cercanos. De esta forma disminuiría la calidad en la búsqueda de patrones. Esto se explica
en la Figura 15: los paraderos se muestran como rectángulos, las estrellas representan transacciones
realizadas en el paradero de la izquierda y los puntos representan transacciones realizadas en el
paradero de la derecha.
Figura 15: Agrupación de transacciones diferentes6
De forma inversa, si es muy fina la grilla, aumenta la probabilidad de que a un mismo paradero
se le asigne en una medición un rectángulo en particular y luego en otra medición, otro diferente. Esto
puede ocurrir dada la naturaleza estimativa de las coordenadas de los puntos de subida de los usuarios,
sumado a la precisión de las herramientas GPS utilizadas en el cálculo de la posición. Además,
independientemente del tamaño de la grilla, puede suceder que el corte de separación entre un
rectángulo y otro atraviese encima de un paradero, separando transacciones que correspondan a un
34
mismo paradero. Este efecto se puede apreciar en la Figura 16, el paradero se muestra como un
rectángulo sobre la grilla y los puntos representan transacciones realizadas en este paradero.
Figura 16: Transacciones separadas7
Otro tipo de partición posible son por comunas o zonificación Estraus8 con aproximadamente
600 diferentes zonas, pero comparten las mismas desventajas descritas anteriormente.
Para entender mejor el siguiente concepto, se observa sólo la primera transacción del día de un
usuario con comportamiento regular (extraído de la Figura 14). De esta forma, se tiene que este usuario
siempre utiliza el mismo paradero todas las mañanas, por simplicidad se utiliza en la figura el nombre de
la comuna a la cual pertenece este paradero.
Figura 17: Primera Transacción del día9
En la Figura 18 se pueden visualizar estas mismas cinco transacciones como puntos sobre el
plano (coordenadas obtenidas a través de dispositivos GPS).
6 Fuente: Elaboración propia. 7 Fuente: Elaboración propia. 8 Zonificación basada en tipo de uso de suelo. 9 Fuente: Elaboración propia.
35
Figura 18: Mapa Primera Transacción del día10
Es posible ver que aunque estas transacciones pertenecen a un mismo paradero, no comparten
exactamente la misma latitud y longitud, o sea, están un poco desplazadas entre sí. A pesar de esto es
posible ver que se encuentran agrupadas y no distan entre ellas más de algunos metros.
De esta observación nace la idea de buscar transacciones de un usuario que compartan la misma
función dentro del día (primera, segunda… n-esima transacción del día) de diferentes días, y compararlas
entre sí, para analizar si están lo suficientemente cerca para determinar que pertenecen a un mismo
paradero.
Si un usuario tiene un comportamiento regular, debería tener en general el mismo número de
transacciones diarias a través de la semana. Como en ciertas ocasiones esto puede no ser así, se debe
buscar la moda de transacciones diarias dentro de la cantidad de días que se dispone como información
de cada usuario.
Una vez que se conoce la moda del número de transacciones diarias de un usuario, se determina
la cantidad de días que tienen el mismo número de transacciones que la moda, esto es, la frecuencia de
la moda fmoda:
dN
moda ii
f X=∑
Ecuación 4: Frecuencia de la moda
Donde Nd es el número total de días de la muestra y iX = 1 si el número de transacciones
realizadas el día i es igual a la moda y 0 en otro caso.
36
Luego, se debe determinar si la frecuencia de la moda (transacciones por día) es suficiente
respecto al número de días de la muestra. Para cada usuario se tiene:
modam
d
TN
f ≥
Ecuación 5: Restricción frecuencia de moda
Donde Tm (threshold) es el umbral (que va entre 0 y 1) que se utilizará para evaluar si se acepta
como suficientemente regular o no el número de transacciones diarias de un pasajero.
Mientras más cercano a 1 sea Tm, se deberían encontrar por lo general menos comportamientos
regulares, pero se asegura una regularidad de mayor calidad. Mientras más cercano a cero, sucede lo
contrario, o sea, se puede encontrar un mayor número de usuarios que cumplan está regla, pero la
regularidad del comportamiento podría ser menos clara.
3.2.2.1 Clustering
Una vez que se ha superado la cantidad de días con número de transacciones iguales a la moda,
se filtran los demás días de la muestra, (aquellos que tienen un número de transacciones diferentes a la
moda), luego se procede a utilizar un algoritmo de clustering para cada grupo de transacciones de los
distintos días.
Dado que la posición asociada a las transacciones se encuentra en coordenadas de latitud y
longitud, que es un sistema angular, se debe utilizar una transformación a un sistema cartesiano para
poder realizar las comparaciones de distancia entre puntos. El sistema escogido para esto fue UTM
(Universal Transverse Mercator), que tiene la particularidad de usar metros como unidad de medida.
Para más detalles sobre este sistema, revisar el anexo 8.2.
Cuando se aplica el algoritmo de clustering a todos los puntos que corresponden a una misma
función dentro del día (por ejemplo, primera transacción del día), puede suceder que efectivamente
todos los puntos estén lo suficientemente cerca, esto es, dentro de un círculo de radio Ԑ. Por otro lado,
si se piensa en que alguno de esos puntos es muy distante respecto al resto (fuera del círculo de radio
Ԑ), no se debe considerar como perteneciente al mismo paradero. De esta forma, se aplica el mismo
número de clustering que el número de transacciones por día, que es la moda, ya que como se dijo
anteriormente, los datos fueron filtrados.
10 Fuente: Elaboración propia.
37
Al aplicar clustering a las transacciones pertenecientes a una misma función dentro del día,
puede suceder que se generen más de un clúster, en el caso que un usuario no tenga un
comportamiento regular, o sea, usando rutas diferentes a través de la semana, o utilizando paraderos
distintos aunque se tenga la misma función dentro del día.
Sea Nc el número de transacciones de un usuario pertenecientes a una misma función o
secuencia dentro de un día, al aplicar clustering se debe evaluar si el clúster es lo suficientemente
“robusto”. En el caso que se genere más de un clúster se debe buscar aquel que contenga el mayor
número de transacciones, este clúster “ganador” debe ser evaluado para determinar si cumple que su
número de transacciones Ng respecto a Nc es mayor a un umbral Tc.
Entonces se debe cumplir:
gc
c
NT
N≥
Ecuación 6: Restricción población clúster
Si al aplicar clustering a todas las transacciones pertenecientes a una misma función del día se
tiene que algún clúster no cumple con la condición anterior, se rechaza que el usuario tenga un
comportamiento regular, o sea, no se puede aseverar que existe un patrón de uso en el sistema.
Para explicar mejor, se da el siguiente ejemplo: se tienen 50 días laborales de un usuario que
realiza 3 transacciones diarias regularmente, al aplicar clustering para todas las primeras transacciones
del día se encuentran 2 clústers, el primer clúster tiene 20 transacciones, el segundo tiene 30
transacciones y se define un umbral Tc = 0.7.
Entonces se tiene que Ng = 30 y Nc = 50, luego 30/50 = 0.6 es menor al umbral Tc (0.7) por lo
que se rechaza el clúster y por ende se descarta que exista un patrón de usuario.
En otro ejemplo, se tienen 100 días laborales de un usuario que realiza 4 transacciones diarias
regularmente, al aplicar clustering para todas las terceras transacciones del día se encuentran 3 clústers,
el primer clúster tiene 5 transacciones, el segundo tiene 6 transacciones y el tercero tiene 89
transacciones y se define un umbral Tc = 0.85 o 85%.
Luego se tiene que Ng = 89 y Nc = 100, entonces 89/100 = 0.89 es efectivamente mayor al
umbral Tc (0.85) por lo que se acepta el clúster.
38
Se podría decir en este caso, que aquellas 11 transacciones pertenecientes a pequeños clústers
alejadas de las demás son outliers, ya que no hay correspondencia con la gran mayoría.
En el presente trabajo, se tomó la decisión de utilizar el algoritmo OPTICS para el clustering de
datos. A diferencia de algoritmos como k-means (ver sección 2.2.2) OPTICS (ver sección 2.2.4.2) permite
generar clusters sin conocer con anterioridad el número de clusters a encontrar.
3.2.3 Generación de patrones
Una vez que se cumplió con la Ecuación 5 y la Ecuación 6, se procede a buscar las coordenadas
que representan a cada clúster “ganador” en cada función del día o secuencia de realización de las
transacciones, en este caso se usa la mediana de la posición de los puntos que pertenecen a cada clúster
“ganador”.
Luego para cada usuario se guarda el representante de cada clúster en el mismo orden de la
secuencia diaria en que fueron generados.
3.3 Imputación de datos
La idea principal de la imputación es corregir datos, esto se realiza con la ayuda de los patrones
de usuario que se describieron anteriormente. En este caso, lo que se quiere corregir es la estimación de
las bajadas descritas en [1]. A grandes rasgos, este proceso se explica en la siguiente sección.
3.3.1 Viajes con información incompleta
Dentro de las posibilidades de un viaje, existe la opción de utilizar el sistema de transporte
público y alternar en cierto punto con algún otro tipo de medio de transporte, por ejemplo: taxis,
colectivos, vehículos privados, entre otros. También existe el efecto de la evasión blanda, que ocurre
cuando un pasajero no marca en alguna parte de su recorrido, por ejemplo, cuando el bus está muy
lleno, pero de todas formas paga su pasaje en otro parte del viaje.
Cuando un usuario tiene un comportamiento regular a través del sistema de transporte público,
pero en alguna ocasión puntual realiza algún cambio en su comportamiento de viaje, no completamente
sino que en solo un tramo o dos, se perderá esa información (punto de subida) de las bases de datos del
sistema AFC y se dirá que en ese día se tiene para ese usuario un viaje incompleto.
39
En primera instancia, sería complicado analizar que viajes dentro de los datos corresponden a
viajes incompletos y más difícil aún sería analizar la posible opción de movilización que utilizó el usuario
en aquellas ocasiones. Por este motivo se hace imprescindible un estudio previo del comportamiento de
cada usuario, es por esto que primeramente se llevó a cabo un análisis de aquellos usuarios que poseen
un comportamiento regular a través de los días laborales y se determinaron los casos donde fue posible
encontrar un patrón de comportamiento como se explicó anteriormente.
El efecto que tiene el utilizar otro medio de transporte o la evasión blanda en algún punto del
viaje, sobre el algoritmo de estimación del punto de bajada, es que por lo general se estima un punto
demasiado lejos de la siguiente transacción, por lo que se rechaza como una posibilidad de bajada
viable, disminuyendo la capacidad de estimación del algoritmo.
Luego, si se pudiera determinar un valor probable para el lugar donde se tomó otro medio de
transporte, se podría usar esa posición como un pivote para estimar el punto de bajada de la transacción
realizada antes de utilizar otro medio, ya que se podría decir que el usuario se bajó en algún lugar
cercano al punto donde utilizó otro medio de transporte o donde no marcó con su tarjeta Bip!.
3.3.2 Búsqueda de transacciones faltantes
Una vez que se tiene definido un patrón para un usuario, se busca encontrar viajes incompletos
para poder estimar o imputar su valor más probable, basándose en que se debe haber utilizado otro
medio de transporte en un punto cercano a donde hubiese usado el sistema de transporte público, dado
que en forma regular se ha movilizado antes por estos puntos, y como se dijo anteriormente, solo en
aquellos casos donde el comportamiento no es completamente diferente al patrón original.
Si N es el número de transacciones diarias que contiene el patrón de un usuario (que a la vez es
la moda que se encontró a través de los días de la muestra como se explicó anteriormente), se buscan
días que tengan N-1 transacciones.
Luego se procede a analizar si las N-1 transacciones del día en estudio corresponden con el
patrón, para esto se prueban todas las combinaciones posibles utilizando una transacción “comodín”, o
sea, se va moviendo este comodín vacío a través de la secuencia de transacciones diarias
reposicionándolas. Luego se comparan las transacciones del día en estudio con las que les corresponda
en posición con las transacciones del patrón. Esta búsqueda de correspondencia es más estricta de lo
que se pensó hacer en un principio, que era solo mirar la transacción anterior a la transacción faltante,
esto inspirado en una simplificación utilizada en las cadenas de Markov (ver anexo 8.3).
40
Para determinar si una transacción del día en estudio es cercana a una transacción del patrón, se
compara la distancia euclidiana de las posiciones donde fueron realizadas.
Luego, para la comparación entre las distintas transacciones se debe cumplir que cada
transacción del día en estudio esté a una distancia máxima Ԑ de la transacción que le corresponda del
patrón, entonces si Pd es la posición de la transacción del día en estudio y Pp es la posición de la
transacción del patrón que le corresponde, se debe cumplir:
d pP P ε− ≤
Ecuación 7: Restricción distancia máxima
Si alguna transacción no cumple esta condición se rechaza este reordenamiento del día en
estudio y se prueba con otro reordenamiento, esto es, colocando la transacción “comodín” en otra
posición en la secuencia de transacciones del día en estudio. Si ninguna combinación logra que se
corresponda el día en estudio con el patrón, se rechaza este día como candidato a contener una
transacción imputable como viaje incompleto.
A Continuación se muestra la Figura 19 como ejemplo, se tiene un usuario que realiza 3
transacciones diarias regularmente, por lo que es posible identificar un patrón con transacciones: A – B –
C en ese orden a través del día (estas letras además indican una posición diferente). Luego de analizar
varios días dentro de la muestra de este usuario, se encuentra un día en particular con N-1 = 2
transacciones: A – C. Se procede a comparar las posibles combinaciones utilizando un “comodín”,
representado por un cuadrado vacío y se resalta con un rectángulo la combinación que “coincide” con el
patrón.
41
Figura 19: Comparación Día - Patrón11
Si se determina que la transacción faltante de un viaje incompleto es la primera del día, no se
puede utilizar para imputar alguna bajada, ya que no hay una transacción anterior a esta.
Este mismo procedimiento se realiza para días que tengan N-2 transacciones. Para esto se
deben utilizar 2 transacciones “comodines”, se verifica si alguna combinación posible (moviendo los 2
“comodines” a través de las N-2 transacciones del día en estudio), coincide con las del patrón del
usuario, entonces se puede decir que es un viaje incompleto con dos transacciones faltantes.
Una vez que se tiene una combinación de un viaje incompleto coincidente con el patrón, se usa
la posición que corresponda del patrón para imputar. A su vez, es necesario imputar la hora a la que se
debe haber llevado a cabo esta transacción faltante (o punto donde se utilizó otro medio de transporte).
Este proceso no es directo, ya que como se mostró en la Figura 14, es imposible discretizar por rangos
de tiempo para un usuario en general. Luego, lo que se hace es guardar las diferencias de tiempo
existentes entre las transacciones en los días que tienen el mismo número de transacciones que la
moda.
Con estas diferencias de tiempo entre transacciones se calcula un delta promedio entre cada
una, entonces para cada transacción perteneciente al patrón final, se almacena su delta de tiempo
promedio respecto a su transacción anterior y también la posterior (siempre como módulo de tiempo,
o sea, un valor positivo), para la primera transacción del patrón solo se guarda el delta promedio de
tiempo posterior y para la última solo la anterior.
11 Fuente: Elaboración propia.
42
Una vez que se establecen los delta promedio de tiempo de las transacciones pertenecientes al
patrón, se utilizan para estimar el tiempo de la transacción a imputar, o sea, cada vez que se determina
una posición t donde se puede encontrar una transacción faltante, se toma el tiempo de la transacción
anterior del día en estudio, esto es t-1, y se le suma el delta de tiempo promedio posterior
perteneciente a t-1 o se le suma el delta promedio de tiempo anterior perteneciente a t, también es
posible tomar el tiempo de la transacción posterior a t, o sea t+1 y se le resta el delta de tiempo
promedio anterior perteneciente a t+1 o se le resta el delta promedio de tiempo posterior
perteneciente a t. Esta elección es relevante cuando se tienen valores nulos para algunos deltas de
tiempo, y en especial cuando se trata de una transacción faltante en la primera o última posición.
Sea Tt’ el tiempo a imputar para una transacción faltante en la posición t dentro de un día, Tt el
tiempo real al que se llevó a cabo una transacción del día en la posición t, ΔTant(t) la diferencia de
tiempo promedio existente entre las transacciones t y t-1 (anterior), ΔTpos(t) la diferencia de tiempo
promedio existente entre las transacciones t y t+1 (posterior), luego se tienen las diferentes opciones
para calcular el tiempo de una transacción imputada expresadas desde la Ecuación 8 a la Ecuación 11. Se
tiene además que ΔTant(t) = ΔTpos(t-1) y ΔTant(t+1) = ΔTpos(t).
t t 1 pos(t 1)T ' T T− −= + ∆
Ecuación 8: Tiempo, opción 1
t t 1 ( t )T ' T Tant−= + ∆
Ecuación 9: Tiempo, opción 2
t t+1 ant (t+1)T ' T T= − ∆
Ecuación 10: Tiempo, opción 3
t t+1 (t )T ' T Tpos= − ∆
Ecuación 11: Tiempo, opción 4
Finalmente se deben almacenar los dato de posición y tiempo (que debe contener la fecha
también) imputados asociados al usuario para ser usados como pivotes para poder encontrar el punto
de bajada de la transacción real anterior a la imputada.
43
3.4 Eficiencia en el cálculo
Dado el gran volumen de datos que se deben procesar, es necesario diseñar algoritmos que
permitan ser paralelizados, es por esto que el desarrollo se llevó a cabo manteniendo una clara
separación entre las tareas realizadas para de esta forma poder procesar los datos de forma paralela.
Una de las líneas de investigación en este rubro fue la utilización de una arquitectura de procesamiento
distribuido llamada Xgrid de Apple, la principal ventaja de Xgrid es su bajo costo, dado que es posible
aumentar el poder de cálculo agregando desde servidores a notebooks Mac, utilizando implementos
comunes de redes domésticas como routers y cables de red estándar.
La arquitectura básica consta de clientes que envían peticiones de procesamiento a un
controlador que administra las peticiones y se encarga de gestionar el procesamiento de datos en
computadores llamados agentes.
Figura 20: Arquitectura Xgrid12
La forma de utilizarlo es mediante la línea de comandos como se muestra a continuación:
xgrid -h localhost -job submit script.sh 17983 18498 -in /Users/Shared/j/
Con –h se indica el computador dentro de la red donde está instalado el “controlador”.
Con –job submit se indica el nombre del programa a ejecutar, además en este caso se entregan
los parámetros que recibe el programa: 17983 18498, que corresponden al id inicial y final que se
procesaran.
12 Fuente: http://www.macresearch.org/the_xgrid_tutorials_part _i_xgrid_basics Fecha último acceso: 03/04/2011
44
Con –in se especifica la carpeta donde se ejecutará la aplicación, de esta forma es posible
agregar los archivos necesarios para el programa.
En general Xgrid recibe archivos ejecutables para procesar, pero como en el desarrollo de este
trabajo se utilizó Java que genera archivos que son interpretados por la máquina virtual se debe hacer
uso de un script que contenga la información necesaria para ejecutar la aplicación java. En este caso se
tiene la siguiente información dentro del script:
#!/bin/sh
java -cp ./postgresql-8.4-702.jdbc4.jar:. App $1 $2
Se debe escribir #!/bin/sh para que el archivo script sea ejecutado por el comando sh del
sistema. El comando de ejecución Java recibe el classpath con la información de donde se encuentra la
biblioteca jdbc de forma relativa, el nombre del programa (App) y los parámetros, se escribe $1 y $2
para que se entreguen en el mismo orden los parámetros que recibe script.sh.
La otra alternativa que se estudió, fue el uso de threads, para utilizar todos los procesadores
disponibles en el contexto de una sola máquina. Para establecer el número de threads a utilizar se
usaron “semáforos”, lo que se explica con mayor detalle en la sección 4.2.5.
4 Aplicación en Transantiago
4.1 Descripción de los datos de Transantiago
4.1.1 Preprocesamiento
Todos los datos utilizados en este trabajo, fueron preprocesados con anterioridad por la División
Ingeniería de Transporte del Departamento de Ingeniería Civil de la Universidad de Chile.
Primeramente se debió asociar los datos de transacciones Bip! con los datos de posicionamiento
generados por los dispositivos GPS de buses, en el caso del metro se utilizaron las coordenadas de cada
estación. De esta forma fue posible definir una posición para las transacciones.
45
Luego se procedió a estandarizar los archivos de datos utilizados, como por ejemplo los archivos
CSV13 (Comma Separated Values). También se estandarizaron las fechas y tipos numéricos. También se
llevó a cabo un procedimiento de filtrado de datos erróneos.
Se realizó un tramado automático de rutas, esto es, la definición de rutas a partir de puntos
indicados, optimizando el número total de puntos necesarios. En la Figura 21 los puntos sobre los que
pasa una recta perpendicular a la ruta, son aquellos escogidos para la definición de la ruta.
Figura 21: Tramado automático de rutas [12]
Para mejorar la calidad de los datos de posicionamiento, se realizó una proyección de puntos
GPS ortogonalmente a la ruta teórica, en la Figura 22 se muestra un ejemplo para el caso de una ruta
recta, seguido de un ejemplo para el caso de una esquina.
Figura 22: Proyección a ruta [12]
4.1.2 Descripción de datos transaccionales
Luego de la fase de preprocesamiento, se da paso a la etapa de carga de datos en tablas de una
base de datos, luego se optimizan estas tablas según las necesidades de etapas posteriores. En la Figura
23 se muestran cada una de las tablas involucradas y sus respectivas relaciones.
13 Más información en: http://tools.ietf.org/html/rfc4180 - Fecha último acceso: 03/04/2011
46
Figura 23: Diagrama Relacional Transantiago
Las tablas que se utilizan en este trabajo tienen información de fecha y tiempo en que se realizó
la transacción, el id de la tarjeta Bip!, la tarifa que se pagó, la patente del bus o el nombre de la estación
de metro utilizada, latitud, longitud, el operador, capacidad, servicio y sentido del bus, tipo de día
(Laboral, Sábado o Domingo), entre otros.
47
Se puede ver una descripción detalla de los datos en la sección 8.1 de los anexos.
4.2 Implementación del algoritmo
Para la implementación de los algoritmos se utilizó el lenguaje de programación Java, versión 6.
Esta elección se llevó a cabo por su orientación a objetos y portabilidad, ya que se planeó desde un
principio tener la libertad para ejecutar estos algoritmos en plataformas Windows y Mac.
Dado que la base de datos de Transantiago utilizaba el motor PostgreSql, se usó el conector
JDBC versión 4 respectivo.
Se utilizó la biblioteca Java-ml versión 0.1.6 para aplicar el algoritmo OPTICS y la biblioteca
Jcoord versión 1.0 para realizar transformaciones de coordenadas expresadas como latitud y longitud a
coordenadas UTM expresadas en metros dentro de un plano cartesiano definido y viceversa.
4.2.1 Diagrama de Clases
Para la implementación de este proyecto, se utilizó orientación a objetos de forma de obtener
mayor separación de roles entre cada parte del programa. En la Figura 24 se ilustra el diagrama de clases
utilizado. A continuación se describe brevemente la función de cada clase:
• La clase “Kml” se encarga de la visualización de datos.
• La clase “Transaction” contiene toda la información de transacciones y permite calcular
la distancia entre ellas.
• La clase “Day” es un contenedor de todas las transacciones de un día y mantiene datos
como el número de transacciones.
• La clase “OpticsSubida” mantiene toda la lógica necesaria para el cálculo de patrones.
• La clase “DaysTools” es una clase auxiliar que se encarga de realizar operaciones
exclusivamente sobre los días, como por ejemplo la moda del número de transacciones
diarias y diferencias de tiempo entre transacciones.
• La clase “Punto” es otra clase auxiliar para el manejo de coordenadas.
• La clase “ImputationSubida” mantiene toda la lógica necesaria para el cálculo de
imputaciones de datos.
48
Figura 24: Diagrama de Clases
14
4.2.2 Búsqueda de patrones
Una vez que se ha creado una conexión a la base de datos, se extraen los id de las tarjetas Bip!
con las transacciones asociadas, principalmente los datos de posición (latitud, longitud) y tiempo (fecha,
hora), filtrados para obtener solo días laborales (de lunes a viernes. El primer paso dentro del algoritmo
de búsqueda de patrones es crear por cada usuario una estructura de datos que contiene los días con
sus transacciones en orden.
14 Fuente: Elaboración propia.
49
Se dispone de 5 días laborales continuos (viernes a lunes) de una semana de finales de marzo de
2009 y 6 días laborales de la primera semana de abril de 2009. Los datos de cada semana se encuentran
en tablas diferentes.
En la Tabla 5 se muestra información de los registros para cada semana de datos disponible,
considerando la diferencia entre todas las transacciones y aquellas realizadas en días laborales, a su vez,
se muestra el número total de tarjetas Bip! teniendo en cuenta la misma distinción mencionada.
Tabla 5: Datos Transaccionales de Transantiago15
Semana de 2009:
Nº Trx. totales
Nº Trx. (días laborales)
Nº Tarjetas Bips!
Nº Tarjetas Bips! (días laborales)
Marzo 36.056.734 30.291.666 3.268.388 3.081.336
Abril 39.239.077 33.081.579 3.435.692 3.261.753
En los experimentos, se busca analizar el comportamiento de los usuarios, ahora bien, hoy en
día no es posible saber si un usuario utilizó más de una tarjeta Bip! para realizar sus viajes o si varios
usuarios compartieron una misma tarjeta, por lo que estrictamente hablando se buscarán patrones de
comportamiento por cada tarjeta Bip!, pero se hará referencia a esto como comportamiento de
usuarios.
Con la ayuda de la estructura antes mencionada, se obtiene la moda del número de
transacciones diarias, y se analiza la condición expuesta en la Ecuación 5, si se cumple, se filtran los días
que no tienen la moda como número de transacciones de la estructura contenedora de los días del
usuario (tarjeta Bip!).
Luego para cada día se procede a calcular las diferencias de tiempo entre transacciones
aledañas.
Antes de poder clusterizar utilizando el algoritmo OPTICS, se deben traspasar los datos a una
estructura de Java-ml llamada “Instance” para luego agruparlos en otra llamada “Dataset”. En cada
“Dataset” se debe incluir la posición de todas las transacciones pertenecientes a una misma función del
día, y deben ser transformadas a coordenadas UTM, para poder hacer comparaciones de distancia
dentro de un plano.
15 Fuente: Elaboración propia.
50
OPTICS, recibe tres parámetros:
• Distancia máxima que define la vecindad de los elementos de un clúster (por
simplicidad, se hace referencia a un radio Ԑ, que es la distancia máxima entre cada
elemento de un clúster y su vecindad).
• Mínimo de elementos en la vecindad de cada elemento de un clúster para ser aceptado
(o si no, esos puntos se consideran como ruido).
• Medida de distancia (en este caso se usa distancia euclidiana).
Para el radio Ԑ se hicieron pruebas con distintos valores, esto se verá en el capítulo de
resultados. Como mínimo de puntos, se usaron 2 posiciones de transacciones en general, dado la poca
cantidad de días en la muestra utilizada (a lo más, un clúster puede tener 11 elementos, si es que el
pasajero viajó todos los días).
Una vez aceptado un clúster, se obtiene la mediana de las transacciones contenidas y este valor
se transforma nuevamente a coordenadas de latitud y longitud.
En la Tabla 6, se muestra como queda registrado el patrón de un usuario, se almacena el id de la
tarjeta Bip!, la secuencia dentro del día que le pertenece (N), las coordenadas de latitud y longitud, los
deltas de tiempo promedio expresados en segundos respecto a la transacción anterior y posterior. Es
posible ver que el delta de tiempo anterior de una transacción es igual al delta de tiempo posterior de la
transacción anterior, se decidió aceptar esta duplicidad en los datos, para facilitar el acceso a ellos, pero
no tiene mayor relevancia. A una primera transacción de un patrón no es posible calcular su delta de
tiempo anterior y a una última transacción no es posible calcular su delta de tiempo posterior.
Tabla 6: Registros de Patrón16
ID N Latitud Longitud ΔT anterior ΔT posterior
4287666004 1 -33,44476306072 -70,7411700300879 542
4287666004 2 -33,4451430007202 -70,7231420000826 542 2192
4287666004 3 -33,413285170719 -70,5814821900507 2192 2008
4287666004 4 -33,3998821272924 -70,5065788269843 2008 38929
4287666004 5 -33,3901512172819 -70,5004475890179 38929 276
4287666004 6 -33,3960685744342 -70,5056457520313 276 1840
4287666004 7 -33,414312000719 -70,5844360000512 1840 2520
4287666004 8 -33,4442204607202 -70,7238814300828 2520
16 Fuente: Elaboración propia.
51
Durante todo el desarrollo se tuvo presente la eficiencia de los algoritmos, ya que los cálculos
son muy intensivos tanto en uso de CPU como Disco. En particular, se utilizaron índices “btree” con
“fillfactor” al 100%, esto significa que se utiliza una estructura de árbol con todos los nodos saturados
para no perder eficiencia, dado que los datos en la tabla son estáticos y el índice se genera una vez que
ya están todos los datos almacenados. En cambio en una tabla transaccional donde posteriormente se
pueden insertar más datos, es mejor dejar espacios libres en los nodos hojas, ya que se disminuye la
cantidad necesaria de “splits” o divisiones.
Además de utilizar índices, se realizó un reordenamiento de los datos en disco por id, en la tabla
de patrones, lo que ayudó a disminuir aún más el tiempo de ejecución. Esto se puede llevar a cabo
mediante el comando “CLUSTER” de PostgreSql, indicando el índice por el cual se desea reordenar en
disco. El único inconveniente de este comando es que para su ejecución se necesita tener libre en disco
al menos tres veces la cantidad a reordenar.
El mismo resultado se puede obtener creando una nueva tabla mediante una consulta SQL con
todos los datos ordenados por el campo id. La desventaja de este método es que se debe crear una
tabla diferente a la original, para luego eliminar la tabla antigua y renombrar la nueva. La ventaja es que
para este proceso, solo se necesita el doble del espacio de la tabla a reordenar.
4.2.3 Imputación de datos
Para poder imputar datos, se procede a buscar a todos los usuarios que se les pudo definir un
patrón de uso diario, para comparar los días del usuario con el patrón obtenido. Por motivos de
eficiencia, se extraen a una tabla diferente todos los ids de usuarios con patrón y se crea un índice con
reordenamiento en disco.
Si el día que se está analizando posee una transacción menos que el patrón, se busca un posible
“match” o correspondencia según lo explicado en la página 39, en este caso, solo se analizan patrones
de largo mínimo 2. Si el día en estudio posee dos transacciones menos que el patrón, también se busca
una correspondencia con 2 posiciones libres (ver página 39), por lo que el largo mínimo de un patrón
debe ser 3 transacciones diarias.
Si se haya una correspondencia, entonces se procede a imputar el valor que corresponda
utilizando la posición del patrón y los deltas de tiempo involucrados.
Todas las transacciones generadas en Transantiago tienen un identificador correlativo
(autoincrementado) independiente para cada tarjeta Bip! llamado “ntt”, de esta forma, cada vez que se
52
imputa un valor, se asocia mediante el “ntt” a la transacción para la cual es posible usar el valor
imputado como un pivote en la búsqueda del punto de bajada que no se pudo estimar inicialmente.
Finalmente en la Tabla 7 se tiene una muestra de algunos registros de datos imputados para
diferentes tarjetas Bip!.
Tabla 7: Registros de datos Imputados17
ID NTT N Latitud Longitud Tiempo
17910218 398 3 -33,4664073958769 -70,5984774270973 2009-03-25 13:42:23
17945386 1616 2 -33,4445266738048 -70,6574340821642 2009-03-20 20:21:24
17976378 511 2 -33,4262220007198 -70,5909720000524 2009-03-20 18:14:50
18048586 1316 2 -33,4296320007197 -70,6470610000635 2009-03-20 19:17:27
18086570 1244 3 -33,4803621943628 -70,6570266719021 2009-03-24 18:51:59
18062282 1 -33,414312000719 -70,5844360000512 2009-03-25 09:26:15
18090314 1320 2 -33,4509690007209 -70,679166000071 2009-03-26 16:35:53
18088938 762 2 -33,4341087355709 -70,6477966309868 2009-03-25 08:36:53
18095082 472 2 -33,4688190007227 -70,5762010000499 2009-03-24 17:23:55
Es posible observar que el sexto registro mostrado, no posee un “ntt” asignado, esto se debe a
que la transacción imputada es la primera del día (N = 1), por lo que no puede ser utilizada para
encontrar un probable punto de bajada para ninguna transacción de ese día. En un futuro esto podría
cambiar si es que se considerase el caso de que se pueda utilizar esta transacción imputada para la
búsqueda de la bajada de la última transacción del día anterior, aunque por lo general, el algoritmo de
estimación de bajadas usa la primera transacción del mismo día para la estimación de la bajada de la
última transacción de ese mismo día.
A modo de ejemplo, se muestra en la Tabla 8 el patrón generado para el mismo usuario
presentado en la página 31. Entonces se tiene el id de la tarjeta de este pasajero (ID), el orden dentro
del día en que se realiza la transacción (N), la latitud y longitud de abordaje (lugar donde marca con la
tarjeta Bip!) y las diferencias promedio de tiempo con las transacciones anteriores y posteriores.
17 Fuente: Elaboración propia.
53
Tabla 8: Patrón Usuario18
ID N Latitud Longitud ΔT anterior ΔT posterior
1095898 1 -33,5938115707303 -70,7042053900781 2220
1095898 2 -33,4464740007207 -70,6605000000666 2220 1232
1095898 3 -33,4155159013842 -70,5899785359134 1232 26703
1095898 4 -33,408140693246 -70,5649696346231 26703 538
1095898 5 -33,414312000719 -70,5844360000512 538 2032
1095898 6 -33,4455152307207 -70,6609042800667 2032
Utilizando este patrón es posible buscar los posibles valores a imputar, si es que existe alguna
transacción faltante dentro de un día laboral, que como explicamos anteriormente puede ser efecto de
un acto de evasión blanda o porque se utilizó otro medio de transporte en ese tramo del viaje. En este
caso se encontró que el día lunes 23 de marzo de 2009, el pasajero realizó su viaje de costumbre, pero
no realizó la última transacción que comúnmente hace todos los días, luego es de esperar que se haya
bajado en el mismo sitio que acostumbra para la penúltima transacción del día, este punto de bajada
puede ser estimado utilizando como pivote el punto de subida siguiente, que en este caso corresponde
a la última transacción del día, que es valor que se imputa, visible en la Tabla 9.
Luego, el algoritmo de imputación registra la transacción faltante del viaje utilizando los
siguientes datos: el id de la tarjeta Bip!, el número identificador de la transacción a la que se le podría
encontrar un punto de bajada (ntt), la posición dentro del día (N), la latitud, longitud y tiempo (fecha y
hora) de la transacción imputada.
Tabla 9: Imputación Usuario19
ID NTT N Latitud Longitud Tiempo
1095898 1165 6 -33,4455152307207 -70,6609042800667 23-03-2009 19:24:14
Con esto, es posible visualizar en la Figura 25 el dato imputado (resaltado con un rectángulo)
junto a las demás transacciones del usuario.
18 Fuente: Elaboración propia. 19 Fuente: Elaboración propia.
54
Figura 25: Transacciones con Imputación20
Se presenta en la Figura 26 la vista de mapa para el grupo de transacciones pertenecientes a la
sexta posición dentro de los días de la muestra para el usuario analizado, para esto se ha usado un icono
con forma de “pin”. La posición del dato imputado se puede ver con forma de letra “i”.
20 Fuente: Elaboración propia.
55
Figura 26: Mapa Imputación21
Para visualizar mejor la posición donde se encuentran los datos, se presenta la Figura 27, con los
iconos separados. Es posible apreciar que en este caso, las coordenadas de los datos son muy cercanas
entre sí.
Figura 27: Mapa Imputación (otra vista)22
Ahora es posible ejecutar el algoritmo de estimación de bajadas utilizando la base de datos de
imputaciones. En este caso, se podría encontrar un punto de bajada probable para la quinta transacción
del día 23 de marzo identificada con “ntt” nº 1165 para el usuario (o id de tarjeta Bip!) nº 1095898.
21 Fuente: Elaboración propia. 22 Fuente: Elaboración propia.
56
4.2.4 Visualización
Para visualizar en un mapa las coordenadas de las transacciones tal como se ha mostrado en
figuras anteriores (como por ejemplo en la Figura 27), se utilizó Google Earth versión 5.2.
Figura 28: Google Earth23
Para interactuar con Google Earth se utilizaron archivos xml llamados kml24
(Keyhole Markup
Language, estándar internacional mantenido por Open Geospatial Consortium) generados
automáticamente a través de un programa en Java de elaboración propia, usando las bibliotecas
“javax.xml” y “org.w3c.dom” para el manejo de xml.
4.2.5 Concurrencia
Dado que se debía trabajar con un gran volumen de datos y se necesitaron algoritmos intensivos
en CPU, se realizó la programación utilizando threads. De esta forma fue posible hacer un uso eficiente
de todos los “Cores” de la CPU.
Para el manejo de threads se usó la biblioteca “java.util.concurrent.Semaphore”, principalmente
para limitar la creación de threads al número de “Cores” disponibles en cada momento a través de un
semáforo25
.
A continuación se muestra el porcentaje de uso de cada uno de los 4 Cores reales disponibles y
la cantidad de memoria RAM utilizada para una ejecución de algoritmos de búsqueda de patrones:
23 Fuente: Elaboración propia. 24 http://www.opengeospatial.org/standards/kml/ - Fecha último acceso: 03/04/2011 25 http://download.oracle.com/javase/6/docs/api/java/u til/concurrent/Semaphore.html Fecha último acceso: 03/04/2011
57
Figura 29: Uso de CPU y memoria RAM26
Para mayor detalle, se puede ver en la Figura 30, el uso de CPU, Disco y Red, esto último debido
a la interacción entre el programa escrito en Java y PostgreSql a través de JDBC. Se puede observar la
correlación existente entre el uso del disco y la red dado que se encuentra en el mismo computador el
disco con los datos y el servidor PostgreSql. La forma de altos y bajos en Disco y Red se da porque el
algoritmo accede los datos de usuarios en grupos, para luego entregarlos a los threads para su
procesamiento.
Figura 30: Rendimiento27
Los algoritmos de búsqueda de patrones e imputación de datos, escalan bastante bien a medida
que aumenta el número de procesadores disponibles, haciendo un uso promedio de cada uno entre un
90% a 100% en toda la ejecución. Es de esperar que a medida que aumenta el número de procesadores
utilizados, el cuello de botella sea el acceso a disco, por lo que sería útil analizar el uso de arreglos de
discos y/o utilizar discos de estado sólido (SDD) por ejemplo.
Al ejecutar una búsqueda de patrones particular sin threads, se necesitaron 9 horas con 9
minutos, disminuyendo a 3 horas con 47 minutos al utilizar threads, lo que equivale a una reducción del
59% del tiempo. Luego, al ejecutar la respectiva imputación de datos, se necesitaron 5 horas con 8
26 Fuente: Elaboración propia. 27 Fuente: Elaboración propia.
58
minutos sin threads, disminuyendo a 2 horas con 3 minutos utilizando threads, lográndose una
reducción del 60% del tiempo.
4.2.6 Parámetros de algoritmos
El algoritmo de búsqueda de patrones utiliza los siguientes parámetros:
• Umbral de aceptación/rechazo para el poblado mínimo de un clúster ganador.
• Umbral de aceptación/rechazo para la frecuencia de la moda respecto al largo de
transacciones diarias.
• Número de threads que pueden ejecutarse simultáneamente.
Para el algoritmo OPTICS utilizado en la búsqueda de patrones, se tienen los siguientes
parámetros:
• Distancia máxima que define la vecindad de los elementos de un clúster (por
simplicidad, se hace referencia a un radio Ԑ).
• Mínimo de elementos en la vecindad de cada elemento de un clúster para ser aceptado
(o si no, esos puntos se consideran como ruido).
• Medida de distancia (en este caso se usa distancia euclidiana).
El algoritmo de imputación de datos utiliza el siguiente parámetro:
• Número de threads que pueden ejecutarse simultáneamente.
Este algoritmo no necesita más parámetros debido a que toda la información necesaria se
extrae de la base de datos de patrones generados y la base de datos de transacciones.
5 Análisis de Resultados
Los experimentos se ejecutaron en un computador con las siguientes características:
• Procesador: Intel(R) Core(TM)2 Quad CPU Q6600 2.4 Ghz.
• Memoria Ram: 4 GB (3.25 utilizable en S.O. de 32 bits).
59
• Disco: Seagate Barracuda – 7200 RPM – Interfaz SATA 2 (3Gb/s) – capacidad 500 GB.
• Sistema Operativo: Windows 7 – 32 bits.
Los datos utilizados en los experimentos corresponden a transacciones generadas en 5 días
laborales seguidos de marzo de 2009 y 6 días laborales seguidos de abril de 2009 (sin tomar en cuenta
los días no laborales entre medio) con las tienen las siguientes características:
Tabla 10: Datos Transaccionales de Transantiago28
Datos de 2009:
Nº Trx. totales Nº Trx. (días laborales)
Nº Tarjetas Bips! Nº Tarjetas Bips! (días laborales)
Marzo 36.056.734 30.291.666 3.268.388 3.081.336
Abril 39.239.077 33.081.579 3.435.692 3.261.753
El número de tarjetas presentes tanto en los datos del mes de marzo como en los datos del mes
de abril son solo 2.482.789. Por otro lado son 1.377.511 tarjetas excluyentes entre ambas fuentes de
datos, esto es, la unión de tarjetas de ambas muestras menos la intersección.
5.1 Resultados en la búsqueda de patrones
A continuación se presentan los resultados de los experimentos en la búsqueda de patrones
utilizando distintos parámetros en el algoritmo.
Parámetros:
• Tm: Umbral (threshold) de aprobación de la frecuencia moda ( fmoda).
• Ԑ: Radio que define la vecindad de los elementos de la muestra (en metros).
• Tc: Umbral (threshold) de aprobación del número de elementos en el cluster ganador.
• MinPts: En todos los experimentos se usó “2” como valor de este parámetro, debido a la
poca cantidad de días en la muestra.
Además del número de patrones encontrados, se indica el tiempo que demoró el proceso.
28 Fuente: Elaboración propia.
60
Tabla 11: Experimentos - Patrones29
Tm Ԑ Tc Tiempo Nº Patrones
0.8 50 0.8 3 horas con 45 minutos 241.110
0.5 20 0.5 3 horas con 51 minutos 500.905
0.5 20 0.7 3 horas con 47 minutos 240.614
0.5 100 0.5 3 horas con 53 minutos 729.250
Los tiempos de los experimentos son bastante similares independientemente de los parámetros
utilizados. La búsqueda de patrones es sensible ante los umbrales de aprobación de la moda y del
número de elementos de un clúster, por ejemplo en el cuarto experimento solo se varió Tc desde 0.5 a
0.7, y los patrones encontrados disminuyeron de 500.905 a 240.614.
En el caso más relajado (el último mostrado), se tiene que de un total de 729.250 patrones
encontrados en días laborales, 690.143 de esos id de tarjetas están presentes en la semana de datos del
mes de marzo y 694.290 de esos id de tarjetas están presentes en la semana de datos del mes de abril.
Esto equivale a un porcentaje de 690.143
22,4%3.081.336
= usuarios con un patrón definido en la
semana de datos de marzo y se tiene un porcentaje de 694.290
21,3%3.261.753
= usuarios con un patrón
definido en la semana de datos de abril, todo esto respecto a las tarjetas Bip! presentes en los días
laborales.
Además del total de 729.250 patrones, no se debe contar con aquellos que solo tienen 1
transacción diaria, esto es: 196.187. Entonces el total de patrones útiles son 533.063.
5.2 Resultados en imputación de transacciones
Los experimentos realizados en esta sección no utilizan parámetros, ya que depende de los
datos generados anteriormente. Se mostrarán los parámetros con que fueron realizados los
experimentos de búsqueda de patrones para que se entiendan los resultados.
29 Fuente: Elaboración propia.
61
Tabla 12: Experimentos - Imputaciones30
Tm Ԑ Tc Tiempo Nº Imputaciones
0.8 50 0.8 2 horas con 6 minutos 110.945
0.5 20 0.5 4 horas con 14 minutos 241.149
0.5 20 0.7 2 horas con 3 minutos 106.382
0.5 100 0.5 6 horas con 7 minutos 359.591
El tiempo de ejecución en estos experimentos aumenta con el número de imputaciones
encontradas. Comparando con la cantidad de patrones encontrados anteriormente, se tiene que a
mayor cantidad de patrones, es posible imputar una mayor cantidad de valores.
Es importante destacar que, aunque la representatividad de los patrones disminuye a medida
que se utilizan parámetros más relajados, esto no significará que se generen imputaciones erróneas, si
no que la imputación no se generará a partir de un comportamiento marcadamente regular.
A pesar de que se han utilizado parámetros muy relajados en el último caso mostrado, los
resultados están por debajo de las expectativas:
De un total de 359.591 imputaciones encontradas, 125.249 corresponden a imputaciones en la
semana de datos del mes de marzo y 234.342 corresponden a imputaciones en la semana de datos del
mes de abril.
En la semana de datos de marzo se tiene un total de 4.992.331 transacciones realizadas en días
laborales donde el algoritmo de estimación de bajada no pudo estimar, o sea, se logró solo un
125.2492,5%
4.992.331= de transacciones corregidas31.
Esto se puede deber a múltiples factores, como por ejemplo que bajo la metodología expuesta,
solo es posible realizar imputaciones sobre aquellos usuarios que tienen un comportamiento regular, no
habiendo posibilidad de imputar valores para pasajeros con comportamientos irregulares. Un factor que
afecta directamente los resultados, es el la poca cantidad de datos con la que se contaba a la hora de
realizar este trabajo: 11 días laborales. Sería deseable realizar nuevos experimentos con al menos 1 o 2
meses continuos de datos transaccionales. Por ejemplo, pueden existir pasajeros con comportamientos
regulares, pero que no viajan todos los días, estos casos son difíciles de trabajar con poca cantidad de
30 Fuente: Elaboración propia. 31 Este análisis no se pudo realizar para la semana de datos de abril, ya que al momento de realizar este trabajo, no estaban disponibles los datos de estimación de bajadas de esta semana.
62
datos, ya que un par de días que sean diferentes al comportamiento regular podrían provocar que se
rechace ese patrón.
Aunque pueden existir usuarios que regularmente viajen hacia un lugar específico para luego
volver al mismo sitio de origen, bajo la metodología expuesta no es posible definir un patrón si los
usuarios utilizan distintas formas de viajar de forma continua, ya sea utilizando otros medios de
transporte o diferentes alternativas de viaje dentro del sistema de transporte público.
5.3 Evaluación de datos imputados
Para realizar la evaluación de los datos imputados, primero que nada, se debe seleccionar una
muestra de usuarios. De esta forma, se escogieron los datos de pasajeros que tuvieran un patrón de uso
definido y que realizaron transacciones al menos en 5 días laborales del total de 11 días laborales
disponibles en la muestra general y que cada día tuvieran al menos 2 transacciones diarias. Además se
debía cumplir con tener todos los días el mismo número de transacciones diarias. En total se tomó una
muestra de 6.114 pasajeros.
Luego, se procede a quitar una transacción escogida de forma aleatoria a cada usuario,
guardándose en una tabla los datos de las transacciones que se quitaron y en otra tabla todos los demás
datos sin la transacción escogida.
Posteriormente se ejecuta el algoritmo de búsqueda de patrones sobre los datos con la
transacción faltante, encontrándose un total de 6.096 patrones, o sea, se determinó que un 99,7% de
los pasajeros tuvieron un comportamiento regular, lo que era de esperarse, dado que en esta prueba
solo se quitó una transacción.
Finalmente se ejecuta el algoritmo de imputación de datos, encontrándose 6.096 imputaciones,
entonces se tiene que para cada pasajero al que se le definió un patrón fue posible determinar que
faltaba una transacción.
Para analizar la calidad de los datos imputados, se calculó la distancia entre la posición de la
transacción imputada y la posición de la transacción real (que había sido quitada de la muestra
inicialmente). En todos los casos la distancia fue menor a un metro, lo que es muy bueno. Esto se debe a
que el comportamiento de los usuarios respecto al lugar donde abordaron fue bastante regular.
63
Luego se analizaron las diferencias de tiempo existentes entre la transacción imputada y la real,
estas diferencias se distribuyen de la siguiente manera:
Tabla 13: Diferencias de tiempo
Diferencia de tiempo menor a: Cantidad de imputaciones Porcentaje del total
15 minutos 1.924 31,6%
30 minutos 2.965 48,6%
45 minutos 3.623 59,4%
1 hora 4.156 68,1%
1:15 horas 4.573 75%
1:30 horas 4.881 80%
2 horas 5.285 86,7%
3 horas 5.706 93,6%
Luego, es posible observar que la variabilidad temporal de los datos es mayor que la variabilidad
de las posiciones de abordaje en esta prueba, lo que da una idea acerca de lo que ocurre en la realidad,
al imputar datos sin conocer lo que realmente sucedió.
6 Conclusiones
El estudio de un sistema complejo como lo es Transantiago presenta desafíos muy interesantes,
actualmente se han desarrollado metodologías que permiten obtener información valiosa a partir de los
datos generados por este sistema, pero aún es un campo fértil para estudios de diversa índole.
Se ha avanzado mucho respecto a la estimación del punto de bajada de los usuarios y
actualmente se sigue mejorando este proceso, por ejemplo, se han agregado factores de expansión que
permiten una mayor representatividad de los resultados y se está estudiando un mejor método para
diferenciar entre viajes diferentes y trasbordos, entre otros.
Este trabajo es un esfuerzo más para obtener un algoritmo de estimación de bajadas más
robusto y a la vez se deja la puerta abierta a otras posibilidades que pueda generar en sí misma la
búsqueda de patrones de uso en Transantiago.
Dada las características y restricciones de Transantiago, se logró diseñar un método para buscar
patrones de uso, pero esto no significa que sea la única forma de lograrlo. De manera similar, este
trabajo planteó técnicas de imputación para viajes incompletos, basándose en los comportamientos
64
regulares de los usuarios, pero sería posible definir otras técnicas de imputación con características
diferentes.
En este trabajo se tuvo siempre presente la importancia de poder paralelizar los procesos, dada
la gran cantidad de datos que genera Transantiago, es por esto que se implementaron soluciones
capaces de hacer un uso eficiente de todos los procesadores disponibles en un equipo, sin importar si se
utilizan sistemas Windows, Linux o Mac.
Lamentablemente, la cantidad de datos disponibles para realizar los experimentos es pequeña,
considerando que gran parte de este trabajo se basa en cálculos estadísticos. Además se tiene que el
número de transacciones imputadas está por debajo de las expectativas iniciales, dado el universo de
transacciones a las que no fue posible estimar un punto de bajada.
6.1 Trabajo futuro
A continuación se describen los puntos que sería interesante abordar en el futuro de este
trabajo.
6.1.1 Paralelismo (Xgrid)
Durante el desarrollo de este trabajo se ha investigado acerca del funcionamiento de la
tecnología Xgrid (ver sección 3.4), que permite realizar computación distribuida de una forma mucho
más accesible que otros medios de paralelismo. Con un poco de trabajo sería posible adaptar el código
de los algoritmos para que se ejecutaran bajo la arquitectura Xgrid, siendo posible disminuir mucho más
los tiempos de cálculo.
6.1.2 Análisis de patrones de 1 transacción diaria
Sería interesante analizar los casos de patrones con solo 1 transacción diaria, ya que es muy
probable que se trate de casos como por ejemplo, el marido que va a dejar a la mujer a su trabajo y
luego retorna utilizando el sistema de transporte público. De esta forma, se podría buscar algún día
donde puede haber realizado el viaje completo para extrapolar a los demás días. Claramente se debe
hacer un examen riguroso antes de concluir cualquier cosa.
65
6.1.3 Evaluación de algoritmos
Es necesario construir métodos que permitan evaluar de alguna forma directa la calidad de los
datos imputados, como por ejemplo, utilizar una sub muestra de datos de las que se tenga conocimiento
para luego quitar aleatoriamente transacciones dentro de los viajes y de esta forma contrastar lo que
realmente ocurrió con el valor imputado.
6.1.4 Otros métodos de imputación
Sería muy interesante poder desarrollar otras técnicas de imputación de datos que
complementen o contrasten el trabajo aquí realizado.
7 Referencias bibliográficas
[1] M. Munizaga, C. Palma, and P. Mora, “Public transport OD matrix estimation from smart card payment system data,” pp. 1-15, 2010.
[2] C. Cortéz, J. Gibson, A. Gschwender, M. Munizaga, and M. Zúñiga, “Bus commercial speed diagnosis based on GPS monitored data,” presented at the Transportation Research Board 89th Annual Meeting, pp. 1-16, 2010.
[3] R. Chapleau and K. K. Chu, “Imputation Techniques for Missing Fields and Implausible Values in Public Transit Smart Card Data,” in Presented at the 11th World Conference on Transportation
Research, Berkeley, CA, pp. 1-35, 2007. [4] R. Chapleau and K. K. Chu, “Modeling Transit Travel Patterns from Location-stamped Smart Card
Data Using a Disaggregate Approach,” in Presented at the 11th World Conference on
Transportation Research, Berkeley, CA, pp. 1-28, 2007. [5] K. K. Chu and R. Chapleau, “Enriching Archived Smart Card Transaction Data for Transit Demand
Modeling,” presented at the 87th Annual Meeting of the Transportatio Research Board, pp. 1-16, 2007.
[6] R. Chapleau and C. Morency, “Dynamic spatial analysis of urban travel survey data using GIS,” in Twenty-Fifth Annual ESRI International User Conference, San Diego, California, pp. 1-14, 2005.
[7] R. Chapleau, M. Trépanier, and K. K. Chu, “Driver-assisted bus interview (DABI): Passive transit travel survey using smart card automatic fare collection system and its applications,” in Transportation Research Record, 2105, Washington, D.C., 2009.
[8] R. Chapleau, M. Trépanier, and K. K. Chu, “The ultimate survey for transit planning: Complete information with smart card data and GIS,” in International Conference on Survey Methods in
Transport: Harmonization and data comparability, Annecy, France, pp. 1-25, 2008. [9] C. Morency, M. Trépanier, and B. Agard, “Measuring transit use variability with smart-card data,”
Transport Policy, vol. 14, no. 3, pp. 193–203, 2007. [10] I. Witten and E. Frank, Data Mining
Practical Machine Learning Tools and Techniques. Morgan Kaufmann, 2005. [11] M. Trépanier, N. Tranchant, and R. Chapleau, “Individual Trip Destination Estimation in a Transit
Smart Card Automated Fare Collection System,” Journal of Intelligent Transportation Systems, vol.
66
11, no. 1, pp. 1-14, 2007. [12] Marcela A. Munizaga, “Obtención de información a partir de datos de transporte público en gran
escala: GPS + Transacciones bip!,” 21-de abril-2010. [13] P. Yu et al., “Top 10 algorithms in data mining,” Knowledge and Information Systems, vol. 14, no. 1,
pp. 1-37, Enero. 2008. [14] T. Kanungo, D. M. Mount, N. S. Netanyahu, C. D. Piatko, R. Silverman, and A. Y. Wu, “An efficient k-
means clustering algorithm: Analysis and implementation,” Pattern Analysis and Machine
Intelligence, IEEE Transactions on, vol. 24, no. 7, pp. 881–892, 2002. [15] T. Kohonen, “Self-organized formation of topologically correct feature maps,” Biological
cybernetics, vol. 43, no. 1, pp. 59–69, 1982. [16] R. Xu and D. C. Wunsch, Clustering. John Wiley and Sons, 2009. [17] S. A. Rıos, “A study on web mining techniques for off-line enhancements of web sites,” 2007. [18] M. Ester, H. Kriegel, J. S, and X. Xu, “A density-based algorithm for discovering clusters in large
spatial databases with noise,” pp. 226--231, 1996. [19] M. Ankerst, M. M. Breunig, H. Kriegel, and J. S, “OPTICS: Ordering Points To Identify the Clustering
Structure,” pp. 49--60, 1999. [20] A. A. Markov, “Rasprostranenie zakona bol’shih chisel na velichiny, zavisyaschie drug ot druga,”
Izvestiya Fiziko-matematicheskogo obschestva pri Kazanskom universitete, vol. 2, no. 15, pp. 135–156, 1906.
[21] J. O. Berger, Statistical decision theory and Bayesian analysis. Springer, 1985. [22] T. Bayes, “An essay toward solving a problem in the doctrine of chances,” Philosophical
Transactions of the Royal Society of London, vol. 53, pp. 370–418, 1764.
8 ANEXOS
8.1 Diccionario de datos
Para entender mejor la siguiente fase del proceso de transacciones, es necesario revisar uno a
uno los nuevos campos, a continuación se explica cada uno de ellos y al final de esta sección se ilustra
mediante una figura cómo queda la nueva tabla de transacciones.
Op: Código del operador.
Tiempo: Fecha y hora de la transacción (Timestamp).
Id: Código identificador de la tarjeta Bip! con la que se realizó la transacción.
Pago: Tarifa de la transacción.
Ntt: Contador correlativo asociado a cada tarjeta Bip!, se incrementa por cada transacción realizada por
esa tarjeta.
67
Sitio: Lugar donde se llevó a cabo la transacción, este campo guarda el código del paradero en caso de
bus o nombre de la estación en caso del metro.
Tipo_trans: Código del tipo de transacción (cargado de tarjeta, o viaje).
Contrato_num: Código del contrato de la tarjeta Bip!.
Contrato_str: Este campo contiene la información del tipo de contrato de la tarjeta Bip!, como por
ejemplo superior diurno, estudiante en práctica verano, escolar básica, entre otros.
Latitud: Campo que contiene las coordenadas de latitud de la posición de la transacción Bip!.
Longitud: Campo que contiene las coordenadas de longitud de la posición de la transacción Bip!.
X: Campo que contiene la coordenada x en el sistema UTM (ver 8.2), ya que la unidad de medida es en
metros, se utiliza para realizar los cálculos.
Y: Campo que contiene la coordenada y en el sistema UTM (ver 8.2), ya que la unidad de medida es en
metros, se utiliza para realizar los cálculos.
Nsegundos: Campo que contiene la cantidad de segundos que hay entre el tiempo de la transacción y el
pulso GPS más cercano temporalmente. Este dato tiene como objetivo determinar si la estimación de
posición de la transacción hecha en un bus tiene un error aceptable, esto porque existen casos donde el
intervalo entre pulsos GPS del bus son mayores a 30 segundos, en efecto, el intervalo de pulsos de un
bus detenido asciende a 5 minutos.
Servicio: Campo que contiene el servicio del bus donde fue hecha la transacción, cuando el bus no tiene
servicio asignado el campo queda nulo, cuando una transacción es hecha en una zona paga, este campo
almacena todos los servicios posibles concatenados y separados por un guión “-”. Para transacciones
realizadas en una estación de metro, el campo queda nulo.
Sentido: Campo que contiene el sentido del servicio, al igual que el campo servicio es nulo para buses
sin servicio asignado y en el caso en que la transacción se realiza en una estación de metro. Para el caso
de zona paga, este campo contiene la concatenación de los sentidos de los servicios posibles separados
por un signo “-“.
68
Periodo: Campo que contiene la clasificación de horarios definidos por Transantiago, para este campo se
ubica la hora de la transacción sobre la tabla mostrada a continuación, esta tabla contiene más registros
para indicar los días sábados y domingos pero se omitieron para este informe.
Tabla 14: Periodos en casos de días laborales
Tipo Día Definición Periodo Hora Inicio Hora Término
Laboral 01 - Pre Nocturno 23:00 0:59
Laboral 02 - Nocturno 1:00 5:29
Laboral 03 - Transición Nocturno 5:30 6:29
Laboral 04 - Punta Mañana 6:30 8:29
Laboral 05 - Transición Punta Mañana 8:30 9:29
Laboral 06 - Fuera de Punta Mañana 9:30 12:29
Laboral 07 - Punta Mediodía 12:30 13:59
Laboral 08 - Fuera de Punta Tarde 14:00 17:29
Laboral 09 - Punta Tarde 17:30 20:29
Laboral 10 - Transición Punta Tarde 20:30 21:29
Laboral 11 - Fuera de Punta Nocturno 21:30 22:59
Nservicios: Este campo contiene el número de servicios asignados al bus en el instante de la transacción,
el objetivo de este dato es indicar cuando un bus tiene más de un servicio asignado, lo que significa una
ambigüedad en los datos.
Tipo_Transporte: Este campo define el tipo de transporte asociado a la transacción, los casos solo
pueden ser BUS, METRO o ZP (Zona Paga). El objeto de este campo es identificar el tipo de transporte en
forma directa sin necesidad de realizar deducciones usando el campo operador o el tipo de patente para
identificar que son validadores, lo que disminuye futuros tiempos de cálculo.
Capacidad: Este campo indica la capacidad del bus. Al igual que servicio y Nservicios proviene de la
información de asignación de servicio, por lo que será nulo en caso de que no se haya asignado un
servicio.
Tipo_Operador: Este campo indica si el operador es de tipo Metro, Troncal o Alimentador, para obtener
el valor de este campo sabiendo el operador, se usa la siguiente tabla.
Tabla 15: Tabla de información adicional por unidad de negocio
Operador Tipo Operador Unidad de Negocio
1 METRO METRO
2 TRONCAL T2
3 TRONCAL T3
4 TRONCAL T4
5 TRONCAL T5
69
6 ALIMENTADOR A1
7 ALIMENTADOR A2
8 ALIMENTADOR A3
9 ALIMENTADOR A4
10 ALIMENTADOR A5
11 ALIMENTADOR A6
12 ALIMENTADOR A7
13 ALIMENTADOR A8
14 ALIMENTADOR A9
15 TRONCAL T1
Unidad_de_Negocio: Este campo describe al operador con otro tipo de codificación, al igual que el
campo anterior se utiliza la tabla anterior para obtenerlo.
SERV_UN_ZP: Este campo señala el servicio-sentido para los casos que la transacción es hecha en un bus
con servicio asignado o el nombre de la estación de metro cuando la transacción es hecha en metro o la
concatenación de servicios-sentido para el caso que sea zona paga. Este campo toma el valor de la
unidad de negocio para buses sin servicio asignado.
Tipo_Dia: Este campo nos indica si el día es de tipo Laboral, Sábado o Domingo.
Media_Hora: Este campo indica en que modulo horario cae la transacción, los módulos horarios
consisten en la división de un día cada 30 minutos.
Escolar: 1 en caso que el contrato no sea de tipo “Valor” y cero en caso contrario.
Tiempo_Ant: Diferencia de tiempo con la transacción anterior, en caso de no existir una transacción
anterior este campo queda nulo.
Tiempo_Pos: Diferencia de tiempo con la transacción siguiente o posterior, en caso de no existir una
transacción siguiente, este campo queda nulo.
Distancia_Ant: Distancia en metros con la transacción anterior, nulo para el caso de no existir una
transacción anterior.
Distancia_Pos: Distancia en metros con la transacción posterior, nulo para el caso de no existir una
transacción siguiente.
Finalmente la tabla de transacciones queda como se muestra en la Tabla 16.
70
Tabla 16: Tabla de transacciones
Número Nombre Campo Tipo
1 Operador Integer
2 Tiempo Timestamp
3 Id Bigint
4 Pago Smallint
5 Ntt Smallint
6 Sitio Varchar(100)
7 Tipo_Trans Smallint
8 Contrato_num Smallint
9 Contrato_str Varchar(100)
10 Latitud Double
11 Longitud Double
12 X Double
13 Y Double
14 Nsegundos Integer
15 Servicio Varchar(100)
16 Sentido Varchar(50)
17 Periodo Varchar(100)
18 Nservicios Smallint
19 Tipo_Transporte Varchar(20)
20 Capacidad Smallint
21 Tipo_Operador Varchar(20)
22 Unidad_De_Negocio Varchar(20)
23 SERV_UN_ZP Vachar(100)
24 Tipo_Dia Varchar(20)
25 Media_Hora Timestamp
26 Escolar Integer
27 Tiempo_Ant Integer
28 Tiempo_Pos Integer
29 Distancia_Ant Integer
30 Distancia_Pos Integer
Desde la Tabla 17 a la Tabla 20 , se muestra a modo de ejemplo, un conjunto de transacciones
reales, escogidas al azar.
71
Tabla 17: Registros de transacciones – parte 1
Tabla 18: Registros de transacciones – parte 2
Tabla 19: Registros de transacciones – parte 3
72
Tabla 20: Registros de transacciones – parte 4
Identificación de Viajes, etapas y combinaciones.
Utilizando los datos previamente procesados como se explicó anteriormente, se puede dar paso
a una siguiente etapa que busca identificar información más relevante, como por ejemplo cuantos viajes
se realizan utilizando cierto operador, cuantas etapas tienen, tiempos de viaje, entre otros. Para lograr
esto se establecieron ciertas reglas que identifican si una transacción es la primera etapa de un viaje o si
es la última y con esto a su vez definir variadas características que determinan el tipo de viaje. La
metodología de este proceso se describe en [1].
Para la identificación de las transacciones iniciales y finales de un viajes se diseñaron 3 etapas
que filtran e identifican las transacciones, estos filtros se pueden entender como más campos en la tabla
de transacciones Bip!, a continuación se explican cada uno de ellos.
Inicio 1: Este campo indica la forma más intuitiva de identificar un inicio de viaje y corresponde a
transacciones que tienen pagos correspondientes a un primer cobro o para las transacciones que sean la
primera de la tarjeta en los datos.
Fin 1: Este campo indica la forma más básica de identificar una etapa final de un viaje y consiste en
identificar las transacciones tales que la siguiente transacción tenga un pago correspondiente a un cobro
o que sea la última transacción de esa tarjeta en los datos.
Inicio 2: En este campo se realiza un segundo filtro sobre las transacciones que ya son inicio según el
campo inicio1, por lo que tiene los mismos valores que inicio 1 a excepción de los casos que en la
transacción anterior Fin 1 sea falso y Fin 2 (campo explicado más adelante) sea verdadero, en otras
73
palabras, que la transacción anterior se haya transformado en una transacción final de viaje en esta
etapa 2.
Fin 2: Este campo es construido con una lógica que contiene variadas condiciones.
Inicio 3: Este campo es el definitivo para establecer si una transacción es una etapa que inicia un viaje, y
es igual al campo inicio 2 excepto para el caso que la anterior transacción haya sido considerada fin de
viaje indicado en el campo Fin 3.
Fin 3: Este campo contiene el valor definitivo para definir si la transacción es una etapa final de un viaje.
Nviaje: Campo que indica el número del viaje de la tarjeta Bip! durante los datos.
Netapa: Campo que indica el número de la etapa en cada viaje.
Tviajemin: Campo con el tiempo acumulado de cada etapa en un viaje.
Totaletapas: Campo que para cada etapa inicial de un viaje indica el número de etapas total que tiene
ese viaje, sino es etapa inicial está vacío.
N0etapas: Campo que contiene para todas las transacciones un código que indica cuantas etapas tiene
el viaje al que pertenece (1E, 2E, 3E, 4E, +4E).
Combinacion1: Campo que indica la combinación Serv/UN/ZP/Estacion Metro del viaje en orden
cronológico.
Combinacion2: Campo que indica la combinación Serv/UN/ZP/METRO del viaje en orden cronológico.
Combinacion3: Campo que indica la combinación de operador del viaje.
Combinacion4: Campo que indica la combinación por tipo de operador.
Metro: Campo que indica con 1 cuando la transacción es hecha en metro y 0 sino.
S_S: Campo que indica con un 1 cuando la transacción es hecha en bus sin servicio asignado.
PagoTotal: Campo que contiene el pago acumulado durante el viaje.
En la Tabla 21 se muestra un ejemplo de un registro de la tabla descrita anteriormente.
74
Tabla 21: Registro de ejemplo
Número Nombre Campo Ejemplo
1 Operador 11
2 Tiempo 2009-04-05 15:25:26
3 Id 1090090
4 Pago 0
5 Ntt 1414
6 Sitio SA-7180
7 Tipo_Trans 19
8 Contrato_num 101
9 Contrato_str Valor
10 Latitud -33.4581667740567
11 Longitud -70.7055755934334
12 X 341491
13 Y 6296617
14 Nsegundos 4
15 Servicio I03
16 Sentido Regreso
17 Periodo 05 - Mediodía Domingo
18 Nservicios 1
19 Tipo_Transporte BUS
20 Capacidad 77
21 Tipo_Operador alimentador
22 Unidad_De_Negocio A6
23 SERV_UN_ZP I03R
24 Tipo_Dia Domingo
25 Media_Hora 15:00:00
26 Escolar 0
27 Tiempo_Ant 200
28 Tiempo_Pos 500
29 Distancia_Ant 1500
30 Distancia_Pos 2000
31 Inicio1 T
32 Fin1 F
33 Inicio 2 T
34 Fin 2 F
35 Inicio 3 T
36 Fin 3 T
37 Nviaje 1
38 Netapa 1
39 Tviajemin 0
40 Totaletapas 1
41 N0etapas 1E
42 Combinacion1 Estación Central/J13I-J13cI/110I
43 Combinacion2 Metro/A7/T1
44 Combinacion3 metro/alimentador/troncal
45 Combinacion4
75
46 Metro 0
47 S_A 0
48 PagoTotal 460
8.2 Coordenadas UTM
El Sistema de Coordenadas Universal Transversal de Mercator (Universal Transverse Mercator,
UTM) es un sistema de coordenadas basado en la proyección cartográfica transversa de Mercator, que
se construye como la proyección de Mercator normal, pero en vez de hacerla tangente al Ecuador, se la
hace tangente a un meridiano. A diferencia del sistema de coordenadas geográficas, expresadas en
longitud y latitud, las magnitudes en el sistema UTM se expresan en metros únicamente al nivel del mar
que es la base de la proyección del elipsoide de referencia.
Figura 31: Divisiones UTM
Husos UTM:
Se divide la Tierra en 60 husos de 6º de longitud, la zona de proyección de la UTM se define
entre los paralelos 80º S y 84º N. Cada huso se numera con un número entre 1 y 60, estando el primer
huso limitado entre las longitudes 180° y 174° W y centrado en el meridiano 177º W. Cada huso tiene
asignado un meridiano central, que es donde se sitúa el origen de coordenadas, junto con el ecuador.
Los husos se numeran en orden ascendente hacia el este. Por ejemplo, la Península Ibérica está situada
en los husos 29, 30 y 31, y Canarias está situada en el huso 28. En el sistema de coordenadas geográfico
las longitudes se representan tradicionalmente con valores que van desde los -180º hasta casi 180º.
76
Bandas UTM:
Se divide la Tierra en 20 bandas de 8º Grados de Latitud, que se denominan con letras desde la
“C” hasta la “X” excluyendo las letras "I" y "O", por su parecido con los números uno (1) y cero (0),
respectivamente. Puesto que es un sistema norteamericano (estadounidense), tampoco se utiliza la
letra "Ñ". La zona “C” coincide con el intervalo de latitudes que va desde 80º S (o -80º latitud) hasta 72º
S (o -72º latitud). Las bandas polares no están consideradas en este sistema de referencia. Para definir
un punto en cualquiera de los polos, se usa el sistema de coordenadas UPS. Si una banda tiene una letra
igual o mayor que “N”, la banda está en el hemisferio norte, mientras que está en el sur si su letra es
menor que la "N".
8.3 Cadenas de Markov
Una cadena de Markov [20], que recibe su nombre del matemático ruso Andrei Andreevitch
Markov (1856-1922), es una serie de eventos, en la cual la probabilidad de que ocurra un evento
depende del evento inmediato anterior. En efecto, las cadenas de este tipo tienen memoria.
"Recuerdan" el último evento y esto condiciona las posibilidades de los eventos futuros. Esta
dependencia del evento anterior distingue a las cadenas de Markov de las series de eventos
independientes, como tirar una moneda al aire o un dado.
Este tipo de proceso, introducido por Markov en un artículo publicado en 1907, presenta una
forma de dependencia simple, pero muy útil en muchos modelos, entre las variables aleatorias que
forman un proceso estocástico. En los negocios, las cadenas de Markov se han utilizado para analizar los
patrones de compra de los deudores morosos, para planear las necesidades de personal y para analizar
el reemplazo de equipo.
8.4 Inferencia bayesiana
La inferencia bayesiana [21] es un tipo de inferencia estadística en la que las evidencias u
observaciones se emplean para actualizar o inferir la probabilidad de que una hipótesis pueda ser cierta.
El nombre "bayesiana" proviene del uso frecuente que se hace del Teorema de Bayes [22] durante el
proceso de inferencia.
77
Los métodos bayesianos tienen en común la asignación de una probabilidad como medida de
credibilidad de las hipótesis. En este contexto, la inferencia se entiende como un proceso de
actualización de las medidas de credibilidad al conocerse nuevas evidencias. Matemáticamente se trata
de obtener las probabilidades de las hipótesis condicionadas a las evidencias que se conocen. La
actualización de las probabilidades condicionadas hipótesis a las evidencias se fundamenta en la
aplicación del Teorema de Bayes. La diferencia entre los distintos métodos bayesianos, modelos
causales y redes bayesianas, estriba en las hipótesis de independencia condicional entre hipótesis y
evidencias. Dichas relaciones se expresan comúnmente mediante un grafo dirigido acíclico.
La inferencia bayesiana es una inferencia estadística en la que se utiliza la evidencia o las
observaciones para actualizar o inferir nuevamente que una hipótesis puede ser verdadera. El nombre
"bayesiano" proviene del uso frecuente del teorema de Bayes en el proceso de inferencia.
Un ejemplo de inferencia bayesiana es el siguiente:
Durante miles de millones de años, el sol ha salido después de haberse puesto. El sol se ha
puesto esta noche. Hay una probabilidad muy alta (o 'Yo creo firmemente que' o 'es verdad que') el sol
va a volver a salir mañana. Existe una probabilidad muy baja (o 'yo no creo de ningún modo que' o 'es
falso que') el sol no salga mañana.
La inferencia bayesiana usa un estimador numérico del grado de creencia en una hipótesis aún
antes de observar la evidencia y calcula un estimador numérico del grado de creencia en la hipótesis
después de haber observado la evidencia. La inferencia bayesiana generalmente se basa en grados de
creencia, o probabilidades subjetivas, en el proceso de inducción y no necesariamente declara proveer
un método objetivo de inducción.