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. Nuria 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 unidades que nadie te avisó de que estaban mezcladas. 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 entre ellos durante toda la semana. La ficha de las parcelas tiene una fila por parcela: su cultivo, su superficie, su tipo de suelo, cuánto se regó y cuánto se abonó. Los sensores tienen muchas filas por parcela —una lectura cada pocos días a lo largo de la campaña—, con la humedad, la temperatura, la lluvia y las horas de sol. El NDVI, el índice de vegetación que llega del satélite, también trae varias pasadas por parcela. La cosecha tiene una fila por parcela con el número que quieres predecir, los kilos por hectárea. Y las parcelas nuevas son las de este año, con la misma ficha que las demás pero todavía sin cosecha: son las que al final tendrás que predecir.

## 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 la ficha de parcelas tiene dos mil filas y los sensores sesenta y siete mil, eso te dice de entrada que hay muchas lecturas de sensor por cada parcela, y que para modelar tendrás que resumir esas lecturas a una sola fila por parcela. Si la cosecha tiene las mismas filas que las parcelas, confirma que hay un rendimiento por parcela. Mirar las formas no es un trámite: es la primera comprobación de que las tablas encajan como esperas.

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`.

## Lo segundo: qué tipo ve pandas en cada columna

Saber cuántas columnas hay no basta: hay que saber de qué TIPO las ve pandas, porque ahí se esconde la mitad del trabajo de limpieza. Cuando pandas lee un CSV, intenta adivinar si cada columna es un número entero, un número con decimales o texto. Si una columna que debería ser un número viene con algo pegado —un símbolo, una unidad, una coma en lugar de un punto—, pandas no la reconoce como número y la trata como texto. Y una columna de texto no se puede promediar ni meter en un modelo: hay que limpiarla primero. Así que inspeccionar los tipos el lunes es, en realidad, hacer la lista de deberes del martes.

En pandas, el tipo de una columna se consulta con `.dtype`, y lo que verás es un vocabulario corto: `int64` es un número entero, `float64` es un número con decimales, y `object` es la etiqueta que pandas le pone al texto. La trampa está en las columnas que salen como `object` cuando esperabas un número: ahí hay suciedad escondida. En la ficha de parcelas vas a encontrar varias, y no por casualidad.

## Contar las filas desde SQL

No todo lo vas a hacer en Python. Para cruzar y contar extractos, muchas veces es más rápido y más claro escribir una consulta SQL, el lenguaje de las bases de datos. En AgroSense 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 `parcelas.csv` es la tabla `parcelas`, `sensores.csv` es `sensores`, y así con todas. En la carpeta `sql/` de tu repo vas a dejar las consultas de agregación, y la primera es la más sencilla: contar cuántas filas tiene cada tabla, para confirmar las formas que viste en Python pero desde el otro lado.

La función de SQL que cuenta filas es `COUNT(*)`: cuenta todas las filas de la tabla, sin mirar ninguna columna en concreto. Es distinta de `COUNT(DISTINCT algo)`, que cuenta valores diferentes de una columna. Confundir las dos es un error clásico, y precisamente ese es el defecto que vas a corregir: una línea cuenta parcelas distintas en vez de contar lecturas totales, y por eso una cifra sale mucho más baja de lo que debería.

## Y la pista del lunes: la humedad no cuadra

Mientras miras los sensores, algo chirría. La humedad del suelo debería ir de 0 a 100 por ciento, pero ves valores de 0,42 al lado de valores de 42, y alguno de 150. Se lo comentas a Dídac, y te explica el clásico de los sensores de campo: los nodos del lote viejo mandan la humedad en tanto por uno (0,42 significa 42%) y los nuevos la mandan en porcentaje (42 es 42%), así que la misma magnitud viene en dos escalas mezcladas en la misma columna. Y además hay valores imposibles —una humedad del 150% o negativa— de cuando un sensor se vuelve loco. Hoy solo tienes que entender que están ahí; mañana los arreglas.

Con eso cierras el lunes: sabes qué cinco tablas tienes, cómo se cruzan, qué columnas vienen sucias y por qué la humedad trae números raros. No has calculado nada útil todavía, y está bien así. Mañana empiezas a limpiar y a construir la tabla con la que de verdad vas a modelar.