Lunes: montar el repo y mirar los datos

## Lunes, 11:00. Los extractos ya están en la carpeta

Ya sabes qué vas a predecir y por qué importa. Ahora toca mirar los datos de verdad. Rebeca te ha dejado en la carpeta compartida cinco ficheros CSV, y antes de calcular nada con ellos hay una regla que se aprende pronto y se agradece siempre: no te fíes de lo que crees que hay dentro de un fichero hasta que lo abras y lo mires. Un extracto puede traer más filas de las que esperas, columnas en un tipo raro, o la misma magnitud escrita de mil formas. El lunes de un proyecto es para eso: para dibujar el mapa del terreno antes de empezar a construir.

Estos son los cinco ficheros, y conviene entender qué representa cada uno porque van a cruzarse toda la semana. El histórico de servicios tiene un aviso por fila: cada llamada que atendió la central, con su marca de tiempo, su zona, su tipo (avería, grúa, rueda, arranque, rescate) y la matrícula del coche. El maestro de zonas tiene una fila por zona canónica, con su población y si es metropolitana. La meteo tiene la temperatura por zona y hora. El calendario de festivos tiene una fila por día del año, con si es festivo. Y los periodos a predecir son los tramos futuros —próximos días por zona y hora— que Rebeca quiere que le predigas, todavía sin demanda porque aún no han pasado.

## Lo primero: la forma de cada tabla

La forma de una tabla —cuántas filas y cuántas columnas tiene— es la primera pregunta que se le hace a un dato nuevo, porque ya cuenta una historia. Si el histórico de servicios tiene más de cien mil filas, eso te dice que hay muchísimos avisos, y que cada uno es una llamada suelta: todavía no una serie. Si la meteo tiene veintitrés mil filas, es porque guarda una temperatura por cada zona y cada hora de un año entero. Mirar las formas no es un trámite: es la primera comprobación de que las tablas son lo que crees que son.

En pandas, la librería de Python para manejar tablas, cargar un CSV se hace con `pd.read_csv` y la forma se consulta con `.shape`, que devuelve una pareja de números: filas y columnas. En el primer ejercicio vas a cargar los cinco ficheros de golpe y pedir la forma de cada uno. Es el primer bloque de tu fichero `src/01_explorar.py`.

## La pieza clave del caso: un aviso no es un tramo

Aquí está la idea que de verdad tienes que entender hoy, porque condiciona todo lo que harás mañana. El histórico de servicios está a la granularidad del aviso: una fila por cada llamada atendida. Pero la central no dimensiona los turnos aviso a aviso, sino por tramo horario y zona: "cuántos operadores pongo el martes de 8 a 10 en Zaragoza". Así que el modelo no se entrena sobre los avisos sueltos: se entrena sobre una serie donde cada fila es una combinación de zona, fecha y hora, con un recuento de cuántos avisos entraron en ese tramo. Ese recuento, n_servicios, es el target. Pasar de "un aviso por fila" a "una fila por zona/fecha/hora" se llama agregar, y es el trabajo central del martes.

## Y empieza a oler la suciedad: la zona escrita de mil maneras

Mientras miras el histórico, algo chirría. La zona debería ser una de cuatro —Zaragoza, Madrid, Valencia, Ebro-A2—, pero cuando pides los valores distintos de la columna te salen muchísimos más: " Zaragoza " con espacios, "Zgz", "ZARAGOZA", "ZARAGOZA centro", "zaragoza", "Mad", "Vlc", "València", "corredor Ebro"... Guillem te lo confirma: cada operador escribe la zona como le da la gana, y hay más de veinte variantes para esas cuatro zonas. Hoy solo tienes que ver que están ahí y entender que esa columna no se puede usar hasta normalizarla; mañana la mapeas a las cuatro canónicas contra el maestro de zonas.

Lo mismo pasa con la marca de tiempo, y es peor, porque es la columna de la que depende toda la serie. Guillem te avisa de que el timestamp viene en tres formatos mezclados según el módulo del CAU que lo generó: unos como "2023-07-26 22:26" (el formato ISO de siempre), otros como "27/03/2023 22:17" (día primero, al estilo español), y otros como "19 ago 2023 08:09" (con el mes abreviado en español). Ese tercero es el traicionero, y mañana le dedicarás un rato, porque la herramienta normal de pandas para parsear fechas no entiende que "ago" significa agosto. Hoy solo apúntalo.

## Contar los avisos desde SQL

No todo lo vas a hacer en Python. Para cruzar y contar extractos, muchas veces es más rápido escribir una consulta SQL, el lenguaje de las bases de datos. En CoberturaYa tienes DuckDB, un motor que te deja consultar directamente los CSV como si fueran tablas: cada fichero se convierte en una tabla con el nombre del fichero sin la extensión, así que `servicios.csv` es la tabla `servicios`. En la carpeta `sql/` de tu repo dejarás las consultas de agregación, y la primera cuenta cuántos avisos hay por zona y por mes: el primer vistazo al pulso de la demanda, para ver si de verdad hay más en invierno como dice Rebeca.

Para agrupar por mes necesitas sacar el mes de la marca de tiempo, y en DuckDB eso se hace extrayendo el componente de mes de la columna. Como la zona todavía viene sucia, de momento la cuentas tal cual para hacerte una idea del volumen; la normalización fina es cosa de mañana. El objetivo del ejercicio no es un número perfecto, es ver la forma: dónde entran más avisos y en qué meses.