Análisis y creación de modelos del tráfico en la ciudad de Madrid (2019 - 2021) con R y Python

UNIVERSIDAD COMPLUTENSE DE MADRID FACULTAD DE INFORMÁTICA Trabajo Fin de Grado en Ingeniería Informática Análisis y creación de modelos del tráfico en la ciudad de Madrid (2019 - 2021) con R y Python Analysis and modeling of traffic in the city of Madrid (2019 - 2021) with R and Python Dirigido por: Sonia Estévez Martín Ana Álava Papí Martín Rovira Barrionuevo Curso académico 2021-22 Convocatoria junio 1 Resumen El presente Trabajo de Fin de Grado abarca un estudio del tráfico de la ciudad de Madrid en los años 2019, 2020 y 2021, así como la creación de modelos predictivos de la carga de sus carreteras. El estudio ha sido realizado empleando los lenguajes Ry Python a través del entorno de RStudio. Para ello, nos hemos valido de conjuntos de datos extraídos del Portal de datos abiertos del Ayuntamiento de Madrid[1] tales como: intensidad de tráfico, puntos de medida de tráfico, y distritos de la ciudad de Madrid. Primero, se ha realizado una limpieza básica de datos anómalos que corrompían nuestro estudio, tales como valores negativos, NA y otros códigos de error. Seguidamente, se ha realizado una limpieza exhaustiva basándonos en incongruencias en los datos y eliminando variables que carecían de valor para nuestro estudio. Durante todo este proceso hemos estado en contacto con los responsables del portal de datos del Ayuntamiento de Madrid, los cuales nos han resuelto ciertas dudas que les planteamos. Tras finalizar la limpieza de los datos hemos realizado un análisis descriptivo de las variables, en el que se ha tratado de reflejar visualmente mediante gráficos y mapas el impacto que ha tenido la pandemia en el tráfico de la ciudad de Madrid, haciendo una comparativa de resultados proporcionados por los tres años. Por último, antes del modelado, hemos tratado todos los datos para darles el formato adecuado para emplear los algoritmos de forma eficaz. En lo que al modelo respecta, se han empleado dos técnicas como son la regresión lineal simple y la regresión logística multi-clase. Para cada una de las técnicas empleadas se han realizado varias iteraciones variando diversos parámetros hasta encontrar la combinación óptima de predictores y variables para nuestros modelos. Finalmente hemos realizado un breve análisis de los resultados obtenidos y sus implicaciones. 2 Palabras Clave •Carga •Tráfico •Regresión •R •Python 3 Abstract This Final Degree Project covers a study of the traffic of the city of Madrid in the years 2019, 2020 and 2021, as well as the creation of predictive models of the load of its roads. The study has been carried out using the Rand Python languages through the RStudio environment. For this purpose, we have used datasets extracted from the open data Portal of the Madrid City Council[1] such as: traffic intensity, traffic measurement points, and districts of the city of Madrid. First, a basic cleaning of anomalous data that corrupted our study, such as negative values, NA and other error codes, was performed. Next, an exhaustive cleaning was carried out based on inconsistencies in the data and eliminating variables that had no value for our study. Throughout this process we have been in contact with the responsible for the data portal of the Madrid City Council, who have resolved certain doubts that we raised. After finishing the data cleaning, we have carried out a descriptive analysis of the variables, in which we have tried to visually reflect through graphs and maps the impact that the pandemic has had on the traffic in the city of Madrid, making a comparison of the results provided by the three years. Finally, before modeling, we have treated all the data to give them the appropriate format to use the algorithms effectively. As far as the model is concerned, we have used two techniques such as simple linear regression and multi-class logistic regression. For each of the techniques used, several iterations have been carried out, varying various parameters until the optimal combination of predictors and variables for our models was found. Finally, we have made a brief analysis of the results obtained and their implications. 4 Keywords •Load •Traffic •Regression •R •Python 5 Contents 0.1 Introducción................................. 12 0.1.1 Motivación de la investigación . . . . . . . . . . . . . . . . . . . 12 0.1.2 Objetivos .............................. 12 0.1.3 Antecedentes ............................ 12 0.1.4 Plandetrabajo........................... 13 0.1.5 Estructura de la memoria . . . . . . . . . . . . . . . . . . . . . 14 0.1 Introduction................................. 15 0.1.1 Motivation.............................. 15 0.1.2 Goals................................. 15 0.1.3 Background............................. 16 0.1.4 Workdynamics........................... 16 0.1.5 Document’s structure . . . . . . . . . . . . . . . . . . . . . . . . 17 0.2 Metodología y herramientas . . . . . . . . . . . . . . . . . . . . . . . . 18 0.2.1 Selección de nuestra metodología de trabajo . . . . . . . . . . . 18 0.2.2 Herramientas empleadas . . . . . . . . . . . . . . . . . . . . . . 19 0.2.2.1 Lenguajes de programación empleados . . . . . . . . . 19 0.2.2.2 Entornos de trabajo . . . . . . . . . . . . . . . . . . . 20 0.2.2.3 Herramientas para la comunicación y sincronización . . 21 0.2.2.4 Repositorio de trabajo . . . . . . . . . . . . . . . . . . 21 0.3 Fundamentoteórico............................. 22 0.3.1 Metodología CRISP-DM . . . . . . . . . . . . . . . . . . . . . . 22 0.3.2 Métricasdeerror .......................... 24 6 CONTENTS 7 0.3.3 Algoritmos empleados . . . . . . . . . . . . . . . . . . . . . . . 25 0.3.3.1 Regresión Lineal Múltiple . . . . . . . . . . . . . . . . 25 0.3.3.2 Regresión Logística . . . . . . . . . . . . . . . . . . . . 25 0.3.3.3 Algoritmos descartados . . . . . . . . . . . . . . . . . 28 0.4 Exploración y procesamiento de los datos . . . . . . . . . . . . . . . . . 29 0.4.1 Estudio y comprensión de los datos . . . . . . . . . . . . . . . . 30 0.4.1.1 Obtención del conjunto inicial de datos . . . . . . . . . 30 0.4.1.2 Descripción de los datos . . . . . . . . . . . . . . . . . 31 0.4.1.3 Exploración del conjunto de datos . . . . . . . . . . . 36 0.4.1.4 Calidad de los datos . . . . . . . . . . . . . . . . . . . 37 0.4.1.5 Problemas en la fase de preparación de los datos . . . 37 0.4.2 Tratamiento de los datos . . . . . . . . . . . . . . . . . . . . . . 38 0.4.2.1 Selección de datos y variables . . . . . . . . . . . . . . 40 0.4.2.2 Dar formato a los datos . . . . . . . . . . . . . . . . . 40 0.4.2.3 Construcción de nuevas variables . . . . . . . . . . . . 41 0.4.3 Análisis descriptivo de las variables . . . . . . . . . . . . . . . . 41 0.5 Integración de R con Python . . . . . . . . . . . . . . . . . . . . . . . . 47 0.6 Modelado .................................. 49 0.6.1 1ªFase del modelado - Regresión lineal múltiple en R . . . . . . 51 0.6.2 2ªFase del modelado - Regresión logística multi-clase . . . . . . 55 0.7 Evaluación de los resultados . . . . . . . . . . . . . . . . . . . . . . . . 60 0.8 Conclusiones y trabajo a futuro . . . . . . . . . . . . . . . . . . . . . . 60 0.8 Conclusions and future work . . . . . . . . . . . . . . . . . . . . . . . . 62 0.9 Aportaciones individuales . . . . . . . . . . . . . . . . . . . . . . . . . 63 0.9.1 AnaÁlavaPapí........................... 63 0.9.2 Martín Rovira Barrionuevo . . . . . . . . . . . . . . . . . . . . . 65 List of Figures 1 Diagrama de planificación del mes de Septiembre 2021 . . . . . . . . . 14 2 Esquema de la metodología CRISP-DM . . . . . . . . . . . . . . . . . . 22 3 Encuesta realizada por Data Science Process Alliance en 2020 . . . . . 24 4 Cargasincategorizar............................ 26 5 Cargacategorizada ............................. 26 6 Regresión logística binaria vs Regresión logística multi-clase . . . . . . 27 7 MétodoOnevsAll ............................. 27 8 Árboldedecisión.............................. 28 9 RandomForest ............................... 29 10 Representación de las tablas realizada con la herramienta phpMyAdmin 31 11 Diagrama de flujo de nuestros datos . . . . . . . . . . . . . . . . . . . . 39 12 Intensidad media por tramo en un año . . . . . . . . . . . . . . . . . . 42 13 Intensidad media por tramo en el mes de abril . . . . . . . . . . . . . . 42 14 Carga media por tramo en una fase . . . . . . . . . . . . . . . . . . . . 42 15 Carga media para cada mes y por distrito del año 2020 . . . . . . . . . 44 16 Ocupación media por tramo en el año 2019 . . . . . . . . . . . . . . . . 45 17 Ocupación media por tramo en el año 2021 . . . . . . . . . . . . . . . . 45 18 Ocupación media por horas en el mes de octubre en tramos interurbanos (Años2019y2021)............................. 46 19 Ocupación media por horas en el mes de octubre en tramos urbanos (Años2019y2021)............................. 46 20 Estructura del dataset para nuestros modelos . . . . . . . . . . . . . . 50 8 LIST OF TABLES 15 mapa de calor como en el modelo de regresión logística multi-clase. En el punto 6 se detallan las distintas fases del modelado de los datos. En el punto 7 se evalúan los resultados obtenidos del modelo predictivo. En el punto 8 se exponen las conclusiones y trabajo futuro de este proyecto. En el punto 9 se recogen las aportaciones individuales de cada miembro. 0.1 Introduction 0.1.1 Motivation The first thing we decided was to carry out a TFG on data analysis since we are very interested in this field and we had already studied subjects in which we had worked in a similar way, such as Data mining and the Big Data paradigm, Web Information Management and Social Network Analysis. The main attraction that we see to this field is how you go from having an initial set of data, which a priori does not give you any information, to extract useful information, to which you can give the application you need. In this way, for example, companies have been able to improve manufacturing processes, marketing campaigns, identify fraud and any another application that we imagine. After being clear about the orientation of the TFG, we were looking for the theme, and finally we opted to carry out a traffic data analysis from the Madrid City Council. The reasons that led us to choose this theme are that we find it interesting to learn more about something that affects us daily such as the traffic in our city, In addition, traffic is a very interesting element of study, since sometimes it behaves unexpectedly and it is very difficult to extract patterns about it. 0.1.2 Goals The goals of the research are to be able to get to know some patterns or tendencies in the traffic of the city of Madrid, without going into detail, as we have already mentioned, traffic is a relatively unpredictable element, and therefore hard to study. In addition, taking advantage of the anomalous situation that we have experienced in this recent years with the appearance of COVID-19 and the impact it has had on our lives, we believe it is interesting to study the impact of the pandemic in traffic, that is why we have chosen the data from beginning of the year 2019 until the end of the year 2021. After this initial study of traffic evolution and behavior, we have used different LIST OF TABLES 16 predictive models in order to be able to predict the road load according to different variables. 0.1.3 Background After having defined the theme alongside the goals of our study, we focused on the search of information on previous studies. The most relevant studies that we have found related to our subject, are the studies themselves published on Community of Madrid’s website. These studies carry out an analysis of traffic in the community of Madrid[2], especially oriented to the roads’ capacity, considering the road’s type and vehicles that frequent it. The studies published on this platform are annual, starting in 2015. Currently (April 2022) the reports for the years 2015, 2016, 2017 and 2018 are available, so the 2019-2021 period is not covered, which has given us one more reason to select this time slot to work. We also found a study[3] in the Transparency Portal of the Madrid City Council, where it is analyzed, differentiating between the different districts and types of roads, and intensity of the roads, the latter breaking down the interurban areas and analyzing them in more detail. In addition, the matrix of car trips is estimated, in which areas (urban or interurban) where the origin and destination of these trips take place. In this article[4] from El País, there is a study that compares the traffic data before and after the pandemic, more specifically between the years 2019 and 2021, referring to the influence of teleworking and the possible increase in the use of private vehicles out of fear of the risk of contagion. In this article they work with the same data as those used in this project, but with a more focused approach on mobility and the different transport alternatives such as bicycles and public transport, from which patterns and trends are extracted during the period of the pandemic. 0.1.4 Work dynamics At the beginning of the development of this project we posed two possible ways of guiding it. The first one was to conduct two studies on different data sets (each one conducted by a different member), and then compare the conclusions obtained. The advantages of this approach were that we were going to have differents perspectives and ways of approaching the same problem, which was very interesting for the final analysis comparing both studies. At the same time, the problem that arose was that it was very ambitious, given the fact that it would probably involve two TFGs in one, and we would also omit the team work factor, which is very interesting, especially nowadays where team work is essential to develop a project successfuly. And thats why we opted for the option of working together, synchronously, on the same set of data. For the distribution of tasks, at the beginning we chose to hold meetings via Discord so we could work together, which allowed us to have absolute knowledge of all parts of LIST OF TABLES 17 the project at all times. We kept this work method during the first months, because at the beginning of the project, it seemed to us it was the most important way to familiarize with the data and the whole project. Later, we changed that initial way of working and opted to hold a meeting per week, in which we simply commented on the work that we had been doing during those days and the problems encountered, and in case of having been able to solve them, explained the solution. At these meetings we also shared suggestions on how to approach the work, and new ways of working were agreed upon if necessary. Finally, we specified the tasks to be carried out before the next meeting. To help us coordinate and organize ourselves better, we have used tools we had worked previously with such as Github repositories, Google Drive... In addition, we investigated about new tools that could help us be useful and we discovered Trello, that allows us to have a shared notebook, in which we wrote down the doubts, the tasks completed so far, the tasks in process, future steps of the project, links of interest, etc. In addition, we help ourselves with diagrams with the tasks to be carried out and the estimated due date, in order to have a better control of the deadlines and try to minimize unforeseen events as much as possible. Figure 1 shows an example of one of the Gantt charts that we have used. 0.1.5 Document’s structure This document has been structured as follows: Section 1 describes the motivation, objectives and approach to the development of this project, as well as previous studies related to our project and the structure of the document. Section 2 describes both the methodology chosen for the development of the project and the different tools used for this purpose. Section 3 explains in more detail the chosen methodology and the algorithms used for our predictive model. In section 4, a data exploration, a treatment process in which the data are cleaned, and variables are formatted and created, is carried out. Subsequently, a descriptive analysis of the most significant variables is performed. Section 5 explains the integration of R with Python, both in the development of the heat map and in the multi-class logistic regression model. Section 6 details the different phases of data modeling. Section 7 evaluates the results obtained from the predictive model. Section 8 presents the conclusions and future work of this project. LIST OF TABLES 18 Section 9 contains the individual contributions of each member. 0.2 Metodología y herramientas En esta sección explicamos que metodologías hemos seguido a lo largo de la realización del proyecto, así como las herramientas que hemos empleado durante todo el proceso de desarrollo, además de los principales motivos que nos han llevado a elegirlas frente a las otras opciones de las que disponíamos. 0.2.1 Selección de nuestra metodología de trabajo Las metodologías de desarrollo para minería de datos más conocidas son SEMMA, CRISP-DM y KDD. Cada una de ellas se diferencia por sus fases y planteamientos para desarrollar un proyecto: Tras investigar sobre todas ellas y realizar una comparativa tal y como se muestra en la tabla 1, pensamos que la que más se ajusta a nuestro tipo de proyecto es CRISP-DM (Cross-industry Standard Process for Data Mining) ya que nos permite cubrir todas las fases del proyecto, sus tareas respectivas, y poder hacer relaciones entre estas tareas. Pensamos que es una metodología muy adecuada para nuestro proyecto, ya que la secuencia de las fases no es rígida, pudiendo volver a la etapa anterior para realizar otra iteración si fuese necesario, lo que nos permite mucha flexibilidad a la hora de trabajar en un proyecto como este, en el cual estamos en constante descubrimiento de nuevas necesidades y problemáticas. LIST OF TABLES 19 KDD SEMMA CRISP Flexibilidad Esquema en cascada, secuencia de fases más rígida Alta Alta Complejidad Más complejo de implementar que los otros dos, tiene una cantidad considerable de fases a desarrollar Simple y bastante ágil, sus fases están más implementadas a desarrollo ágil Es el menos complejo de entender y aplicar, cuenta con una curva de adaptabilidad muy amplia para cualquier desarrollador Número de fases 966 Siglas Knowledge Discovery in Databases Sample, Explore, Modify, Model and Access Cross-industry Standard Process Relevancia actual Baja Media Alta Table 1: Comparativa de las principales metodologías para el Data Science 0.2.2 Herramientas empleadas En este apartado explicaremos las herramientas y tecnologías empleadas durante el desarrollo de este proyecto, así como las decisiones que nos han llevado a elegirlas sobre otras alternativas similares. 0.2.2.1 Lenguajes de programación empleados Los principales lenguajes para el tratamiento de datos son Python y R, ya que tienen un amplio soporte de librerías y disponen de múltiples funciones orientadas a realizar Data Science. Además, son herramientas gratuitas y con una amplía aceptación en la comunidad, por lo que hay infinidad de proyectos disponibles en internet, que aunque no se centren en la misma temática, podemos estudiar para coger ideas, solventar dudas y tener en definitiva más facilidad a la hora de trabajar. Además, de esta forma, el proyecto es escalable, permitiendo nuevas orientaciones o incluso ampliaciones del estudio ya realizado. LIST OF TABLES 20 En la tabla 2 mostramos una comparativa entre estos dos lenguajes, centrándonos en las ventajas e inconvenientes que nos aportan al emplearlos en el desarrollo de nuestro proyecto. De esta forma podemos tener una visión más clara de las necesidades que tenemos y las facilidades o inconvenientes de emplear cada uno de los lenguajes mencionados. R Python Pros 1) Muchos paquetes estadísticos 1) Más intuitivo 2) Más potente para visualizar datos 2) Mucha documentación Contras 1) Mayor complejidad 1) Menos potente 2) Ejecuciones más lentas Table 2: Comparativa de los principales lenguajes para Data Science Tras analizar que lenguaje se adaptaba mejor a los requerimientos del proyecto, optamos por emplear R como lenguaje principal y dejamos Phyton relegado a un segundo plano para realizar algunas funciones concretas de acuerdo a necesidades puntuales. Por otro lado, aunque no sea un lenguaje de programación como tal, hemos empleado Latex como herramienta para documentar todo nuestro trabajo. A pesar de no haber trabajado con Latex previamente, hemos considerado que aporta un toque más profesional y adecuado para este trabajo que otras herramientas como Word. 0.2.2.2 Entornos de trabajo Para el uso de R hemos empleado el entorno de RStudio, el cuál nos ha ayudado en las labores de visualización y carga de datos, así como una interfaz más intuitiva con la que trabajar. El desarrollo de la totalidad del código lo guardábamos en un script el cúal teníamos asociado a un repositorio de Github, de forma que podíamos trabajar de forma dinámica sin contratiempos con los backups y ediciones simultaneas. Y en caso de ser necesario realizar pruebas concretas, las ejecutábamos a través de la consola de forma local, con lo que no alterábamos el código, eliminando los riesgos de dejarlo modificado de forma no intencionada. Además, para el empleo puntual de Pyhton fuera del entorno de Rstudio hemos empleado la herramienta Pycharm la cuál nos brinda ciertas facilidades a la hora de trabajar. Otras alternativas similares son Visual Studio Code y editores de texto similares. Para realizar el diagrama de flujo de nuestros datos hemos utilizado Microsoft Visio, LIST OF TABLES 21 ya que nos pareció una aplicación muy intuitiva y fácil de personalizar. 0.2.2.3 Herramientas para la comunicación y sincronización •Discord: Esta aplicación la usamos como principal medio de comunicación, en ella realizábamos nuestras reuniones mediante llamadas y usábamos el chat para ir anotando las dudas que surgían y las tareas a realizar. •Google Meet: Esta aplicación la usamos para realizar reuniones con nuestra tutora, de manera que estuviese al día con nuestros avances, poder resolver nuestras dudas y realizar correcciones. •Trello: En esta aplicación organizamos nuestras tareas por bloques, de manera que podíamos gestionar fácilmente el estado de las tareas moviéndolas entre los distintos bloques según fuéramos avanzando en el desarrollo de nuestro proyecto. •Github: Esta aplicación la usamos para llevar un control de versiones de nuestro código. •Drive: Esta aplicación la usamos para almacenar nuestro proyecto entero, tanto el proyecto de R, como la memoria. También guardábamos documentación útil para el desarrollo del proyecto. 0.2.2.4 Repositorio de trabajo Con el objetivo de que este proyecto sea escalable y reproducible, hemos tratado de documentar todos los pasos seguidos en su realización, tanto a nivel de fundamentos teóricos y estudio, como de desarrollo de código el cual cuenta con comentarios explicativos también. La estructura de nuestros datos consta de tres carpetas: •Distritos: En esta carpeta guardamos los archivos .shp correspondiente a los distritos de Madrid. •Tráfico: En esta carpeta se guardan los archivos .csv de tráfico divididos en tres carpetas, una por año, y en cada una de ellas doce archivos correspondientes a los meses. •Ubicacion_de_los_puntos_de_medida_del_trafico: En esta carpeta se guardan los archivos .shp correspondientes a los puntos de medida de tráfico, divididos en tres carpetas, una por año, y en cada una de ellas los archivos correspondientes a los meses. LIST OF TABLES 22 0.3 Fundamento teórico Como parte del trabajo, a continuación desarrollamos las bases teóricas que respaldan a todos los procesos, algoritmos y metodologías que hemos empleado. 0.3.1 Metodología CRISP-DM Tras comentar los motivos de la elección de esta metodología, a continuación explicaremos en que consiste, así como de las fases que está formada. En la figura 2 podemos observar un esquema a grandes rasgos de esta metodología. Fuente: Alexander Schröder (2021), CC BY-SA 4.0 via Wikimedia Commons Figure 2: Esquema de la metodología CRISP-DM A continuación explicaremos en que consiste cada una de estas 6 fases: 1. Comprensión del negocio Comprensión de los objetivos y requerimientos Valoración de la situación LIST OF TABLES 23 Objetivos de Minería de Datos 2. Estudio de los datos Obtención del conjunto inicial de datos Exploración del conjunto de datos Identificar la de calidad de los datos 3. Preparación de datos Selección de datos Limpieza de datos Construcción de los datos Formateo de los datos Definición del datawarehouse 4. Modelado Implementación en herramientas de Minería de Datos. 5. Evaluación Determinar si los resultados coinciden con los objetivos Identificar las temas de negocio que deberían haberse abordado 6. Despliegue Instalar los modelos resultantes en la práctica Configuración para minería de datos de forma repetida Como podemos observar, la secuencia de fases se ajusta muy bien y es muy coherente con nuestro proyecto, por lo que con ligeros ajustes eliminando la orientación a negocio y obviando el paso del datawarehouse (ya que no necesitamos almacenar los datos de tal forma), podemos implementarla y seguirla de forma muy realista. A pesar de la fuerza que ha cobrado la metodología Scrum en los últimos años, CRISP-DM se mantiene al frente como principal elección para los proyectos de minería de datos, tal y como refleja la encuesta realizada por Data Science Process Alliance en 2020. LIST OF TABLES 24 Fuente: Data Science Process Alliance (2020). Poll result comparision. Figure 3: Encuesta realizada por Data Science Process Alliance en 2020 0.3.2 Métricas de error Las siguiente métricas han sido empleadas como indicador de calidad de las iteraciones realizadas mediante regresión lineal múltiple. Para la comparación del modelo final obtenido de la regresión lineal con el modelo final de la regresión logística multi-clase, hemos empleado otra métrica distinta (el % de acierto del modelo), por problemas de compatibilidad como explicamos más adelante. •MSE: El error cuadrático medio calcula la media de la diferencia cuadrada entre el valor real y el valor estimado, de manera que un error 0 sería un modelo perfecto, y cuanto mayor sea este error peor será el modelo. MSE =1 N N X i=1 (yi−ˆyi)2 donde yies el valor real y ˆyiel valor estimado. •MAE: El error absoluto medio calcula la media de la diferencia absoluta entre el valor real y el valor estimado. Es una puntuación lineal, por lo que cada una LIST OF TABLES 31 hasta diciembre 2021. El motivo de elegir esa franja de tiempo es que contamos con un gran volumen de datos para nuestro estudio (ver tabla 3). Además, podemos estudiar el periodo que comprende a la COVID-19 ya que partimos de un periodo anterior a su aparición en España y más concretamente en Madrid (entorno a febrero-marzo de 2020). 0.4.1.2 Descripción de los datos Para realizar nuestro estudio hemos empleado los siguientes conjuntos de datos: tráfico diario, ubicación de los puntos de medida del tráfico y distritos La estructura de los archivos que contienen dichos conjuntos de datos está esquematizada en la Figura 10. Además, en la Tabla 3 se ofrece una breve descripción de los datos de partida. Figure 10: Representación de las tablas realizada con la herramienta phpMyAdmin Archivo Registros Campos distritos 21 6 pmed_trafico_MM_YYYY ≈4500 por mes 9 trafico_MM_YYYY ≈1100000 por mes 9 Table 3: Descripción de la estructura de los archivos descargados Descripción de Archivos 1) Archivos denominados trafico_MM_YYYY Estos archivos muestran las medidas de tráfico de la ciudad de Madrid en la M30 y en la zona urbana en periodos de 15 minutos. LIST OF TABLES 32 La medición se realiza mediante un sistema de espiras colocadas debajo del asfalto separadas por 2.5 metros. Las espiras son cuadrados de 2 metros de lado que, entre otros, se encargan de medir la velocidad de los vehículos, su tamaño, peso y el tiempo que permanecen ocupadas durante esa medición. En la tabla 4 explicamos en detalle cada variable y los valores que toman. Para dicha tabla, la variable error, resaltada con el símbolo ∗, toma los siguientes valores: N: no ha habido errores ni sustituciones E: los parámetros de calidad de alguna de las muestras integradas no son óptimos S: alguna de las muestras recibidas era totalmente errónea y no se ha integrado LIST OF TABLES 33 Variable Descripción Valores id Identificación única del Punto de Medida en los sistemas de control del Ayuntamiento de Madrid 4372 fecha Fecha y hora oficiales de Madrid [01-01-2019 00:00, 31-12-2021 23:59] tipo_elem Tipo de vía M30 y URB intensidad Número de vehículos que han pasado por el Punto de Medida en el periodo de 15 minutos (se hace una estimación de vehículos/hora) [0, 9420] ocupacion Porcentaje de tiempo que el Punto de Medida permanece ocupado en el periodo de 15 minutos [0%, 100%] carga Parámetro que establece el grado de uso de la vía durante el periodo de 15 minutos. Se calcula de acuerdo a la intensidad, ocupación y capacidad de la vía. [0, 100] vmed Velocidad media de los vehículos en el periodo de 15 minutos (Km/h). Sólo para puntos de medida interurbanos (M30) [0, 246] error∗ Indicación de si ha habido al menos una muestra errónea o sustituida en el periodo de 15 minutos. N, E, S periodo integracion Número de muestras recibidas y consideradas para el periodo de integración. [1, 30] Table 4: trafico_MM_YYYY 2) pmed_trafico_MM_YYYY Contiene los datos de la ubicación de cada uno de los puntos de medida que recogen datos del tráfico de la ciudad de Madrid (calle, coordenadas, barrio...). Este archivo nos ha permitido enlazar nuestros puntos de medida con su localización geográfica, con lo que hemos podido crear ciertas representaciones tales como mapas, asociándolos a su vez al archivo de los distritos. LIST OF TABLES 34 Variable Descripción Valores tipo_elem Tipo vía M30 URB distrito Identificador del distrito de Madrid donde se encuentra el medidor [1, 21] id Identificador único y permanente del punto de medida 4571 cod_cent Código de centralización en los sistemas [1001, 98416] [PM10013, PM43223] nombre Denominación del punto de medida. Para los puntos de medida de tráfico urbano se identifica con la calle. Para los puntos de vías rápida y accesos a Madrid se identifica con el punto kilométrico, la calzada y si se trata de la vía central, vía de servicio o un enlace 4227 utm_x Coordenada X_UTM del centroide de la representación del polígono del punto de medida [429055.9, 450772.3] utm_y Coordenada Y_UTM del centroide de la representación del polígono del punto de medida [4464902, 4485213] longitud Proporciona la localización del punto de medida, en dirección Este u Oeste desde el meridiano de Greenwich [-3.836943, -3.580713] latitud Proporciona la localización del punto de medida, en dirección Norte o Sur desde el ecuador [40.33245, 40.51561] Table 5: pmed_trafico_MM_YYYY 3) Distritos En este archivo se recogen los datos de los distintos distritos de Madrid, contiene información sobre sus coordenadas, tamaño... LIST OF TABLES 35 Variable Descripción Valores cod_dis Identificador único del distrito [1, 21] cod_dis_tx Identificador único del distrito (...) [01, 21] nombre Nombre del distrito 1. Centro 2. Arganzuela 3. Retiro 4. Salamanca 5. Chamartín 6. Tetuán 7. Chamberí 8. Fuencarral - El Pardo 9. Moncloa - Aravaca 10. Latina 11. Carabanchel 12. Usera 13. Puente de Vallecas 14. Moratalaz 15. Ciudad Lineal 16. Hortaleza 17. Villaverde 18. Villa de Vallecas 19. Vicálvaro 20. San Blas - Canillejas 21. Barajas distri_may Nombre del distrito (formato mayúsculas) 1. CENTRO 2. ARGANZUELA 3. RETIRO 4. SALAMANCA 5. CHAMARTIN 6. TETUAN 7. CHAMBERI 8. FUENCARRAL - EL PARDO 9. MONCLOA - ARAVACA 10. LATINA 11. CARABANCHEL 12. USERA 13. PUENTE DE VALLECAS 14. MORATALAZ 15. CIUDAD LINEAL 16. HORTALEZA 17. VILLAVERDE 18. VILLA DE VALLECAS 19. VICALVARO 20. SAN BLAS - CANILLEJAS 21. BARAJAS distri_mt Nombre del distrito (formato mayúsculas y codificación UTF-8) 1. CENTRO 2. ARGANZUELA 3. RETIRO 4. SALAMANCA 5. CHAMARTÍN 6. TETUÁN 7. CHAMBERÍ 8. FUENCARRAL - EL PARDO 9. MONCLOA - ARAVACA 10. LATINA 11. CARABANCHEL 12. USERA 13. PUENTE DE VALLECAS 14. MORATALAZ 15. CIUDAD LINEAL 16. HORTALEZA 17. VILLAVERDE 18. VILLA DE VALLECAS 19. VICÁLVARO 20. SAN BLAS - CANILLEJAS 21. BARAJAS area_m2 m2de la superficie del distrito [4679185 , 237838370] Table 6: Distritos LIST OF TABLES 36 0.4.1.3 Exploración del conjunto de datos La etapa de exploración de los datos es necesaria y en ella se realizan ciertas comprobaciones que nos permiten verificar la consistencia de dichos datos. A menudo estos datos deben ser transformados para facilitar su futuro tratamiento. A continuación indicamos archivo por archivo dichas comprobaciones: 1) Archivos Trafico_MM_YYYY •Si tenemos valores de intensidad = 0 en la M30, la vmed debería ser = 0 ya que no hay flujo de vehículos y por tanto no puede haber vmed. •Para un mismo punto de medida, si observamos dos registros de intensidad iguales, deberíamos obtener ocupaciones prácticamente idénticas, ya que el comportamiento es casi idéntico. Efectivamente los datos se comportaron de la forma prevista. •Para valores de intensidad = 0, la ocupación debería ser = 0, ya que no hay flujo de vehículos. En este caso hemos hallado incongruencias que posteriormente estudiaremos. •Con intensidad > 0, esperamos ocupación > 0, ya que si entran vehículos, mínimo tienen que ocupar un periodo de tiempo las espiras. Al realizar esta comprobación detectamos ciertas anomalías que se estudiarán posteriormente. •Con intensidad > 0 y ocupacion < 30 (valores bajos de ocupación, para evitar los casos de atascos en los que obviamente vmed tiende a 0), esperamos vmed > 0 en la M30, ya que los vehículos deben pasar por las espiras a cierta velocidad, por pequeña que sea. Hallamos casos que se comportaban de manera inesperada los cuales serán objeto de análisis. •En la M30, cuando la intensidad =0ylavmed = 0, nos fijamos en la ocupacion puesto que debería ser elevada reflejando que existe un atasco, ya que hay flujo de vehículos pero están parados. Hay ciertos casos que no cumplen esta hipótesis y reflejan valores de ocupacion muy bajos, por lo que los estudiaremos posteriormente. •La variable error indica si se ha detectado un fallo en la medición, hemos eliminado todas las entradas con estas características. 2) Archivos pmed_trafico_MM_YYYY •La variable cod_cent, que se define como código de centralización en los sistemas, presenta una nomenclatura diferente para los puntos de medida interurbanos, formado por dos letras y 5 dígitos "PMXYYYZ": LIST OF TABLES 37 –Dígito ’X’, corresponde al tipo de calzada con un rango de valores del 1 al 5, pudiendo ser 1 (calzada interior),2 (calzada exterior),3 (carretera de salida de Madrid) y4 (carretera de entrada de Madrid) –Dígitos ’Y’, si se encuentra en la M30, los dos primeros dígitos es el kilómetro y el tercer dígito el hectómetro, si se encuentra en una carretera de entrada o salida, los dos primeros dígitos son el kilómetro del enlace de la carretera con la M30 y el tercer dígito es el número ordinal que indica la proximidad a la M30. –Dígito ’Z’, corresponde a la situación en la calzada con un rango de valores del 1 al 8, pudiendo ser 1 (tronco),2 (Vía de servicio (o lateral)),3 (Transfer de vía de servicio a tronco),4 (Transfer de tronco a vía de servicio),5 (Acceso al tronco),6 (Acceso a la vía de servicio),7 (Salida del tronco),8 (Salida de la vía de servicio). 0.4.1.4 Calidad de los datos •Calidad a priori: Tras realizar el estudio preliminar, podemos afirmar que contamos con un gran volumen de datos, los cuales tendremos que limpiar exhaustivamente puesto que hay numerosas incongruencias pero que afectan a muy pocos datos, por lo que tras la limpieza seguiremos contando con un gran volumen de datos para nuestro estudio. •Calidad a posteriori: Tras la realización de todo el estudio, y viéndolo con perspectiva, la calidad de los datos efectivamente es buena puesto que se han podido desarrollar ciertos modelos con unos porcentajes de acierto alto, pero, la cantidad de datos seleccionado ha sido excesiva ya que hemos tenido muchos problemas a la hora de trabajar con ellos por temas de memoria y velocidad de procesamiento. 0.4.1.5 Problemas en la fase de preparación de los datos Durante el estudio y preparación de los datos, nos encontramos con ciertos obstáculos, tanto de comprensión del comportamiento u obtención de algunas de las variables, como de interpretación de resultados en los que hallamos anomalías que dificultaban la comprensión de los resultados, ya que se presentaban casos opuestos que contaminaban el estudio. Al no tratarse de casos aislados decidimos ponernos en contacto con los responsables del Portal de Datos del Ayuntamiento de Madrid[1], realizando un vídeo, acompañado de una presentación PowerPoint, en el que exponíamos nuestras dudas, tanto las variables que no terminábamos de comprender, como los casos anómalos y nuestra interpretación del posible error. En su respuesta nos explicaron con detalle tanto las variables que no comprendíamos como el porqué de las situaciones anómalas. Esto nos permitió continuar con nuestro estudio y limpiar y procesar los datos de forma más precisa. LIST OF TABLES 38 Nuestras principales dudas fueron: •Para tramos con intensidad igual a 0 y ocupacion elevada (60% o superior), no entendíamos porqué las variables ocupacion ycarga eran iguales (si la ocupacion es de un punto en concreto y la carga es de toda la vía), y porqué, para estos casos, la variable vmed tenía valores NA, y si esos valores afectaban al cálculo del resto de variables. Nos explicaron que esas situaciones pueden darse en atascos o semáforos cuando el censo inicia el minuto ocupado y, poco antes de terminar el minuto, el vehículo que lo estaba activando se ha ido, sin llegar a ser ocupado por el siguiente, de forma que no hay ningún tránsito completo y no se puede calcular la vmed. •Para tramos con intensidad igual a 0 y ocupacion baja (30% o inferior), no sabíamos si esto se debía a que la ocupacion fuese de vehículos que ya se encontraban en el tramo, y para tramos con intensidad mayor que 0 y ocupacion yvmed igual a 0, quisimos saber porqué la ocupacion se comportaba igual tanto para valores altos como bajos. Nos explicaron que, en ambos casos, se debe a un mal funcionamiento del sistema, ya que, por ejemplo, el periodo de ocupación de cada sensor a una velocidad de unos 70 Km/h es de unas 250 milésimas de segundo, y esto hace que el sistema no tenga una fiabilidad del 100%, dejando un margen de error del 5%. •Para tramos con intensidad alta y vmed igual a 0, observamos que había casos en los que la ocupacion era muy baja, y quisimos saber si se debía a un error de la variable vmed, ya que la interpretación que hicimos de ocupacion eintensidad no sugería que hubiese retenciones, y si, como comentamos antes, ese error estaba afectando al cálculo del resto de variables. Nos explicaron que, para tramos urbanos, los sensores son dobles, para poder calcular la velocidad y el tamaño de los vehículos, y cuando un vehículo pasa solo por uno de los dos sensores o uno de ellos no funciona, únicamente se pueden contabilizar los tránsitos y la ocupación del sensor que se ha activado, pero no es posible calcular ni la velocidad ni el tamaño. 0.4.2 Tratamiento de los datos Al tratarse de ficheros de gran volumen de datos, hemos utilizado la librería de R data.table, para mejorar el tiempo de ejecución y facilitar la manipulación y exploración de los datos, concretamente hemos usado las funciones fread yfwrite para optimizar la lectura y escritura de estos. Para poder empezar a trabajar con los datos lo primero es detectar aquellos que nos van a ser de utilidad y prescindir de los que no aportan ninguna información. Para ello hemos realizado una serie de procesos que se explicarán a continuación. LIST OF TABLES 39 Fuente: Iconos csv creados por Freepik - Flaticon Figure 11: Diagrama de flujo de nuestros datos LIST OF TABLES 40 0.4.2.1 Selección de datos y variables Puesto que se trata de datos históricos, el primer paso que hemos realizado es guardar toda la información que teníamos en nuestros datasets. Sin embargo, hemos tenido que tratar los archivos de partida y eliminar algunas columnas, ya que al unir algunos archivos implicaría redundancia de datos. 0.4.2.2 Dar formato a los datos •En nuestros archivos de tráfico tenemos registros de dos tipos de vía: Interurbano (M30) y Urbano (URB), las cuales tienen ciertas diferencias, como por ejemplo que los tramos URB no tienen valores para la velocidad media. Por lo que hemos separado esos datos en dos archivos diferentes de acuerdo a ese criterio. Además, tras un estudio más intensivo hemos decidido agrupar nuestros datos en periodos de 1 hora (originalmente todas las mediciones venían en períodos de 15 minutos). De esta forma hemos pasado a trabajar con 1/4 del volumen de datos, agilizando mucho los periodos de ejecución de nuestros algoritmos. Además, esto no afecta a la calidad de los datos ya que mediciones cada 15 minutos son excesivamente precisas para trabajar con datos de tráfico en un periodo de 3 años. Para realizar este cambio hemos tenido que juntar las mediciones agrupándolas por el id (identificador de punto de medición) y la fecha (la cual pusimos en formato YYYY/MM/DD/HH eliminando minutos y segundos para poder agrupar en periodos de 1 hora). Además, variables como son la carga, la vmed o la ocupación han sido recalculadas aplicando un promedio de los 4 periodos de 15 minutos. Posteriormente, tras la agrupación por horas, hemos creado 4 nuevas variables: año, mes, día y hora a partir de la variable fecha, de esta forma podemos realizar agrupaciones más sencillas basándonos en estos criterios para la realización de gráficas para nuestro estudio. También hemos recodificado la variable día, la cual originalmente indicaba el día del mes (valores desde 1 hasta máximo 31). Hemos aplicado la función weekday() de tal forma que ahora la variable día representa el día de la semana que es (LunesDomingo). Este cambio se debe a que nos interesa mucho más esta codificación para el enfoque que queremos darle a los datos, ya que por ejemplo resulta muy interesante observar tendencias o patrones en los días de la semana, pero no tanto en los días del mes porque es más trivial. Otro de los principales cambios que hemos realizado en este dataset es la aplicación de One Hot Encoding sobre las variables año, mes, día yhora. La estrategia que implementa esta codificación es crear una columna para cada valor distinto que exista en la variable que estamos codificando, y marcar con un 1 la columna a la que pertenezca dicho registro y dejar las demás con 0. Por ejemplo, en vez de tener una variable mes que va puede tomar los valores desde 1 a 12, creamos LIST OF TABLES 47 haga teletrabajo por las tardes. 0.5 Integración de R con Python Para integrar Python en R, a la hora de realizar el mapa de calor, nos documentamos de las posibles opciones, finalmente nos decidimos por la librería reticulate ya que ofrece muchas formas de combinar ambos lenguajes, permitiéndonos aprovechar lo mejor de ambos según las circunstancias. En nuestro caso nos decantamos por desarrollar todo el código Python en un script .py y hacer una llamada desde el script .R a ese script .py para ejecutarlo. Puntualmente realizamos llamadas al script .R desde el script .py para extraer información de tablas, evitando así tener que guardarlas en un .csv. Para el desarrollo del mapa utilizamos las siguientes librerías: •shapefile: Para la lectura y tratamiento de datos de archivos shapefile. •pandas: Lectura y tratamiento de archivos (en nuestro caso .csv). •matplotlib: Para la generación de gráficos a partir de datos contenidos en listas o arrays. •numpy: Para realizar cálculos avanzados. •os: Acceso a funcionalidades dependientes del Sistema Operativo. Información sobre el entorno del mismo y manipulación de la estructura de directorios. •imageio: Para leer y escribir una amplia gama de datos de imágenes, incluidas imágenes animadas, datos volumétricos y formatos científicos. La generación de nuestro mapa consta de tres partes: 1. Preparación de los datos. •Utilizamos un fichero .shp que contiene la información de los distritos, tanto sus nombres como sus coordenadas, y un dataframe que contiene el valor medio de carga por mes para cada distrito. •Modificamos el fichero .shp (distritos) de forma que su columna COD_DIS (identificador único del distrito) fuera de tipo int para poder ordenarla por este factor. •El dataframe (carga_x_distrito) lo obtuvimos con una llamada al script .R en el cual habíamos procesado y estructurado los datos para crear este dataframe, que recogía para cada mes, la carga media por distrito. LIST OF TABLES 48 •Para preparar la paleta de colores que usamos en el mapa de calor, guardamos en un array todos los máximos y mínimos de la carga media de cada mes (para posteriormente hacer una leyenda con valores absolutos para todos los meses), y en otro array guardamos los códigos de color de una paleta, y finalmente ejecutamos la función de la librería pandas qcut(), de la que obtenemos un array ’bins’ con los máximos y mínimos divididos en seis rangos indicando tan solo el máximo y mínimo de cada rango. 2. Creación del mapa. Para generar nuestro mapa, ejecutamos tres funciones por mes. •La primera, una función en la que asignamos un código de color en función del valor de carga del distrito, haciendo uso del array ’bins’, y guardamos esta información en el array tonalidad. •La segunda, una función que, en primer lugar, utiliza las coordenadas del archivo .shp para generar la silueta de los distritos, y en segundo lugar, recorre un array con el id de cada distrito con el que se consulta, en el fichero .shp que coordenadas tiene, y en el array tonalidad el color que le corresponde, y con esto rellena la información de ese distrito haciendo uso de la función fill() de la librería matplotlib. Una vez finalizado este bucle guardamos el mapa en local. •La tercera, la función show() de la librería matplotlib, que muestra el mapa por pantalla. 3. Creación del GIF. •Para generar el GIF, utilizamos la librería Imageio. Recorremos el directorio con los archivos .png creados para cada mapa de cada mes y guardamos en un array el nombre de la imagen leído con la función imread(). Por último guardamos en local el GIF con la función mimwrite(). Además, el modelo de regresión logística multi-clase también lo hemos desarrollado empleando el lenguaje Python, a través del entorno PyCharm para trabajar de una forma más cómoda y potente. En este caso, no conectamos Pyhton a R a través de librerías sino que desde Phython realizamos una lectura de los archivos .csv que habíamos guardado tras el proceso de limpieza. Los motivos de que nos han llevado a emplear Phyton es que ya teníamos cierta familiaridad empleando este tipo de algoritmos y además nos parecía interesante trabajar y familiarizarnos con los dos lenguajes más potentes para DataScience, para, de cara al futuro, tener más perspectiva y experiencia con ambos lenguajes. LIST OF TABLES 49 0.6 Modelado El objetivo de este modelado es poder identificar que factores son los más importantes a la hora de predecir la carga que tendrá una carretera en Madrid en cierto momento. Para el entrenamiento de nuestros modelos hemos reducido el volumen de datos con el que contábamos, ya que a pesar de haber agrupado los registros por horas, y tras todo el proceso de limpieza, el volumen de datos era poco práctico para la realización de los modelos, ya que colapsaban por problemas de falta de memoria y de velocidad de procesamiento. Para disminuir el volumen de datos, hemos aplicado una función pseudo-aleatoria (antes de agrupar los datos en una sola estructura), de forma que nos hemos quedado con el mismo porcentaje de datos de cada uno de los meses para de esta forma mantener el balance de los datos. Tras este proceso, finalmente contamos con un dataset final datos_modelado_completo.csv con 1,032,260 de filas y 11 columnas (de las cuales 10 serán empleadas como predictores, descartando el id ya que no aporta información relevante). En la figura 20 se puede ver una representación del esquema de este dataset en R. LIST OF TABLES 50 Figure 20: Estructura del dataset para nuestros modelos Dado que los modelos hay que entrenarlos con unos datos distintos de los que luego usamos para validar (porque sino hay sesgo), el primer paso que hemos llevado a cabo es aplicar la función sample() con la finalidad de crear dos subconjuntos distintos. La hemos aplicado de la siguiente forma: sample (2, nrow (dataset), replace = TRUE, prob = c (0.7,0.3)). Esta función nos permite asociar un identificador (en LIST OF TABLES 51 nuestro caso 1 o 2) a cada una de las filas del dataset de acuerdo a la probabilidad que hemos escogido en cada caso, de esta forma, cada fila tiene un 0.7 de ser asociada con un 1 y un 0.3 de asociarse al valor 2. Posteriormente, basándonos en esos identificadores, dividimos en dos subconjuntos de acuerdo al identificador. Finalmente, nuestro dataset de entrenamiento datos_modelado_training.csv cuenta con un 70% de los datos y el dataset de validación el 30% restante. El motivo de elegir estas proporciones es que es más apropiado contar con un conjunto de entrenamiento más grande que el de validación, puesto que el conjunto de entrenamiento es el que el algoritmo emplea para aprender a estimar la variable dependiente. 0.6.1 1ªFase del modelado - Regresión lineal múltiple en R Como primera fase del modelado hemos decidido emplear un algoritmo de regresión lineal para ver como se comportaba con nuestros datos y que información nos podía aportar. Para ello, empleamos la función lm() de la librería stats, la cual crea un modelo basándose en regresión lineal simple mediante la siguiente formula y = x1 + x2 ... + xn. Donde yrepresenta la variable dependiente y x1 ... xn representan los predictores que queremos emplear para generar el modelo. En esta iteración hemos empleado el subconjunto de training datos_modelado_training.csv para entrenar el modelo mediante la siguiente formula: iteracion1 = lm(carga = ocupacion + intensidad + hora + vmed + tipo_elem + mes + dia_semana + anio + fase, data = training), de forma que hemos empleado todos los predictores disponibles para ver como se comportaba cada uno de ellos. Tras generar el modelo, empleamos la función summary(), la cual nos aporta diversa información que nos va a permitir estudiar el modelo generado. En la figura 21 podemos observar la información obtenida. LIST OF TABLES 52 Figure 21: Reporte de la 1ªiteración mediante regresión lineal simple LIST OF TABLES 53 El valor Adjusted R-squared = 0.6848 señala que los predictores que hemos empleado en este modelo consiguen explicar un 68.4% del comportamiento de la carga, por lo que para un primer modelo, y empleando regresión lineal simple es un valor bastante significativo. Además si observamos el p-value, podemos ver que la mayoría de nuestros predictores cuentan con valores muy bajos, indicando que tienen baja probabilidad de hacer que nuestra hipótesis falle. Es curioso observar como los registros de los meses de Julio y Diciembre tienen un poco más de tendencia al fallo, probablemente debido a que coincide con los meses de comienzo de periodo vacacional, donde es más difícil predecir los movimientos ya que interviene más el factor humano. Otra de las métricas que observamos, es el RSE (residual standard error) con un valor de 9.73, lo cual implica que nuestra predicción de la carga se estima que tiene ese fallo medio en cada predicción. Dado que nuestra variable carga toma valores en el intervalo [0-100], un fallo de 9.73 no es significativo ya que tampoco nos interesa predecir el valor exacto de la carga, sino una estimación razonable. El problema de las métricas anteriores es que dependen de los grados de libertad del modelo, por lo que solo nos sirven para comparar modelos en los que empleemos el mismo número de predictores y por ello tengamos los mismos grados de libertad. Dado que para encontrar la mejor combinación de predictores hemos ido creando diferentes iteraciones, y en cada una hemos trabajado con diferente número de predictores, hemos recurrido a métricas absolutas en lugar de a las previamente mencionadas de carácter relativo. De esta forma, podamos comparar todos nuestros modelos entre sí. Por lo que para comparar nuestras diversas iteraciones hemos empleado las siguientes métricas: ECM →error cuadrático medio y el EMA →error medio absoluto. Las métricas previamente nombradas están definidas en el punto 0.3.2 del presente trabajo. Este primer análisis en R nos permitió identificar la calidad de cada uno de los predictores, así como ver la calidad de nuestros primeros modelos generados. Tras este paso inicial cambiamos a Python simplemente con la finalidad de experimentar con los dos lenguajes y no restringirnos solo a R. Para el desarrollo de la regresión lineal en Phyton, nos servimos de la función LinearRegression de la librería sklearn además de la librería numpy para emplear funciones vectorizadas y minimizar los tiempos de ejecución. En la figura 22 se muestra el código desarrollado. LIST OF TABLES 54 Figure 22: Código de la regresión lineal en Phyton Puesto que posteriormente hemos empleado regresión logística multi-clase y las métricas de error que empleamos no son válidas para comparar ambos modelos, hemos recurrido al % de acierto como referencia de la calidad de nuestros modelos. Es por ello que la agrupación por rangos mostrada en la figura 22 es necesaria para poder comparar este modelo con el de regresión logística, ya que la regresión logística indica la pertenencia o no a una clase (en nuestro caso, rangos de la variable carga) y en la regresión lineal predecimos el valor de la carga. Para ello hemos llevado a cabo el siguiente proceso: 1. Entrenar el modelo con el conjunto de entrenamiento. LIST OF TABLES 55 2. Emplear el modelo para predecir la carga. Para ello hemos empleado el conjunto de validación. 3. Agrupar la carga en los mismos rangos que los empleados en la regresión logística. 4. Comparar la predicción con la carga real (ambas ya discretizadas). 5. Calcular el % de acierto del modelo empleando los datos de validación. Finalmente tras todo el análisis en R y su posterior implantación en Phyton concluimos con una iteración que cuenta con un porcentaje de acierto del 77.2%, la cual emplea todos los predictores del dataset regresión_logistica_training menos el predictor que hace referencia al id. 0.6.2 2ªFase del modelado - Regresión logística multi-clase Este algoritmo ha sido desarrollado por nosotros empleando las técnicas vistas en asignaturas como Aprendizaje Automático, a diferencia de la regresión lineal anteriormente vista, en la cual empleábamos una librería para su cálculo, hemos decidido crear nosotros y realizar todo el proceso con el desarrollo de nuestras fórmulas . En las siguientes figuras 30,28,27,26 y 23 se muestra todo el código desarrollado (omitiendo carga de datos, librerías ...) para realizar este modelo. A continuación explicamos por orden de ejecución, el funcionamiento de nuestro modelo desarrollado: 1. Llamada a la función: Indicamos como argumentos los conjuntos de entrenamiento y de validación, donde las variables Xcontienen todas las columnas con los predictores que deseamos emplear, y las variables Ycontienen las 4 columnas que representan las clases de nuestra carga. La variable num_labels indica el número de clases con el que estamos trabajando, en nuestro caso 4. La variable regularización representa el termino de regularización que queremos emplear a nuestro modelo, en caso de no querer aplicar regularización se le indica un valor 0. La técnica de regularización permite disminuir el peso de los predictores en caso de estar sufriendo sobre-ajuste en nuestro modelo. El sobre-ajuste supone un problema porque lo que implica es que nuestro modelo está generalizando mal, es decir se ha producido sesgo. Una forma de identificarlo es probar a validar el modelo con los datos de entrenamiento y también de validación, en caso de estar sufriendo sobre-ajuste, el modelo tendrá mucho porcentaje de acierto con los datos de entrenamiento (es normal, ya que se ha entrenado con ellos), pero, a la hora de trabajar con datos nuevos, como es el conjunto de validación, el porcentaje de acierto se verá drásticamente disminuido. LIST OF TABLES 56 Por último mval es número de datos con el que estamos validando, esto nos sirve para posteriormente comparar el número de aciertos con el número de casos y poder extraer el porcentaje de acierto de nuestro modelo. Figure 23: Llamada a nuestro modelo con los parámetros 2. Función One vs All Emplea el método ya explicado previamente en el apartado0.3.2. Además nos servimos de la función opt.fmin_tnc de la librería optimize la cual mediante la llamada que se muestra en la figura 26 nos permite minimizar la función de coste, es decir el error total que comete nuestro modelo al predecir las cargas. Definimos nuestra función de coste de la siguiente forma (figura: 24): Figure 24: Función de coste Donde nuestra hipótesis es: Figure 25: Hipótesis de la regresión logística La fórmula mostrada en la figura 25 indica que nuestra hipótesis es igual a la función sigmoide de un vector Theta (que contiene todos los pesos que el modelo ha calculado para nuestros predictores) multiplicado por la matriz X(que contiene todos los datos de entrada que le estamos suministrando al modelo. El funcionamiento general de esta función One vs All es el siguiente: 1) Calcula el vector Theta con todos los pesos de los predictores que minimizan la función de coste. 2) Además, devuelve el coste asociado a nuestro modelo empleando esos pesos que permiten tener un coste mínimo. LIST OF TABLES 63 2. Creation of a neural network: We would have liked to use more types of models such as neural networks, we think it would be very interesting to see how this model can be adapted to our data and see what information it gives us. 3. Relate it to the crisis in the public transport sector: An interesting idea would be to relate it to public transport data in the city of Madrid during the same period, to see what impact the pandemic has had, and if it has shifted people towards any particular type of transport. 4. Relacionarlo con accidentes de tráfico: Another potential way is to obtain data on accidents that occurred in the same period of time in the city of Madrid. these data, as well as those related to the use of public transport, can be found in the Open Data Portal of the Madrid City Council[1]. The idea would be to find certain patterns in traffic metrics which are related to an increase in traffic accidents. 5. Traffic simulator: Finally, the most ambitious project would be the creation of a traffic simulator with a graphical interface and uses all the registers we have been working with, so that it not only predicts the load but all kinds of variables. This would provide a dynamic view of the traffic flow and undesired situations such as collapses or accidents could be avoided. 0.9 Aportaciones individuales 0.9.1 Ana Álava Papí En primer lugar, realicé tutoriales del lenguaje Ren RStudio para la familiarización con el lenguaje y el entorno de desarrollo, para ello desarrollé proyectos individuales ayudándome de tutoriales y de la documentación oficial de R. En cuanto a la búsqueda de datos para nuestro TFG, nuestra tutora Sonia Estévez nos recomendó el Portal de datos abiertos del Ayuntamiento de Madrid[1], por lo que revisamos los datos de la página buscando una temática que pudiera ofrecernos un estudio amplio y diversas formas de enfoque. Inicialmente nos decantamos por hacer un estudio de la relación del tráfico con la contaminación acústica de la ciudad de Madrid acompañados de las ubicaciones de sus respectivos puntos de medida, pero al comenzar el estudio nos dimos cuenta del gran volumen de datos, información y posibilidades que ofrecían los datos de tráfico, por lo que finalmente, nos decidimos por hacer un estudio únicamente con los datos de tráfico y las ubicaciones de sus puntos de medida. Con los datos ya seleccionados nos dispusimos a realizar un análisis preliminar para la comprensión de las variables y la localización de posibles anomalías. A partir de aquí comenzamos a realizar limpiezas sencillas, es decir, nos centramos en eliminar valores LIST OF TABLES 64 NAs que corrompían la información, así como patrones anómalos. Durante el proceso de limpieza de los datos, me centré en la optimización de funciones, ya que, al tener un gran volumen de datos, ralentizaba mucho su procesamiento y en ocasiones el ordenador no era capaz de procesarlos. Puntualmente, nos surgieron dudas con respecto al comportamiento de ciertos datos, por lo que, a través de nuestra tutora, nos pusimos en contacto con los responsables de los datos del Ayuntamiento de Madrid enviando un vídeo y exponiendo nuestras dudas, las cuales nos resolvieron y pudimos continuar y readaptar nuestra limpieza. En este punto decidimos comenzar a redactar la memoria, para ir documentando los pasos de nuestra limpieza de forma más detallada, para esto, realizamos una reunión con nuestra tutora en la que nos inició en Latex proporcionándonos una plantilla inicial y unas reglas básicas. A continuación, nos repartimos las tareas. Mi tarea consistió en realizar un análisis descriptivo de las variables, para ello, me centré en las variables más significativas, y traté de reflejar el impacto de la pandemia en los resultados: •En primer lugar, se hace una representación anual de la variable intensidad, de manera que se pueda ver el impacto de la pandemia en el número de vehículos en las vías, de esta forma presentamos la tendencia que van a seguir nuestros datos a lo largo del estudio. Para hacer un mayor hincapié, se representa el mes de abril para los tres años, perteneciendo abril de 2020 íntegramente al periodo de confinamiento. Ambas representaciones en un gráfico de barras. •Para la representación de la variable ocupacion, se analiza mensualmente, en un gráfico de barras, pero únicamente para los años 2019 y 2021, de manera que se pueda hacer una comparativa entre la antigua y la nueva normalidad, centrándonos posteriormente en un análisis por horas en el que se pretende relacionar la evolución de la ocupacion con la aparición del teletrabajo. •Para la representación de la variable carga, se analizan, en un gráfico de barras, los tres años en el periodo correspondiente a las tres fases de desescalada. Adicionalmente, representé la variable carga en un mapa de calor por distritos, integrando Python y R, para ello me informé de las distintas librerías, tanto en R como en Python para la generación de mapas, finalmente decidí realizar la preparación de las tablas de datos en R y el tratamiento de los datos y la generación del mapa en Python. Para ello utilicé los datos proporcionados de la ubicación de los puntos de medida a modo de conexión entre los datos de los distritos y los datos de tráfico como se puede ver en la tabla 10, de esta forma representé los valores medios de carga en cada distrito con distintas tonalidades, siendo la más oscura la de mayor carga y la más clara la de menor. LIST OF TABLES 65 Finalmente participé en el desarrollo de la memoria. 0.9.2 Martín Rovira Barrionuevo Al comienzo del curso académico empecé con la búsqueda de información relativa a las herramientas que íbamos a emplear, como por ejemplo el lenguaje R. Para ello, nuestra tutora, Sonia Estévez, nos facilitó alguna documentación la cual proponía mini trabajos que a pesar de ser de temáticas distintas vino muy bien para ir cogiendo soltura con el lenguaje. Además de esta documentación, investigué por otras fuentes como son la biblioteca de la facultad (online), youtube e internet en general. Durante las primeras semanas estuvimos buscando conjuntos de datos que nos pareciesen interesantes y contasen con datos de calidad para realizar nuestro estudio. Tras evaluar diversas opciones y centrarnos en los datos de tráfico de la ciudad de Madrid, empezamos el trabajo con los datos de forma conjunta a través de reuniones en la plataforma Discord, donde mi compañera y yo empezamos a realizar las primeras fases de limpieza y comprensión de los datos de manera conjunta. Posteriormente, contactábamos con nuestra tutora para comentar los avances y las dudas que iban surgiendo. Inicialmente estas reuniones eran de carácter semanal, lo cual era propiciado por la gran cantidad de dudas originadas de empezar el trabajo y el uso de un lenguajes prácticamente nuevos como eran R y Latex. Después de este comienzo, pasamos a un análisis más profundo de los datos y esto implicó nuevas dudas y nuestra tutora Sonia nos facilitó el contacto de los responsables del Portal de Datos del Ayuntamiento de Madrid, a los cuales les mandamos un vídeo con una presentación sobre las dudas que no eramos capaces de resolver (dicho vídeo y la presentación asociada está disponible en la carpeta de anexos del trabajo). Tras unos cuantos correos con el Ayuntamiento de Madrid, resolvimos todas nuestras dudas y procedimos a corregir y aumentar la limpieza de acuerdo a la información obtenida. Una vez terminadas las fases de limpieza y los meses iniciales, cambiamos el plan de trabajo de forma que nos repartíamos tareas para poder avanzar más rápidamente y las reuniones empezaron a ser cada 2 semanas. Por mi lado me centré en el formateo y una segunda limpieza de los datos para prepararlos para entrenar a los modelos que íbamos a emplear posteriormente. Me centré en estudiar las variables, ver como podía adaptarlas para que se comportasen de forma adecuada e investigué las posibles predictores a crear para aportar un extra de información. Esta fase previamente mencionada requirió mucho tiempo pues tuve que volver constantemente a realizar reajuste de acuerdo a las necesidades que iban surgiendo, por lo que no se trató de una sola iteración, sino multitud de pequeñas iteraciones desarrolladas a lo largo de los meses. Posteriormente pasé a la creación de los modelos mediante Python. Una vez acabados los modelos, empecé a trabajar en el modelado, intentando buscar la combinación óptima de las métricas para maximizar el rendimiento de nuestros modelos. LIST OF TABLES 66 Durante todo el proceso realizado fui documentando junto a mi compañera todos los pasos realizados, de forma que el presente documento ha sido creado poco a poco a lo largo de los meses. Finalmente y de forma conjunta, mi compañera y yo revisamos toda la documentación y completamos de acuerdo a las especificaciones. Bibliography [1] Honorio Enrique Crespo Díaz Alejo. Portal de datos abiertos del ayuntamiento de madrid. Consultor de los ayuntamientos y de los juzgados: Revista técnica especializada en administración local y justicia municipal, (3):128–144, 2020. [2] Estudio de la intensidad media diaria de vehículos (imd), 2020. https: //www.comunidad.madrid/servicios/transporte/estudio-intensidad-mediadiaria-vehiculos-imd (última visita, 16-05-2022). [3] Estado de la movilidad de la ciudad de madrid, 2019. https: //transparencia.madrid.es/FWProjects/transparencia/Movilidad/Trafico/ InformesMovilidad/InformeMovilidad2019.pdf (última visita, 16-05-2022). [4] Daniele Grasso y Borja Andrino. ¿cómo ha cambiado la movilidad en madrid? un millón de viajes menos en transporte y coches como antes. 2021. https://elpais.com/espana/madrid/2021-12-12/como-ha-cambiado-lamovilidad-en-madrid-un-millon-de-viajes-menos-al-dia-en-transportey-trafico-como-antes-de-la-pandemia.html (última visita, 16-05-2022). [5] Joaquín Amat Rodrigo. Introducción a la regresión lineal múltiple. 2016. https:// www.cienciadedatos.net/documentos/25_regresion_lineal_multiple (última visita, 16-05-2022). [6] Hadley Wickham. ggplot2: Elegant Graphics for Data Analysis. Springer-Verlag New York, 2016. https://ggplot2.tidyverse.org (última visita, 16-05-2022). 67